Last Call Review of draft-ietf-hip-bone-
review-ietf-hip-bone-secdir-lc-lonvick-2010-06-20-00

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