Current Meeting Report
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:
Phil Roberts <email@example.com>
Basavaraj Patil <firstname.lastname@example.org>
Internet Area Director(s):
Thomas Narten <email@example.com>
Erik Nordmark <firstname.lastname@example.org>
Internet Area Advisor:
Thomas Narten <email@example.com>
To Subscribe: firstname.lastname@example.org
In Body: (un)subscribe
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.|
Request For Comments:
|RFC2005||PS||Applicability Statement for IP Mobility Support
|RFC2004||PS||Minimal Encapsulation within IP
|RFC2003||PS||IP Encapsulation within IP
|RFC2006||PS||The Definitions of Managed Objects for IP Mobility
Support using SMIv2
|RFC2356|| ||Sun's SKIP Firewall Traversal for Mobile IP
|RFC2794||PS||Mobile IP Network Access Identifier Extension for IPv4
|RFC2977|| ||Mobile IP Authentication, Authorization, and Accounting
|RFC3012||PS||Mobile IP Challenge/Response Extensions
|RFC3024||PS||Reverse Tunneling for Mobile IP, revised
|RFC3115||PS||Mobile IP Vendor/Organization-Specific Extensions
|RFC3220||PS||IP 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
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
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
A number of issues will be sent to the mailing list by Alper Y.
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
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
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.
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