Subject: [Mipshop] IETF 70 MIPSHOP WG minutes

From: Vijay Devarapalli <[email-masked]>
Date: Sun, 30 Dec 2007 00:31:37 -0800

Hello folks,

Here are the draft minutes for the MIPSHOP meeting at IETF 70. Thanks to 
Fan Zhao and Juan Carlos Zuniga for taking the notes.

Please let us know if there are any corrections.

Vijay
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

_______________________________________________
Mipshop mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mipshop