Re: Rant (Was Re: Our friend FTP, again)

[David Bonn <David.Bonn () watchguard com>]

> > > > > "David" == David LeBlanc <dleblanc () mindspring com> writes:

David> Possibly.  I also think that IPSec will solve a lot of problems once
David> it is widespread.  It doesn't require IPv6, and once every protocol
David> doesn't have to roll its own privacy and integrity mechanisms, that
David> will take us a long way.  IPSec is going to be shipping in most major
David> OS's RSN - we'll see if people actually use it...

IPSec is a topic worthy of a rant.

What we've bought with IPSec is a packet-level security mechanism that 
is technically quite complete and administratively quite hopeless.

You have excellent and impressive policy definition capabilities -- in 
particular, you can specify encryption and authentication policies by
source and destination address, protocol, and source and destination
ports.  This is in theory kinda cool, because you can theoretically
add more paranoia to services that probably need it (SNMP, SMTP) but
you can avoid encrypting a service that already is reasonably secure
(SSL, SSH).  That's the theory.

In practice, what a poor network administrator probably wants from
IPSec are two things: one, let people read their e-mail and pass files
around from a laptop computer when they're at traveling or otherwise
not at the office; second, connect their entire local network to other
networks that have varying degrees of trust.  IPSec (and supporting
protocols such as ISAKMP/IKE) give network administrators fits in both
scenarios.

In the first case, without nonstandard trickery, it isn't generally
possible to have a host connect through an ISP, contact another IPSec
endpoint, authenticate itself, and have a tunnel come up.  This is
because IPSec is built around the assumption that the IP addresses
(particularly tunnel endpoints) and other policy parameters in a given
security association are completely known before the tunnels are
configured.  It is true that IBM and Ashley Laurent have proposed a
solution to this problem, but you'd think that a security architecture
would actually consider what people need to do.

The second problem is at once more subtle and more annoying.  From a
management standpoint, you've essentially inherited a mess.  Any
modification of the remote network your office is having IPSec with
requires a reconfiguration of your local tunnel endpoint.  If there
are lots of tunnels (like more than four or five) this could be a
pretty humungous administrative burden.  You could do various goofy
things with other tunneling protocols and running routing protocols
through these tunnels within tunnels, but the upshot is that it is
hard to see how to make IPSec scale, even with IKE and certificates
(don't even get me started on certs).

Now, if you throw in more complicated policy configurations than just
the destination addresses, you've got some real entertainment.  You
can't build IPSec policies that can handle FTP or MS Exchange traffic
separate from other stuff.  That's probably somewhat managable because
nobody in their right mind ever uses all of that policy stuff, and if
they do they ought to apply a high level of paranoia to all traffic
with some specific exceptions.  In practice, I think all of that cool
policy stuff is unlikely to be used, and rather painful to get working
in the first place.

Using real-life anecdotal data, I know that 90 percent of my companie's
technical support calls actually end up dealing with local network
configuration problems.  Most firewall vendors, security consultants,
and VPN vendors probably see about the same thing.  With IPSec we're
throwing something terribly and needlessly complex on top of an
already creaky management and administrative structure.

...enough of my talking.

David Bonn, CTO
WatchGuard Technologies, Inc.