Re: [IPsec] WG Last Call: draft-ietf-ipsecme-roadmap-03

I have the following comments.

1) Section 2.1, in both the text and the diagram, refers to combined-mode 
algorithms only in relation to ESP.  However, RFC 4543 defines the use of 
AES-GMAC for both ESP and AH.
2) Nit -- there are a few places that don't hyphenate "combined mode" when 
used as an adjective: "combined mode algorithm[s]" should be 
"combined-mode algorithm[s]".
3) Section 2.3.1, nit -- "at time" should read "at times".
4) Section 2.3.1, second paragraph -- The first sentence refers to two SA 
pairs and then the following sentences refer to two SAs.  Perhaps we 
should make this transition less abrupt?  I suggest inserting a sentence 
after the first to indicate that "SA" can be used to refer not only to the 
unidirectional SA but also to the pair.
5) Section 2.3.1, second paragraph -- Is it worth noting that "phase 1 SA" 
and "phase 2 SA" are also common names for the IKEv1 SAs?
6) Nit -- there are a couple spots where we have unfortunate widow/orphan 
lines.  E.g., between pp. 13/14 and 15/16.
7) Page 21 -- At the very top, the reference "psecme-2" should read 
"ipsecme-2".  Also, I'm curious why this reference is linked and some 
earlier ones (e.g., "ipsecme-3") aren't.
8) Section 5.3 -- Under RFC 2404, it mentions that SHA-1 ICVs are 
truncated to 96 bits for IPsec.  We should also mention that this 
truncation is done for IKEv2 as well.
9) Section 5.3 -- As above, AES-GMAC is a combined-mode algorithm.
10) Section 5.3 -- Under RFC 4543, it mentions that the salt "is generated 
by IKEv2".  Now that there are IANA assignments for IKEv1 to negotiate 
AES-GMAC for AH/ESP (thanks, Tero!), it seems appropriate to generalize 
this statement about the salt.
11) Section 5.3 -- Under RFC 2403, as with RFC 2404, IKEv2 truncates the 
ICV as well.
12) Section 5.4 -- Under RFC 4106, as with RFC 4543 above, we should 
generalize the statements "is generated by IKEv2" and "IKEv2 negotiations" 
to refer simply to IKE.

I glossed over some sections that aren't of significant interest to me.

Scott Moonen (smoonen@us.ibm.com)
z/OS Communications Server TCP/IP Development
http://scott.andstuff.org/
http://www.linkedin.com/in/smoonen

From:
Paul Hoffman <paul.hoffman@vpnc.org>
To:
ipsec@ietf.org
Date:
08/19/2009 02:05 PM
Subject:
Re: [IPsec] WG Last Call: draft-ietf-ipsecme-roadmap-03

At 12:05 AM +0300 8/11/09, Yaron Sheffer wrote:
>This is the beginning of a two-week WG Last Call, which will end August 
24.
>The target status for this document is Informational (to obsolete RFC 
2411).
>The current document is at
>http://tools.ietf.org/html/draft-ietf-ipsecme-roadmap-03.

That was a week ago.

>If you have not read the document before now, please do so. Having fresh
>eyes on the document often brings up important issues. This document is 
very
>much a survey, so please also review it for completeness: are there
>documents that should be mentioned but aren't. Send any comments to the
>list, even if they are as simple as "I read it and it seems fine".

And, so far, we have heard nothing. *This is bad.* This is a WG document: 
that means it needs to have rough consensus of the WG. Silence is not 
consent.

>Please clearly indicate the position of any issue in the Internet Draft, 
and
>if possible provide alternative text. Indicate the nature or severity of 
the
>error or correction, e.g. major technical, minor technical, nit, so that 
we
>can quickly judge the extent of problems with the document.

...and do so within the next week.

If we do not get enough input during WG Last Call, we will have to 
reconsider how to handle this and future documents.

--Paul Hoffman, Director
--VPN Consortium
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec