Re: SPD issues

[Mark Duffy <mduffy@quarrytech.com>]

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 
> one of them is really for forwarding.

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.


>Comments?
>
>Steve