INTERIM_MEETING_REPORT_ Reported by Kannan Alagappan/Digital Equipment Corporation Minutes of the IP Routing for Wireless/Mobile Hosts Working Group (MOBILEIP) The MOBILEIP Working Group convened for an interim meeting on September 9 and 10 in Newark, NJ. This group is charted to develop or adopt architectures and protocols to support mobility within the Internet. In general, the two day meeting was productive. The group reached some agreement on the major architectural issues and terminology. The goals of the meeting were to generate a group draft, appoint an editor, and diffuse egos. CDPD Overview Mark Knopper presented a brief overview of the Wireless Data Market and the CDPD architecture, protocols, services. According to one source, 27% of the market will be for personal communications and 40% for mobile office. CDPD is developing open specifications for air protocol (secured), carrier interoperability, and network functionality (``ISO terminology in specification, but really IP''). A-Interface (airlink) between mobile end systems and mobile database stations, E-Interface (external network) between CDPD network and external world, and I-Interface (inter-service provider) between other CDPD service providers networks. Volumes 3 and 5 of the specification are relevant to this working group. The MNRP protocol is derived from ES-IS and seems to be between the mobile and visitor agent. The MNLP protocol is from the visitor agent to the home agent. The MDLP protocol is for cell switching between mobile data base stations. Mark also handed out a paper on the CDPD Engineering Plan for IP Address Allocation, draft 1.1. This paper proposes an allocation plan for IP addresses, and includes a justification and some discussion of the architecture and routing issues for the CDPD network. User/Functional Requirements John Penners presented his requirement analysis for Mobile IP. John described hard requirements and soft requirements. The group agreed that our solution should not preclude support for mobile segments, but mobile segments are not a hard requirement. After some discussion, two fundamental user requirements along with a few additional soft user requirements were decided upon: 1. A mobile host shall be capable of continuing to communicate using the same IP address, after it has been disconnected from the Internet and reconnected at a different point. 2. A mobile host shall be capable of interoperating with existing hosts, routers, and services. Additional soft user requirements: 1. Not weaken IP security. The general feeling is that there is none now. The marketing requirement is that users do not feel that Mobile IP significantly reduces their present security. 2. A Mobile host should be able to participate in IP multicast groups. 3. There should be a means of hiding mobile location information from correspondent hosts. Most of the other requirements in John's list were grouped as criteria for evaluating our solution. Greg Bruell rearranged John's list based on a hierarchical approach with a weighted model. These are metrics by which the group will judge its solution. o Robustness - Fault Isolation - the ability to isolate faults created by mobile users should be considered for both individual and group behavior. - Lost Packet Operation - protocols involved in supporting mobility should be able to maintain correct operations in the presence of loss of packets. - Robustness - support for mobile computing should provide sufficient robustness. - Failure Modes - failure modes, and specifically behavior in presence of partioned internet should be carefully evaluated. o Scalability - Distributed Burden - a scheme for mobile computing should be sufficiently flexible with respect to its capabilities of re-distributing the burden associated with supporting mobile computing between various entities within an internet. - Incremental Overhead - the incremental overhead of supporting mobile computing should reflect the number of entities that benefit from mobile computing. - Changes to Infrastructure - a scheme that supports mobile computing shall assume that changes that involve most of the components of the existing infrastructure are infeasible. - Scalability and Robustness - scalability needs to be complemented with robustness and fault isolation. o Security - Privacy of Location - a solution to mobile computing should be able to allow selective suppression of location information. - Security - any scheme for supporting mobile computing shall not adversely impact available security mechanisms. o Multicast/Broadcast - Multicast Applications - The support for mobile computing should allow multicast applications. ability for a mobile host to join a multicast group, send and receive multicast messages must be addressed. o Use of Resources - Minimize Network Resources - a scheme that supports mobile computing should attempt to minimize the use of the networking resources (e.g., bandwidth, memory on routers, CPU on routers) that are required to deal with mobility related issues. - Additional Equipment - a scheme that supports mobile computing should attempt to minimize the amount of additional equipment needed. - Cost of Resources - in addition to minimizing network resources, any scheme used to support mobile computing should be cognizant of the cost of these resources. o Level of Mobility - Multiple Mobile Host - a solution to mobile computing shall be able to deal with mobile segments that contain one or more hosts. - Multiple Levels of Mobility - a mobile computing solution shall be able to handle multiple levels of mobility. - Off-line Mobility - a mobile computing solution must not prevent upper layers from achieving off-line mobility while a host becomes disconnected from the rest of an internet for a prolonged period of time. Next, the group defined functional requirements. After some discussion on the top-down design methodology, the group decided on three functional requirements: 1. Establish and dissolve association with an attachment point. 2. Tunnel packets to a mobile host. 3. Inform other entities of mobile location. Alan Quirt described a short-term and long-term view for mobile IP: o Short-term (~2 years) - Develop a solution that essentially works. - Some broken IP problems. - Mostly plug-in, dial-in model. o Longer term (~5 years) - Everything works. - New IPng. - True wireless mobility. Tunneling Discussion (Encapsulation vs. Options) o Choice of tunneling protocol has an impact on location updating, how redirects are handled, and loop detection. o Options have more functionality but they slow down the infrastructure. o Options have a minor technical advantage, but they have a major practical disadvantage. o Options are IP-specific, therefore if we use options it may be hard to use our mobility solution with other protocols. o If hosts today receive a packet with an unknown option, what will they do? General feeling is that we should only send options to hosts that understand our protocol. o Options are nice because they give entities along the path a way to look at header. This can also be done with encapsulation. o Can we recommend IP encapsulation but allow options based on where tunnel ends? If so, we would need some sort of negotiation protocol to decide which one to use. This doesn't seem like a good idea. o If you really want options. One possibility is to encapsulate your options in the forward direction. This needs more thought. o Suggestion to use existing encapsulation protocol and don't invent a new one. o Having the source binding in every packet via options is a nice idea. If we seperate out the control packets, when do we send it? o We obviously don't need to send a control packet with every data packet. o It doesn't make sense to support *both* encapsulation and options. o We should not send an encapsulation or option to CH unless we know it understands the type of tunnel. o Seems like we want a separate data channel and control channel. Therefore use encapsulation for everything. First packet should not carry any source binding info to a CH in the interest of purity. o Network operators in general say ``don't use options''. o If we can make it work with encapsulation then why bother with options. So, propose tunneling via encapsulation for IPv4. o It is alright for ICMP control packets to be initiated by MHs. MH can send ICMP packet to CH directly. o Propose use UDP instead of ICMP for redirects since if CH doesn't understand the message, it will return positive feedback (ICMP msg) saying CH doesn't understand this port. o Would like to use ICMP for redirects so routers can snoop on packets to get location updates. o Would like to preserve the feature of possibly adding snooping and location updates into routers. If we have UDP redirects, we would be precluding this snooping. o What is the difference? An unknown ICMP type or an UDP to unknown port message both generate a packet back to sender. It isn't clear how this message is used. o Dogleg routing impacts entire Internet infrastructure. Dogleg impacts scalability because this type of routing more than doubles the traffic to mobile hosts. o Location caching should be left to future research. o If correspondent host doesn't understand mobile-ip protocol, do triangle routing. Try to optimize later. Agreement was reached on: - Tunneling via encapsulation - Dogleg routing to ignorant hosts During the next part of the discussion, the following terminology was used: HAA - Home Address Agent COAA - Care-Of-Address Agent CH - Correspondent Host MH - Mobile Host Q: Where does tunnel end? Tunnel always ends at the Care-Of-Address (COA). The COA may be on either the MH or COAA. Q: Where does the tunnel begin? Tunnel starts at either the CH or HAA. Q: Who sends the ICMP redirect? MH or HAA. Q: When does MH decide to send forward pointer update to old COAA? Eager or lazy o Simpler to deal with location privacy if MH sends redirect. o HAA, COAA, and MH can all send redirects. However it is probably more secure if redirects are sent by HAA or MH. o When a MH moves to a new COAA, the old COAA should be updated then all the CHs. This may be difficult since we don't know which CHs have cached location information. o It is better if the new COAA updates the old COAA when a MH has moved instead of waiting for the old entry to timeout. This will provide faster convergence. o One advantage of a HAA sending all redirects instead of a MH is that network traffic is on the wired network. o If packet for a MH goes to its old COAA and the old COAA does not have a forwarding pointer, it will send the packet to HAA o HAA does redirecting of packets and it maintains a location database. o Hosts can choose to believe redirect messages. Dogleg Routing Elimination Discussion o There are important security issues with trying to eliminate dogleg routing. Hosts need to authenticate redirect messages for MHs. o Some people generally said that they would like to see the working group produce a first Internet-Draft based on dogleg routing. Once we have more experience, we can add dogleg elimination or optimal routing. Another comment was if we only wanted a solution with dogleg routing, we could have solved the problem two years ago. o A vote was taken: Would you support a first Internet-Draft that does not address dogleg routing elimination, but only addresses the basic user requirements for mobile-ip? Yes - 9, No - 4 (a few abstained). o Another vote was taken : Would you support an RFC that does not address dogleg routing elimination, but only addresses the basic user requirements for mobile-ip? Yes - 8, No - 5 (a few abstained). o Based on this tentative vote, we decided to focus the rest of the day's discussion on getting a simple mobile IP design. Q: When a MH moves to a new COAA, is the old COAA told? Yes, at least the old COAA is notified that MH has unregistered. The old COAA does not need to keep a forwarding pointer. We may want to leave a forwarding pointer behind with a short TTL so we can capture packets in flight from HAA to the old COAA. Q: How do we do loop elimination? If we don't try to eliminate dogleg routing, then loop elimination isn't a serious problem. Q: What happens if packet goes to old COAA and no forwarding pointer? Old COAA forwards packet to HAA. o Steve mentioned that not everyone agreed with the decision to postpone dogleg routing elimination. Therefore we spent some time discussing this issue further. - CP: Would like to allow possibility of adding dogleg routing elimination in first draft. Thought that our vote was forbidding this possibility. - SD: Our vote yesterday was based on the question, ``is it acceptable to send out a draft without dogleg elimination?'' A majority said that it would be okay. - DD: If we distribute a first draft without a solution, then we haven't done our job. - YR: Fact that multiple solutions to dogleg routing exist indicates that we don't know how to do it. If people came up with a single solution, then we can adopt it. - KA: Propose adding dogleg elimination as an appendix to first draft. - PK: When taking a test, you do all the easy problems first, then the hard ones. Similarly, let's get a draft without dogleg elimination first. - YR: Dogleg elimination is still research. People interested in research should go to IRTF. - SD: Let's have a basic draft and people can propose text to solve optimal routing. - PK: We need experience with mobile-ip. We need to prototype multiple implementations and try it out over Internet. o We need one draft no matter how imperfect. Having ten solutions for dogleg elimination doesn't get interoperability. - CP: People who care to solve optimal routing can get together and work on it. Let's solve first things first. - YR: Eventually, we may want to move Internet-Draft to Prototype (instead of Experimental). Beaconing/Registration Discussion There was discussion on allowing multiple COAAs. That is having one COA served by multiple routers. For example, a set of routers on a subnet can act as a COAA for visiting MHs. It was agreed that a COAA should not proxy ARP for guest MHs. A registration proposal was discussed similar to CDPD. Where a MH sends a registration message to a COAA. The COAA registers the MH with the MH's HAA. The HAA returns a registration ack/nack message to the COAA. The COAA returns a ack/nack message to the MH. This simple protocol is designed to minimize the MH to COAA traffic. However it requires trust between the COAA and HAA. o Beaconing/Registration can be divided into two parts. First, MH discovers that a COAA exists. Second, MH intiates registration with COAA. o Advertisement should be multicast periodically so that a MH can determine which COAA cell it is in. If a MH doesn't hear an advertisement after some time, it may choose to multicast a Solicit message. A COAA that hears a solicit message, should unicast an advertisement to the MH. o Also, a MH may need to send a solicit message if it is attached to the network via an access point that filters incoming multicast packets. Agreement was reached on: - Advertisement/Solicitation/Registration model - Solicit responses are unicast o The term COAA will now be referred to as BASE in order to avoid the confusion between COA and COAA. o BASE Advertisement message contains the following information. Agreement was reached on: BASE Advertisement - type,code,checksum - COA address - [BASE address] ? - base incarnation number - advertisement interval - MAC address (in MAC header) o We may not need a base incarnation number since the HAA can tell the BASE that a MH is in its cell. o One reason for having a BASE address and a COA address in the advertisement is that they may be different if we allow multiple BASE stations to advertise the same COA address. o We got into a discussion where a domain propagates host routes inside. A MH registers with one BASE and it can move transparently around the domain without having to send any additional location updates to its HAA. Thus, this is one proposal for dampening traffic back to a HAA. o Another suggestion was to allow level 2 advertisement information to be sufficient to support registration. This may not be possible since the advertisement will need to pass along level 3 information like the COA address. o It may be necessary to have two addresses in the advertisement for multi-homed BASE stations. o MH Solicit message contains the following information. Agreement was reached on: MH Solicit - type,code,checksum - MH's IP address (in IP header) - MAC address (in MAC header) o The Registration protocol consists of 4 messages. First, is a MH-BASE registration message, second is a BASE-HAA registration message, third is a HAA-BASE ack/nack message, and finally a BASE-MH ack/nack message. o The MH-BASE registration message contains the following information. Agreement was reached on: MH-BASE Registration - type,code,checksum - HAA's address - sequence number (from MH to HAA) - previous COA address - [previous BASE address] ? - MH authenticator to HAA - MH authenticator to BASE ? - MH's IP address (in IP header) - MAC address (in MAC header) o We need the HAA's address because when a MH moves from its home subnet to a foreign subnet, the MH's HAA will not proxy ARP for the MH until it has been notified. Therefore the registration message must be sent directly to the HAA. o In terms of security, we recognize that eavesdropping can occur along the path. We want to prevent eavesdropping by someone on another network. Adopt a weak security model for now. Add strong security in the future. o The BASE-HAA registration message contains the following information. Agreement was reached on: BASE-HAA Registration - type,code,checksum - COA address - [BASE address] ? - sequence number (from MH to HAA) - MH authenticator to HAA o The HAA-BASE ack/nack message contains the following information. Agreement was reached on: HAA-BASE ACK/NACK - type,code,checksum - MH's IP address - sequence number - COA address - location_cache expiration time (from HAA to MH) o The BASE-MH ack/nack message contains the following information. o Default value for location_cache expiration timeout is infinity. HAA specifies a timeout value. Agreement was reached on: BASE-MH ACK/NACK - type,code,checksum - MH's IP address (in IP header) - sequence number - cookie value - location_cache expiration timer (from HAA to MH) - cell expiration timer (from BASE to MH) o We need to write down the risk assumptions for weak security and strong security. Agreement was reached on: - We are aiming for weak security at least. Strong security in the future. Weak security doesn't protect against snoopers. People who can eavesdrop when a packet takes the intended path can break security. But we protect against a random person anywhere breaking the security. - Steve Bellovin is our security consultant for mobile-ip. We need to get him more involved. - We need a liason between mobile-ip WG and a router company in order to check our ideas. Greg Bruell volunteered. (Not clear exactly what this means yet.) - We need a liason between mobile-ip WG and a NOS company in order to check our ideas. Steve Parker volunteered. (Not clear exactly what this means yet.) o Advertisement interval can be configured depending on the link layer technology. There is a tradeoff between the advertisement interval and the amount of bandwidth consumed. o Next we discussed what should happen when a data packet is tunneled to a BASE station that doesn't know where a MH is located. o Two possibilities are 1) a CH tunnels a packet to a old BASE station that doesn't have a forwarding pointer and 2) HAA tunnels a packet to the correct BASE station, but the BASE station has forgotten that it contains the MH. o In the first case, the old BASE station should send the packet to the MH's IP address. There is an issue of how we make sure that this packet doesn't get rerouted. If the MH is remote, the HAA will receive the packet and forward it to the correct BASE. o In the second case, the BASE has been told that the MH is in its cell. The BASE searches locally for the MH. One possibility is that the BASE sends out an advertisement message so that the MH will register. Since an advertisement message may be lost we may want to send this message periodically. o BASE should be able te authoritatively say that 'a MH is not here' to HAA. o In our model, the BASE is handling reregistration with HAA. Therefore we may need a `force through' bit so that BASE will reregister with HAA. Also, we may want reregistration to come from MH through BASE since we want a fresh authenticator. This needs more thought. o When a MH moves to a new BASE, the old BASE should at least be told that the MH has moved. o The unregister message contains the following information. Agreement was reached on: BASE-OLD_BASE UNREGISTER - type,code,checksum - MH's IP address - MH's cookie for old BASE - new COA address - [new BASE address] ? - forward_pointer hold tiem (upper bound) o If we want to do dogleg elimination, this message may need to be ack'ed. Agreement was reached on: - We need to look more carefully at how a MH behaves in home network vs. MH in foreign network o It is still an open on the exact packet formats and the protocol used in Advertisement/Solicit/Registration. If the protocol is UDP, then we need to decide on a well-known port number. Dogleg Eliminators Gave a Simple Dogleg Elimination Proposal Alan Quirt and Andrew Myles put up a slide each with an analysis of dogleg elimination. (Packet flow with ``='' indicates that packet is tunneled.) o For security, redirects must come from MH or HAA o Only HAA sees dogleg information without requiring an extra protocol. o Therefore redirects should be handled by HAA. o Dogleg routes packets as follows. CH ---> HAA ==> BASE ---> MH CH <--- BASE <--- MH o Optionally, a BASE can send a redirect to CH to get optimal routing. Since this redirect isn't authenticated, the CH would issue a challenge/response with the MH. Challenge/Response is a random number that is returned unmodified. CH <--- BASE (ICMP Redirect) CH ---> HAA ==> BASE ---> MH (ICMP Redirect challenge) CH <--- BASE <--- MH (ICMP Redirect response) o Now CH has a location binding for MH at the BASE address. So packets from CH to MH take an optimal path. CH ==> BASE ---> MH CH <--- BASE <--- MH o Since the redirect message is never trusted, it doesn't matter who sends the redirect to the CH. Terminology The group agreed on the following terminology. o Mobile Host o 1Correspondent Host o Ignorant Host o Home Subnet o Foreign Subnet o Home Agent (was HAA/Location Server) o Foreign Agent (was COAA/Base Station) o Triangle Routing (was Dogleg Routing) o Care-Of-Address (Address of Foreign Agent) The group needs to define the following terms. o Weak Security o Tunnel (v) Document Editor Charlie Kunzinger has volunteered as editor. He does not have a stake in any proposals. He is an experienced editor and tends to have a short turn around time. Instructions for Liaison activities (802.11) Charlie Perkins is the liaison between The MOBILEIP Working Group and the IEEE 802.11 subcommittee. It would be useful if the 802.11 could provide an indication of MAC address when a MH switches cells. Also, if 802.11 can provide cell arrival signals and cell departure signals we may be able to exploit them. Attendees Kannan Alagappan kannan@dsmail.lkg.dec.com Gregory Bruell gob@wellfleet.com Stephen Deering deering@parc.xerox.com Daniel Duchamp djd@cs.columbia.edu Jari Hamalainen jah@rctre.nokia.com David Johnson dbj@cs.cmu.edu Phil Karn karn@qualcomm.com Mark Knopper mak@merit.edu Charles Kunzinger kunzinger@vnet.ibm.com Brian Marsh marsh@mitl.com Greg Minshall minshall@wc.novell.com Andrew Myles andrew@mpce.mg.edu.au Steve Parker sparker@ossi.com John Penners jpenners@advtech.uswest.com Charles Perkins perk@watson.ibm.com Alan Quirt aquirt@bnr.ca Yakov Rekhter yakov@watson.ibm.com Shyhtsun Felix Wu wu@cs.columbia.edu Ruixi Yuan yuan@syl.dl.nec.com