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. > > > 2.4: this sentence is inconsistent: "The INITIAL_CONTACT > > > notification, if sent, MUST be in the first IKE_AUTH request or > > > response, not as a separate exchange afterwards; however, > > > receiving parties MAY ignore it in other messages." If it MUST be > > > only at a certain location, then it should be ignored (or even > > > rejected) in others. > > > > No. The first one says where you MUST send it, the second part says > > what you do if someone does not follow that MUST, which tells you MAY > > ignore it. > > > > There is no inconsistancy there. > > > > The text is written like this as this was changed between RFC4306 and > > draft-ietf-ipsecme-ikev2. The RFC4306 does not specify the location, > > but IKEv2bis does, and because of this old implementations might send > > INITIAL_CONTACT notifications in wrong place, and the text says that > > you are free to ignore it in those places. > > > > Support for INITIAL_CONTACT is MAY anyways (both sending and > > processing it on receive). > > > > So no need to change anything there. > > > OK, the original sentence would suddenly make sense if the word > "however" were removed. That would be ok for me. > > > 2.8.2: we should add a sentence on what happens if the peer receives > > > TEMPORARY_FAILURE and does not understand it (because it's new > > > to this spec). > > > > There is text for that alread which says (section 3.10.1): > > > > Types in the range 0 - 16383 are intended for reporting errors. An > > implementation receiving a Notify payload with one of these types > > that it does not recognize in a response MUST assume that the > > corresponding request has failed entirely. > > > > So I do not see need to change the the 2.8.2. If change is needed > > perhaps adding pointer to the 3.10.1, but I think even that is not > > needed). > > No, this is a very special case - because such implementations are > still "RFC-compliant". So we should explain how the behavior would > still be reasonable with such peers. But if someone makes special code for their implementation to do something when it receives unknown error notify (TEMPORARY_FAILURE), wouldn't it be better to instead make code that understands the notify... I mean the current code out there following the RFC4306 should be ok, with new error codes. If it is changed in any way it should be changed to send and understand TEMPORARY_FAILURE, not to add some special case for unknown notifications. Or are you thinking we should explicitly say that "if implementations follow that 3.10.1 MUST then they work fine when they receive TEMPORARY_FAILURE notifications even when they do not understand it"? -- kivi...@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
