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
http://www.iec.org/online/tutorials/cell_comm/topic03.html
Handoff Hysteresis
Only handoff when signal drops below a given threshold Signal could be lower than optimal Fewer handoffs
http://people.deas.harvard.edu/~jones/cscie129/nu_lectures/lecture7/cellular/handoff/handoff.html
Upcoming Cellular Networks
4G cellular networks being developed Uses ALL-IP network architecture Ability to use 802.11 base stations Highly scalable
Critical in emergency conditions
4G Network
http://www.eeng.dcu.ie/~arul/4G.html
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 authenticateitself 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 toauthenticate 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 IPHeader
Header
ESP
OriginalIP
Header
Authentication / Integrity
New IPHeader
Header
AH
OriginalIP
Header
ESPESPAHAH
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 1999.
URL: http://www.eurescom.de/~pub-deliverables/P900-series/P912/D1/p912d1.pdf
“Security guidelines for the introduction of mobility to IP”, Security for mobility in IP, EURESCOM, March 2000. URL: http://www.eurescom.de/~pub-deliverables/P900-series/P912/D2/p912d2.pdf
Olivier Charles, “Security for Mobility on IP”, MTM 2000, Dublin, February 2000. URL: http://www.eurescom.de/~public-seminars/2000/MTM/12Charles/12aCharles/12Charles.pdf
SEQUI VPN Glossary, URL: http://www.sequi.com/SEQUI_VPN_Glossary.htm#IKE
“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:http://www.ietf.org/html.charters/mip4-charter.html
Mobility for IPv6 (mip6), IETF Working Groups. URL:http://www.ietf.org/html.charters/mip6-charter.html
D.Johnson, C. Perkins and J.Arkko, “Mobility Support in IPv6”, RFC 3775. URL:http://www.ietf.org/rfc/rfc3775.txt
Arkko et al, “Using IPsec to Protect Mobile IPv6 Signaling Between Mobile Nodes and Home Agents”, RFC 3776. URL: http://www.ietf.org/rfc/rfc3776.txt
IKEv2 Mobility and Multihoming (mobike), IETF Working Groups. URL:http://www1.ietf.org/proceedings_new/04nov/mobike.html
References
Jari Arkko, “Introduction to multihoming, address selection, failure detection, and recovery”, IETF Proceedings. URL:http://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 2004. URL:http://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 2004. URL:http://www.ietf.org/internet-drafts/draft-ietf-ipsec-ikev2-17.txt
IKEv2 Mobility and Multihoming Protocol (MOBIKE), Internet Draft, draft-ietf-mobike-protocol-02.txt, September 2005. URL:http://www.ietf.org/internet-drafts/draft-ietf-mobike-protocol-02.txt