Hi George, gmgietf at identaware.com schrieb:
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
Right. A unicast SA shared among several endpoints.
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
Sure, because there is no multicast address used; communication is unicast, just the SA (the keys) are shared/coordinated among all the endpoints.
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.
But this only considers multicast SAs, i.e. packets with a multicast address as destination.
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?
Or: How could IKE and a GKM coordinate their SPI assignments such that GKM does not assign a SPI for a group (shared unicast) SA that has been allocated by the IKE to a unicast SA? I could rephrase my question like that, yes.
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.
That is what I was thinking, but I was wondering if this issue was touched in any IETF documents. Apparently not.
hth, George
Thanks, Michael
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---->CA 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