[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: SPD issues



Hi Joe,

See my comments below.  I don't pretend to know the answers.
In fact, these issues seem quite thorny to me.

> -----Original Message-----
> From: Joe Touch [mailto:touch@ISI.EDU]
> Sent: Monday, October 20, 2003 4:57 PM
> To: Mike Taylor
> Cc: Mark Duffy; Stephen Kent; ipsec@lists.tislabs.com
> Subject: Re: SPD issues
>
>
>
>
> Mike Taylor wrote:
>
> ...
> >>>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?
>
> Yes. Even in embedded devices, unless the forwarding database is in ROM,
> it gets changed.
>
> > 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.
>
> This has nothing to do (necessarily) with virtual routers, or even
> dynamic routing.
>
> > 	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.
> ...
>
> Agreed. If there's no SPD lookup, then this is not an issue.
>
> > 	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).
>
> Misrouting is an issue of the packet goes out on an interface with
> encryption that isn't appropriate for that interface. I.e., if I change
> the SPD and the forwarding table at the same time, and whether there are
> packets pending in IPsec inbetween - and there isn't any current rule
> that prohibits those two occurrances.
>
> > 	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.
>
> It might be. It's not clear that this matters for this situation, though.
>
> However, if the SPD lookup in this case depends on forwarding, it's
> possible that packets will be emitted based on tunneling that is based
> on forwarding that is stale by the time they exit. Again, it's possible
> that packets could be sent in the wrong direction with weaker security
> than is intended.

I see your point in that if I have two different policies for the same
source address (the red network) but different destination addresses
(maybe one is the public internet and another is for some other subnet
in my domain).  Perhaps the latter has weaker security (none at all even)
than the former and because routing gets messed up datagrams could go
out the wrong interface, perhaps a public one, with no protection at all.

This may well be what the original authors of 2401 were thinking about
when they created a per-interface SPD concept.  However, I'm not sure
I see how that really solves the problem either.  It just seems moves it
from getting the routing correct to getting the assignment of policies to
physical interfaces correct.

In other words, perhaps the two problems really aren't separable at all.
Thus,
perhaps IPSec requires a fundamental change to IP in that it must be
incorporated into routing.  Perhaps in an IPSec box it should be impossible
to create a route without specifying an IPSec policy to go with it.  Would
that solve the problems? Hmmm...... It certainly causes a problem for
BITS/BITW
implementations.  But if such solutions are really hacks then perhaps we
shouldn't give them any official blessing.  The whole issue of security is
so important that we can't afford not to get it right this time around.

>
> If the SPD lookup MUST NOT depend on the forwarding table, then this is
> not an issue. If the SPD lookup MAY depend on the forwarding, then this
> needs to be considered.
>
> > 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.
>
> I'm not advocating the requirement of virtual interfaces for this issue
> either; I'm just observing the a potential relationship between the SPD
> lookup and the forwarding operation afterwards.
>
> > 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.
>
> This might work if there were no non-IPsec routes for a packet. That's a
> very special case, IMO.

But in this concept there are no non-IPSec routes because there is only
a single SPD.  So there is no way for a datagram to exit the box
without IPSec getting a look at it.  This idea is only one possible way
to avoid creating "fake" routes for the datagrams destined to some remote
private network that are going to be tunneled and for which there cannot
be any real route.  Another way to avoid the fake route issue is by
creating some sort of virtual interface to which routes point.  But what
if there are also routes to "real" interfaces for the same destination?
Again, having per-interface outbound SPDs won't help that in a stack that
supports multiple routes for a single destination.

>
> Further, if the IPsec 'takes it from there' and then finds out that
> there is no SA, what is the ICMP error message? SA not found (or
> silent), or route not found?
>
> > 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.
>
> (see draft-touch-ipsec-vpn-06.txt, or our ICNP paper from 2000 cited
> therein) ;-)
> ...
>
> Joe
>