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

"Manish Kumar (manishkr)" <manishkr@cisco.com> Fri, 19 September 2014 09:41 UTC

From: "Manish Kumar (manishkr)" <manishkr@cisco.com>
To: Paul Wouters <paul@nohats.ca>, Yaron Sheffer <yaronf.ietf@gmail.com>
Thread-Topic: [IPsec] Call for adoption: MOBIKEv2: MOBIKE extension for Transport mode
Thread-Index: AQHPzrPWRLwerj0eMEKLxt9Gpu/v4JwI7j2A
Date: Fri, 19 Sep 2014 09:41:06 +0000
Message-ID: <D041F68C.27F1D%manishkr@cisco.com>
References: <54131C57.2060605@gmail.com> <alpine.LFD.2.10.1409121350180.31178@bofh.nohats.ca>
In-Reply-To: <alpine.LFD.2.10.1409121350180.31178@bofh.nohats.ca>
Accept-Language: en-IN, en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/14.4.1.140326
Content-Type: text/plain; charset="us-ascii"
Content-ID: <AD788B69AECA2E4F89505824DEC2146E@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/ZSSBsKpzmESmlXoMHqX87Sk4bWc
Cc: ipsec <ipsec@ietf.org>
Subject: Re: [IPsec] Call for adoption: MOBIKEv2: MOBIKE extension for Transport mode
Precedence: list

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" <paul@nohats.ca> 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
>IPsec@ietf.org
>https://www.ietf.org/mailman/listinfo/ipsec

[IPsec] Call for adoption: MOBIKEv2: MOBIKE exten… Yaron Sheffer
Re: [IPsec] Call for adoption: MOBIKEv2: MOBIKE e… Paul Wouters
Re: [IPsec] Call for adoption: MOBIKEv2: MOBIKE e… Daniel Migault
Re: [IPsec] Call for adoption: MOBIKEv2: MOBIKE e… Paul Wouters
Re: [IPsec] Call for adoption: MOBIKEv2: MOBIKE e… Daniel Palomares
Re: [IPsec] Call for adoption: MOBIKEv2: MOBIKE e… Joe Touch
Re: [IPsec] Call for adoption: MOBIKEv2: MOBIKE e… Valery Smyslov
Re: [IPsec] Call for adoption: MOBIKEv2: MOBIKE e… Frederic Detienne (fdetienn)
Re: [IPsec] Call for adoption: MOBIKEv2: MOBIKE e… Manish Kumar (manishkr)