Subject: [IPsec] More Issues for IKEv2bis

From: Yoav Nir <[email-masked]>
Date: Mon, 8 Feb 2010 07:59:37 +0200

Hi. Another week, another 5 issues to discuss.

Issue #159 - Payload processing order within messages
=====================================================
(3.1) Clarify that the text:

                      Payloads are processed in the order in which
   they appear in an IKE message by invoking the appropriate processing
   routine according to the "Next Payload" field in the IKE header and
   subsequently according to the "Next Payload" field in the IKE payload
   itself until a "Next Payload" field of zero indicates that no
   payloads follow.

does NOT mean strict left-to-right processing within the message. This is just initial parsing, and further payload processing can be in any order.

It's clear to me from the surrounding text, that this means that the next payload field is used to *identify* the payloads, and this is the meaning of "process" here, rather than "act upon".  So how about:
                      Payloads are identified in the order in which
   they appear in an IKE message by looking in the "Next Payload" field in 
   the IKE header, and subsequently according to the "Next Payload" field 
   in the IKE payload itself until a "Next Payload" field of zero indicates
   that no payloads follow.

Does this clarify it for everyone?

Issue #161 - Contradiction re: authentication failure
=====================================================
2.21: the first paragraph says that if an auth failure occurs at the responder, AUTHENTICATION_FAILED is included in the protected response (to IKE_AUTH), while the last paragraph says it's a separate Informational exchange.

I think this has already been fixed, no?  Here's the text:
2.21.  Error Handling

   There are many kinds of errors that can occur during IKE processing.
   The general rule is that if a request is received that is badly
   formatted, or unacceptable for reasons of policy (such as no matching
   cryptographic algorithms), the response contains a Notify payload
   indicating the error.  The decision whether or not to send such a
   response depends whether or not there is an authenticated IKE SA.

   If there is an error parsing or processing a response packet, the
   general rule is to not send back any error message because responses
   should not generate new requests (and a new request would be the only
   way to send back an error message).  Such errors in parsing or
   processing response packets should still cause the recipient to clean
   up the IKE state (for example, by sending a DELETE for a bad SA).

   Only authentication failures (AUTHENTICATION_FAILED) and malformed
   messages (INVALID_SYNTAX) lead to a deletion of the IKE SA without
   requiring an explicit INFORMATIONAL exchange carrying a DELETE
   payload.  Other error conditions MAY require such an exchange if
   policy dictates that this is needed.

Issue #162 - Clarifying NAT-T
=============================
2.23: "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 there is a mismatch of the NAT_DETECTION_SOURCE_IP hash with all of the NAT_DETECTION_SOURCE_IP payloads received, the recipient MAY reject the connection attempt if NAT traversal is not supported." In the first sentence, the comparison is not just with the source address/port. Also, while NAT-T is a MAY, once you decide that you implement NAT-T, this comparison becomes at least a SHOULD. "If they don't match it SHOULD enable NAT-T" contradicts an earlier MUST: "if a NAT is detected, both devices MUST send UDP encapsulated packets". And the second sentence doesn't make sense as pointed out before - if you recognize these payloads, then obviously you support NAT-T. Overall, the normative part of this section needs to be reworked.

I think there are two issues here. The first is with the text "SPIs, source IP address, and port", when referring to both SOURCE_IP and DESTINATION_IP. I think this can be resolved by replacing it with "SPIs, source or recipient IP address respectively, and port".

The other issue is with the apparent contradiction with the MUSTs and the SHOULDs. I disagree with that. Although NAT-T is a MAY, it makes sense even for implementations that don't support it to recognize the detection payloads. An implementation that does not support NAT-T should really fail the creation of an IKE SA if NAT is there, because IPsec will not work. Using the detection payloads is a good way to find this out. So:
- the recipient MAY compare (because NAT-T is optional)
- SHOULD enable NAT Traversal (not MUST because maybe NAT-T is not supported, only detection)
- MAY reject the connection attempt in NAT-T is not supported.

The text doesn't specifically refer to such semi-supporting implementations, and the whole normative part actually refers only to implementations that support NAT-T. Reading it over, it does sound a little clumsy, but I don't see how an implementer could get it wrong. Unless there is some alternative text for this entire section, I suggest we leave it as is.

Issue #163 - Emphasize dynamic source address update
====================================================
Replace the last bullet in 2.23 by the slightly reworded paragraph, which I suggest to move up (before the paragraph "The specific requirements...").

Dynamic updates of peers' soucre address: there are cases where a NAT box decides to remove mappings that are still alive (for example, the keepalive interval is too long, or the NAT box is rebooted). To recover in these cases, hosts that do not support other methods of recovery such as MOBIKE [MOBIKE], and that are not behind a NAT, SHOULD send all packets (including retransmission packets) to the IP address and port from the last valid authenticated packet from the other end (that is, they should dynamically update the address). A host behind a NAT SHOULD NOT do this because it opens a possible denial of service attack. Any authenticated IKE packet or any authenticated UDP-encapsulated ESP packet can be used to detect that the IP address or the port has changed. When IKEv2 is used with MOBIKE, dynamically updating the addresses described above interferes with MOBIKE's way of recovering from the same situation. See Section 3.8 of [MOBIKE] for more information.

Also, append to the sentence (in 2.6): "Incoming IKE packets are mapped to an IKE SA only using the packet's SPI, not using (for example) the source IP address of the packet." this text: "Refer to Sec. 2.23 for cases where an IKE endpoint needs to handle dynamic change of a peer's IP address."

Not much discussion here, except for a posting by Paul on February 2nd, which didn't actually address the issue. only the section.  I have no problem accepting this change or leaving it out. Let's hear from the rest of the WG.

Issue #164 - Next Payload header of last contained (encrypted) payload
======================================================================
Change the sentence: "In the header of an Encrypted payload, the Next Payload field is set to the payload type of the first contained payload (instead of 0)." to "In the header of an Encrypted payload, the Next Payload field is set to the payload type of the first contained payload (instead of 0); conversely, the Next Payload field of the last contained payload is set to zero."

I'm fine with this change. Others?

---

From: Yaron Sheffer <[email-masked]>
Date: Mon, 8 Feb 2010 08:34:17 +0200

Issue #161 should have referred to 2.21.2, not to 2.21. But reading the text again, I am happy with the way it's worded in -07.

Thanks,
	Yaron

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Yoav Nir
> Sent: Monday, February 08, 2010 8:00
> To: IPsecme WG
> Subject: [IPsec] More Issues for IKEv2bis
> 
> 
> 2.21: the first paragraph says that if an auth failure occurs at the
> responder, AUTHENTICATION_FAILED is included in the protected response
> (to IKE_AUTH), while the last paragraph says it's a separate
> Informational exchange.
>

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 9 Feb 2010 12:34:16 +0200

Yoav Nir writes:
> ...

That change looks fine for me.

> responder, AUTHENTICATION_FAILED is included in the protected
> response (to IKE_AUTH), while the last paragraph says it's a
> separate Informational exchange. 
> 

I think so.

> 2.23: "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
> there is a mismatch of the NAT_DETECTION_SOURCE_IP hash with all of
> the NAT_DETECTION_SOURCE_IP payloads received, the recipient MAY
> reject the connection attempt if NAT traversal is not supported." In
> the first sentence, the comparison is not just with the source
> address/port. Also, while NAT-T is a MAY, once you decide that you
> implement NAT-T, this comparison becomes at least a SHOULD. "If they
> don't match it SHOULD enable NAT-T" contradicts an earlier MUST: "if
> a NAT is detected, both devices MUST send UDP encapsulated packets".
> And the second sentence doesn't make sense as pointed out before -
> if you recognize these payloads, then obviously you support NAT-T.
> Overall, the normative part of this section needs to be  
>  reworked.
> 
> I think there are two issues here. The first is with the text "SPIs,
> source IP address, and port", when referring to both SOURCE_IP and
> DESTINATION_IP. I think this can be resolved by replacing it with
> "SPIs, source or recipient IP address respectively, and port".

Yes. That change is fine.

> The other issue is with the apparent contradiction with the MUSTs
> and the SHOULDs. I disagree with that. Although NAT-T is a MAY, it
> makes sense even for implementations that don't support it to
> recognize the detection payloads. An implementation that does not
> support NAT-T should really fail the creation of an IKE SA if NAT is
> there, because IPsec will not work. Using the detection payloads is
> a good way to find this out. So: 
> The text doesn't specifically refer to such semi-supporting
> implementations, and the whole normative part actually refers only
> to implementations that support NAT-T. Reading it over, it does
> sound a little clumsy, but I don't see how an implementer could get
> it wrong. Unless there is some alternative text for this entire
> section, I suggest we leave it as is. 

I agree on that too.

> Replace the last bullet in 2.23 by the slightly reworded paragraph,
> which I suggest to move up (before the paragraph "The specific
> requirements..."). 

Moving it up is fine. 

> Dynamic updates of peers' soucre address: there are cases where a
			    ^^^^^^
typo

> NAT box decides to remove mappings that are still alive (for
> example, the keepalive interval is too long, or the NAT box is
> rebooted). To recover in these cases, hosts that do not support
> other methods of recovery such as MOBIKE [MOBIKE], and that are not
> behind a NAT, SHOULD send all packets (including retransmission
> packets) to the IP address and port from the last valid
> authenticated packet from the other end (that is, they should
> dynamically update the address). A host behind a NAT SHOULD NOT do
> this because it opens a possible denial of service attack. Any
> authenticated IKE packet or any authenticated UDP-encapsulated ESP
> packet can be used to detect that the IP address or the port has
> changed. When IKEv2 is used with MOBIKE, dynamically updating the
> addresses described above interferes with MOBIKE's way of recovering
> from the same situation. See Section 3.8 of [MOBIKE] for more
> information. 
> 
> Also, append to the sentence (in 2.6): "Incoming IKE packets are
> mapped to an IKE SA only using the packet's SPI, not using (for
> example) the source IP address of the packet." this text: "Refer to
> Sec. 2.23 for cases where an IKE endpoint needs to handle dynamic
> change of a peer's IP address." 
> 
> Not much discussion here, except for a posting by Paul on February
> 2nd, which didn't actually address the issue. only the section.  I
> have no problem accepting this change or leaving it out. Let's hear
> from the rest of the WG.

So the text is same, but you just want to move it out from the bullet
list to normal text paragraph? That is fine for me.

> Change the sentence: "In the header of an Encrypted payload, the
> Next Payload field is set to the payload type of the first contained
> payload (instead of 0)." to "In the header of an Encrypted payload,
> the Next Payload field is set to the payload type of the first
> contained payload (instead of 0); conversely, the Next Payload field
> of the last contained payload is set to zero." 
> 

Looks good.
-- 
[email-masked]