Re: SPD issues

[Joe Touch <touch@ISI.EDU>]

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.

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.

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