[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: SPD issues
Mark Duffy wrote:
> Hi Mike, see below...
>
> At 10:09 AM 10/20/2003 -0700, Mike Taylor wrote:
> [...]
>
>> > > [SK] I think we have to say something about options for how
>> forwarding
>> > >decisions can be made in the context of IPsec, especially in tunnel
>> mode.
>> >
>> > [MD] How about:
>> >
>> > For packets that "bypass" IPsec processing, and for packets that arrive
>> > with IPsec protection which is removed at the device, the IP output
>> > interface and next hop are selected by the normal IP forwarding
>> mechanism
>> > of the device [which would be beyond the scope of 2401bis] applied
>> to the
>> > plaintext packet.
>> >
>> > For packets that have IPsec applied to them by the device (tunnel or
>> > transport mode) the IP output interface and next hop are selected by
>> the
>> > normal IP forwarding mechanism of the device applied to the IPsec
>> packet.
>>
>> [MT] This wording is not sufficiently clear as their is quite a
>> difference
>> between
>> the routing applied *after* IPSec processing in tunnel mode, and the
>> routing
>> required to get a red datagram to IPSec, i.e., either to some virtual or
>> real
>> interface to which an SPD is attached that has a policy relevant to the
>> datagram.
>> In the latter, the route may very well not be "real" in the sense that it
>> may
>> exist solely for the purpose of getting the red datagram to IPSec, and in
>> fact the
>> destination IP address may be some private address (with IPSec in tunnel
>> mode)
>> that couldn't possibly be reached via the public Internet by a
>> conventional
>> (non-VPN) forwarding decision.
>
>
> My understanding of the proposed model is that the IPsec device has an
> "SPD selection function" that choses the SPD to use; how the choice is
> made is implementation dependent. This replaces (or rather, enlarges
> on) the SPD-per-interface model of 2401. I believe that that SPD
> selection function fills the role of the "routing required to get a red
> datagram to IPSec" in your message above.
>
>> In a purist sense the solution to these issues falls into the realm of
>> implementation
>> details that don't really need to be specified in 2401bis. I don't think
>> 2401bis
>> should require, for example, virtual interfaces as a solution.
>
> Nor do I. Which is why I personally find the idea of an "SPD selection
> function" attractive. Trying to disguise the SPD selection function as
> a "forwarding decision" just adds confusion.
>
> So, there is an SPD selection function that chooses an SPD. And there
> is an IP forwarding function that selects a next hop to forward a
> datagram to. And the two may be comepletely independent or completely
> entwined, depending on the nature of the device.
It's the entwined case that presents the largest problem. I.e., if the
SPD selection is based on forwarding information that then changes by
the time the subsequently tunneled (or not tunneled) packet is emitted
from IPsec.
This could happen whether dynamic or static routing is used; the issue
is flux in the forwarding table and whether it is _allowed_ to affect
SPD selection.
Calling the function "SPD selection" doesn't absolve the problem.
Joe