Hi all, Russ Housley has updated his DISCUSS to be the following (Russ see question in on point 2 below):
1) I had many, many comments on section 8.3. My comments were longer than the section itself. Given that, I decided to provide replacement text instead of the comments. The basis of most of these changes is alignment with draft-ietf-ipsec-esp-ah-algorithms-01, which is has just been forwarded to the IESG by the IPsec WG. Here is my proposed text: Current IPsec RFCs specify the support of transforms and algorithms for use with AH and ESP: NULL encryption, DES-CBC, HMAC-SHA-1-96, and HMAC-MD5-96. However, "Cryptographic Algorithm Implementation Requirements For ESP And AH" [CRYPTREQ] contains the current set of mandatory to implement algorithms for ESP and AH. It also specifies algorithms that should be implemented because they are likely to be promoted to mandatory at some future time. IPv6 nodes SHOULD conform to the requirements in [CRYPTREQ] as well as the requirements specified below. Since ESP encryption and authentication are both optional, support for the NULL encryption algorithm [RFC-2410] and the NULL authentication algorithm [RFC-2406] MUST be provided to maintain consistency with the way these services are negotiated. However, while authentication and encryption can each be NULL, they MUST NOT both be NULL. The NULL encryption algorithm is also useful for debugging. The DES-CBC encryption algorithm [RFC-2405] SHOULD NOT be supported within ESP. Security issues related to the use of DES are discussed in [DESDIFF], [DESINT], [DESCRACK]. DES-CBC is still listed as required by the existing IPsec RFCs, but updates to these RFCs will be published soon. DES provides 56 bits of protection, which is no longer considered sufficient. The use of HMAC-SHA-1-96 algorithm [RFC-2404] within AH and ESP MUST be supported. The use of HMAC-MD5-96 algorithm [RFC-2403] within AH and ESP MAY also be supported. The 3DES-CBC encryption algorithm [RFC-2451] does not suffer from the same security issues as DES-CBC, and the 3DES-CBC algorithm within ESP MUST MUST be supported to ensure interoperability. The AES-128-CBC algorithm [RFC-3602] MUST also be supported within ESP. AES-128 is expected to be a widely available, secure, and efficient algorithm. While AES-128-CBC is not required by the current IPsec RFCs, it is expected to become required in the future. -> Resolution: I think that the text is fine, I will update the document accordingly -> Question to Russ - how to handle IKEv1 vs. IKEv2? What would be a reasonble reference here? 2) In section 8.4, one of my previous comments was rejected without explanation. I said: "I am uncomfortable with support for IKE being a MAY. It ought to be a SHOULD." While I understand that an Informational document is an inappropriate vehicle to impose this requirement, the deployment benefits can be pointed out. I believe that the 1st paragraph of section 8.4 needs further explanation. A security association is identified by a triple consisting of a Security Parameter Index (SPI), an IP Destination Address, and a security protocol identifier (either AH or ESP). So, manual key management involves a bit more than inserting the same cryptographic key in communicating peers. This document should not specify how that is done, but it should indicate that it needs to be done. -> Resolution: I could update the text from MAY to a SHOULD, does the WG feel this is reasonable? 3) Comment: The first paragraph of the Introduction says: "... all IPv6 nodes can be expected to implement the mandatory requirements listed in this document." How can this be true unless it is published on the Standards Track or as a BCP? Perhaps it out to say that it summarizes the requirements from other published Standards Track documents to put them all in one place. The second paragraph of the Introduction does not sound like something that ought to be said in an Informational RFC. -> I will prepare text to fix this. 4) Section 4.5 requires all hosts to support IPv6 Stateless Address Autoconfiguration as defined in RFC 2462. It ought so say that support for static addresses is okay too. -> Resolution: this is reasonable, I will update the text. What I need from the WG is sign-off on point 2 above. I will submit the rest of the text for review either tonight or first thing tomorrow AM. John -------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------