Last Modified: 2004-10-15
| 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 |
|---|---|---|
| RFC3775 | Standard | Mobility Support in IPv6 |
| RFC3776 | Standard | Using IPsec to Protect Mobile IPv6 Signaling between Mobile Nodes and Home Agents |
|
Minutes of MIP6 WG meeting
-------------------------- IETF61, Washington DC Nov 12th, Friday 2004 9 AM - 1130 AM Chairs: Basavaraj Patil and Gopal Dometty Minutes provided by: Samita Chakrabarti and John Loughney 1. Agenda bashing and WG doc status update ------------------------------------------- - MIPv6 Socket API - completed last call - now on AD review - Firewall issues I-D completed LC - MIP6 MIB status: MIBdoctor pass1 completed; pass2 ongoing - TAHI test suite will release version 3.0 in December which is fully compliant with RFC3775/3776 URL: http://www.tahi.org/mipv6/ 2. Auth I-D discussion ---------------------- A consensus call on standardizing this I-D was held on the WG ML. Chairs believe consensus was to progress the I-D as a proposed standard. An issue tracker for the I-D has been created. Comments are welcome. Thomas Narten: There is an appeal to the Consensus call result now. Consensus was rough, nice if it was clearer. We don't formally vote. Packing the room is something to look for, but lurkers can be informed / posters can be uninformed. Counting company votes is dangerous. Question / choices: 1. Do not publish at all - has consequences for the relevance of the IETF 2. Publish on standards track - sends signal that this has IETF support 3. Publish as info - Does get IETF review & has been done in other cases, e.g. - 3GPP James K - has interoperability concerns, but if just for 3GPP2, then its OK. 3GPP2 has come to the IETF, so we should do it. Concerned about standards track, because it might cause interoperability issues due to multiple mechanisms. Would like MIP community to work better with 3GPP2. Thomas Narten - we've had a relationship for 3 years with 3GPP and have engineer to engineer working, agrees that would be nice to have with 3GPP2. Basavaraj - disagrees that there will be interop problems. People who want to deploy it are from 3gpp2, but could have wider possibly applicability. Haven't heard about what the concerns of folks who don't want this work to be standardized. Pervez Yegani - 3GPP2 needs this work, working with Thomas on liason statement. Doesn't see an interop issue. James K - Explained twice already. IETF can specify two mechanisms, but operator can deploy just one. If you have a terminal that supports both mechanisms, it may be confused which one can be used. Problem is a deployment. Hesham - it's not an interop problem but a deployment problem. In similar circumstantes, sometimes a higher order mechanism is needed for negotiation. Wants third option. Gopal - Disagrees with James. We cannot control deployments. This is not 3GPP specific. Thomas - should be careful about calling it an interop problem. Its not black or white. It might be that 3GPP2 wants to avoid the IPsec mechanism. There can be a cost with multiple mechanisms. Eric Nordmark - unwise to have multiple mechanisms; we will have to implement both or circumstances will not work. Thinks that some assumptions are wrong. If we have multiple mechanisms, then we should have a good reason for this. Basavaraj - saying that the HA will need to implement both, terminal will only need one. Jari Arkko - it doesn't have to be a weaker option. interop issue - distintion is that 2 random nodes will authenticate to each other. Pete McCann - this mechanism is needed to interface with existing credentials, removed IPsec from current architecture because IPsec / IKE v1 cannot interface with existing credentials James - thinks we should go back to 3GPP2 and get them to find out about what is needed for IKEv2 Someone - wonder if this could be handled in IPv6 host or MIPv6 host. Pervez - only argument we have heard against this is interoperability. Don't we have rough consensus. Thomas - we don't vote, some people are debating the validity of the consensus. Pervez - from the business perspective, saying it won't interoperate isn't convincing. Basavaraj - doesn't see the benefit of publishing this as info. Greg Daley - tried to stay out of this discussion. Thinks we need encryption between the HA & MN, but how to get the key? Thinks we should work on this, doesn't care about the status of the document, but would like do work on this. We need an AS on this mechanism. Concerned that the Security Area will barf on this. Thomas - 3GPP2 needs this soon, so we need to complete this. Greg - then we need to get people involved in it. Concerned about there is no ESP here. Need a checklist for this. Need strong applicability statement on the features - multicast traffic might be spoofed, etc. Gopal - if we do go info, we will have deployment, then future work can be dependent on it. Thomas - thinks this will be an ongoing topic for discussion. Pascal - thinks there is an impact on other MIP related topics. We will have 2 solutions on the handset. Thomas How many people don't want it at all - noone Do this as a standards track - 9 Publish as informational - 30 Greg Daily- Release this as an experimental doc, but work on it still. Thomas Narten- reasonable to pub as info, but work on it still Hesham - can't have a contract promising anything, shouldn't be a problem releasing it as info. Thomas Narten - 3GPP2 would prefer standards track. Pekka Savola - we cannot make a contract, publish as info/exp. because of timing requirements, and then analyze the problem more. 3. IKEv2 on MIP6 (Vijay Devarapalli) ------------------------------------- I-D: draft-ietf-mip6-ikev2-ipsec-00.txt RFC3776 describes IPsec on MIP6 Changes in IPsec architecture (2401bis), and IKEv2 - New draft to incorporate these changes - SPD and SAD config and packet formats - required processing steps on the MN and HA - describes the use of IKEv2 Key negotiation - Manual keying must be supported Dynamic keying though should be supported Dynamic key shoud or may? Comment - do you mean public key certificate? - we have manual key for pre-shared key Jari Arkko: The draft talks about how to use IKEv2 but this is optional- no need to support it. In that case there is no issue. SPD config New selectors Mobility header msg type ICMPv6 message type If IPsec specifieds mobility header as a selector, then MIP6 should support it. Question: How do you make interfaces of IKEv1 and IKEv2 work together in IPsec? Vijay - The new IPsec will not be interoperable with the older one Hesham Soliman - Are we going to step away from per-interface SPDs Moving away from current interfaces is a good move. Vijay - We still need to distinguish payloads in different cases, tunnel, without tunnel etc. PAD configuration Peer auth data base provides a link bet key protocol and SPD SAD config Use of IKEv2 to negotiate keys MN initiates IKEv2 exchange Identity is included in IKE_AUTH Use of EAP - MN indicates it wants to use EAP by leaving IKE_AUTH field unfilled IKE_AUTH should be done after EAP exchange Issues - takes 4 round trips instead of 2 - Should work with other EAP and AAA-HA interface - Should we say HA MUST/MAY require this interface? Home address configuration: Must or May ? Jim Kempf - It should be "SHOULD" Erik N. - It looks like a bootstrapping solution. It should be linked with bootstrap to have a single solution Jari Arkko - thinks bootstrapping support here is a good thing. 4. Using IPsec to protect signaling between MN and CN (Francis Dupont) ---------------------------------------------------------------------- I-D: draft-dupont-mipv6-cn-ipsec-01.txt Presented at the last IETF Idea : When you have IPsec bet, CN and MN, just use it Has some details in the doc what is suitable. You need SA between CN and MN etc. Question: - Should it be WG item ? - Seperate doc for the cookie-based COA test? (optional) - Implementations(already one, others?) Vijay - Will support it to become WG doc Jim Kempf - We should think about how it interacts with Mobike. We should make this as wg draft. Suresh - It should be a wg document B Patil - Anyone has objection to make it wg doc ? If not we make it as wg doc No objection was raised at the meeting. 4a: (Francis Dupont) ------------------- COA cookie test - Initiated by CN , usable by CN which does not have built-in COA test/trust - A state cookie is used in order to avoid DOS attacks - non-empty IANA consideration section Next step: Which RO protection mechanism do we need? Vijay - it can be an optional care-of-addr test WG item? More discussion needed before we make a wg doc. Christian V: We had mailing list discussion but it modifies the way base spec does. Jim Kempf - We should be more systematic in thinking about one solution or piecemeal soln Erik - Don't see how we tie in with RO cookie test. If the threat is third party bombing attack, then how does it help? What are the security requirements? Jari - I'd rather have Charlie's draft do COA addr test. Also take a look at the draft we produced in Mobopts 5. AAA AND MOBILE IPV6 (Giaretta Gerardo) ----------------------------------------- 5.1 I-D: draft-giaretta-mip6-aaa-ha-goals-00.txt & I-D: draft-yegin-mip6-aaa-fwk-00.txt Motivation: Dynamic MIP6 conf MN-HA sec association AAA-HA interface - Interface between AAA of the MSP and HA (HA is a kind of access server) Basic security model MN --------------------MSP AAA -----------------------HA Usage scenario - bootstrapping directly with HA MN -----NAS------AAA-MSP-----HA Junghoon - Given EAP exchange is there any network access server? We first need to have access through NAS then the second step Ans:It is a direct interaction with HA Pete M : We can separate out network access from MIP access. We should not tie them together. Junghoon : What is the meaning of performing IKEv2 before network access service ? If a MN can access(like, performing IKEv2) the visted domain network without granting the network access, it can result in a possbile attack to that network. Usage scenario 2 MN --- NAS--------AAA-MSP -------------HA <-------piggybacked MIp6 within EAP -> <---AAA-HA ------> A) <-- PANA, L2 DHCP extension->< RADIS/DIA-><---AAA-HA--> B) Hesham - Make it generic Comment - Focus should not only focus AAA-HA protocol, but also NAS-MSP-AAA Greg D - Did not read the draft. If you have security across NAS, AAA-MSP, HA- Do you already have security association between MSP and HA? Hesham - This is a good way to use IPsec in MIP6 James - This solution is not going to work if you don't have AAA infrastructure Usage scenario3 MN---------NAS_____________AAA-MSP -------HA <IKE--------------------------><---AAA-HA---> <--BU?-------> Goals: Security, Accounting etc. Next steps Should we identify a protocol that fulfil the goals? DIAMETER, RADIUS, SNMPv3 Similar draft by Alper on AAA-HA interfaces - Raj has sent out the pointer to the slides. In the interest of time, the draft was not presented. Raj described briefly the highlights of Alpers I-D. Hesham : What is the requirement? - Should the requirements go to AAA, midco m ? No reason to put requirement for midcom wg James Kempf - likes this, would like to remind people that there are hotspots without link security and authenticates via web page. This solution won't work if you don't have a AAA infra. Should we work on this? Hesham Soliman - what is the intention of this? Basavaraj Patil - development requirements for AAA work. 5.2 MIPV6 AUTHORIZATION AND CONFIGURATION BASED ON EAP ------------------------------------------------------ I-D: draft-giaretta-mip6-authorization-eap-02.txt Giaretta Gerardo someone - how to define aaa server between ha & aaa server? Pasi Eronen - lots of info that would like to provision to user. EAP isn't the right approach. Jari Arkko - agrees with Pasi. There are procedural issues as well as technical. This approach might not require AP changes, but changes to EAP methods. If you can re-use existing protocols, this is easier. If you want to use EAP for new purposes, this is harder. James Kempf - would prefer to be minimalistic here. Hesham Soliman - agree we need to draw a limit, but there are 3 levels of auth typically. There is interest in leveraging AAA infra for this. Doesn't think this will change EAP much. Next step - Waiting for EAP wg feedback - WG doc? MN-HA Ipsec SA can be estblished from a shared secret using IKE with PSK auth EAP method can be used to exchange PSK Jari A- There are some other requirements in EAP methods. 5.3 APPLICATION MASTER SESSION KEY (AMSK) FOR MOBILE IPV6 --------------------------------------------------------- I-D: draft-giaretta-mip6-amsk-00.txt Giaretta Gerardo Jari Arkko - question on changes to EAP framework. As a whole, there are more requirements than just on EAP methods, may be changing EAP API. Hesham Soliman - does EAP SIM produce an AMSK? Jari Arkko - I think so. 6 DIAMETER MOBILE IPV6 BOOTSTRAPPING APPLICATION USING PANA ----------------------------------------------------------- I-D: draft-jee-mip6-bootstrap-pana-00.txt I-D: draft-tschofenig-mip6-bootstrapping-pana-00.txt Junghoon Jee, Hannes Tschofenig PANA is used between MN and HA Used to bootstrap mip6-auth Pac <<<PANA message exch----> HA Does wg think PANA is appropriate to deliver bootstrapping info ? New DIAMETER bootstrapping scenario? James K - PANA can work with EAP. Has a problem defining PANA to go beyond 1st hop link. ICMP often doesn't work after 1st hop. Yoshihiro Ohba - PANA is based on UDP James - OK, so I guess that is not a problem. 7. MOBILE IPV6 BOOTSTRAPPING ARCHITECTURE USING DHCP ---------------------------------------------------- I-D: draft-ohba-mip6-boot-arch-dhcp-00 Yoshihiro Ohba Model 1 - DHCP server AAA-MS client Model 2 - NAS as AAA-MS client Draft describes how this arch map to bootstrapping scenario James Kempf - Ralph Droms mentioned that backending DHCP server into AAA server is not a good idea. Same problem about NAS pushing stuff into DHCP server. OK to put Home Address into DHCP server. Concerned about the complications & bittleness of this. 8. BOOTSTRAP CONTROL FUNCTION MECHANISM FOR MOBILE IPV6 BOOTSTRAP ----------------------------------------------------------------- I-D: draft-deng-mip6-bootstrap-bcf-00.txt Hui Deng - Introduced new network element (BCF) AAA ------- HA1 | | MN -----BCF -------- ---- HA2 | --------- HA3 Discuss on list with rest of the bootstrapping stuff. Possible design team issue. Q: Why is it necessary to separate network access from the bootstrapping function? A: Because the operators already have an access authentication mechanism in place. Adding MIP6 to the same, will increase the risk and also complicate the network. Hui: Can we separate bootstrap solution into: IASP and MSP? 9. PRECOMPUTABLE BINDING MANAGEMENT KEY KBM FOR MOBILE IPV6 ----------------------------------------------------------- I-D: draft-ietf-mip6-precfgkbm-01.txt Vijay Devarapalli - Proceed with this document. 10. IMPROVEMENT OF RETURN ROUTABILITY PROTOCOL ---------------------------------------------- I-D: draft-qiu-mip6-rr-improvement-00.txt Jianying ZHOU DOS attack, session hijacking, movement halting attack Problem HOTI/COTI - independent of COA and HoA use HOA in COTI and COA in HOTI for authentication and signals Christian V.- Even if you combine the two, the attacker will have ability to attack Yes - but it is much more difficult, as it needs to know both addr Erik - If we do this, we can't keep the same home keygen when COA changes Jari - What's the point becuase the packets are flying by anyway and has same limitation that Erik mentioned 11. Next steps for WG --------------------- - Bring closure to Auth and Identifier - Taking transition problem as wg doc - DT for bootstrapping - Revise charter based on privacy bar bof 12. Multihoming in MIP6 ----------------------- Thierry Ernst I-Ds: draft-montavont-mobileip-multihoming-pb-statement-02.txt draft-ernst-generic-goals-and-benefits-00.txt Motivation for multihoming Applied to fixed hosts, mobile hosts and routers Seeking sense from the room Shall we include support multiple interfaces in MIP6 WG ? Thomas Narten: A problem statement for multihoming is required first. Multi-homing working group is working on different issues - so the problem statement document would indicate the non-mobility cases and carefully consider the mobility cases. Once we identify those, we can then consider whether and what this group needs to address. Gabriel: I have a question: if you are going to characterize the multihoming problem then are you also going to consider the case in which you have multiple IPv4 as well as multiple IPv6 addresses? Will get hairy, but at least mentioning might be in order. 13. Load Balance for Distributed Home Agents in Mobile IPv6 ---------------------------------------------------------- I-D: draft-deng-mip6-ha-loadbalance-02.txt Hui Deng Problem: There are many reasons a home agent might want to reduce the number of mobile nodes it is currently supporting. For example, it might be overloaded, it wants to achieve better load-balancing between a peer home agent, or it is going offline for service. Idea: New Load Balance Information Option New Home Agent Handoff Message Question to WG: - Should it be WG item ? |