RE: SPD issues

[Mark Duffy <mduffy@quarrytech.com>]

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.

Makes sense?

--Mark