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