CURRENT MEETING REPORT

Reported by John Zao, BBN Corporation

Minutes of the IP Routing for Wireless/Mobile Hosts Working Group (mobileip)

The MOBILEIP Working Group met twice on March 6th and 7th at the Los Angles IETF. The first meeting was focused on IPv6 mobility and the second was primarily concerned with IPv4 mobility. The organization of these minutes is by topic area: first IPv6 then IPv4.

IPv6 Mobility

The first meeting started with Charlie Perkins <perk@watson.ibm.com> presenting an overview of the working group's IPv6 Mobility draft, co-authored by Charlie and Dave Johnson's <dbj@cs.cmu.edu> (see draft-ietf-mobileip-ipv6-00.txt).
Mobile Nodes will be able to construct care-of addresses using IPv6 neighbor discovery protocols and obtain subnet prefix. Hence, they can be the natural end of IP tunneling or other form of packet redirection. Explicit FAs are no longer needed.
All IPv6 nodes will be mobility aware. This implies automatic route optimization and thus lightens the load of HAs.
CH can place the care-of address of MN in routing headers and compute the packet authenticator. Only HA needs to use IP encapsulation to effect packet redirection because it can not alter the authenticator.

IPv6 Mobile IP Requirements

Questions and Discussions:

Plenty of discussions arose on the issues of access control which led smoothly into the discussions of using Mobile IP with firewalls (the next agenda item).

An issue was raised in regards to accounting with the absence of explicit FAs. IPv4 enforces the use of an explicit FA to relay registration messages by setting the R bit in the messages. Similar mechanism was felt to be needed to perform access control functions. However, the general consensus prefers to deal with the problem as a security issue for assigning local IP addresses -- a DHCP problem rather than a MIP problem. Authentication methods should be built into the address assignment scheme and IPv6 routers should be able to recognize bad local address and drop the packets. The use of RADIUS Working Group technology was also suggested. All these provides only a philosophical framework for possible solutions; no solid scheme was proposed.

Firewall Issues

A lengthy discussion took place regarding the issues of packet passing to MNs through the firewalls. Two different problems were identified: (1) passing MN packets through the firewalls FROM the FOREIGN SUBNET, and (2) passing MN packets through the firewalls INTO the HOME SUBNET. The first problem seems to be more difficult although the two problems may be equivalent in some situations.

The difficulty of passing packets through the firewalls FROM the FOREIGN SUBNET is caused by the fact that firewalls drop packets which are not originated from hosts belonging to the local subnet, and the process will likely be performed without any warning such as ICMP error messages. The suggestion of hiding true source addresses of MNs will not work because future firewalls should be able to defeat similar host masquerading. The real solution can only come with embedding certain authentication tokens (negotiated between MNs and foreign firewalls) into the packets so that the identity of their true sources can be authenticated and accepted according to the security policy. The problem of passing MN packets through the firewalls INTO the HOME SUBNET is simpler because it should be easier for the MNs to set up certain mechanism with their home subnet so that they can authenticate themselves to the firewalls.

These problems were recognized as generally applying to host mobility, not limited to IPv6 Mobile IP. Hence, the Working Group was concerned, at one point, about the impact of the problems towards the standardization of IPv4 Mobile IP. Decisions were finally made that the firewall traversal issues will affect many protocols besides Mobile IP. The Mobile IP Working Group will thus produce a description of the problems and prepare to accommodate the future solution of the problems as they arise in the IPv6 community. An attempt to address the simpler problem of passing packets INTO HOME SUBNETS was also suggested.

Mobile Mesh Network BOF (added item)

Ran Orr <rorr@venice.sedd.trw.com> initiated a discussion on the relations between IPv6 Mobile IP and the work in Mobile Mesh Network (MMNet) BOF. With the recognition that the issues of MMNet form a superset of those of Mobile IP, the discussion was recommended to be conducted after the meeting.

Alternative Design of IPv6 Routing Header

Fumio Teraoka (SONY) <tera@csl.sony.co.jp> proposed a different design of IPv6 routing header which may help the MN packets to pass through the firewalls and leave the foreign subnets. His design exchanges the positions of MN's care-of address (COA) and home addresses in the IPv6 Header and the Destination Option Header:

As a result, the IPv6 Header will contain the local care-of addresses of MNs and hence may have less of a problem traversing the firewalls. It was noted, however, that firewall technology would likely adapt to this situation and restrict packets so constructed.

Discussions on firewall problems were triggered once again by the presentation and were centered around the effects of using different routing headers. Source routing will not work with firewalls; nor will simple encapsulation. Likely, packets needs to be tunneled through the firewalls by adding another level of encapsulation. Questions about special vs ordinary tunneling were also raised.

IPv4 Mobility

The second meeting of Mobile IP working group put its focus on IPv4 mobility. It was conducted with the following agenda:

Last Call for Discussions before Standardization of Basic Mobile IP

The Internet-Draft, "IP Mobility Support" <draft-ietf-mobileip-protocol-15.txt>, is in IESG Last Call for advancement to Proposed Standard RFC. At the meeting, a final round of discussion was called by working group Co-Chairman, Jim Solomon to address some concerns posted to the IETF mailing list. Explicit notification of the community about the final resolutions of these issues must be arranged before standardization of the protocol.

Concern was raised that MN may not obtain the next nonce value from HA if it moves from the FA before completion of current registration. MN would then have to use an old nonce in the next registration and thus caused a registration failure.

This problem was considered non-critical in all rapid movements among FAs for the new registration request will always be relayed by the new FA and cause the reply (of registration failure) to be send through the correct path, i.e. via the new FA to MN. MN can then extract the new nonce from the reply and obtain re-synchronization of nonces.

The only problematic case arises when MN travels back to home subnet before completing the last registration. Since the deregistration request will be sent from the home subnet with MN home address, the reply of failure will be sent to the old FA instead of the true location of MN.

A solution was suggested which requires HA to examine the source addresses of deregistration messages. If the messages are sent by MN directly then the replies of these messages will be sent to MN on the home network. In some implementations, this would involve temporarily brining down the MN's tunnel to send the registration request, and then reinstating the tunnel.

Definition of Start and End Time of Registration Periods

Since the delay between registration requests and replies is not always negligible comparing with the lifetime of registration, it is important to specify the start and end time of registration period, and determine when the MN should initiate a re-registration.

The discussion concluded that at the MN, the period should start at the time it sends the registration request, and end when the lifetime specified in the registration reply expires counted from the defined start. At HA, the registration period starts at the time the request is processed, and ends when the lifetime specified in the reply expires counted from the defined start. At the FA, it was suggested that the period should start when the request is forwarded and end when the granted lifetime expires, counting from the defined start time.

Broadcast / Multicast Preference Extension of Mobile IP [C. Perkins]

Charlie Perkins <perk@watson.ibm.com> and Baiju Patel <baiju@watson.ibm.com> proposed a Broadcast Preference Extension to the Mobile IP Registration Request message [see draft-perkins-mobileip-bcastpref-00.txt]. The extension allows a MN to specify the IP broadcast datagrams it wants to receive from its home network (via its HA).

The Broadcast Preference extension may be included several times within a single registration request; each selects a particular kind of datagrams that the MN wants to receive. The extension specifies conditions on the protocol number and the port number, which must both be satisfied by the datagrams before the HA should forward them to the MN. It also provides four flags: C (Clean), P (Permanent), A (Additional) and X (Exclude) to specify the action to the list of selected datagrams that is caused by the extension.

Comments were invited after the presentation especially on the additional constraints (beside of protocol and port numbers) necessary for selecting the broadcast / multicast datagrams. A question was raised by the audience on the difference between the use of P and A flags. The answer was that the selection marked by a P flag can only be cleared by an extension with C flag set while the selection marked by an A flag can also be cleared by an extension containing the same selection marked by an X flag.

PPP Mobility Extension of IPCP [B.Patel]

Baiju Patel and Charlie Perkins also proposed a new option called the Mobility Agent Configuration Option to the IP Control Protocol (IPCP) in PPP protocol suite [draft-patel-mobileip-pppext-00.txt]. The option allows a requesting peer to determine whether the responding peer is capable of and willing to function as either home or foreign agent of Mobile IP. From the transaction, the requesting peer can also obtain a care-of address from the responding peer.

The Mobility Agent Configuration Option will be sent by a PPP requesting peer with a valid IP address. When a PPP peer receives the option, it must respond with Configure-Ack, Configure-Nak or Configure-Rej to indicate if it can be a mobility agent and whether it will serve as a HA or a FA. In the FA case, a care-of address will also be dispatched.

After the discussion, there was a discussion on the proper order to send IPCP messages with Mobility Agent Configuration and IP Address options. It is recommended that a mobile IP peer should first try to use the Mobility Agent Configuration option and then the IP Address option, if necessary. There was some question as to the need for the Mobility Agent Configuration option.

Hierarchical FA and Regional Registration [C.Perkins & D.Johnson]

Increasingly, the Mobile IP community realizes the inefficiency of requiring the MNs to register with their HAs *every time* they change their FAs. The registration procedure may become too expensive (if the HAs are far away) or even impossible to complete (if partitions exist among networks).

Charlie Perkins and Dave Johnson <dbj@cs.cmu.edu> proposed two different schemes to enable regional registration using a hierarchy of FAs. Both schemes employ a tree hierarchy of FAs with each level of the hierarchy embedded in network regions with different granularity. When a MN moves between the regions, it can register only with the FA, which is at the root of the hierarchy including both its previous and current FAs, but not with its HA. The registration will be a local procedure if the movements of MN are minute. Charlie's and Dave's schemes, however, are different in their ways of establishing the hierarchy of FAs. In Charlie's scheme, the hierarchy is "static" with FAs being pre-positioned into every level of the hierarchy. In Dave's scheme, the hierarchy can be constructed "dynamically": MN can choose *any* FA in a network region as its primary FA; as the MN moves within the region, it will notify the primary FA of its current binding with new FAs known as the secondary FAs. In both schemes, new registration messages, security architecture and failure recovery mechanisms must be devised in order to guarantee robust operation.

In the discussion after the presentations, security (especially key management) was acknowledged to be a key issue in the development of both schemes. It was also pointed out that the biggest benefit of the hierarchical approach lies with the increase of maximum handoff rate; the total size of binding tables in all the FAs is actually increased not decreased with the introduction of the hierarchy. Finally, basic Mobile IP can be used to handle all the transaction between the primary FAs and the HAs.

Route-Optimized Mobile IP [D.Johnson]

Dave Johnson announced the release of a new Internet draft on Route-optimized Mobile IP [draft-ietf-mobileip-optim-04.txt]. New features in the draft include key distribution mechanisms between HA-FA and HA-CH and nonce dispatch mechanism.

The audience suggested the use of public-key certificates instead of bare public keys in all key distribution, and voiced concerns about potential security policy problems with the use of HAs as KDCs to dispatch keys between MNs and FAs. Charlie Perkins urged the group to put more effort into this protocol.

Route-Optimization with IP-squared Protocol [K.Okanoue]

Kazuhiro Okanoue <okanoue@nwk.CL.nec.co.jp> presented the design of an Internet router with agent functionality (A+R) and its use to perform route-optimized Mobile IP.

The router will be equipped with three additional functions: (1) MN location binding caching, (2) mobility security association with HAs, and (3) datagram encapsulation. It will be placed between CHs and MNs to tunnel datagrams from non-MIP-compliant CHs to the MNs.

In the discussion after the presentation, a doubt was cast as to whether such a router was already implied by the route-optimized Mobile IP. A closer look would be needed in order to understand the contribution of this work.

Secure Domain-Based Mobile IP [J.Zao]

John Zao <jzao@bbn.com> presented an ARPA-funded project at BBN to develop a scalable secure Mobile IP supporting fast mobility and access control.

The project aims at developing two pieces of technology: (1) a public/hybrid key management infrastructure which can be used to support authenticated location updates and secure IP tunneling, and (2) a domain based extension of the basic Mobile IP which can be used to both hide fast host mobility and conduct access control within the domain. The first technology will enable the secure use of route optimized Mobile IP among all CHs covered by the security infrastructure and the establishment of secure tunnels between MN-FA, FA-HA, MN-CH, etc. The second technology, which is similar to Perkins' hierarchical FA scheme, makes possible large scale and fast host migration in the global Internet. However, compliment to the other hierarchical FA development, this work focuses on the security issues of access control, domain-based key management and firewall traversal.

Ideas on a Firewall Traversal Extension [C.Perkins]

Realizing the pressing issues pertain to the use of Mobile IP among firewalls, Charlie Perkins presented his first ideas of a message extension for allowing datagrams from MN to pass through the firewalls in the foreign domain. Inclusion of the SPI of proper security associations was suggested. More work is definitely needed in this area.