On Sep 4, 2008, at 8:23 PM, Keith Welter wrote:
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?
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. > 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?
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.
|
