Paul Hoffman writes: A few comments.
> I took Yoav's proposed replacement for the last three paragraphs of 1.5 and > made some editorial changes. This is a big enough change, I want to be sure everyone agrees to the new wording. The section now (in my temporary copy of the draft) reads: > > 1.5. Informational Messages outside of an IKE SA > > If an encrypted IKE request packet arrives on port 500 or 4500 with > an unrecognized SPI, it could be because the receiving node has > recently crashed and lost state or because of some other system > malfunction or attack. The receving node MAY send a notification of > the wayward packet with a Notify payload without cryptographic > protection to the source IP address. Such a message is not part of > an INFORMATIONAL exchange, and the receiving node MUST NOT respond to > it. Doing so could cause a message loop. > > The INVALID_SPI notification MAY be sent in an IKE INFORMATIONAL > exchange when a node receives an ESP or AH packet with an invalid > SPI. The Notification Data contains the SPI of the invalid packet. > This usually indicates a node has rebooted and forgotten an SA. If > this Notify payload is sent outside the context of an IKE SA, it > should only be used by the recipient as a "hint" that something might > be wrong (because it could easily be forged). The recipient of this > notification cannot tell whether the SPI is for AH or ESP, but this > is not important because the SPIs are supposed to be different for > the two. These two paragraphs are left from previous version and should be removed (now all they are talking about is explained in more details below). > There are some cases in which a node receives a packet that it cannot > process, but it may want to notify the sender about this situation. > > o If an ESP or AH request or response packet arrives with an There are no "requests" and "responses" in ESP and AH. Just remove these words. > unrecognized SPI. This might be due to the receiving node having > recently crashed and lost state, or because of some other system > malfunction or attack. > > o If an encrypted IKE request packet arrives on port 500 or 4500 > with an unrecognized IKE SPI. This might be due to the receiving > node having recently crashed and lost state, or because of some > other system malfunction or attack. > > o If an IKE request packet arrives with a higher major version > number than the implementation supports. > > In the first case, if the receiving node has an active IKE SA to the > IP address from whence the packet came, it MAY send an INVALID_SPI > notification of the wayward packet over that IKE SA in an > Informational exchange. The Notification Data contains the SPI of s/Informational/INFORMATIONAL > the invalid packet. The recipient of this notification cannot tell > whether the SPI is for AH or ESP, but this is not important because > the SPIs are supposed to be different for the two. If no suitable > IKE SA exists, the node MAY send an informational message without Probably s/informational/Informational ? I'm not sure because the term "Informational Message" is never formally introduced in the document apart from this section... > cryptographic protection to the source IP address, using the source > UDP port as the destination port if the packet was UDP (IKE or UDP- > encapsulated ESP or AH). In this case, it should only be used by the > recipient as a hint that something might be wrong (because it could > easily be forged). This message is not part of an Informational s/Informational/INFORMATIONAL > exchange, and the receiving node MUST NOT respond to it because doing > so could cause a message loop. The message is constructed as > follows: There are no IKE SPI values that would be meaningful to the Shouldn't the first letter in "There" be lower case 't'? > recipient of such a notification; using zero values or random values > are both acceptable, this being the exception to the rule in > Section 3.1 that prohibits zero IKE Initiator SPIs. The Initiator > flag is set, the Response bit is set to 0, and the version flags are > set in the normal fashion. In is not said which Exchange Type should be set in Informational Message (one may of course guess that it is INFORMATIONAL, but I think it is better to spell out this explicitly). > In the second and third cases, the message is always sent without > cryptographic protection (outside of an IKE SA), and includes either > an INVALID_IKE_SPI or an INVALID_MAJOR_VERSION notification (with no > notification data). The message is a response message, and thus it > is sent to the IP address and port from whence it came with the same > IKE SPIs and the Message ID and Exchange Type are copied from the > request. The Response bit is set to 1, and the version flags are set > in the normal fashion. Regards, Valery Smyslov. _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
