Yoav Nir writes:
> Is this acceptable to everyone?
Couple of comments.
> 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.
We should also note that it should use the same port number that was
used for sending this unknown ESP packet was UDP encapsulated when it
came in.
I.e. if it receives raw ESP or AH, it knows there cannot be NAT, thus
port 500 is ok.
If it receives UDP encapsulateed ESP packet with unknow SPI then it
knows there most likely is a NAT (or firewall) which requires UDP
encapsulation, thus the informational message should also be sent
using UDP encapsulation format (i.e. use the IP addresses and ports in
the incoming UDP encapsulated packet and just swap source and
destination, and the IKE packet also needs to have four octets of zero
prepended to it).
> 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
s/prohibits zero IKE SPIs/prohibits zero IKE Initiator's SPI./
> 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.
I would move the exchange type to the same list with IKE SPIs and
Message ID, ie.. change the text to be:
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
