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