Subject: [IPsec] Payload order in IKEv2 (tracker issues #16 and #45)

From: Paul Hoffman <[email-masked]>
Date: Sun, 15 Feb 2009 12:10:48 -0800

Greetings again. We have not come to resolution on this topic, and we should make another attempt before we give up.

RFC 4306 says:
   Although new payload types may be added in the future and may appear
   interleaved with the fields defined in this specification,
   implementations MUST send the payloads defined in this specification
   in the order shown in the figures in section 2 and implementations
   SHOULD reject as invalid a message with those payloads in any other
   order.

There are a few problems with this. For one, there are payloads that are only a few figures in section 2; there are many more figures in section 1. Another problem is that there are plenty of payloads that are defined in RFC 4306 that are not shown in any figure in section 2; these are not "future" but current payloads.

I see three options:

a) Downgrade the MUST to a SHOULD without other changes.

b) Remove this altogether because the paragraph is insufficient for implementation and, in part, wrong.

c) Do nothing.

Both (a) and (b) will cause implementations that follow the MUST and SHOULD in the paragraph to not interoperate with implementations that do not follow the given order. (a) is not completely clear. (c) leaves insufficient and unclear mandates in the document.

So far, no one has said that their implementation will fail if it gets payloads that it thinks are not in the order shown in section 2. On the other hand, not all implementers of IKEv2 are reading the drafts or following this list, so that is far from definitive.

Thoughts? Other ways forwards?

--Paul Hoffman, Director
--VPN Consortium

---

From: Yaron Sheffer <[email-masked]>
Date: Mon, 16 Feb 2009 08:15:53 +0200

Hi Paul,

Thanks for the lucid analysis. To muddy the water some more, http://tools.ietf.org/html/draft-ietf-ipsec-ikev2-04 has this same paragraph refer to what is today Sec. 1 of the RFC, the "right" section, the one that describes all the base exchanges. However in -05, this was already changed (but with no mention in the change log). Clearly 6 years ago, someone intended IKEv2 payloads to be in order. This does not obligate us today though.

Thanks,
	Yaron

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Paul Hoffman
> Sent: Sunday, February 15, 2009 22:11
> To: IPsecme WG
> Subject: [IPsec] Payload order in IKEv2 (tracker issues #16 and #45)
> 
> Greetings again. We have not come to resolution on this topic, and we
> should make another attempt before we give up.
> 
> RFC 4306 says:
> There are a few problems with this. For one, there are payloads that are
> only a few figures in section 2; there are many more figures in section 1.
> Another problem is that there are plenty of payloads that are defined in
> RFC 4306 that are not shown in any figure in section 2; these are not
> "future" but current payloads.
> 
> I see three options:
> 
> Both (a) and (b) will cause implementations that follow the MUST and
> SHOULD in the paragraph to not interoperate with implementations that do
> not follow the given order. (a) is not completely clear. (c) leaves
> insufficient and unclear mandates in the document.
> 
> So far, no one has said that their implementation will fail if it gets
> payloads that it thinks are not in the order shown in section 2. On the
> other hand, not all implementers of IKEv2 are reading the drafts or
> following this list, so that is far from definitive.
> 
> _______________________________________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec
> 
> Scanned by Check Point Total Security Gateway.
> 
> Scanned by Check Point Total Security Gateway.

Email secured by Check Point

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 17 Feb 2009 14:45:33 +0200

> a) Downgrade the MUST to a SHOULD without other changes.

I think that should be fine, but I think more important would be to
change "SHOULD reject" to "SHOULD NOT reject" or even "MUST NOT
reject". As I do not think anybody currently follows this SHOULD I
think that should not make any current real implementations
incompatible with new versions.
-- 
[email-masked]

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 17 Feb 2009 07:13:39 -0800

At 2:45 PM +0200 2/17/09, Tero Kivinen wrote:
>reject".

Sorry, yes, I forgot that. (a) is "downgrade the 'MUST send' to 'SHOULD send' and therefore change the 'SHOULD reject' to 'MUST NOT reject'".

--Paul Hoffman, Director
--VPN Consortium