1. Yanos Saravanos Avanthi Koneru
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

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 QoS
Amount of overhead added to the packets
QoS
Packet Loss, Delay
Jitter

8. Protocol for carrying Authentication for Network Access
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 Re-authentication 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 Network Architecture
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 Network Architecture
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 Network Architecture
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 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 Sending
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 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. IKEv2 Mobility and Multihoming
mobike
IKEv2 Mobility and Multihoming

32. MOBIKE IKEv2 Problem: Solution
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.

51. Conclusions
MOBIKE also supports more complex scenarios where the VPN gateway also has several network interfaces: these interfaces could be connected to different networks or ISPs, they may be a mix of IPv4 and IPv6 addresses, and the addresses may change over time. Furthermore, both parties could be VPN gateways relaying traffic for other parties.
The base version of the MOBIKE protocol does not cover all potential future use scenarios, such as transport mode, application to securing SCTP, or optimizations desirable in specific circumstances.

52. References
Tanizawa et al, “A Wireless LAN Architecture Using PANA for Secure Network Selection”, IEEE 2005.
Pagliusi et al, “PANA-GSM Authentication for Internet Access”, IEEE 2003.
D.Johnson, C. Perkins and J.Arkko, “Mobility Support in IPv6”, RFC URL:
Arkko et al, “Using IPsec to Protect Mobile IPv6 Signaling Between Mobile Nodes and Home Agents”, RFC URL:
IKEv2 Mobility and Multihoming (mobike), IETF Working Groups. URL:

53. References
Jari Arkko, “Introduction to multihoming, address selection, failure detection, and recovery”, IETF Proceedings. URL:
“Design of the MOBIKE protocol”, Internet Draft, draft-ietf-mobike-design-00.txt , June URL:
Internet Key Exchange (IKEv2) Protocol, Internet Draft, draft-ietf-ipsec-ikev2-17.txt, September URL:
IKEv2 Mobility and Multihoming Protocol (MOBIKE), Internet Draft, draft-ietf-mobike-protocol-02.txt, September URL:

54. References
Tanizawa et al, “A Wireless LAN Architecture Using PANA for Secure Network Selection”, IEEE 2005.
Pagliusi et al, “PANA-GSM Authentication for Internet Access”, IEEE 2003.
D.Johnson, C. Perkins and J.Arkko, “Mobility Support in IPv6”, RFC URL:
Arkko et al, “Using IPsec to Protect Mobile IPv6 Signaling Between Mobile Nodes and Home Agents”, RFC URL:
IKEv2 Mobility and Multihoming (mobike), IETF Working Groups. URL:

55. References
Jari Arkko, “Introduction to multihoming, address selection, failure detection, and recovery”, IETF Proceedings. URL:
“Design of the MOBIKE protocol”, Internet Draft, draft-ietf-mobike-design-00.txt , June URL:
Internet Key Exchange (IKEv2) Protocol, Internet Draft, draft-ietf-ipsec-ikev2-17.txt, September URL:
IKEv2 Mobility and Multihoming Protocol (MOBIKE), Internet Draft, draft-ietf-mobike-protocol-02.txt, September URL: