Current Meeting Report
Slides


2.2.4 IP Routing for Wireless/Mobile Hosts (mobileip)

NOTE: This charter is a snapshot of the 53rd IETF Meeting in Minneapolis, MN USA. It may now be out-of-date. Last Modified: 07-Feb-02
Chair(s):
Phil Roberts <proberts@megisto.com>
Basavaraj Patil <basavaraj.patil@nokia.com>
Internet Area Director(s):
Thomas Narten <narten@us.ibm.com>
Erik Nordmark <nordmark@eng.sun.com>
Internet Area Advisor:
Thomas Narten <narten@us.ibm.com>
Mailing Lists:
General Discussion:mobile-ip@sunroof.eng.sun.com
To Subscribe: mobile-ip-request@sunroof.eng.sun.com
In Body: (un)subscribe
Archive: http://playground.sun.com/mobile-ip/
Description of Working Group:
The Mobile IP Working Group has developed routing support to permit IP nodes (hosts and routers) using either IPv4 or IPv6 to seamlessly "roam" among IP subnetworks and media types. The Mobile IP method supports transparency above the IP layer, including the maintenance of active TCP connections and UDP port bindings. Where this level of transparency is not required, solutions such as DHCP and dynamic DNS updates may be adequate and techniques such as Mobile IP not needed.

The WG moving forward will focus on deployment issues in Mobile IP and provide appropriate protocol solutions to address known deficiencies and shortcomings. For example, the wireless/cellular industry is considering using Mobile IP as one technique for IP mobility for wireless data. The working group will endeavor to gain an understanding of data service in cellular systems such as GPRS, UMTS, CDMA2000, and interact with other standards bodies that are trying to adopt and deploy Mobile IP WG protocols in these contexts. In order to provide a complete solution and a set of protocols that can be used as a roadmap for widespread deployment, the following work needs to be accomplished by this WG. In the near term, the WG needs to work on:

- Use of NAIs to identify mobile users/nodes.

- Specifying how Mobile IP should use AAA functionality to support inter-domain and intra-domain mobility.

- Develop solutions for IPv4 private address spaces for the scenarios needed for deployment.

- Documenting any requirements specific to cellular/wireless networks.

In the longer term, the WG needs to address:

- QoS in the mobile IP environment using diff-serv and/or int-serv/RSVP.

- Location Privacy.

The Working Group will ensure that solutions proposed for these problem domains are suitable for IPv4 and IPv6 respectively.

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.
Done   Submit the IPv4 Mobile Host Protocol to the IESG as a Proposed Standard.
Done   Submit the IPv6 Mobile Host Protocol to the IESG as a Proposed Standard.
Done   Submit Internet-Draft for NAI support in Mobile IP to IESG for consideration as a Proposed Standard.
Done   Review security framework requirements for Mobile IP.
Done   Review solutions and submit drafts for mobility in private address spaces.
Done   Supply AAA requirements for Mobile IP to the AAA Working Group
Sep 00   Submit the IPv4 Mobile IP Protocol to the IESG for consideration as a Draft Standard.
Oct 00   Review the WG charter and update as needed.
Dec 00   Develop an access technology independent method for supporting low latency handover between access points within an administrative domain or across administrative domains.
Jul 01   Review QoS in a Mobile IP enabled network.
Aug 01   Submit Mobile IPv6 MIB to IESG for consideration as a Proposed Standard.
Internet-Drafts:
Request For Comments:
RFCStatusTitle
RFC2005PSApplicability Statement for IP Mobility Support
RFC2004PSMinimal Encapsulation within IP
RFC2003PSIP Encapsulation within IP
RFC2006PSThe Definitions of Managed Objects for IP Mobility Support using SMIv2
RFC2356 Sun's SKIP Firewall Traversal for Mobile IP
RFC2794PSMobile IP Network Access Identifier Extension for IPv4
RFC2977 Mobile IP Authentication, Authorization, and Accounting Requirements
RFC3012PSMobile IP Challenge/Response Extensions
RFC3024PSReverse Tunneling for Mobile IP, revised
RFC3115PSMobile IP Vendor/Organization-Specific Extensions
RFC3220PSIP Mobility Support for IPv4, revised

Current Meeting Report

 IP Routing for Wireless/Mobile Hosts WG (mobileip)

Tuesday, March 19 at 0900-1130
===============================

CHAIR: Basavaraj Patil, Phil Roberts
Minute Taker: George Tsirtsis

1. Agenda Bashing, Basavaraj
Document status

Discussion about FMIPv4/v6. There is no progress at the moment.
There was some interoperability test for FMIPv6


2. Registration Revocation in MobileIP
The speaker solicits interest for the draft. Some private discussion has taken place but not much in the public domain. Show of hands for support of this work was requested.

Someone from 3GPP2 stated that this is one way of doing this but there are other ways too. A few people showed interest so the work will go ahead


3. Connectathlon Update, Samita
-Mobile Ipv6 draft version 15. 10 participants
No major problems were reported
3 implementations had support for authentication sub-option, no other
security mechanism was tested

Two Questions:
How useful is the "refresh" field in BAck? Should this be dropped?

Charlie: Suggest we make it an option since this is not always needed

-FMIPv6 Handoff
2 implementations

A number of issues will be sent to the mailing list by Alper Y.

-MIPv4
6 implementations

RFC3024 was implementated ut all missed the LPAS feature

No major issues


4. Mobile IPv6 Discussion
Phil R talked about MIPv6 security progress the last few months

4.1 MIPv6 Design Team - Jari
Draft was sent to mailing list a couple of days ago
-Pre16.txt is the actual spec, pre16.pdf describes the changes Draft version 17 will also be needed. Main changes are in section 4.4 and 5.1 There are now 5 messages needed but only 1.5 RTTs, 2 messages sent via two paths at the same time

Hesham: is it still worth making BUAck mandatory?

Jari: the issue will be taken into account

Charlie: We need to specify how long does the MN need to wait for the messages coming back

Francis: Verified/non-verified terminology should be used

Charlie: Mobility Header should be called Next Header Type

Erik: This may confuse because this is a terminal header for MIPv6. There is need for some text in the spec to clarify

Vijay: Shouldn't the Home Address in BU is a parameter rather than fixed?

Jari: maybe this is a good idea, take it off-line

Jari: Discussion about retransmission strategies is needed Discussion about the nature of the security association between MN and CN.

Francis: You need R-bit in the BU

Erik & others: this is taken out in earlier spec

Jari: Take it offline

Hesham: To protect the CN from DoS attacks the CN runs in stateless mode.

Isn't the MN vulnerable to the same attacks? The CN could be the bad guy

Jari: Someone needs to remember something and the MN benefiots mostly from this

Hesham: Yes but it is still a problem

Erik: So what is the concern?

Hesham: The CN can create state in the MN just by sending Binding Requests

Jari: Very little you can do about this

Erik: MNs could have intelligence to only do RO with CNs that make sense to do so

Hesham: Some text about this would be useful.

James: Have you done a stady on what the impact would be to create statefull CNs and stateless MNs as opposed to the other way around??

Someone: this is also allowed by the specs

Charlie: Draft 16 is interim.no one should implement this. Draft 17 will be the real one Jari and Chairs: YES!

Charlie: Are we really considering using IPSEC as the sole MN-CN BU auth mechanism? This is too heavy!

Hesham: This maybe used instead of HoA test

Jari: Maybe

4.2 Currently Open Issues in MIPv6 Base Spec
Erik N for the Design Team

-Many Editorial Issues
-Max Binding Lifetimes should be defined (5min?)
-State Tables for CN, MN
-Better Terminology for "RR Procedure" COT/COTI/HOT/HOTI
-Better names for message types

Charlie: Need to make sure we allow static security configuration for special cases

Thomas: Are you asking for the spec to say that the Bus can be secured by mechanisms outside this doc?

Charlie: we should say which bytes MUST be protected but the way this is done should not be restricted. In the IETF we define ONE way of securing the Bus but this should not be presented as the only one.

Someone: Agrees with Charlie

More Open Issues:
-Bit Method to prevent bidding down attacks

Malinen: wants this method to be in a different RFC. There could be other methods of expressing the fact that you do not want to do RR. Lets get a few ways and pick one.

Phil: This is a complex issue, There are arguments that this is needed in base spec

Pekka H: when we do Security engineering as opposed to normal protocol specification we specify that we MUST NOT do something. This has to be in base spec. It is not possibly to put in different document something that prevents something in the Base spec from happening.

Thomas: the Base spec needs to have code here so that all nodes supported otherwise it can never be used

Bob H: Are you suggesting the bit will say do not do RR but will not say what to do instead. Isn't this an attack itself?

Erik: Now all will do RR but when a new mechanism people will be able to use it. This is only for your own communication and does not affect others Bob

H: Concerns about the idea to reserve bits in interface ID of the Ipv6 address space. Addresses are defined as global/local/unicast/mcast etc.This is a peculiar use of this and in the future we could have other ideas that need the same.This may not be a good path to take

Malinen: There is need for this but the bit idea may not be the only one.Unclear at this stage

Raj: Is it not possible to deprecate RR altogether in the future?

Erik: You can not do that because it will have to be done in all nodes, all Internet

Malinen: the same was done with going from MD5 to HMAC in MIPv4

Erik: Yes but that does not affect CNs!


The IPv6 WG will discuss reserving bits for this in ther Ipv6 WG meeting in Thursday. We need to make the usage case in MIPv6

Issue: How and whether to authenticate the BA and BR

Should we add a nonce in BU which will be returned by BA/BR? Is this enough?

Vijay: For the BUAck you can use the same key you have for the BU. BR is different.

Hesham: It is not different because the CN can only send a BR after a BU has been received


Issue: Whether to authenticate to BM?
The BM can be spoofed by off-path attackers, which would cause some more work but no ill effects

Issue: Should HAO be used in the Home Registration or not?

Issue: How to secure home registrations, use ESP or AH?

Someone: If you use ESP how are you going to secure the CoA?

Vijay: You need to repeate the CoA in the BU itself, can not rely on the source address of the packet

Erik: Yes, that is right.

Issue: Is it useful to have an SPI field in the packet

It is not needed for RR but maybe could be added as an option by future mechanisms

Charlie: We need to allow manual and other mechanisms but the SPI could be an option

Issues will be sent to the mailing list for further discussion


5. LMM Requirements, Carl draft-ietf-mobileip-lmm-requirements-01.txt
Suggestion to move on the requirements document to last call.

Carl: Jari has one possibly new Security requirement

James: We need one solution on this.

Phil: Jari please post security requirements to the list. Also everyone check how the MIPv6 discussion affects this.


6. MIP/VPN Issues, Phil
draft-adrangi-mobileip-nat-vpn-problem-stat-req-00.txt
eFarid on VPN traversal for MIP

Phil: Is this a problem the WG wants to solve?

GeorgeT: The Work are needs to consider the larger picture i.e.: HA inside and outside of the firewall.

Someone: This is definatelly an issue and needs to be resolved.

Bob H: This is waist of WGs time. By the time this is really a problem you should be solving it with Ipv6

GeorgeT: This is also a problem for MIPv6

Someone: But then you do not have the NAT issue

Phil: George should propose extended scope for the work the list maybe split between NAT and Firewall traversal.


7. NAT/NAPT Traversal, Henrik draft-ietf-mobileip-nat-traversal-00.txt
Someone: There is at least one backwards compatibility issue

Henrik: Yes we know about this and we can consider it.

Phil: We will issue last call after the IETF

8. MIPv4/AAA Keys Open issues, Phil
Phil: some issues seem have to been resolved. Only issue is re-authentication

Charlie: all changes are in the last draft.

Phil and Charlie agreed that the changes are small enough that no new last call will be needed.

Slides

Agenda
Registration Revocation in Mobile IP
Connectathon 2002 Interoperability Testing Update
Overview of draft-16 for MIPv6
Issues beyond the base RFC
Currently Open Issues in the MIPv6 Base RFC
NAT Traversal for Mobile IPv4
Mobile IPv4 Traversal Across VPN Gateways
Localized Mobility Management Requirements for IPv6