[IPsec] Comments on draft-ietf-ipsecme-roadmap-00

Hi Sheila, Suresh,

Overall, this is a very impressive document, both clear and extensive. Thanks so much!

Here are some comments, and some suggested text. Everyone on the list is most welcome to suggest text for their favorite RFCs.

- 2.1: I suggest to unify the 3 Algorithm boxes in the figure into one, "Algorithms". There are also documents describing HMAC, and describing D-H groups.
- 2.2: for the "earlier version", please mention the RFC numbers (1825-1829).
- 2.2.1: but in IPsec-v3 you still need the dest address to distinguish SAs, e.g. if you're on a gateway.
- 2.3.1: why use the older term "IPsec SA", instead of the newer "Child SA"?
- 2.3.1: I think the incorporation of EAP is important enough to be on the list of changes.
- 2.4: suggest to remove the last 3 bullets, which are way outside the core IPsec.
- 3.2: RFC 3585, please add "this RFC has not been widely adopted". Similarly (AFAIK) for RFC 4807 in Sec. 3.3, and RFC 3884 in Sec. 3.4.
- 3.4: suggested blurb for draft-ietf-ipsecme-traffic-visibility:

ESP, as defined [RFC4303], does not allow a network device to easily determine whether protected traffic that is passing through the device is encrypted, or only integrity-protected. This document extends ESP to provide explicit notification of integrity-protected packets, and extends IKEv2 to negotiate this capability between the IPsec peers.

- 4.1.1: I suggest to add the following introductory paragraph.

While historically IKEv1 was created by combining two security protocols, ISAKMP and Oakley, in practice the combination (along with the IPsec DOI) has commonly been viewed as one protocol, IKEv1. The protocol's origins can be seen in the organization of the documents that define it.

- 4.1.2: suggested blurb for Bis:

This document combines the original IKEv2 RFC with the Clarifications, and resolves many implementation issues discovered by the community since the publication of these two documents.

- 4.2.3: the section number appears twice!
- 4.2.3: DPD: mention that in IKEv2 this has been incorporated into the protocol.
- 5: typo: SA}s
- 5.1: the note that claims "by inference" that RFC 4835 applies to IPsec-v2 seems debatable to me, in view of Sec. 6 of that document.
- 5.2: I have an issue with the distinction we're making between stream ciphers and block ciphers. We should not be sending the message that integrity protection can be sometimes omitted.
- 5.3: just because we don't like HMAC-MD5, this is no reason not to cover RFC 2403. Moreover, it is still a MAY in RFC 4835, which also says, "Weaknesses have become apparent in MD5 [MD5-COLL]; however, these should not affect the use of MD5 with HMAC".
- 5.4: please add an introductory note explaining combined algorithms.
- 5.5: similarly, please add an introductory note explaining pseudo-random functions.
- 5.7: SMIME => S/MIME. And you probably meant TLS/SSL, not SSH.
- 7.4: we should point out that there are no known KINK implementations (AFAIK).
- 7.5: similarly, are there any implementations of DHCP as described in RFC 3456?
- 7.6: and IPsecKEY, too.

Thanks,
            Yaron

Email secured by Check Point