IETF 70 MIPSHOP WG Meeting Minutes ---------------------------------- Note takers: Fan Zhao and Juan Carlos Zuniga 0. Agenda review 1. WG status and I-Ds update draft-ietf-mipshop-fmipv6-rfc4068bis-04 FMIPv6 got extensive reviews from the IESG. Comments have been addressed. draft-ietf-mipshop-4140bis-01 Submitted to the IESG. draft-ietf-mipshop-handover-key-03 In the RFC editor queue. AAA-based handover key No document, need to take a decision on what to standardize. draft-ietf-mipshop-3gfh-04 Was reviewed by the AD. FMIPv6 on CDMA needs a new revision. Reviews were solicited from 3GPP2, but got no comments. draft-ietf-mipshop-fh80216e-05 FMIPv6 over 802.16e completed the LC. Sent to the IESG. Need to address AD review comments. draft-ietf-mipshop-mis-ps-05 With the IESG MIH solution Design team document to be adopted as a WG document Re-chartering: AAA-based handover key and MIH solution are pending. Open discussion on what work item should be added, and only documents with strong interests will be adopted, such as those with use cases. 2. Fast handovers for PMIPv6 Hidetoshi Yokota draft-yokota-mipshop-pfmipv6-01 Hidetoshi Yokota: Made some modifications that are needed for PMIP6. Tried to reuse FMIP6 as much as possible. With PMIP, MN is not involved in the HO signaling. Some lower-layer signaling is used. Context information is transferred by HI/Hack exchange. Review the new changes proposed in the PMIP protocol and describe different handover scenarios in PMIP. MN interface ID option is a new option for context transfer. The format of MN_ID is described. Gerardo: just replace the "something" with lower level signaling. Is PMIPv6 and FMIPv6 just about about context transfer between MAGs? Hidetoshi Yokota: Not only the context transfer, but also other changes. In the case of handover with PMIP, MN does not use CoA, while FMIP ses CoA. We modified the messages of FMIP. Gerardo: I do not understand, what is the motivation? All necessary steps in PMIP are not required because we keep the same IP address. Hidetoshi Yokota: Inter MAG handover. Some data is transferred; the destination of data is the new CoA. Sri: It is not just context transfer, but also the tunnel between the MAGs. Vijay: This proposal also sets up a tunnel from the old MAG to the new MAG to forward packets during the handover. Raj: move the PBU/PBA from the critical path Sri: For come parameters, some context transfer needs to be extended as well. Behcet: This protocol is tied to PMIP, should be done in Netlmm. There are more requirements from netlmm. Route Optimization is done in Netlmm. Hidetoshi Yokota: RO is different. It should be in Netlmm while this work should be in Mipshop. Gerardo: The new chapter may include the indication. It is a Netlmm specific issue. MIP is just one method. Vijay: No issues with taking up FMIPv6 with PMIPv6 with MIPSHOP. This proposal is trying to optimize PMIPv6 handover using FMIPv6 extensions. So it can be done in MIPSHOP. Alex: It is more like in the problem statement phrase. PMIP may have other needs for speedy handover. It is too fast to jump on. PMIP is so different. Doing solution is too early. Hidetoshi Yokota: We feel there is not much difference between fmip handover and pmip handover. If discuss the problem statement, it is also the same problem of fmip handover. Alex: I am not convinced. Jari Arkko: Understand where the demand comes from, but wants to know if folks really have a use for this. Raj: I am not sure where. This is the optimization for packet loss. Jari Arkko: This working group may not be reach the community who want to use PMIPv6. These folks might be just following the NETLMM WG. Raj: Those people do think there is a need. When the mobile node does not have the capability to send the messages, you can apply this solution. Jari Arkko: mipshop is a good place to work on the optimization. I intend to ask the community that wants to implement the PMIP whether this is needed. Raj: next step? Vijay: I will get the sense from the WG and ask on the mailing list. 3. MIH Design Team Update Telemaco Melia draft-melia-mipshop-mstp-solution-01 The main doc describes scenarios. Similar to mip6 bootstrapping. We do not have AAA extensions. MN may want to discover what is provided by the third party. Server must support tcp/udp and MN must support tcp. UDP and TCP can be chosen based on different requirements. The current doc should be the base for the WG doc. 802.21 is sponsor ballot. DT is flexible with how to organize. Vijay: There are three different documents. Any comments on how the documents are being structured? No comments. Vijay: DNS, DHCP depends on the deployment. The MN needs to figure out the scenario before it can use a certain mechanism? It is not clear what the MN should do, since the recommendation is to use sometimes DNS and sometimes DHCP. Telemaco: It depends on the scenario. Subir Das: Since it depends on the scenario, consider which is the default scenario. Vijay: Since you have different scenarios, MN may boot up from the home or the visited link, it must have a default method. Gabor: DNS can always be used. In some scenarios DHCP could be more convenient. Subir Das: Is it really required that the document defines which is default? Vijay: On scenario 2, you try and fall back because dhcp fails. Name missed: usually you use dhcp anyway. Vijay: How many people support this to become a WG doc? 16 hands. Any objection? No. Vijay: Regarding the organization, we need to figure it out. Will check with Stefano to see whether we should have one or three documents. 4. FMIPv6 on Point-to-Point Links Behcet Sarikaya draft-xia-mipshop-fmip-ptp-01 p2p link is used on 3gpp, wimax and 3gpp2. FMIP does not define the prefix management. On the p2p link, the prefix is a dedicated prefix. Proposed small changes to FMIP. Network-initiated handover: to detail the operation in the next version. It is optional to do DAD on the p2p link Become a WG draft? Hesham: Was not it that it should be merged with fmipv6? Behcet: Rajeev preferred to add one section to prefix management. Vijay: Will confirm on the mailing list. 5. AAA based handover keys for FMIPv6 Vijay Devarapalli Vijay: The WG needs to work on the mechanism. The third option needs a new document. For the option1 we already have a draft. Need to hear more opinions from the WG. Yoshihiro Ohba (Toshiba): It is a good idea to use hokey. In the roaming environment, sometimes the domain maybe considers the domain specific solution. The domain has many ways to generate the handover key. Hesham: I have a question on option1. If there is the WG consensus, why we need to ask again? Vijay: The WG consensus call ended in 2006. Security reviews and mobility directorate reviews were pending at that time. It took 8 months for us to get a security review, but not conclusive, and there were other process related delays. We have to text WG sense again for this document. Vijay: Option 3 needs a new doc. Do you have a way, like show hand to move forward? Jari: we should choose between the options, not much pay attention to who will edit the document at this point. Alper: We should identify that there is a problem, and then let's discuss the options. Historically, only one has been discussed (not the last two). We might pick one or more, but let's have the technical discussions Vijay: Someone has to work option 3. Need a volunteer. Vijay: discuss on the mailing list. 6. Enhancements to RFC 4866 Wassim Haddad draft-haddad-mipshop-netflood-defense-00 Wassim presented it. Julien: why do you use the certificate from MN to access router? Wassim: Access router discloses to CN. The hash will allow the CN to check it is really from the access router before checking the public key. Julien: what is the benefit? Wassim: If the hash is not correct, drop the message. The CN will check it before checking the public key. Hesham: send r0 to CN? Wassim: no. Hesham: How does this happen between access routers? Wassim: Extension is needed. If there is other node that can defend the network, the access router can advertise the public key of another node. 7. Next Steps Vijay Devarapalli Vijay: Complete work on two remaining items. Proposals for recharter: - Solution for AAA based HO key for FMIPv6 - FMIPv6 with PMIPv6 - FMIP prefix assignment Discussion to follow on mailing list