CURRENT_MEETING_REPORT_ Reported by Jim Solomon/Motorola Minutes of the IP Routing for Wireless/Mobile Hosts Working Group (MOBILEIP) Joint Meeting of the MOBILEIP and IPNG Working Groups The two groups met on the morning of Tuesday, 18 July. This meeting was co-chaired by Jim Solomon, co-chair of the MOBILEIP Working Group, and Ross Callon, co-chair of the IPNG Working Group. Introductory Remarks The co-chairs took turns introducing the output produced by their respective working groups. Jim Solomon first introduced the primary requirements of the IPv4 mobility protocol: (1) mobile nodes must be able to communicate using only their (permanent) home IP address; and (2) mobile nodes must be able to inter-operate with the enormous installed base of (non-mobility-enhanced) IPv4 hosts and routers. A brief outline of the architecture of IPv4 mobility was also presented. Ross Callon then introduced IPv6, highlighting the differences between IPv4 and IPv6. Ross noted that there is no installed base of IPv6, thereby relaxing the second criteria of IPv4 mobility and increasing the possible solution space for IPv6 mobility. A fundamental choice for the design of IPv6 then becomes: should IPv6 be a direct ``port'' of IPv4 mobility or should IPv6 mobility be designed in such a way as to take advantage of the new functionality that IPv6 contains (as compared to IPv4). Presentations Fumio Teraoka presented his proposal for IPv6 mobility; one based upon the VIP concept put forth in his IPv4 mobility proposal [1]. This proposal optimizes routing to mobile node by having routers on the path between home agent and mobile node learn and cache the (authenticated) binding between a mobile node's home address and its current location. Concerns were raised about the amount of processing required by routers in the Internet due to the presence of a hop-by-hop option in all mobile registration packets. In particular, the routers must verify an RSA digital signature in addition to processing the contents of the packet to obtain the desired location bindings. Dave Johnson and Charlie Perkins presented their proposal for IPv6 mobility [2]. This proposal leverages off of the ``route optimization'' work within the Mobile IP group for IPv4. This proposal optimizes routing to mobile nodes by having correspondents (i.e., those host and routers actually communicating with a mobile node) cache the mobile node's current location, tunneling packets directly to the mobile node's current care-of address. The Johnson/Perkins proposal involves using an IPv6 destination option to provide address bindings to correspondents. Open Discussion The floor was opened to comments from the community at large. The consensus seemed to be that: 1. Mobility for IPv6 should leverage off of the new functionality provided by IPv6, rather than being a ``direct port'' of IPv6. 2. Mobile IPv6 should be ``owned'' by the MOBILEIP Working Group and no new working group needs to be formed for Mobile IPv6. If necessary, the Mobile IP charter will be expanded to reflect this decision. 3. Due to the fact that IPv4 mobility is being delayed by patent concerns, now would be a great time for someone with an unencumbered proposal for IPv6 mobility to step forward. Tuesday Afternoon -- Mobile IP(v4) Based upon the results of the morning meeting (joint with the IPng Working Group), the chairs have an action item to review the Mobile IP charter and determine whether it must be expanded to include responsibility for IPv6 mobility. Patent Issues IBM has provided a statement viz. Charlie Perkins' patent -- the terms are ``reasonable and nondiscriminatory'' as required by RFC 1602. However, the terms are neither ``free'' nor are they a flat fee. At the request of the co-chairs, Joel Halpern (Routing Area Director) has requested funds from ISOC for legal counsel to investigate the scope of infringement of the current working group draft. One possible outcome of this investigation is that the counsel might suggest that the amount of exposure of the mobile IP protocol could be significantly reduced by eliminating certain ``features'' of the protocol (e.g., MN de-tunneling its own packets by obtaining a local COA; and replay protection using nonces). Implementation Reports Several working group members are implementing and/or have implemented the protocol. Anders Klemets has an implementation (MN, FA, HA), running under SunOS v4.1.3 that he is willing to provide people wishing to perform beta testing. Contact him at if you would like a copy. Interoperability Testing Plans When enough people have brought their implementations up to Version 11 of the draft, interoperability testing will proceed (hopefully by late August). Frank Kastenholz of FTP Software will check into the feasibility of hosting an interoperability shindig. Otherwise, Charlie Perkins of IBM indicated a willingness to do likewise. Specification Issues A) Prefixes in Agent Advertisement. The consensus is that these are sometimes useful to MNs, thus we have decided to include them as an option in agent advertisements. The option will contain one prefix for each router address present in the ``base'' portion (i.e., the RFC 1256 portion) of the advertisement. Tony Li will provide text for this to the editor. B) UDP Ports viz. authentication. In the general case, the HA does not know the source port used by the MN for the registration request, therefore it is impossible for the HA to verify the authenticator. Furthermore, it was deemed that the threat of not including the UDP ports in the computation of the authenticator was minimal. Thus, the authenticator(s) will now be computed over only the Mobile IP portions of the packet; equivalently, the authenticator(s) will not be computed over any portion of the UDP header. C) TTL: Is the tunnel 1 hop or N hops? The argument for ``1 hop'' is that it provides no loss of connectivity to a mobile node when it is away from home. The argument against it is that making the tunnel ``1 hop'' inevitably requires placing a larger TTL in the encapsulating (outer) header than that of the original datagram. After a long discussion, the only consensus that was reached was that Mobile IP should learn from the operational experience of the MBONE and ``do what mrouted does''. [I suspect that the group needs more discussion about this on the mailing list. -- Jim Solomon] D) The working group agreed that the draft needs a ``wholesale'' rewriting in order to make the draft more comprehensible to those that have not followed Mobile IP for years. Note that the changes here are all editorial and that changes in content will only be those reflecting the consensus of the group at the meetings and on the list. E) Gratuitous Registration Reply from HA to old FA. Anders pointed out that there is a correctness problem with the protocol in that a stale entry in an (old) FA's visitor list makes it impossible for that FA to communicate with an MN which moves to and registers with a (new) FA. Ensuing discussion revealed that there is a trivial denial-of-service attack possible by sending bogus registration replys to an FA, convincing the FA to remove the MN from its visitor list. Thus, the group decided that gratuitous registration replies should only be sent to the old FA if the HA shares a security association with that FA, implying that the FA/HA authenticator can be used. Similarly, the FA should ignore a registration reply that is: (a) not prompted by a corresponding registration request; or (b) does not have a valid FA/HA authentication extension. This restricts the potential attackers to be those devices on the media that the MN is visiting. Several working group members pointed out that, due to the presence of protocols such as ARP, any nodes on the mobile media can wreak similar havoc using alternative mechanisms and that we are not making the problem any worse. Wednesday -- Mobile IP(v4) Specification Issues -- Continued F) The topic of MN/FA and FA/HA authentication was raised yet again in reference to eliminating these authentication extensions and using the IPSEC authentication header instead. This proposal was rejected due to uncertainty in the time-frame for IPSEC and, perhaps more importantly, the fact that it is less work to implement the extensions once the (mandatory) MN/HA authentication extension is implemented. G) It was proposed that an MN be able to provide a broadcast ``filter'' to let the HA know which broadcasts it is interested in (e.g., a specific IPPROTO number, or a specific IPPORT number, etc.). The group consensus was that a mechanism to support this functionality should not be part of the base specification and that those requiring this functionality should submit an Internet-Draft specifying its operation. H) Noting that the current working group draft contains three authentication extensions, yet only one key identifier extension, the group decided that a mechanism must be provided to apply a key identifier to all of the authentication extensions. It was decided to integrate a Security Parameter Index (4 bytes) of identical syntax and semantics to the SPI used in IPSEC into each of the respective authentication extensions. The extensions now look as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | SPI .... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... SPI (cont.) | Authenticator ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ See the IP Authentication Header document [3] for more information on the use of SPI's. Route Optimization Dave Johnson explained his and Charlie Perkins' proposal for route optimization in IPv4 mobility [4]. The proposal involves a mechanism for distributing authentic binding information to the nodes which require it, mitigating to some extent the key-management difficulties. The authors stressed that the need for feedback on their proposal from the members of the MOBILEIP Working Group. References [1] ftp://cnri.reston.va.us/internet-drafts/draft-teraoka-ipv6-mobility-sup-01.txt [2] ftp://cnri.reston.va.us/internet-drafts/draft-perkins-ipv6-mobility-sup-02.txt [3] ftp://cnri.reston.va.us/internet-drafts/draft-ietf-ipsec-auth-02.txt [4] ftp://cnri.reston.va.us/internet-drafts/draft-ietf-mobileip-optim-02.txt