Subject: [IPsec] Bis issues 16 and 45: order of IKE payloads (now here's a controversial one!)

From: Yaron Sheffer <[email-masked]>
Date: Wed, 28 Jan 2009 00:49:47 +0200

Current text:

NOTE TO IMPLEMENTERS: Does anyone require that the payloads be in the order shown in the figures in Section 2? Can we eliminate the requirement in the following paragraph? If not, we will probably have to add a new appendix with the order, but there is no reason to do that if no one actually cares. {{ Remove this paragraph before the document is finalized, of course. }}

Tero: Our implementation do not care about the order of the payloads except in some specific places (CERT payloads and so on).

Paul: Not done. We still need to hear from others.
Current text (sec. 2.5):

{{ Demoted the SHOULD in the second clause }}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; implementations are explicitly allowed to reject as invalid a message with those payloads in any other order.

Tero: I would really like to change this to say that payloads must be accepted in any order, but implementations should try to send them out in the order shown in the figures. Exceptions to this is the CERT payloads (the end entity cert MUST be first), and REKEY and COOKIE notifies.

Paul: Not done. This is interesting, but should be discussed on the list.
Yaron: this really is a major protocol change, we cannot guarantee that no existing implementation cares about payload order. I suggest to leave the protocol as-is, although nobody likes this constraint.

Email secured by Check Point

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

---

From: Scott C Moonen <[email-masked]>
Date: Wed, 28 Jan 2009 12:45:03 -0500

I am comfortable saying that you SHOULD send the payloads in the indicated 
order and MUST accept them in any order (except where the order implies 
meaning, as with CERT and CERTREQ).

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

From:
Yaron Sheffer <[email-masked]>
To:
IPsecme WG <[email-masked]>
Date:
01/27/2009 10:13 PM
Subject:
[IPsec] Bis issues 16 and 45: order of IKE payloads (now here's a 
controversial one!)

Current text:
NOTE TO IMPLEMENTERS: Does anyone require that the payloads be in the 
order shown in the figures in Section 2? Can we eliminate the requirement 
in the following paragraph? If not, we will probably have to add a new 
appendix with the order, but there is no reason to do that if no one 
actually cares. {{ Remove this paragraph before the document is finalized, 
of course. }} 
Tero: Our implementation do not care about the order of the payloads 
except in some specific places (CERT payloads and so on). 
Paul: Not done. We still need to hear from others. 
Current text (sec. 2.5):
{{ Demoted the SHOULD in the second clause }}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; implementations are explicitly allowed to reject as invalid a message 
with those payloads in any other order. 
Tero: I would really like to change this to say that payloads must be 
accepted in any order, but implementations should try to send them out in 
the order shown in the figures. Exceptions to this is the CERT payloads 
(the end entity cert MUST be first), and REKEY and COOKIE notifies. 
Paul: Not done. This is interesting, but should be discussed on the list. 
Yaron: this really is a major protocol change, we cannot guarantee that no 
existing implementation cares about payload order. I suggest to leave the 
protocol as-is, although nobody likes this constraint.

---

From: Yaron Sheffer <[email-masked]>
Date: Wed, 28 Jan 2009 21:43:50 +0200

Except that your proposal would make existing implementations (that assume a specific payload order as a responder) noncompliant.

            Yaron

________________________________
From: Scott C Moonen [mailto:[email-masked]]
Sent: Wednesday, January 28, 2009 19:45
To: Yaron Sheffer
Cc: IPsecme WG; [email-masked]
Subject: Re: [IPsec] Bis issues 16 and 45: order of IKE payloads (now here's a controversial one!)

I am comfortable saying that you SHOULD send the payloads in the indicated order and MUST accept them in any order (except where the order implies meaning, as with CERT and CERTREQ).

From:

To:

Date:

01/27/2009 10:13 PM

Subject:

[IPsec] Bis issues 16 and 45: order of IKE payloads (now here's a controversial one!)

________________________________

Current text:

---

From: Scott C Moonen <[email-masked]>
Date: Wed, 28 Jan 2009 15:35:48 -0500

Certainly -- sorry, to clarify, I'm not advocating it, just stepping up 
for the roll call and observing that it would not be a hardship for me.

From:
Yaron Sheffer <[email-masked]>
To:
Scott C Moonen/Raleigh/IBM@IBMUS
Cc:
IPsecme WG <[email-masked]>, "[email-masked]" 
<[email-masked]>
Date:
01/28/2009 02:44 PM
Subject:
RE: [IPsec] Bis issues 16 and 45: order of IKE payloads (now here's a 
controversial one!)

Except that your proposal would make existing implementations (that assume 
a specific payload order as a responder) noncompliant.
 
            Yaron

From: Scott C Moonen [mailto:[email-masked]] 
Sent: Wednesday, January 28, 2009 19:45
To: Yaron Sheffer
Cc: IPsecme WG; [email-masked]
Subject: Re: [IPsec] Bis issues 16 and 45: order of IKE payloads (now 
here's a controversial one!)

From: 

Current text:

---

From: [email-masked]
Date: Wed, 28 Jan 2009 21:11:55 +0000

All,
It seems to me that implementations should be able to handle out of order  
payloads - and as Scott noted, exceptions being where specific orderings  
are specified and required. Reason for this - if you don't allow for out of  
ordering payloads, then you'll probably have to account for all payloads  
which may not be very scalable due to future feature support. Of course,  
for backwards compatibility to account for devices that send canned  
messages, we could specify a base fixed message format and allow for out of  
order payloads hence forth. But in general, shouldn't ALL devices be able  
to handle unknown payload types? If so, older devices shouldn't really care  
where you place one of the newer/unknown type payload in a message. I guess  
what I am saying is this: if All devices can handle unknown payload types,  
than out of order packets should not be an issue.

- Jeff Sun

On Jan 28, 2009 12:35pm, Scott C Moonen <[email-masked]> wrote:
>
> Certainly -- sorry, to clarify, I'm
> not advocating it, just stepping up for the roll call and observing that
> it would not be a hardship for me.
>
>
>
> Yaron Sheffer [email-masked]>
>
> To:
> IPsecme WG [email-masked]>, "[email-masked]"
> [email-masked]>
>
> Date:
> 01/28/2009 02:44 PM
>
> Subject:
> RE: [IPsec] Bis issues 16 and 45: order
> of IKE payloads (now here's a controversial one!)
>
>
>
>
>
>
>
>
> Except that your proposal would
> make existing implementations (that assume a specific payload order as
> a responder) noncompliant.
>
>
>
>
> Yaron
>
>
>
>
>
>
>
>
> Yaron Sheffer [email-masked]>
>
>
> To:
>
> IPsecme WG [email-masked]>
>
>
> Date:
>
> 01/27/2009 10:13 PM
>
>
> Subject:
>
> [IPsec] Bis issues 16 and 45: order
> of IKE payloads (now here's a controversial one!)
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Current text:
>
> NOTE TO IMPLEMENTERS: Does anyone
> require that the payloads be in the order shown in the figures in Section
> 2? Can we eliminate the requirement in the following paragraph? If not,
> we will probably have to add a new appendix with the order, but there is
> no reason to do that if no one actually cares. {{ Remove this paragraph
> before the document is finalized, of course. }}
>
> Tero: Our implementation do not
> care about the order of the payloads except in some specific places (CERT
> payloads and so on).
>
> {{ Demoted the SHOULD in the second
> clause }}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; implementations are explicitly allowed to
> reject as invalid a message with those payloads in any other order.
>
> Tero: I would really like to change
> this to say that payloads must be accepted in any order, but  
implementations
> should try to send them out in the order shown in the figures. Exceptions
> to this is the CERT payloads (the end entity cert MUST be first), and  
REKEY
> and COOKIE notifies.
> Yaron: this really is a major protocol change, we cannot guarantee
> that no existing implementation cares about payload order. I suggest to
> leave the protocol as-is, although nobody likes this constraint.
>
>
>
>
>
>

---

From: Yoav Nir <[email-masked]>
Date: Thu, 29 Jan 2009 09:12:38 +0200

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Yaron Sheffer
Sent: Wednesday, January 28, 2009 12:50 AM
To: IPsecme WG
Subject: [IPsec] Bis issues 16 and 45: order of IKE payloads (now here's a controversial one!)

Current text:

I may have replied to this before, but our implementation behaves like Tero's. We don't even require that all IKE SA payloads precede all Child SA payloads in the IKE_AUTH exchange.