INTERIM_MEETING_REPORT_ Reported by Alan Quirt/Bell Northern Research Minutes of the IP Routing for Wireless/Mobile Hosts Working Group (MOBILEIP) An interim meeting of the Mobile IP Working Group was held at Qualcomm in San Diego, Monday and Tuesday 21-22 February 1994. These minutes mainly summarize the decisions of the meeting. It is not practical to report all the discussion, but where it was lengthy some of the main alternatives are mentioned. Goal of the Meeting The goal is to complete the Internet-Draft for Mobile IP, with group consensus, and publish it promptly after the meeting. This draft, with any changes resulting from discussion through the mailing list, should be presented to IETF in Seattle in late March, for the standards track. (An alternative was to issue an immediate Experimental RFC for Mobile IP, planning to enter the standards track next year. This was rejected because it would delay the final standard. Implementation can proceed just as soon based on an Internet-Draft.) Administrative Matters Our editor, Charlie Kunzinger, has resigned. (Thanks, Charlie, for your hard work.) Bill Simpson, our new editor, hopes to have the meeting draft out by 5 March. The editor and chairman will obtain a well-known UDP port number for control messages, an IP protocol number for encapsulation, and two multicast addresses for beacons and solicitation. (Several attempts were made to reopen the question of using ICMP for beacon and solicit messages, but many felt that old issues should not be reopened. UDP supporters emphasized ease of implementation on top of existing commercial protocol stacks.) Charlie Perkins brought to our attention United States Patent 5,159,592 which was filed by him in October 1990 and assigned to IBM. It describes a method of issuing temporary IP addresses from a pool, and a gateway for wireless mobile hosts. Several earlier patents are cited in it. It could have some impact on the current Mobile IP design. Charlie agreed to investigate whether IBM will make the patent available ``for a reasonable fee, on a nondiscriminatory basis.'' Security Because of recent widespread passive attacks via the Internet, security was a major topic of the meeting, and strongly influenced other areas. Wireless operation may increase eavesdropping risk, but the wired Internet can no longer be trusted much more. We quickly agreed that the privacy of message content is a separate end-to-end issue, outside the scope of Mobile IP. We will use the IP Security Protocol and its successors when they are available. Our security goal is to ensure that our protocols do not give outsiders any easy way to redirect a mobile host's traffic. We must also ensure that we do not depend on information that would be hidden by IP security. The meeting agreed that the minimum acceptable security must include a way for a mobile host and its home agent to authenticate each other's messages. Today this can be done most easily using a strong hash function such as MD5, with a manually configured shared secret key. This allows only authentication of messages between the mobile and its home agent, including the important case of passing a binding (a pairing of a mobile with a care-of address) from the mobile to the home agent. It is no help in authenticating the messages between mobile and foreign agents that were necessary to establish the binding. Sometimes there will be methods outside of Mobile IP to increase the security of those messages, such as the authentication protocols in recent wireless standards. If stronger security is essential, secret keys can be manually configured between mobiles or home agents and the foreign agents that they use. (A clever scheme presented by John Zao (see mailing list Mobile IP 831) offered a way of creating session keys, but could not fully authenticate foreign agents. It also perhaps increased the exposure of the shared secret between home and mobile. The consensus was to not use this scheme in its present form.) Here and throughout, public key certificates would allow easier authentication of all parties in Mobile IP, and secure distribution of shared session keys. However, patent and export control issues are delaying the creation of an Internet key management system. The consensus was that we needed a practical level of security now, with provision for easy extension once a key management system is available. The following list of points was suggested for Mobile IP security. Most items seemed to be generally acceptable, but the meeting did not formally adopt the list. 1. Algorithm-independent support for keyed cryptographic checksums or digital signatures for authentication. This requires authentication fields in type/length/value format, where the type indicates algorithm. For now, both the algorithm and key can be manually configured. Later, a list of supported algorithms will need to be sent in an initial setup message, and negotiate the algorithm to be used. 2. Mobile host and home agent must support at least MD5 with 128-bit keys using manual key distribution. These keys must be supplied, but default values might be acceptable in some controlled environments. 3. Foreign agents must support at least MD5 with 128-bit keys using manual key distribution. Such keys are configured on a per-mobile basis. Agents are allowed to serve mobiles with which they do not share a key. 4. All registration messages must be authenticated whenever a shared key exists between the parties. This implies that all messages between mobiles and their home agents must be authenticated. 5. The sequence number field in existing messages should be extended to 64 bits to allow optional use of time stamps in NTPv3 format, for increased security against replay attacks. 6. It would be helpful in the long term to add a ``home agent'' record to the Domain Name Service. Today such records would not be believable, but with a future DNS that enforces authentication, they would be a handy way to get or check a mobile to home agent binding. 7. Fields that must be covered by an authentication checksum include: type, op-code, addresses and address-lengths, service-life, binding-life, sequence number, and perhaps IP options. 8. We need at least one new reply code: ``Service Denied, Administratively Prohibited.'' 9. Because key management is harder for them, foreign agents should be lightweight. They should take few actions on their own. For example, they should never revoke a binding to a previous foreign agent on their own. They may forward registrations or revocations from the mobile or the home agent, either of which might be able to authenticate the request. 10. There should be only one binding lifetime, applying to both home and foreign agents. A value of zero for any lifetime should mean that the binding is denied or revoked. A value of all-one-bits should indicate an indefinite lifetime. (There was considerable discussion of how many binding lifetimes are needed. Should a mobile's binding to a foreign agent have just one binding-lifetime at both home and foreign agents, or should it have two? If there is only one lifetime, all (re)registrations must go to both the foreign and home agents. That increases traffic, sometimes over a long path. If there is one lifetime, the packet format, the protocol, and time-out handling are simpler. As no clear resolution was reached, the provision for separate time-outs in the December draft will presumably be kept.) 11. There may be situations where a mobile wishes to tunnel all of its outgoing packets back through the home agent, to conceal its location from outsiders. The present protocol does not support reverse tunnels, but it would be easy to add later. Routing Optimization The meeting reluctantly agreed that: o The ``weak security'' model proposed in earlier drafts is unacceptable in the new, harsher Internet environment, and o Stronger security is impractical without a key distribution service. All routing optimization will be removed from the base protocol. Dave Johnson, Andrew Myles, and Charlie Perkins agreed to edit a separate RFC defining experimental extensions to Mobile IP for routing optimization. They will include strong authentication for use where suitable key distribution is available. There will also be warnings of the security risks involved in accepting unauthenticated routing optimization messages. Separating the routing optimization will make the base document shorter and easier to read. The optimization may or may not be folded in at a later date. Either way it is intended to become an official part of the standard once Internet key management makes it practical to authenticate routing messages. Meanwhile the experimental protocol can be used in safe isolated networks to gain experience. [Comment that had to be preserved: It is painful to have your packets trapped in a route canal :-)] Encapsulation The encapsulation method for complete IP packets will be based on the IMHP scheme, which adds only 12 bytes of header to each packet (only 8 bytes if the original sender is the tunnel source). The header for fragments will include full IP header information; this can probably be treated as a variant of the IMHP encapsulation protocol rather than a separate protocol. Only IP packets are handled. (A warning was given, based on experience, that multiple encapsulation should be avoided. It creates a risk of recursive encapsulation when a routing loop occurs. Based on this warning, it may not be a good idea to re-encapsulate other protocols already tunnelled inside IP.) Multiprotocol Encapsulation Some people need to tunnel a protocol such as IPX or AppleTalk all the way to a mobile host. The foreign agent cannot be the end of the tunnel because it does not know the other protocols (though it may be involved for billing and beaconing), so the mobile must obtain a temporary IP address using DHCP or some other means. The encapsulation protocol could be GRE or something equivalent. The relationship between this multiprotocol encapsulation and Mobile IP has not been worked out. ``Pop-ups'' Pop-ups are mobile hosts that ``pop up'' on a remote subnet that has no foreign agent. They obtain a temporary address by any available means (such as DHCP or manual assignment) then act as their own foreign agent. They use normal Mobile IP protocols to the home agent. Because they share a secret key with the home agent, their messages can be authenticated. (There would be advantages to eliminating foreign agents as tunnel endpoints. Protocols and authentication would be simpler, and it would be easier to tunnel non-IP protocols. However, a pool of available mobility addresses would be needed for every subnet. Foreign agents are also essential for beaconing, and useful for packet redirection when routing optimization is used. In commercial networks they might be involved in billing. The consensus was that foreign agents as currently defined are essential today to conserve address space, but their role should be reconsidered after IPng is deployed.) Ad-hoc Networking Several mobile hosts (typically with wireless networking support) may be near each other but not near a wired network. A suggested solution is to simply let a mobile host respond to an ARP request, without concern for matching high order address bits, in that situation. Multiple Agents A mobile could potentially have multiple home agents if several routers into its home subnet were capable of acting as home agents. For greater robustness the mobile might maintain a list of home agent addresses, each with a secret key for authentication. However, only one such agent would normally be active at a time. (This is a complex area needing more design work. For example, Mobile IP does not define any mechanisms by which multiple home agents can properly synchronize their state.) Since registration with a foreign agent and revoking a previous registration are separate operations, a mobile could be served by more than one foreign agent at a time. This would allow softer handoff when a mobile is moving from one wireless coverage area to another. To support this feature, the home agent would have to maintain a list of active foreign agents for each mobile, and forward each packet to all of them. Existing higher layer protocols should be capable of eliminating any duplicate or reordered packets that the mobile receives. Agent Advertisement It was agreed that the beaconing and solicitation parts of Mobile IP would be modeled very closely on the existing router advertisement protocol, including a name change from beaconing to advertisement. However, the actual protocol will be new, because different information is needed in the messages, and because we use UDP not ICMP. Both home and foreign agents may advertise similarly. If an agent has multiple addresses, only one will be advertised. (Some felt that home agents should not advertise.) Returning Home It was agreed that on returning to its home address, a mobile need not specifically register with its home agent. As soon as the mobile has revoked all foreign registrations, the home agent should cease forwarding packets addressed to the mobile, and should use a gratuitous ARP on the mobile's behalf to clear obsolete ARP caches. Higher Layers There should be an appendix with hints for higher layer protocols in a mobile environment; for example, there should be a way to configure longer default time-outs. Mobile Subnets There was some discussion of the possibility that a registration might represent the location of a whole subnet (where a subnet is the thing you get by combining a netmask and an address) that moves together, perhaps on an airplane or a ship. It was suggested that we try to find a good way to express this situation. It may affect only registration messages. Detailed Study of Draft All of Tuesday afternoon was spent on a section-by-section examination of the existing draft, in the light of the earlier decisions. With the elimination of route optimization, many sections were dropped. Since the revised draft will be available shortly after these minutes, no details are recorded here. Attendees Kannan Alagappan kannan@sejour.lkg.dec.com Randall Atkinson atkinson@itd.nrl.navy.mil Stephen Deering deering@parc.xerox.com Pierre Dupont dupont@mdd.comm.mot.com Richard Fox rfox@metricom.com Scott Hinnrichs smh@netserv.com David Johnson dbj@cs.cmu.edu Phil Karn karn@qualcomm.com Charles Kunzinger kunzinger@vnet.ibm.com Tony Li tli@cisco.com Gabriel Montenegro Gabriel.Montenegro@eng.sun.com Andrew Myles andrew@mpce.mg.edu.au Sanjiv Nanda nanda@hocus.att.com Steve Parker sparker@ossi.com John Penners jpenners@advtech.uswest.com Charles Perkins perk@watson.ibm.com Alan Quirt aquirt@bnr.ca Joel Short jshort@CS.UCLA.EDU William Simpson bsimpson@morningstar.com Jim Solomon solomon@comm.mot.com Fumio Teraoka tera@csl.sony.co.jp John White jccw@mitre.org John Zao zao@das.harvard.edu