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

Transcription

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

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

3 Mobile IPv6

4 Mobile IPv6 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 4

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 5

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! 6

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

8 Mobility Home Network Home address (HoA)??? Correspondent node (CN) 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) 8

9 Mobility goals: Mobile IPv6 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 9

10 Mobile IPv6 tunnelling Home Network Home agent HA at HoA source = CN destination = HoA CN Encapsulated packet source = HA destination = CoA source = CN destination = HoA 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 10

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 11

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

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 13

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 14

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 15

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 16

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

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

19 Connection hijacking A False BU source = C destination = B This is A I'm at C B 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 19

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

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 21

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 22

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 23

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

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

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

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

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

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 29

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

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

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

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

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

35 Attack 5: Unnecessary BUs HA at HoA Spoofed packet source = B destination = HoA Attacker CN Unnecessary BU (authentication not shown) MN at CoA 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 35

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

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

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

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

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

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 41

42 Address ownership and squating General problem with addresses and identifiers

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

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

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

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 46

47 IPv6 addresses 47

48 IPv6 address 64-bit Subnet Prefix FEDC:9773:D983: bit Interface Id F56C:74C4:9212:02BA 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) 48

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

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

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 51

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 52

53 Neighbor discovery Soliciting 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." Solicited node Multicast neighbor solicitation (NS), unicast neighbor advertisement (NA) Also unsolicited multicast NA 53

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 1. Pick an address: 3ff0::5d28:1e51:b429:bc1f 2. Multicast a neighbor solicitation to the link: "Is anyone using 3ff0:: 5d28:1e51:b429:bc1f?" No answer address ok 54

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

56 Cryptographically generated addresses (CGA)

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 57

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] Hash = SHA-1 (Address Owner's Public Key) 64 bits Subnet Prefix ug=00 62 hash bits Interface Id 58

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 59

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 60

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 61

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

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 63

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 64

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 65

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 Remaining threats MAC address ownership? Lower-layer attacks ND/RD tunneling attack DoS against the PK protocols 69

70 Link layer: Lower-layer attacks 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 70

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 71

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 72

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? 73

74 Exercises Why cannot CGA-based authentication prevent all IP sourceaddress spoofing? Can CGA-based authentication prevent IP source-address spoofing in DDoS attacks? Why? What would be the advantages and limitations of using CGAbased 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? 74