Hi all.
Combining Pasi's proposed text with Tero's comments I came up with this version.
Is this acceptable to everyone?
Yoav
There are couple of cases when a node receives a packet it cannot
process, but may want to notify the sender about this situation:
o If an ESP or AH packet arrives 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.
o If an encrypted IKE request packet arrives on port 500 or 4500
with an unrecognized IKE SPI, it could be because the receiving node
has 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.
(Note that the second and third cases apply only to IKE request
packets, not response packets.)
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.
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 (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 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 INVALID_IKE_SPI or 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 is copied. The Response bit is
set to 1, and the version flags are set in the normal fashion. The
responder SHOULD copy the Exchange Type from the request.
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
