Re: revised IPsec processing model

[Mark Duffy <mduffy@quarrytech.com>]

Thanks Steve.
I have a further comment on just two items, below.

--Mark

>>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".
>
>I don't understand the reasoning here.  We have been told that it is 
>inappropriate (unduly restrictive?) to have the SPD embody forwarding 
>info, hence the introduction of the forwarding function and the embodying 
>of its output in a VID value that can be used both for SPD selection and 
>to carry forward with the packet to control where it goes after IPsec 
>processing.

It is the "used both for..." part of that that I am resisting.

My opinion is that the proposed forwarding function and virtual interface 
concepts are helpful, but do not go far enough in generalizing the IPsec 
model.  What I would hope to see 2401bis embrace is a model where packets 
enter an IPsec device, some device-specific logic selects an SPD to apply, 
and then the IPsec and bypassed packets are forwarded out an interface 
chosen by some separate device-specific logic, for example IP longest 
matching prefix forwarding.

Let me give an example of a hypothetical yet reasonable device that is not 
readily accomodated by the 2401bis model as proposed.  Suppose we have a 
security gateway sort of device that has 3 LAN interfaces that it is 
protecting i.e. "protected networks" and 2 WAN interfaces to the Internet 
i.e. "uplinks."  Plaintext packets are sent and received on the protected 
network interfaces, and a mix of plaintext and IPsec packets are sent and 
received on the uplinks.  Suppose that a separate SPD is to be used for 
each protected network interface.  Consider the case of packets arriving 
from the protected network interfaces.  The SPD to be applied needs to be 
selected based on the interface the packet srrived _from_, not the 
interface the packet (either bypassed, or encapsulated in IPsec) will be 
forwarded _to_.

One could explain that in terms of the proposed model by saying that the 
incoming packets are sent by a "forwarding function" (based on the 
protected interface they were received from) to one of 3 virtual 
interfaces, and that each of those virtual interfaces has an SPD 
associated.  Then, after packets are encapsulated or bypassed, there is 
another forwarding function that chooses the outgoing uplink.  IMO however 
such an explanation would be a contortion.



>>>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.
>
>IKE, as-is, negotiates one pair of SAs at a time, and has not means to 
>communicate the intent of one side to bind together different SAs 
>negotiated independently, as best I know.  So, rather than saying that 
>there might be some magic way to express this through SPD entries, I was 
>suggesting that we cleanly abandon it if IKE cannot negotiate it. 
>Otherwise we have so many ways to have things not work despite successful 
>IKE-level negotiation ...

My point was that depending on the specific functions of IPsec devices, and 
depending on their configuration, the nesting of SAs might "just happen" 
and that even though IKE would not be used to bind the SAs together, the 
whole thing would "just work".  I don't see any reason for 2401bis to 
explicitly disallow this, as this would not be requiring any specific 
support from 2401bis or from IKE.

For example, packets might be forwarded via a virtual interface with an 
associated SPD.  That SPD causes certain packets to be encapsulated in 
tunnel mode IPsec packets of SA sa-1 addressed to IPsec peer p-1.  Those 
IPsec packets (as well as other packets) are subjected to another 
forwarding decision to select the correct outgoing physical link towards 
their destination, such as p-1.  Suppose that that outgoing interface also 
has an associated SPD that causes AH and ESP (and other) packets to be 
encapsulated in IPsec SA sa-2.  So, some packets might be sent out 
encapsulated in sa-1. some in sa-2, some in sa-1 nested withing sa-2, and 
some sent unencapsulated.  But sa-1 and sa-2 have no particular 
relationship to one another.

--Mark