Re: [IPsec] Call for adoption: MOBIKEv2: MOBIKE extension for Transport mode

[Paul Wouters <[e-mail]>]

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