I've now done my AD review for draft-ietf-ipsecme-roadmap-06, and have
some comments. Some of them are making sure what was going to get done
got done. The ones after "NEW" are the new comments. Here are the
comments:
#1) Remove sections 6.5-10 and 6.12-16. Pasi & Paul agreed; I didn't
see anybody object.
#2) Section 5.x: Pasi & Paul agreed; I didn't see anybody object to
the following:
OLD:
ESP-v2 - undefined (no IANA #)
NEW:
ESP-v2 - optional (but no IANA #, so cannot be negotiated by IKEv1)
#3) Pasi and Paul had a back and forth about Sections 8.6 and 8.4.1.
I thought it was agreed to move these two to a new section because
they don't have anything to do with IPsec/IKE, except for borrowing
some design from RFC 4306?
#4) Repeating Pasi's comment:
Section 6.1: RFC 3740 barely mentions IPsec, so the description
should probably point out that 3740 isn't really about IPsec.
#5) I don't think this move was completed: Repeating Pasi's comment
and Sheila's response:
> - IMHO MOBIKE would belong together with other IKEv2 remote
> > access extensions in Section 4.2.4?
> >
OK - MOBIKE will be moved to 4.2.4 (Remote Access) under the Section
"IKE Additions and Extensions"
#6) I think this comment was addressed in 5.4.1. and 5.4.2 but not in
5.4.3 and 5.6.2:
> - 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.
NEW
#8) Sec 5.4.1 and 5.5.1: To avoid the discussion about whether this
document updates 4307 or 4109. Please add some text to the NOTEs that
says and errata has been submitted that addresses this (don't add a
pointer to it somebody will complain later that it's not stable).
There has been one submitted on 4307 but not on 4109. If 4109 is
wrong submit an errata.
#9) I think section 3.1.1 should be IPsec-v2 (or "Old" IPsec
(IPsec-v2) and 3.1.2 should be IPsec-v3 (or "New" IPsec (IPsec-v3).
Section 2.2 says that's how they're going to be referred to.
#10) Sec 3.2.8 should be discussing RFC 5879 not 5840 ;)
#11) Sections 3.3.4, 4.1.2.3, 4.2.1.4, 5.7.3, 8.9.1 and 8.9.2: For the
work-in-progress can we add "work-in-progress" to the heading?
#12) Sec 4.1.1.4: remove "using": [RFC2412] describes a key
establishment protocol using which two authenticated parties can
#13) Sections 4.2.2.1: Last sentence says:
This optional extension applies to both IKEv1 and IKEv2.
These don't really define extensions to IKE or IPsec; it's just a
requirements document. Please reword.
#14) Sections 5 and and 1: Should "Optional" be replaced with
"'optional'"? I want to avoid confusion with the keyword OPTIONAL so
even though "Optional" is correct to use at the beginning of the
sentence when you're talking about this word maybe putting it in
quotes and making it all lower case will further drive the point home.
#15) Sections 5.2.2, 5.2.3, 5.3.2, 5.5.1, 5.7, 5.7.1, and Appendix B
make use of the + and - after the requirements language. Do you think
that this is covered by the penultimate paragraph in Section 1 or
should something be said about them in 5.1? I'd like to err on the
side of caution and at least mention that these are used and their
definitions are taken from the document reference that follows (or
something like that).
#16) Sec 5.2.3: I'm getting hung up on getting the text to align with
the words. The text says 128-bit keys is MUST but bullets show it as
SHOULD/SHOULD+.
#17) Sec 5.2.5: Need a new line:
5.2.5. draft-ietf-ipsecme-aes-ctr-ikev2, Using Advanced Encryption
Standard (AES) Counter Mode with IKEv2 (S)
<<< new line here
[ipsecme-2] extends [RFC3686] to enable the use of AES-CTR to provide
encryption and integrity-protection for IKEv2 messages.
#18) Sec 6.4: r/purposel/purpose.
#19) Sec 7.3: r/LZJH algorithm/LZJH algorithm.
#20) Sec 7.6: Is this only applicable to IKEv1? If so, I'd make an
explicit statement that it's N/A for IKEv2.
Please address these in a new version and make sure an errata is filed
for RFC 4109. After both are published, I will request IETF LC.
Cheers,
spt
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
