[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: SPD issues
At 18:37 -0700 10/21/03, Mike Taylor wrote:
> -----Original Message-----
[mailto:owner-ipsec@xxxxxxxxxxxxxxxxx]On Behalf Of Stephen Kent
Sent: Tuesday, October 21, 2003 2:06 PM
Subject: Re: SPD issues
At 13:53 -0700 10/21/03, Joe Touch wrote:
>Stephen Kent wrote:
>>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
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
in plaintext format onto an untrusted network.
IPsec really defines a boundary (what we woulkd traditionally call a
red/black boundary) that packets traverse. if you decide that the
interfaces to the trusted nets are on the red side of an IPsec device
with multiple interfaces, then IPsec would not be invoked at all. if
you put interfaces on the black side, you have made a mistake,
because you are explicitly relying on the routing/forwarding on the
black side to do the right thing.
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
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
and furthermore, the interface to which the route points cannot be changed
the policy explicitly being redefined, in other words, delete the route and
with a new policy. Of course, a human adminstrator could still very well
make an error and
point the route and the wrong interface.
see comments above
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,
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
best-effort datagram delivery service. In an ideal world (that probably
ever exist even after IPv6 becomes predominant) there would be nothing
hosts except pure routers. No NAT, no SGs, no proxies, etc. etc. As the
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
I think you are overstating the problem a bit. IPsec is designed to
that one can deploy it in a variety of configurations without
requiring applications to be aware of its presence. However, one can
certainly misconfigure SPDs to undermine the security offered, and if
one allows bypass of certain traffic, then there will always be
channels that can be used to exfiltrate data from a host or site.