Hi Tero,
I was ready to accept your answer, until I came across the following sentence
in -07.
"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."
This seems to say exactly what I was proposing! Did I miss another statement in
the document where we say the opposite (that payload order doesn't matter)?
Thanks,
Yaron
> -----Original Message-----
> From: Tero Kivinen [mailto:kivi...@iki.fi]
> Sent: Wednesday, January 20, 2010 18:29
> To: Yaron Sheffer
> Cc: ipsec@ietf.org
> Subject: RE: [IPsec] IKEv2-bis, comments up to 2.16
>
> Yaron Sheffer writes:
> > > > 1.4: "The processing of an INFORMATIONAL exchange is determined
> by
> > > > its component payloads." Adding "The payloads are processed in
> > > > strict left-to-right order" would make it deterministic, and is
> > > > probably what people do today.
> > >
> > > There should be no need to make the processing deterministic, as at
> > > least I cannot think of case where the processing order would
> matter,
> > > and I do not want someone to start complaining if someone process
> them
> > > in "wrong" order.
> > >
> > > I do not think the addition should be done.
> >
> > I'm not convinced. CP payloads can do many things, including side
> > effects on other network components. Notifications are even more
> > open ended, with every IKE extension adding a new one. We should
> > recommend some deterministic processing.
>
> None of the current notifications or configuration payloads have such
> deterministic processing requirements, and if some extension adds new
> notifications of configuration payloads, then that document should
> also add requirement for their deterministic processing.
>
> For example in our implementation it is current impossible to process
> payloads in the order they appear in the packet, as we first parse all
> payloads from the packet, and during that tome process some of the
> payloads (for example configration payloads, and some notify
> payloads), but then for example delete payloads are processed later
> during INFORMATIONAL exchange processing. Also most of the notify
> payloads are processed later the initial pass just goes through those
> we need to see early (for example the NAT_DETECTION_* payloads), but
> some like INITIAL_CONTACT notifications are processed much later (i.e.
> only after the IKE_AUTH AUTH payloads has been verified).
>
> Adding requirement for order of payload processing would make
> implementation quite a much harder, and as there is currently no
> reason for it, I do not think it is good idea to add such requirement.
>
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
