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.
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
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
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
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
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
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 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.
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
