Paul Hoffman writes:
> 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).
Remove the "IKE or" part, as we are still talking about ESP/AH packet
which has unknow SPI. It cannot be IKE packet. Perhaps better to
change the whole sentence to:
If no suitable IKE SA exists, the node MAY send an informational
message without cryptographic protection to the source IP address.
If the incoming ESP or AH packet was UDP-encapsulated, then node
needs to use NAT-T IKE format and IP addresses and UDP ports from
the headers are reversed and used for return informational
message.
> 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.
I think we should explictly mention that Exchange Type of that messge
is set to "INFORMATIONAL".
> 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.
--
kivi...@iki.fi
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
