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

From: Yaron Sheffer <[email-masked]>
Date: Fri, 12 Sep 2014 19:16:23 +0300

Dear working group,

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.

Thanks,
Yaron

---

From: Paul Wouters <[email-masked]>
Date: Fri, 12 Sep 2014 14:02:39 -0400 (EDT)

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

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

---

From: Daniel Migault <[email-masked]>
Date: Sat, 13 Sep 2014 20:20:12 +0200

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-masked]> 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
> _______________________________________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec
>

-- 
Daniel Migault
Orange Labs -- Security
+33 6 70 72 69 58

---

From: Paul Wouters <[email-masked]>
Date: Sun, 14 Sep 2014 18:51:52 -0400 (EDT)

On Sat, 13 Sep 2014, Daniel Migault wrote:

> 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.

Okay, good to know.

> As a result, currently, when one receives USE_TRANSPORT_MODE and MOBIKE_SUPPORTED, it has to chose between supporting MOBIKE or the
> transport mode.

That makes sense to me, because combining the two does not really make
sense.

> 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.

What kind of differences do you meassure? Is it latency? less packet
drops and retransmits?

I take it that mobike ensures the DNS response still comes in on the
correct IP, even if you have changed links. However, I would expect the
DNS answer to get lost anyway if you are switching links and have to
wait on a new IKE SA to be (re)established to re-gain an active IPsec SA
that has your 'inner' IP on it. I would expect those delays to matter
much more than shaving of a few bytes using transport mode instead
of tunnel mode.

I do need to readup on MOBIKE to further understand how one could even
use transport mode SA's for something that's clearly meant as a tunnel
mode SA. I do not understand how the outer IP is used while protecting
the mobike inner IP.

Paul

---

From: Daniel Palomares <[email-masked]>
Date: Mon, 15 Sep 2014 15:45:26 +0200

Hello Yaron,

As a co-author of the draft, I support adopting this draft as a WG
document.
We implemented the very first draft (the first version) that included some
other options that are now deprecated (like flags and versioning, etc).

However, with MOBIKE and USE_TRANSPORT_MODE Notify Payload, the
implementation becomes a lot simpler. IMHO, for example, within an Open
Source implementation like StrongSwan, It wouldn't take more than 30 lines
of code.

BR
Daniel Palomares

2014-09-12 18:16 GMT+02:00 Yaron Sheffer <[email-masked]>:

> Please respond to this mail with a Yes or No and a short rationale, at
> latest by Friday Sep. 19.
>
>  Thanks,
> 	Yaron
>
>
>

---

From: Joe Touch <[email-masked]>
Date: Wed, 17 Sep 2014 15:52:14 -0700

On 9/12/2014 11:02 AM, Paul Wouters wrote:
> die, not see more use. 

See RFC 3884. Just because you're getting rid of IPsec-controlled
tunnels doesn't mean you have to give up tunnels, and using separate
IP-in-IP tunneling has distinct advantages in today's dynamic routed,
virtual networked world.

If you want to pick something to die, please kill IPsec tunnel mode as
an integrated beast.

Joe

---

From: "Valery Smyslov" <[email-masked]>
Date: Thu, 18 Sep 2014 18:24:07 +0400

Hi Yaron,

I think that the draft in its original form doesn't exist now (btw, it seemes to have expired),
as the authors has clearly indicated, that the solution, that was presented
in the draft, is no longer actual, and a new, more simple approach should be taken.
But it is described in no draft yet. Unless we are adopting the problem, and not
the proposed solution, I think it is better to postpone the adoption untill
the new draft describing the new solution is published.

Regards,
Valery.

  ----- Original Message ----- 
  From: Yaron Sheffer 
  To: ipsec 
  Sent: Friday, September 12, 2014 8:16 PM
  Subject: [IPsec] Call for adoption: MOBIKEv2: MOBIKE extension for Transportmode

Dear working group,

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.

Thanks,
	Yaron

------------------------------------------------------------------------------

---

From: "Frederic Detienne (fdetienn)" <[email-masked]>
Date: Fri, 19 Sep 2014 00:19:18 +0000

Answer: yes, should pursue

Transport mode is an important use case.

I concur with Joe Touch’s arguments on Tunnel Mode. There are much more powerful overlay methods than IPsec Tunnel mode yet IPsec/IKE security is the best in its class. In this area, transport mode and is needed.

For native applications, tunnel mode simply adds unnecessary burden and overhead.

MOBIKE for transport mode is relevant and useful even if transport mode is misunderstood.

thanks,

	fred

---

From: "Manish Kumar (manishkr)" <[email-masked]>
Date: Fri, 19 Sep 2014 09:41:06 +0000

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