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

From: Alfred Hönes <[email-masked]>
Date: Sun, 15 Feb 2009 22:50:17 +0100 (MEZ)

At Sun, 15 Feb 2009 12:10:48 -0800, Paul Hoffman wrote:

> 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

The issue clearly extends to sequencing requirements in extension
specifications, and such requirements can also be stated in the prose.
Therefore, I would prefer to revert to Postel's Principle, and
describe the guiding principles more precisely and more general.

Changing the MUST to a SHOULD for the sender will add some amount of
flexibility; IMO, the requirement for the receiver could be dropped.
Thus, unless existing implementations indeed insist on the original
order rules at the receiver side, I suggest the following text:

|  New payload types may be added in the future and may appear
|  interleaved with the fields defined in this specification.
|  Implementations SHOULD send payloads in the order specified in the
|  text and the figures of this document and extension documents -- with
|  priority to text and to this document -- unless specified explicitely
|  in a different or more stringent manner.

Kind regards,
  Alfred Hönes.

-- 

+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.-Phys.  |
| Gerlinger Strasse 12   |  Phone: (+49)7156/9635-0, Fax: -18         |
| D-71254  Ditzingen     |  E-Mail:  [email-masked]                     |
+------------------------+--------------------------------------------+