Subject: [Mobike] comments on draft-nikander-esp-beet

From: Jari Arkko <[email-masked]>
Date: Tue, 21 Mar 2006 13:40:58 -0600

I have read the draft. Overall, its well written and specified. I do
have a number of comments, however:

o  The fact that you are not doing full tunnel mode semantics limits
    the application of this mode. For instance, in typical VPN setup
    we do need the full semantics but would still perhaps appreciate
    compressed headers.

    Is there a solution that would allow this? I understand the
    role of the BEET in the HIP context and how the inner identifiers
    work, and the architecture. But is tehre something that
    prevents a more general solution that would be better in
    line with the general IPsec user community, including MOBIKE?

o  Without the generalization to full tunnel mode, I think BEET
    is something that can only be with MOBIKE when you use
    either direct connections to the specific peers that you want
    to talk to. This is something that is potentially useful, but
    not as useful as the general solution would be. The limited
    solution would though become more useful if we assume a
    future where BTNS exists and can be used in connection with
    MOBIKE and BEET.

    Question: does BEET prevent usage in a situation where
    a VPN gateway is used but the IPsec SAs are specific to
    the peers that the client communicates with? I.e., not end
    to end usage but inner addresses are fixed per SA pair.

o  I remained unconvinced that the Mobile IP section is matches
    what people would like to do (or even that its correct). I can
    talk about the details off line, but my point is that the integrated
    use of BEET in application X would require further work, and
    might not be something that you want to commit to.

o  If this work comes to MOBIKE, I'd rather not see the PF_KEY
    part in the document.

--Jari

_______________________________________________
Mobike mailing list
[email-masked]
https://www.machshav.com/mailman/listinfo.cgi/mobike

---

From: Pekka Nikander <[email-masked]>
Date: Tue, 21 Mar 2006 16:14:45 -0600

> have a number of comments, however:

Thanks, Jari!

>    work, and the architecture. But is there something that

Not supporting full tunnel semantics is intentional in BEET.
We did want to support only a bound pair of inner IP addresses.
Full tunnel semantics requires that different packets can have
different inner IP addresses.  In general, if you allow any
addresses within the tunnel, you can't compress the addresses
to nothing but need to present something in the packet, at
least one bit.  Hence, if we want to go to that direction, I
would apply normal header compression protocols instead of BEET.

Conversely, BEET can be and should be seen from three different
points of view.  Compressing inner IP header to zero bytes is
just one.  The other two are making transport mode address agile,
and allowing ESP to function as a *secure* place in the stack
for implementing identifier / locator split.

>    to end usage but inner addresses are fixed per SA pair.

There are no technical reasons why BEET could not be used
between a end-host and a VPN gateway (in a road warrior
fashion), nor between two security gateways, as long as
the inner IP addresses are kept fixed.

The reason why this is explicitly forbidden in the current
draft is that back when the draft was initially written, I
didn't understand the potential security consequences of such
usage, and I am still unsure.  In other words, if someone did
a proper security analysis on those use cases, I think they
could be fairly easily supported.  There may be some caveats
that must be documented, but I wouldn't expect any protocol
changes.

>    talk about the details off line, but my point is that the
>    integrated use of BEET in application X would require further
>    work, and might not be something that you want to commit to.

OK; the Mobile IP section is based on what Mobile IP people
told me, and I may have gotten it wrong.

> o  If this work comes to MOBIKE, I'd rather not see the PF_KEY

Fine with me.  OTOH, I do think that the various PF_KEY extensions
out there should be gathered somewhere and at least documented,
if not standardised.

--Pekka