[Mip6] IETF 61 minutes

Hi all,

Here are my rough notes from the meeting. Please send corrections, additions. I missed the last 5 minutes of the meeting, as I had to run to the airport.

thanks,
John

1.	AGENDA, BLUESHEETS, NOTE-TAKERS AND JABBER SCRIBES   5 MINS
2.	DOC STATUS

AD Review - 
 extentions to socket api for mipv6
 mipv6 route optimization security design background

wglc completed	
 MIPv6 & FW
 several comments, document to be updated & resubmited

MIB status 
 Updated review, comments from MIB doctors

3.	AUTH-ID DISCUSSION
 Was consensus call on list, believe that there was consensus on the list
 Issue tracker created & suggestions to the draft are welcome.

Thomas Narten: Appeal of MIPv6 Consensus call
 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:
 Do not publish at all - has consequences for the relevance of the IETF
 Publish on standards track - sends signal that this has IETF support
 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.

3gpp2 guy - 3GPP2 needs this work, working with Thomas on liason statement. Doesn't see interp 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.

?? - 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 - it doesn't have to be a weaker option. interop issue - distintion is that 2 random nodes will authenticate to each other.

Pete - 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.

3GPP2 guy - only argument we have heard against this interoperability.  Don't we have rough consensus.

Thomas - we don't vote, some people are debating the validity of the consensus.

3GPP2 - 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 Daily- 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.

Ghopal - 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.

Someone  - 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.

4.	MIP6 OPERATION WITH IKEV2 AND THE REVISED IPSEC ARCH

4.1	I-D: draft-ietf-mip6-ikev2-ipsec-00.txt -  Vijay Devarapalli

See slides

Open issue on level of support of IKEv2

Richard Graves - question on support for manual vs dynamic keys

Jari Arkko - on should / may / etc. - is this 3775-bis or is it IKEv2 support. If it is the later, then it should be a MUST.

Francis Dupont - have a concern about MUST 

someone from Ericsson - question about IPsec SA, would like to see a reference to the revised security arch

Vijay Devarapalli- sees an interop issue with IPsec, 

Hesham Soliman  - are we moving away from tunnel-based mechanism.  

Francis - Doesn't think this is a good way (use of EAP)

PM - this is the most important mechanism & likely to be deployed

James Kempf - thinks that Home Address Config should be a SHOULD

EN - thinks that this is related to bootstrapping discussion.  It would be good to do as much as possible together.

Jari Arkko - thinks bootstrapping support here is a good thing.

4.2	Using IPsec to protect signaling between MN and CN   5 Mins

I-D: draft-dupont-mipv6-cn-ipsec-01.txt

see presentation

Question is that, can this mechanism be used to secure route-optimizatoin

Vijay Devarapalli- support this work

James Kempf - thinking about mobike here.  a bit early to think how these will interact, but should think about this.  Will this work for transport as well as tunnel mode? then its a good idea.

Francis Dupont - yes.

Suresh - thinks its a good idea, applicability is clear.

Objections to making this a WG item?  No comments. It will become a wg item, after confirmation on the ML.

4.3	Care-of address test procedure using a state cookie  5 Mins

I-D: Annex of draft-dupont-mipv6-cn-ipsec-01.txt Francis Dupont

Vijay Devarapalli- coa test can be used.

Christian - comment about coa test

James Kempf - rechartering discussed breaking-up the main spec into functionalities, should we do this?

EN ? - doesn't understand how this is related to the COA test in base spec. Sees that this is general mechanism.

Jari Arkko - when we do security, we should do it all in one place to make sure we capture all the interactions in one place.

5.	AAA AND MOBILE IPV6                                    20 MINS

5.1	I-D: draft-giaretta-mip6-aaa-ha-goals-00.txt & I-D: draft-yegin-mip6-aaa-fwk-00.txt   

Giaretta Gerardo/Alper Yegin

Junghoon Jee - question about scenario 1 - cannot understand where the network service occurs.

PM - possible to seperate NAS from MIPv6, so we should seperate the authentication here.

someone - have to think about how to authorize the network service.

Hesham Soliman   - Scenario 2 - do auth on NAI or something, not on the home address option.

Junghoon Jee - need some extention for Diameter / RADIUS

Greg Daily- sounds like this is related with 3GPP2 provider case, would be worth discussing.

Hesham Soliman  - this is good for IPsec.

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.

6.	MIPV6 AUTHORIZATION AND CONFIGURATION BASED ON EAP    10 MINS

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.

7.	APPLICATION MASTER SESSION KEY (AMSK) FOR MOBILE IPV6   5 MINS

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.

8.	DIAMETER MOBILE IPV6 BOOTSTRAPPING APPLICATION USING PANA  15 MINS

I-D: draft-jee-mip6-bootstrap-pana-00.txt
I-D: draft-tschofenig-mip6-bootstrapping-pana-00.txt

Junghoon Jee, Hannes Tschofenig

James Kempf - Question - 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 runs over UDP.

James Kempf - takes back his issue. 

9.	MOBILE IPV6 BOOTSTRAPPING ARCHITECTURE USING DHCP      15 MINS

I-D: draft-ohba-mip6-boot-arch-dhcp-00   Yoshihiro Ohba

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.

10.	BOOTSTRAP CONTROL FUNCTION MECHANISM FOR MOBILE IPV6 BOOTSTRAP 10 MINS

I-D: draft-deng-mip6-bootstrap-bcf-00.txt Hui Deng

discuss on list with rest of the bootstrapping stuff. Possible design team issue.

11.	PRECOMPUTABLE BINDING MANAGEMENT KEY KBM FOR MOBILE IPV6 5 MINS
    I-D: draft-ietf-mip6-precfgkbm-01.txt
    Charles Perkins

procede with this document.

12.	IMPROVEMENT OF RETURN ROUTABILITY PROTOCOL             10 MINS

    I-D: draft-qiu-mip6-rr-improvement-00.txt

    Jianying ZHOU

13. Next steps                  Chairs                     5 Mins

Time permitting, we will discuss these IDs and interest in this work:

a. Multihoming in MIP6
   I-Ds: draft-montavont-mobileip-multihoming-pb-statement-02.txt
         draft-ernst-generic-goals-and-benefits-00.txt
   Nicolas Montavont

b. Load Balance for Distributed Home Agents in Mobile IPv6
   I-D: draft-deng-mip6-ha-loadbalance-02.txt
   Hui Deng

_______________________________________________
Mip6 mailing list
Mip6@ietf.org
https://www1.ietf.org/mailman/listinfo/mip6