Re: visibility of identifier in shim6 payload packet

[Jari Arkko <jari.arkko@piuha.net>]

marcelo bagnulo braun wrote:

>
> shim without proper security is simply inacceptable. We must provide a
> security mechanism (at least one) from the start of the shim will not fly.

I fully agree with this.

> And saying use IPSec in the security considerations section will not
> fly, because oportunistic IPSec does not make a proper job and pre
> shared keys and PKI are not feasible in the short term.

The short version of my opinion is that I do
not see IPsec as a mechanism that satisfies
the goals of Shim6.

The longer version: I do like modular design,
and I don't mind having the possibility of several
different methods, possibly including IPsec, to
exist in addition to the mandatory to implement
mechanism for Shim6.

However, I believe that the low-hanging fruit for
IPsec use in the multihoming and mobility space
has already been picked, and that trying to do
something as ambitious as Shim6 with IPsec
as the primary mechanism would not succeed.

The low-hanging fruit is MOBIKE. This protocol
provides multihoming and mobility functions, and
it assumes that sufficient security associations
already exist for other reasons. In practical terms
this translates to usage in the VPN space, between
the VPN client and the VPN gateway. Its very easy
to deploy and it works. But its also already done,
and I see no reason to design new protocols that
do the same thing.

Also, extending this functionality to host to host
behaviour would face significant challenges.
There is no global authentication infrastructure
between hosts, and its not clear to me that such
infrastructure would even be desirable. Furthermore,
if the protocols were lightweight (no per packet
protection) as the Shim6 WG wanted, even
an authentication infrastructure would not
help at all, unless it had knowledge of which
hosts owned which addresses.

There is one design option which does seem
plausible, however, and does not require
authentication infrastructure. Namely,
opportunistic mode where all communications
are always bound to an ephemeral identity.
But this is again something that has already
been built -- HIP.

So from my point of view the only design that
can be made to match the requirements that
the Shim6 WG felt where important -- deployability,
ability to deal with referrals, avoiding overhead,
etc. is in the current documents. We can add
modularity and secondary authentication tools
if people feel that is important, however.

--Jari