[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-----
 From: owner-ipsec@xxxxxxxxxxxxxxxxx
 [mailto:owner-ipsec@xxxxxxxxxxxxxxxxx]On Behalf Of Stephen Kent
 Sent: Tuesday, October 21, 2003 2:06 PM
 To: ipsec@xxxxxxxxxxxxxxxxx
 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.

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

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, 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. :(

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.


Steve