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

Re: src addr/SPI coupling



On the outbound side we obviously need to keep track of both SPI and
destination address, because we did not allocate the SPI.

But it seems the only reason why we would need to keep track of an IP
address along with the SPI on the inbound side is Multicast (or lack of
SPI space). But even then why are we talking about "destination" address
on the inbound side: we are always the destination of an inbound secured
packet if we are the cryptographic endpoint, whether the packet is in
transport or tunnel mode.

So I think Michael was right when he first mentioned "Source" address.
The RFC seems incorrect to me here, I mean for the Inbound case.

RFC 2401, section 4.1:
"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"

Here destination means destination of the SA and this is absolutely
correct.

BUT, later on (section 4.4.1):
" For an inbound IPsec packet for which multiple IPsec SAs are to be
   applied, the lookup based on destination address, IPsec protocol, and

   SPI should identify a single SA."

Why destination address??? We actually need no address at all here, and
if we did it would be the Source one, not the Destination.
The only case I can think of (where destination address could be useful)
is a box with multiple IP interfaces, but this would be local
implementation matter.


Regards,

Emmanuel.

jshukla wrote:

> ----- Original Message -----
> From: "Michael Thomas" <mat@cisco.com>
>
>  >
>  > Now wait a minute. I thought the receiver chose
>  > the SPI.  If so, it owns that number space (modulo
>  > Cheryl's comment about multicast), so there
>  > shouldn't be collisions. If another sender tried
>  > to use that SPI, it would imply that they have
>  > keying material.
>  >
>  > Mike
>  >
>
> SPI collision does not happen at the receiver,
> but at the sender. The receiver can ensure
> that the SPI does not conflict with another
> SPI in its database, but it cannot ensure that
> the sender has not chosen the same SPI for
> "another" SA. (because multiple key material
> map to the same SPI).
>
> regards,
> Jayant
>  > jshukla writes:
>  >  >
>  >  > ----- Original Message -----
>  >  > From: "Michael Thomas" <mat@cisco.com>
>  >  > >    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
>  >  >
>  >  > To make sure that SA is unique!? SPI is only
>  >  > 32 bits long and there is a finite chance of
>  >  > collision.
>  >  >
>  >  >         SPI is chosen by the destination of
>  >  > SA who makes sure that it does not have two
>  >  > identical SPIs (it does not prevent the source
>  >  > from having the same SPI for another SA).
>  >  >         The source of SA uses the destination
>  >  > address along with SPI to make sure that
>  >  > SA is unique (in the event there is a collision and
>  >  > the source ends up having two SAs that share
>  >  > a common SPI).
>  >  >
>  >  > >    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
>  >  >
>  >  > It will surely run into trouble. BTW, this
>  >  > problem is similar to the NAT problem.
>  >  >
>  >  >
>  >  > regards,
>  >  > Jayant
>  >  >



Follow-Ups: References: