Subject: Re: revised processing model, take II

From: Mark Duffy <[email-masked]>
Date: Tue, 04 Nov 2003 00:24:14 -0500

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

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?

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

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

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

---

From: Stephen Kent <[email-masked]>
Date: Tue, 4 Nov 2003 10:13:43 -0500

At 0:24 -0500 11/4/03, Mark Duffy wrote:
>>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.
>
>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.

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