[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: revised IPsec processing model
Hi Scott,
What you describe below is by my understanding the model not only of
Steve's 2401bis proposal but also the (arguably more limiting) model of rfc
2401. And yes, I think it does not permit the processing required for my
example.
In the 2401 model, the SPD associated with an interface controls IPsec on
that interface as follows: It specifies whether outgoing packets SENT out
that interface should be dropped, bypassed, or have IPsec applied, and
whether incoming packets RECEIVED on that interface should be dropped,
bypassed, or must have arrived with IPsec protection.
My example requires that this be turned inside-out in a sense. To make the
example work, the SPD associated with one of the LAN (aka subscriber)
interfaces controls whether incoming packets RECEIVED on that interface
should be dropped, bypassed, or have IPsec applied, and whether outgoing
packets SENT out that interface should be dropped, bypassed, or must have
arrived into the device with IPsec protection.
Again, this was only an example device. The larger point was to
demonstrate the generalizing the model to make SPD selection *independent*
of forwarding decision (i.e. independent of exit interface) enables
applications of IPsec that are not otherwise possible. Another example
that was made earlier in this thread was the case where an SPD should apply
to a set of interfaces.
Since you have supplied such a nice picture, I'll attempt to edit it to
represent what I am advocating:
+----------------------------+ +---------------------+
| SPD selection +-------+ | | packet forwarding |
| module | SPD a | | | (routing) module |
| +-------+ | | |
| |-->----------> |
| / +-------+ | | \ |
| -->-----> | SPD b | | | \ |
| / +-------+ | | \ |
+-----/----------------------+ +------------\--------+
/ \
incoming / \ outgoing
packet / | packet
+----------------+ +----------------+ +-----V----------+
| Interface 0 | | Interface 1 | | Interface n |
+----------------+ +----------------+ +----------------+
^
_______/
incoming
packet
--Thanks, Mark
At 03:35 PM 7/31/2003 -0700, Scott G. Kelly wrote:
[snip]
>Mark Duffy wrote:
>| 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_.
>
>Steve can correct me if I've misinterpreted the model, but what you are
>saying here doesn't square with my understanding of the model. Here is
>how I understand it (and have implemented it in a previous life):
>
>~ +-----------------+
>~ | packet from an |
>~ | application |
>~ +-------+---------+
>~ | outgoing
>~ V packet
>~ +----------------------------------------------+
>~ | packet forwarding (routing) module |
>~ |
>~ | +-->----->------+
>~ +-/-----------------\---------------------------+
>~ incoming / \ outgoing
>~ packet / | packet
>~ +----------------+ +----V-----------+ +----------------+
>~ | Interface 0 | | Interface 1 | | Interface n |
>~ | +-------+ | | +-------+ | | +-------+ |
>~ | | SPD 0 | | | | SPD 1 | | ... | | SPD n | |
>~ | +-------+ | | +-------+ | | +-------+ |
>~ +----------------+ +----------------+ +----------------+
>~ ^
>_______/
>incoming
>packet1
>
>
>Note that these interfaces may be physical *or* logical. In this model,
>packets coming in from the network are first evaluated according to the
>policies of the ingress interface. Assuming the packet is allowed to
>continue (i.e. it is not discarded), the next step is to perform a
>forwarding lookup. If the packet is locally destined, it will be passed
>up to the appropriate internal consumer. If not, the egress interface
>must be determined according to the forwarding lookup (which will be
>longest prefix match), and then the policy of the egress interface will
>be examined to determine what to do next. In the case of internally
>generated (outbound) packets, the local application hands them to the
>stack, which first does a forwarding lookup to determine the egress
>interface, and then the policies of that interface are applied.
>
>Why doesn't this model permit the processing you want?
>
>Scott