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:
- 3Gwireless micro-mobility
- Vendor/Org extensions
- Mobile IP for IPv6
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
(Rajesh Bhalla)
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
- minimize RNN handoff latency and round-trip signaling through the packet network
- Extend link layer connectivity beyond a physical layer termination
- RNN and link-layer termination PDSN
- Provide mobility from RNN to RNN
- Provide a secure signaling mechanism for data transport
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)
(draft-ietf-mobileip-rfc2002-bis-00.txt)
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)
(draft-ietf-mobileip-aaa-reqs-00.txt)
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
- MN presents credentials to the FA
- Credentials are sent to FAAA, HAAA where they are verified, sent to HA
- AAA protocol should work without specific details of Mobile IP
- Mobile IP should work without specific details of AAA
- FA - FAAA association, HA-HAAA association
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)
(draft-hiller-cdma2000-AAA-00.txt)
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)
(draft-ietf-mobileip-vendor-ext-00.txt)
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)
(draft-mkhalil-mobileip-kena-00.txt)
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)
(draft-calhoun-mobileip-aaa-keys-00.txt)
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
- AAA protocol
- MN must get the keys in some other way
Proposal: Session keys destined for the MN are sent to the HA in the
- AAA message
- HA adds these session keys to the Registration Reply
- Mobile node gets the keys when the reply arrives
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)
(draft-mkhalil-mobileip-mier-00.txt)
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 :
- BULL (AIX)
- ERICSSON - TELEBIT (FreeBSD)
- NEC (FreeBSD)
- INRIA (FreeBSD)
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
- Retransmissions of Binding Updates should increment the sequence number
- Renumbering, HA should DAD before binding ACK
- Draft has to do further into details of HA discovery
Q: Dave Johnson: I have seen only the second one mentioned on the mailing list
Conclusions
- Test event was very successful
- Some IPv6 stacks exist and can communicate
- Movement detection needs clarification
- o tests but discussion about IPSEC, IKE, and MIPv6 - SA with mobile SHOULD use a wildcard source
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)
(draft-valko-cellularip-01.txt)
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
- Per-mobile routing soft-state
- Loss and delay sensitive applications
Scalable and real-time location management
- Support for active and idle mobile hosts
- Routing cache, paging cache/implicit paging
Simple access network design
- Off-shelf IP based boxes (don't need expensive MSC/BSC)
- Plug and play configuration
- Support L2 or L3 networks
A lot of proposals in the past
- HAWAII, Cellular IP, THEMA, hierarchical MIP
Major changes to the Internet Draft
- Security support added
o Mobile and network have shared secret
o Control messages are authenticated
o Mobile goes through authorization phase, creates a PID, used by MN as it goes through the access network
- Paging areas added
o reduces messaging of idle hosts
- Semi-soft handoff with/without "delay devices"
o support for delay and loss sensitive apps (TCP and RTP/UDP) with fast handoff
o Sends a route-update packet to the new base station, then can receive packets from both old and new base station
o Delay devices introduced to do "coarse synchronization"
Minor changes to the I-D
- Cache mappings cannot be created or modified by data packets, but can be refreshed
- Optional paging tear-down
o Use soft-state whenever possible
- Control packets are ICMP
- Control packets must contain timestamp and auth information
Web page for Cellular IP
comet.columbia.edu/cellularip/
4. Cellular IP Performance (Javier Gomez)
(draft-gomez-cellularip-perf-00.txt)
Implementation, Topology, evaluation
- handoff
- Active/idle
Cellular IP nodes/mobile hosts: Pentium 300 MHz
Wired links: ethernet 10/100
wireless linnks: 802.11 with new device drivers
Software
- Runs in user space, based on PCAP
- easy to upgrade to newer freeBSD releases
- easy to port to other UNIX OSes
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
- Cellular IP uses per-host routes
- Achieves scalability by a separation of active/idle mobile hosts
- Most hosts are idle at any given time
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)
(draft-calhoun-mobileip-min-lat-handoff-00.txt)
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)
(draft-mkhalil-mobileip-buffer-00.txt)
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
- Request and Binding Update messages
Buffer Control Response
- Optional for MN and FA
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
- Mobile IP: transparent availability based on permanent IP address
- Permanent home address allocation
Network Access Identifier
- Identifies users
- assists routing authentication requests
- users can roam between admin domains
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
- Home address acquired dynamically on a temporary basis
- Local connectivity
- Roaming between different domains shall be possible
- Both in public and corporate networks
- Support cross-domain allocation
- "Home" and care-of address could be allocated from different admin domains
Solution
- DHCP-like mechanism should manage temporary IP address allocation
- Dynamic address associated with NAI using DNS-like mechanism
- Temp home address should be kept by the MN as long as it is connected to the same admin domain
Q: 100 ms is too slow
A: within a domain only
What should we do?
- Recent IETF drafts
o AAA Requrements
o DRCP (dynamic registration and configuration protocol)
o NAI draft
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)
(draft-ietf-mobileip-reg-tunnel-01.txt)
Purpose:
- Propose modifications that could be combined with MIP RT Management
- draft for issues in next generation cellular telephony networks
Special concerns:
- limitations on OTA capacity, computing power, power supply
- Real-time applications, high mobility
- mass market, global coverage with global roaming (different from just local coverage)
Issues
- Tromboning in data routing
o Triangle routing through HA
o Should have distributed FA database
- Peer-to-peer rather than master-slave
o over-the-air capacity, computing power, power supply demanding
o (should put more demanding aspects into the network)
o should be able to fool-proof MIP
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
- UMTS applications
o performance evaluation and architecture optimization
o DDB architecture
- Lucent ATM distributed load-balancing technology very similar
Open issues
- Call routing regional tunnel management, route optimization
- Addressing & routes
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