Subject: [IPsec] Closing issue #143 (rewrite of section 1.5)

From: Yoav Nir <[email-masked]>
Date: Thu, 28 Jan 2010 14:40:02 +0200

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.

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 28 Jan 2010 16:39:32 +0200

> Is this acceptable to everyone?

Couple of comments. 

>    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).

>    that prohibits zero IKE SPIs.  The Initiator flag is set, the

s/prohibits zero IKE SPIs/prohibits zero IKE Initiator's SPI./

>    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.  
-- 
[email-masked]

---

From: Yoav Nir <[email-masked]>
Date: Sun, 31 Jan 2010 10:29:51 +0200

Fixed.  Is this OK?

 

 
 
   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.

-----Original Message-----
From: Tero Kivinen [mailto:[email-masked]] 
Sent: Thursday, January 28, 2010 4:40 PM
To: Yoav Nir
Cc: [email-masked]
Subject: [IPsec] Closing issue #143 (rewrite of section 1.5)

Couple of comments. 

Scanned by Check Point Total Security Gateway.