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 the design of the current IPsec NAT-T, like
using a different port number to avoid any 2709-like stuff :-)
- Should we include RFC 3329? It does (partly) specify the
"3gpp-ipsec" mechanism for setting up IPsec SAs (basically, a simple
key management protocol instead of IKE), and this is something that is
actually implemented (however, some of the details needed to implement
this are not actually in 3329, but only in 3GPP specs...)
- Section 8.5.1: this has an IKE extension (to pretty core
part of IKE), so might belong in Section 4.2 instead.
- RFC 4322 probably should be mentioned somewhere (near BTNS and/or
IPSECKEY).
- Section 8.8.1: suggest adding something like "It also defines how
public key fingerprints (hashes) are distributed via BGP, and used
later to authenticate IKEv2 exchange between the tunnel endpoints."
- Section 6: MIKEY (as specified in IETF RFCs) creates security
associations for SRTP, not IPsec -- so it's not really relevant for
this document (some other SDOs have extended MIKEY to create IPsec
SAs, but that's an area we IMHO don't need to cover in this roadmap).
So Sections 6.(7,8,9,10,12,13) should be dropped.
- Section 6.1: RFC 3740 barely mentions IPsec, so the description
should probably point out that 3740 isn't really about IPsec.
- I'm not sure what 4534/4535 have to do with IPsec; it doesn't
look like it supports creating IPsec SAs, for example.
- Sections 6.(14,15,16) are not about IPsec, but non-IPsec
approaches to securing multicast; so they don't really belong here.
- Section 8.6 and 8.4.1 are not about IPsec, but adapting IKEv2 to
non-IPsec uses. Perhaps these (and RFC 4705, which is missing from the
list) should be grouped under "Non-IPsec Protocols Related to IKE" or
something? (and Section 8.4.1 doesn't really belong under title "EMU";
it did not come from the EMU WG).
- Section 7.4: would it be useful to mention that some vendors
have proprietary extensions for Kerberos in IKEv1 (not KINK)?
(since these are really deployed and used, unlike KINK...)
- Section 7.1: I would suggest not having separate sections for all
IPComp compression algorithms. Perhaps a one-sentence summary like:
"Compression algorithms for IPcomp include DEFLATE [RFC 2394], LZS
[RFC2395], and LZJH [RFC 3051]." would be sufficient?
- Section 1: "The usage of terms in this document conforms to
definitions in [RFC4949]." No, it does not; just remove this sentence.
Here's what Sam wrote back then for his ABSTAIN ballot for 4949:
"However there is a lot left in the glossary that is the author's
personal opinion. We found a number of instances where the author
was trying to use this glossary to establish normative meanings for
words based on his belief of how those words should be
used--sometimes in direct conflict with common practice."
(For example, 4949 considers terms like "MAC (message authentication
code)" and "initialization vector" to be wrong; the "correct" terms
would be "keyed hash"/"protected checksum" and "initialization
value").
- Section 4.2.4.3: now RFC 5739.
- Section 1 and 5: "MUST, SHALL or MAY" should probably be
"MUST, SHOULD or MAY"?
- I'd suggest swapping the order of 7.2.1 and 7.2.2.
- Section 7.6 and 7.6.1: I'd suggest combining this to a single
section.
Best regards,
Pasi
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
