Re: [MSEC] shared SA w/ automatic keying

[Paul Lambert <paul at marvell.com>]

> -----Original Message-----
> From: msec-bounces at ietf.org [mailto:msec-bounces at ietf.org] On Behalf Of
> Subject: Re: [MSEC] shared SA w/ automatic keying
>
> 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?

This would be easy if one bit were set aside (like the high order) in the SPI that would be reserved only for multicast SPI.

Looking at RFC 4303 ... this is not there :-(  but it could be done as a implementation guideline.

The notion in RFC 4301 that reuse is possible and then mandating that you are able to demultiplex the overlap is a flawed approach and should be depreciated.  The use of an IP address with the SPI should really never be required.


Paul

>
> 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
_______________________________________________
MSEC mailing list
MSEC at ietf.org
https://www.ietf.org/mailman/listinfo/msec