Clarifications about HIP (was Re: New multiaddressing review and new MAST draft)

[Pekka Nikander <pekka.nikander@nomadiclab.com>]

>>>          *    Uses strong, cryptographically based protocol details,
>>>               overloading some HIP functionality with security
>>>               functionality
>
...
> Your reference to solving "other identity related problems" is
> what I meant. I think the scope of HIP has been broader than
> just enabling multiaddressing.

I understand.  But maybe you should consider rephrasing.
IMHO, the statement is hard to understand.

>>>          *    Is tied significantly to [IPSEC]

> My point was not about concepts, but about implementation
> and operation.  So I think the concern I was raising was
> that a system cannot use HIP without being required to
> also support IPSec.  Is my understanding of this incorrect?

As I tried to point out, you can implement ESP for HIP yourself,
and then you don't need any IPsec support from the underlying
platform.

> However having implementation and operation dependencies
> -- especially when neither service is yet universal -- is
> problematic.

As I tried to clarify, HIP *can* co-exist with other IPsec usage,
and utilize the ESP implementation from IPsec if it is available.
(Some more details on that can be found in the ongoing charter
discussion on the HIP mailing list.)

>>>          *    Creates a new DNS RR entry
>
> If this is an adjunct feature, then it's probably fine.  If it
> is required for the basic service, then it is a barrier to adoption.

HIP can be used without any DNS entries, in the so called opportunistic
mode.  However, the details still need some thinking to make the
opportunistic mode more efficient.  On the other hand, storing any
long term HIP public keys into the DNS looks like a good practise,
and shouldn't be too hard.  Most people that can modify their kernel
can also change some (forward) DNS entries, too.

>>>          *    Requires that NATs be aware of HIP
>
> My point is that requiring NAT support is a huge barrier to adoption.

With HIP, the NAT issue is really beaty vs. supporting current NAT.
My current, personal preference is to prioritize beaty.  Running the
HIP protocol on the top of UDP instead of IP is not such a big deal,
but running ESP on the top of UDP is pain.  You really should be able
to mux packets based on SPI as well as you can mux them based on
UDP ports.  The trick is to learn the association between the SPIs
in the two directions, and HIP allows the NAT boxes to learn that.

On the other hand, if we do find a way of using HIP without
requiring ESP, then it might make more sense to specify how
to run the HIP protocol over UDP.

> PN> To be more specific, HIP uses ESP as its packet transport
> PN> mechanism.
>
> Does this not mean that you cannot use HIP unless you also
> support IPSec?

Second time:  The answer depends on what exactly you mean
with "support IPsec".  The system must implement ESP
(but not AH or IKE or IKEv2 or claim IPsec compliance).
It doesn't much matter whether ESP is implemented as a
part of HIP, or separately by the system.

--Pekka Nikander