RE: [Mip6] IETF61 WG meeting minutes (Draft)

["DENG, HUI -HCHIBJ" <[e-mail]>]

:) Seems also my slot about load balance has not been reported

-Hui Deng

-----Original Message-----
From: Thierry Ernst [mailto:[e-mail]] 
Sent: 2004?12?6? 20:25
To: [e-mail]
Subject: Re: [Mip6] IETF61 WG meeting minutes (Draft)


Seems that my slot about multihoming (was after next steps) hasn't been reported. 

Thierry


On Sat, 4 Dec 2004 17:46:43 -0600
[e-mail] 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
[e-mail]
https://www1.ietf.org/mailman/listinfo/mip6

_______________________________________________
Mip6 mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/mip6