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

[Chris Lonvick <[e-mail]>]

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