Re: [Mip6] IETF61 WG meeting minutes (Draft)
Thierry Ernst <ernst@sfc.wide.ad.jp> Mon, 06 December 2004 12:57 UTC
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09625 for <mip6-web-archive@ietf.org>; Mon, 6 Dec 2004 07:57:43 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CbIXK-00048u-UX for mip6-web-archive@ietf.org; Mon, 06 Dec 2004 08:04:19 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CbIE1-0003Vl-67; Mon, 06 Dec 2004 07:44:21 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CbHsq-0005xU-BQ for mip6@megatron.ietf.org; Mon, 06 Dec 2004 07:22:28 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA01385 for <mip6@ietf.org>; Mon, 6 Dec 2004 07:22:27 -0500 (EST)
Received: from mail.sfc.wide.ad.jp ([203.178.142.146]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CbHz8-0001HL-9Q for mip6@ietf.org; Mon, 06 Dec 2004 07:29:02 -0500
Received: from iseran.local (unknown [130.79.48.5]) by mail.sfc.wide.ad.jp (Postfix) with ESMTP id 845A04D8BC for <mip6@ietf.org>; Mon, 6 Dec 2004 21:21:43 +0900 (JST)
Date: Mon, 06 Dec 2004 21:24:48 +0900
From: Thierry Ernst <ernst@sfc.wide.ad.jp>
To: mip6@ietf.org
Subject: Re: [Mip6] IETF61 WG meeting minutes (Draft)
Message-Id: <20041206212448.534165bc.ernst@sfc.wide.ad.jp>
In-Reply-To: <697DAA22C5004B4596E033803A7CEF4403B1C270@daebe007.americas.nokia.com>
References: <697DAA22C5004B4596E033803A7CEF4403B1C270@daebe007.americas.nokia.com>
Organization: Keio University
X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.10; powerpc-apple-darwin7.4.0)
Mime-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d6c15d82a53e26283536b4a751453103
Content-Transfer-Encoding: 7bit
X-BeenThere: mip6@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: mip6.ietf.org
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/mip6>, <mailto:mip6-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:mip6@ietf.org>
List-Help: <mailto:mip6-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/mip6>, <mailto:mip6-request@ietf.org?subject=subscribe>
Sender: mip6-bounces@ietf.org
Errors-To: mip6-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8f3b9db08b8c0fe2301a77f547096e31
Content-Transfer-Encoding: 7bit
Seems that my slot about multihoming (was after next steps) hasn't been reported. Thierry On Sat, 4 Dec 2004 17:46:43 -0600 Basavaraj.Patil@nokia.com wrote: > > > 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 > > Comment(Jee?)- 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. > > 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. > > 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 > > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6
- [Mip6] IETF61 WG meeting minutes (Draft) Basavaraj.Patil
- Re: [Mip6] IETF61 WG meeting minutes (Draft) Thierry Ernst
- Re: [Mip6] IETF61 WG meeting minutes (Draft) John Loughney
- RE: [Mip6] IETF61 WG meeting minutes (Draft) DENG, HUI -HCHIBJ
- Re: [Mip6] IETF61 WG meeting minutes (Draft) Junghoon Jee