Re: [MSEC] shared SA w/ automatic keying

[gmgietf at identaware.com]

Hi Michael, 

I am not sure that I understand your question. I think you are describing an 
application wherein one unicast IPsec SA is shared by a set of three or more 
endpoints. Although this proposed SA resembles a group IPsec SA, in your 
scenario the SA is identified only by its SPI, and not using the 2-tuple 
{destination multicast IP address, SPI}. The SA identifier topic is 
discussed in section 4.1 of RFC4301. It explains how SPI assignments of a 
GKM are kept independent of the SPI assigned by an IKE subsystem. 

Perhaps your question could be rephrased to be: how could IKE and a GKM 
coordinate their SPI assignments such that IKE does not assign a unicast SPI 
that has been allocated by the GKM to a group IPsec SA? or assure that an 
SPI allocated by the IKE is not used by the GKM? 

There is no IPsec standardized method to achieve this constraint on unicast 
SPI assignment. Coordination of IKE and the GKM would require the 
distributed management of the SPI identifier space across all key management 
systems (both IKE and GKM) participating in a security domain. 

hth,
   George 

Michael Noisternig writes: 

> Hi all, 
>
> the IPsec SA/SP management framework supports SAs shared among multiple 
> devices (for unicast communication). This is probably frequently done when 
> keys are set up manually. Because of this sharing, IKE cannot be used for 
> automatic keying. However, also GKM protocols cannot be used since the SPI 
> (selected by the GCKS) may conflict with current SPIs. (SAs for unicast 
> packets are looked up using the SPI solely. A distinguisher like a 
> multicast dst. address as in msec-ipsec-extensions is not at hand.) 
>
> It seems that SA sharing is not compatible with automatic keying (or at 
> least, automatic SPI selection); however, I could not find any statement 
> on this in the ipsec/msec documents. 
>
> Of course, a question is why you would want to do SA sharing. (a) One 
> point is connection state overhead. (b) Another may be unidirectional 
> links. Consider this (contrived) scenario: 
>
>        A (GCKS)
>       ^ ^
>      /   \
>     v     v
>     B---->C 
>
> A can communicate bidirectionally with B and C, but C cannot send data to 
> B. Therefore, B and C cannot negotiate keys; however, C may receive shared 
> keys from A (which could be the GCKS in addition to a normal group 
> member). 
>
> Not sure if (b) would happen in real world, but (a) may. 
>
> What is your opinion on this issue? 
>
> Thanks for any answers,
> Michael
> _______________________________________________
> MSEC mailing list
> MSEC at ietf.org
> https://www.ietf.org/mailman/listinfo/msec


_______________________________________________
MSEC mailing list
MSEC at ietf.org
https://www.ietf.org/mailman/listinfo/msec