Subject: [IPsec] One last review: draft-ietf-ipsecme-aes-ctr-ikev2

From: Paul Hoffman <[email-masked]>
Date: Thu, 8 Apr 2010 16:11:30 -0700

I have revised the IKEv2bis draft with the IETF Last Call comments. It is available at <http://tools.ietf.org/html/draft-ietf-ipsecme-ikev2bis-09>. The diff is at <http://tools.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-ikev2bis-09.txt>.

This is the WG's final chance for review before this is sent to the IESG for their approval. Yaron will ask our new AD, Sean Turner, to send the document to the IESG sometime early next week, so please do a final check NOW to see whether there are any mistakes introduced in the -09. Thanks!

--Paul Hoffman, Director
--VPN Consortium

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 8 Apr 2010 18:14:04 -0700

--Paul Hoffman, Director
--VPN Consortium

---

From: Sean Turner <[email-masked]>
Date: Tue, 13 Apr 2010 13:38:15 -0400

One nit, I missed earlier:

Section 6, there's a reference to [RFC4306] but the reference section 
uses [IKEv2].

spt

Paul Hoffman wrote:
> _______________________________________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec
>

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 13 Apr 2010 11:25:54 -0700

At 1:38 PM -0400 4/13/10, Sean Turner wrote:
>Section 6, there's a reference to [RFC4306] but the reference section uses [IKEv2].

Good catch! Fixed in -10.

--Paul Hoffman, Director
--VPN Consortium

---

From: Tero Kivinen <[email-masked]>
Date: Wed, 14 Apr 2010 17:24:51 +0300

Paul Hoffman writes:
> I have revised the IKEv2bis draft with the IETF Last Call comments.
> It is available at
> <http://tools.ietf.org/html/draft-ietf-ipsecme-ikev2bis-09>. The
> diff is at
> <http://tools.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-ikev2bis-09.txt>. 
> 
> This is the WG's final chance for review before this is sent to the
> IESG for their approval. Yaron will ask our new AD, Sean Turner, to
> send the document to the IESG sometime early next week, so please do
> a final check NOW to see whether there are any mistakes introduced
> in the -09. Thanks! 

In the section 1.2 the text

   The recipients of messages 3 and 4 MUST verify that all signatures
   and MACs are computed correctly.

was changed to

   Both parties in the IKE_SA_INIT exchange MUST verify that all
   signatures and MACs are computed correctly.

which is wrong, as IKE_SA_INIT is messages 1 and 2, IKE_AUTH is the
messages 3 and 4. IKE_SA_INIT messages do not have signatures or MACs.

----------------------------------------------------------------------
In the section 2.23 the following text was removed:

"UDP encapsulation MUST NOT be done on port 500."

I think that text should still be there.

Also you removed mandatory requirement for listening port 4500 if
NAT-T is supported. So I would add the first bullet back. I do not
understand why it this was removed:

   o  IKE MUST listen on port 4500 as well as port 500.  IKE MUST
      respond to the IP address and port from which packets arrived.

Yes, the last part is explained multiple time, but it is especially
important for NAT-T case, which makes it worth of repeating in this
requirement list. 
----------------------------------------------------------------------
In section 2.25 there is typo:

s/REYEY_SA/REKEY_SA/

----------------------------------------------------------------------
In section 3.3.1 the -09 version says:

"the SPI is obtained from the outer IP header."

which is completely wrong. IP header does not have SPI field, the IKE
header has SPI field. Remove the offending "IP" which was added in
last version.
-- 
[email-masked]

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 14 Apr 2010 09:48:14 -0700

>messages 3 and 4. IKE_SA_INIT messages do not have signatures or MACs.

Good catch: fixed in -10.

Agree.

>important for NAT-T case, which makes it worth of repeating in this

This was removed because it appears in a list that is preceded with "In this section only, requirements listed as MUST apply only to implementations supporting NAT traversal." As you say, it also applies even if NAT traversal is not supported.

Done.

Done.

--Paul Hoffman, Director
--VPN Consortium