Subject: Re: [IPsec] IPsec Digest, Vol 53, Issue 3

From: Keith Welter <[email-masked]>
Date: Thu, 4 Sep 2008 10:23:13 -0700

Thanks Yoav.  I have a couple more questions inline below.

> 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.
I'm curious why you say there's no such thing as a half-open child SA.
If an implementation creates the child SA state in the process of
sending the CCSA request then it seems like that it would be reasonable
to call this child SA half-open until the CCSA response is received.
RFC 4306 section 2.6 uses the term "half-open" to describe IKE SAs so
I'm confused why the same term couldn't be applied to a child SA.
Are you implying that an implementation should not create any child SA
state until the CCSA response is received?

> 
> 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.
Ok, thanks for the clafication.

> 
> > 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.
Ok, I want to probe a little deeper here.  RFC 4301 section 4.1 says:
   "For an SA used to carry unicast traffic, the Security Parameters
   Index (SPI) by itself suffices to specify an SA.  (For information on
   the SPI, see Appendix A and the AH and ESP specifications [Ken05b,
   Ken05a].)  However, as a local matter, an implementation may choose
   to use the SPI in conjunction with the IPsec protocol type (AH or
   ESP) for SA identification."
Suppose an implementation choses to use the SPI in conjunction with
the IPsec protocol for IPsec SA identification.  Such an implementation
could have multiple IPsec SAs with the same SPI but different protocols.
It seems like this could cause interoperability problems if these SAs
are negotiated with a peer that uses only the SPI for SA
identification.  If that assumption is correct, it seems like an 
implementation should avoid using the same SPI, differentiated only by
protocol, with a given peer.  In other words, if an implementation
uses SPI x for an ESP SA it should not attempt to use SPI x for an AH
SA with the same peer simultaneously.  Would you agree?
_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

---

From: Yoav Nir <[email-masked]>
Date: Mon, 8 Sep 2008 12:18:21 +0300

> state until the CCSA response is received?

The half-open SA in RFC 4306 is an IKE SA, and it is on the responder,  
not the initiator. The meaning of the term is that the IKE SA already  
has keys, but is not yet authenticated. A child SA is just about  
exchanging keys, so there's no middle state. But this is just  
terminology.

> SA with the same peer simultaneously.  Would you agree?

That is not necessary, as each IKE peer chooses the SPI for the  
INBOUND SA. It does not choose the SPI for the outbound SA, so it  
can't make any assumptions about the outbound SPI being unique per- 
host, unique per-protocol, or unique in any sense of the word. The  
policy leads to the selection of the outbound SA, and the SPI is just  
a property of that SA.  For inbound SAs, an implementation should  
choose a unique SPI (at least per protocol) so that it can distinguish  
which SA is associated with that SPI. It should be globally unique  
rather than per-peer, so that we can allow mobility.
In other words, in inbound processing, the SPI (or SPI + protocol) is  
the key to the table. In outbound processing, it's just a value.

---

From: Tero Kivinen <[email-masked]>
Date: Fri, 5 Sep 2008 12:27:17 +0300

> I'm confused why the same term couldn't be applied to a child SA.

You can call them half-open SA, but there is not really that much you
can do with them. 

> state until the CCSA response is received?

Of course you need to create some state, but in general you cannot for
example start receiving on them, as you do not know what algorithms
the responder selected, and you cannot generate keying material as you
do not know the Nonce required for that. So in a sense it is not
really half-open SA, but only a create child SA exchange that is in
progress.

> SA with the same peer simultaneously.  Would you agree?

That should not matter, as SPI selection is local matter, the other
end should not assume the SPIs allocated by the other end are unique,
it should just use the SPIs the other end allocated without any extra
checks. As for his point of view those SPIs are only used when he is
sending packets, he will just take the SPI from SA and fill it in to
the ESP packet, only the incoming SPI (i.e. the one he allocated
himself) is used to demultiplex data.
-- 
[email-masked]
_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec