[IPsec] Some thoughts on draft-ietf-ipsecme-roadmap[-01]

[Alfred Hönes <[e-mail]>]

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: [phone], Fax: -18         |
| D-71254  Ditzingen     |  E-Mail:  [e-mail]                     |
+------------------------+--------------------------------------------+