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

RE: SPD issues





> -----Original Message-----
> From: owner-ipsec@lists.tislabs.com
> [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Stephen Kent
> Sent: Tuesday, October 21, 2003 2:06 PM
> To: ipsec@lists.tislabs.com
> Subject: Re: SPD issues
>
>
> At 13:53 -0700 10/21/03, Joe Touch wrote:
> >Stephen Kent wrote:
> >
> >>Folks
> >>
> >>There may be some misunderstanding about what holes an SPD
> >>selection function creates.
> >
> >
> >...
> >>The only way to be really confident about the security services
> >>being provided for traffic is to have just one SPD, or to make sure
> >>that the multiple SPDs are not overlapping in terms of the
> >>destination addresses (for outbound traffic), or that the security
> >>services offered in any overlapping entries are equivalent.

I don't see how having a single SPD helps.  Even with a single
SPD I can have two outbound policies for the datagrams that match a given
source address where different levels of protection are applied based
on the destination address.  Suppose, for example, that I have an SG
with 3 interfaces, one to an untrusted network, 192.168.0.0/24,
and the other two to trusted private networks 10.240.1.0/24 and
10.240.2.0/24.
And furthermore, there is a 3rd trusted subnet, 10.240.3.0, reachable
via the router 10.240.1.1.

Now I could have two policies in my one SPD for datagrams from source
addresses on 10.240.2.0/24.  If they're going to 192.168.0.0/24 then I want
ESP encryption and authentication.  If they're going to 10.240.3.0/24 then
I just bypass IPSec.

Then if routing gets messed up and a datagram from 10.240.2.0 and destined
to 10.240.3.0 gets no IPSec applied but ends up being sent out of the
192.168.0.0/24 interface instead of 10.240.1.0 I have sent sensitive
information
in plaintext format onto an untrusted network.

Still, I admit that I'm not sure this is something that can be dealt with
easily by IPSec.  It would seem to require that IPSec always be built
natively
into an IP stack, and that it is somehow tied very tightly to the forwarding
database such that routes are essentially owned by IPSec and must have a
policy,
and furthermore, the interface to which the route points cannot be changed
without
the policy explicitly being redefined, in other words, delete the route and
re-enter
with a new policy.  Of course, a human adminstrator could still very well
make an error and
point the route and the wrong interface.

It seems to me that the ultimate problem is that it really isn't
possible to provide rock solid security unless applications are aware of it,
and
it is provided end-to-end (i.e. no tunnel mode, SGs etc.)  Ultimately this
is the only model that properly fits the original concept of IP as an
unreliable
best-effort datagram delivery service.  In an ideal world (that probably
won't
ever exist even after IPv6 becomes predominant) there would be nothing
between
hosts except pure routers.  No NAT, no SGs, no proxies, etc. etc.  As the
forefathers
knew, this is the only way to achieve a highly robust, self-healing Internet
topology.  Of course, this model would likely put a lot of us out of
business. :(


> >
> >Steve,
> >
> >Is it possible that this paragraph ("The only way...") should be
> >added as the caveat? I.e., the concern I had was that SPD indexing
> >could be an open loophole; this closes it sufficiently.
> >
> >Feel free to forward this suggestion to the list if you feel it
> >would be useful.
> >
> >Joe
> Joe,
>
> Good point.  I think it is fair to warn folks about the need to pay
> very close attention to config mgmt issues when multiple SPDs are
> employed. A reference to Peter's paper might also be relevant.
>
> Steve