Hi Paul, Thank you for raising the questions, that gives me he opportunity to clarify what have been discussed/agreed in Toronto.
As an author I am supporting the adoption of the document as a WG document. In the Toronto meeting, we agreed that MOBIKE versionning must be removed in the next version of the draft. We also agreed that Security Consideration should discuss more in detail the exposure of the IP addresses. All these will be part of the next version. The next version of the draft will define how MOBIKE and the USE_TRANSPORT_MODE Notify Payload work together. As a result, they will be no MOBIKE versions, the spec will be much simpler, and we will still be fully interoperable / compatible with existing code of MOBIKE -- i.e. code that has not been updated. >From RFC5996 section 1.3.1, the default IPsec mode is the Tunnel mode. When a USE_TRANSPORT_MODE Notify Payload is received. "It requests that the Child SA use transport mode rather than tunnel mode for the SA created. If the request is accepted, the response MUST also include a notification of type USE_TRANSPORT_MODE. If the responder declines the request, the Child SA will be established in tunnel mode. " As a result, currently, when one receives USE_TRANSPORT_MODE and MOBIKE_SUPPORTED, it has to chose between supporting MOBIKE or the transport mode. The next version of the draft, will make possible to respond USE_TRANSPORT_MODE and MOBIKE_SUPPORTED. In all other cases, nothing is changed. Motivations for this are UDP (mostly DNS) but also GRE tunnels. In our opinion, for the DNS use case, saving bytes matters especially when only the responses is returned over a degraded link like WLAN. BR, Daniel On Fri, Sep 12, 2014 at 8:02 PM, Paul Wouters <[email protected]> wrote: > On Fri, 12 Sep 2014, Yaron Sheffer wrote: > > This is a call for adopting draft-mglt-ipsecme-mobikev2 as a WG document. >> Please respond to this mail with a Yes or No and a short >> rationale, at latest by Friday Sep. 19. >> > > This document confuses me. > > It seems section 4 to 7 are about much more than just transport mode. It > seems to (re?)introduce versioning, non-transport notify payloads, etc. > > MOBIKE is about keeping your assigend address with you, making your > inner IP consistent regardless of the outer IP. That makes no sense > with transport mode, which is tied to your ephemeral outer address. > > Transport mode IPsec is terrible idea in todays NATed world. It should > die, not see more use. The NAT issues are not at all mentioned in this > draft. What if two clients connect to the same MOBIKE VPN server with > the same internal IP of 10.1.2.3? > > The use case is "saving a few bytes", which to me seems very weak. > > It would only work with UDP, not TCP. For UDP, doesn't recvfrom() and > recvmsg() family deal with changing IPs? IKE and DNS servers already > use this to listen on ANY and reply to the address of the received > packet. > > This is a lot of specification and code and possible interop problems > for a use case of "saving a few bytes on some UDP packets". > > It is possible further discussion might convince me otherwise, although > not likely. I'm happy to discuss this item further as a working group > if adoption now means we can still decide it is not a good idea later. > If adoption to the WG now means we must end up with some kind of spec, > than I would rather not see adoption now. > > Paul > > _______________________________________________ > IPsec mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/ipsec > -- Daniel Migault Orange Labs -- Security +33 6 70 72 69 58
_______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
