IETF 68 MIPSHOP WG Meeting Minutes ---------------------------------- Note takers: Juan Carlos Zuniga and Gabor Bajko 1. Agenda review 2. WG status and I-Ds update draft-ietf-mipshop-fmipv6-rfc4068bis-02 Completed WG last call. Waiting on the handover keys document. There will be a new revision before sending the document to the IESG. draft-ietf-mipshop-handover-key-00 An issue on the use of CGA key for encrypting the handover key A proposal for a work-around draft-ietf-mipshop-3gfh-03 Considering an LS to 3GPP2 to figure out their interest in this draft draft-ietf-mipshop-fh80216e-02 Received reviews from 16ng WG WG last call soon draft-ietf-mipshop-4140bis-00 Updated to reflect the use of IKEv2 between the MN and the MAP WG last call after the IETF meeting draft-ietf-mipshop-mis-ps-02 Will be sent to the IESG for publication soon. MIH Solution Design Team very behind schedule Change of editor An update will be available this meeting 3. Fast Handovers for Mobile IPv6 (FMIPv6) Rajeev Koodli Changes to the draft from the last version were presented. No comments received during the presentation. A new version will be generated based on the comments received during the WG last call. 4. Distributing a Symmetric FMIPv6 Handover Key using SEND Rajeev Koodli Rajeev presented a new mechanism to use another key pair to encrypt the handover key. Hesham: Why use another RSA instead of a symmetric key encryption? Rajeev: Same RSA must not be used Hesham: don't use another public/private key pair, use a symmetric key. How to generate a symmetric key? Vijay: This would need extending the spec to carry this information Hesham: Piggyback or use fmip6 signalling (both require additions to the spec). with SEND: piggyback neighbour discovery. Greg: computational overhead for symmetric is smaller than for the public/private pairs, It makes sense to have symmetric keys Rajeev: This is not done on a per packet basis Hesham: Frequent handovers can happen Vijay: Lets move on. Let’s get this done in the next two weeks Jim Bound: Nobody has used CGA. I don't like FMIPv6 being dependent on CGA. Vijay: We are standardizing two options, CGA and shared keys based on the AAA infrastructure. We still need to pick a document for the AAA based FMIPv6 handover keys. Alper: CGA vs AAA, Can we mandate one vs the other? Vijay: Shared secret is needed for FMIPv6 to work. How the secret gets there, that is still open. Rajeev: We should show that there is at least one mechanism to do it in order to move forward on FMIPv6. 5. Fast handovers for PMIPv6 Hidetoshi Yokota Vijay: Fast Handovers for PMIPv6, Not sure whether this work will be in NETLMM or MIPSHOP Hidetoshi presented the details of the draft. Hesham: Is sending the info to LMA that different? AR could be further away than the LMA Vijay: The assumption is that ARs are closer to each other than the LMA to the AR. Hesham: Should it be separate documents for fast handovers and context transfer? Hidetoshi: Context transfer is tightly coupled Hesham: That doesn’t mean that they need to be in the same document Rajeev: Forwarding an existing session is a problem. How do you exchange info between router is another problem. You could specify them in different section Frank: NETLMM is a better place Vijay: We should not worry about this now, since the decision will be taken with consulting the NETLMM chairs and the AD. 6. FMIPv6 on Point-to-Point Links Frank Xia Frank presented details about FMIPv6 using PtP links Vijay: I still want to see what is missing regarding PtP links Frank: Prefix management “could” be an issue Vijay: I thought that it was already included in draft Frank: NAR not PMR Rajeev: If MN configures address, it can still get prefix through the FBack We can put what makes sense in base draft, but not clear what the base spec needs to do 7. FMIPv6 over 802.16e links Heejin Jang Heejin presented details of the draft. Rajeev: What is an AR in the 16e model? WiMAX discussion could be captured in an appendix. Work needs to be coordinated with PtP draft. 8. MIH Design Team Update Telemaco Melia Telemaco presented an update on MIH-DT discussions and where they are. Alper: Are these real scenarios?, could MoSh(?) provide ES/CS? Juan Carlos: ES/CS local and IS remote is a viable scenario Alper: How about DHCP for IS? Tele: You need to make the IS available to the DHCP server Gabor: DHCP is for configuration, not for transport of information Vijay: Take this discussion to the list 9. MIH Transport protocol considerations David Griffith David Griffith gave a brief description of their work Performance evaluation of L3 transport protocols for 802.21. Graphs to be discussed in MOBOPTS Lars: Are you changing the TCP RTO? David: No. 10. AAA based handover keys for FMIPv6 Chairs Vijay: Standardization of AAA to generate HO keys for FMIPv6. There are four options available. Details in slides. Vidya: I don’t understand option 4 Jari: We had consensus about AAA keying, but now we have an option to do/not do it. Option 4 should be valid if no one wants to work on the draft and edit a particular draft. Suresh: (missed comment) Rajeev: Did we not have consensus on doing this work? Vijay: Only 6 people replied and no one volunteered to do the work Vidya: We should not ask the question again Jari: It seems like we need to keep option 1 and remove option 4 Alper: There is interest for the other options Yoshi: HOKEY is missing the transport protocol Jari: We can’t take a decision. We need to do the work and then take a consensus call 11. Next Steps Chairs WG last calls soon on draft-ietf-mipshop-4140bis-00 and draft-ietf-mipshop-fh80216e-02 draft-ietf-mipshop-mis-ps-02 and draft-ietf-mipshop-fmipv6-rfc4068bis-02 will be sent to the IESG soonSeND-based handover keys draft WG last call after the work-around solution is reviewed Solicit reviews on draft-ietf-mipshop-3gfh-02 and figure out 3GPP2 interest in this document Publish first version MIH solution document soon Resolve the situation on handover keys using AAA Figure out where the work on FMIPv6 extensions to PMIPv6 fits