Presentation is loading. Please wait.

Presentation is loading. Please wait.

Network Security: Security of Internet Mobility Tuomas Aura T-110.5241 Network security Aalto University, Nov-Dec 2014.

Similar presentations


Presentation on theme: "Network Security: Security of Internet Mobility Tuomas Aura T-110.5241 Network security Aalto University, Nov-Dec 2014."— Presentation transcript:

1 Network Security: Security of Internet Mobility Tuomas Aura T Network security Aalto University, Nov-Dec 2014

2 2 Outline Mobile IPv6 Return routability test Address and identifier ownership Cryptographically generated IPv6 addresses

3 Mobile IPv6

4 4 Network-layer mobility protocol Developed since 1991; now standardized by the Internet Engineering Task Force (IETF) Mobile IP(v4) [RFC 5944], Mobile IPv6 [RFC 6275] 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 Mobile IPv6 never became the dominant mobility mechanism for the Internet, but the security lessons apply to many other protocols and applications! Next, we'll go through the threat analysis and security protocol design step by step

5 5 Why is Mobile IP(v6) not used? Mobility in the IP layer was supposed to be a generic solution to all mobility, but it is not widely used IPv6 deployment slowed than expected Too narrow view of what is mobility: Changing IP address (handover between WLAN APs, DHCP allocating a different address) – only this is solved by Mobile IP(v6) Shared IP address (hosts behind a NAT) Multihoming (wired+wireless+cellular interfaces, and thus several IP addresses coming and going) Failover (duplicated nodes, e.g. telecom signaling points) Delay tolerance (device sleeping, no signal) Stateless protocols have taken over HTTP, REST, TLS tolerate connection failure and changing IP address Applications are not designed to depend on long-living TCP connections !

6 6 Mobile IPv6 and addresses The mobile node (MN) has two IPv6 addresses Home address (HoA): Has subnet prefix of the home network Used as address (=location for routing packets) when MN is at home. Used as host identifier when MN is roaming in a foreign network Home network is typically virtual – MN never at home Care-of address (CoA): MN’s current point of attachment to the Internet Has subnet prefix of the foreign network Correspondent node (CN) can be any Internet host (Note: MN and CN are hosts, not routers.) Note the dual role of IP addresses!

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

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

9 9 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, 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

10 10 Mobile IPv6 tunnelling Home agent (HA) is a router at the home network that forwards packets to and from the mobile MN always reachable at HoA source = HA destination = CoA CN MN at CoA tunnel source = CN destination = HoA Home agent HA at HoA Home Network Encapsulated packet source = CN destination = HoA

11 11 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

12 12 Route optimization (RO) HA at HoA MN at CoA source = CN destination = CoA For HoA Routing header (RH) source = CoA destination = CN This is HoA I'm at CoA 2. Binding Update (BU) 3. Following packets 1. First packet source = CoA destination = CN From HoA Home address option (HAO) CN tunnel This is the early RO protocol (very efficient!), before security analysis and security- protocol design

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

14 14 Route 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

15 15 Binding update Originally, a 2-message protocol: Binding update (BU) from CoA to CN Binding acknowledgement (BA) from CN to MN The final standard is a much more complex protocol, for security reasons which we'll 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

16 16 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

17 How the MIPv6 security protocol was developed: threats and protection mechanisms 17

18 18 Attack 1: false binding updates A, B and C can be any IPv6 nodes (i.e. addresses) on the Internet source = C destination = B This is A I'm at C False BU Stolen data Attacker AB C

19 19 Spoofed data Connection hijacking source = C destination = B This is A I'm at C False BU Stolen data Attacker source = C destination = B From A Attacker could highjack old connections or open new A, B and C can be any Internet nodes AB C

20 20 Man-in-the-middle attack False BU Attacker False BU This is B I'm at C This is A I'm at C AB C

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

22 22 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

23 23 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

24 24 BU Authentication – v.1 CN send a key in plaintext to HoA MN at CoA HA at HoA secure tunnel 2. K 1. BU 3. BU, MAC K (BU) accept BU CN

25 25 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 routing-based authentication, CGA, and other protocols discourage lying about who you are Still possible to lie about where you are!

26 26 Attack 2: bombing attack Attacker can flood the target by redirecting data streams source = C destination = B This is A I'm at C False BU Unwanted video stream Target bbc.co.uk Video stream Attacker A B C

27 27 Bombing attack - ACKs 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! False BU Unwanted video stream Target bbc.com Attacker source = C destination = B This is A ACK False acknowledgments A B C A

28 28 BU Authentication – v.2 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! MN at CoA HA at HoA secure tunnel 2a. K0 1. BU 3. BU, MAC K (BU) K=h(K0,K1) accept BU 2b. K1 CN

29 29 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

30 30 Attack 3: Exhausting state storage Correspondent will generate and store K0, K1 Attacker can flood CN with false BUs → CN has to remember thousands of K0s and K1s Attacker 2a. K0 1. BU 2b. K1 lost source = D destination = B This is E I'm at D C B

31 31 BU authentication – v.3 We can make the correspondent stateless secure tunnel 2a. K0 = h (N, HoA) 1. BU 3. BU, MAC K (BU) K=h(K0,K1) accept BU N periodically changing random secret MN at CoA HA at HoA CN 2b. K1 = h (N, CoA)

32 32 Attack 4: reflection and amplification Two DDoS packets become one — minor issue IP trace-back cannot find the attacker secure tunnel 2a. K0 1. 2b. K1 DDoS Attacker B MN at CoA HA at HoA

33 33 BU Authentication – v.4 Balanced message flows prevent amplification 2a. K0 1b. BU 3. BU, MAC K (BU) K=h(K0,K1) accept BU 2b. K1 secure tunnel 1a. BU MN at CoA HA at HoA CN

34 4. BA 34 The Mobile IPv6 Standard (RFC 6275) Return routability (RR) test for HoA and CoA 2a. HoT 1b. CoTI ESP tunnel 1a. HoTI MN at CoA HA at HoA CN 3. BU 2b. CoT

35 35 Attack 5: Unnecessary BUs Tunneled packets trigger BUs → spoofed packets to home address trigger true but unnecessary BUs → DoS Attack against MN or a correspondent Defense: limit the amount of resources used for BU authentication; revert to non-optimized routing ESP tunnel source = B destination = HoA Attacker Spoofed packet Unnecessary BU (authentication not shown) MN at CoA HA at HoA CN

36 Bombing attacks in general General problem with mobility, multihoming, failover etc. 36

37 37 Packet-bombing attack Junk & Stream Services Ltd Target Rd Evil St BobAlice Please send me stuff. – Alice Does authentication help?

38 Junk & Stream Services Ltd 38 Packet-bombing attack Target Rd Evil St BobAlice Please send me stuff at Target Rd. – Bob Authentication does not always help!

39 Junk & Stream Services Ltd 39 Ask Permission to Send (1) Target Rd Evil St BobAlice Please send me stuff at Target Rd. – Bob Do you want this? What’s that? I’m not answering

40 Junk & Stream Services Ltd 40 Packet-bombing with mobility Target Rd Evil St BobAlice Please send me stuff at Evil St. – Bob Do you want this? Yes! I have moved to Target Rd. – Bob Thank you! Send more. – Bob

41 41 Protocol layering issues Mobility is usually implemented in a lower protocol layer than data transport (e.g., IP vs. TCP). → Mobility is transparent to the data-sending layer → Sender does not know about changes of the peer address  Solutions typically lead to layer violations i.e. require network and transport layer to know about each other’s state

42 Address ownership and squating General problem with addresses and identifiers

43 43 Address squatting Welcome to LAN Town I need to find a free address to stay at 1 LAN Rd 2 LAN Rd 3 LAN Rd 4 LAN Rd

44 44 Address squatting Can I stay at 1 LAN Rd? Welcome to LAN Town 1 LAN Rd 2 LAN Rd 3 LAN Rd 4 LAN Rd Can I stay at 2 LAN Rd? Can I stay at 3 LAN Rd? Can I stay at 4 LAN Rd? Sorry, I’m already living at 1 LAN Rd Sorry, I’m already living at 2 LAN Rd Sorry, I’m already living at 3 LAN Rd Sorry, I’m already living at 4 LAN Rd

45 45 Address squatting Welcome to LAN Town There is no place for me here 1 LAN Rd 2 LAN Rd 3 LAN Rd 4 LAN Rd

46 46 Addresses and identifier allocation Methods for allocating IP addresses and other unique identifiers: Static allocation — IP addresses, MAC addresses Stateful configuration by a server — DHCP Autoconfiguration — IPv6 addresses Autoconfiguration requires least infrastructure and administration, is most scalable, and is suitable for ad-hoc and mobile-access networks Autoconfiguration is also most vulnerable to attacks like address squatting

47 IPv6 addresses 47

48 48 IPv6 address Nodes attached to the same gateway router have the same subnet prefix but different interface ids Subnet prefix is used for routing 62 bits of the interface id can be chosen in random (2 bits have a special meaning) F56C:74C4:9212:02BAFEDC:9773:D983: bit Subnet Prefix64-bit Interface Id

49 49 Stateless autoconfiguration FE80::Interface Id 64 bits ug=10 EUI-64 Company IdExtension Id MAC Address (EUI-48) 48 bits Company IdExtension Id 64 bits FFFE Link-local IPv6 Address Subnet PrefixInterface Id 64 bits ug=10 Global IPv6 Address 62 bits

50 50 Address privacy extensions (RFC 4941) The interface identifier is randomized to enhance user privacy: servers on the internet cannot recognize the client machine by its IPv6 address 62 pseudo-random bits Subnet PrefixInterface Id 64 bits ug=00 Global IPv6 Address

51 51 Configuring IPv6 addresses Host’s addresses [RFC 4291]: Zero or more global addresses: subnet prefix | interface identifier At least one link-local address for each interface: FE80::0 | interface identifier Router has one link-local address for each interface Stateless address autoconfiguration [RCF 4862]: Host creates a link-local address and performs duplicate address detection (DAD) Host performs router discovery to obtain router addresses and subnet prefixes; it chooses which one(s) to use Host creates a global address for each prefix and performs DAD (some implementations don’t) Neighbor discovery [RFC 4861] maps IP addresses to MAC addresses

52 52 Uniqueness of addresses EUI-64 addresses are supposed to be unique because MAC addresses are → Address collision is an unrecoverable error. Give up and report failure IPv6 address privacy extensions have random interface identifiers, which may sometimes collide → Try different random values and perform DAD. After a few collisions, give up and report error (How likely is a collision?) DHCPv6 can be used to assign addresses instead of stateless autoconfiguration In all cases, duplicate address detection is mandatory

53 53 Neighbor discovery Multicast neighbor solicitation (NS), unicast neighbor advertisement (NA) Also unsolicited multicast NA Soliciting node Solicited node Multicast NS to the link: "Who has the address 3ff0::5d28:1e51:b429:bc1f?" Unicast NA to the source: "00:30:65:19:67:28 has 3ff0::5d28:1e51:b429:bc1f."

54 54 Duplicate address detection (DAD) During address autoconfiguration, DAD is required for each unicast address to detect accidental address collisions and administrative errors New node No answer → address ok 2. Multicast a neighbor solicitation to the link: "Is anyone using 3ff0:: 5d28:1e51:b429:bc1f?" 1. Pick an address: 3ff0::5d28:1e51:b429:bc1f

55 55 DAD address squatting Attacker responds to every neighbor solicitation (NS) from the new node with a neighbor advertisement (NA) → New node cannot find a free address New Node Attacker Is anyone using 3ff0::5d28:1e51:b429:bc1f? I am

56 Cryptographically generated addresses (CGA)

57 57 Address ownership Needed: a mechanism for proving address ownership Potential uses: Preventing DAD address squatting Preventing spoofing of neighbor advertisements in neighbor discovery Authenticating Mobile IPv6 binding updates Authenticating ICMPv6 error messages Exchanging keys for opportunistic IPSec

58 58 Cryptographically generated address (CGA) The interface identifier contains the address owner's public signature key → can sign messages sent from the address CAM proposal for Mobile IPv6 [O’Shea & Roe 2000] Subnet PrefixInterface Id Hash = SHA-1 (Address Owner's Public Key) 64 bits 62 hash bits ug=00

59 59 Proof of address ownership Node sends the public key and a signed message from the CGA address Receiver Recomputes the hash of the public key Compares the hash with the with the interface id of the source address Verifies the signature using the public key → Receiver knows that the message was sent by the owner of the source address CGA-signing can prevent spoofing of IP-layer signaling messages such as neighbor advertisements

60 60 Countering dictionary attacks Attacker could create a database of all (or most) interface identifiers and corresponding public keys Solution: include the subnet prefix as “salt” in the hash input However, link-local addresses still vulnerable and every IPv6 node needs one

61 61 Hash extension The hash in CGA is at most 62 hash bits → vulnerable to brute-force attacks in the foreseeable future Moore’s law (one variation): CPU speed doubles every 18 months → one bit of hash strength lost → in about 30 years, CGA might be useless Already too weak for strong authentication but still ok for DoS protection Solution: Increase artificially the cost of a brute-force attack Cost of creating a CGA will increase by the same factor Allow CGA creator to decide how much extra strength is needed Cost of using CGA (signing and verifying) will stay constant

62 62 Standard CGA address format [RFC 3972] Subnet PrefixInterface Id Security Parameter (Sec) Hash1 = SHA-1 (Public Key, Modifier, Subnet Prefix, Collision Count) 64 bits ug=00 3 bits 59 hash bits Modifier must be chosen so that Hash2 begins with 16*Sec zero bits. Hash2 = SHA-1 (Public Key, Modifier, 0, 0) = 000…000xxx…xxx 2

63 63 Bidding down problem Cannot require all Internet nodes to have CGA addresses. Which addresses are CGA and which are not? Cannot trust the address owner to tell. Attacker can claim that it is not using CGA even when it is Solutions: Our proposal, not accepted in IETF: use an unused combination of “g” and “u” bits (g=1 and u=1) in the interface id as a type tag for CGAs Current solution: Prioritize CGAs. CGA-signed data will overwrite unsigned data (e.g. in the neighbor cache) but not the other way

64 64 CGA limitations DNS names must be mapped to IP addresses → CGA-based authentication prevents spoofing of source IP addresses; it does not prevent DNS spoofing Authenticates the interface identifiers only, not the subnet prefix (=location in the network topology) CGA-based authentication prevents spoofing of someone else’s IP address. An attacker can generate a new address with any subnet prefix. CGA does not prove that the node or address exists Attacks against link layer may be just as bad

65 65 CGA advantages Authentication of an IP address without a PKI or other security infrastructure With Secure DNS, gives strong host authentication Without Secure DNS, prevents many DoS attacks Particularly suitable for authenticating IP-layer signaling

66 Secure neighbor discovery 66

67 SEND Secure neighbor discovery (SEND) [RFC 3971] CGA-based signatures on neighbor advertisements Prevents NA spoofing Prevents address squatting in DAD Zero-configuration security! Certificate-based authorization of routers Certificate authorizes router for a an address prefix Extension to X.509 to certify IPv6 address allocation [RFC 3779] Requires hosts to know the root key; currently no global CA hierarchy Freshness: Timestamp in unsolicited advertisement and redirect Nonce in NS and RS, copied to NA and RA

68 Remaining threats

69 69 Remaining threats MAC address ownership? Lower-layer attacks ND/RD tunneling attack DoS against the PK protocols

70 70 Lower-layer attacks Link layer: Local network can be flooded for DoS MAC address spoofing Attacker can teach learning Ethernet switches to redirect any node’s packets to itself by broadcasting a frame with a spoofed MAC address Physical layer: Radio jamming Jamming trailer of selected packets Link-layer security is getting increasing attention → we are forcing the attacker down the stack

71 71 ND/RD tunneling (wormhole) attack A mobile node does not know which link it is (or should be) on! Attacker can tunnel ND and RD packets between two local networks → Node will believe it is on a the remote links Cryptographic authentication and authorization does not help Tunneling can be done by physical copying of electric or radio signals Distance bounding based on speed-of-light distance measurement Implementation must be at hardware layer

72 72 Local link security — why bother? Large networks, public access networks and shared access points always have untrusted nodes on local link The DoS attacker (e.g. worm) will be on the local link; we must limit damage Force attackers to down the stack to radio jamming and indiscriminate jamming instead of targeted attacks Protect against accidental misconfiguration Wireless networks are mission-critical

73 73 Exercises Based on the historical flaws in Mobile IPv6, are there any potential security problems in dynamic DNS? Does Secure DNS solve these problems? Could a SIP INVITE specify a false destination for a data stream? How could this be prevented? 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? What problems arise if the mobile node can automatically pick a home agent in any network that has one?

74 74 Exercises Why cannot CGA-based authentication prevent all IP source- address spoofing? Can CGA-based authentication prevent IP source-address spoofing in DDoS attacks? Why? What would be the advantages and limitations of using CGA- based authentication with IPSec? Design cryptographically generated MAC addresses for Ethernet. How would they be used? How to use CGA-based authentication with IPSec? What are the benefits and limitations?


Download ppt "Network Security: Security of Internet Mobility Tuomas Aura T-110.5241 Network security Aalto University, Nov-Dec 2014."

Similar presentations


Ads by Google