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

[Tero Kivinen <kivinen at iki.fi>]

Keith Welter writes:
> 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.

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

> Are you implying that an implementation should not create any child SA
> 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.

> 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 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.
-- 
kivinen at safenet-inc.com
_______________________________________________
IPsec mailing list
IPsec at ietf.org
https://www.ietf.org/mailman/listinfo/ipsec