[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: src addr/SPI coupling
> In the case of multicast traffic, where separate key servers may be
> controlling keys/SA assignment for different multicast sessions,
> you'd have to come up with a mechanism to ensure that there are
> (a) no collisions in SPI assignment across the possible universe of
> key servers, (b) but still have reasonable randomness to the SPI
> allocation (the phase 2 SPIs are used as additional randomness
> in the key derivation), and (c) the SPI space per address is
> sufficiently
> large enough for rekeying for some noticeable amount of time (because
> of (b)).
Are (b) and (c) really a problem? The entropy provided by the SPIs is only
needed to provide distinct keymat for multiple SAs in the same packet,
right? A counter in the key derivation would serve the same purpose.
Andrew
-------------------------------------------
Upon closer inspection, I saw that the line
dividing black from white was in fact a shade
of grey. As I drew nearer still, the grey area
grew larger. And then I was enlightened.
> -----Original Message-----
> From: owner-ipsec@lists.tislabs.com
> [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Cheryl Madson
> Sent: Monday, May 07, 2001 4:07 PM
> To: Michael Thomas
> Cc: Jan Vilhuber; Michael Thomas; ipsec@lists.tislabs.com
> Subject: Re: src addr/SPI coupling
>
>
> At 11:24 AM 5/7/2001, Michael Thomas wrote:
> >Jan Vilhuber writes:
> > > Actually, section 4.1 from rfc 2401 states:
> > >
> > > A security association is uniquely identified by a
> triple consisting
> > > of a Security Parameter Index (SPI), an IP
> Destination Address, and a
> > > security protocol (AH or ESP) identifier. [...]
> > >
> > > It's not the source address.
> >
> > OK, that changes the sense of the problem, but not
> > the original question. Why does there need to be
> > any dependency on the destination address to
> > select the right SA? This still seems like it
> > could run into trouble on the mobile node
> > incoming traffic if the destination address
> > were "wrong" (which is, I think, the way a
> > naive stack might view it.)
> >
> > Mike
>
> In the case of unicast traffic, one could argue that given a
> sufficiently large
> SPI space, that there might not be a need to have it on a
> per-destination
> address per box. That's assuming the IKE deamon(s) are all coordinated
> across the box. [Yes, there's normally one, but it probably
> shouldn't be
> that constrained...] That means being able to have one SPI space for
> tens of thousands of connections on a large aggregation box, and still
> enough for a reasonable number of rekeys of those connections.
>
> Keep in mind, though, that IPsec was originally designed with
> at least an eye towards multicast (even though we didn't claim to
> understand the problem set much then...).
>
> In the case of multicast traffic, where separate key servers may be
> controlling keys/SA assignment for different multicast sessions,
> you'd have to come up with a mechanism to ensure that there are
> (a) no collisions in SPI assignment across the possible universe of
> key servers, (b) but still have reasonable randomness to the SPI
> allocation (the phase 2 SPIs are used as additional randomness
> in the key derivation), and (c) the SPI space per address is
> sufficiently
> large enough for rekeying for some noticeable amount of time (because
> of (b)).
>
> In fact, we came up with (dest addr, protocol, spi) mainly because of
> multicast. But that was even before my time...
>
> thx - C
>
>
>
> ===============================================
>
> Cheryl Madson
> Strategic Cryptographic Development; Systems & Solutions Engineering
> Cisco Systems, Inc.
> cmadson@cisco.com
>
>
Follow-Ups:
References: