Fixed.  Is this OK?

   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,
   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 
   (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 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 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.  





-----Original Message-----
From: Tero Kivinen [mailto:kivi...@iki.fi] 
Sent: Thursday, January 28, 2010 4:40 PM
To: Yoav Nir
Cc: ipsec@ietf.org
Subject: [IPsec] Closing issue #143 (rewrite of section 1.5)

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

Scanned by Check Point Total Security Gateway.
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Reply via email to