RE: SPD issues

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

> -----Original Message-----
> From: Joe Touch [mailto:touch@ISI.EDU]
> Sent: Monday, October 20, 2003 2:01 PM
> To: Mark Duffy
> Cc: Mike Taylor; Stephen Kent; ipsec@lists.tislabs.com
> Subject: 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.

By the forwarding information changing do you really mean that the
forwarding
database changes?  Assuming so, then I hadn't thought much about that case
yet
but here's how I see it so far.  This description refers to a native IPSec
implementation which is what I'm working on.  I haven't though much about
BITS/BITW.  I am attempting to create a fairly basic, small footprint
implementation
(for small embedded systems) and am not looking at more advanced issues like
multiple
virtual routers in one box at this time.  That is one reason I don't want to
see
too many implementation details turning up as requirements in 2401bis.

	1.  If SPD selection for outbound datagrams is based on a single outbound
	    SPD rather than an SPD per interface then it doesn't much matter
	    if the forwarding info changes after the policy is selected.
	    In fact, the selection of the policy has little to do with the
	    IP forwarding function, other than that a route must exist for
          that chooses some interface on which to send the datagram (and
maybe
	    even that can be made irrelevant - see below).

	    Of course, in transport mode the route better point to the correct
interface,
	    but in tunnel mode it doesn't really much matter with a single outbound
SPD.
	    However, using a "normal" route this way in tunnel mode seems to me so
          far to be the ugliest aspect of the IPSec/forwarding interaction,
see below.

	2.  In transport mode at present my implementation intercepts red datagrams
	    after the forwarding function has chosen and outbound interface,
performs
	    IPSec processing, marks that as complete, then sends the datagram back
out on
	    the wire via the interface originally chosen by the IP forwarding
function
	    (possibly after fragmentation although naturally I am attempting to
avoid that).
	    If in reality the interface has changed in the few milliseconds since
the original
	    routing decision was made this isn't any more serious a problem, nor
any more solvable,
	    than if the forwarding database changes a microsecond after the
datagram
          has been sent out already.  One, or a few, datagrams would be
misrouted,
	    possibly dropped, and perhaps retransmitted (if TCP or other reliable
	    transport).

	3.  In tunnel mode after the policy is located all IPSec processing is
completed
	    included addition of the new tunnel outer IP header.  Then the datagram
is marked
	    as having been through IPSec and given to the IP forwarding function
	    to route (to the tunnel endpoint) as it sees fit.  It may well exit a
different
	    interface than the one pointed to by the routing of the inner header.
	    It will not be examined by IPSec again.

This seems to me to cleanly divorce IP forwarding issues from IPSec.
However, as
noted in #1 above, there is this whole pretty ugly issue of where should a
route for
red datagrams point?  After all, if we are tunneling between two private
networks
then in reality the inner red IP datagram probably (because of the use of
private address
space) couldn't really be delivered to the destination via the Internet.  So
the route
that has to be added just to get the red datagram to IPSec is completely
artificial in
that case.  Yuck.

I believe that is why many folks might like to see virtual interfaces play a
role in the
new IPSec processing model.  That way, the routes for red datagrams can
point to a
virtual interface rather than to some real physical interface out of which
the datagram
should never exit without 1st having been through IPSec processing, and in
fact, from
which the datagram may *never* exit if it is wrapped in an IPSec tunnel and
IP forwarding
ends up sending out some other interface.  So I'm considering now whether to
implement virtual
interfaces.  But I don't want it to be mandated in a specification.  It is
an implementation
issue and the more kludgey approach of just point the route for red
datagrams at whatever
interface (in tunnel mode that is, in transport it better point to the
correct one of course)
will work and is sufficient, if not very elegant.

In fact, another approach for a native IPSec implementation which I only
just thought of as
I was writing this email might be simply be to add code to the processing of
outbound IP datagrams
such that if the forwarding function reports that no route exists to the
destination then invoke
IPSec outbound processing to see if the datagram is covered by an IPSec
policy (presumably a
tunnel mode policy) and if so then let IPSec take it from there, rather than
dropping the datagram
because the destination is unreachable.  Hmmm.. I sort of like this idea and
will certainly
consider it further for my implementation.

I also believe that this issue of having an "artificial" route for tunnel
mode is why many folks
want to see the requirement that Security Gateways operate in tunnel mode
only (unless they're
acting as hosts) removed from 2401bis, or at least clarified.  Because, for
example, in the
FreeBSD world it looks to me like many administrators implement IPSec
tunnels by actually using a
"gif" interface, which is a virtual interface that performs IP-in-IP
tunneling on the datagrams
routed to it, and applying IPSec in *transport* mode to the datagrams that
exit the gif device.
At least, that's my take from researching the issue some.  This does seem
like a perfectly effective
way of creating a tunnel using IPSec in transport mode only.  In fact, its
even gotten me to
wondering whether IPSec tunnel mode should ever have been invented!  Perhaps
even IPSec tunnel
mode itself is an example of putting too much implementation detail in a
specification!
Because perhaps the very same problem can be solved more elegantly the way
many users
of FreeBSD seem to solving it. And if that is true, then the layering
principals of good protocol
design would seem to dictate that there is no real need to mandate "native"
IPSec tunnels in
the specifications.

I'm still in the fairly early stages of the implementation although I do
have running code.
Am I misunderstanding some of these issues?  I'm late to the whole 2401bis
discussion.
I wasn't even aware a 2401bis effort was underway until I had already
started coding from 2401
and pondering these issues.  I was glad to see that a 2401bis effort was
underway and that
attempts were being made to address some of the very same issues that had me
perplexed after having
studied 2401.  But I am also anxious to see the issues I found with 2401
fixed in an elegant,
and implementation independent way in 2401bis.

- Mike


>
> 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
>