Hi Valery,
I would like to hear other people's opinion on this issue. At the very least,
the text I'm citing should be clarified.
BTW, Vendor ID payloads can appear anywhere in the message (per Appendix C), so
you can just put them first and you're fine.
Thanks,
Yaron
> -----Original Message-----
> From: Valery Smyslov [mailto:[email protected]]
> Sent: Friday, January 22, 2010 20:55
> To: Yaron Sheffer; Tero Kivinen
> Cc: [email protected]
> Subject: Re: [IPsec] IKEv2-bis, comments up to 2.16
>
> Hi Yaron,
>
> > 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)?
>
> The text you cited doesn't impose any requirements in terms of RFC2119.
> It's just a general rule which is to be followed in most cases. But it
> doesn't
> mean that there must be no exceptions to this rule.
>
> I think, Tero is absolutely right here - requiring payloads to be
> processed
> in the same order as they appear in the message will make
> implementations
> more complex. Moreover, VendorID payloads MUST be processed prior
> to any other, otherwise we lose an ability to use any private values in
> the
> same
> message (and, as a result - no private values in IKE_SA_INIT at all,
> as there are no prior messages).
>
> Regards,
> Valery Smyslov.
>
>
>
> Scanned by Check Point Total Security Gateway.
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
