RE: SPD issues

["Mike Taylor" <mtaylor.eng@sbcglobal.net>]

> -----Original Message-----
> From: owner-ipsec@lists.tislabs.com
> [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Mark Duffy
> Sent: Tuesday, October 14, 2003 8:56 PM
> To: Stephen Kent
> Cc: ipsec@lists.tislabs.com
> Subject: Re: SPD issues
>
>
> At 07:03 PM 10/14/2003 -0400, Stephen Kent wrote:
> >Mark,
> >
> >>         <SNIP>
> >>
> >>
> >>>         - My previous proposal for a revised processing model, from a
> >>> few weeks ago, retained the idea of multiple SPDs, allocating them to
> >>> virtual interfaces, and introduced the notion of a forwarding
> function
> >>> to select the right virtual interface, and thus SPD.  But, unless we
> >>> feel a need to have different SPDs per interface, this seems like
> >>> overkill. I think we do want to allow forwarding of outbound
> traffic to
> >>> be independent of SPD selection, so some notion of an explicit
> >>> forwarding function in the model still seems appropriate. but, as we
> >>> discussed the model, there was a suggestion that we might
> need two such
> >>> functions, one to select an SPD, and then one to be applied
> after IPsec
> >>> processing. maybe, if we separate SPD selection from interface
> >>> selection we can have two functions but only one of them is
> really for
> >>> forwarding.
> >>
> >>I am all for separating the "SPD selection function" from the "IP
> >>forwarding function".  (Once that is done though, I don't see
> why the IP
> >>forwarding function is any concern of IPsec's.)
> >
> >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.
>
> 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.

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.

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.  Rather,
there should
be an appendix in 2401bis with suggested implementations such as the use of
virtual
interfaces, or what have you.  It should point out any known pitfalls
(security
issues) with various implementation choices.  But that's just my 2 cents
worth.

<soapbox>
It seems to me that the real issue here goes to the heart of the original
principals
of IP networking.  An IP network ideally ought to be a bunch of networks
connected
together by boxes whose sole function is to perform the forwarding function.
All
other processing really ought to be done by the hosts connected to those
networks,
just as the "forefathers" knew that reliable data exchange should be
accomplished
by the end-points using a transport level protocol (TCP) running over an
unreliable
best effort datagram delivery service, rather than by having per-link error
correction
as in X.25.  So (as the IPv6 folks have recognized) security must ultimately
also be
done end-to-end.  A security gateway is no more and no less an abomination
than a
NAT box and ideally should be viewed as a temporary solution until we have
full end-to-end
security.  But of course, it is very likely that this utopian vision won't
come to
pass in my lifetime.
</soapbox>

>
> And for packets that have a "drop" action selected, the document
> can remain
> silent.  After all, the world would be rendered uninteresting if all
> mystery were removed ;-)
>
> Mark
>