Last Modified: 2004-06-24
draft-ietf-mobileip-ipv6-24 (RFC XXX) and draft-ietf-mobileip-mipv6-ha-ipsec-06 (RFC XXX)
The protocol as specified in the above two documents can be considered as the baseline or minimum protocol set for implementing IPv6 mobility. During the development phase of the base protocol, a few additional features were identified as necessary to facilitate deployment (described below).
The primary goal of the MIP6 working group will be to enhance base IPv6 mobility by continuing work on developments that are required for wide-scale deployments. Additionally the working group will ensure that any issues identified by the interop testing of the MIPv6 specifications are addressed quickly. Specific work items with this goal in mind are listed below:
1) Create and maintain an issue list that is generated on the basis of interop testing and address these issues as enhancements to the base protocol
2) Features such as renumbering of the home link, home agent discovery, Route Optimization, which are currently a part of the base specification can be specified more explicitly as separate specifications. This will also enable modularizing the Mobile IPv6 specification further into the minimal subset and add-on features. Some of these specifications will be identified as base mechanisms of Mobile IPv6.
3) A number of enhancements to basic IPv6 mobility were identified during the development of the base specification. These enhancements will be taken up in a phased manner depending on the priority identified with each. Below are listed the work items to be taken up by the WG:
- A bootstrap mechanism for setting up security associations between the Mobile Node (MN) and Home Agent (HA) that would enable easier deployment of Mobile IPv6. This bootstrap mechanism is intended to be used when the device is turned on the very first time and activates MIPv6. The WG should investigate and define the scope before solving the problem.
- Improving home agent reliability: in the event of a home agent crashing, this would allow another home agent to continue providing service to a given mobile node.
- Support for a Mobile Node changing its home address, either because of renumbering in its home network or because it periodically changes addresses (perhaps via RFC3041)
- Route optimization will require security mechanisms for trusting and updating the binding information.Return-routability is the basic mechanism for route-optimization. Mechanisms using a shared secret Key/Security Association will be considered. Methods for establishing a security association between the mobile node and the correspondent node are out of the scope of the WG.
- The working group will also document problem statements associated with deploying Mobile IPv6 in the following areas: a. Mobile IPv6 issues in the presence of firewalls b. Mobile IPv6 deployment and transition issues in the presence of IPv4/IPv6 networks c. Multicast issues
It should be noted that there are potential optimizations that might make mobile IP more attractive for use by certain applications (e.g., making handovers "faster"). The latter category of optimizations is explicitly out-of-scope at this time; this WG will focus on issues for which there is strong consensus that the work is needed to get basic mobility deployable on a large scale.
| Nov 03 | Problem statement documents (to IESG): (1)- Issues with firewall; (2) - Mobile IPv6 transition between v4/v6 networks | |
| Jan 04 | Bootstrapping problem statement to IESG | |
| Feb 04 | Submit MIPv6 MIB to IESG | |
| Mar 04 | Alternate Route Optimization scheme to IESG | |
| May 04 | Home agent reliability to IESG | |
| Aug 04 | Bootstrapping solution to IESG | |
| Nov 04 | Separate specs for Home Agent (HA) Discovery, Route Optimization, Renumbering to IESG |
| RFC | Status | Title |
|---|---|---|
| RFC3776 | Standard | Using IPsec to Protect Mobile IPv6 Signaling between Mobile Nodes and Home Agents |
| RFC3775 | Standard | Mobility Support in IPv6 |
|
Mobile IPv6 (mip6) meeting minutes
IETF 60, San Diego #################################################### # Session 1 of 2 # # Tuesday August 3rd, 2004 from 9 AM - 1130 AM # #################################################### ============================================================== Thanks to Samita Chakrbarti, Nick Moore and Gabriel Montenegro for taking the minutes. ============================================================== 1. Agenda and Document status updates - Basavaraj Patil - MIP6 base specifications have been approved as PS RFC3775 and RFC3776 - API and RO-Sec documents have completed WG LC. A few issues identified and these are being tracked via the issue tracker Revised IDs will be submitted to ADs. - MIB document being reviewed by MIB doctors. To be submitted to ADs following the review. - Bootstrap design team completed work on the problem statement. I-D published as WG document (draft-ietf-mip6-bootstrap-ps-00); Discussion archive is available (http://vesuvio.ipv6.tilab.com/pipermail/mip6-boot/); Future discussion on MIP6 ML. - Two new wg drafts draft-ietf-mip6-auth-protocol-00.txt draft-ietf-mip6-nai-option-00.txt - Mip6 issues with firewalls Revised version published; Will be published as WG I-D after ietf60 - Use of IKEv2 for setting up the MN-HA SA required for MIP6 Issues tracker for WG docs: http://www.mip4.org/issues/tracker/mip6/ All WG I-Ds are expected to use this issue tracker. ********************************** 2. Discussion on ro-sec doc - Gabriel Montenegro - Update: LC Completed; I-D pursued as Informational. - Closed issues: o Improvement to spurious BUs o Passive attack against privacy o Presentation of ingress filtering o Issues with IPSec related text in intro o Caveat about questionable assumption o Thanks to Francis Dupont for very helpful comments o DNSSEC bashing o Added different home-addr and coaddr check. More tweaking is perhaps needed ********************************** 3. Bootstrapping problem statement - Alpesh Patel - Definition of the problem: obtaining enough information to setup SA with home agent, home-address, home agent. - Goals and non-goals are discussed. Adv: minimize pre-configuration, obtain hoa dynamically, anchor to HA dynamically, possible integration with AAA - Scope of the problem stmt and various scenarios were discussed. o Mobility service suscription o Integrated ASP network o Third party MSP o Infrastructure-less scenario ( out of scope of this doc) - Seed information: - FQDN of HA, MN's NAI and shared secret with AAA or public key (digital certificate) - Next steps: - Fix editorial comments from design team, more comments should be posted in the wg. No issues by DT. Christian : Any evaluation made on EAP or existing soln? Ans: Solutions have yet to be evaluated. Current discussion focused on problem statement only. Erik : Requirement of access authentication for access network? Piggybacking is not desirable and wrong path to follow. Ans: Could piggy back bootstrap info when changing access network (Patil, Alpesh, Jim) Narten : How often do we bootstrap? Bootstrapping does not need optimization Ans: Depends on the deployment scenarios. Could be just once or every time a mobile node powers up etc. Majid : looking for solution? Is this group chartered with AAA solution Ans: AAA is one solution. Various approaches are being evaluated. Jari: Separate out access network and service network authentication Alper: Bootstrapping for LMM scenario is required Vidya: Since it is auto-config it should belong to zeroconf Christian: MIPv6 is already complex - leave the document for flexibile solutions. Jim Kempf - This is no theoretical physics. We have to use based on what people are using today. This document is a good start. Gopal : Please send comments on this doc to ML. We will have revised doc by next IETF ********************************** 4. MN-HA authentication presentation - Alpesh o draft-ietf-mipv6-auth-protocol - Changes since last version was discussed MN-HA authentication options and MN-AAA options were discussed - Solution: o new Mobility options during BU - MN identification option - MN-HA and MN-AAA authentication options triggers AAA interaction HA-HAAA - response in the BAck - Pros: o minimum over the air signaling o ease deploymenbt: nai and auth infrastructure same as IPv4 o SDO's such as PP2 require this option - Next steps: Add clarifying text in sec considerations clarify MN-AAA authetication option clarify the usage/details of identification option Christian: The design should not specify a new protocol. Use existing protocols like EAP. No need to invent a new one. - this assumes there is only one round trip - should not have this constraint - protocol should allow several round trips - just embed EAP and be done with it Charlie Perkins - not anything new, this is just the same as MIP4 - but don't like the ID option used for replay protection cuz this is provided by the BU anyway Vijay: - no need for ID option for replay protection, sequence number in the BU is enough Hannes - even SDO's might want to use UMTS-AKA or some such for wlan internetworking and this requires 2 round trips, so you should also support that Lots of pushback from Francis and others on these drafts assuming the MN won't use IPsec. Pete McCann - make sure it's clear that RO is not possible with this draft, for that you do require IPsec Samita - why did we go through all the trouble of spec-ing IPsec if we now backpedal Patil : We are doing this draft because it would be ease deployment of the protocol. Draft version 15 discussed a similar mechanism. Yoshiro from Toshiba - no talk about rekeying, why not? Ans from Kuntal: in PP2 we do rekeying on a per-session basis Jim K : To be honest, 3GPP2 and 3G vendors need this. We should listen to our customers. Have it reviewed by Sec directors. Charlie : Problem with identity option Parviz Y- If there is nothing wrong in the sec. mechanism in this draft then please move this ID fast as 3GPP2 has deadlines Narten - expressed concern on adoptability of IPsec if IETF keeps allowing alternative approachs. Patil - It is critical for Mobile IPv6 deployment Consensus Question: Should the WG take up this work item? Consensus sought on the I-D. No clear consensus achieved. Consensus to be taken up on the mailing list. ********************************** 5. NAI extension - Alpesh Patel o draft-ietf-mipv6-nai-option - No open issues known to the author. - Alper's request to extend it contain FQDN info. service enabler: NAI Charlie: not comfortable with elevating this to the stature of THE internet identifier Kent: this is to easily obtain an optimal HA Vijay: applicability is limited to the authentication option draft, not useful beyond that. NAI is user identity only useful within AAA infrastructure ??: some existing identities (e.g., IMSI) don't fit into the NAI format (not supported by the BNF) Samita - the draft should clarify if the NAI option would be applicable for other business models. If the answer is yes, then it makes sense to proceed with this draft. ********************************** 6. Pre-configured Kbm between MN and CN - Charles Perkins o draft-ietf-mip6-precfgKbm Testing Care-of-address - requires new sub-section or new draft. It can co-exist with the existing Route optimization mechanism. Should the pre-Kbm draft be expanded to allow CN to demand coa test ? Kbm then becomes a preconfigured home keygen token, so that terminology in the draft should be changed. Added testing CoA's by signaling that this is required and the CoTI/CoT exchange. Care-of keygen token from this; Home keygen token using preconfig secret betwe MN and CN; In this case, the Kbm is really a preconfigured home keygen token Francis: care-of test problem is something he also has with IPsec MN-CN draft and have several solutions possible propose to have a document on how to do CoT initiated by CN Vijay: agree Francis: yes, make it a separate document/mechanism Should all BUs contain nonce-indices option for consistency? Jari- We have multiple mechansim to do RO security mechansim. This draft does not need to support all the options. Charlie's draft comments will be taken into ML ********************************** 7. Use of manually configured IPsec SA between MN & HA - Vijay Devarapalli - Rfc3776 supoorts both manual and dynamic IPSec keying - Manual IPSec Keying for Mobile IPv6 - What is dynamic IPSec keying? IKE - MIPv6 3GPP2 adoption: o IPSEC w IKE o Mobility option auth protocol - PP2 uses stream ciphering algorithms for all encryption cuz they're more efficient over wireless, so they use AES-CTR Francis: AES is NOT a stream cipher, it is a block cipher. And IPsec does not use stream ciphers, only block ciphers. ********************************** 8. Remote testing status at IPv6 plug test - Patrick Guillemin - Origin Madrid IPv6 summit may 2003, first remote IPv6 plug tests - 20 registered companies, but only few people used this. How many people read the draft ? Should this test continue? Vijay- This is very useful - we should continue with this. Basavaraj requested Samita And TJ Kniveton to revise the draft-kniveton for interop testing. TJ acknowledged on the microphone. ********************************** 9. MIPv6 authorization using EAP - Gerardo Giaretta I-D: draft-giaretta-mip6-authorization-eap Advantage : no changes in AP Both Radius/Diameter can be used between NAS and AAA server MN-HA IPSec SA can be setup from keying material exported by the EAP Next step: Extension of I_D for IKE auth ********************************** 10. Using IPsec between Mobile and Correspondent IPv6 Nodes - Francis Dupont No questions or issues. The whole issue of RO and what schemes should the WG take up needs to be revisited. ********************************** 11. Load Balance for Distributed Home Agents in Mobile IPv6 - Hui Deng o draft-deng-mip6-ha-loadbalance Traffic between MN-HA would be loadbalanced. HA will pro-actively notify MN about the change and new HA More improvement is needed for SA and HA handover messages B. Patil : Do we need a load-balancing solution in IETF ? If bootstrapping is considered for load-balancing, then we can first see how that solution becomes applicable to load balancing. Load balancing is not that critical ********************************** 12. Problem Statement for MIPv6 Interactions with GPRS/UMTS Packet Filtering - Xiabao Chen - Potential issues for MIPv6 deployment in GPRS/UMPTS were discussed including 3 scenario cases. - It is an individual draft - the author asked if this should be submitted as RFC. Jim Kempf - This is an implementation problem. Should take it to 3GPP. Speaker - We are not trying to solve it at IETF. But this is for information and raising awareness. ********************************** 13. Applying Cryptographically Generated Addresses to Optimize MIPv6 - Jari Arkko Note: ( Ericsson is working on IPR issue) Techniques employed - CGA - Home routing while moving ( less pkt loss) - Minimal address testing (smaller latency) - significant signal reduction -- reduction of the latency -- Improved security Jim Kempf : Issue: every CN would have to implement this option Jari - It is optional for improvement of latency Chairs (B.Patil) : We should step back and see if we are able to produce multiple authentication scheme for RO. Jari : CGA is quite stable and we need to get to RFC to use them. ********************************** /////////////////////////////////////////////////////////////// / / / End of Session 1 of 2 / / / /////////////////////////////////////////////////////////////// #################################################### # Session 2 of 2 # # Tuesday August 3rd, 2004 from 5 PM - 6 PM # #################################################### 1. Roadmap for MIPV6 -- Gopal Dometty WG doc status auth drafts - Get consensus & issue last call prefcfg Kbm close issues mipv6-mib Last call after MIB expert review ietf-mip6-ro-sec closes issues mip6api proceed to IESG Work under consideration for WG status: -MIP6 bootstrap solutions -Firewalls problem sttmt -MobileIPv6/v4 interop -Use of IKEv2 for seting MN-HA SA Discussion on reqirement and scope: -Alternative RO scheme -MIPv6 integration with AAA infrastructure -HA load balancing/reliability -Mipv6 location privacy Jari Arkko: (Bootstrapping problem comment) should be possibility of alternative themes. Erik Nordmark: We should propose some alternatives to routing optimization security. Jari Arkko: no harm in designing alternative schemes, there is space for them. No-one's going to be hurt by alternative schemes. James Kempf: Is route optimization on our charter. (Erik: yes.) JK: Then I'm in favour of it but it should be a background item. Gopal D: charter identifies one solution, doesn't necessarily exclude others, but ... JK: if charter is ambiguous it should be updated. ********************************** 2. Carl Williams: IPv4/IPv6 interoperability for mobility. George Tsirtsis: Problem statement since a year ago. Some comments incorporated but no comments since February. Can this become WG draft? Raj: can we get a consensus? (not many people have read it) Chairs: please resubmit and we'll take it from there. ********************************** 3. HeeJin Jang: DHCP Option for HA Discovery o draft-jang-dhc-haopt Jari Arkko: is it mandatory to send the MN identifier in response to the DHCP server? You're trying to skip the ocnfiguration of some of the parameters by getting from DHCP server, but that means adding a new parameter. Alper Yegin: In the current impl. its mandatory for node to provide, Raj: is there any validation, security WRT who's requesting? Alper: example is incomplete, in the base MIPv6 RFC there needs to be authentication, we need to fold auth into DHCP we're hoping to use existing DHCP auth but somehow we need to map. Jari: it's not too dangerous to give the address of the HA to anyone who asks ... if you're doing bootstrapping you're missing security association. Alper: We've presented to DHCP, but DHCP WG needs MIPv6 to ask for it to be included. James Kempf: We've discussed whether this is for local HA or remote HA is there any distinction made. Alper: Yes, the MN has a way to convey which it is asking for James: useful for local HA, Charlie Perkins: about identifier, isn't it going to have a hard time picking remote HA without identifier. Is this just for local HA? If you want to get some kind of remote HA you're going to need id. There's an alternative AAA method. Alper: Like MIPv4, and 3GPP has decided to use DHCP. Ralph Droms: is that so? James: that's because they don't have EAP. Ralph: MIP6 vs DHC working group: DHCP working ground is responsible for the syntax, we work in collaboration with another WG which is responsible for the semantics: should this be a MIP6 or a DHCP WG item. Raj : Where is the configuration information actually stored, only in the local or only in the home network how do you retrieve that unless id ... Alper: this mechanism is not supposed to change the DHCP routing. information should already be at the server it'd normally contact. Ralph: if there's an oracle someplace through which we can get HAgent for all home networks into all foreign networks, device could get home information on foreign systems. But how is it distributed. Pascal T: this draft may be very useful for local info for LMM. ********************************** 4. Bootstrapping using Radius - Kuntal Chowdhury I-D: draft-chowdhury-mip6-bootstrap-radius-00.txt Pascal: everything done in MIP needs to be redone in NEMO so you get prefixes as well, could you extend this draft to think about NEMO. Vidya: thinks its important to work on both DIAMETER and RADIUS. James K: realistically, people are using RADIUS, DIAMETER would be good I don't like the idea of having the attributes be the HAddr as such. we should use EAP? If we decide to go with hop-by-hop security we'll regret it. Kuntal: there is an option to use end-to-end. so far we did not decide. JK: point is you've got to roll some custom auth, why not just use EAP. Kuntal: whatever, as long as you can get authed Jari: it seems that you are defining attributes not new RADIUS commands, with that in mind it seems existing rad -> dia methods should work. Ralph Droms: you mentioned the DHCP RADIUS option, my view: the existing agent option is not designed to put new info into a DHCP server which is carried to client, it lets DHCP server choose from its provisioned information ... Kuntal: when I wrote draft (missed ...) JK: that's a pretty big change in the DHCP arch. chairs would have to work out if they want to do it. Charlie P: we have AAAv6 submitted for consid by MIP but went to AAA and they didn't want it either ... if we're going to look at this we should consider AAAv6. Erik: you're assuming AAA home and routing home are same admin domain. if that isn't the case you'd need some other bootstrapping. potentially my AAA home is diff to my routing home. Alper: in response to james: although you can get end-to-end using EAP there are two problems, it's not used in all access nets and you need some sort of bucket in EAP and that's not in all EAP. Samita: can you use prefix length instead of prefix in message to save some bytes. ********************************** 5. Certificate-based Binding Update Protocol (CBU) - Jianjing Zhao I-D: draft-qiu-mip6-certificated-binding-update-01.txt Raj: consensus call: base spec has RR has auth, there are now alternatives. should the WG consider alternative schemes. Charlie: how is this to be partitioned between this group and mobopts. if mobopts comes up with a scheme should it go into this group or stay in mobopts. Raj: yes, if they got some numbers they could move into this WG. Jari (JA): as an example ... Charlie P: it was in this charter because it was removed from this draft at the last minute. Raj: so do we open it up? JA: as a practical datapoint, we have IANA considerations in the RFC, must be standards track to allocate numbers ... James: hows an MN supposed to know what technique its going to use. we should have it figured out. Thomas: if somebody wants to do experiments why do they need new code points. what is the criteria to decide when to go forward with a route optimization scheme. Raj: ... thus MobOpts. JA: we want to deploy, and we already have two methods (so floodgates already open) Erik: if the goal is to think carefully before have >1, its' odd that there's already 2, but 3,4,5 can't happen. Should be a more level playing field. Vijay D: Can we assign experimental numbers then? JA: about this level playing field, does this prevent the adoption of other RO schemes? JA: I don't think there interop issue here, we can always fall back to base RR ... Thomas: if you've got one mandatory and one on the side its easy enother, Francis D: its in the charter to investigate shared key. Nick Moore: is it we (mip6) or we (mobopts) who will take up this work? /////////////////////////////////////////////////////////////// / / / End of Session 2 of 2 / / / /////////////////////////////////////////////////////////////// |