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?
, and the policy of the boxes in question. An IDS might LIKE to examine content, but if if does not have a tight link to a firewall, it may just be disappointed by an inability to examine content. > >...this, > >See discussion in the archives from 6-Aug and 7-Aug entitled >"Motivation for ESP-null marking", particularly two responses from Ken >Grewal. I'll go back and check; thank's for the pointer. >... > >As you've said, it's only the middlebox that inspects the packets, and >they already do it at the same data rate. It's not really necessary to >measure entropy. They only need to run their usual inspection, and get >random data instead of the protocol they were expecting. maybe, maybe not. And
RSS Feed