Subject: [IPsec] Question about deleting a half-open child SA

From: Keith Welter <[email-masked]>
Date: Tue, 2 Sep 2008 14:34:16 -0700

Suppose the initiator sends an SA payload that contains both an AH and ESP 
proposal.  Before receiving the response, the initiator decides to close 
the half-open child SA.  I assume that the informational request should 
include two delete payloads, one for AH and one for ESP.  Is that correct?

Related to that question, I don't see a requirement that all proposals in 
an SA payload have the same SPI.  So, in this example, it would be 
permissible for the AH and ESP proposals to have different SPIs.  Is that 
correct?

Keith Welter
IBM Enterprise Networking Solutions
1-415-545-2694 (T/L: 473-2694)
_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

---

From: Yoav Nir <[email-masked]>
Date: Wed, 3 Sep 2008 09:52:34 +0300

Hi Keith

On Sep 3, 2008, at 12:34 AM, Keith Welter wrote:

> Suppose the initiator sends an SA payload that contains both an AH  
> and ESP proposal.  Before receiving the response, the initiator  
> decides to close the half-open child SA.  I assume that the  
> informational request should include two delete payloads, one for AH  
> and one for ESP.  Is that correct?

There's no such thing as a half-open Child SA. What you describe is a  
proposal that the initiator still hasn't received a reply for. There  
is no SA yet, at least on the initiator side. In fact the initiator  
cannot know at this point whether or not an SA is even going to be  
established, because the peer may reject the proposal, or else may  
have rebooted.

For this reason, it is not appropriate at this point to begin  
constructing the Informational message with the DELETE payloads, as  
this message will be nonsensical if the CCSA request is rejected.  
Instead, the initiator must wait until a response is received. Then it  
can either (1) do nothing, if the request was rejected or (2) delete  
the one SA that actually got created.

Doing it as you propose, would definitely result in a DELETE message  
for a non-existing SA, which is bad, although I don't see any text in  
RFC 4306 or 4306bis about what action the responder should take when  
it receives such a request. It's probably not delete-the-ike-sa bad,  
but still something you shouldn't do.

> Related to that question, I don't see a requirement that all  
> proposals in an SA payload have the same SPI.  So, in this example,  
> it would be permissible for the AH and ESP proposals to have  
> different SPIs.  Is that correct?

Yes, that's correct. The SA payload is ready to offer protocols of  
variable SPI size, so while both AH and ESP use a 4-byte SPI, maybe  
someday we'll have superESP with an 8-byte SPI. In that case, an SA  
payload with two proposals, one for AH and the other for superESP  
would have to have different SPIs. As it is, it's still possible to  
use different values, but it's not a requirement.

---

From: Tero Kivinen <[email-masked]>
Date: Wed, 3 Sep 2008 14:14:29 +0300

> include two delete payloads, one for AH and one for ESP.  Is that correct?

There is no really working method to delete the SA until it is
created, i.e. you cannot delete half open SAs. Even if you send delete
notifications, it might be possible that the responder has not yet
seen the SA creation packet, thus delete SA would refer to unknown
SPIs, and responder would reply with error to both of them.

The best is simply wait for the SA negotiation to finish and delete it
after that. This is anyways required if the other end only supports
window size of 1, as you cannot send delete notifacation before you
get reply back to your create child SA exchange.

> permissible for the AH and ESP proposals to have different SPIs.  Is that 

Yes. The SPIs does not need to be same. There might be for example
some implementation which could even allocate the SPIs for different
protocols on different ranges. 
-- 
[email-masked]
_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec