Subject: SPD issues

From: Stephen Kent <[email-masked]>
Date: Wed, 24 Sep 2003 18:50:37 -0400

Folks,

In revising the processing mode, based on feedback from various 
folks, I want to make sure that we have enough functionality, but not 
more than is really needed. In this regard, I want to conduct a quick 
poll.

The topic, in a way, is how many SPDs do we need?  2401 says we have 
an SPD per interface, but maybe that's not enough, or too many, or 
just not the right question to be asking.

So, let's ask the question differently.  What are the inputs needed 
to select the right SPD?
	- In a very simple context it seems we could get away with 
just one SPD, relative to which all traffic is examined.  so any 
answer we choose must yield this answer for the simple cases.

	- In a PPVPN context, having a different SPD per subscriber 
seems to make sense, since the intent it so allow each subscriber to 
define his/her own SPD.  In this case, the SPD could be selected 
based on the source of the (outbound) traffic. You could think of 
this as being per interface, relative to the interfaces via which the 
outbound traffic arrives, but it does not imply a need for different 
SPDs for the interfaces via which inbound traffic arrives, an 
asymmetry.

	- My previous proposal for a revised processing model, from a 
few weeks ago, retained the idea of multiple SPDs, allocating them to 
virtual interfaces, and introduced the notion of a forwarding 
function to select the right virtual interface, and thus SPD.  But, 
unless we feel a need to have different SPDs per interface, this 
seems like overkill. I think we do want to allow forwarding of 
outbound traffic to be independent of SPD selection, so some notion 
of an explicit forwarding function in the model still seems 
appropriate. but, as we discussed the model, there was a suggestion 
that we might need two such functions, one to select an SPD, and then 
one to be applied after IPsec processing. maybe, if we separate SPD 
selection from interface selection we can have two functions but only 
one of them is really for forwarding.

	- Along those lines, we could introduce an SPD selector 
function that, like the forwarding function, can use any info in a 
packet to select an SPD, but without associating the SPD with an 
interface per se.

Comments?

Steve

---

From: Mark Duffy <[email-masked]>
Date: Sun, 28 Sep 2003 23:36:54 -0400

Hi Steve, I added some comments in line.   --Mark

At 06:50 PM 9/24/2003 -0400, Stephen Kent wrote:
>Folks,
>
>In revising the processing mode, based on feedback from various folks, I 
>want to make sure that we have enough functionality, but not more than is 
>really needed. In this regard, I want to conduct a quick poll.
>
>The topic, in a way, is how many SPDs do we need?  2401 says we have an 
>SPD per interface, but maybe that's not enough, or too many, or just not 
>the right question to be asking.
>
>So, let's ask the question differently.  What are the inputs needed to 
>select the right SPD?
>         - In a very simple context it seems we could get away with just 
> one SPD, relative to which all traffic is examined.  so any answer we 
> choose must yield this answer for the simple cases.
>
>         - In a PPVPN context, having a different SPD per subscriber seems 
> to make sense, since the intent it so allow each subscriber to define 
> his/her own SPD.  In this case, the SPD could be selected based on the 
> source of the (outbound) traffic. You could think of this as being per 
> interface, relative to the interfaces via which the outbound traffic 
> arrives, but it does not imply a need for different SPDs for the 
> interfaces via which inbound traffic arrives, an asymmetry.

I don't see that there is necesarily any asymmetry there (but even if there 
was, would that matter?).  The outbound traffic from a subscriber and the 
inbound traffic towards a subscriber would each be processed against an SPD 
associated with the (same) subscriber interface.  That seems 
symmetrical.  And  in the most general case, *every* interface could be 
considered a "subscriber interface" with such SPDs associated with 
it.  That seems symmetrical too.

>         - My previous proposal for a revised processing model, from a few 
> weeks ago, retained the idea of multiple SPDs, allocating them to virtual 
> interfaces, and introduced the notion of a forwarding function to select 
> the right virtual interface, and thus SPD.  But, unless we feel a need to 
> have different SPDs per interface, this seems like overkill. I think we 
> do want to allow forwarding of outbound traffic to be independent of SPD 
> selection, so some notion of an explicit forwarding function in the model 
> still seems appropriate. but, as we discussed the model, there was a 
> suggestion that we might need two such functions, one to select an SPD, 
> and then one to be applied after IPsec processing. maybe, if we separate 
> SPD selection from interface selection we can have two functions but only 

I am all for separating the "SPD selection function" from the "IP 
forwarding function".  (Once that is done though, I don't see why the IP 
forwarding function is any concern of IPsec's.)

By using different SPD selection functions, different results can be 
obtained:

The RFC 2401 behavior can be obtained by an SPD selection function based on 
the output IP interface for outbound packets and the receiving IP interface 
for inbound packets (i.e. the black side interface).

The behavior described above for different SPDs per subscriber can be 
obtained by an SPD selection function based on the receiving IP interface 
for outbound packets and the output IP interface for inbound packets (i.e. 
the red side interface).

And the very simple case mentioned above can be handled by an SPD selection 
function that just returns the same SPD in all cases.

>         - Along those lines, we could introduce an SPD selector function 
> that, like the forwarding function, can use any info in a packet to 
> select an SPD, but without associating the SPD with an interface per se.

Yes, please!  But I would say that it should be able to use not only "any 
info in a packet" but also meta-information associated with a packet (e.g. 
the interface it arrived or will depart on) to select an SPD.  Perhaps 
that's what you intended anyway.