revised IPsec processing model

[Stephen Kent <kent@bbn.com>]

Folks,

Here is the new, proposed processing model for IPsec.  Comments 
welcome, of course.

Steve

------

The current IPsec subscriber traffic processing model, as defined in 
2401, is imprecise in several respects, and it does not accommodate 
some significant deployment use that have arisen, e.g., PPVPNs. 
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.

We first look at outbound traffic, which is where most of the 
proposed changes are visible, then examine inbound traffic 
processing. The focus here is on subscriber traffic, with some 
discussion of IKE traffic.

Several concepts underlie the proposed model:

- virtual interface: every IPsec device has at least one virtual 
interface, which may correspond to one physical interface (the common 
case). Multiple virtual interfaces may map to a single physical 
interface, e.g., for overlay nets, or one virtual interface may map 
to multiple virtual interfaces. The choice of a one-to-one, 
many-to-one, or one-to-many mapping for virtual to physical 
interfaces is a local matter, which each implementer is free to 
select apropos to the environment on which IPsec is implemented. 
Every virtual interface has an ID (VID), a purely local identifier, 
which is used with the forwarding function defined below, to select 
the virtual interface to which outbound traffic is directed. The VID 
is NOT technically a selector, because it does not need to appear in 
an SPD; rather it is used to select an appropriate SPD.

- forwarding function: to provide a clear separation between 
forwarding (routing) and security decisions, an explicit forwarding 
function is added. This function can be trivial, in the case where 
there is only one interface (virtual or physical). It may be complex 
if there are multiple interfaces and if the implementation elects to 
offer a more sophisticated form of route selection. The spec makes no 
assumptions about the internal operation of the function, other than 
to say that the whole packet is passed to it and the output is a VID. 
In turn, the VID is used to select the appropriate SPD.

	- SPD: the SPD is largely the same as currently defined. 
Instead of being defined on a per interface basis, it is now per 
virtual interface, and is labeled with a VID, as specified above. The 
new SPD will differ in terms of the selectors allowed (consistent 
with IKEv2). Rather than referring to separate SPDs for inbound vs. 
outbound traffic (pre interface) we will talk in terms of entries in 
each SPD being directional, i.e., there are separate inbound and 
outbound entries for each SPD for each virtual interface. This makes 
sense because the inbound and outbound entries are really linked.

	- SPD caches: the current processing model refers to 
searching the SPD for each outbound packet to determine how to 
process it, and to check inbound traffic after IPsec processing, to 
ensure that traffic arriving on an SA is consistent with the 
selectors defined when the SA was created. This is a potentially time 
consuming search process, in both directions, because of the need to 
search the SPD entries in the order specified by the administrator or 
user who created them. The search process also is ambiguous as 
currently defined, with regard to processing inbound packets.  To 
simplify the process, and to allow for very fast SA lookups, we 
introduce the notion of an outbound SPD cache (on a per virtual 
interface basis), and the caching of inbound SPD entries in two 
places. 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. For outbound traffic, 
each cached entry maps to an SA, or indicates that matching traffic 
should be bypassed or discarded. For inbound traffic, the SPD cache 
serves as the reference for the selectors to be matched against 
arriving packets, or defines traffic to be bypassed or discarded. An 
algorithm for decorrelation was published as an ID some time ago, and 
I think there is at least one paper on the topic published as well. 
2401bis will not mandate a specific algorithm, but will include an 
example in an appendix.

With these concepts in mind, we can describe the revised model. First 
we examine outbound traffic processing.  (There is no separate 
discussion of fragment processing for now, as we await the WG 
decisions of several pending proposals re fragmentation.)

1. when a packet arrives from a subscriber interface, invoke the 
forwarding lookup function.

2. match the packet headers against the SPD cache specified by the 
VID 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, search the SPD that corresponds to this cache. If 
the SPD calls for bypass or discard, create a new outbound and 
inbound cache entries. If the SPD entry calls for creation of an SA 
(pair), 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, 
and an error is logged, and may be signaled. (A packet that triggers 
an SPD lookup MAY be discarded by the implementation, or it may be 
buffered and then processed against the newly created cache entry, if 
one is created.) The SAD entry contains the inbound selector values 
linked to the SPD entry used to create the inbound SA, to support 
checking of received traffic.

4. The VID assigned to the packet in step 1 (the forwarding lookup) 
is used to select the interface to which the packet is directed, 
after the specified processing (if any) is applied in step 3.

Inbound processing is somewhat different from outbound processing, 
largely because we use of SPIs to map IPsec traffic to SAs, vs. 
performing a lookup based on traffic selector values. However, we 
still have to perform traffic selector lookups for non-IPsec inbound 
traffic, to determine whether this traffic is to be discarded or 
bypassed. Thus an inbound IPsec cache is used to quickly process this 
traffic. The description below does not include reassembly 
processing, while we await a WG decision on the possibility of 
rejecting fragments for SAs from specified sources.

1. When a packet arrives, it is tagged with a VID. This ID may be 
directly mapped from a physical interface, or a lookup function may 
be invoked to assign a VID, analogous to what is offered for outbound 
traffic in step 1 above. Note that there is no need to tag a packet 
with a VID if it is an IPsec packet directed to the IPsec 
implementation. This is because there is only one SAD which applies 
to all traffic, regardless of the interface. However, because SPDs 
are per-interface, entries for bypass or discard traffic might be 
specific to the interface via which the inbound traffic is received. 
If there is no need to treat inbound traffic differently depending on 
the interface upon which it arrived, the VID may be a constant.

2. examine the header to determine if it is addressed to the IPsec 
implementations, and if so, if it appears to be for a key management 
protocol. If so, direct the packet to key management processing.

3a. If the packet is addressed to the IPsec implementation and AH or 
ESP is specified as the protocol, lookup the packet using the SPI in 
the SAD. Remember that each SAD entry now includes 2-bits to specify 
which fields are used to determine a match (unicast vs. multicast). 
If there is no match, discard the traffic, logging the error as 
specified by local management controls. If there is a match in the 
SAD, apply AH or ESP as specified, using the SAD entry selected 
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. If there is a mismatch, log the error and 
signal it if a signaling mechamism is available and enabled.

3b. If the packet is not addressed to the implementation, or if the 
traffic is not AH or ESP, lookup the packet header in the inbound 
(discard/bypass) SPD cache for this (virtual) interface. If there is 
a match and the packet is to be discarded or bypassed, do so. If 
there is no match, lookup the packet in the inbound SPD (for the 
interface in question) and create an appropriate inbound and an 
outbound cache entry. (No SAs are created in response to receipt of a 
packet that requires IPsec; only bypass or discard entries can be 
created this way.)

This processing model is simpler and less vague than the old model, 
and it offers the potential for higher speed processing of traffic. 
It does, however, remove some functionality.  For example, there is 
no provision for SA bundles. It would be easy to include support for 
the simple AH+ESP combination that IKEv1 was able to negotiate, and 
that 2401 mandates, if that combination is still viewed as needed. 
However, IKEv1 was not able to negotiate any other nested protocol 
combinations and I don't think IKEv2 has addressed this problem 
either, especially the notion of adding new SAs to create an SA 
"bundle." So, I suggest we remove the requirement to support SA 
bundles, unless the WG feels strongly otherwise.

There is also no provision within this processing model to support 
nested SAs, i.e., all IPsec processing is performed in one pass. 
However, after the packet is emitted, it could be redirected through 
the IPsec module via local, virtual interfaces and use of the 
forwarding lookup function, to cause more than one layer of IPsec 
headers to be applied or removed. Note that to accomplish this, 
multiple entries would have to be created, in distinct SPDs, each 
specifying a layer of IPsec processing to be applied. However, IKE 
still lacks a means to negotiate this, so I suspect that only manual 
configuration, or some key management mechanism not yet defined for 
IPsec, would be needed to take advantage of this approach.