Re: revised processing model, take II

[Stephen Kent <kent@bbn.com>]

At 0:24 -0500 11/4/03, Mark Duffy wrote:
>Hi Steve, I have a couple of questions on the processing model description.
>Sorry to be so long in getting these questions out.  --Thanks, Mark
>
>
>At 12:02 PM 10/17/2003 -0400, Stephen Kent wrote:
>>Revised IPsec subscriber traffic processing model (take II)
>
>...
>>However, we split each SPD into three pieces: one is applied to all 
>>traffic that is to be subject to IPsec protection (SPD-S), one 
>>applied to all outbound traffic that is to be bypassed or discarded 
>>(SPD-O), and one applied to inbound traffic that will be bypassed 
>>or discarded (SPD-I). If an IPsec implementation supports only one 
>>SPD, then the SPD consists of all three parts. If multiple SPDs are 
>>supported, some of them may be partial, e.g., some SPDs may contain 
>>only SPD-I entries, to control inbound bypassed traffic on a 
>>per-interface basis.
>
>It's not clear to me why this split of the SPD into 3 parts is 
>introduced.  SPD-S seems to be consulted anyway whenever SPD-O is 
>consulted.  Perhaps the split is to allow SPD-I to be consulted 
>without having to consult SPD-S?

yes, that was the primary reason I chose to describe the SPD as being 
composed of three parts.

>I'm not sure this is worth the complexity added.  The fact that 
>SPD-S contains rules for both inbound and outbound traffic, but 
>SPD-I and SPD-O each contain rules for only one direction only adds 
>to the difficulty of understanding this, I think.  Also, do these 3 
>SPD pieces consist of ordered sets of rules, or are they presumed to 
>be decorrelated at this point?  If not decorrelated it would seem to 
>be difficult to separate them, as they might be inter-ordered.

yes, the assumption is that they have been decorrelated. also, the 
split is primarily for purposes of exposition.

>Re the last sentence above, why might SPDs be partial in a multi-SPD 
>system, while they wouldn't be in a single-SPD system?  I.e. why 
>would some interfaces have only SPD-I and not SPD-S or SPD-O?

if one had an SG with two red interfaces and one black, one might 
choose to have red-interface SPDs that would not have any SPD-S 
entries, because no traffic traversing these interfaces would require 
IPsec, but one might want to constrain the addresses asserted by 
systems behind each of the red interfaces.

>
>...
>>The search process also is ambiguous as currently defined.  To 
>>simplify the process, and to allow for very fast SA lookups (for 
>>SG/BITS/BITW), we introduce the notion of an SPD cache for all 
>>outbound traffic. There is nominally one cache per SPD. Since SPD 
>>entries may overlap, one cannot safely cache these entries in 
>>general. Simple caching might result in a match against a cache 
>>entry whereas a search of the SPD would have resulted in a match 
>>against a different entry. But, if we decorrelate the SPD,
>
>Does the model assume that there is an ordered SPD (like in 2401), 
>and then a decorrelated version generated from it?  Or is the SPD, 
>wherever mentioned in the new model, assumed to be decorrelated?  If 
>so, the decorrelation should be mentioned earlier in the description.

yes, we assume that we start with a correlated SPD, because that is 
how folks are accustomed to managing these sorts of firewall filter 
rules. Then the decorrelation algorithm is applied, to allow us to 
cache SPD entries. The decorrelation is invisible at the management 
interface.

>
>>then the resulting entries can safely be cached, and each cached 
>>entry will map to an SA, or indicate that matching traffic should 
>>be bypassed or discarded, appropriately.
>
>...
>>Inbound Traffic Processing (black-to-red)
>>
>>Inbound processing is somewhat different, because of the use of 
>>SPIs to map IPsec traffic to SAs. The inbound SPD cache is applied 
>>only to bypassed or discarded traffic, and the inbound SPP lookup 
>>is applied only to the SPD-I part of an SPD.
>
>That doesn't seem quite right.  Shouldn't the inbound SPD cache be 
>applied to all traffic received without IPsec protection, and using 
>both the SPD-S and SPD-I?  Otherwise it will not catch packets that 
>should have been protected but weren't.  Either that, or (better 
>yet) it should state that any packet not matching any decorrelated 
>entry in SPD-I must be discarded.

Sorry I was not clear here. The intent for any SPD cache is that a 
packet that fails to match any entry is then referred to the 
corresponding SPD. Every SPD should have a nominal, final entry that 
catches anything that is otherwise unmatched, and discards it. This 
would ensure that non-IPsec protected traffic that arrives and does 
not match any SPD-I entry will be discarded, which, as you noted, is 
the desired behavior.

>
>...
>>2b. If the packet is not addressed to the device, lookup the packet 
>>header in the (appropriate) SPD-I cache. If there is a match and 
>>the packet is to be discarded or bypassed, do so. If there is no 
>>cache match, lookup the packet in the corresponding SPD-I and 
>>create a cache entry as appropriate. (No SAs are created in 
>>response to receipt of a packet that requires IPsec; only bypass or 
>>discard entries can be created this way.)
>
>same as above, should state that a packet not matching an SPD-I rule 
>must be discarded.

right.


Also, Charlie Lynn pointed out to me that we need not do a 3-way 
demux for inbound non-IPsec traffic. The IKE traffic can just be 
bypassed via an appropriate SPD-I entry, and then forwarded to the 
IKE process, if we model that process as being on the red side of 
IPsec.  I think this is a good model, and consistent with how many 
folks would implement the IKE function anyway, so I will make this 
further simplification when we move the text into 2401bis, and I will 
include a note that this is how we envision one would handle inbound 
IKE traffic.

Steve