Document: Reviewer: David L. Black Review Date: November 19, 2006 IETF LC End Date: November 19, 2006 These drafts are on the right track, but have open issues, described in the review. The drafts are in very good shape - the key security areas are well- specified, and in some cases better than some of what I've seen in IPsec drafts. The open issues are those not marked as nits below - the only one that looks potentially serious/difficult is the dependence on IP fragmentation. Nit: The phrase "standard authenticated Diffie-Hellman key exchange for session key generation" occurs starting in Section 4.1 - explain what "standard" means. The treatment of Opportunistic Mode in Section 4.1.6 is "interesting" for a security protocol document in that it deliberately omits the details and security considerations. If this draft were headed for Proposed Standard RFC status, that would be grounds for removal of Opportunistic mode, but this draft is headed for Experimental RFC status, for which the lack of details may be acceptable. If the Security Area has not already commented on this (e.g., in the secdir review), please bring this issue to their attention. Section 5.1.3 indicates a reliance of HIP on IP fragmentation. IP fragmentation is becoming increasingly troublesome, so this will be a problem in practice. The corresponding reliance on IP fragmentation for IKE is a known cause of problems with certificates, as the size of some certificates is a common cause of IP fragmentation with UDP/IP. At a minimum, this section should carry a strong recommendation that the separately-specified HIP support for certificates support Hash & URL certificate formats in order to avoid certificate sizes that will cause IP fragmentation. Certificates are a major cause of IP fragmentation in IKE, particularly when chains are involved. The text in Section 5.3.2 on Diffie-Hellman value reuse could use some clarification. The underlying issue is that the HIP exchange does not use the nonces that IKE and IKEv2 use, which makes DH value reuse significantly more dangerous. The current text says that DH values SHOULD not be reused unless the system is under attack (I1 storms), in which case they MAY be reused. This appears to drop the level of security in response to an attack, which may not be the best course of action. I don't want to say that HIP ought to use IKE-like nonces, but this text appears to need some more thought. Section 5.3.3 doesn't discuss DH value reuse. It should. Section 5.3.6 and Section 6.13 need more precision on the sorts of "state information changes" that SHOULD NOT be made as a consequence of receiving a NOTIFY packet. Section 6.5 needs to specify how to calculate the Diffie-Hellman Kij value. Nit: In Section 6.6.1, the connection between limitations on sending I1's and DoS attacks is not clear. A DoS attacker will not respect the limitations in this section, so the discussion might be in terms of not making a bad situation worse (probably already covered under "network congestion") or detection of a DoS attack at the receiver by determining that the sender is not observing these limitations. Nit: In Section 9, please give IANA some guidance on how to deal with the unused Notify Message Type values that are less than 42.