2.5.2 IP Routing for Wireless/Mobile Hosts (mobileip)

NOTE: This charter is a snapshot of the 39th IETF Meeting in Munich, Bavaria, Germany. It may now be out-of-date.

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 for the IP Routing for Wireless/Mobile Hosts Working Group Meeting

Reported by: Steve Silverman and Steve Parker. Edited by Erik Nordmark.

Mobile IPv4 - Wednesday, Aug 13, 1997

I. Dave Johnson reminded everyone about MobiCom 1997 September 26-30 Budapest, Hungary

II. Jim Solomon reported that the PPP IPCP Mobile IP Option draft has passed WG last call in the PPPEXT working group.

III. RFC 2002 errors and ambiguities: Presented by Jim Solomon, Motorola.

The issues were sent to the mailing list prior to the meeting. The largest unclear issue is whether the SPI field included in authentication calculation. Charlie to issue a draft with bug fixes which will move to an updated RFC. The issue of the document name was brought up. The document should probably have IPv4 in the name. There is no update needed for RFC 2003. The issue of supporting multiple Care Of Addresses is something that will not be addressed by the new draft. It could be included in a new version of mobile IP.

IV. RFC 2006 (MIB) errors and ambiguities: Presented by David Cong, Lucent.

New ID to be issued, to hold information but not sent out for RFC. Will issue a new RFC when both RFC 2002 and 2006 are ready for draft standard. Most fixes are because of fixes in 2002. Editorial changes like adding a Table of Contents and fixing the default values and range definitions for various mib variables to be consistent with RFC 2002. The clarification of SPI in RFC 2002 implies that security is unidirectional which implies some clarifications to the security tables in the MIB. Clarification that the R bit is per interface, not per agent. Consensus that the maximum registration time configuration (maxAdvMaxRegLifetime) should be per mobile node. Need implementations of the MIB. One exists but not publicly available. Many people are interested (over 3) so testing can happen.

V. Interoperability & Deployment Experience: Dave Johnson, Carnegie Mellon Univ.

No experience to report yet but expected soon. Will deploy transparent switching to/from CDPD, Wavelan, and Ethernets. Intend to cover all campus except some dorms. Number of mobiles remains to be seen. David Reeder, Portland State Univ. Installed. Several HAs. One is in a classroom without physical connection, demos CAD. HA mostly for research and experimenting. Wavelan, each corner of building has transmitter. Can hear multiple FAs, choose best. Used over WAN. DARPA conference in Feb, FA running there, and some mobile nodes running off of that. Tunneled back to PSU. No filtering problems, since foreign had no filtering capability. Right now two HAs enough, small user pool (7 - 15 professors. Some grad students using it heavily.)

VI. Firewall Traversal Experience: Presented by Gabriel Montenegro, Sun.

Reported on a firewall traversal and reverse tunneling (without FA) interoperability test between Sun and Toshiba. The firewall traversal was using SKIP and not IPsec.

VII. Reverse Tunneling Security Issues: Presented by Gabriel Montenegro, Sun.

ID not submitted in time but mailed to list. Problem: An intruder can send a registration request to a FA with a fake Home Agent address. When using reverse tunneling this can cause all the MNs packets to be sent to a fake Home Agent. This can be used by attackers to either capture all the content of the packets sent by the MN or as a denial of service attack against the MN. Two variants depending on if the intruder sends the registration before or after the MN has sent its real registration to the FA.

Several alternatives to introduce cookies in the protocol:
· Sender-initiated Cookies - Send current and previous cookies in registration request to prevent hijacks. Requires that the either MN has stable storage to retain the previous cookie or the MN when rebooting can not register until the previous cookie has timed out.
· Receiver-Initiated Cookies FA sends in advertisements. Use cookie extension in registration reply. Prevents off-subnet nodes from registering with FA.
· Constant HA Reregister only on same HA. Might prevent failover to other HA.

Consensus to use TTL=255 for the registration request (when registering for reverse tunneling) to limits attacks to local nodes.

VIII. Tunnel Setup Protocol (TSP): Presented by Gabriel Montenegro, Sun.

IX. Tunnel Establishment Protocol (TEP): Presented by Pat Calhoun, 3com, and Charlie Perkins, Sun.

Features:
· Provides support for multi-protocol encapsulation
· Provides hierarchical registration

draft to come: draft-calhoun-tep-01.txt

New terminology:
· Targeted Tunnel Agent (like a HA)
· Requesting Tunnel Agent (like a FA)
· PDU Receiver (like a mobile node)

Issues:
· Problem with security using hierarchical registrations.
· Transitivity of Trust. Need point of trusted contract.
· Topology is not synonymous with security hierarchy. Nets might be willing to disclose the latter but not the former.

X. Security-Oriented Extension to Mobile IP (SOMIP) MC Chuah (Lucent) YZ Li (Bay) presented by Milo Osric.

Goals:
· Want to reduce frequent distant registrations.
· Prevent illegal use of routing service.
· Easier to handle security (more scalable)
· Interoperable with RFC2002.
· Separate registration and routing functions.

Mobile IPv6 - Thursday, Aug 14, 1997

XI. Announcement regarding firewall traversal - Steve Glass has an interesting idea for solving the problem of firewalls. Will send it to the list.

XII. Route Optimization in Mobile IP <draft-ietf-mobileip-optim-06.txt> Presented by Charlie Perkins, Sun.

Binding Cache Maintenance Smooth Handoff
· MN supplies Binding Update to previous FA to forward "packets in flight"
· Short timeout
· Registration Key required for secure operation.

Registration Key Acquisition
· Want to use SA's or public keys
· Diffie Hellman as a last resort
· Man-in-the-middle attacks - HA acts as KDC to prevent Bad FAs.

Discussion of various problems:
· Is HA the one to send Binding Update? Or FA?
· Comment: We should use IPSEC.
· Special Tunnels: to avoid routing loop, old FA tunnels packet to HA.
· Algorithm at Foreign Agent
· Advertise "S" bit for smooth-handoff-enabled
· Algorithm presented.
· Few people have tried to implement this.

XIII. Recent Changes in Mobile IPv6 <draft-ietf-mobileip-ipv6-03.txt> Presented by David Johnson, CMU.

· One implementation (CMU)
· In addition, two implementations barely started.

Overview of the resolved open issues

Dynamic Home Agent Address Discovery
· Home-Agents Anycast address for home subnet.
· One home agent is reached with the anycast and it returns an error code indicating that the MN should send another message with a specific address.

Issue: MN might need the addresses of all the HAs in case one of them is overloaded and will fail the registration attempt.
· Solve by having the HA that receives the anycast multicast to all the HAs on the link.
· Make it clear that the HA only relays valid and authenticated binding updates and not acts as a general forwarder of packets destined to the home agent anycast address.

The IANA and the IPNGWG have been asked for a well-known anycast suffix.

Uses IPSEC for replay protection.
· Sequence counter used for reordering of binding updates.
· Sequence counter 16 bits not 32.

New home agent address option:
· Binding Update must be authenticated.
· Home Address Option Security
· Home Address option does not need authentication unless the binding update option is already included in the packet.

Comment: Draft needs all exact packet formats with respect to the Home Address option to make it clear what the packet looks like when the transport pseudo header checksum is computed and when the AH computation is performed.

Comment: Home address option header (144 bits) will be compressible by IPv6 header compression.

Movement Detection Timing
· MN needs to know when it missed a router advertisement.
· Add indicator of Router Advertisement broadcast interval (missing in -03 draft)

Note: On Thursday there was consensus in the IPNGWG meeting on the use of the new home agent anycast address and requiring that all IPv6 nodes process the Home Address option.

XIV. Changes in IPv6 that might impact Mobile IPv6. Jim Solomon. The IPng WG is considering:

· Increasing the minimum link MTU to 1500-epsilon (enough to fit some encapsulation headers with AH/ESP)
· Add text specifying that the routing header MAY be reversed if authenticated.
· No consensus on "strict" routing header. Loose is what is left.
· Asked the WG to consider the impact (if any) on Mobile IPv6.

XV. Mobile IP vs. NAT (Native Address Translation) Boxes

Issue brought up by Charlie Perkins. NAT BOF last night. NAT boxes are selling well.
Home addresses are losing their meaning - implications for Mobile IP? One view: NAT may preclude full functionality.

XVI. Layer 2 Tunneling Protocol (L2TP)

Issue brought up by Charlie Perkins. Should this be considered? Only affects IPv4. 2003 is only being used by MIP. Chairs pointed out that a new WG is being formed to look at all tunneling (except IPv6 tunneling). Perhaps issues relating to L2TP should be discussed in that WG.

Slides

Security Oriented Mobile-IP
Tunnel Establishment Protocol
Tunnel Set-up Protocol
Reverse Tunneling
Route Optimization

Attendees List

go to list

Previous PageNext Page