At 4:14 PM -0500 6/18/10, Joy Latten wrote: >The last paragraph of section 2.5 in RFC 4306 states: > > 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. > >So, for clarification, if an initiator sends an IKE_SA_INIT message whose KEi >and Ni >payloads are not in order, for example, Ni comes before KEi, then it is up to >the >responder's implementation whether or nor he will accept or reject the message? >I guess I am fixated on the "SHOULD" in the above paragraph. It is acceptable >for >responder to accept the message and send second message, his IKE_SA_INIT >response?
IKEv2bis, which is now in the RFC Editor's queue, says: Although new payload types may be added in the future and may appear interleaved with the fields defined in this specification, implementations SHOULD send the payloads defined in this specification in the order shown in the figures in Sections 1 and 2; implementations MUST NOT reject as invalid a message with those payloads in any other order. --Paul Hoffman, Director --VPN Consortium _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
