pasi.ero...@nokia.com writes:
> 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 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 first and third cases apply only to IKE request
> packets, not response packets.)
The first case applies to ESP or AH packets, so this text should apply
only to the last two cases.
> 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. The Initiator flag is set, the Response bit is set to
> 0, and the version flags are set in the normal fashion.
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?
> 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.
Otherwise the text looked good.
--
kivi...@iki.fi
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
