--------------------------------------------------------------------------------------------------- MEXT meeting minutes TUESDAY, March 24, 2009 1520-1700 Afternoon Session II --------------------------------------------------------------------------------------------------- Minutes by: Ed Jankiewicz --------------------------------------------------------------------------------------------------- - Extended Home link Domagoj Premec http://tools.ietf.org/html/draft-premec-mext-extended-home-link-01 Add to DSMIPv6 as part of MEXT charter IPv6-only home network, but connected to dual-stack Hesham: Home Agent is dual-stack on the egress side not on the home link side Link-layer connection restricted to IPv6-only or IPv4-only Proposal - the MN is allowed to not register with HA, thus has no IPv4 If it needs IPv4, it registers its IPv6 HoA as the CoA for the IPv4 HoA. George Tsirtsis - Looks like an MCoA registration Hesham - it is also a DSMIPv6 registration; ESP does not cover the HoA Interaction with PMIPv6 MAG is in control of the IPv6 HoA, MN manages the IPv4 HoA Adopt as WG? List seemed to indicate Hesham - binding update specifies different handling of source address, like DSMIP, not used anywhere else Vijay - confusing - need specific indication that you are binding v6 home address to a v4 address. Not safe to assume this combination of options is guaranteed to be unique; an explicit flag would help Hesham - messed up format, the receiver may get confused George - complex due to many different types of binding update. Maybe the MCoA format would Vijay - rather than a flag, new mobility option which includes both the v4 and v6 addresses Chan Wah - treat the Ipv6 home address as a care of address - does this conflict with the base spec? Vijay - question the need, not that much support, not required because interest has died out. Marcelo - seems to be some interest, and someone doing something, but Christian Cashpeters - appears to be well-formed packet ? draft is good, but confusing. Hesham - is 3GPP interested in this? Yes. This in not a well-formed packet; it doesnŐt know what to do with it. Marcelo - please work with the author on the mailing list in writing, against the doc. Help the author. Will check back on call for adoption and confirm action on list. --------------------------------------------------------------------------------------------------- - Open Issues with RFC 3775 bis - Charles Perkins http://tools.ietf.org/html/draft-ietf-mext-rfc3775bis-03 Recent revision including updates for all previous issues, closed or soon to be Four new issues raise 1. BU de-reg race 2. malicious RA => MN 3. additional spec for handling alt-CoA, how long to keep 4. relax mandate to use IPsec, given RFC 4285 Race condition on BU de-register When MN sends BU de-reg, the HA deletes the BCE. What if MN previous BU was delayed? May arrive and HA interpret as a new registration (not checking the sequence#) Marcelo - do we want to deal with and how? Vijay - the previous BU was a refresh? Yes. Right, may create a new BCE Hesham - we have to solve it. George - yes it is an issue, but what is the solution Raj Patel - corner case, may not worth solving in the 3775bis, but if the fix is simple Marcelo - yes, we should solve. How? Hesham - need state - sequence number, security association, George - max time for BU to arrive over the internet should have something to do with half an max RTT over the Internet. That is in the 100s of msecs. So the timeout of a few seconds should be sufficient e.g., 5sec Marcelo - reasonable? Vijay - tentative delete? New binding update arrives - ack or drop? Sequence out of order? Silent drop? Hesham - soft delete, short timeout, new error code (or reuse one) ? is this a device returning home or a device unsubscribing? If on home link DAD defense would catch it Michael - when the BCE is deleted, also delete the SA - then the packet would not match Vijay - it is legal to return home and not defend Vijay will write down the proposal this week Malicious router advertises the MN home prefix Julien - there are solutions - SeND, not specific to MIP Charlie - do we need to revise 3775bis to address this issue? Julien - note it in security considerations Hesham - reject the issue Jari - could be resolved by other means; reject the issue Marcelo - this is just one attack among many. Reject it. ? SeND does not solve this; this is not a neighbor discovery issue, MIP issue Suresh - this was in a draft, discussed, not seen as a real threat Greg Daily - this is DNA rather than 3775, other Standards Track solutions Alt-CoA - make sure the home agent maintains the source address; disagreement whether we need to say Julien - donŐt see the issue - is the person who brought it up able to explain? Vijay - as I understand use the Alt-CoA used for tunneling data traffic, to protect CoA, little text but major change for MIPv6 Charlie - change requires remembering another address, design impact is non-minimal Marcelo - accept or reject? Hesham - happy to reject Raj, Julien, etc. reject Marcelo - rejected IPsec vs Mobile IPv6 - relax the mandate in 3775bis This is really complicated - more than we bargained for, any resolution introduces significant changes to the design of Mobile IPv6 Vijay - relax MUST to SHOULD use IPv6, 4865 is used in some case Hesham - this has implications, so it will take a long time to get consensus Charlie - allow for a Terry Davis - if IPsec were as easy as DHCP everyone would use it. Aviation canŐt live with the complexity ? introducing non-interoperable features Ross? - same security mechanism for Binding Updates, SHOULD leaves interop problems Julien - given IPsec works, MUST gives interoperability; SHOULD leaves the gap Terry - if we get interoperability with IPsec fine Raj Patel - tangent; the protocol needs to specify a default mechanism; donŐt be deceived that specifying IPsec as the method solves the problem. Greg Daily - used the authorization header in earlier drafts, not IPsec; possible but out of scope for 3775bis. Charlie - MIPv4 has interoperability with other means of authentication ? multiple SDOs go with IPsec, we convinced everyone to use it, how can we retrench now? If you relax to SHOULD, what happens when you donŐt - it cannot break the protocol Raj - the other SDOs have not hit the wall on IPsec yet to discover it does not work ? changing to SHOULD doesnŐt fix the problem; keeping MUST doesnŐt mean it wonŐt change at some time later. Marcelo - sympathetic to Terry and others having pain; changing to SHOULD does not solve the problem. You have to come up with an alternative method. Keep MUST, but try to figure out another way to solve it. 12 for MUST, 12 for SHOULD; tie goes to do nothing Greg Daily - need a problem statement on the domain and scope; close the issue on 3775bis, potential new charter item Hesham - close the issue, happy to push off a potential new work item Marcelo - need to follow-up on the list. Failed to close all issuesÉ --------------------------------------------------------------------------------------------------- Flow bindings in MIPv6 Hesham Soliman http://tools.ietf.org/html/draft-ietf-mext-rfc3775bis-03 include support for default routes, explain interactions with BU; applicability to DSMIPv6; should require MCoA or not? Support for default bindings - draft needs to define default bindings for flows that donŐt match any FIDs. Logically belongs to the MCoA draft. Subsequently it was removed from the MCoA draft, so need to address here Insert a default FID for each CoA (requirement on the user, or hide from user by adding wild card FID) ? we got comments from the WG regarding default binding in the flow binding document Hesham - belongs to the binding of the CoA; ? if flow binding can work without MCoA it has to be in the flow binding doc; with MCoA it can be addressed there K Leung - if there is a packet not matching any flow ID how can there be multiple defaults? George - one way to do it is to have a wild card FID, can order the defaults based on the priority field Hesham - ordered list of defaults George - how to prioritize Hesham - policy engine knows the priorities Post the question on the list for further discussion Should this draft be tied to MCoA? George - prefer to tie it to MCoA --------------------------------------------------------------------------------------------------- Non-WG items --------------------------------------------------------------------------------------------------- - Route optimization for DSMIP draft-oulai-mext-dsmip-v4ro-ps 10 min - Hesham and Desire Mobility in a Dual Stack Internet DSMIPv6 allows tunneling, NAT traversal No solution for Route Optimization over IPv4 clouds Is RO solution worth working on? Should it be done for DSMIPv6 It is defined in 3775 so it probably is important Example solution draft-ouli-mext-dsmip-ro Marcelo - feedback for the authors; let them know if this is interesting, should be worked on. Consider open recharter if there is enough interest George - obvious problem, but not urgent. Will get there eventually, worthwhile looking at Raj - definitely RO is an interesting problem to look at; donŐt see the urgency right now Suresh - I have a solution too; no urgent need --------------------------------------------------------------------------------------------------- - MIPv6 security update 5 min - Raj MIPv6 Security Architecture Update Charlie Follow-up to last IETF Make some provision for alternative security between MN and HA. 3776 and 4877 specified the use of IPsec and IKEv2, but come to the conclusion that it might be the wrong choice, too complex and hacked to work Overly complex security implementation is counter-productive Develop an alternative security architecture, tying the security association more closely to the device identity Proposal Get likeminded folks together to discuss how to develop an alternative; must have well- defined or minimal interactions between MIP6 and security module; must include key exchange Establish a design team (Raj, Charlie, etc) for an approach by IETF75 Hesham - dispute IPsec being wrong before seeing detailed argument; DSMIP the problem was NAT not IPsec. We have to deal with VPN users as Mobile Nodes. We had a nice solution - CGA - instead of IPsec Jari - MN home security not solved by CGA Hesham - could have a public key to work at home Jean-Michel - what do you mean by complexity and hacks? Raj - no good interface between MIP6 and IPsec/IKEv2; you end up building a MIP6 specific IPsec; IPsec is a great solution for a lot of things, not a great fit for MIP6; open to considering all solutions, including CGA. Having to deal with NATs makes it all the worse. J-M - how to manage home address, CoA and security association; Suresh - IPsec not a barrier to the adoption of MIP6, need clear separation. Modular - so some folks use 4285, etc. Terry - PKI root, key lengths, etc. especially internationally. ---------------------------------------------------------------------------------------------------