2.5.2 IP Routing for Wireless/Mobile Hosts (mobileip)

NOTE: This charter is a snapshot of the 40th IETF Meeting in Washington, DC. It may now be out-of-date. Last Modified: 28-Oct-97

Chair(s):

Erik Nordmark <nordmark@eng.sun.com>
Jim Solomon <solomon@comm.mot.com>

Routing Area Director(s):

Joel Halpern <jhalpern@newbridge.com>

Routing Area Advisor:

Joel Halpern <jhalpern@newbridge.com>

Mailing Lists:

General Discussion:mobile-ip@smallworks.com
To Subscribe: majordomo@smallworks.com
In Body: subscribe mobile-ip
Archive: ftp://ftp.smallworks.com/mobile-ip.archive

Description of Working Group:

The Mobile IP Working Group is chartered to develop or adopt architectures and protocols to support mobility within the Internet. In the near-term, protocols for supporting transparent host ``roaming'' among different subnetworks and different media (e.g., LANs, dial-up links, and wireless communication channels) shall be developed and entered into the Internet standards track. The work is expected to consist mainly of new and/or revised protocols at the (inter)network layer, but may also include proposed modifications to higher-layer protocols (e.g., transport or directory). However, it shall be a requirement that the proposed solutions allow mobile hosts to interoperate with existing Internet systems.

In the longer term, the group may address, to the extent not covered by the mobile host solutions, other types of internet mobility, such as mobile subnets (e.g., a local network within a vehicle), or mobile clusters of subnets (e.g., a collection of hosts, routers, and subnets within a large vehicle, like a ship or spacecraft, or a collection of wireless, mobile routers that provide a dynamically changing internet topology).

Goals and Milestones:

Done

  

Review and approve the charter, making any changes deemed necessary.

Done

  

Post an Internet-Draft documenting the Mobile Hosts protocol.

Done

  

Review the charter of the Mobile IP Working Group for additional work required to facilitate non-host mobility.

Jul 96

  

Submit the IPv4 Mobile Host Protocol to the IESG as a Proposed Standard.

Dec 96

  

Submit the IPv6 Mobile Host Protocol to the IESG as a Proposed Standard.

Mar 97

  

Review the WG charter and update as needed.

Internet-Drafts:

Request For Comments:

RFC

Status

Title

 

RFC1853

 

IP in IP Tunneling

RFC2005

PS

Applicability Statement for IP Mobility Support

RFC2004

PS

Minimal Encapsulation within IP

RFC2003

PS

IP Encapsulation within IP

RFC2002

PS

IP Mobility Support

RFC2006

PS

The Definitions of Managed Objects for IP Mobility Support using SMIv2

Current Meeting Report

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

Recorded by: Yih-Chun Hu and Dave Maltz (CMU)

Edited by: Dave Johnson (CMU) with minor edits by Jim Solomon (Motorola)

I. Overview

The Mobile IP Working Group held one meeting during the week. The agenda was primarily devoted to Mobile IPv6, featuring a review of the changes to the Mobile IPv6 draft by Dave Johnson. Charlie Perkins reviewed some changes made to the Route Optimization for Mobile IPv4 drafts. Presentations proposing extensions to Mobile IP and future work were also made on the topics of Rapid Authentication, a Tunnel Establishment Protocol, and IPsec Tunneling for Mobile IP, by Luis Sanchez, Charlie Perkins, and John Zao, respectively.

II. General Announcements and Status Information

Gabriel Montenegro stated that the Reverse Tunneling draft is only awaiting the assignment of an extension number from IANA, and then it will go to Last Call. See draft-ietf-mobileip-tunnel-reverse-04.txt.

Mobile IPv6 still needs some IANA assignments, too. We need a Home-Agents anycast address, as well as option type codes for the Binding Update, Binding Request, Binding Acknowledgement, and Home Address destination options. Steve Deering is supposed to make this happen, and we are supposed to bug him about it until he does.

Dave Johnson announced that MobiCom'98, The Fourth Annual ACM/IEEE International Conference on Mobile Computing and Networking will be held October 25-30, 1998, in Dallas, Texas. Paper submissions are due April 21, 1998. For more information, see the MobiCom'98 web pages at http://www.mobicom98.utdallas.edu/.

III. Review of Changes to Mobile IPv6, Presented by Dave Johnson <dbj@cs.cmu.edu>

This presentation reviewed the changes in the Mobile IPv6 draft since the previous version of the draft. The changes are itemized in an appendix of the draft and were discussed in the meeting. The current version of the draft is draft-ietf-mobileip-ipv6-04.txt. Among the meeting attendees, only the CMU Monarch Project has implemented Mobile IPv6, and no attendees reported themselves as having an implementation in progress.

This version of the draft introduced a new mechanism to allow a mobile node to request its home agent to handle all home addresses for the mobile node, based on each of the prefixes believed by the home agent to be on-link. The new draft specified this by use of a new ID Length field in Binding Updates, but the consensus of the meeting was that this should instead be represented by a Prefix Length field. In an unresolved issue, the Binding Update format allows a mobile node to request forwarding for a single address, using a Prefix Length of 0, or for all addresses for the mobile node on its home network with each of the on-link network prefixes, using a nonzero Prefix Length. Since there can be only one Home Address extension per Binding Update, the only way to indicate more addresses for the mobile node (such as those acquired by DHCP, which differ in more than just the prefix bits) is to send multiple Binding Updates. There was no consensus on whether or how Binding Updates should be changed to allow the listing of more addresses as part of a single Binding Update.

Another issue that arose in the meeting was the exact rules for forwarding to a mobile node packets addressed to its link-local address or site-local address. The new draft specifies that such packets MUST NOT be forwarded, in order to avoid the confusion that could otherwise arise when such packets are forwarded outside their original scope.

On this point, Steve Deering noted that outside of the Mobile IP Working Group, there is widespread misunderstanding about what service Mobile IP is trying to provide. Is Mobile IP attempting to give a mobile node a virtual presence on the home network, or is it providing a forwarding service? The answer to many detail-oriented issues are based on the answer to this question. If Mobile IP attempts to give virtual presence semantics, home agents would have to act like bridges. Any packet that a mobile node would hear if it was attached to the home network must be forwarded to it. On the other hand, if Mobile IP attempts to give forwarding semantics, the home agent's actions cannot be described simply and must be enumerated in the drafts or refer explicitly to other IPv6 forwarding/encapsulation drafts.

The Working Group consensus is that Mobile IP provides forwarding semantics. The home agent is just a router with a physical interface and tunnels. The draft should make it clear that the home agent is not a bridge, and is not exempt from normal rules of IPv6 forwarding. Though some people want Mobile IP to provide virtual presence semantics so it looks as if they're always at home, it looks like this breaks too much of non-mobile IPv6's model.

Based on this consensus of the model provided by Mobile IP, we returned to the specific question of whether or not to forward packets addressed to a link-local or site-local address. The issue rests largely on the exact semantics of link-local and site-local addresses, which have not yet be finalized by the IPng Working Group. In particular, it's not yet clear whether a home agent can even tell by looking at an address whether or not the address belongs to the same site as the mobile node (and the home agent). A current Ipng proposal, though, says that if a node is communicating with another node inside the same site it SHOULD use that node's site-local address, if known. If so, however, then the language in the current Mobile IP draft saying that such packets MUST NOT be forwarded by the home agent, will break any connections with a mobile node if it moves away from home, if the connections were started while at home and connect with another node in the mobile node's home site. This issue must be resolved between the Mobile IP and IPng Working Groups.

As at least an interim solution, the Mobile IP Working Group decided that home agents MUST NOT forward packets sent to a link-local address, and MUST NOT forward packets sent to a site-local address unless the home agent is sure the mobile node's care-of address is still inside the same site. Jim Solomon asked if anyone had claims of IPR on the sequence number in Binding Updates since the semantics border on that of nonces -- something which IBM has previously asserted relevance to existing patents (cf RFC 2002). Dave Johnson explained that the sequence number is *only* a sequence number and is not involved in replay protection. It is only used in ordering Binding Updates, in exactly the same way as any sequence number, and so should not be covered by the patent.

The draft's description of the processing of the Home Address destination option is now complete, and must be checked out with an IPsec expert to make sure there are no conflicts. The basic end-to-end processing order is:

TCP -> Mobile IP swap -> IPsec -> wire -> IPsec -> Mobile IP swap -> TCP

The processing of a received Home Address option in a packet is described in the draft as a conceptual model. As an implementation issue, though, the CMU Monarch Project implementors reported that in processing a received Home Address option, they found it useful to physically swap the Source Address in the packet's IP header (the care-of address) with the Home Address field in the Home Address option, so that after the swap the Home Address option contains the care-of address and the IP Source Address field contains the home address. This preserves any ingress filtering protection as the packet travels up through protocol stack, since higher layers can still check the care-of address for sanity should they want to.

The draft is currently silent on the topic of mobile networks. There are two kinds of mobile networks: fixed-on-mobile, where a mobile router hides all mobility issues from a network of fixed hosts behind it that use it as their default router; and mobile-on-mobile, where a router, which is also a mobile node, provides router service to other mobile nodes (who have a home network elsewhere). The mechanisms described in the current draft support mobile-on-mobile correctly, without the draft specifically mentioning that it does so. Supporting fixed-on-mobile is harder. The draft needs to either explain or disclaim fixed-to-mobile networks. Perhaps we can simply adopt what is done in RFC 2002 for Mobile IPv4. This issue needs further consideration.

Receiving a packet containing a Home Address option MUST be supported by all IPv6 nodes -- that is, not just mobile nodes or home agents or routers, but ALL IPv6 nodes. However, the top two bits of the Home Address option type code must still be set to indicate what should happen if a node receives this option but doesn't recognize it. The draft currently specifies that these bits are set to cause such a receiver to return an ICMP "parameter problem" error to the sender (a mobile node), but the draft doesn't say what the sender should do when it receives such an ICMP error. It is unclear whether the sender should: (a) treat the destination as unreachable and log the error; or (b) try to talk to the correspondent without the Home Address Option, using its home address as the IPv6 Source Address, and realize that its packets have some likelihood of being dropped by ingress-filtering routers.

IV. Rapid Authentication for Mobile IP, Presented by Luis Sanchez <lsanchez@bbn.com>

The idea behind this presentation was to find a scalable approach to authentication, since we may need to authenticate to nodes other than the home agent. If that happens, we need scalability. The only way to authenticate to arbitrary nodes is to use public key methods, but such methods have high computation cost. If a mobile node is moving fast, it can't do a public key exchange fast enough when moving into new domains. The approach described here is to do the public key exchange once, and then to get tickets that allow you to move around the domain without need of further public key exchanges.

This rapid authentication scheme has three goals. First, to be compatible with the standards track Mobile IP protocols. Second, to improve the efficiency of mobile nodes to move around inside an administrative domain; there is no intent to make the first authentication faster. Finally, rapid authentication avoids requiring trust across boundaries.

The protocol uses an extra code in the foreign agent Advertisement to indicate that the foreign agent supports rapid authentication and can act as a Rapid Key Distribution Center for the mobile node while the mobile is visiting the administrative domain. The security associations developed by the Rapid Authentication protocol are in a separate PK_KEY class from standard IPsec security associations.

Source code for the system should be released soon. Also, although the slides in this presentation were marked "BBN confidential", the speaker stated that they were in fact not confidential.

V. Tunnel Establishment Protocol (TEP), Presented by Charlie Perkins <cperkins@eng.sun.com>

The idea of TEP is based on a tunnel protocol for Virtual Private Networks (VPN). Some people want multi-protocol tunneling, multilevel security domains, VPNs, etc., and the IETF is generating many tunneling protocols. TEP's goal is be a general protocol to set up all tunnels. TEP is designed to allow a multi-protocol tunnel agent (like a Mobile IPv4 foreign agent) to request a tunnel on behalf of some node (like a Mobile IPv4 mobile node) that doesn't need to participate in the protocol. TEP is designed so that the constructed tunnel is bidirectional.

The designers want to take the experience from Mobile IPv4 in RFC 2002, and add elements to obtain extra functionality. They plan to use the same ports and basic registration methods as Mobile IP, with new extensions.

Some changes in terminology were suggested to make the protocol more understandable. The following terms map roughly into the given Mobile IPv4 entities:

targeted tunnel agent == home agent
requesting tunnel agent == foreign agent
PDU receiver == mobile node

TEP also includes provisions for a hierarchy of foreign agents, in order to reduce the number of packets that must travel to/from the home agent when the mobile node is making local moves between foreign agents which are in the same or nearby domains.

VI. Route Optimization in Mobile IPv4, Presented by Charlie Perkins <cperkins@eng.sun.com>

This presentation described some of the changes made recently to the Route Optimization extensions for Mobile IPv4. The Route Optimization draft has now been split into three separate drafts:

Registration key establishment has little to do with the Binding Cache, but has lots to do with establishing security associations. This draft now needs feedback from security experts.

It was pointed out that during the editing changes, the drafts' descriptions of when and how to send Binding Updates were removed, and need to be added back. Note also that the Route Optimization extensions are being redesigned to more closely follow the protocol model designed for Mobile IPv6, and these revised drafts do not yet completely reflect that redesign.

VII. IPsec Tunneling for Mobile IP, Presented by John Zao <jzao@bbn.com>

Most of the previous work in this Working Group has dealt with how to secure the control traffic of Mobile IP. There is another part of the Mobile IP traffic that may need to be secured --- the tunneled packets. The questions are should we protect the tunneled packets, and if so, where should we add IPsec protection to do so? IPsec needs to be married to Mobile IP so it doesn't add an extra header, since there's already a tunneling header used for Mobile IP.

This presentation proposed using IPsec at every tunnel, and negotiating the tunnels via the normal Mobile IP control messages. A new IPsec tunnel extension would be added to the Registration Request and Reply messages, and flags would be used to select tunnel parameters, like is currently done for GRE and Minimal Encapsulation.

David Reeder noted that Portland State University already has an implementation of Mobile IP that does most of this, except for advertising the possibility of IPsec tunneling in its Agent Advertisements. See http://www.cs.pdx.edu/research/SMN/ .

Slides

IPSec Tunneling for Mobile IP
Johnson Presentation - ipv6
Rapid Authentication (RA) Mobile IP Security (MoIPS)
Regkey
Route optimization
Spec Tun
Tunnel EST protocol

Attendees List

go to list

Previous PageNext Page