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
