Network Mobility

1
Network Mobility

• Yanos Saravanos
• Avanthi Koneru

2
(No Transcript)
3
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

4
(No Transcript)
5
(No Transcript)
6
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

7
(No Transcript)
8
Current Security Techniques

• HTTP-based schemes
• Mobilestar
• Point-Point Protocol (PPP) using EAP
• 802.1X

9
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

10
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

11
Benchmarks

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

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

• home network
• home agent
• foreign agent
• foreign address
• care-of address
• foreign (or visited) network
• correspondent
• permanent address

14
Indirect forwarding to a mobile node
Computer Networking A top-down approach
featuring the Internet, Kurose and Ross, 3rd
edition, Addison Wesley, 2004.
15
Encapsulation and Decapsulation
Computer Networking A top-down approach
featuring the Internet, Kurose and Ross, 3rd
edition, Addison Wesley, 2004.
16
Direct routing to a mobile user
Computer Networking A top-down approach
featuring the Internet, Kurose and Ross, 3rd
edition, Addison Wesley, 2004.
17
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.

18
Mechanisms to be reviewed

• Protocol for carrying Authentication for Network
  Access (PANA)
• Mobility and Multihoming extension for IKEv2
  (MOBIKE)

19
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

20
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.

21
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.

22
Terminology

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

23
Protocol Overview

• Discovery and handshake phase
• Authentication and authorization phase
• Access phase
• Re-authentication phase
• Termination phase

24
(No Transcript)
25
PANA lt--gt 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.

26
(No Transcript)
27
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.

28
Establishing a Secure Negotiation Channel using
IKEv2
Figure from Dr. Andreas Steffen, Secure Network
Communication, Part IV, IP Security (IPsec).
29
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.

30
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.

31
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.

32
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.

33
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.
  

34
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.

35
References

• Security requirements for the introduction of
  mobility to IP, Security for mobility in IP,
  EURESCOM, October 1999.
• URL http//www.eurescom.de/pub-delivera
  bles/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/1
  2Charles/12aCharles/12Charles.pdf
• SEQUI VPN Glossary, URL http//www.sequi.com/SEQU
  I_VPN_Glossary.htmIKE
• Computer Networking A top-down approach
  featuring the Internet, Kurose and Ross, 3rd
  edition, Addison Wesley, 2004.

36
References

• Mobility for IPv4 (mip4), IETF Working Groups.
  URLhttp//www.ietf.org/html.charters/mip4-charter
  .html
• Mobility for IPv6 (mip6), IETF Working Groups.
  URLhttp//www.ietf.org/html.charters/mip6-charter
  .html
• D.Johnson, C. Perkins and J.Arkko, Mobility
  Support in IPv6, RFC 3775. URLhttp//www.ietf.or
  g/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. URLhttp//www1.ietf.org/proceedin
  gs_new/04nov/mobike.html

37
References

• Jari Arkko, Introduction to multihoming, address
  selection, failure detection, and recovery, IETF
  Proceedings. URLhttp//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.
  URLhttp//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. URLhttp//www.ietf.org/internet-drafts/draf
  t-ietf-ipsec-ikev2-17.txt
• IKEv2 Mobility and Multihoming Protocol (MOBIKE),
  Internet Draft, draft-ietf-mobike-protocol-02.txt,
  September 2005. URLhttp//www.ietf.org/internet-
  drafts/draft-ietf-mobike-protocol-02.txt