Yaron Sheffer writes: > 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."
That says there is nothing in the spec which requires you to do out of order payload processing. It does not say you cannot do that, and as there is not really anything where the result would be different depending in which order you process payloads the way implementation processes payloads does not really matter. On the other hand the parsing needs to be done in the order the payloads are in the packet (it would be very hard to do in any other order :-), and if the parsing causes for example UNSUPPORTED_CRITICAL_PAYLOAD, then that should be sent before the rest of the payloads are parsed (i.e. the first unsupported critical payload should trigger that error). > 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)? Nope, but the text above does not forbid any other processing order, as long as the end result will be same, or at least this is how I have interpreted it. The text is not MUST in interoperability sense, it is just text explaining how the processing of packets happens, and as there is not really a way to detect how the implementation processes packets from the outside, it does not need MUST in interoperability sense. Your text would add MUST in interoperability sense, and I would like to see how you are going to test that some product really supports that MUST. -- kivi...@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
