[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: src addr/SPI coupling
----- Original Message -----
From: "Emmanuel Hislen" <hislen@lucent.com>
> On the outbound side we obviously need to keep track of both SPI and
> destination address, because we did not allocate the SPI.
>
right
>
> 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.
>
Consider three entities A, B, and C. "A" initiates a multicast
session M1, selects SPI sp1. It is entirely possible that
"B" might select the same SPI sp1 for another multicast
sessions M2.
If you use SPI and source address, you can see the problem
easily. Whenever "B" sends a message, "C" sees an ambiguity
and cannot pick the right SA based on source address and
SPI alone. He has two SA's that now qualify, one corresponding
to the multicast session M1 and other corresponding to the
session M2. Only way for "C" to pick the correct SA is to
determine if the message corresponds to multicast session
M1 or M2. It does so by using the destination address.
I guess what you did not consider is that other nodes can
also send messages in a multicast session.
>
> Regards,
>
> Emmanuel.
>
regards,
Jayant
References: