pasi.ero...@nokia.com writes: > > This is against the text in the section 3.1 which says: > > > > o Initiator's SPI (8 octets) - A value chosen by the initiator to > > identify a unique IKE security association. This value MUST NOT > > be zero. > > > > Was that intentional, i.e. can both the Initiator's and responder's > > SPIs be zero? > > I didn't change this part; the text has been there since the first > draft (and is also in RFC 4718, section 7.7). Here's what 4718 said: > > In case of INVALID_SPI, however, there are no IKE SPI values that > would be meaningful to the recipient of such a notification. Also, > the message sent is now an INFORMATIONAL request. A strict > interpretation of the specification would require the sender to > invent garbage values for the SPI fields. However, we think this > was not the intention, and using zero values is acceptable. > > (References: "INVALID_IKE_SPI" thread, June 2005.) > > Since the value will be anyway meaningless to the recipient, I don't > think it matters what it is; so I would propose we leave this as-is.
Should we note something that we know this is against MUST in section 3.1, but sending zero initiator SPI is still ok? The problem I have with this text, is that I know that some day someone will come to me and ask me to explain why we send zero initiator SPI when sending these error notifications even when there is text saying that initiator SPI MUST NOT be zero... (and yes, I am used to explaining things already saying that "this is because the document is internally inconsistent" :-) The text in RFC4718 at least brings this issue out, the text put to the ikev2bis is silent about the internal inconsistency. -- kivi...@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
