Yaron Sheffer writes: > - I would have liked to see ESP BEET mode referenced, since it's more widely > implemented than other docs that we do mention. But as far as I know it is > not on track to becoming an RFC.
I agree on that, and I think it might also be good to mention other very widely implemented (expired) drafts which will never come out as RFCs, namely IKEv1 configuration mode (draft-dukes-ike-mode-cfg-02) and IKEv1 xauth (draft-beaulieu-ike-xauth-02). > - 4.1.1: if RFC 2409 is N/A for IPsec-v3, how come RFC 4304 defines the use > of ESN in IKEv1? But you can't expect a Roadmap document to resolve all > issues. As RFC4303 says ESP does not have version number, thus version is only known by the signaling methods or out of band configuration. Use of IKEv2 automatically implies ESP-v3. If IKEv1 is used then that would imply ESP-v2, but RFC4304 explictly defines method of negotiating ESP-v3 feature in IKEv1, thus if that feature is used, then ESP-v3 is also assumed. That is at least my interpretation of the situation... Of course everybody should stop using already obsoleted IKEv1 protocol :-) > - 7.5: I would describe the history differently (I was there...). IPSRA > attempted to tack user authentication onto IKEv1 with no change to IKE. This > indeed proved cumbersome, and the result was the brand new IKEv2, which in > fact adopted some of the IPSRA ideas, primarily the use of EAP. Agree... > - Table 1: There is nothing that limits the Heuristics draft to ipsec-v3. In > facts legacy devices are a major reason for publishing these heuristics. True, altough in IPsec-v2 things are bit easier, as there is no combined mode ciphers i.e. no GMAC, thus no need to detect IV. The draft does not limit itself to either version. BTW, the latest draft is draft-ietf-ipsecme-esp-null-heuristics-01.txt not draft-kivinen-ipsecme-esp-null-heuristics. Other comments: -- It would be much easier to read the document if each document would be easier to detect from each other. Now when moving from one document to next is indicated by even more indented bulletpoint text than the actual text it does not provide good visual feedback to search documents. It might be better to change all document headers to sections (and perhaps exclude them from toc (i.e. add toc="exclude" to them if using xml to rfc)). -- In section 5.2 covering RFC3686 document says: ... AES-CTR is a stream cipher with a 32-bit random nonce (1/SA) and a 64-bit IV, both of which are sent in the packet along with the encrypted data. The description of the random noise and 64-bit IV is correct, but only the 64-bit IV is sent along the packet. The nonce is provided by the IKE with the keying material. There is also draft-ietf-ipsecme-aes-ctr-ikev2-02 to define how that is used in IKEv2 (and as IKEv2 and ESP-v3 share same iana registry there is already number for it). -- For RFC5529 I do not think we need separate RFC to use Camellia-CBC in IKEv2. It is just normal CBC mode algorithm and the generic rules in RFC4306 covers it. As it also already has IANA number I do not see any reason why it cannot be used in IKEv2 too. For the Camellia-CTR the situation is different as generic RFC4306 text only covers CBC mode ciphers, not counter mode ciphers. Perhaps the draft-ietf-ipsecme-aes-ctr-ikev2-02 should be expanded to include more of the counter mode ciphers (i.e. provide generic rules how counter mode ciphers are used in IKEv2)? For the Camellia-CCM there is the RFC5282 which describes how combined mode ciphers are used in the IKEv2. I think that document along with RFC5529 should be enough to specify how Camellia-CCM is used in IKEv2. -- kivi...@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec