Re: comments on draft-nikander-esp-beet

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

Thanks, Jari!

> 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 there something that
>    prevents a more general solution that would be better in
>    line with the general IPsec user community, including MOBIKE?

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.

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

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.


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

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
>    part in the document.

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