RE: SPD issues

["Mike Taylor" <mtaylor.eng@sbcglobal.net>]

See my comments below.

> -----Original Message-----
> From: Stephen Kent [mailto:kent@bbn.com]
> Sent: Tuesday, October 21, 2003 10:10 AM
> To: Joe Touch
> Cc: Mark Duffy; Mike Taylor; ipsec@lists.tislabs.com
> Subject: Re: SPD issues
>
>
> At 10:00 -0700 10/21/03, Joe Touch wrote:
> >Mark Duffy wrote:
> >
> >>
> >>>>[MD] 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.
> >>>
> >>>
> >>>[JT] 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.
> >>>
> >>>This could happen whether dynamic or static routing is used; the
> >>>issue is flux in the forwarding table and whether it is _allowed_
> >>>to affect SPD selection.
> >>>
> >>>Calling the function "SPD selection" doesn't absolve the problem.
> >>>
> >>>Joe
> >>
> >>
> >>No.  But it isolates the problems of which SPD to use, and which
> >>interface/ next hop to send the packet to.  Whoever feels that
> >>these are or need to be entwined for their application is free to
> >>do so.. Those
> >>solving simpler problems can avoid that.  And 2401bis can take
> >>itself out of the business of IP forwarding decisions.
> >>
> >>Mark
> >
> >I'm in favor of those last two observations, but it's the "whoever feels
> >.. is free to do so" that worries me. I.e., this gives enough freedom to
> >end up with a nasty loophole, e.g., "SPD selection can be supported, but
> >how is up to the implementer, and whether it is secure depends on the
> >implementation".
> >
> >Joe
>
> Joe,
>
> We have enough variation in how different contexts want to select
> SPDs (when more than one is needed) that I don't think we can do more
> than say that there is a lookup function which takes the outbound
> packet and local metadata as inputs.  This seems analogous to your
> earlier suggestion to allow a forwarding function to have access to
> the whole outbound packet to support an unspecified forwarding
> lookup, when we were thinking of having an explicit forwarding
> function as part of IPsec.
>
> Many IPsec implementations will need only one SPD, so this whole
> issue is a no-op in those cases.  In cases where multiple SPDs are
> appropriate, then yes, the implementor and the admin will have to
> exercise caution in these contexts.  Generally, we cannot have it
> both ways.  if we keep things simple, we can have more confidence in
> their security, but we loose flexibility.

Bear in mind that it doesn't really matter if there is only one SPD.
Because even a single SPD can have multiple policies for outbound
red datagrams that match the source address of a particular sender,
and provide different levels of security (perhaps none at all) depending
on the destination address.

So it isn't really a no-op just because there is only one SPD.

Believe me, I'm in favor of keeping the RFC as simple as possible, and
ideally would like to see forwarding and IPSec SPD lookup divorced from
one another.  But it isn't yet clear that truly solid security can be
provided that way.

Its all got me wondering if there really is a fool-proof solution to
this problem other than specifying that the level of protection afforded
to any given outbound datagram should be based solely on the source
of the datagram, and not on the destination.  In other words, in the real
world if I am transmitting sensitive information then effectivly all
networks are untrusted.

But if we want to continue with the notion that some networks are trusted
more
than others, then perhaps (and I recognize that it would be fairly radical
change) the correct model for IPSec is that there MUST be an outbound SPD
per-interface (becaues we view security as inherently being tied to the
trustworthiness of different interfaces) and that the security afforded
a datagram is based strictly on the source of the datagram and the interface
that it exits, rather than the source and the destination addresses.

Because I think the issue we're dancing around here is that while I might
think its OK to send a red datagram to a given destination with possibly
no protection at all, I only belive that because I believe that the
destintation
is connected to some trusted network where security isn't needed.
Otherwise,
I'd be pretty crazy to do it.  But this ignores the fact that due to routing
errors or misconfiguration, or a bad implementation, the datagram might
actually
escape onto a network I don't trust.  This doesn't have to be the public
internet.
It might just be, for example, that a datagram from accounting to HR
gets misrouted into an engineering lab where it is captured by some
engineer's packet
sniffer and he sees that the big layoff is coming.  Gee, wonder why I
thought of
that example.  Must be the times. :(


>
> Steve