Thanks Yoav. I have a couple more questions
> Hi Keith
> On Sep 3, 2008, at 12:34 AM, Keith Welter wrote:
> > Suppose the initiator sends an SA payload that contains both
> > and ESP proposal. Before receiving the response, the initiator
> > decides to close the half-open child SA. I assume that
> > informational request should include two delete payloads, one
> > and one for ESP. Is that correct?
> There's no such thing as a half-open Child SA. What you describe is
> 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
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
> 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
> 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
> > 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:
an SA used to carry unicast traffic, the Security Parameters
Index (SPI) by itself suffices to specify an SA. (For information
the SPI, see Appendix
and the AH and ESP specifications
Ken05a].) However, as a local matter, an implementation may
to use the SPI in conjunction with the IPsec protocol type (AH
ESP) for SA identification."
Suppose an implementation choses to use the SPI in
the IPsec protocol for IPsec SA identification. Such
could have multiple IPsec SAs with the same SPI but
It seems like this could cause interoperability problems
if these SAs
are negotiated with a peer that uses only the SPI
identification. If that assumption is correct,
it seems like an
implementation should avoid using the same SPI, differentiated
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