Subject: [Ipsec] Fwd: I-D Action:draft-hoffman-ikev2bis-01.txt

From: Paul Hoffman <[email-masked]>
Date: Mon, 11 Jun 2007 19:43:04 -0700

Charlie and Pasi and I have revived the IKEv2bis document. We would 
like all IKEv2 implementers (and all careful readers) to give it 
another read. We listed all the major changes in the last section of 
the document.

Please comment on this mailing list. And, by all means, please make 
the subject lines of your comments relevant to the topic. If you have 
minor editorial comments, feel free to send them to us off-line.

Thanks in advance!

>A New Internet-Draft is available from the on-line Internet-Drafts 
>directories.
> 
>                                                                                         
>         Title           : Internet Key Exchange Protocol: IKEv2
>         Author(s)       : C. Kaufman, et al.
>         Filename        : draft-hoffman-ikev2bis-01.txt
>         Pages           : 124
>         Date            : 2007-06-11
> 
>                                                                                         
>This document describes version 2 of the Internet Key Exchange (IKE)
>protocol.  It is a restatement of RFC 4306, and includes all of the
>clarifications from RFC 4718.
> 
>                                                                                         
>A URL for this Internet-Draft is:
>http://www.ietf.org/internet-drafts/draft-hoffman-ikev2bis-01.txt

--Paul Hoffman, Director
--VPN Consortium

_______________________________________________
Ipsec mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipsec

---

From: Fukumoto Atsushi <[email-masked]>
Date: Tue, 12 Jun 2007 22:03:37 +0900

re ikev2bis-01 section 2.2:
   The Message ID is a 32-bit quantity, which is zero for the
   IKE_SA_INIT messages (including retries of the message due to
   responses such as COOKIE and INVALID_KE_PAYLOAD {{ Clarif-2.2 }}),
   and incremented for each subsequent exchange.  Thus, the first pair
   of IKE_AUTH messages will have ID of 1, the second (when EAP is used)
   will be 2, and so on. {{ Clarif-3.10 }}

I feel this paragraph is less clearer than -00 text.  What if EAP is
not used?  What is the initial value for the Responder's Request?

In section 2.5:
   {{ 3.10.1-5 }} If an endpoint receives a message with a higher major
   version number, it MUST drop the message and SHOULD send an
   unauthenticated notification message of type INVALID_MAJOR_VERSION
   containing the highest (closest) version number it supports.

Hmm, is this message an INFORMATIONAL Request?  I was assuming it is
an IKE_SA_INIT response with Notify payload, but now I'm not sure.

Also in 2.5:
   IKEv2 adds a "critical" flag to each payload header for further
   flexibility for forward compatibility.  If the critical flag is set
   and the payload type is unrecognized, the message MUST be rejected
   and the response to the IKE request containing that payload MUST
   include a Notify payload UNSUPPORTED_CRITICAL_PAYLOAD, indicating an
   unsupported critical payload was included.

What to do if unknown critical payload exist in a response message?  I
found it's described in section 3.10, but it's a little confusing that
only partially elaborating on what to do here.

Section 3.3:
                    Sometimes there is a choice of multiple algorithms,
   whereas other times there is a combination of algorithms.  For
   example, an initiator might want to propose using ESP with either MD5
   or 3DES.

Is this correct?  I'm not sure what is the intention to choose from
MD5 or 3DES.

Also in 3.3:
   The first Proposal MUST have a Proposal # of one (1).

But 3.3.1 mentions that the above MUST is only for request, and the
response is different.  This is confusing.

In section 3.3.2, there are algorithm values already assigned and not
listed, though I don't know whether they should be listed here.

In section 3.10:
   o  Protocol ID (1 octet) - Protocol ID (1 octet) -

Looks like an edit error.

   whose SPI is given the SPI field

"is given in"?

Regards,

					FUKUMOTO Atsushi
					[email-masked]

---

From: Scott C Moonen <[email-masked]>
Date: Tue, 12 Jun 2007 08:41:40 -0600

Hi Paul.  The existing IKEv2 RFC and this draft both address the use of 
OPAQUE port specifications in IKEv2, but do not address the use of OPAQUE 
protocol specifications.  I'm not sure quite how it would be done (the 
OPAQUE port specification uses the unique range [65535, 0], whereas 
protocols are not specified as ranges).  But in some cases RFC 4301 
requires support for OPAQUE protocol selectors for IPv6 (where 
fragmentation may obscure the upper-layer protocol, unlike IPv4), and so 
ideally IKEv2 should handle this requirement as well.  Have you considered 
addressing this?

Thanks,

Scott Moonen ([email-masked])
z/OS Communications Server TCP/IP Development
http://scott.andstuff.org/

Paul Hoffman <[email-masked]> 
06/11/2007 10:43 PM

To
IPsec WG <[email-masked]>
cc

Subject
[Ipsec] Fwd: I-D Action:draft-hoffman-ikev2bis-01.txt

Thanks in advance!

--Paul Hoffman, Director
--VPN Consortium

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 12 Jun 2007 08:28:57 -0700

At 8:41 AM -0600 6/12/07, Scott C Moonen wrote:
>The existing IKEv2 RFC and this draft both address the use of OPAQUE 
>port specifications in IKEv2, but do not address the use of OPAQUE 
>protocol specifications.  I'm not sure quite how it would be done 
>(the OPAQUE port specification uses the unique range [65535, 0], 
>whereas protocols are not specified as ranges).  But in some cases 
>RFC 4301 requires support for OPAQUE protocol selectors for IPv6 
>(where fragmentation may obscure the upper-layer protocol, unlike 
>IPv4), and so ideally IKEv2 should handle this requirement as well. 
> Have you considered addressing this?

It would be grand if IKEv2 implementers who also deal with IPv6 would 
comment on this.

--Paul Hoffman, Director
--VPN Consortium