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

Re: SPD issues





Mike Taylor wrote:

Hi Joe,

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

agreed.


-----Original Message-----
From: Joe Touch [mailto:touch@xxxxxxx]
Sent: Monday, October 20, 2003 4:57 PM
To: Mike Taylor
Cc: Mark Duffy; Stephen Kent; ipsec@xxxxxxxxxxxxxxxxx
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.

Yeah - that's why I'm wondering if the "use external SPD lookup" might be a security hole per se. Pushing it to an external, unspecified function certainly has that flavor.


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.

In that case, there would need to be an SPD entry that says "don't IPsec"; that was the case I was thinking of, but I agree that this should be in the SPD at that point.


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.

Yes - that's a can of worms of a different color (to mix metaphors).


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