- draft-ietf-ipsecme-ikev2-ipv6-config is no longer on the Standards Track.
- KINK and BTNS should be all-caps. Similarly MOBIKE.
- 3.1: "IPsec protections are provided by two extension headers" - this is
true for IPv6, I don't think the term is applicable to IPv4.
- In fact, it would be nice if Sec. 3 mentioned that IPsec and IKE apply
equally to IPv4 and IPv6. It may be trivial to IPsec folks, but it isn't
really.
- 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.
- "Requirements levels for RFC3715" are meaningless - this is a requirements
document.
- 4.1.1: the relation of IKEv1 and Oakley, as described here, is confusing.
Because the Oakley *document* is informational, so you only need to read the
other 3 docs as an implementer.
- 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.
- 4.2.3: "dead peer detection (DPD) is an integral part of IKEv2", but now
renamed to "liveness test" or "liveness check".
- 4.2.4: why say that session resumption "requires changes to IKEv2"? It is
an extension like many others. Similarly for the Redirect draft.
- 4.2.4: typo in the reference: psecme-2.
- 5.2: please add a reference to the new AES-CTR document (also requires to
change Table 2).
- 5.4.1: shouldn't we mention that RFC 5282 is based on a more generic AEAD
framework (RFC 5116)?
- 5.6: please define what is "Suite B" (a newcomer would be confused by the
different uses of the word "suite" here).
- 6: typo: "[RFC5197] provides in in-depth".
- 7.3: Sec. 1 of RFC 5386 makes it clear that it does *not* apply to IKEv1,
or at least cannot be applied to all implementations. In addition, there is
great confusion surrounding the term "unauthenticated security associations"
in the BTNS context, but the IPsec Roadmap is not the place to deal with
this issue.
- 7.4: I wouldn't say KINK is *another* attempt to provide an alternative,
because BTNS is not an alternative, it is just an IKE (and RFC4301) tweak.
- 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.
- 8.3: this section could be improved by explaining what HIP is. It is
fashionable ("hip") to quote Wikipedia, so here goes: The Host Identity
Protocol (HIP) is a host identification technology for use on Internet
Protocol (IP) networks, such as the Internet. The Internet has two main name
spaces, IP addresses and the Domain Name System. HIP separates the end-point
identifier and locator roles of IP addresses. It introduces a Host Identity
(HI) name space, based on a public key security infrastructure.
- 8.3: typo: "for for describing".
- The description of RFC5206 has mismatched parenthesis.
- 8.7: I agree with Yoav we should include the "almost published" ROHC
documents.
- 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.
Thanks,
Yaron
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
