Network Security: Broadcast and Multicast, Mobile IPv6

1. Network Security: Broadcast and Multicast, Mobile IPv6 Tuomas Aura

2. Outline Broadcast and multicast • Receiver access control (i.e. data confidentiality) • Multicast authentication • DoS protection Mobile IPv6 • Spoofed bindings, bombing attack • Return routability test

3. Broadcast and multicast

4. 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

5. IP unicast

6. Satellite broadcast

7. IP multicast protocols

8. 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

9. Future of multicast and broadcast? • Multicast tree vs. P2P overlay multicast protocols • Youtube and unicast

10. 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?)

11. Receiver access control

12. 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

13. 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

14. Multicast and broadcast authentication

15. 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

16. 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 • Backward chaining • Received can authenticate and consume data immediately • Sender must buffer data before sending and signing

17. 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

18. Guy Fawkes protocol (1) • Delayed authentication [Ross Anderson 1997] • Initially, receiver knows Y = hash(X) • To authenticate message M: • Sender publishes Z= MACX(M) • 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

19. 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,…: • Sender selects a random Xi and computes Yi = hash(Xi) • Sender publishes in a newspaper Zi= MACXi-1 (Mi, Yi) • 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

20. 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

21. 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

22. TESLA (2) • 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

23. TESLA (3) • 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)

24. DoS protection

25. 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

26. 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

27. 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?

28. Mobile IPv6

29. 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 Mobile IPv6

30. 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.)

31. Mobility Correspondent node (CN) • How to communicate after MN leaves its home network and is roaming in a foreign network? (HoA, CN and CoA are IPv6 addresses) Home Network Home address(HoA) Mobile node (MN) Foreign Network Care-of address (CoA)

32. 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

33. Mobile IPv6 tunnelling Home Network CN • Home agent (HA) is a router at the home network that forwards packets to and from the mobile • MN always reachable at HoA source = CNdestination = HoA Home agent HA at HoA source = HAdestination = CoA tunnel Encapsulatedpacket source = CNdestination = HoA MN at CoA

34. 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

35. Route optimization (RO) CN 1. First packet HA at HoA 3. Followingpackets 2. Binding Update (BU) source = CoAdestination = CNThis is HoAI'm at CoA source = CNdestination = CoAFor HoA tunnel Routing header (RH) source = CoAdestination = CNFrom HoA MN at CoA Home addressoption (HAO)

36. 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

37. 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

38. 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–CoAbinding 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

39. 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

40. Threats and protectionmechanisms All weaknesses shown here have been addresses in the RFC

41. Attack 1: false binding updates • A, B and C can be anyIPv6 nodes (i.e. addresses) on the Internet A B False BU source = Cdestination = BThis is AI'm at C Stolen data C Attacker

42. Attacker could highjack old connections or open new A, B and C can be any Internet nodes Connection hijacking A B False BU source = Cdestination = BThis is AI'm at C Stolen data source = C destination = BFrom A Spoofed data Attacker C

43. Man-in-the-middle attack A B False BU False BU This is BI'm at C This is AI'm at C Attacker C

44. 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

45. 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

46. 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

47. BU Authentication – v.1 • CN sends a key in plaintext to HoA 2. K HAat HoA CN accept BU 1. BU securetunnel 3. BU, MACK(BU) MNat CoA

48. 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!

49. Attack 2: bombing attack • Attacker can flood the target by redirecting data streams bbc.co.uk Attacker Video stream B A source = Cdestination = BThis is AI'm at C False BU Unwanted video stream Target C

50. Bombing attack - ACKs Attacker bbc.com False BU • 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! A A B source = Cdestination = BThis is AACK Falseacknowledgments Unwanted video stream Target C