[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: SA identification
"Steven M. Bellovin" wrote:
>
> In message <p05010401b6dfaec6aa35@[128.33.238.44]>, Stephen Kent writes:
> >During Teusday's HIP BOF , JI raised a question that I had begun to
> >contemplate while working on revising 2401: why do we need three
> >values to identify an SA for incoming IPsec traffic? We currently
> >require matching on protocol (AH vs. ESP), SPI, and destination
> >address. It's clear that the protocol input can be made redundant by
> >assigning SPIs without protocol specificity. Some mobility problems
> >could be addressed if we ignored destination address. So, I have two
> >questions for the list:
> >
> > - do we have any examples of plausible scenarios where we
> >need the destination address as a discriminator for inbound traffic
> >(inn addition to the SPI)?
> >
> > - how strongly would vendors feel about changing the spec to
> >remove the requirement to match on all 3 values noted above?
> >
> >Note that SA identification is a local matter for an IPsec receiver,
> >and thus it should be possible for a receiver to use just the SPI
> >just through appropriate management of that space. So the question is
> >really whether anyone manages SPIs in a fashion that relies on using
> >the other two values for differentiation.
>
> The usual answer is that multicast needs it. Now that we have a
> multicast security group, this may be more important.
Just so the issue is clear to everyone: while the receiver chooses all
its SPIs in the unicast case, in the multicast case there are multiple
systems choosing SPIs it has to recognize and the SPIs could indeed
collide. Even if the multicast SPIs are all centrally managed by a key
server there's a potential namespace collision with unicast SPIs.
> I agree, though, that the 3-tuple requirement is annoying. And I
> suspect that people would not like the answer "use a 3-tuple for
> multicast, but a pair for unicast".
Rather than make it multicast/unicast specific, a new SA attribute could
be used to denote whether or not a 3-tuple should be used for
evaluation. This would give multicast apps (or any unicast apps which
wanted extra assurance) the chance to protect themselves. But I'm not
sure this is any more palatable as it affects the key management system
(passing the SA attribute) and adds more state to the IPSec processing.
The only reason that I bother to bring it up is that I think there's a
lot of value in some unicast cases to disregarding the destaddr, and it
would be useful to be able to accommodate that.
Brian Weis
bew@cisco.com
> --Steve Bellovin, http://www.research.att.com/~smb
References: