Transcript Network Security

Network Security:
Broadcast and Multicast,
Mobile IPv6
Tuomas Aura
Outline
Broadcast and multicast
Receiver access control (i.e. data confidentiality)
Multicast authentication
DoS protection
Mobile IPv6
Spoofed bindings, bombing attack
Return routability test
2
Broadcast and multicast
Broadcast and multicast
Unicast = send to one receiver
Traditional IP routing
TCP, HTTP, video and audio streaming
Server sends a separate copy to each receiver
Broadcast = send to everyone
Terrestrial radio and television, satellite
Link-layer broadcast on Ethernet or WLAN,
flood-fill through an overlay network
Multicast = send to a group of receivers
IP multicast, overlay streaming , IPTV
Can save bandwidth by routing through a tree
4
IP unicast
5
Satellite
broadcast
6
IP multicast protocols
7
IP multicast
Internet group management protocol (IGMP) in IPv4 and Multicast
listener discovery (MLD) in IPv6 between clients and the gateway router
Clients use to connect to a local multicast router
Protocol-independent multicast (PIM) within larger networks
PIM sparse mode (PIM-SM) or dense mode (PIM-DM) used closed routing
domains
Inter-domain protocols: Multicast Source Discovery Protocol (MSDP) and
MBGP
Still experimental
The multicast routing protocols do not provide security in themselves
8
Future of multicast and broadcast?
Multicast tree vs. P2P overlay multicast protocols
Youtube and unicast
9
Security goals
Applications: satellite and cable TV, Internet TV,
peer-to-peer content distribution, GPS/Galileo,
teleconference
Access control to multicast and broadcast data
Data authentication
DoS protection — access control for senders
Privacy — confidentiality of subscriber identities
(which channel is my neighbor watching?)
10
Receiver access control
11
Access control to data
Goal: allow only authorized access to data
Encrypt data, distribute keys to authorized
recipients (= multicast group)
Key distribution issues:
Revocation speed
Amount of communication and computation per joining or
leaving node
Scalability (teleconference vs. satellite TV broadcast)
Possible packet loss when session keys are replaced
Sharing keys to unauthorized parties is easier than sharing
data
Group key distribution
Various efficient protocols for distributing keys to a
multicast group
Typical solution: unicast key distribution to individual
subscribers
Ok for small groups (e.g. teleconference) or slow updates (e.g.
IPTV subscription)
Can piggyback individual key updates on multicast data
Does not require separate unicast channel
Ok for slow updates (e.g. satellite TV)
Advanced protocols
Typically log(N) communication to revoke one receiver out of N
13
Multicast and broadcast
authentication
Multicast data authentication
Security goals:
Integrity, data-origin authentication
Sometimes non-repudiation
Early dropping of spoofed data
Other constraints:
Loss tolerance vs. reliable transmission
Real-time requirements
Small groups could use a shared key and MACs
Every member can spoof data
Won’t work for large or mutually distrusting groups
Asymmetric crypto seems the right tool
One sender and many receivers
15
Hash chaining
Forward chaining
Amortize the cost of a signature over many data packets
Sender can send in real time
Receiver should buffer data and consume only after signature received
Received vulnerable to DoS from spoofed packets
hash
data
H1
data
H2
data
H3
H4 Sign(H4)
data
n=4
Backward chaining
Received can authenticate and consume data immediately
Sender must buffer data before sending and signing
Sign(H1) H1
data
H2
data
H3
data
H4
data
n=4
16
Loss tolerant chaining
Redundant hash chains
Efficient multi-chained stream signature (EMSS)
E.g. 1-3-7 chaining sequence tolerates bursty losses of up
to 7 packets:
Redundant signatures costly
Random chaining sequence shown to be efficient
Alternative: forward error correction code
17
Guy Fawkes protocol (1)
Delayed authentication [Ross Anderson 1997]
Initially, receiver knows Y = hash(X)
To authenticate message M:
1. Sender publishes Z = MACX(M)
2. Sender reveals M, X
Z is a commitment that binds the message M and
the secret X. Revealing X later authenticates M
Critical detail:
The commitment Z must be received before X is revealed
In the Guy Fawkes protocol, Z is published in a news paper
= broadcast medium with guaranteed latest delivery time
18
Guy Fawkes protocol (2)
Out-of-band initialization:
Sender selects a random X0 and computes Y0 = hash(X0)
Sender publishes Y0 via an authenticate channel
Protocol round i=1,2,3,…:
1. Sender selects a random Xi and computes Yi = hash(Xi)
2. Sender publishes in a newspaper Zi = MACXi-1 (Mi, Yi)
3. Sender reveals Mi, hash(Xi), Xi-1
Zi is a commitment that binds the message Mi and the
secret Xi-1. Revealing Xi-1 later authenticates Mi
The next key Yi is authenticated together with Mi
Critical:
Each Zi must be received before Xi-1 revealed
19
Lamport hash chain
[Leslie Lamport 1981]
One-time passwords for client-server authentication
Initialization:
Random number X0
Hash chain Xi = h(Xi-1), i=1…n
Server stores Xn
Client reveals hashes in reverse order: Xn–1, Xn-2,…
Protects against password sniffing
Cannot be replayed like a normal password
Better than real random passwords> takes less storage space
and the serve password database (/etc/password) can be public
Entity authentication only; no key exchange
20
TESLA (1)
Time efficient stream loss-tolerant authentication [Perrig et
al. 2000][RFC 4082]
After initialization, secret-key crypto (cryptographic hash and
MACs) only
Delayed authentication: broadcast sender commits to MAC
keys and reveals them after a fixed delay
Authentication delay at least one round-trip time (RTT)
MAC keys come from a hash chain
Requires loose clock synchronization
Authentication delay must be set to > maximum clock skew
No buffering of data at sender; buffering for a fixed period at
the receiver
Tolerates packet loss
Scales to any number of receivers
No non-repudiation
21
TESLA (2)
k0
h
MAC keys:
k1
h
k2
h
k3
h’
h’
h’
k’1
k’2
k’3
h
???
???
h
kt-1
h
kt = random
h’
h’
k’t-1
k’t
Initialization:
Sender commits to the key chain and release schedule by signing:
k0, start time T1, interval duration Tint, disclosure delay d∙Tint
Time periods start at T1, others Ti+1=Ti+Tint
MAC keys k’1, k’2, k’3,…
Used for message authentication in periods starting from T1, T2, T3…
ki revealed d periods later (revealing ki reveals all kj, j≤i)
Sender and receiver must have loosely synchronized clocks
22
TESLA (3)
k0
h
MAC keys:
T1
k1
h
k2
k3
h
k4
h
h’
h’
h’
h’
k’1
k’2
k’3
k’4
T2
T3
h
???
h
???
T4
TN-1
kN-1
h
kN = random
h’
h’
k’N-1
k’N
TN
???
Packets:
???
Setup: Sign(k0,Y1,Tint,d=2,N)
Contain k1
Contain k2
Contain kN-3 Contain kN-2 Contain kN-1 Contain kN
Packets received in period i will be authenticated in period i+d
If a packet that belongs to the period [Ti ,Ti+1] is received after Ti+1,
it cannot be authenticated
Ok to have silent periods but dummy packets may be needed to
avoid long authentication delays
Next key chain can be initialized by sending the new k0 in the last
packets of the previous chain (cf. Guy Fawkes)
23
DoS protection
Access control for senders
Multicast is a mechanism for traffic amplification → can
be used for DoS attacks to consume bandwidth
One-root solution: the root node of the multicast tree
authenticates senders and checks for authorization
Ok for satellite broadcast
No such root in IP multicast in the Internet, in many-to-many
communication, or in peer-to-peer content distribution
Authentication of data at each router needed to avoid insertion
of false data → maybe too expensive
Reverse path forwarding: each router checks the routing
table for the source address and decides whether the
packet came from the right direction
Prevents some spoofing attacks
Needed to prevent routing loops anyway
Non-crypto access control for receivers
A multicast receiver could subscribe to a large
number of multicast streams
Packet flood to the location of the receiver
Either free, unencrypted streams or streams of encrypted
packets it cannot decrypt
Need some way of limiting subscriptions at the
receiver end
26
Exercises
Combine backward and forward chaining to divide
the buffering requirement between sender and
receiver
How could a criminal organization use cryptography
to make a series of anonymous but plausible
threats? (Hint: Guy Fawkes was a 17th century
terrorist)
If the receiver has no capability for public-key
operations, how would you initialize TESLA?
27
Mobile IPv6
Mobile IPv6
Network-layer mobility protocol
Developed since 1991; now standardized by the
Internet Engineering Task Force (IETF)
Mobile IP(v4) [RFC 3344], IPv6 [RFC 3775]
History:
Mobile IPv6 standardization halted in 2000 because of
security concerns
Security protocol proposed by us in 2001 became a
part of the standard. Major security problems fixed
Next, we'll go through the threat analysis and
security protocol design step by step
29
Mobile IPv6 and addresses
The mobile node (MN) has two IPv6 addresses
Home address (HoA):
Subnet prefix of the home network
Used as address when MN is at home. Used as node
identifier when MN is roaming in a foreign network
Home network may be virtual – MN never at home.
Care-of address (CoA):
MN’s current point of attachment to the Internet
Subnet prefix of the foreign network
Correspondent node (CN) can be any Internet host
(Note: MN and CN are hosts, not routers.)
30
Mobility
Home Network
Correspondent
node (CN)
Home
address
(HoA)
Mobile node (MN)
Foreign Network
Care-of address (CoA)
How to communicate after MN leaves its home
network and is roaming in a foreign network?
(HoA, CN and CoA are IPv6 addresses)
31
Mobile IPv6 goals
Mobility goals:
MN is always reachable at HoA as long as it is connected
to the Internet at some CoA
Connections don’t break when CoA changes
Performance goals (different levels):
Roaming (transparent access to VPN, email and web while
away from home) has low QoS requirements
Mobile multimedia (real-time voice and sound while
constantly moving) requires delays < 200 ms
Security goals:
As secure as the current Internet without mobility
32
Mobile IPv6 tunnelling
Home Network
Home agent HA
at HoA
source = HA
Encapsulated destination = CoA
packet source = CN
destination = HoA
source = CN
destination = HoA
CN
MN at CoA
Home agent (HA) is a router at the home network that
forwards packets to and from the mobile
MN always reachable at HoA
33
Tunneled packets on the wire
IPsec ESP tunnel between HA and MN
HA uses its own IPv6 address as the tunnel endpoint
MN uses the CoA as the tunnel endpoint → both SPD and SAD
must be updated at HA when the mobile moves
Packet from CN to HoA:
IP[CN,HoA] | Payload (intercepted by HA)
Forward tunnel from HA to CoA:
IP[HA,CoA] | ESP | IP[CN,HoA] | Payload
Reverse tunnel from MN to HA:
IP[CoA,HA] | ESP | IP[HoA,CN] | Payload
Packet forwarded from HA to CN:
IP[HoA,CN] | Payload
Note: no problems with ingress filtering because all
source addresses are topologically correct
34
Route optimization (RO)
HA
at HoA
1. First packet
CN
3. Following
packets
2. Binding Update (BU)
source = CoA
destination = CN
This is HoA
I'm at CoA
MN
at CoA
source = CN
destination = CoA
For HoA
source = CoA
destination = CN
From HoA
Routing
header
(RH)
Home address
option (HAO)
35
Route-optimized packets on the wire
Packet from CN to MN:
IP[CN,CoA] | RH[HoA] | Payload
(RH = Routing header Type 1, “for HoA”)
Packet from MN to CN:
IP[CoA,CN] | HAO[HoA] | Payload
(HAO = Home address option, “from HoA”)
Again, all source addresses are topologically correct
36
Route optimization
Important optimization:
Normally, only the first packet sent via home agent (HA).
Binding udpate (BU) triggered when MN receives a
tunneled packet. All following packets optimized
But, if CN does not support BU or decides to ignore them,
then all packets are tunneled via HA
MN may send the BU at any time
In principle, IP layer is stateless and does not know
whether there was previous communication
37
Binding update
Originally, a 2-message protocol:
Binding update (BU) from CoA to CN
Binding acknowledgement (BA) from CN to MN
Now a much more complex protocol, for security
reasons that we'll soon explain
CN caches the HoA–CoA binding in its binding cache
for a few minutes
MN may send a new BU to refresh the cache or to update
its location
CN may send a binding request (BR) to MN to ask for a
cache refresh
38
Who are MN, CN?
Any IPv6 host may be the correspondent
Any IPv6 address can become mobile, even though
most never do
By looking at the address, CN cannot know whether
home address (HoA) belongs to a mobile node
→ Security flaws in Mobile IPv6 may be used to attack
any Internet node
39
Threats and protection
mechanisms
All weaknesses shown here have been addresses in the RFC
40
Attack 1: false binding updates
A
B
False BU
source = C
destination = B
This is A
I'm at C
Attacker
C
A, B and C can be any IPv6 nodes (i.e. addresses) on the
Internet
41
Connection hijacking
A
B
False BU
source = C
destination = B
This is A
I'm at C
source = C
destination = B
From A
Attacker
C
Attacker could highjack old connections or open new
A, B and C can be any Internet nodes
42
Man-in-the-middle attack
A
B
False BU
This is B
I'm at C
Attacker
False BU
This is A
I'm at C
C
43
If no security measures added
Attacker anywhere on the Internet can hijack
connection between any two Internet nodes, or
spoof such a connection
Attacker must know the IPv6 addresses of the target
nodes, though
44
BU authentication
MN and HA trust each other and can have a secure
tunnel between them. Authenticating BUs to CN is
the problem
The obvious solution is strong cryptographic
authentication of BUs
Problem: there is no global system for
authenticating any Internet node
45
Authentication without infrastructure?
How authenticate messages between any two IPv6
nodes, without introducing new security infrastructure?
Set requirements to the right level: Internet with Mobile
IPv6 deployed must be as secure as before it → no
general-purpose strong authentication needed
Some IP-layer infrastructure is available:
IPv6 addresses
Routing infrastructure
Surprisingly, both can be used for BU authentication:
Cryptographically generated addresses (CGA)
Routing-based “weak” authentication, called return routability
46
BU Authentication – v.1
HA
at HoA
2. K
CN
accept BU
1. BU
3. BU, MACK(BU)
MN
at CoA
CN sends a key in plaintext to HoA
47
Is that good enough?
“Weak”, routing-based authentication, but it meets the
stated requirement
Attacker has to be on the path between CN and HA to
break the authentication and hijack connections
This is true even if the MN never leaves home, so mobility does
not make the Internet less secure
Not possible for any Internet node to hijack any connection →
significantly reduced risk
K is not a general-purpose session key! Only for
authenticating BUs from MN to CN
Anything else?
The weak authentication, CAM, and other protocols discourage
lying about who you are
Still possible to lie about where you are!
48
Attack 2: bombing attack
Attacker
A
Video stream
bbc.co.uk
B
source = C
destination = B
False BU This is A
I'm at C
Unwanted
video stream
Target
C
Attacker can flood the target by redirecting data streams
49
Bombing attack - ACKs
Attacker
A
A
bbc.com
False BU
B
source = C
destination = B
False This is A
acknowledgments ACK
Unwanted
video stream
Target
C
Attacker participated in the transport-layer handshake → can
spoof TCP ACKs or similar acknowledgements
Attacker only needs to spoof one ACK per sender window to keep
the stream going
Target will not even send a TCP Reset!
50
BU Authentication – v.2
HA
at HoA
2a. K0
CN
accept BU
1. BU
2b. K1
3. BU, MACK(BU)
K=h(K0,K1)
MN
at CoA
CN sends a message to CoA to ask whether someone there wants the
packets
Common misconception: the purpose is not to send K0 and K1 along two
independent paths!
51
Is that good enough?
Not possible to lie about identity or location;
all information in BUs is true
Almost ready, but we still need to consider standard
denial of service attacks against the BU protocol
52
Attack 3: Exhausting state storage
lost
2a. K0
B
1. BU
source = D
destination = B
This is E
I'm at D
2b. K1
lost
Attacker
C
Correspondent will generate and store K0, K1
Attacker can flood CN with false BUs →
CN has to remember thousands of K0s and K1s
53
BU authentication – v.3
N
HA
at HoA
2a. K0 = h (N, HoA)
periodically
changing
random
value
CN
accept BU
1. BU
2b. K1 = h (N, CoA)
3. BU, MACK(BU)
K=h(K0,K1)
MN
at CoA
We can make the correspondent stateless
54
Attack 4: reflection and amplification
HA
at HoA
2a. K0
B
2b. K1
MN
at CoA
1.
DDoS
Attacker
Two DDoS packets become one — minor issue
IP trace-back cannot find the attacker
55
BU Authentication – v.4
HA
at HoA
2a. K0
CN
1a. BU
1b. BU
accept BU
2b. K1
3. BU, MACK(BU)
K=h(K0,K1)
MN
at CoA
Balanced message flows prevent amplification
56
The Mobile IPv6 Standard Protocol
HA
at HoA
2a. HoT
CN
1a. HoTI
1b. CoTI
2b. CoT
3. BU
4. BA
MN
at CoA
Return routability (RR) test for HoA and CoA
Similar mechanisms, completely different purpose
57
Exercises
Based on the historical flaws in Mobile IPv6, are there any
potential security problems in dynamic DNS? Does Secure
DNS solve these problems?
Design a more efficient binding-update protocol for Mobile
IPv6 assuming a global PKI is available
How could the return-routability test for the care-of address
(CoA RR) be optimized if the mobile is opening a TCP
connection? What are the advantages and disadvantages?
Find out about credit-based authorization for Mobile IPv6.
How does it reduce latency? Is it secure?
What problems arise if mobile node can automatically pick a
home agent in any network
58