Re: SPD issues

[Joe Touch <touch@ISI.EDU>]

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

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