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

Re: SCTP and IPsec issues



On Fri, Mar 23, 2001 at 06:27:48PM -0500, Angelos D. Keromytis wrote:
> 
> 1) Currently, IPsec SAs are identified by the triplet
> 
>   (destination address, SPI, security protocol)
> 
> for the purposes of locating them in the SAD. Since SCTP packets can
> have any of a set of destination addresses, this identification
> needs to be extended to be
>
>  ({set of destination addresses}, SPI, security protocol).
> 
> The alternative (setting up a number of SAs, for each of the valid
> destination addresses) does not work because of SA state issues (at
> least the replay counter has to be synchronized across all these
> SAs) and the obvious memory waste.

My apologies for being pedeantic, but you don't mean that in order to
access the SAD, you have to know the complete set of the destination
addresses, right?  Rather, that given any one of a set of the
destination addresses, the SPI, and the security protocol, one can
look up an SA in the SAD.  Correct?


One other issue to add to your list.  I was talking to some SCTP
folks, and the one thing which they thought would likely be
successfully added to SCTP is a mechanism for adding an additional
endpoint address to an existing SCTP connection.  If this feature does
get added to SCTP (and I can see how it might be useful; for example,
to add your new IP address if you're about to be renumbered, so you
can have SCTP connections survive renumbering events) then we will
need some way by which we can modify the SPD to take into account the
new endpoint address.  I don't think we'll need a particularly
complicated mechanism to handle this.  A simple solution would be to
just forcing a new Phase 2 exchange whenever the endpoint address set
changes; after all, I don't think this will likely be a frequent operation.

						- Ted


Follow-Ups: References: