Re: revised IPsec processing model: Q: VID and forwarding function

[Ricky Charlet <rcharlet@speakeasy.net>]

Hello,

	I'm trying to understand the motivations for VIDs and explicit 
forwarding function separation. Currently, I am guessing (based on your 
first paragraph) that these new features enable PPVPNs and/or overlay 
networks. If so, how so? If not, what new functionality is enabled by 
these features?

	This one is an editorial quesiton: I wonder about a particular phrase 
in the paragraph which begins "- virtual interface:" There is a clause 
which says "or one virtual interface may map to multiple virtual 
interfaces.". I suppose from the intended parallelism of the sentence 
that it perhaps should have read "or one virtual interface may map to 
multiple physical interfaces."


	Also, the last paragraph implies a loop behavior for IPsec processing:
   1. consult forwarding function to get VID
   2. do IPsec processing as per VIDs SPD
   3. go to 1.

	The exit condition for this loop is not specified. Let's consider 
outbound processing for an example. If the forwarding function is aware 
of only routing information (i.e. it is separated from security policy 
decisions) then it seems to me that this loop will get stuck:
   1. forwarding function says exit VID is X
   2. spd says this packet is allowed to pass
   3. go to 1.

	Certainly as implementors, we could all thing of our own little ways 
to break this loop. But shouldn't we have uniform guidance?



---
Ricky Charlet
rcharlet@alumni.calpoly.edu
510.324.3163


On Thursday, July 17, 2003, at 11:48 AM, 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.
>
> 	- 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.
>