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

From: Yaron Sheffer <[email-masked]>
Date: Tue, 11 Aug 2009 00:05:07 +0300

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.

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".

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.

Thanks,
            Yaron

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 19 Aug 2009 11:04:43 -0700

>http://tools.ietf.org/html/draft-ietf-ipsecme-roadmap-03.

That was a week ago.

>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.

>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

---

From: "Laganier, Julien" <[email-masked]>
Date: Thu, 20 Aug 2009 17:37:44 -0700

Greetings,

I have reviewed this document and I think it's in good shape but I however have one technical comment that I'd like to discuss.

In Section 3.4. "Additions to IPsec", "RFC 4891, Using IPsec to Secure IPv6-in-IPv4 Tunnels" is marked as optional. I do not understand the significance of marking this as optional because:

1) 4891 is informational and only describes a set of configuration settings rather than a protocol, and,

2) an IPsec traffic selector can discriminate based on "Next Layer Protocol" and thus can be used to realize 4891.
 
So I'm thinking 4891 requirement level should be N/A rather than optional.

The exact same reasoning seems to apply to "RFC 3884, Use of IPsec Transport Mode for Dynamic Routing" which is also marked as optional.

What do you think?

--julien

---

From: Greg Daley <[email-masked]>
Date: Fri, 21 Aug 2009 14:45:22 +1000

Hi Yaron,

My reading of the document didn't have time to delve into specific issues regarding
the individual sources, except in a few areas where my interest lies.

Therefore my reading was focussed on the clarity of structure and text, and the completeness
of specifications described.

S7.1
(really just an editing issue)

s/provides losslesss compression/provides lossless compression/

S8.2

Is it worth mentioning that OSPF protection in RFC4552 works with manual keying
only, and that no key exchange protocols are specified?

Most of the earlier document paragraphs describe the affinity of a protocol to IKE/IKEv2 etc.

Please note that I have already used this document myself as a reference (as someone
becoming more familiar with current protocol development for IPSec/IKEv2) so I think
that the document is useful and a good starting point for implementors/protocol developers.

Sincerely, 

Greg Daley

> From: [email-masked]
> To: [email-masked]
> Date: Tue, 11 Aug 2009 00:05:07 +0300
> Subject: [IPsec] WG Last Call: draft-ietf-ipsecme-roadmap-03
> 

_________________________________________________________________
What goes online, stays online Check the daily blob for the latest on what's happening around the web
http://windowslive.ninemsn.com.au/blog.aspx

---

From: Scott C Moonen <[email-masked]>
Date: Fri, 21 Aug 2009 09:41:38 -0400

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 ([email-masked])
z/OS Communications Server TCP/IP Development
http://scott.andstuff.org/
http://www.linkedin.com/in/smoonen

From:
Paul Hoffman <[email-masked]>
To:
[email-masked]
Date:
08/19/2009 02:05 PM
Subject:
Re: [IPsec] WG Last Call: draft-ietf-ipsecme-roadmap-03

That was a week ago.

>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.

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
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

---

From: Yoav Nir <[email-masked]>
Date: Mon, 24 Aug 2009 08:46:31 +0300

Sorry for the delay.

I believe the draft is in good shape, but I do have some comments.

1. ESN is mentioned as optional for IKEv1 and included in IKEv2. It is not mentioned that this is an optional feature for IPsec (both old and new)

2. Section 4.2.1 describes RFC 4478 (authentication lifetime). It says "This document defines a new informational message that...". Instead it should say "This document defines a new status notification, that...". Also, after "unless the initiator re-authenticates" I would add "within a specified period of time".

3. Section 5.6 describes cryptographic suites documents (RFC 4308 and 4869), including the algorithms these documents specify (encryption, data integrity and DH group). It does not mention the not-so-obvious fact that RFC 4869 also requires the use of ECDSA for public keys used for authentication (if public keys are used), whereas 4308 makes no such requirement.

4. Section 8.7 describes RoHC RFCs that relate to IPsec. I think it should also mention the soon-to-be-published drafts about compressing IPsec traffic:
 - draft-ietf-rohc-ipsec-extensions-hcoipsec
 - draft-ietf-rohc-ikev2-extensions-hcoipsec
 - draft-ietf-rohc-hcoipsec

In addition to these, a few nits:

1. The document capitalizes the name of the WG as IPsecme. I think we like using IPsecME, no?

2. The descriptions of RFC 3947 and RFC 3948 are oddly placed. Both are in section 3 (IPsec) although 3947 is about IKE, and yet they are separated rather than following one another. I think that either 3947 should be moved to section 4 (IKE) or that they should be moved together.

3. RFCs 3947 and 4304 (ESN) are in section 3 (IPsec) but are more appropriate for section 4 (IKE)

4. Section 4.2.3 describes dead peer detection. It should mention that RFC 4306 (and the bis) call this feature "liveness check".

Email secured by Check Point