Mobile IP WG minutes (IETF54 @ Yokohama on July 15th, 2002) ----------------------------------------------------------- Meeting minutes captured by Basavaraj Patil and Phil Roberts Agenda bashing: --------------- Mr. Mastaka Ohta requested a presentation slot - rejected by the chairs, ADs asked, and then insisted that the ongoing persistent request be taken offline 3012bis has actually completed WG last call. Actually, it has been sent to the IESG and is on the review list already. 3220bis is with the RFC editor and should be published as a new RFC soon. Reg-Revocation in WG last call now. AAA-Keys has completed WG last call and awaiting changes based on IESG review comments. MIPv6 discussions ----------------- Resolutions of all issues will be proposed to the ML, with included text for the draft. WG will be able to comment. 76 - unclear response on whether to include this, asked whether useful, whether not. Dave Johnson requested whether it is dangerous to have it in the text and he and Charlie at least indicated some concern. Some found it useful. 74 - source selection, plus guidance here, plus implementors common sense will get this right (Hesham). Dave J history - acknowledging that it is useful and is there so folks will know it is possible. (Mr. Keichi?) some communications must use COA so text will be needed to clarify this. (?) Problem needs to be solved, will be done elsewhere, not in this document. (Francis) need something like API or state machines for some details and security descriptions. (Hesham) in some other API, let's not make it CoA vs HA, but something more abstract. 62 - (Hesham) separate issue posted to the ML. Some twisted notion of ll home address and needing to keep what's at home. (TJ) thinks it ought to be obvious. (Francis) should wait for DAD and DIID before deciding on the best solution. (Phil) let's go with what we've got (Hesham) either defending home address or defending link local (Phil) yes, home 72 - (Charlie) uses same binding update signalling as is in this draft, whereas the fast handover work has new signalling. (James) there is signalling for this in the fmip draft. (Charlie) Doesn't make sense to use the existing messages to do what it was designed to do? (Rajeev) new signalling is slightly different. (Charlie) even if you take it out, it could still be done. This provides guidance. (Alper) maybe it would be best left where it is to allow better performance now. (Erik) the security description is incomplete. (Note to self - work with Jari about what is actually needed to make this complete. If it's a lot, take seriously the request to drop it). 49 - (Hesham) need to clarify why this is a hard problem. (Francis) this is a general IPSEC/IKE problem. Give it to IPSEC to solve. (Erik) it is harder than what Hesham said: if I assign myself a temporary address (3041), preferred for a day, deferred for 6 days. Don't want anyone to claim it in the mobility case even though I used it for just a little bit. Hard - need something different. Not tied to binding lifetime, but the lifetime of the temporary address, conflict between multiple mobile nodes trying to claim the same temporary. Conclusion is agreeable to all. 56 - (FD) HA discovery is totally insecure and there is no way to make it sure. (Hesham) It doesn't need to be secure. A fake HA will be discovered immediately. (Raj) What is the threat with not securing the HA process? (FD) Not sure, but need to use IPSEC and IPSEC will fail. All other proposed solutions can be done in a secure manner. (Jim) Was arguing that maybe an alternative is possible, and reducing the size of the doc is a goal. Maybe there is an argument for a special protocol. (Hesham) this mechanism serves a good purpose and it should be left in. (Dave J) Removing features solely for the purpose of making the doc shorter is a recipe to further reducing the implemented functions. (Jari) node requirements can mandate stuff (Dave J) node requirements doesn't exist. At worst you create extra work rather than denial-of-service. (Thomas) not clear there is a concrete proposal here. Need a concrete proposal if we're going to do something to replace this. Proposal is to keep it, finish discussion on the ML. 70 - (DJ) what is the purpose in making it mandatory? (Jari) when using ESP to protect BUs, ESP doesn't protect source address. (DJ) use it only when using ESP? (Jari) possible, but introduces unnecessary dependency. (DJ) Why not make it a required field? We end up with distinguishing between a BU for home and for non-home BUs. (Jari) we already have that. (FD) make it mandatory (Jari) need to know whether it is ESP. Just make a requirement for home registrations. Don't try to solve an implementation problem by changing the protocol. Let implementors. (Hesham) it's not a big problem, don't change it now. (Rajeev) in FMIPv6 and HMIPv6 you need it. (Charlie) leave it up to implementors (Dave J) if you don't know whether you are using ESP you must use this. (TJ) dynamic HA discovery question (56). Alternative proposal, if addresses don't fit in MTU, do it j-1 addresses and make j the address of the HA that is responding. Still get first optimization. (Charlie) important to keep the first optimization. (Hesham) prohibit site-local COA - no text is there. (Erik) let's not say anything about site-locals 80 - (FD) R-bit is needed to say whether mobile node is a router. Issues Dave Johnson wants to raise (DJ) For RR the MN can't know whether the nonce is too old. An MN can send a BU requesting not to acknowledge. Can't get told nonce is too old. -> Need to be able to handle Binding Acks and match them with sequence numbers even in the case we did not request a binding ack. (DJ) For RR, the cookie may be protected by ESP on HA-MN link. If it isn't protected anyone on or near the FL will see both cookies. Why not require ESP on MN-HA link? (Jari) Previous discussion led us to believe it is a MAY. One of the reasons is that the kind of attacks that can happen will hurt MN-HA but cannot hurt third parties. (DJ) disagrees - affects conversation with CN also. (Hesham) thinks it's a SHOULD (DJ) wants a MUST, reckless not to take advantage of required fnality (DJ) will post rest of issues to list. (Mr K) why do all nodes have to support HAO? (DJ) for CNs to receive a packet from a mobile node while it is away from home. (Mr K) this does not prevent communication. (DJ) MN that sends a packet with HAO implies that all nodes must support it. Fast Handoff in V6: -------------------- (Phil's pres on an 802.11 fast handoff draft) Phil set the context and provided the background for the work and discussion. He also outlined a strategy for moving forward. Phils recommendation is that Fast HO be defined for specific link layers and we can start with defining Fast HO for 802.11 For details on the proposal refer to the slides. - Hesham agrees. However a general protocol is all you really need. Jak: Disagrees. Example of IPv6 in RFC2461 and 2464 Ohta: FMIPv6 useless. Document is large. 3G/FoMA is not valid for Internet access Hesham: 802.11 work will raise the same issues all over again Jim Bound: Agrees with the process proposed by Phil and supports it Gopal: Doing the 802.11 spec will narrow the focus and help Gopal agrees that the 802.11 spec should simply specify the triggers Rajeev: V05 already supports implementing FMIpv6 on 802.11 Hesham: Will the 802.11 draft simply specify the L2 triggers for fast HO? Jak: The current draft is focused on Preaddress configuration and this is not possible in 802.11 (Rajeev's presentation) (Jim) on network controlled handover. How does PAR know to send PrRtAdv without an L2 trigger? Only use when there is potentially no L2trigger, when MN sends a solicitation. Assertion: there is no way to do something like this without some kind of l2 info. (Hesham) tunnel was previously terminated on the mobile node - now what happens with ingress filtering. (Rajeev) question about what's available on L2? (Jim) we are setting requirements (Rajeev) are we putting musts for L2s (Jim) there may be a tight coupling that needs to be specified. - had to cut off the pres, Rajeev will post issues to the ML and solicit discussion from the WG on answers to his question. VPN Traversal requirements -------------------------- (Farid Adrangi presented the requirements) (Raj) on RO, is it an objective to solve v4 R.O. (Farid) may (Raj) what does RO have to do with this problem? If a new entity is introduced is rt. opt. needed. Limited Private Address Support ------------------------------- (Gabriel's pres) new draft updates guidance for implementation of reverse tunneling (Phil) what do you want to do with it? (Gab) separate wg document as BCP or Informational (Pete) concerned that implementation community is split because there are CDMA vendors who are doing separate implementations from what is done at Cthon. Existing RFC is a fine spec, pp2 understands what it means. Needs to review. LMM Requirements ----------------- (Carl pres) Some small mods. Ready for WG last call.