Subject: [Ipsec] Why Destionation address while SPI is present.

From: "mahdavi" <[email-masked]>
Date: Sat, 27 Nov 2004 14:26:01 +0330

Hi. 

I have confused with this sentence in RFC2401 

"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."

Since SPI is generated by the receiver, Receiver can generate a unique SPI for
himself. In Inbound receiver can just search on SPI and does not need to
seaech on IP Destination Address and security protocol too. 

So Y we should search on these two fields too ? ? 

PS: we are designing IPSec in heart of a high speed router. 

thanks in advance. 

--

_______________________________________________
Ipsec mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipsec

---

From: Stephen Kent <[email-masked]>
Date: Mon, 29 Nov 2004 10:42:09 -0500

>PS: we are designing IPSec in heart of a high speed router.

Yes, the use of an address is redundant for IPsec unicast traffic, 
and unless the receiver chooses to reuse the SPI space for AH and 
ESP, it there is no need to examine the protocol field either. In 
2401bis we have reworded this section.

Steve

---

From: Joe Touch <[email-masked]>
Date: Mon, 29 Nov 2004 17:10:20 -0800

One issue for unique SPIs is coordination of different BITW instances on
a single machine. Presumably they have different IP addresses, but
omitting that address from the lookup means the different BITWs would be
_required_ to coordinate SPIs issued.

I.e., does omitting the address put additional constraints on BITWs?

Joe

Stephen Kent wrote:
| At 2:26 PM +0330 11/27/04, mahdavi wrote:
|
|> Hi.
|>
|> I have confused with this sentence in RFC2401
|>
|> "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."
|>
|>
|> Since SPI is generated by the receiver, Receiver can generate a unique
|> SPI for
|> himself. In Inbound receiver can just search on SPI and does not need to
|> seaech on IP Destination Address and security protocol too.
|>
|> So Y we should search on these two fields too ? ?
|>
|> PS: we are designing IPSec in heart of a high speed router.
|>
|> thanks in advance.
|>
|
| Yes, the use of an address is redundant for IPsec unicast traffic, and
| unless the receiver chooses to reuse the SPI space for AH and ESP, it
| there is no need to examine the protocol field either. In 2401bis we
| have reworded this section.
|
| Steve
|
| _______________________________________________
| Ipsec mailing list
| [email-masked]
| https://www1.ietf.org/mailman/listinfo/ipsec

---

From: "William Dixon" <[email-masked]>
Date: Tue, 30 Nov 2004 03:10:25 -0800

I've always thought that 2401 & 2401bis assumed there was one IPsec
implementation for a given IP address in theory. Maybe that's not strictly
required, but then neither is support for two or more in coexistence
specifically required. A number of conflicts could occur if more than one
IPsec implementation uses the same IP address, in addition to SPI selection.

They both will be blocking, permitting and negotiating SAs for potentially
the same traffic with different policies that are potentially independently
administered. It would be difficult to have multiple IKEs listening on port
500. But easy enough to configure IKE to use different ports with policy.
You'd have to be able to not drop a packet with a SPI that wasn't yours. And
be able to guarantee binding order for packet intercept during successive
boots.

Coexistence has been a practical market requirement for client host
platforms given the popularity of IPsec tunnel VPN clients.

I can imagine that there will be varying degrees of native support for
IPsec-based scenarios for IPv6, just as we saw for IPv4 remote access.

So my question is whether coexistence should be addressed by a WG document ?

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Joe Touch
> Sent: Monday, November 29, 2004 5:10 PM
> To: Stephen Kent
> Cc: [email-masked]
> Subject: Re: [Ipsec] Why Destionation address while SPI is present.
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> One issue for unique SPIs is coordination of different BITW 
> instances on a single machine. Presumably they have different 
> IP addresses, but omitting that address from the lookup means 
> the different BITWs would be _required_ to coordinate SPIs issued.
>

---

From: Stephen Kent <[email-masked]>
Date: Tue, 30 Nov 2004 09:33:56 -0500

>I.e., does omitting the address put additional constraints on BITWs?

Joe,

Each BITW device is an independent implementation of IPsec, so I 
would not expect them to be able to coordinate SPI generation, nor 
would I expect them to be able to share keys. if they don't share 
keys, then traffic arriving at the "wrong" one cannot be processed 
anyway. So, I would rely on each having a different address and thus 
not coordinating any of the other parameters needed to appear to be 
equivalent. of course, a vendor may choose to do something outside of 
the spec to offer this sort of extended functionality, but the key 
sharing issue might make it harder to achieve FIPS 140-2 approval.

Steve

---

From: Joe Touch <[email-masked]>
Date: Tue, 30 Nov 2004 07:35:41 -0800

Stephen Kent wrote:
> Each BITW device is an independent implementation of IPsec, so I would 
> not expect them to be able to coordinate SPI generation, nor would I 
> expect them to be able to share keys. if they don't share keys, then 
> traffic arriving at the "wrong" one cannot be processed anyway. So, I 
> would rely on each having a different address and thus not coordinating 
> any of the other parameters needed to appear to be equivalent. of 
> course, a vendor may choose to do something outside of the spec to offer 
> this sort of extended functionality, but the key sharing issue might 
> make it harder to achieve FIPS 140-2 approval.
> 
> Steve

Right - that's what I thought. However, that also means that it would be 
the address/SPI pair that would be important. I.e., there are two 
different kinds of failure:
	a) failed to lookup addr/SPI
	b) key found failed to work

*IF* IPsec considers those different errors, then the pair is required. 
If they're considered equivalent (logged the same, generate/don't 
generate the same internal error, etc.), then addr can be omitted.

Joe