Re: SPD issues

[Stephen Kent <kent@bbn.com>]

Mark,

>	<SNIP>
>
>
>>         - 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.)

I think we have to say something about options for how forwarding 
decisions can be made in the context of IPsec, especially in tunnel 
mode.

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

There is no need to select an SPD for inbound packets if they are 
IPsec-protected. We still envision just one SAD per IPsec 
implementation, and the revised processing model says that the 
relevant SPD info needed to check inbound packets after processing is 
bound to the SAD entries. That leaves the question of SPD info for 
inbound bypass/discard traffic.

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

yes, using just one SPD should be an option.

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

yes, I did mean to include meta data, e.g., local interface via which 
the outbound packet was received.

Steve (still catching up on 2 weeks of e-mail)