Subject: question on ESPbis, Sec. 2.1

From: Mark Baugher <[email-masked]>
Date: Thu, 23 Jan 2003 09:30:44 -0800

Steve
   http://www.ietf.org/internet-drafts/draft-ietf-ipsec-esp-v3-03.txt uses 
the protocol id (ESP or AH) as part of the SA lookup as an option.  I don't 
understand why it is needed in either the unicast or the multicast cases.

Mark

---

From: Henry Spencer <[email-masked]>
Date: Thu, 23 Jan 2003 13:26:29 -0500 (EST)

> understand why it is needed in either the unicast or the multicast cases.

The idea is that there is at least the option of giving ESP and AH
separate SPI number spaces.  This was the case in the past, and there have
been IPsec implementations which exploited it:  when asked to make a
connection using both ESP and AH, they would use the same SPI for both.

                                                          Henry Spencer
                                                       [email-masked]

---

From: Mark Baugher <[email-masked]>
Date: Thu, 23 Jan 2003 12:52:18 -0800

>connection using both ESP and AH, they would use the same SPI for both.

Why wouldn't the receiver just allocate separate SPIs and skip the 
additional overhead of a maintaining and searching a protocol index?  Does 
this somehow aid the sender?

Mark

---

From: Henry Spencer <[email-masked]>
Date: Thu, 23 Jan 2003 16:01:48 -0500 (EST)

On Thu, 23 Jan 2003, Mark Baugher wrote:
> additional overhead of a maintaining and searching a protocol index?

In the one case I'm familiar with, it simplified keeping track of which
SAs were associated with which connection. 

> Does this somehow aid the sender?

No, it's strictly a receiver issue.  

Note that there is a backward-compatibility issue:  the mere fact that it
was allowed in the past means that outlawing it now is problematic.

                                                          Henry Spencer
                                                       [email-masked]

---

From: Henry Spencer <[email-masked]>
Date: Thu, 23 Jan 2003 16:26:14 -0500 (EST)

On Thu, 23 Jan 2003, Mark Baugher wrote:
> >No, it's strictly a receiver issue...
> 
> Pardon me if I'm being dense.  But if it's just a receiver issue and some 
> receiver wants to hand out the same SPI for an AH and an ESP connection, 
> then I don't see why it's a problem to remove it from the spec.

The point is that the sender must tolerate it -- he must not make assumptions
about the SPIs assigned by the receiver being unique.

                                                          Henry Spencer
                                                       [email-masked]

---

From: Mark Baugher <[email-masked]>
Date: Thu, 23 Jan 2003 13:19:26 -0800

Mark

---

From: Mark Baugher <[email-masked]>
Date: Thu, 23 Jan 2003 19:15:57 -0800

>about the SPIs assigned by the receiver being unique.

I would think that a sentence in the I-D such that "the sender should not 
make assumptions about how the receiver assigns SPIs, which may not be 
unique across different IPsec protocols" would suffice.  This is a lot 
cheaper than adding an index to a database table, which is an option in 
ESPbis.  It would save us two optional features in the ESPbis specification.

Mark

---

From: Henry Spencer <[email-masked]>
Date: Fri, 24 Jan 2003 11:33:36 -0500 (EST)

On Thu, 23 Jan 2003, Mark Baugher wrote:
> ESPbis.

How so?  It seems to me that these are two different ways of saying
exactly the same thing -- the receiver is permitted to have separate SPI
number spaces for the different protocols, so the sender must not assume
distinct SPIs.  One wording may be better than the other at explaining it,
but I fail to see any technical difference. 

                                                          Henry Spencer
                                                       [email-masked]

---

From: Stephen Kent <[email-masked]>
Date: Fri, 24 Jan 2003 12:58:49 -0500

At 9:30 AM -0800 1/23/03, Mark Baugher wrote:
>Steve
>   http://www.ietf.org/internet-drafts/draft-ietf-ipsec-esp-v3-03.txt 
>uses the protocol id (ESP or AH) as part of the SA lookup as an 
>option.  I don't understand why it is needed in either the unicast 
>or the multicast cases.
>
>Mark

Mark,

Your are right, it is not necessary in either case. But, for 
backwards compatibility, and because it is a local matter for the 
receiver, we don't preclude a receiver from using the protocol type 
if it wishes.

Under what circumstances do you envision that a sender might be 
confused by the possibility that two SAs to the same destination 
might have the same SPI and be differentiated only by including the 
protocol field in the lookup? A sender does not uses these values in 
its lookup of an SAD entry, so I didn't see how this would cause a 
problem.

Steve