Network Mobility Yanos Saravanos Avanthi Koneru

Agenda Introduction Problem Definition Benchmarks and Metrics Components of a mobile architecture Summary of MOBIKE and PANA Conclusion References Avanthi Yanos

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

Real Mobility – Cellular Handoff Hard handoff  Connected to 1 base station at all times Soft handoff  Connected to 2 base stations temporarily

Handoff Hysteresis Only handoff when signal drops below a given threshold  Signal could be lower than optimal  Fewer handoffs

Upcoming Cellular Networks 4G cellular networks being developed  Uses ALL-IP network architecture  Ability to use base stations  Highly scalable Critical in emergency conditions

4G Network

Current Security Techniques HTTP-based schemes  Mobilestar Point-Point Protocol (PPP) using EAP 802.1X

Issues with Current Authentication HTTP-based schemes  Requires user intervention PPP  Requires point-to-point link  EAP requires extra encapsulation 802.1X  Only works for 802 protocols  Not widely deployment yet

Problem Definition All current security protocols do not allow end user to move New protocols must:  Keep session during handoffs  Allow integration between mobile networks (802.11, cellular, etc)  Not dramatically increase packet size

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

Elements of a mobile network architecture “Computer Networking: A top-down approach featuring the Internet”, Kurose and Ross, 3rd edition, Addison Wesley, 2004.

Elements of a mobile network architecture home network home agent foreign agent foreign address care-of address foreign (or visited) network correspondent permanent address

Indirect forwarding to a mobile node “Computer Networking: A top-down approach featuring the Internet”, Kurose and Ross, 3rd edition, Addison Wesley, 2004.

Encapsulation and Decapsulation “Computer Networking: A top-down approach featuring the Internet”, Kurose and Ross, 3rd edition, Addison Wesley, 2004.

Direct routing to a mobile user “Computer Networking: A top-down approach featuring the Internet”, Kurose and Ross, 3rd edition, Addison Wesley, 2004.

Security for Mobility on IP IP mobility introduces the need for extra security because the point of attachment is not fixed, so the link between the mobile node and its home network should be considered insecure. In all potential mobile-IP scenarios, security will be a critical service enabler, ensuring that the mobile operator can communicate over IP without putting at risk the confidentiality, integrity, or availability of the home network and the information it contains.

Mechanisms to be reviewed Protocol for carrying Authentication for Network Access (PANA) Mobility and Multihoming extension for IKEv2 (MOBIKE)

PANA - Protocol for carrying Authentication for Network Access a layer two agnostic network layer messaging protocol for authenticating IP hosts for network access a transport protocol for authentication payload (e.g., EAP) between a client (IP based) and a server (agent) in the access network. Client-server protocol

Why PANA? A scenario: An IP-based device is required to authenticate itself to the network prior to being authorized to use it. This authentication usually requires a protocol that can support various authentication methods, dynamic service provider selection, and roaming clients. In the absence of such an authentication protocol on most of the link- layers, architectures have resorted to filling the gap by using a number of inadequate methods. Ex: PPPoE PANA – a cleaner solution to the authentication problem.

Goals of PANA To define a protocol that allows clients to authenticate themselves to the access network using IP protocols. To provide support for various authentication methods, dynamic service provider selection, and roaming clients.

Terminology PANA Client (PaC) Device Identifier (DI) PANA Authentication Agent (PAA) Enforcement Point (EP)

Protocol Overview Discovery and handshake phase Authentication and authorization phase Access phase Re-authentication phase Termination phase

PANA MOBIKE PANA will enable the establishment of an IPsec SA between the PaC and the EP (a router) to enable access control. The WG will also working on how such an IPsec SA is established by using IKE after successful PANA authentication.

MOBIKE - Background IPSec SA = AH + ESP + IKE Authentication / Integrity Encrypted New IP Header ESP Original IP Header Authentication / Integrity New IP Header AH Original IP Header ESPAH

Main Scenario  Mobike  The main scenario is making it possible for a VPN user to move from one address to another without re- establishing all security associations, or to use multiple interfaces simultaneously, such as where WLAN and GPRS are used simultaneously.

Establishing a Secure Negotiation Channel using IKEv2 Figure from Dr. Andreas Steffen, Secure Network Communication, Part IV, IP Security (IPsec).

Problem Currently, it is not possible to change these addresses after the IKE_SA has been created. Scenario 1: A host changes its point of network attachment, and receives a new IP address. Scenario 2: A multihoming host that would like to change to a different interface if, for instance, the currently used interface stops working for some reason.

Solution The problem can be solved by creating new IKE and IPsec SAs. Not optimal since, in some cases, creating a new IKE_SA may require user interaction for authentication (manually entering a code from a token card). Creating new SAs often also involves expensive calculations and possibly a large number of roundtrips.

MOBIKE Solution The party that initiated the IKE_SA (the "client" in remote access VPN scenario) is responsible for deciding which address pair is used for the IPsec SAs, and collecting the information it needs to make this decision. The other party (the "gateway" in remote access VPN scenario) simply tells the initiator what addresses it has, but does not update the IPsec SAs until it receives a message from the initiator to do so.

Goals of the MOBIKE working group IKEv2 mobile IP support for IKE SAs. Support for changing and authenticating the IKE SA endpoints IP addresses as requested by the host. Updating IPsec SA gateway addresses. Support for changing the IP address associated to the tunnel mode IPsec SAs already in place, so that further traffic is sent to the new gateway address. Multihoming support for IKEv2. Support for multiple IP addresses for IKEv2 SAs, and IPsec SAs created by the IKEv2. This should also include support for the multiple IP address for SCTP transport. This should also work together with the first two items, i.e those addresses should be able to be updated too.

Goals of the MOBIKE working group (..cntd) Verification of changed or added IP addresses. Provide way to verify IP address either using static information, information from certificates, or through the use of a return routability mechanism. Reduction of header overhead involved with mobility-related tunnels. This is a performance requirement in wireless environments. Specification of PFKEY extensions to support the IPsec SA movements and tunnel overhead reduction.

Conclusion Utilizing the benefits of the opportunities provided by default in IPv6 for the design of Mobile IP support in IPv6. Besides, these two protocols there are a lot of other security issues. Focus on mechanisms which will be adopted in the design of IPv6.

References “Security requirements for the introduction of mobility to IP”, Security for mobility in IP, EURESCOM, October URL: series/P912/D1/p912d1.pdfhttp:// series/P912/D1/p912d1.pdf “Security guidelines for the introduction of mobility to IP”, Security for mobility in IP, EURESCOM, March URL: deliverables/P900-series/P912/D2/p912d2.pdfhttp:// deliverables/P900-series/P912/D2/p912d2.pdf Olivier Charles, “Security for Mobility on IP”, MTM 2000, Dublin, February URL: seminars/2000/MTM/12Charles/12aCharles/12Charles.pdfhttp:// seminars/2000/MTM/12Charles/12aCharles/12Charles.pdf SEQUI VPN Glossary, URL: “Computer Networking: A top-down approach featuring the Internet”, Kurose and Ross, 3rd edition, Addison Wesley, 2004.

References Mobility for IPv4 (mip4), IETF Working Groups. URL: Mobility for IPv6 (mip6), IETF Working Groups. URL: 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:

References Jari Arkko, “Introduction to multihoming, address selection, failure detection, and recovery”, IETF Proceedings. URL: 1/sld1.htmhttp://www1.ietf.org/proceedings_new/04nov/slides/mobike- 1/sld1.htm “Design of the MOBIKE protocol”, Internet Draft, draft-ietf-mobike- design-00.txt, June URL: design-00.txthttp://www1.ietf.org/proceedings_new/04nov/IDs/draft-ietf-mobike- design-00.txt Internet Key Exchange (IKEv2) Protocol, Internet Draft, draft-ietf-ipsec- ikev2-17.txt, September URL: drafts/draft-ietf-ipsec-ikev2-17.txthttp:// drafts/draft-ietf-ipsec-ikev2-17.txt IKEv2 Mobility and Multihoming Protocol (MOBIKE), Internet Draft, draft-ietf-mobike-protocol-02.txt, September URL: