While I have not had a chance to go through the draft to comment on the contents but I would definitely vote for the value in the use case. Usage of transport mode doesn't mean no tunnelling; just simply, using a tunnelling method more appropriate for the usage. I would rather be in favour of decoupling tunnelling part from IPSec (any appropriate tunnelling method) so that IPSec is more relevant for wider used cases and vice-versa.
Thanks, Manish On 12/09/14 11:32 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 _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
