I've now done my AD review for draft-ietf-ipsecme-roadmap-05, and have
bunch of comments (most of them minor). Most important first:
- I'm not very happy about the use of MUST, SHOULD, etc. in this
document. This is supposed to be a purely informational guide to other
documents, not something that sets requirements (of any level) for
anyone.
For cryptographic algorithms, we already have separate documents that
specify the requirement levels. IMHO repeating them here just means
the two places will soon be inconsistent (which is not helpful for the
audience here). If the WG has considered this and decided the
repeating them here is useful, I would strongly suggest just having
the tables in Appendix B (with explicit note that they're probably out
of date by the time the reader finds them), and removing them from
Section 5.x.
For things other than cryptographic algorithms, I'm not sure if
talking about "requirements levels" even makes that much
sense. Consider, for example, Section 4.2.4.2 (IKEv2 redirect):
Requirements levels for RFC5685:
IKEv1 - N/A
IKEv2 - optional
This is not really specifying any requirement level; a phrasing
like "This extension applies only to IKEv2, not IKEv1" would IMHO
be more accurate. Text in most other sections (than crypto algs)
could be rephrased similarly.
- Appendix B: I'm trying to match table B against RFC 4307/4835 and
I can't quite get them to match. For example, RFC 4307 lists
AUTH_AES_XCBC_96 as "SHOULD+", while the column "IKEv2" here says
"optional". This suggests that perhaps even including this table
isn't such a good idea...
- Section 5.4: "Since combined mode algorithms are not a feature
of IPsec-v2, these IKEv1 implementations are used in conjunction with
IPsec-v3." I'm not sure if this is really a good way to describe
the situation; after all, GCM-for-ESP (RFC 4106) predates IPsec-v3...
I'd suggest something like "Although IPsec-v2 ESP [RFC2406] did not
originally include combined mode algorithms, some IKEv1
implementations have added the capability to negotiate combined mode
algorithms for use in IPsec SAs; these implementations do not include
the capability to use combined mode algorithms to protect IKE SAs."
Analogous changes are needed in 5.4.1, 5.4.2, 5.4.3, and 5.6.2.
- Section 5.4.1: "[RFC4309] includes IANA values for use in ESP-v3";
ESP doesn't have any IANA registries; IKEv1 and IKEv2 do. RFC 4309
is included in both.
- Quite many IETF protocols use (or can use) IPsec to protect their
traffic, so we have *lot* of RFCs that specify how to configure IPsec
for use X (ranging from RADIUS and Diameter to iSCSI and TGREP).
I don't think these belong in the IPsec document roadmap, unless they
modify/extend how IPsec works (e.g. define new payloads/something
for IKEv1/v2, or change the IPsec processing somehow).
With this in mind, I'd suggest deleting 8.1.1, 8.1.2, and 8.2;
rephrasing 8.1.3 and 8.1.4 to explain their impact on IPsec;
deleting 8.1.5/8.1.6/8.1.7 and adding RFC 5026 (text below).
Proposed new text for 8.1.3:
This document specifies the use of IPsec in securing Mobile IPv6
traffic between mobile nodes and home agents. Mobile IPv6 requires
considering the Home Address destination option and Routing Header
in IPsec processing. Also, IPsec and IKE security association
addresses can be updated by Mobile IPv6 signaling messages.
Proposed new text for 8.1.4:
This document updates [RFC3776] in order to work with the revised
IPsec architecture [RFC4301]. Since the revised IPsec architecture
expands the list of selectors to include the Mobility Header message
type, it becomes much easier to differentiate between different
mobility header messages. This document also specifies the use
of IKEv2 configuration payloads for dynamic home address configuration.
Proposed text for RFC 5026:
This document extends [RFC4877] to support dynamic discovery of
home agents and the home network prefix; for the latter purpose, it
specifies a new IKEv2 configuration attribute and notificatio7n.
- Section 5.x: IMHO lines like "ESP-v2 - undefined (no IANA #)"
are a bit confusing, because ESP does not have any IANA registries;
the registries are specific to a key management protocol (IKEv1,
IKEv2, Photuris, KINK, HIP, ...).
- Section 5.7.4: "It also includes 3 EC DH groups (groups 19-21) that
were previously defined in [RFC4753]". The normative specification
for groups 19-21 in IKE is still 4753/5753bis, so I would propose
just omitting this sentence.
- I would suggest moving 3.2/3.3 somewhere later in the document -- as
the document already says, this is not really deployed stuff, and
might fit better in e.g. Section 7.
- IMHO MOBIKE would belong together with other IKEv2 remote
access extensions in Section 4.2.4?
- Should RFC 2521 be mentioned? (it's largely obsolete, I guess, but
for completeness..)
- What about RFC 2709? (it's definitely obsolete, but things like
this influenced t
