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@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
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
implementation which is what I'm working on. I haven't though
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
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
function (possibly after fragmentation although naturally I am
avoid that). If in reality the interface has changed in the few
the original routing decision was made this isn't any more serious a
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
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
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
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
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
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
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
mode is why many folks want to see the requirement that Security Gateways operate in
only (unless they're acting as hosts) removed from 2401bis, or at least clarified.
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
exit the gif device.
(see draft-touch-ipsec-vpn-06.txt, or our ICNP paper from 2000 cited therein) ;-) ...