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

["John Loughney" <[e-mail]>]

Hi Thierry,

I had to run to catch a plane so I did not catch your presentation. Did 
someone else get notes?

John

________________ Original message ________________
Subject:	Re: [Mip6] IETF61 WG meeting minutes (Draft)
Author:	"ext Thierry Ernst" <[e-mail]>
Date:		06th December 2004 9:24:48  PM

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