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

From: Chris Lonvick <[email-masked]>
Date: Thu, 10 Jun 2010 19:22:37 -0700 (PDT)

Hi,

I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG.  These comments were written primarily for the benefit of the
security area directors.  Document editors and WG chairs should treat
these comments just like any other last call comments.

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?

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

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.

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.

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.

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

Regards,
Chris

---

From: Ari Keränen <[email-masked]>
Date: Tue, 15 Jun 2010 18:34:08 +0300

Hi Chris,

Thanks for the review! Comments inline.

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

> traffic.  Is this what is envisioned for a client joining a HIP 

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.

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

>        it may be a hash of a public key.

Makes sense, I'll fix this.

>        be reachable at because there is an active HIP association with the

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.

> 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