Re: [secdir] secdir review of draft-ietf-hip-bone

[Ari Keränen <[e-mail]>]

Hi Chris,

Thanks for the review! Comments inline.

On 06/11/2010 05:22 AM, Chris Lonvick wrote:
> I have not been keeping up with the discussions of this working group.  I 
> read through this document and skimmed through RFC-5201.  I remain 
> confused on a couple of topics.  If they are explained somewhere, please 
> just give me a general pointer and don't bother explaining to me (as I 
> will likely continue to not keep up with this WG. :-)
> 
> - Obviously a host can join two HIP instantitions.  What happens when the 
> overlay identifiers conflict?  Must the overlay identifiers be globally 
> unique or can they have local context?

The idea behind overlay identifiers is that they are statistically 
unique, i.e., the chance for two overlays picking up the same ID is 
really low. However, if this happens, a node that is already part of an 
overlay can not join the other overlay with the same ID. The exact 
behavior, error message signaling, etc. depends on the HIP BONE instance 
and the peer protocol that the instance is using (e.g., 
draft-ietf-hip-reload-instance and its peer protocol 
draft-ietf-p2psip-base).

So, the identifiers need not to be globally unique as long as a single 
node does not see the same ID more than once at the same time. That 
said, nothing prevents using a centralized entity giving out Overlay IDs 
that would not clash.

> - When a host joins a HIP instantiation, is this exclusive?  Can a host 
> that has joined a HIP instantiation continue to directly communicate with 
> IPv4 and IPv6 hosts or must it communicate through a gateway?  Here I'm 
> thinking of a device that fires up IPsec - in my experience the policy is 
> to encrypt all traffic to the gateway and then let the gateway forward 
> traffic.  Is this what is envisioned for a client joining a HIP 
> instatiation?

A host can continue using standard IPv4 and v6 connections despite being 
part of an overlay, but also a "default gateway" kind of scenario you 
mentioned is possible. Section 5.2 has some text about deciding whether 
messages should be sent via an overlay, but essentially, it's about 
local policy and configuration.

> The only real security concern I have in the document is in section 6.1, 
> where you RECOMMEND 32 bits of randomness be used in the OVERLAY_ID 
> parameter.  I don't understand why this is recommended or what purpose it 
> may have.  What I'm saying is that even if you have 2 HIP BONE instances 
> throughout the Internet, there is a non-zero chance that the OVERLAY_ID 
> parameters will be identical unless people intervene and choose the 
> values.  The chances increase with more instances regardless of how many 
> bits of randomness you may recommend - reference the "birthday attack". 
> I'd suggest that you drop the recommendation for randomness and just 
> recommend that people attempt to prevent a collision via any means 
> possible.  Continuing to recommend some amount of randomness would give 
> people a false sense that a collision may not occur.

OK. The idea here was to have a minimum amount of randomness to give 
sufficiently small chances for an ID clash. I'll rephrase that to 
recommended "any other means possible" instead.

> Some nits from the document:
> In Section 2 two things:
> CURRENT:
>     Node ID:  A value that uniquely identifies a node in an overlay
>        network.  The value is not usually human-friendly, but for example
>        a hash of a public key.
> PERHAPS SHOULD BE:
>     Node ID:  A value that uniquely identifies a node in an overlay
>        network.  The value is not usually human-friendly.  As an example
>        it may be a hash of a public key.

Makes sense, I'll fix this.

> CURRENT:
>     Valid locator:  A Locator (as defined in [RFC5206]; usually an IP
>        address or an address and a port number) that a host is known to
>        be reachable at, for example, because there is an active HIP
>        association with the host.
> PERHAPS SHOULD BE:
>     Valid locator:  A Locator (as defined in [RFC5206]; usually an IP
>        address, or an address and a port number) that a host is known to
>        be reachable at because there is an active HIP association with the
>        host.

A host could be known to be reachable even if there is no active HIP 
association, so I'd keep the original form for the definition giving the 
HIP association only as an example.

> From that, what is a "HIP association"?  Perhaps you mean to say that the 
> host is part of a HIP overlay network?  Just fyi, "HIP association" is 
> used elsewhere in the text and in RFC-5201.  If it's important then you 
> may want to define it here as well.

As RFC5201 defines it, HIP association is "an IP-layer communications 
context" (established using HIP). I'll add that to the terminology section.


Cheers,
Ari