2.5.3 IP Routing for Wireless/Mobile Hosts (mobileip)

NOTE: This charter is a snapshot of the 46th IETF Meeting in Washington, DC. It may now be out-of-date. Last Modified: 29-Sep-99

Chair(s):

Phil Roberts <qa3445@email.mot.com>
Basavaraj Patil <bpatil@nortelnetworks.com>

Routing Area Director(s):

David Oran <oran@cisco.com>
Rob Coltun <rcoltun@siara.com>

Routing Area Advisor:

Rob Coltun <rcoltun@siara.com>

Mailing Lists:

General Discussion:mobile-ip@standards.nortelnetworks.com
To Subscribe: listserv@standards.nortelnetworks.com
In Body: subscribe mobile-ip first_name last_name
Archive: http://www.nortelnetworks.com/standards

Description of Working Group:

Note: Dave Oran (oran@cisco) is the WG Advisor

The Mobile IP Working Group has developed routing support to permit IP nodes (hosts and routers) using either IPv4 or IPv6 to seamlessly "roam" among IP subnetworks and media types. The Mobile IP method supports transparency above the IP layer, including the maintenance of active TCP connections and UDP port bindings. Where this level of transparency is not required, solutions such as DHCP and dynamic DNS updates may be adequate and techniques such as Mobile IP not needed.

The WG moving forward will focus on deployment issues in Mobile IP and provide appropriate protocol solutions to address known deficiencies and shortcomings. For example, the wireless/cellular industry is considering using Mobile IP as one technique for IP mobility for wireless data. The working group will endeavor to gain an understanding of data service in cellular systems such as GPRS, UMTS, CDMA2000, and interact with other standards bodies that are trying to adopt and deploy Mobile IP WG protocols in these contexts. In order to provide a complete solution and a set of protocols that can be used as a roadmap for widespread deployment, the following work needs to be accomplished by this WG. In the near term, the WG needs to work on:

- Use of NAIs to identify mobile users/nodes.

- Specifying how Mobile IP should use AAA functionality to support inter-domain and intra-domain mobility.

- Evolve the security framework/trust model for mobile nodes.

- Develop solutions for IPv4 private address spaces for the scenarios needed for deployment.

- Documenting any requirements specific to cellular/wireless networks.

In the longer term, the WG needs to address:

- Additional IP-based solutions for micro mobility (movement within a subnet).

- QoS in the mobile IP environment using diff-serv and/or int-serv/RSVP.

- Location Privacy.

The Working Group will ensure that solutions proposed for these problem domains are suitable for IPv4 and IPv6 respectively.

Goals and Milestones:

Done

  

Review and approve the charter, making any changes deemed necessary.

Done

  

Post an Internet-Draft documenting the Mobile Hosts protocol.

Done

  

Review the charter of the Mobile IP Working Group for additional work required to facilitate non-host mobility.

Jul 96

  

Submit the IPv4 Mobile Host Protocol to the IESG as a Proposed Standard.

Dec 96

  

Submit the IPv6 Mobile Host Protocol to the IESG as a Proposed Standard.

Mar 97

  

Review the WG charter and update as needed.

Jun 99

  

Review the WG charter and update based on current needs and focus.

Jun 99

  

Submit the Mobility Support in IPv6 to the IESG for consideration as a Proposed Standard.

Jun 99

  

Submit Internet-Draft for NAI support in Mobile IP to IESG for consideration as a Proposed Standard.

Aug 99

  

Review the use of AAA in Mobile IP to support inter-domain and intra-domain mobility and dynamic home agent assignment.

Dec 99

  

Review security framework requirements for Mobile IP.

Dec 99

  

Review solutions and submit drafts for mobility in private address spaces.

Dec 99

  

Submit draft on using AAA in Mobile IP for inter-domain and intra-domain mobility as a proposed standard.

Dec 99

  

Submit draft capturing cellular requirements to IESG as an Informational RFC.

Jul 00

  

Review QoS in a Mobile IP enabled network.

Jul 00

  

Submit Mobile IPv6 MIB to IESG for consideration as a Proposed Standard.

Sep 00

  

Submit the IPv4 Mobile IP Protocol to the IESG for consideration as a Draft Standard.

Internet-Drafts:

Request For Comments:

RFC

Status

Title

 

RFC1853

 

IP in IP Tunneling

RFC2005

PS

Applicability Statement for IP Mobility Support

RFC2004

PS

Minimal Encapsulation within IP

RFC2003

PS

IP Encapsulation within IP

RFC2002

PS

IP Mobility Support

RFC2006

PS

The Definitions of Managed Objects for IP Mobility Support using SMIv2

RFC2344

PS

Reverse Tunneling for Mobile IP

RFC2356

 

Sun's SKIP Firewall Traversal for Mobile IP

Current Meeting Report

The Mobile IP WG met in Washington D.C for two sessions on Thursday, November 11th '99 from 9 - 11.30 AM and 3:30 - 5:30 PM.

Attendance at the sessions was approximately 226.

The meeting minutes for both sessions have been provided by Pete McCann.

| Morning Meeting (9:00 AM - 11:30 AM) |

WG Status

Status of MN-NAI draft - The IESG has assigned an Experimental status to this document.
Charles says it should be proposed standard - why don't we ask for this change now?
Pat: "It's not clear how Mobile IP will make use of NAI" said the IESG. But we need to make it work with other ROAMOPS stuff.
Raj says we will make another request to the IESG to change the status to PS.

WG documents that will go to last call:

Dave Johnson
Got a lot of comments at the last minute on Mobile IPv6 Mostly regarding IPSec interactions. We will go to working group last call shortly, then to IETF last call.

Mobile IP Requirements for AAA
Raj says that this document is owned by the Mobile IP WG and the WG needs to arrive at a consensus on the requirements. The intent is to feed the requirements as input to the AAA WG. The WG has been requested to provide more input into AAA Pat: AAA WG has a very aggressive timeline. People should read this draft and provide comments. Maybe the only way to do that is to take it to last call.

Draft Presentations :

1. Mobile IP Based Micro Mobility Management Protocol for 3Gwireless Network Systems - draft-ietf-mobileip-3Gwireless-ext-01.txt

It's a WG document because it will aid deployment of Mobile IP. The document is a work of TIA TR45.4 and 3GPP2 TSG-A lots of contributing companies Overview of 3G wireless network service domain - RNN, PDSN, R-P network PDSN terminates link-layer and hosts a foreign agent Draft focuses on R-P connection - minimizes latency of handoff

R-P Mobillity protocol objectives

Q: Raj & Charles: could we use Binding Update for this?
A: yes, but standardization status of Route Optimization is unclear

Q: Dave Johnson: why is your schedule so tight?
A: (rajesh and lipford) yes, our schedule is tight - TSG is already in last call

Q: Ramjee: is RP an IP network?
A: yes
Q: Why not send binding update if the FA is at the RNN?
Pete: We have a requirement to give good service to nodes without MIP clients. This is why RP must tunnel PPP data.

Q: Nordmark: how does old PDSN know the MN has gone?
A: timeouts

Q: when do you do a PDSN change?
A: outside the scope

2. Update to RFC2002 - MobileIPv4 revised (Charles Perkins)

Really, really nit-picky details
Some places in original draft said be careful about using now it said just don't

Clarification by Charles:
This refers to discussion about how to handle ARP for the mobile node and the foreign agent.

RFC2002bis places significant new restrictions on the use of ARP.

MN must ignore reserved bits in advertisement instead of drop the advertisement Calculation of authentication extension must include SPI FA can now configure a max number of pending registrations, and may delete them if > 7 seconds old

Clarification by Charles:
RFC2002 offers 7 seconds as a typical value for this timeout. Particular implementations can still pick whatever value they like. Other discussion at the meeting suggested the specification of a minimum value, and changing the suggested maximum from 7 seconds to something more.

FA must check for the case of MN registration even when on home network Unrecognized set bits or unrecognized care-of address cause FA to drop registration request

Max number of outstanding requests not standardize, but 7 seconds is hardcoded.
Dave J. & Nordmark: why is this hard coded?
A: ok, we'll talk about it

What to do with this draft? Mandatory support for reverse tunneling? Do we take it to draft standard or to an intermediate proposed standard? Does it become an RFC?

Some features have not been tested for interoperability - this would hinder draft standard status

Pat: if there is a protocol change, it must go back to the beginning?
A: yes, if they are big
Dave: if changes reduce the maturity level, then yes, we have to go back to proposed
Pat: all interoperability already uses the new SPI calculation

Q: new FA forwarding text; sometimes two MNs on the same FA sometimes get traffic forwarded directly rather than via HA. Also MNs can introduce denial of service if they make a mistake in their registration messages - sometimes re-registrations can be redirected at a MN!
A: Reverse tunneling might be important enough to go in.

Q (Charles): Is this a revised draft or a new draft?
A: Raj : maybe it's just a revision and we should go to draft standard
A: Dave: a new proposed standard would be a new 6 month clock

Q: Nordmark: what about the untested features?
A: Charles: yes, that's a concern

Q: what about private addresses?
A: Charles: let's not tackle that yet
A: Raj: we had some discussion and came to consensus, but it doesn't need to go in this draft

Montenegro: We could support private addresses with RFC2344
Survey of the room on proposed vs draft for this revision: about 25 for porposed, low single digits for draft, a few abstainers. Because of the low number of votes we will take the question to the list.

3. AAA Requirements for Mobile IP (Charles Perkins)

This has been presented to AAA WG
Tom Hiller has a similar presentation
This is now a MIP WG item - please read it and comment

Interactions between Mobile IP and AAA

Q: Johnson & Dommety: Can we really do away with security association between MN and HA? It's coded in the standards
A: Yes, this is a change, but people in industry like it
Q: Johson & Raj: this is a change. Doesn't it break implementations?
A: Maybe, but this is a good way to model interaction between MIP and AAA
Q: Gopal: we need to keep RFC2002 as is
A: Charles: we are not breaking RFC2002, but we do need to change the requirement MN-HA extension
Q: Vipul: can't we just use MN-HA extension as is?
Q: Pat: AAAH will be generating session keys. We need to know when to go to AAA vs. doing MIP
Q: Gopal: we could view HAAA & HA as one network. We are asking AAAH to do Mobile IP
A: Pat: AAAH has no idea what a MIP RRQ looks like

4. AAA Requirements for cdma2000 (Tom Hiller)

TR45.6 wireless data group
Carriers & vendors

Intro: packet data service for cdma2000; PPP service with limited mobillity + Mobile IP
Public & Private network access
Avoid IPsec tunneling over air interface
HA in public or private network
Overlay, dual-authentication architecture

General Architecture
PDSN, AAA, VLR, HLR, HA

cdma2000 MIP deployment status
We need FAC with RADIUS-like extension
Deployment depends on NAI and FAC drafts
We need a robust AAA infrastructure

Q: NAI privacy is not a first requirement?
A: We're studying it, we don't know if it's a long term requirement or not

5. Mobile IP Vendor/Organization Specific Extensions (Gopal Dommety)

Facilitate extensions for research and experimentation
Deployment in specific environments
Will help standards organizations (TR45.6) to standardize usage in specific environments

Two extensions are proposed:
Normal Vend/Org specific extension (NVSE)
Type should be in range 128 to 255
Vendor ID - higher order=0, low 3 bytes are SMI number for org/vendor
Opaque data

Critical Vend/Org specific (CVSE)
Type in range 0-127
Length is two bytes long

Q: Pat: we all know there will be an identifier in the opaque data. In RADIUS, we ended up with a lot of different encodings for the types. Maybe we should add a "type" in the opaque data field.
A: Ok, maybe we will add a two-byte type for the data.

Three new error codes
Reg denied by FA - TBD code 1 unsupported vendor specific
Reg denied by HA

Q: Vipul: since type is critical, should we revise RFC2002 to add error message if critical type is not recognized?
A: good idea, but we should defer to Charles
A: Charles: he's happy to put it in if the group agrees

Raj: next step is to make the changes and go to last call
Please send comments. Any major concerns?

6. KENA (Raja Narayanan)

KENA concepts/highlights
Centralized key distribution framework protects user privacy and enables authentication is real time sensitive can be easily implemented using extensions to existing protocols

Lots of questions about need for NAI privacy and traceability If NAI is encrypted, it is still the same every time and would be traceable
Same for link-layer identifier

7. AAA Session Keys (Pat Calhoun)

It's now an individual contribution. The WG was asked if this needs to be a WG document. General agreement reached. The document will be resubmitted as a WG document.

MIP AAA requirements state that KDC is required
Creates 3 keys MN-HA, MN-FA, FA-HA

Problem: session keys destined for FA and HA will be delivered in some

Proposal: Session keys destined for the MN are sent to the HA in the

Q: Gopal: couldn't this be encrypted with the MN-HA key/SPI, not the MN-AAA key/SPI
Q: Nordmark: shouldn't we hide the SPIs?
A: Yes, maybe we will make these changes

| Afternoon Meeting (3:30 PM - 5:30 PM) |

1. Mobile IP Extension Rationalization (Mohamed Khalil)

Add a "content type" and "E" field. SPI present if "E" is present.
Then some session data.
Use "type" field like "NAI" or "Authentication Extension" then use
Content-Type to be "MN-HA" or "MN-FA", or "MN" "HA" "FA". Add an "ET" bit

If someday we run out of types, we need to allocate 2 new types, one from 0-127, another from 128-256

Q: Pat: why can't we start using the new extended types right away?
A: the long-term solution is harder to manage
Q: Pat: what about the space after the E bit?
A: Different extensions can have different flags
Q: Pat: why cant we encode encryption in the content-type?
A: User could do that if he wants

Q: Charlie: In auth extension, why not have a longer length and not keep the reserved bits? They could be taken care of with the SPI.

Q: Dave Johnson: why are we re-doing encryption? Why not use ESP?
A: this is just like what Pat presented this morning

Q: Why do we need the E bit?
A: Sometimes SPI doesn't need to be present
Q: Pat: there are many types that don't need SPI?

Q: Raj: what if we just had a reserved section, not an E bit?
A: yes, E bit not needed for many types

Q: Security association may be used for protecting the extension only? Then maybe any attribute would need an SPI?
A: Maybe... we'll take further questions on the list.

Q: Is there interest in making this draft a WG item? (Raj asks) is there a real concern we are running out of Type space?
Q: Pat: how many type numbers are assigned today?
A: Charles: about 20 or so. We should have a bit more discussion on the mailing list about whether this is needed.

2. Mobile IPv6 Connectathon Report (Francis Dupont)

Organized by the G6 group

Implementations by :

Tests were done between MN & fixed correspondent, and MN &MN. Some tests were done through the 6bone but most tests run on a local WaveLAN.

Graph of network connectivity

Suggestions for improvement in IPv6 draft

Q: Dave Johnson: I have seen only the second one mentioned on the mailing list

Conclusions

Q: Dave Johnson: not enough details. where can I get more? (clarification in French)
A: last slide: http://www.loria.fr/~ichris/mobipv6/connectathon99/index.html

3. Cellular IP Update (Andrew Campbell)

Woody Allen story.... (Bulldozer noise in the background)

Cellular IP project
Started at Columbia with Ericsson
Simple Vision: combining the strengths of Cellular + IP without inheriting their weaknesses, leverage MIP work

Design Goals
Fast and seamless handoff

Scalable and real-time location management

Simple access network design

A lot of proposals in the past

Major changes to the Internet Draft

Minor changes to the I-D

Web page for Cellular IP
comet.columbia.edu/cellularip/

4. Cellular IP Performance (Javier Gomez)

Implementation, Topology, evaluation

Cellular IP nodes/mobile hosts: Pentium 300 MHz
Wired links: ethernet 10/100
wireless linnks: 802.11 with new device drivers

Software

Implementation Model
Dowlink interface, uplink interface, PCAP in kernel space
Routing cache, paging cache, in user space

Repeat experiment with TCP (TTCP)
performance graph of downlink TCP throughput vs. number of handoffs per minute
Semisoft handoff improves throughput - using a buffer improves throughput even more

Q: Charlie: what is semi-soft handoff?
A: immediately upon handoff, we can send control messages to the old BS to forward packets

Scalability issues

Other scalability issues: increase the size of the database in which we search for a mobile
Graph: nodes throughput in Mbps vs. number of MNs in the database
Is not too bad for IP forwarding to a single user when we do binary search
Linear search performance gets very poor as number of MNs increases

Q: do you really mean 10^6 MNs?
A: yes
Q: how many routers need to be updated?
A: depends on the scenario

source code is at comet.columbia.edu/cellularip

Q: you are not including changes in the over-the-air data rate as the MN changes speed? As the active nodes move at different velocities, they change their data rate.
A: yes, we need more signaling

Q: performance are for TCP streams. What about latency?
A: no. Compared throughput with IP forwarding
Q: look at CDPD - its latency is too high.
A: Achieving 90% of what IP forwarding can do, so latency should not be an issue

5. Minimal latency secure handoff (Pat Calhoun)

What can we do to minimize latencey when MN-FA share a key?

Mobile IP WG has a AAA KDC requirement
Home AAA server acts as a key distribution center and creates session keys

Foreign agent receives the session keys via the AAA protocol
When MN moves to a new FA, the new FA must retrieve the MN-FA and FA-HA session keys

An assumption has been made that the FA could get the keys from the AAAF.
If the AAAF does not have the session keys locally, the request must be sent to the AAAH to retrieve new session keys
This adds considerable delay in the hand-off process

Proposal
When new session keys are distributed by the AAAH, the FA encrypts the MN-FA and FA-HA session keys, and adds them to the RRP MN includes them in the RRQ at the new FA

Message size
Increased but only when new keys get generated

Q: (Raj): if all FAs are in the same domain?
A: we could query the previous FA, but it's simpler to use a blob that is passed to the new FA
Q: Charles: state of route optimization draft is not clear, but it may come back to life. Wouldn't it be better to retrieve the key from the old FA over the wired network using the same SA?
A: do we have a chicken and egg problem? Before we send the binding update, we need to authenticate?
Charlie: no, the binding update includes the authentication
Pat: ok, maybe this isn't necessary

Q: To clarify: when the MN moves to a new FA, instead of sending previous FA NAI, just use previous FA notification message from binding update draft
A: Charlie: correct, but we don't need the NAI. You could use it if you wanted to.

Q: (Milo): Two kinds of models, terminal centric, network-centric model. Maybe as we roam, I identify myself to the new FA, on behalf of MN I establish connectivity to a new HA
A: Charlie: no need to go to the extreme of eliminating all information from MIP RRQ
Milo: we still have registration between FA and HA, but not necessarily triggered by MN, just the announcement of the MNs identity. All information is retrieved from previous FA.
A: Charlie: not related to current presentation. This is purely a device for passing around keys.

Q: Pat: can we process RRQ and Binding Update simultaneously?
A: Charlie: they happen in parallel
Q: what would happen if MN-FA was invalid, but MN-HA is valid?

Next version of draft will be issued that provides similar functionality when PKI is used instead of a KDC

6. Buffer Management for MIP (Haseeb Akhtar)

In addition to the layer-2 mechanism, we are trying to propose something on layer 3
Problem: packet loss during handoff
MN moves to a new FA, HA creates a new tunnel between HA-NFA, packets in transit to the previous FA are lost

Q: Dave Johnson: what about packets that were already sprayed into the air
A: old FA is constantly buffering, even packets that were sent on the air

Solution: buffer and forward data
Minimize the window of data loss: previous FA buffers packets and forwards to the MN
Results in fewer retransmissions for upper layer protocols

3 scenarios are in the draft, we will cover 2.
1. Mobile Assisted handoff
2. PFANEH handoff

New Messages
Buffer Control Request - Mandatory for MN and FA
Can be sent as an independent message or as an extension to Registration

Buffer Control Response

Q: Dave Johnson: I don't think you can convince everyone to allocate large buffers in FAs
A: Maybe, but its a tradeoff
A: we need a buffer of 2 or 3 packets
Dave: we need one window size for each TCP connection. That's more than 2 or 3

7. Dynamic IP Address Allocation in Mobile IP (Tomas Bostrom)

Current assumptions

Network Access Identifier

Why do we need dynamic address allocation?
Address = location
Name = identity
Hosts should be identified based on names, not IP addresses
Modern technology promotes nomadic computing (home network wherever you go)
=> concepts of home and foreign have become obsolete
no need for a permanently allocated address

Dynamic Address Allocation Scope

Solution

Q: 100 ms is too slow
A: within a domain only

What should we do?

Q: Gopal: NAI draft + RFC 2002 can do this
A: Would like to extend this idea

Q: Mobile IPv6 solves this problem
A: this is IPv4 base

Q: Milo: you have solved just half a problem, MN is just a client. If I want to refer to the MN, I need dynamic DNS. It is simpler to just go to a static HA than try to solve these problems.
A: MN should keep its temp IP address as long as it is connected to the same admin domain.
Q: Dave: do you lose that address when you move outside the domain?
A: yes
Q: this breaks TCP connections and the charter of this WG

Clarification from Tomas to the question:

When I said yes I assumed that the terminal was turned off before it was moved outside the domain. However, if the terminal is turned on while moving to a new domain the terminal should keep the same address in the new administrative domain using cross-domain allocation mechanisms and thereby keep its TCP connections alive.

Q: Gopal: what is the problem you are trying to solve? If you want to do only IP allocation we already do it

8. Modifications to "Mobile IP Regional Tunnel Management" from a cellular perspective (John Wang)

Purpose:

Special concerns:

Issues

Q: (Dave Johnson) is tromboning same as triangle routing?
A: yes.

Why is tromboning a great concern?
Cost & quality of service

Q: Dave Johnson: who provides services of higher layers of the hierarchy?
A: cellular service providers could have total or shared ownership
Q: Are you proposing a global infrastructure separate from the Internet?
A: no limitations. Could be part of intranet, depending on business model

Well Recognized Technology

Open issues

Q: Are you proposing new inter- or intra-system network?
A: there is no requirement. Could be either. For performance it should be intra-system
Q: So this is baseline for UMTS or cdma2000 architecture?
A: Cellular carriers in 3GPP and UMTS require this
Q: 3GPP already has some internal protocol

Slides

AAA Requirements from Mobile IP
Buffer Management for Buffer Management for MIP
Cellular IP Performance
Dynamic IP Address Allocation in Mobile IP
Mobile IP Vendor/Organization Specific Mobile IP Vendor/Organization Specific Extensions