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