Re: New multiaddressing review and new MAST draft

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

Dave,

Firstly, I very much agree with Marcelo wrt. his comment
about security.

Secondly, some specific comments about the HIP section:

>      3.5.2.    Host Identity Protocol (HIP)
>      
>      HIP works with IPv4 and IPv6.  Also, it:
>      
>           *    Creates a new, globally unique name space

You may consider adding "probabilistically", since the only
currently defined type of HIs are public keys.  HIP does not
assume any key registry, and therefore the uniqueness of host
identifiers is only probabilistic.

(I also suspect that none of the current implementations supports
 resolving HIT conflicts, even if the spec requires that.  However,
 even with that the probability of conflicts is very low.)

>           *    Uses strong, cryptographically based protocol details,
>                overloading some HIP functionality with security 
>                functionality

I am not quite sure about the word "overload".  That is, I don't
quite understand what you imply with it.

HIP was initially designed to solve other identity related
problems but mobility and multi-homing, with strong focus
on security.  Rudimentary mobility support was there from
fairly early on, but real mobility support (with rendezvous)
and multi-homing came only afterwards, around the time I
joined the HIP gang a couple of years ago.  And the exact
details for those are still being worked on.

>           *    Is tied significantly to [IPSEC]

Well, while that is technically correct, the word "significantly"
may give a wrong impression (see below).  Furthermore, there are
some thoughts of loosening those ties.  The problem is that we
haven't found any way to do so without compromising the some
security aspects.  It may be possible in the future, though.

>           *    Creates a new DNS RR entry

Correct.  However, for the time being we will use IPSECKEY,
which is in IESG review, I think.

>           *    Requires a Rendezvous server for mobility support

Well, it requires rendezvous for con-current mobility.  Client
mobility or slow server mobility (with dyndns updates) works
pretty well without any rendezvous servers.  In fact, the
rendezvous function has not been fully specified.

Hence, I would suggest changing "mobility" to "con-current" mobility
(or something equivalent that matches with your overall terminology).

>           *    Requires that NATs be aware of HIP

This was an explicit design choice.  It would be possible to
make HIP work using UDP tunneling, but we chose not to do so.
At least not yet.  If there is real need for that, such support
could be added, but the result would not be pretty any more.

>      Many of the HIP features are appealing, such as the cleanliness
>      of the architectural model depicted in Section 4 of the HIP
>      architecture document.  Were the Internet stack being created
>      now, HIP well might be an excellent approach. 

Thank you.

>      However
>      retrofitting this approach into the existing, deployed Internet
>      entails serious barriers to adoption, such as its dependence on
>      IPSec.

I am not quite sure how serious the alledged barriers are.
HIP does require changes to the stack, yes.  It introduces
a kind of shim or wedge, just like MAST or LIN6.  It does
not work with current NAT boxes, but that has been an explicit
design choice for the time being.

A word about dependence with IPsec.  HIP uses only a small
portion of IPsec, and supports only a small subset of the
current functionality that full IPsec implementations support.
On the other hand, HIP requires virtually no configuration,
while the current IPsec implementations require a considerable
amount of configuration and expertese.

To be more specific, HIP uses ESP as its packet transport
mechanism.  It integrates well with the current IPsec
processing model, and is able to co-exist with other
IPsec based secure connections.  On the other hand, it is
also possible to implement the ESP functions that HIP
requires completely independent on any IPsec code in the
stack.  One of the existing implementations uses this
approach, and contains a user level ESP implementation.

Hence, I don't immeditely see any serious barries for HIP.
But maybe I am blind in this issue.  Well, if you consider
the NAT issue as such, then be it so.  Otherwise I would
fairly strongly disagree with your statement.

>      In general, addition of a DNS SRV record can be useful for
>      achieving efficient rendezvous, with or without mobility.  It
>      permits participants to know whether a service is supported by
>      its partner, without requiring a probe packet.  While beneficial,
>      this enhancement to DNS data structures is not required for
>      multihoming or client (initiator) mobility.

I am not quite sure what the paragraph above has to do with HIP.

--Pekka Nikander