Subject: [IPsec] Working Group LC: draft-ietf-ipsecme-ikev2bis-06 (yes, IKEv2-bis!)

From: Yaron Sheffer <[email-masked]>
Date: Thu, 10 Dec 2009 11:04:39 +0200

This is to begin a 4 week working group last call for draft-ietf-ipsecme-ikev2bis-06. The target status for this document is Proposed Standard, obsoleting RFC 4306 and RFC 4718.

Please send your comments to the ipsec list by Jan. 5, 2010, as follow-ups to this message.

This is a large document, and arguably the most important document this WG is entrusted with. The LC period is longer than usual but will include vacation time for most of us. Nevertheless, please make an effort to review the entire document, or at least large portions of it. Feel free to post multiple partial reviews.

In this particular case, we are starting the review with a few open issues<http://trac.tools.ietf.org/wg/ipsecme/trac/query?status=new&status=assigned&status=reopened&component=draft-ietf-ipsecme-ikev2bis>. We will make an effort to close them during the WG LC period.

As a reminder regarding the document's scope (and our constraints while reviewing it), I will quote from my mail of Aug. 2008:

General: The goal of the IKEv2 bis document is to clarify the protocol. The goal is not to extend it. Specifically:

* The document will combine RFC 4306 (IKEv2) and RFC 4718 (IKEv2 clarifications), but no other RFCs.
* The document will add clarifications based on the community's deployment experience.
* It is OK to correct minor technical errors and contradictions in the source documents. Any such corrections will be pointed out explicitly - preferably in an appendix (so that people using the old documents can scan it to discover problem areas).
* The document will not add any "nice to have" extensions, no matter how much technical sense they make.

Please clearly indicate the position of any issue in the Internet Draft, and if possible provide alternative text. Please also 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.

The document can be accessed here:

http://tools.ietf.org/html/draft-ietf-ipsecme-ikev2bis-06

Thanks,
      Yaron

---

From: Scott C Moonen <[email-masked]>
Date: Fri, 11 Dec 2009 16:09:26 -0500

I'm not done my review, but here are the observations -- all minor -- that 
I've got so far:

Section 1.2, paragraph 2 -- "the identities are hidden from 
eavesdroppers".  Is it worth noting that a man-in-the-middle could 
intrusively discover the initiator's identity?

Section 1.3.1 -- "When an IKE SA is not created, the error message return 
SHOULD NOT be encrypted because the other party will not be able to 
authenticate that message."  First, this seems out of place, since this 
section talks about CREATE_CHILD_SA for Child SAs.  Second, assuming this 
is talking about IKE_AUTH, I think this contradicts what we'd earlier 
agreed to -- and what section 1.2 now seems to suggest -- in that the 
IKE_AUTH response should normally be encrypted and MACed even on failure.

Section 1.3.2 -- "New initiator and responder SPIs are supplied in the SPI 
fields of the SA payload."  I think we should change this to read "A new 
initiator SPI is supplied ..."  Perhaps we should add something about the 
responder choosing an SPI to the paragraph beginning "The responder 
replies ..."

Section 2.8 -- Note that, when rekeying, the new Child SA SHOULD NOT have 
different traffic selectors and algorithms than the old one."  This 
sentence appears within a paragraph that is otherwise entirely about 
rekeying IKE SAs.  I think it should probably be moved to the end of the 
preceding paragraph.

Section 2.21.2 -- We need to remember to remove the "NOTE FOR WG 
DISCUSSION".

Scott Moonen ([email-masked])
z/OS Communications Server TCP/IP Development
http://www.linkedin.com/in/smoonen

From:
Yaron Sheffer <[email-masked]>
To:
"[email-masked]" <[email-masked]>
Date:
12/10/2009 04:05 AM
Subject:
[IPsec] Working Group LC: draft-ietf-ipsecme-ikev2bis-06 (yes, IKEv2-bis!)

This is to begin a 4 week working group last call for 
draft-ietf-ipsecme-ikev2bis-06. The target status for this document is 
Proposed Standard, obsoleting RFC 4306 and RFC 4718.
 
Please send your comments to the ipsec list by Jan. 5, 2010, as follow-ups 
to this message.
 
This is a large document, and arguably the most important document this WG 
is entrusted with. The LC period is longer than usual but will include 
vacation time for most of us. Nevertheless, please make an effort to 
review the entire document, or at least large portions of it. Feel free to 
post multiple partial reviews.
 
In this particular case, we are starting the review with a few open issues
. We will make an effort to close them during the WG LC period.
 
As a reminder regarding the document’s scope (and our constraints while 
reviewing it), I will quote from my mail of Aug. 2008:
 
General: The goal of the IKEv2 bis document is to clarify the protocol. 
The goal is not to extend it. Specifically:
 
* The document will combine RFC 4306 (IKEv2) and RFC 4718 (IKEv2 
clarifications), but no other RFCs.
* The document will add clarifications based on the community's deployment 
experience.
* It is OK to correct minor technical errors and contradictions in the 
source documents. Any such corrections will be pointed out explicitly - 
preferably in an appendix (so that people using the old documents can scan 
it to discover problem areas).
* The document will not add any "nice to have" extensions, no matter how 
much technical sense they make.
 
Please clearly indicate the position of any issue in the Internet Draft, 
and if possible provide alternative text. Please also 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_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

---

From: Toshihiko Tamura <[email-masked]>
Date: Mon, 14 Dec 2009 10:55:21 +0900

Hi, I want to check one point.
At the last paragraph in Section 2.5, there is a mention of refering 
the figures in Section 2.
Does it mean we should refer all fighres in Section 2?
Or does it mistake section 2 for section 1?

---------
2.5.  Version Numbers and Forward Compatibility
/snip/
   Although new payload types may be added in the future and may appear
   interleaved with the fields defined in this specification,
   implementations SHOULD send the payloads defined in this
   specification in the order shown in the figures in Section 2;
   implementations MUST NOT reject as invalid a message with those
   payloads in any other order.
---------

Regards, 
Toshihiko Tamura

---

From: Paul Hoffman <[email-masked]>
Date: Sun, 13 Dec 2009 19:24:33 -0800

>Or does it mistake section 2 for section 1?

Good catch. It should say "...the order shown in the figures in Sections 1 and 2". We split some of the figures out of 2 into 1, but we still have ones that have payload orders in section 2.

--Paul Hoffman, Director
--VPN Consortium

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 14 Dec 2009 14:49:08 +0200

Paul Hoffman writes:
> Good catch. It should say "...the order shown in the figures in
> Sections 1 and 2". We split some of the figures out of 2 into 1, but
> we still have ones that have payload orders in section 2. 

In the RFC4306 most of the figures with payloads were in the section
1. Section only had Cookies, EAP and Configuration payload examples.

Basic IKE_SA_INIT, IKE_AUTH CREATE_CHILD_SA, and INFORMATION exchange
figures have always been in the section 1.

This is the situation also now (i.e. draft-ietf-ipsecme-ikev2bis-06
still has the basic IKE_SA_INIT, IKE_AUTH CREATE_CHILD_SA, and
INFORMATION exchange figures in section 1 and the only change is that
we splitted one of those figures (CREATE_CHILD_SA) from one figure to
3 figures (creating new Child SA, rekeying IKE SA, rekeying Child SA).

Section 2 never had any figures listing payload orders for example for
CREATE_CHILD_SA exchange.

So this bug has been in the document before the bis document, i.e. it
was in the RFC4306.

On the other hand as we now say that "implementations MUST NOT reject
as invalid a message with those payloads in any other order." I do not
think this is that big issue. Also the payload order is now only
SHOULD not MUST anymore.

BTW, I think that change is one of the significant changes we should
list in the RFC4306, i.e. following the payload order of the figures
in section 2 is no longer MUST, it is now SHOULD (and applies to
figures in section 1 too).

Also it is no longer a SHOULD that messages with different payload
order than in those in figures in section 2. Now implementations MUST
NOT reject messages bacause different payload orders. 
-- 
[email-masked]

---

From: Matthew Cini Sarreo <[email-masked]>
Date: Mon, 14 Dec 2009 14:26:01 +0100

Hello all,

A minor technical note about Issue #22. Section 2.25, last paragraph reads:

A CHILD_SA_NOT_FOUND notification SHOULD be sent when a peer receives a
request to rekey a Child SA that does not exist.  A peer that receives a
CHILD_SA_NOT_FOUND notification SHOULD silently delete the Child SA and send
a request to create a new Child SA from scratch.

The original text does not mention what the SPI should be (it is practially
implied what it should be set to, but is still not mentioned in the text).
Presumably one would set the this to be the SPI of the Child SA that caused
the error (i.e the data for CHILD_SA_NOT_FOUND is the same as the SPI found
inside the REKEY_SA notification). This way, the Initiator knows which
rekeying attempt resulted in this error.

I would propose to change this text to:
A CHILD_SA_NOT_FOUND notification SHOULD be sent when a peer receives a
request to rekey a Child SA that does not exist.  The SA that the initiator
attempted to rekey is indicated by the SPI field in the Notify Payload,
which is copied from the SPI field in the REYEY_SA notification. A peer that
receives a CHILD_SA_NOT_FOUND notification SHOULD silently delete the Child
SA and send a request to create a new Child SA from scratch.

Regards,
Matt

2009/12/14 Tero Kivinen <[email-masked]>

> _______________________________________________
> IPsec mailing list
> [email-masked]

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 14 Dec 2009 08:05:30 -0800

>figures in section 1 too).

Quite right. I remind people again of issue #126:

Section 1.7 lists notable changes from RFC 4106. Those of us making those changes may have forgotten to also update section 1.7.

I already updated section 1.7 for this change, but if people find other such "notable changes", please comment on the thread for #126.

--Paul Hoffman, Director
--VPN Consortium

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 14 Dec 2009 09:06:28 -0800

At 2:26 PM +0100 12/14/09, Matthew Cini Sarreo wrote:
>A CHILD_SA_NOT_FOUND notification SHOULD be sent when a peer receives a request to rekey a Child SA that does not exist.  A peer that receives a CHILD_SA_NOT_FOUND notification SHOULD silently delete the Child SA and send a request to create a new Child SA from scratch.
>
>The original text does not mention what the SPI should be (it is practially implied what it should be set to, but is still not mentioned in the text). Presumably one would set the this to be the SPI of the Child SA that caused the error (i.e the data for CHILD_SA_NOT_FOUND is the same as the SPI found inside the REKEY_SA notification). This way, the Initiator knows which rekeying attempt resulted in this error.
>
>A CHILD_SA_NOT_FOUND notification SHOULD be sent when a peer receives a request to rekey a Child SA that does not exist.  The SA that the initiator attempted to rekey is indicated by the SPI field in the Notify Payload, which is copied from the SPI field in the REYEY_SA notification. A peer that receives a CHILD_SA_NOT_FOUND notification SHOULD silently delete the Child SA and send a request to create a new Child SA from scratch.

It is always good to make this kind of thing explicit. I will add this to the next draft.

--Paul Hoffman, Director
--VPN Consortium

---

From: Scott C Moonen <[email-masked]>
Date: Tue, 15 Dec 2009 11:53:11 -0500

I've finished my read through the draft.  Note that I didn't give much 
scrutiny to the Config or EAP payloads, but I've read over everything 
else.  A few more comments:

1) There are excessive spaces on the second lines of these list items in 
section 2.23:

     - If the server is behind a NAT, substitute the IP address in the
       TSr  entries with the remote address of the IKE SA.
          ^

     - If the client is behind a NAT, substitute the IP address in the
        TSi entries with the local address of the IKE SA.
       ^

2) In section 3.3, this sentence: "If an algorithm that combines 
encryption and integrity protection is proposed, it MUST be proposed as an 
encryption algorithm and an integrity protection algorithm MUST NOT be 
proposed." seems to apply to all protocols, including IKE, and it is more 
strict than what we'd agreed to for ticket #122.  It is also more strict 
than the "MAY" in section 3.3.3.  Speaking of ticket #122, the updated 
text for that ticket is somehow missing in this draft.

3) In section 3.6: "Certificate payloads SHOULD be included in an exchange 
if certificates are available to the sender unless the peer has indicated 
an ability to retrieve this information from elsewhere using an 
HTTP_CERT_LOOKUP_SUPPORTED Notify payload."  This sentence is incoherent 
-- I think if the HTTP_... notify was sent you'd still include a 
certificate payload, it just wouldn't hold a certificate.  I'm probably 
not the best person to suggest alternative wording, but perhaps something 
like "Certificate payloads SHOULD be used to send entire certificates if 
they are ..."

4) Section 3.10.1 -- we should remember to remove "{{ Demoted the SHOULD 
}}" before publication.

5) Section 3.13.1, extraneous capitalization:

   o  Selector Length - Specifies the length of this Traffic Selector
      Substructure including the header.
      ^

6) Section 3.13.1, could probably use a little tweaking to replace 
references to "ICMP" with "ICMP, ICMPv6 and MIPv6".  Also, the paragraph 
containing "This document does not specify how to represent the 'MH Type' 
field ..." actually goes on to specify just that.

7) Section 3.14, "The Encrypted Payload, if present in a message, MUST be 
the last payload in the message.  Often, it is the only payload in the 
message."  Out of curiosity, do we know of any cases where this payload is 
not the only payload in the message?  It strikes me as odd to allow for 
some payloads prior to this one to be integrity protected but not 
encrypted.  I suppose since RFC 4306 allows it we don't have a lot of 
wiggle room here.

8) Section 4, "Every implementation MUST be capable of responding to an 
INFORMATIONAL exchange, but a minimal implementation MAY respond to any 
INFORMATIONAL message with an empty INFORMATIONAL reply."  Is that true 
even if the INFORMATIONAL request contained a Delete payload for a Child 
SA?

9) Appendix D -- we need to fill this in.

From:

 

 

 

Thanks,

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 15 Dec 2009 09:26:25 -0800

At 11:53 AM -0500 12/15/09, Scott C Moonen wrote:
>I've finished my read through the draft.  

Many thanks for the careful review. So, who wants to match or exceed Scott's efforts? We need more eyes on this version of the document before it is ready for IETF Last Call.

--Paul Hoffman, Director
--VPN Consortium

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 15 Dec 2009 10:54:46 -0800

At 11:53 AM -0500 12/15/09, Scott C Moonen wrote:
>1) There are excessive spaces on the second lines of these list items in section 2.23:

Fixed.

>2) In section 3.3, this sentence: "If an algorithm that combines encryption and integrity protection is proposed, it MUST be proposed as an encryption algorithm and an integrity protection algorithm MUST NOT be proposed." seems to apply to all protocols, including IKE, and it is more strict than what we'd agreed to for ticket #122.  It is also more strict than the "MAY" in section 3.3.3.  Speaking of ticket #122, the updated text for that ticket is somehow missing in this draft.

#122 is being fixed in the next draft, not the current draft. In it, I removed the sentence you have a problem with.

>3) In section 3.6: "Certificate payloads SHOULD be included in an exchange if certificates are available to the sender unless the peer has indicated an ability to retrieve this information from elsewhere using an HTTP_CERT_LOOKUP_SUPPORTED Notify payload."  This sentence is incoherent -- I think if the HTTP_... notify was sent you'd still include a certificate payload, it just wouldn't hold a certificate.  I'm probably not the best person to suggest alternative wording, but perhaps something like "Certificate payloads SHOULD be used to send entire certificates if they are ..."

This has been in the document for quite a while. If it is important to you, please open a new ticket for it and start a thread.

>4) Section 3.10.1 -- we should remember to remove "{{ Demoted the SHOULD }}" before publication.

Yarrgh. So much for my regexps. Removed.

>      Substructure including the header.

Fixed.

>6) Section 3.13.1, could probably use a little tweaking to replace references to "ICMP" with "ICMP, ICMPv6 and MIPv6".  Also, the paragraph containing "This document does not specify how to represent the 'MH Type' field ..." actually goes on to specify just that.

Disagree. The WG has not even begun to think about ICMPv6 and MIPv6, so saying anything could lead readers to make assumptions that could end badly.

>7) Section 3.14, "The Encrypted Payload, if present in a message, MUST be the last payload in the message.  Often, it is the only payload in the message."  Out of curiosity, do we know of any cases where this payload is not the only payload in the message?  It strikes me as odd to allow for some payloads prior to this one to be integrity protected but not encrypted.  I suppose since RFC 4306 allows it we don't have a lot of wiggle room here.

Exactly. We don't need to prohibit it, just cast aspersions on it.

>8) Section 4, "Every implementation MUST be capable of responding to an INFORMATIONAL exchange, but a minimal implementation MAY respond to any INFORMATIONAL message with an empty INFORMATIONAL reply."  Is that true even if the INFORMATIONAL request contained a Delete payload for a Child SA?

Opened as Issue #128, on which I will start a new thread.

--Paul Hoffman, Director
--VPN Consortium

---

From: Scott C Moonen <[email-masked]>
Date: Tue, 15 Dec 2009 14:28:34 -0500

> >3) In section 3.6: "Certificate payloads SHOULD be included in an
> >   exchange if certificates are available to the sender unless the
> >   peer has indicated an ability to retrieve this information from
> >   elsewhere using an HTTP_CERT_LOOKUP_SUPPORTED Notify payload."
> >   This sentence is incoherent -- I think if the HTTP_... notify was
> >   sent you'd still include a certificate payload, it just wouldn't
> >   hold a certificate.  I'm probably not the best person to suggest
> >   alternative wording, but perhaps something like "Certificate
> >   payloads SHOULD be used to send entire certificates if they are ..."
> 
> This has been in the document for quite a while. If it is important to
> you, please open a new ticket for it and start a thread.

I'll defer to others who are more familiar with the certificate payload,

From:
Paul Hoffman <[email-masked]>
To:
Scott C Moonen/Raleigh/IBM@IBMUS
Cc:
"[email-masked]" <[email-masked]>
Date:
12/15/2009 01:55 PM
Subject:
Re: [IPsec] Working Group LC: draft-ietf-ipsecme-ikev2bis-06 (yes, 
IKEv2-bis!)

section 2.23:

Fixed.

#122 is being fixed in the next draft, not the current draft. In it, I 
removed the sentence you have a problem with.

>3) In section 3.6: "Certificate payloads SHOULD be included in an 
exchange if certificates are available to the sender unless the peer has 
indicated an ability to retrieve this information from elsewhere using an 
HTTP_CERT_LOOKUP_SUPPORTED Notify payload."  This sentence is incoherent 
-- I think if the HTTP_... notify was sent you'd still include a 
certificate payload, it just wouldn't hold a certificate.  I'm probably 
not the best person to suggest alternative wording, but perhaps something 
like "Certificate payloads SHOULD be used to send entire certificates if 
they are ..."

This has been in the document for quite a while. If it is important to 
you, please open a new ticket for it and start a thread.

}}" before publication.

Fixed.

Disagree. The WG has not even begun to think about ICMPv6 and MIPv6, so 
saying anything could lead readers to make assumptions that could end 
badly.

--Paul Hoffman, Director
--VPN Consortium

---

From: Scott C Moonen <[email-masked]>
Date: Tue, 15 Dec 2009 14:28:33 -0500

> >   references to "ICMP" with "ICMP, ICMPv6 and MIPv6".  Also, the
> >   paragraph containing "This document does not specify how to
> >   represent the 'MH Type' field ..." actually goes on to specify
> >   just that.
> 
> Disagree. The WG has not even begun to think about ICMPv6 and MIPv6,
> so saying anything could lead readers to make assumptions that could
> end badly.

But RFC 4301 already specifies this in section 4.4.1.1.  Given this, I 
think it's incorrect to treat this as unspecified in ikev2bis:

         * If the Next Layer Protocol is a Mobility Header, . . .
           For IKE, the IPv6 Mobility Header
           message type (MH type) is placed in the most significant
           eight bits of the 16-bit local "port" selector.

         * If the Next Layer Protocol value is ICMP, . . .
           For IKE, the message type is placed in the most significant 8
           bits of the 16-bit selector and the code is placed in the
           least significant 8 bits. . . .

It's less clear that this addresses ICMPv6 than MIPv6, but but elsewhere 
in the document "ICMP" is explicitly used in a generic sense, and I think 
we're on pretty good ground for both.  I'm aware of at least one 
implementation other than ours that uses both MH type and ICMPv6 type/code 
in this fashion in IKEv2.

I'd be willing to work on alternative text for 3.13.1 if others agree,

From:

section 2.23:

Fixed.

}}" before publication.

Fixed.

--Paul Hoffman, Director
--VPN Consortium

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 15 Dec 2009 13:29:28 -0800

At 2:28 PM -0500 12/15/09, Scott C Moonen wrote:
>But RFC 4301 already specifies this in section 4.4.1.1.  Given this, I think it's incorrect to treat this as unspecified in ikev2bis:
>
>It's less clear that this addresses ICMPv6 than MIPv6, but but elsewhere in the document "ICMP" is explicitly used in a generic sense, and I think we're on pretty good ground for both.  I'm aware of at least one implementation other than ours that uses both MH type and ICMPv6 type/code in this fashion in IKEv2.
>

The ticket is assigned to you. :-)

--Paul Hoffman, Director
--VPN Consortium

---

From: Tero Kivinen <[email-masked]>
Date: Wed, 16 Dec 2009 11:54:42 +0200

Paul Hoffman writes:
> >A CHILD_SA_NOT_FOUND notification SHOULD be sent when a peer
> >receives a request to rekey a Child SA that does not exist.  A peer
> >that receives a CHILD_SA_NOT_FOUND notification SHOULD silently
> >delete the Child SA and send a request to create a new Child SA
> >from scratch. 
> >
> >The original text does not mention what the SPI should be (it is
> >practially implied what it should be set to, but is still not
> >mentioned in the text). Presumably one would set the this to be the
> >SPI of the Child SA that caused the error (i.e the data for
> >CHILD_SA_NOT_FOUND is the same as the SPI found inside the REKEY_SA
> >notification). This way, the Initiator knows which rekeying attempt
> >resulted in this error. 

For initiator it is clear already because this error notification is
always used as reply to the CREATE_CHILD_SA request, i.e. initiator
already matches this with the corresponding request by the message id
fields.

Because of this the SPI field is not necessarily needed.

> >A CHILD_SA_NOT_FOUND notification SHOULD be sent when a peer
> >receives a request to rekey a Child SA that does not exist.  The SA
> >that the initiator attempted to rekey is indicated by the SPI field
> >in the Notify Payload, which is copied from the SPI field in the
> >REYEY_SA notification. A peer that receives a CHILD_SA_NOT_FOUND
> >notification SHOULD silently delete the Child SA and send a request
> >to create a new Child SA from scratch. 
> 

This would be ok, but would not be enough. We also have text in the
section 3.10 saying that only INVALID_SELECTORS and REKEY_SA has SPI
field, so this new CHILD_SA_NOT_FOUND needs to be added to there too.

We have decided the SPI is filled to the SPI field when it refers to
EXISTING SPI. For example the INVALID_SPI notification does not fill
the SPI field, as the SPI field refers to the SPI that is not known by
the responder. See text in section 3.10 under Protocol ID.

This is similar case, i.e. the responder of who gets the REKEY_SA
notification with unknown SPI does not have Child SA with that SPI,
thus SPI is unknown for him, and because of that I think it is better
for NOT to fill in the SPI field of the CHILD_SA_NOT_FOUND error. As
the exchange where this error refers to is clear from the context (it
is reply to the rekey request), there is no need to include SPI
anywhere.

Because of that I suggest we do not add that text but instead add
sentense saying:

  As CHILD_SA_NOT_FOUND error refers to unknown SPI from the
  responders point of view, it does not fill in the SPI field of the
  CHILD_SA_NOT_FOUND error notification. Instead it sets the protocol
  ID to zero and leaves SPI field empty.
-- 
[email-masked]

---

From: Tero Kivinen <[email-masked]>
Date: Wed, 16 Dec 2009 12:08:55 +0200

> encrypted.  I suppose since RFC 4306 allows it we don't have a lot of 

For example older versions of the resumption draft used constructs
where the had Nonce and some notifications before the encrypted
payload, so that those could be used to find  the state which is then
used to decrypt the rest of the packet.

Current version of the resumption does not use that kind of thing
anymore, but some future version might use. Anyways currently there is
no need to support other payloads before encrypted payload and if
implementation would support such it would need to be very careful to
keep the encrypted and authenticated payloads and cleartext and
not-authenticated payloads separate when parsing the message. 

> even if the INFORMATIONAL request contained a Delete payload for a Child 

Yes.

I.e. you can have minimal implementation which only supports exactly
one IPsec SA and IKE SA and does not support rekeying or creating
additional SAs using CREATE_CHILD_SA exchange.

> 9) Appendix D -- we need to fill this in.

I think that was moved to be section 1.7, so we should remove this
appendix. 
-- 
[email-masked]

---

From: Scott C Moonen <[email-masked]>
Date: Wed, 16 Dec 2009 07:39:50 -0500

> not-authenticated payloads separate when parsing the message. 

Actually, the Encrypted payload's ICV is calculated over the entire 
message, so -- interestingly -- any payloads outside of it are still 
authenticated, but not encrypted.

From:
Tero Kivinen <[email-masked]>
To:
Scott C Moonen/Raleigh/IBM@IBMUS
Cc:
Yaron Sheffer <[email-masked]>, "[email-masked]" <[email-masked]>
Date:
12/16/2009 05:09 AM
Subject:
Re: [IPsec] Working Group LC: draft-ietf-ipsecme-ikev2bis-06 (yes, 
IKEv2-bis!)

Yes.

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 16 Dec 2009 09:30:47 -0800

>  ID to zero and leaves SPI field empty.

If the sender of the CREATE_CHILD_SA is going to match the response by the Message ID, then I do not see why we should make the new rule about the values for the protocol ID and SPI. I would have thought that you were going to suggest something like:

Because the CHILD_SA_NOT_FOUND error refers to an SPI that the responder does not recognize, it does not know what to fill in for the SPI field of the error. Therefore, the initiator SHOULD ignore the SPI field in the response and instead base its actions on the Message ID.

--Paul Hoffman, Director
--VPN Consortium

---

From: David Wierbowski <[email-masked]>
Date: Wed, 16 Dec 2009 15:31:42 -0500

Paul,

I haven't matched Scott's efforts, but I do have some comments:

Comment  #1:

Section 1.2 (The Initial Exchanges) has the following sentence, which was
also in RFC 4306.

   Payloads that may optionally appear will be shown in brackets,
   such as [CERTREQ], indicate that optionally a certificate request
   payload can be included.

This wording seems awkward to me.  I suggest changing "indicate" to
"indicating" as below:

   Payloads that may optionally appear will be shown in brackets,
   such as [CERTREQ], indicating that optionally a certificate request
   payload can be included.

Comment # 2:

Section 1.7 (Differences Between RFC 4306 and This Document) states:

   The protocol described in this document retains the same major
   version number (2) and minor version number (0) as was used in RFC
   4306.  That is, the version number is *not* changed from RFC 4306.

Section 2.5 (Version Numbers and Forward Compatibility) states

   The minor
   version number indicates new capabilities, and MUST be ignored by a
   node with a smaller minor version number, but used for informational
   purposes by the node with the larger minor version number.  For
   example, it might indicate the ability to process a newly defined
   notification message.  The node with the larger minor version number
   would simply note that its correspondent would not be able to
   understand that message and therefore would not send it.

New notifies have been added to the bis draft.   Is a bump in the minor
number warranted?  Is there a down side to bumping the minor number?

Comment # 3:

Section 2.8.1 Simultaneous Child SA rekeying states:

   To B, it looks like A is trying to rekey an SA that no longer exists;
   thus, B responds to the request with something non-fatal such as
   NO_PROPOSAL_CHOSEN.

                                <--  send resp1: N(NO_PROPOSAL_CHOSEN)
   recv resp1 <--

   When A receives this error, it already knows there was simultaneous
   rekeying, so it can ignore the error message.

Section 2.25.1 Exchange Collisions states:

   A CHILD_SA_NOT_FOUND notification SHOULD be sent when a peer receives
   a request to rekey a Child SA that does not exist.  A peer that
   receives a CHILD_SA_NOT_FOUND notification SHOULD silently delete the
   Child SA and send a request to create a new Child SA from scratch.

This seems to be inconsistent.  I suspect that the text in section 2.8.1
should be updated to show CHILD_SA_NOT_FOUND sent instead of
NO_PROPOSAL_CHOSEN.

Comment #4:

Section 2.8.2 Simultaneous IKE SA Rekeying states:

   If only one peer detects a simultaneous rekey, redundant SAs
   are not created.  In this case, when the peer that did not notice the
   simultaneous rekey gets the request to rekey the IKE SA that it has
   already successfully rekeyed, it MUST return TEMPORARY_FAILURE
   because it is an IKE SA that it is currently trying to close (whether
   or not it has already sent the delete notification for the SA).

Section 2.25.2 (Collisions While Rekeying or Closing IKE SAs) states:

   If a peer receives a request to close an IKE SA that it is
   currently trying to close, it SHOULD reply as usual, and forget about
   its own close request.

Based on the text in Section 2.25.2 it seems that perhaps the MUST in
Section 2.8.2 is really a SHOULD.

Comment #5

In section Section 2.8.2 Simultaneous IKE SA Rekeying I suggest we start a
new paragraph at the sentence:

   If only one peer detects a simultaneous rekey, redundant SAs
   are not created.

Comment #6

Section 2.25.2 (Collisions While Rekeying or Closing IKE SAs) states:
   If
   the peer that did notice the simultaneous rekey gets the delete
   request from the other peer for the old IKE SA, it knows that the
   other peer did not detect the simultaneous rekey, and the first peer
   can forget its own rekey attempt.

   However, there is a twist to the other case where one rekeying
   finishes first:

   Host A                      Host B
   -------------------------------------------------------------------
   send req1:
        SA(..,SPIa1,..),Ni1,.. -->
                             <-- send req2: SA(..,SPIb1,..),Ni2,..
                             --> recv req1
                             <-- send resp1: SA(..,SPIb2,..),Nr2,..
   recv resp1 <--
   send req3: D() -->
                             --> recv req3

   At this point, host B sees a request to close the IKE_SA.  There's
   not much more to do than to reply as usual.  However, at this point
   host B should stop retransmitting req2, since once host A receives
   resp3, it will delete all the state associated with the old IKE_SA
   and will not be able to reply to it.

                             <-- send resp3: ()

I suggest  the sentence, "However, there is a twist to the other case where
one rekeying finishes first: " be deleted.  The sample flow that follows it
is just a more detailed description of the sentence that proceeds it.  The
sentence made sense at one time, but not anynore.

Comment 7:

Section 2.23 (Nat Traversal) has the following sequence of text:

   o  The recipient of either the NAT_DETECTION_SOURCE_IP or
      NAT_DETECTION_DESTINATION_IP notification MAY compare the supplied
      value to a SHA-1 hash of the SPIs, source IP address, and port,
      and if they don't match it SHOULD enable NAT traversal.  In the
      case of a mismatching NAT_DETECTION_SOURCE_IP hash, the recipient
      MAY reject the connection attempt if NAT traversal is not
      supported.  In the case of a mismatching
      NAT_DETECTION_DESTINATION_IP hash, it means that the system
      receiving the NAT_DETECTION_DESTINATION_IP payload is behind a NAT
      and that system SHOULD start sending keepalive packets as defined
      in [UDPENCAPS]; alternately, it MAY reject the connection attempt
      if NAT traversal is not supported.

   o  If none of the NAT_DETECTION_SOURCE_IP payload(s) received matches
      the expected value of the source IP and port found from the IP
      header of the packet containing the payload, it means that the
      system sending those payloads is behind NAT (i.e., someone along
      the route changed the source address of the original packet to
      match the address of the NAT box).  In this case, the system
      receiving the payloads should allow dynamic update of the other
      systems' IP address, as described later.

   o  If the NAT_DETECTION_DESTINATION_IP payload received does not
      match the hash of the destination IP and port found from the IP
      header of the packet containing the payload, it means that the
      system receiving the NAT_DETECTION_DESTINATION_IP payload is
      behind a NAT.  In this case, that system SHOULD start sending
      keepalive packets as explained in [UDPENCAPS].

The first bullet says, "In the case of a mismatching
NAT_DETECTION_SOURCE_IP hash, the recipient MAY reject the connection
attempt if NAT traversal is not supported."  This is slightly inaccurate
when multiple NAT_DETECTION_SOURCEIP payloads are sent.  I  think it should
be reworded to say, "In the case there is a mismatch of the
NAT_DETECTION_SOURCE_IP hash in each NAT_DETECTION_SOURCE_IP payloads
received, the recipient MAY reject the connection attempt if NAT traversal
is not supported.

Also, the third bullet seems to already be covered by the last sentence in
the first bullet.  Is the third bullet really necessary?.

Comment 8:

Section 2.23 (Nat Traversal) I thought it was decided that one should be
able to float to port 4500 (or even start out on port 4500) even if there
is no NAT.  That is is not clear from 2.23.  Should floating even when a
NAT is not detected be mentioned in 2.23?

Comment 9:

I agree with Scott Moonen's comment that in Section 3.6 the sentence
"Certificate payloads SHOULD be included in an exchange if certificates are
available to the sender unless the peer has indicated an ability to
retrieve this information from elsewhere using an
HTTP_CERT_LOOKUP_SUPPORTED Notify payload."  Does not seem to make sense.
Certificate payloads are still sent when the HTTP_CERT_LOOKUP_SUPPORTED
Notify payload. is received.  I've seen Paul's response that a new ticket
should be opened if this is important.  I think it is and will open a new
ticket once I figure how to.

Comment 10

In Section 3.7 (Certificate Request Payload) I still find the relationship
between the cert encoding type and the HTTP_CERT_LOOKUP_SUPPORTED notify to
be poorly explained.  Perhaps there is no relationship, but it seems as if
there should be.  For example, what should take precedence the case where
the cert encoding type is "Hash and URL of X.509 certificate" and no
HTTP_CERT_LOOKUP_SUPPORTED notify was sent or in the case where the cert
encoding type is "X..509 certificate" and a  HTTP_CERT_LOOKUP_SUPPORTED
notify was sent?

Dave Wierbowski

  From:       Paul Hoffman <[email-masked]>                                                          
                                                                                                            
  To:         "[email-masked]" <[email-masked]>                                                             
                                                                                                            
  Date:       12/15/2009 12:28 PM                                                                           
                                                                                                            
  Subject:    Re: [IPsec] Working Group LC: draft-ietf-ipsecme-ikev2bis-06 (yes, IKEv2-bis!)                
                                                                                                            
  Sent by:    [email-masked]                                                                        

>I've finished my read through the draft.

Many thanks for the careful review. So, who wants to match or exceed
Scott's efforts? We need more eyes on this version of the document before
it is ready for IETF Last Call.

--Paul Hoffman, Director
--VPN Consortium

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 16 Dec 2009 14:45:50 -0800

>I haven't matched Scott's efforts, but I do have some comments:

Many thanks!

>   such as [CERTREQ], indicating that optionally a certificate request

Got it.

>number warranted?  Is there a down side to bumping the minor number?

Opened as Issue #130.

>should be updated to show CHILD_SA_NOT_FOUND sent instead of

Agree. It is clear from "such as" that the NO_PROPOSAL_CHOSEN is not the definitive answer.

>Section 2.8.2 is really a SHOULD.

I'm not convinced which needs to be changed. Opened as issue #131.

>   If only one peer detects a simultaneous rekey, redundant SAs

Done.

>   However, there is a twist to the other case where one rekeying

Done.

>received, the recipient MAY reject the connection attempt if NAT traversal

Good catch; done.

>the first bullet.  Is the third bullet really necessary?.

Agree.

>NAT is not detected be mentioned in 2.23?

The beginning of the 7th paragraph already says "An initiator can float to port 4500, regardless whether or not there is NAT, even at the beginning of IKE.".

>ticket once I figure how to.

Whoops; Yaron and I may have never told the WG how to.

- Go to <http://trac.tools.ietf.org/wg/ipsecme/trac/>
- Click "Login" to log in if you already have a password; if not, click "Get Passwd" in the thin left column to get a password.
- After you log in, there will be a "New Ticket" choice to the right of "View Tickets".
- If you mess up your first attempt, just keep changing it until it is right. (I typically forget to set the "Component" to "draft-ietf-ipsec-ikev2bis"...)
- When it looks the way you want, send a new message to the mailing list with the ticket number in the subject, such as "Issue #567: Short description of the issue". Including the "#567" will make my job *much* easier.

>encoding type is "X..509 certificate" and a  HTTP_CERT_LOOKUP_SUPPORTED

That's a good candidate for testing your new issue-opening skills. :-)

--Paul Hoffman, Director
--VPN Consortium

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 17 Dec 2009 12:33:06 +0200

Paul Hoffman writes:
> If the sender of the CREATE_CHILD_SA is going to match the response
> by the Message ID, then I do not see why we should make the new rule
> about the values for the protocol ID and SPI. I would have thought
> that you were going to suggest something like:

That is not a new rule, that is standard rule for the Notification
payloads. If you do not have existing SPI then you put Protocol ID to
zero and do not fill in the SPI field. I.e. section 7.8 of the
RFC4718.

I originally thought that we do not need to put anything there as I
expected everybody to understand that as we do not have valid SA then
we do not fill in the SPI field, but as people might interpret this
differently I think we need some text. 

> Because the CHILD_SA_NOT_FOUND error refers to an SPI that the
> responder does not recognize, it does not know what to fill in for
> the SPI field of the error. Therefore, the initiator SHOULD ignore
> the SPI field in the response and instead base its actions on the
> Message ID. 

I think it is better to mandate actions of the one who creates the
Notication payload, not the one who receives it.

So I would leave the last sentence away and only keep the first one,
but as someone commented that actually responder do know about the
SPI, as the SPI was sent to him in the REKEY_SA notification, so he
could copy it from there to this error. Because if this I think it is
better to be more explicit:

   Because the CHILD_SA_NOT_FOUND error refers to an SPI that the
   responder does not recognize, it does not fill in SPI in the
   CHILD_SA_NOT_FOUND error notification.

I do not think we need anything to express how initiator can know
which of his requests failed when he gets error response back to one
of them... It should be clear for everybody that if your request gets
error response back, it was that request that failed.
-- 
[email-masked]

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 17 Dec 2009 13:38:46 +0200

> number warranted?  Is there a down side to bumping the minor number?

Even if we add new notifies, that does not need we MUST increment the
minor version number. It just say we might want to do it.

For error notifications (which were the ones we are adding) this is
not that important as the 3.10.1 is quite clear that the corresponding
request has  failed entirely when you get error notification back.
This means it does not matter which error other end sends (old or new)
the recipient of it still knows the request failed.

It would be different if other end would need to know whether other
end supports new notifications before 

> should be updated to show CHILD_SA_NOT_FOUND sent instead of

Yes. Not all the old sections were properly updated yet. I try to go
them through soon to verify they are correct. 

> Section 2.8.2 is really a SHOULD.

We need to think what will happen if someone does not follow the rule.
For example those two cases are not same (in 2.8.2 incoming message is
IKE SA rekey and in 2.25.2 it is IKE SA delete) also what happens if
the MUST/SHOULD is not followed is different. In the 2.8.2 if other
end does not send TEMPORARY_FAILURE but instead replies normally that
will cause there to be simultanous IKE SA rekey, which will mean that
both ends need to look up the nonces and decide which of the exchanges
won.

As the end who decided not to send TEMPORARY_FAILURE was the one who
decided this, he should be able to cope with that if he decided to do
that. For the other end this just looks like normal simultaneous
rekey, thus it will process it as normally.

This means nothing bad happens even if someone does not follow the
"MUST return TEMPORARY_FAILURE", thus we can safely change it to
"SHOULD return TEMPORARY_FAILURE", so I agree your proposal to change
it to SHOULD.

I will try to go these things through also when I am going through the
new text, i.e. check where (if anywhere) we need to have MUST, and
where we can have SHOULD (or even MAY). 

> the first bullet.  Is the third bullet really necessary?.

I think we should keep the third bullet, but remove the last sentence
of the first bullet and change the first bullet to be:

   o  The recipient of either the NAT_DETECTION_SOURCE_IP or
      NAT_DETECTION_DESTINATION_IP notification MAY compare the supplied
      value to a SHA-1 hash of the SPIs, source IP address, and port,
      and if they don't match it SHOULD enable NAT traversal or it MAY
      reject the connection attempt if NAT traversal is not allowed by
      policy.

Anyways it is bit funny to say we can reject the connection attempt
if NAT traversal is not supported, but if the end was able to parse
NAT_DETECTION_*_IP notifications it does have at least partial NAT
traversal support, so I think it is better to say "if NAT traversal is
not allowed by policy." 

> NAT is not detected be mentioned in 2.23?

Isn't this clear enough:

   An initiator can float to port 4500, regardless whether or not there
   is NAT, even at the beginning of IKE.  When either side is using port
   4500, sending with UDP encapsulation is not required, but
   understanding received packets with UDP encapsulation is required.
   UDP encapsulation MUST NOT be done on port 500.  If NAT-T is
   supported (that is, if NAT_DETECTION_*_IP payloads were exchanged
   during IKE_SA_INIT), all devices MUST be able to receive and process
   both UDP encapsulated and non-UDP encapsulated packets at any time.
   Either side can decide whether or not to use UDP encapsulation
   irrespective of the choice made by the other side.  However, if a NAT
   is detected, both devices MUST send UDP encapsulated packets.

> encoding type is "X..509 certificate" and a  HTTP_CERT_LOOKUP_SUPPORTED

I would think they mean about the same, but not exactly.

I.e. if you request Hash and URL of X.509 certificate that clearly
indicates you support fetching stuff from URL and also X.509
certificates, and it also indicates you would want certificates in the
Hash and URL format.

If you request X.509 certificate and send also
HTTP_CERT_LOOKUP_SUPPORTED that means that you support X.509
certificates, and you also support http lookups, and you prefer
getting certificates using Hash and URL format, but you also accept
the other end to send them in X.509 format if it cannot do Hash and
URL.

Note, that also in the first case if other end getting Hash and URL of
X.509 certificate request cannot do Hash and URL, it can still send
the certificates inband using X.509 as certificate request payloads
are just hints:

   The intent is not to prevent communication through the strict
   adherence of selection of a certificate based on CERTREQ, when an
   alternate certificate could be selected by the sender that would
   still enable the recipient to successfully validate and trust it
   through trust conveyed by cross-certification, CRLs, or other out-of-
   band configured means.  Thus, the processing of a CERTREQ should be
   seen as a suggestion for a certificate to select, not a mandated one.
   If no certificates exist, then the CERTREQ is ignored.  This is not
   an error condition of the protocol.  There may be cases where there
   is a preferred CA sent in the CERTREQ, but an alternate might be
   acceptable (perhaps after prompting a human operator).
-- 
[email-masked]

---

From: Scott C Moonen <[email-masked]>
Date: Thu, 17 Dec 2009 14:09:09 -0500

I suggest replacing the "Start Port" and "End Port" bullets in section 
3.13.1 with the following:

   o  Start Port (2 octets) - Value specifying the smallest port number
      allowed by this Traffic Selector.  For protocols for which port is
      undefined (including protocol 0), or if all ports are allowed,
      this field MUST be zero.  ICMP and ICMPv6 Type and Code values, as
      well as MIPv6 MH Type values, are represented in this field as
      specified in Section 4.4.1.1 of [IPSECARCH].  ICMP Type and Code
      values are treated as a single 16-bit integer port number, with
      Type in the most significant eight bits and Code in the least
      significant eight bits.  MIPv6 MH Type values are treated as a
      single 16-bit integer port number, with Type in the most
      significant eight bits.

   o  End Port (2 octets) - Value specifying the largest port number
      allowed by this Traffic Selector.  For protocols for which port is
      undefined (including protocol 0), or if all ports are allowed,
      this field MUST be 65535.  ICMP and ICMPv6 Type and Code values, as
      well as MIPv6 MH Type values, are represented in this field as
      specified in Section 4.4.1.1 of [IPSECARCH].  ICMP Type and Code
      values are treated as a single 16-bit integer port number, with
      Type in the most significant eight bits and Code in the least
      significant eight bits.  MIPv6 MH Type values are treated as a
      single 16-bit integer port number, with Type in the most
      significant eight bits.

As an alternative, for readability we could consider splitting each of 
these bullets into two paragraphs, starting the second paragraph with the 
sentence "ICMP and ICMPv6 ..."

Additionally, I suggest replacing the two later paragraphs in section 
3.13.1 starting with "The traffic selector types ..." and "Traffic 
selectors can use ..." with the following single paragraph:

   The traffic selector types 7 and 8 can also refer to ICMP or ICMPv6
   type and code fields, as well as MH Type fields for the IPv6 mobility
   header [MIPV6].  Note, however, that neither ICMP nor MIPv6 packets
   have separate source and destination fields.  The method for
   specifying the traffic selectors for ICMP and MIPv6 is shown by
   example in Section 4.4.1.3 of [IPSECARCH].

From:
Paul Hoffman <[email-masked]>
To:
Scott C Moonen/Raleigh/IBM@IBMUS
Cc:
"[email-masked]" <[email-masked]>
Date:
12/15/2009 04:30 PM
Subject:
Issue #129: Traffic Selector and ICMPv6/MIPv6

--Paul Hoffman, Director
--VPN Consortium

---

From: "Laganier, Julien" <[email-masked]>
Date: Thu, 17 Dec 2009 11:33:53 -0800

Thanks for the text proposal, Scott.

I'd like to suggest a slight variation: "MIPv6 MH Type values are treated as a single 16-bit integer port number, with Type in the most significant eight bits and the least significant eight bits set to zero."

--julien

-------------------------------------------------------
From: [email-masked] [mailto:[email-masked]] On Behalf Of Scott C Moonen
Sent: Thursday, December 17, 2009 11:09 AM
To: Paul Hoffman
Cc: [email-masked]
Subject: Re: [IPsec] Issue #129: Traffic Selector and ICMPv6/MIPv6

I suggest replacing the "Start Port" and "End Port" bullets in section 3.13.1 with the following: 

As an alternative, for readability we could consider splitting each of these bullets into two paragraphs, starting the second paragraph with the sentence "ICMP and ICMPv6 ..." 

Additionally, I suggest replacing the two later paragraphs in section 3.13.1 starting with "The traffic selector types ..." and "Traffic selectors can use ..." with the following single paragraph: 

From: 

________________________________________

--Paul Hoffman, Director
--VPN Consortium

---

From: Scott C Moonen <[email-masked]>
Date: Thu, 17 Dec 2009 14:47:15 -0500

> I'd like to suggest a slight variation: "MIPv6 MH Type values are
> treated as a single 16-bit integer port number, with Type in the
> most significant eight bits and the least significant eight bits
> set to zero."

Julien, thanks.  I agree with your suggestion,

From:
"Laganier, Julien" <[email-masked]>
To:
Scott C Moonen/Raleigh/IBM@IBMUS, Paul Hoffman <[email-masked]>
Cc:
"[email-masked]" <[email-masked]>
Date:
12/17/2009 02:34 PM
Subject:
RE: [IPsec] Issue #129: Traffic Selector and ICMPv6/MIPv6

I'd like to suggest a slight variation: "MIPv6 MH Type values are treated 
as a single 16-bit integer port number, with Type in the most significant 
eight bits and the least significant eight bits set to zero."

--julien

-------------------------------------------------------
From: [email-masked] [mailto:[email-masked]] On Behalf Of 
Scott C Moonen
Sent: Thursday, December 17, 2009 11:09 AM
To: Paul Hoffman
Cc: [email-masked]
Subject: Re: [IPsec] Issue #129: Traffic Selector and ICMPv6/MIPv6

From: 

--Paul Hoffman, Director
--VPN Consortium