Below are a few thoughts that came to my mind studying
draft-ietf-ipsecme-roadmap.
Admittedly, this review has originally been done for the -00 draft,
and new material in the recent -01 has only been skimmed over quickly,
but I hope that these considerations will be useful anyway.
(A) Section 2.1
There are some more clearly distinct categories of documents,
some new for the current version of IPsec / IKEv2 :
o documents extending the architecture
(MSEC etc., some are mentioned in section 6/8)
-- this also comprises BTNS;
o documents specifying key management extensions / alternatives
to IKEv2 (also overlap with MSEC and BTNS!);
o documents expanding the set of Authentication methods for IKEv2,
in particular EAP methods suitable for IKEv2;
o documents specifiying / advising on the application of IPsec
in specific contexts / for specific applications.
Should Sect. 2.1/2.* be amended with such categories?
Would these groupings provide guidelines for another (perferable?)
grouping of parts of Sect. 6..8 ?
(B) Use of alternate cryptographic building blocks:
Documents for IPsec transforms based on SEED and GOST primitives
are not mentioned in the document so far.
For more details regarding Camellia, see below.
Linear walk-through including nits
++++++++++++++++++++++++++++++++++
(1) Sect.1
Only very specific RFCs specify their publication *date*
(perhaps wait 3 weeks to see such!), they regularly only give
the *month* -- and so does this memo.
So I suggests to s/date/month/ .
(2) Sect. 2.2.1, 1st para (recurs in 2.3.1)
"IPsec ... use _in_ other protocols."
does not match the protocol layering and might therefore be
considered confusing. I suggest "use _with_ other protocols."
(3) Sect. 3.1 -- "headers"
Hmmm -- ESP is not a "header" , it is an encapsulation (as the
'E' in the acronyme says), having a header and a trailer part
and an embedded encrypted payload (unless NULL encryption is used).
Suggestion: s/[extension] headers/payload [protection] protocols/ .
(4) Sect. 3.1.1
(RFC 2401) : s/the the/the/
(SAD) : s/factilitate/facilitate/
^
(5) Sect. 3.1.2
"[RFC4301] updates [RFC2401],"
Hmmm -- RFC 4301 indeed replaced / succeeded / superseded /
*Obsoleted* RFC 2401 !
Similar for 2402 --> 4302 and 2406 --> 4303 .
(6) Sect. 3.5
(RFC 5406) : Text should be amended to indicate that this memo
is related to "Old" IPsec only!
(7) Sect. 4.1.2
(RFC 4306) : s/DOI.It/DOI. It/
(8) Sect. 4.2.2
(RFC 4806) : s/(e.g. firewall)/(e.g., in a firewall)/
(9) Sect. 5.2
1st para: s/integrity(protection/integrity protection/
^ ^
(RFC 4312)
Updates are in progress for the use of Camellia in IPsec ...
(draft-kato-ipsec-camellia-modes, draft-kato-camellia-ctrccm)
(10) Sect. 5.3
The Japanese Cryptographic community is also in the process of
defining integrity transforms based on Camellia in place of AES,
for all common cipher-based integrity protection transforms.
(11) Sect. 5.4, 1st para
The IPsec documents generally reserve the term 'algorithm'
to cryptographic primitives, and denotes the higher-level
buliding blocks specifically customized to IPsec / IKEv*
as "crytographic transforms".
Thus, s/algorithm/"transform"/g ??
(12) Sect. 5.4
The Camellia documents mentioned above also introduce Camellia-CCM;
another work-in-progress, draft-kato-ipsec-camellia-gcm, adds
Camellia-GCM; both documents should perhaps be listed as well.
(13) Sect. 5.5
The Camellia document set also is going to define Camellia-based
PRFs for IKEv2.
Should these be listed as well?
(14) Sect. 5.6, 1st para -- "inifinite number"
Combining transforms from finite sets of IANA registered algorithms
and their finite variety of applicable parameter values, thank God,
only yields a *finite* set of working combinations.
"Infinite" should not be used thoughtlessly!
(A similar issue recurs in Sect. 6, 1st para)
(15) Sect. 5.7 -- headline
IMHO, "Diffie-Hellman Algorithms" is perhaps too narrow.
Why not use the more 'functional' and precise term,
"Key Agreement Algorithms" ?
(16) Sect. 7.6
(16a) headline
The acronyms of DNS resource record types are written in all uppercase
letters; so sorry, s/IPsecKEY/IPSECKEY/ ! ;-)
(16b) body
s/material in DNS/material in the DNS/
(17) References
s/[RFC 5410]/[RFC5410]/
^
Kind regards,
Alfred Hönes.
--
+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. |
| Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 |
| D-71254 Ditzingen | E-Mail: [email protected] |
+------------------------+--------------------------------------------+
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
