[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: revised IPsec processing model
Mark,
responses inline to your comments:
<SNIP>
>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.
The intent is that the forwarding function can use any data from the
packet. I'm open to suggestions for other names for the function, but
I think Joe Touch suggested this one, and he definitely intended it
to cover the broader set of possible inputs.
The question of one SPD, or an SPD per (virtual) interface is a
separate matter. Before introducing virtual interfaces in the
processing model, we had one SPD per physical interface. So, I just
maintained this part of the model going forward, and doing what seems
to be the obvious, logical extension. So, from a "preserve the status
quo unless the WG expresses consensus otherwise ..." perspective, I
will plan to retain the per-virtual interface SPD model for now.
>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.
>> - 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?
The entries need not be symmetric in all cases, because SPD entries
cover ALL traffic: IPsec, bypass, and discard.
>> <SNIP>
>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).
How one performs decorrelation is an implementation detail, but I
found that I needed to call out a cache explicitly to clarify how
processing was done. And, we cannot cache entries unless we
decorrelate them. That's why the description is stated in its current
form.
>>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.
I am not comfortable with this, for several reasons. First, we
disagree about the use of a function to select an SPD, vs. selecting
an interface with an SPD. Second, I found it too difficult to
explain how to do the processing without introducing caches,
especially for outbound traffic.
>> <SNIP>
>>
>>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?
There is no inbound SPD cache for IPsec traffic. The SPD data in put
in the SAD entry and inbound IPsec traffic is looked up in the SAD.
>>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.
No to the first comment. yes to the second, which is why I amended
the model, in response to other comments, to include a second lookup.
>>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.
See my responses to this issue 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.
The VID may be a constant, and that trivial implementation of the
lookup function is fine for an implementation that does not support
multiple virtual interfaces. There is no intent to mandate such
support; rather the notion is that IF the device natively supports
multiple virtual interfaces, THEN this is how IPsec will accommodate
them.
>>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 ...
Steve