At 10:56 PM -0400 7/11/10, <[email protected]> wrote: >Section 2.2 lists the RFC # range for IPsec-v1. Please also list the RFC # >ranges for IPsec-v2 and IPsec-v3.
Disagree. The definition of IPsec-v2 and -v3 is complicated, as is clear from the document. Listing RFCs here will send the wrong message. >** Sections 5.4.1 and 5.4.2 both contain a NOTE stating that combined mode >algorithms are "not a feature of IPsec-v2" and hence lists them as N/A. >That's not correct. The correct situation is: >- Combined mode algorithms for ESP can be negotiated as encryption > algorithms (the integrity protection algorithm would typically > be omitted proposals that do this). >- Combined mode algorithms cannot be used with IKEv1, as they're > incompatible with its design (see the Introduction section of > RFC 5282 for a more detailed explanation). >Hence the N/A entries for IKEv1 are correct, but both AES-CCM and AES-GCM >should be "optional" for ESPv2 (and the NOTE should be revised accordingly). I am having a hard time following your logic here. Where in "IPsec-v2" do you see combined modes as being defined? I agree that they can be negotiated for ESP; why does that make them a feature for all of IPsec-v2? >Section 5.4.3 - RFC 5282 is based on a combined mode framework in RFC 5116. I think you meant this for 5.4.4. It is a reasonable addition. >Section 8.4.1 appears to apply to IPsec-v2 only, and not IPsec-v3. If that is >correct, it should be stated. Good catch, it should be stated. >Section 8.8.1 also appears to be IPsec-v2 only, and in addition to stating >that should comment that this was not widely adopted, and NAT traversal is the >commonly used mechanism to deal with NATs. RFC 2709 was only a model, not a protocol. The model and protocol are both part of IPsec-v3, but RFC 2709 was not "part of" IPsec-v2 in that it was suggestions for deployment. >In Section 9.2.1, "Fibre Channel/SCSI" --> "Fibre Channel". Agree. >If you want to cite the RFCs involved, IP over FC is RFC 4338 and FC over IP >is RFC 3821. I don't those help here. >idnits 2.12.04 found some minor nits: > > ** There are 4 instances of too long lines in the document, the longest one > being 3 characters in excess of 72. These are non-visible gremlins; the RFC Production Center can squash them easily. --Paul Hoffman, Director --VPN Consortium _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
