Re: revised IPsec processing model

[Mark Duffy <mduffy@quarrytech.com>]

Hi Steve, and thank you.  I think this is a good direction to go in, though 
I think it should be taken a little further.  Comments embedded below.

Thanks, Mark

At 02:48 PM 7/17/2003 -0400, Stephen Kent wrote:
>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.

Regarding the virtual interface and the forwarding function:

A close reading shows that the "forwarding function" may be an arbitrary 
function of the packet (and hopefully of meta-information about the packet, 
such as where it was received from).  However, the term itself is fairly 
loaded and will suggest destination-address-based IP forwarding to many 
readers.  Moreover, 2401bis should IMO permit a separation between where a 
packet is forwarded to, and what SPD is applied to it.  This for example to 
support a device that has one uplink to the Internet and provides 
protection for different LANs using different SPDs: in this case the SPD to 
use for outbound processing might be implied by the interface the packet 
came in on rather than by the interface it goes out on.

So I would propose that instead of a "forwarding function" we have a "SPD 
selection function" that is done on a per-packet basis.  Like the 
forwarding function described above this function is a local matter for the 
IPsec implementation.  It might be a mapping from interface to SPD (RFC2401 
model), or any other function of the packet fields and packet 
meta-information.  With this change the concept of virtual interface could 
be dropped entirely (my preference, since the SPDs would not necessarily 
correspond to the logical IP network interfaces that the term suggests to 
me) or the virtual interface could be considered as a highly abstract thing 
that is one-to-one with an SPD but has no particular relationship to where 
the packet is forwarded, making the VID into an "SPD identifier".


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

Yes, that's great.  In fact, aren't the inbound and outbound entries 
actually constrained to be symmetrical reflections of one another, at least 
if IKE is to be used?


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

The discussion of decorrelating the SPD, and maintaining a cache, seems a 
lot like implementation design.  I would introduce these in 2401bis only if 
it significantly simplifies the description of the required behavior (which 
it's not clear to me that it does here).


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

Per my comment above, I would propose changing this to:

1. when a packet arrives at the IPsec implementation and it is determined 
that the packet is to be protected as an outbound packet, invoke the SPD 
selection 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

and inbound?

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

I have 2 comments on that.
Per my first comment above, I believe the IP forwarding decision should be 
independent of the SPD selection decision.
Also, for packets that have IPsec applied, in tunnel mode, the IP 
destination address of the new packet may now be different.  It is my 
belief that an IPsec implementation that is also a router should at this 
point perform a new IP forwarding decision, based on the new address.


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

Just as for outbound processing, I urge that the model here should have a 
SPD selection function that is a local matter and may or may not be based 
on arriving and/or departing interface.

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

You won't hear any complaints from me.


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

I don't see why IKE as-is could not negotiate this, so long as it allows 
negotiating an SA to protect payload packets that are ESP or AH 
protocol.  It then becomes a local issue of what SPD(s) a packet is 
subjected to as it flows through the IPsec device, and any/all SAs needed 
would be independently negotiated.