revised processing model, take II

[Stephen Kent <kent@bbn.com>]

Revised IPsec subscriber traffic processing model (take II)

The current IPsec subscriber traffic processing model, as defined in 
2401, is imprecise in several respects, and it does not accommodate 
some significant new IPsec scenarios that have arisen since 2401 was 
published , e.g., PPVPNs and overlay nets.  Also, just as we have 
created the extended sequence number facility for AH and ESP to 
accommodate high speed (10Gb/s and beyond) implementations, there are 
changes one can make to the processing model to better accommodate 
traffic classification for outbound traffic.  Finally, there are some 
simplifications one can make to the mode, consistent with the overall 
push for implementation simplification.

This model is intended to apply to all the types of IPsec 
implementations previously identified: security gateway (SG), native 
host, BITS, and BITW. In some instances the model emphasizes features 
that help SG and BITW/BITS implementations improve performance; 
native host implementations generally will neither benefit nor be 
adversely affected by such features.

Several concepts underlie the proposed model:

The revised model provides a clear separation between forwarding 
(routing) and security decisions, to accommodate a wide range of 
contexts where IPsec may be employed. Forwarding may be trivial, in 
the case where there are only one or two interfaces, or it may be 
complex, e.g., if there are multiple red or black interfaces or if 
the context in which IPsec is implemented employs a sophisticated a 
forwarding function. IPsec assumes only that outbound and inbound 
traffic that has passed through IPsec processing is forwarded in a 
fashion consistent with the context in which IPsec is implemented.

The SPD changes in several ways. SPDs are no longer required to be 
defined on a per interface basis. Thus an IPsec implementation MUST 
have at least one SPD, and it MAY support multiple SPDs, if 
appropriate for the context in which the IPsec implementation 
operates. An explicit SPD selection function is invoked to select the 
appropriate SPD for outbound traffic processing. The inputs to this 
function are the outbound packet and local metadata (e.g., the 
interface via which the packet arrived). The output of the function 
is an SPD ID.

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.

Entries in each SPD are still directional, but we have changed the 
terminology to reflect the fact that inbound and outbound SPD entries 
are not really independent, but rather are usually created as 
matching pairs. So, rather than speaking of separate inbound and 
outbound SPDs, we speak in terms of an SPD entry containing sets of 
values that define handling of inbound and outbound traffic.

The SPD entries are also more powerful than before, consistent with 
the new capabilities of IKEv2. Thus an SPD entry is defined as a list 
of one or more selector set pairs.  Each selector set pair consists 
of one selector set for outbound traffic and one selector set for 
inbound traffic. Each selector set consists of five types of 
selectors:
  	- a source IP address range
  	- a destination IP address range
  	- a next layer protocol value (or OPAQUE, or ANY)
  	- a source port range (or OPAQUE)
	- a destination port range (or OPAQUE)

Also, each entry specifies packet disposition as BYPASS, DISCARD or 
IPsec. If IPsec processing is specified for an entry, a "populate 
from packet" (PFP) flag may be associated with one or more of the 
selector types in the SPD entry. If present, the flag applies to all 
selectors of the indicated type in the outbound element of the pair. 
(PFP does not apply to inbound traffic.)

The old processing model refers to searching an SPD for each outbound 
packet to determine how to process it, and to check inbound traffic 
after IPsec processing against the SPD, to ensure that traffic 
arriving on an SA is consistent with the selectors defined when the 
SA was created. For SG, BITS, and BITW implementations, this is a 
potentially time consuming, linear search process, because of the 
need to search the SPD entries in the order specified by the 
administrator or user who created them. For native host 
implementations, there is already an implicit form of caching at 
work, in general. This is because it is common for a native host 
implementation to associate the SPD data that would be cached with a 
socket, thus avoiding the need to search the SPD for each packet sent 
or received via the socket interface.

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

For inbound IPsec traffic, the SAD entry selected by the SPI serves 
as the cache for the selectors to be matched against arriving 
packets. For inbound BYPASS or DISCARD traffic, a cache of the SPD-I 
also is maintained, to facilitate fast processing.

An algorithm for decorrelation was published as an ID some time ago, 
and there is at least one paper on the topic published as well. 
2401bis will not mandate a specific algorithm for decorrelation, but 
will include an example in an appendix.

With these concepts in mind, we can describe the revised model. First 
we examine the path for traffic entering the implementation via a red 
interface and exiting via a black interface.

Outbound traffic processing (red-to-black)

1. when a packet arrives from the subscriber (red) interface, invoke 
the SPD lookup function to select the appropriate SPD. (if the 
implementation uses only one SPD, this step is a no-op.)

2. match the packet headers against the cache for the SPD specified 
by the SPD-ID from step 1

3a. if there is a match, then process the packet as specified by the 
matching cache entry, i.e., bypass, discard, or apply AH or ESP in 
the specified mode. If IPsec processing is applied, there is a link 
from the SPD cache entry to the relevant SAD entry (specifying the 
algorithms, keys, SPI, etc.). IPsec processing is as previously 
defined, for tunnel or transport modes and for AH or ESP, as 
specified.

3b. if no match is found in the cache, search the SPD (SPD-S and 
SPD-O parts) specified by SPD-ID. If the SPD entry calls for bypass 
or discard, create new outbound and inbound SPD cache entries. If the 
SPD entry calls for creation of an SA, the key management mechanism 
(e.g., IKEv2) is invoked to create the SA. If SA creation succeeds, a 
new outbound cache entry is created, along with an SAD entry, 
otherwise the packet is discarded. (A packet that triggers an SPD 
lookup MAY be discarded by the implementation, or it may be processed 
against the newly created cache entry, if one is created.) The SAD 
entry contains the selector values derived from the SPD entry used to 
create this SA.

4. The packet is passed on to the outbound forwarding function 
(operating outside of the IPsec boundary), to select the interface to 
which the packet will be directed.

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. If an arriving packet appears to be 
a black IPsec fragment, reassembly is performed prior to the IPsec 
processing.

0. When a packet arrives, it may be tagged with the ID of the 
interface (physical or virtual) via which it arrived, if necessary to 
support multiple SPDs with different SPD-I entries.

1. the packet it is examined and demuxed into one of three categories:
	- If the packet appears to be IPsec protected and it is addressed to
	  this IPsec device, it is directed to SPI lookup.
	- ICMP traffic directed to this device is directed to black ICMP
	  processing.
	- traffic not addressed to this device is directed to BYPASS/DISCARD
	  lookup. If multiple SPDs are employed, the tag assigned to the packet
	  in step 0 is used to select the appropriate SPD-I (and cache) to
	  search.

2a. If the packet is addressed to the device and AH or ESP is 
specified as the protocol, lookup the packet in the SAD. For unicast 
traffic, use only the SPI. For multicast traffic, use the SPI plus 
the source and/or destination addresses, as specified in the SAD. If 
there is no match, discard the traffic. If the packet is found in the 
SAD, process it accordingly (see step 3).

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

2c. Black ICMP processing examines ICMP traffic and applies local 
policy to determine whether to accept of reject these messages and, 
if accepted, what action to take as a result. For example, if an ICMP 
unreachable message is received, the implementation must decide 
whether to act on it, reject it, or act on it with constraints. 
(This is a separate 2401bis discussion topic.)

3. Apply AH or ESP as specified, using the SAD entry selected in step 
2a above. Then match the packet against the inbound selectors in the 
SAD entry to verify that the received packet is appropriate for the 
SA via which it was received.

After traffic is bypassed or processed through IPsec, it is handed to 
the inbound forwarding function for disposition.

Epilogue

This processing model is simpler and less vague than the old model, 
and it offers the potential for higher speed processing of traffic, 
through the use of caches. Under this model, there is no explicit 
support for nested security associations or SA bundles. These 
features, which were specified in 2401, but which do not appear to be 
widely implemented, still can be effected by appropriate 
configuration of both the SPD and the local forwarding function, but 
this function is outside of the IPsec module and thus the scope of 
this spec. As a result, management of nested/bundled SAs is 
potentially more complex and less assured.