[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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: