Mobile IPv6 & Cellular Telephony

Download Report

Transcript Mobile IPv6 & Cellular Telephony

Mobile IPv6 & Cellular
Telephony
Charles E. Perkins
Nokia Research Center
Mountain View, CA USA
http://www.iprg.nokia.com/~charliep
[email protected]
Why Mobile IP?
• Both ends of a TCP session (connection) need to
keep the same IP address for the life of the
session.
• IP needs to change the IP address when a network
node moves to a new place in the network.
Mobile IPv4 changes the mobility problem into a
routing problem
Mobile IPv4 protocol overview
Home Agent
Foreign Agent
178.24.9.36
•
•
•
•
correspondent node
Advertisement from foreign agent
Seamless Roaming: mobile node keeps home address
Foreign agent offers care-of address
Mobile Node “always on” by way of home agent
The Mobile IP(v4) solution
• Mobile node always uses the same IP address
(called the home address) for communication
• The care-of address is used for routing
• The home agent manages home network
operations for the mobile node while it is away
from home:
– encapsulation
– proxy ARP
• Specified in RFCs 2002-2006
Foreign Agents & Triangles
• The foreign agent advertises the care-of address,
and terminates the tunnel from the home network
• All traffic to the mobile node is sent to the mobile
node's home address. Traffic from the mobile
node does not have to traverse the home network.
• This leads to the phenomenon of triangle routing.
Ingress Filtering
• Ingress filtering routers prevent packets
from entering the Internet unless the source
IP address is topologically correct.
• This leads to the possibility of reverse
tunneling (RFC 2344) from the care-of
address to the home agent.
Cellular architectures
• Involve SS7 over "control plane" to set up virtual
circuits for "user plane" traffic
• Are highly optimized for voice traffic (low delay,
guaranteed bandwidth), not data
• Tend toward "intelligent network" philosophy
which for IP is a misplaced locus of control.
• Operators want to migrate towards "All-IP"
solutions (whatever that means…).
Mobile IPv6 Design Points
•
•
•
•
•
•
Enough Addresses
Enough Security
Address Autoconfiguration
Route Optimization
Destination Options
Reduced Soft-State
Mobile IPv6 protocol overview
Home Agent
Local Router
[email protected]
•
•
•
•
•
correspondent node
Advertisement from local router
Seamless Roaming: mobile node keeps home address
Address autoconfiguration for care-of address
Binding Updates sent to correspondent nodes
Mobile Node “always on” by way of home agent
Enough Addresses
• 340 undecillion addresses
(340,282,366,920,938,463,463,374,607,431,768,211,456) total
• Billions of IP-addressable wireless handsets
• Address space crunch is already evident
– recent unfulfilled request to RIPE
• Multi-level NAT unknown/unavailable
• Even more addresses for embedded wireless
• Especially interesting for China now
Enough Security (almost)
• Authentication Header
• Needed for Binding Update
– Remote Redirect problem
• Encapsulating Security Payload
• Required from every IPv6 node
• Key distribution still poorly understood
– PKI?
– AAA?
Address Autoconfiguration
• A new care-of address on every link
• Stateless Address Autoconfiguration
Routing Prefix
MAC address
• Link-Local Address  Global Address
• Stateful Autoconfiguration (DHCPv6)
• Movement Detection
Destination Options
• Binding Updates without control packets
– allows optimal routing
– replaces IPv4 Registration Request messages
• Home Address option
– better interaction with ingress filtering
– supported by all IPv6 network nodes
• Binding Acknowledgement
– replaces Registration Reply
Route Optimization
• Reduces network load by ~50%
– (depending on your favorite traffic model)
• Most Internet devices will be mobile
• Route Optimization could double Internetwide performance levels!
• Binding Update SHOULD be part of every
IPv6 node implementation
Improved ICMP messages
• IPv4 ICMP returns only 8 payload bytes
• IPv4 home agents could not relay errors
– insufficient inner header information
– some data sources might never find out about
broken links
• IPv6 ICMP messages return enough data
• Also used for anycast home agent discovery
Mobile IPv6 status
• Interactions with IPsec fully worked out
• Mobile IPv6 testing event Sept 15-17
– Bull, Ericsson, NEC, INRIA
• Connectathon last month – success!
• Internet Draft is ready for Last Call
• Another bake-off likely by fall
AAAv4 and Cellular Telephony
•
•
•
•
•
•
Terminology
Protocol overview
Key Distribution
Scalability and Performance
IETF Status
How can we make it work for Mobile IPv6?
Terminology
• Authentication – verifying a node’s identity
• Authorization – for access to resources
– according to authentication and policy
•
•
•
•
•
Accounting – measuring utilization
Network Access Identifier (NAI) – user@realm
Challenge – replay protection from local attendant
AAAF for foreign domain
AAAH for home domain
AAA & Mobile IP protocol overview
AAAF
Local Attendant
AAAH
Home Agent
[email protected]
•
•
•
•
•
•
•
Advertisement from local attendant (e.g., router)
Connectivity request w/MN-NAI from Mobile Node
Local Attendant asks AAAF for help
AAAF looks at realm to contact AAAH
AAAH authenticates & authorizes, starts accounting
AAAH, optionally, allocates a home address
AAAH contacts & initializes Home Agent
Key Distribution
• New security model
– just one SA: mobile node  AAAH
• So, association needed HA  mobile node
• TR45.6, others, want also:
– local attendant  mobile node
• AAAH can allocate the keys for this
Brokers
AAAF
Local Attendant
AAAH
Home Agent
• Needed when there are 1000’s of domains
• NAI is perfect to enable this
• AAAF decides whether to use per realm
– may prefer bilateral arrangement
• iPASS, GRIC
Scalability and Performance
•
•
•
•
Single Internet Traversal
Brokers
Eliminate all unnecessary AAA interaction
Handoff between local attendants (routers)
– can use keys from previous router
• Regional Registration
• HA can use single care-of address per
domain
Mobile IP/AAA Status
• AAA working group has been formed
• Taking a page from the existing model with
RADIUS
• Mobile IP (v4) AAA requirements draft
– Last Call “over”
• Several 3G requirements documents online
• Mobile IP/AAA extensions draft
• AAAv6 Internet Draft(s) submitted
– stateless and stateful variations
Other features (needed for IPv6)
• Routers used instead as mobility agents
• Regional registration
– eliminates most location update traffic
– GGSNs/border routers are candidates
•
•
•
•
•
UDP Lite
Robust Header Compression
AAA  HLR adaptation layer
Challenge generation (not from HLR?)
Privacy considerations
Hierarchical Foreign Agents
GFA
Home Agent
LFA
Home Agent stores GFA address as the Care-of Address
Mobile Node registers only once with Home Agent
Mobile node registers locally with GFA
Often, only one level of hierarchy is being considered
3GPP with GPRS
Evolution from cellular packet/GPRS
Mobility agent
At GGSN
Subscription and
Location Directory
HSS
BSS
PSTN
CPS/GK
GGSN
BSC/RNC
SGSN
GW
GPRS
Internet
Call Processing
Server/Gatekeeper
Traditional BSS with
packet data QoS
enhancements
One (of many) “ALL-IP” visions
Evolution from general IP networks
Subscriber
database
AAA Server
AAA Server
HA
HA
(mobility within
serving ntw)
"Slim RNC/BSC"
CPS
PSTN
FW
FW
Internet,
Intranets
GW
CDMA2000 3G micromobility
AAA Server
RNN
Subscriber
database
AAA Server
HA
PDSN
CDMA2000 3G micromobility
•
•
•
•
•
Terminate physical layer distant from “FA”
Protected, private n/w between FA and MN
PDSN (Packet Data Serving Node) ~ GFA
RNN (Radio Network Node) ~ LFA
RNN manages the physical layer connection
to the mobile node
CDMA2000 3G Requirements
•
•
•
•
•
GRE encapsulation (but will it survive?)
Reverse Tunneling (RFC 2344)
Registration Update
Registration Acknowledge
Session-specific registration extension
– contains MN-ID, type, MN Connection-ID
– contains Key field for GRE
CDMA2000 Registration Update
• Used for handovers to new RNN
• Acknowledgement required
– allows PDSN/old RNN to reclaim resources
•
•
•
•
New authentication extension required
Home address  0
Home agent  PDSN
Care-of address  RNN
IMT-2000/UMTS/EDGE reqt’s
• Independent of access technology
– so should work for non-GSM also
• Interoperation with existing cellular
• Privacy/encryption (using IPsec)
• QoS for Voice/IP and videoconferencing
– particular concern during handover
• Fixed/mobile convergence desired
IMT-2000 reqt’s, continued
• Charge according to QoS attribute request
• Roaming to diverse access technologies
– e.g., Vertical IP
•
•
•
•
Route optimization
Identification/authorization based on NAI
Proxy registration for legacy mobile nodes
Signaling for firewall traversal
IMT-2000 reqt’s, continued
• Reverse tunneling
• Private networks
– but, still allow access to networks other than the
mobile node’s home network
• Dynamic home address assignment
• Dynamic home agent assignment
– even in visited network
– even when roaming from one visited network to
another
IPv6 status for cellular telephony
• Seems highly likely to be mandated for
3GPP, with IPv4 support optional only
• MWIF recommendation for IPv6
• 3GPP2 study group favorable towards IPv6
• Seems difficult to make a phone call to a
handset behind a NAT (not impossible, just
expensive and cumbersome and protocolrich)
Summary and Conclusions
•
•
•
•
•
•
•
Future Internet is largely wireless/mobile
IPv6 needed for billions of wireless devices
Mobile IPv6 is far better and more efficient
Autoconfiguration suitable for the mobile Internet
Security is a key component for success
AAA has a big role to play for cellular rollout
Leverage from current cellular interest