Subject: RE: [Ipsec] IKEv2: invalid SPI in DELETE payload

From: [email-masked]
Date: Wed, 18 Jan 2006 14:07:30 +0200

Tero Kivinen wrote:

> The problem is that if responder's policy changes then he might want
> to delete SA even when there has not been any traffic over that SA
> (which would indicate that the other end managed to create the SA).

I finally managed to write something for the clarifications document
about this issue. Here's some analysis:

X.X Deleting a non-existent SPI

   The specification does not describe what happens when a Delete
   payload containing an unrecognized SPI is received. Normally, this
   situation does not happen, since the state should be synchronized.
   However, there is at least one one rare situation where this can
   actually happen.

   Consider a situation where host A creates a CHILD_SA pair, but soon

   thereafter host B decides to delete it (possible because its policy
   changed):

      Host A                      Host B
     --------                    --------
      send req1: SA(..,SPIa,..),.. -->
                              --> recv req1
                       (lost) <-- send resp1: SA(..,SPIb,..),..

                              <-- send req2: D(SPIb)
      recv req2

   At this point, host A has not yet received message resp1 (and is
   retransmitting message req1), so it does not recognize SPIb in
   message req2. What should host A do?
 
   One option would be to reply with an empty Informational response.
   However, this same reply would also be sent if host A has received
   resp1, but has already sent a new request to delete the SA that was
   just created. This would lead to a situation where the peers are no
   longer in sync about which SAs exist between them.  However, host B
   would eventually notice that the other half of the CHILD_SA pair
   has not been deleted. Section 1.4 describes this case and notes
   that "a node SHOULD regard half-closed connections as anomalous and
   audit their existence should they persist", and continues that "if
   connection state becomes sufficiently messed up, a node MAY close
   the IKE_SA".

   Another solution that has been proposed is to reply with an
   INVALID_SPI notification which contains SPIb. This would explicitly
   tell host B that the SA was not deleted, so host B could try
   deleting it again later. However, this usage is not part of the
   IKEv2 specification, and would not be in line with normal use
   of the INVALID_SPI notification where the data field contains
   the SPI the recipient of the notification would put in outbound 
   packets.

   Currently, this document recommends (to be determined)
   
   (References: "IKEv2: invalid SPI in DELETE payload" thread, Dec
   2005/Jan 2006.)

To me, it looks like the former approach would be sufficient (it's not
very serious if this kind of "half-closed SA" exists for some time),
and better in line with what the spec currently says. Any comments?

Best regards,
Pasi

_______________________________________________
Ipsec mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipsec

---

From: "Yoav Nir" <[email-masked]>
Date: Wed, 18 Jan 2006 14:18:58 +0200

>    thereafter host B decides to delete it (possible because its policy

Agree. INVALID_SPI is not expected in response to a DELETE. Besides, the
initiator wanted this SPI to no longer exist. It doesn't exist. Mission
accomplished. Receiving this empty response is enough of an indication that
the states are our of sync that the initiator can silently delete (and log)
the other half of the SA.

---

From: Alejandro Perez Mendez <[email-masked]>
Date: Wed, 18 Jan 2006 13:46:52 +0100

> the other half of the SA.

And what happen when the responder receives a CREATE_CHILD_SA request
including a REKEY_SA payload that contains an unknown SPI? Should the
responder send INVALID_SPI in this case? Should the responder ignore
such request?

	     Host A                      Host B      		--------
--------
	      send req1: SA(..,SPIa,..),.. -->
                                 --> recv req1
                       (lost) <-- send resp1: SA(..,SPIb,..),..
                              <-- send req2: REKEY_SA(SPIb)
              recv req2

Regards!
--
OpenIKEv2 develop team http://openikev2.sf.net

Alejandro Perez Mendez
Pedro J. Fernandez Ruiz

---

From: [email-masked]
Date: Wed, 18 Jan 2006 15:30:42 +0200

> responder send INVALID_SPI in this case? Should the responder ignore

The same situation (host receives a rekeying request with an
unknown SPI) can also happen if both peers start rekeying at
the same time. 

This case is discussed in the clarifications draft Section 5.12;
currently it recommends replying with NO_PROPOSAL_CHOSEN.
I'm not sure if this is the best possible approach, but it
seemed reasonable when that text was written...

(But the presumably the "host A creates an SA, host B immediately
starts rekeying it" case should be quite rare.)

Best regards,
Pasi

---

From: Alejandro Perez Mendez <[email-masked]>
Date: Wed, 18 Jan 2006 17:08:47 +0100

> seemed reasonable when that text was written...

It's good for me. I had not read entirely this section before.

> starts rekeying it" case should be quite rare.)

One may want to rekey in intervals of 1 or 2 seconds and retransmition
time may be superior. It is a rare case, but it is not impossible.

Regards
 
Alejandro Perez Mendez
Pedro J. Fernandez Ruiz