[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: src addr/SPI coupling
Would it make sense to carve out a portion of the
SPI space for multicast? Also: you can always tell
the destination is multicast on the receiver, so
it wouldn't be impossible to special case _that_
(ie dst=mcast implies different SPI space).
Were there other reasons? I'm mostly curious here
what the motivation was.
Mike
Cheryl Madson writes:
> 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
>
References: