1 / 58

Network Security: Broadcast and Multicast, Mobile IPv6

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.

duff
Download Presentation

Network Security: Broadcast and Multicast, Mobile IPv6

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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

More Related