Network Mobility

1. Network Mobility Yanos Saravanos Avanthi Koneru

2. Agenda • Problem Definition • Background • PANA • MOBIKE • Conclusion • References Yanos Avanthi

4. Why Mobility Matters • Cell phones / PDAs • 692 million cell phones shipped in 2004 • 1.7 billion subscribers by end of 2005 • Streaming multimedia • Live TV • 4G cellular networks being developed • Uses ALL-IP network architecture • Highly scalable • Critical in emergency conditions

5. 4G Network http://www.eeng.dcu.ie/~arul/4G.html

6. Problem Definition • No current security protocols is built around mobility • New protocols must: • Keep session during handoffs • Allow integration between mobile networks (802.11, cellular, etc) • Not dramatically increase packet size

7. Benchmarks • Computational intensity • Effect on throughput • Amount of overhead added to the packets • QoS • Packet Loss, Delay • Jitter

8. PANA Protocol for carrying Authentication for Network Access

9. PANA Goals • Network access authentication protocol • Client-server • Enables EAP to be transported over IP layer • Authentication is a function of the network layer • Link-layer independence

10. Terminology • PANA Client (PaC) • Laptop, PDA, cell phone • Authentication, Authorization and Accounting Client (AAA) • PANA Authentication Agent (PAA) • Server for authenticating and authorizing PaCs • Checks AAA to verify PaC’s rights • Enforcement Point (EP) • Access controller to allow/deny client access

11. PANA Protocol

12. PANA Phases

13. PANA Discovery Process • Discovery and handshake phase • PAC discovers PAA in network • Handshake between PaC and PAA to begin PANA session

14. PANA Authentication Process • Authentication and authorization phase • PaC and PAA establish PANA connection • PaC/PAA derive AAA key for each EP the PAA manages • PAA sends shared key to the EPs • EPs configure filters so PaC can connect

15. PANA Process • Access phase • Traffic between PaC and EP is encrypted using shared key • Ping occasionally to test PANA session • Re-authentication phase • Before session expires, re-authenticate

16. PANA Termination Process • Termination phase • PAA notifies EPs that PaC not available • EPs remove filter

17. PANA Issues • PaC must be able to communicate with network before being authenticated • AP must forward some traffic (ARP, DHCP, and PANA) from unauthenticated clients • Use uncontrolled ports in 802.1X before authentication • Use controlled ports in 802.1X after authentication • PANA does not address network selection by itself

18. PANA Issues • PAAs must communicate with each other • Client roaming between PAAs • PANA not currently built to transfer sessions • Separation of EP and PAA • Requires communication between both • Not currently in PANA specification

19. Proposed Network Architecture

20. Proposed NetworkArchitecture • Wireless Clients • Guest Network (GN) • For unauthenticated clients • Uses unencrypted traffic • Isolated from all other networks • User Networks (UN) • For authenticated clients • Uses encrypted traffic • Multiple user networks for separating services

21. Proposed NetworkArchitecture • Management Network (MN) • Manages access point for managing entities • Isolated from all other networks • AAA server usually located in MN • Access Point • Connects clients to either GN or UN • Logical traffic separation between networks • Binds client’s MAC address to GN or UN • Cryptographic protection of UN traffic

22. Proposed NetworkArchitecture • PAA • Resides in GN to authenticate new guests • Connected to UNs to switch clients from GN to UN • Connected to MN to securely communicate keys and network identifiers for authenticated guests to the AAA

23. Access Point Implementation • Wireless Module • Sends/receives 802.11 frames • Encrypts/decrypts frames using control module • Wired Module • eth0.3 connected to MN • eth0.0 connected to GN • Bridge • Forwards frames between wireless and wired interfaces • Authentication Module • Processes messages from wlan0.0 and eth0.3

24. Access Point Database • Database used to maintain association state for each wireless client • MAC address • Network ID • Key ID • Encryption key

25. AP Database Operation • Receiving • If MAC address is not entered, discard frame • If MAC exists but key does not, forward frame to GN • If MAC and key exist, forward frame to UN • Sending • If MAC address is not entered, discard frame • If MAC and key exist, encrypt frame with key and key ID and send on wireless interface (from is from UN) • If MAC exists but key does not, send frame on wireless interface without encryption (frame is from GN)

26. PANA Authentication Sequence

27. PANA Performance • Total delay: 12.01 sec • PANA protocol delay • Beginning of PANA to beginning of disassociation • Re-association delay • Beginning of disassociation to end of 4-way handshake • Post-PANA DHCP delay • End of 4-way handshake to end of DHCP

28. PANA Performance • Last two delays can be reduced • If wireless client initiates association immediately after disassociation, 2nd delay is reduced to 0.48 sec • 3rd delay is reduced by initiating DHCP procedure immediately after re-association • Normal DHCP procedure takes 0.34 sec • Total delay reducible to ~2.7 sec

29. Additional Work for PANA Network • Test network scalability and roaming • Wireless client implementation must be tuned to improve system performance • Even more critical when client is roaming • Use of system for wired client authentication • Useful for home access routers

30. Conclusion • New architecture that uses PANA for authentication of wireless clients • Provides network separation between AAA clients and AP • New AP architecture • Delays can be greatly reduced

31. mobike IKEv2 Mobility and Multihoming

32. MOBIKE • IKEv2 • The purpose of IKEv2 is to mutually authenticate two hosts, establish one or more IPsec Security Associations (SAs) between them, and subsequently manage these SAs. • Problem: • There are scenarios where one or both of the IP addresses of this pair may change during an IPsec session. In principle, the IKE SA and all corresponding IPsec SAs could be re-established after the IP address has changed. • Solution • Mobike provides an automatic mechanism which updates the IP addresses associated with the IKE SA and the IPsec SAs.

33. Mobility Scenario

34. Multihoming Scenario

35. Focus of current design • Mobike focuses on the tunnel mode, everything going inside the tunnel has to stay unaffected by the changes in the tunnel header IP address i.e., the applications running through the MOBIKE IPsec tunnel cannot even detect the movement, their IP address etc stay constant. • The MOBIKE focuses on what two peers need to agree in IKEv2 level (like new message formats and some aspects of their processing) for interoperability.

36. Operations of mobike • Inform the other peer about the peer address set • Inform the other peer about the preferred address • Test connectivity along a path and thereby to detect an outage situation • Change the preferred address • Change the peer address set • Ability to deal with Network Address Translation devices

37. Proposed mobike framework

38. Design Considerations • Choosing addresses • Inputs and triggers • Connectivity • Discovering connectivity • Decision making • NAT traversal • Constraints • Fundamental restrictions • Moving to behind NAT and back • Responder behind NAT • NAT prevention

39. Design Considerations (..contd) • Scope of SA changes • MOBIKE protocol decided to move all IPsec SAs implicitly when the IKE SA address pair changes. If more granular handling of the IPsec SA is required, then multiple IKE SAs can be created one for each set of IPsec SAs needed. • Zero Address set functionality • There is no need to transmit IPsec data traffic. IPsec protected data can be dropped which saves bandwidth. This does not provide a functional benefit, i.e., nothing breaks if this feature is not provided. • MOBIKE signaling messages are also ignored. The IKE-SA must not be deleted and the suspend functionality (realized with the zero address set) may require the IKE-SA to be tagged with a lifetime value since the IKE-SA should not be kept in alive for an undefined period of time.

40. Design Considerations (..contd) • Return routability test • The addresses a peer is using are part of a certificate. [RFC3554] introduced this approach. If the other peer is, for example, a security gateway with a limited set of fixed IP addresses, then the security gateway may have a certificate with all the IP addresses appear in the certificate. • A return routability check is performed by the remote peer before the address is updated in that peer's Security Association Database. This is done in order provide a certain degree of confidence to the remote peer that local peer is reachable at the indicated address. • IPsec Tunnel or Transport Mode

41. Protocol Overview Mobike Message Exchanges

43. Protocol detail issues • Indicating support for mobike • In order for MOBIKE to function, both peers must implement the MOBIKE extension of IKEv2. If one or none of the peers supports MOBIKE, then, whenever an IP address changes, IKEv2 will have to be re-run in order to create a new IKE SA and the respective IPsec SAs. In MOBIKE, a peer needs to be confident that its address change messages are understood by the other peer. If these messages are not understood, it is possible that connectivity between the peers is lost.

44. Protocol detail issues • Approaches used to recognize peers which support mobike: • Ensuring that a peer receives feedback on whether or not its messages are understood by the other peer, is by using IKEv2 messaging for MOBIKE and to mark some messages as "critical". According to the IKEv2 specification, such messages either have to be understood by the receiver, or an error message has to be returned to the sender. • Ensure receipt of the above-mentioned feedback is by using Vendor ID payloads that are exchanged during the initial IKEv2 exchange. These payloads would then indicate whether or not a given peer supports the MOBIKE protocol. • Use the Notify payload which is also used for NAT detection (via NAT_DETECTION_SOURCE_IP and NAT_DETECTION_DESTINATION_IP payloads)

45. Protocol detail issues • Path Testing and Window size • Complications: • As the IKEv2 has the window of outgoing messages, and the sender is not allowed to violate that window (meaning, that if the window is full, then he cannot send packets), it do cause some complications to the path testing. • once the message is first time sent to the other end, it cannot be modified in its future retransmissions. This makes it impossible to know what packet actually reached first to the other end. • The current IKEv2 document says that if NAT-T is enabled the node not behind NAT SHOULD detect if the IP-address changes in the incoming authenticated packets, and update the remote peers addresses accordingly. This works fine with the NAT-T, but it causes some complications in the MOBIKE, as it needs an ability to probe the another address pairs, without breaking the old one.

46. Protocol detail issues • Path Testing and Window size – Solutions: • To add completely new protocol that is outside the IKE SA message id limitations (window code), outside identical retransmission requirements, and outside the dynamic address updating of the NAT-T. • To make the protocol so that it does not violate window restrictions and does not require changing the packet is sent, and change the dynamic address updating of NAT-T to MUST NOT in case MOBIKE is used.

47. Message presentation • The IP address change notifications can be sent either via an informational exchange already specified in the IKEv2, or via a MOBIKE specific message exchange. • The format of the address update notifications. The address update notifications can include multiple addresses, of which some may be IPv4 and some IPv6 addresses. • MOBIKE decided to use IKEv2 NOTIFY payloads, and put only one data item per notify, i.e. there will be one NOTIFY payload for each item to be sent.

48. Updating address list • Because of the initiator decides, the initiator needs to know all the addresses used by the responder. The responder needs also that list in case it happens move to the address unknown by the initiator, and needs to send address update notify to the initiator, and it might need to try different addresses for the initiator. • MOBIKE could send the full peer address list every time any of the IP addresses changes (either addresses are added, removed, the order changes or the preferred address is updated) or an incremental update. • MOBIKE decided to use protocol format, where both ends can send full list of their addresses to the other end, and that list overwrites the previous list. To support NAT-T the IP-addresses of the received packet is added to the list (and they are not present in the list).

49. Security Considerations • The main goals of MOBIKE are to maintain the security offered by usual IKEv2 procedures and to counter mobility-related threats in an appropriate manner. • Traffic Redirection and Hijacking • MOBIKE payloads relating to updating addresses are encrypted, integrity protected, and replay protected using the IKE_SA. This assures that no one except the participants can, for instance, give a control message to change the addresses. • IPsec Payload Protection • The use of IPsec protection on payload traffic protects the participants against disclosure of the contents of the traffic, should the traffic end up in an incorrect destination or be eavesdropped along the way.

50. Security Considerations • Denial-of-Service Attacks Against Third Parties • Traffic redirection may be performed not just to gain access to the traffic (not very interesting because it is encrypted) or to deny service to the peers, but also to cause a denial-of-service attack for a third party. • Spoofing Network Connectivity Indications • Attackers may spoof various indications from lower layers and the network in an effort to confuse the peers about which addresses are or are not working. • Address and Topology Disclosure • MOBIKE address updates & ADDITIONAL_IP4/6_ADDRESS notifications reveal information about which networks the peers are connected to.