Re: New multiaddressing review and new MAST draft

[Dave Crocker <dhc@dcrocker.net>]

Pekka,

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

The key here, is to be clear about the requirements for security. In
particular, I think we need to be diligent in separating the requirements that
are strictly due to adding multiaddressing, versus the changes that are more
generally interesting and useful.

Let me again stress that I'm not trying to make light of those additional
goals, but want to make sure that we are clear that they are additional. If
satisfying those goals imposes significant challenges to the basic design of
multiaddressing support, then the effort for them should be separated out.


>>      3.5.2.    Host Identity Protocol (HIP)
>>           *    Creates a new, globally unique name space

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

Oh.  Thank you. I completely misunderstood this.


>>           *    Uses strong, cryptographically based protocol details,
>>                overloading some HIP functionality with security 
>>                functionality
PN> I am not quite sure about the word "overload".  That is, I don't
PN> quite understand what you imply with it.
PN> HIP was initially designed to solve other identity related problems but
PN> mobility and multi-homing, with strong focus on security. Rudimentary
PN> mobility support was there from fairly early on, but real mobility support
PN> (with rendezvous) and multi-homing came only afterwards, around the time I
PN> joined the HIP gang a couple of years ago. And the exact details for those
PN> are still being worked on.

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.
And I fear that that makes the design more complicated.


>>           *    Is tied significantly to [IPSEC]

PN> Well, while that is technically correct, the word "significantly"
PN> may give a wrong impression (see below).

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?

Taking ideas and algorithms from other specs, and even "cohabiting" bits of
functionality can be excellent.  I like to do that as much as possible.

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


PN> Furthermore, there are some thoughts of loosening those ties. The problem
PN> is that we haven't found any way to do so without compromising the some
PN> security aspects. It may be possible in the future, though.

I understand.  And that is a strong reason I'm looking to make the
security requirements be as few as is reasonable to support multiaddressing.


>>           *    Creates a new DNS RR entry

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

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.


>>           *    Requires a Rendezvous server for mobility support

PN> Well, it requires rendezvous for con-current mobility. Client mobility or
PN> slow server mobility (with dyndns updates) works pretty well without any
PN> rendezvous servers.

Cool! Again, I had misunderstood this, and thought that the rendezvous server
was required for basic HIT use.


PN> In fact, the rendezvous function has not been fully specified.

(Feel free to take a look at MAST's latest attempt to suggest one...)


>>           *    Requires that NATs be aware of HIP

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

My point is that requiring NAT support is a huge barrier to adoption.


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

PN> Thank you.

No. Thank _you_. I've been stymied on this topic for some years, and it was
only the HIP and SCTP/PBK analysis work that made it possible for me to think
about this more.


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

PN> To be more specific, HIP uses ESP as its packet transport mechanism.

Does this not mean that you cannot use HIP unless you also support IPSec?  I
think that is frankly an significant barrier.  (I think that your next
paragraph means that I am misunderstanding this.)


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

Interesting.


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

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

it probably needs to be moved elsewhere.

Many thanks for the clarifications.


d/
--
 Dave Crocker <dcrocker-at-brandenburg-dot-com>
 Brandenburg InternetWorking <www.brandenburg.com>
 Sunnyvale, CA  USA <tel:+1.408.246.8253>