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

[Daniel Migault <[e-mail]>]

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 <[e-mail]> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ipsec
>



-- 
Daniel Migault
Orange Labs -- Security
[phone]