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

RE: IPSec Complexity

Skye,

Tunnel mode versus transport mode is one question I've changed my mind over
the years and now disagree with Bruce. Elsewhere in his paper he says that
complexity is the enemy of security. My feeling is that tunnel mode
introduces lots of complexity into IPsec. Encapsulation/decapsulation per se
is not the problem; tuunel and transport mode encapsulation/decpasulation
can differ by a few tens of lines of code if you know what you're doing. The
problem is the extra support infrastructure needed to make a tunneling
protocol work. Generally this extra infrastructure won't be available unless
you happen to build routers.

A tunneling protocol alters the network topology, and doing this usually
means the tunneling protocol has to interact with the underlying routing
fabric somehow, or the whole system breaks. We see this today in the debate
over whether to use DHCP or Config Payload to assign an IP address to a
remote access client. This address assignment is only needed because we are
tunneling, and it is not evident how this has anything to do with the
security of the system, so should fall way outside the scope of the working
group. On the other hand, a system based on tunneling really won't work
without something like these mechanisms, so our architectural choice of
tunneling has forced us to introduce seemingly gratuitous functionality. How
does this help the security of the overall system? It doesn't.

What seems to make more sense, at least to me, is to abolish tunnel mode and
rely exclusively on transport mode. If someone wants or needs to tunnel, let
her run her favorite tunneling protocol (GRE, HTTP, L2TP, etc.) over IPsec
transport. My experience (but maybe no one else's) is that this always seems
to lead to much simpler deployments.

Steve Kent and others have argued against this strategy for years, as it
throws away the access control mechanisms tunnel mode affords. Maybe the
tunneling school is right, and it is a big mistake to try to separate
tunneling from IPsec, just as it was a mistake in the original IPsec design
to separate AH's functionality from ESP. But maybe a separation of tunneling
from IPsec is feasible; maybe all we need to do to address their concern is
to define a standard access control mechanism for tunneling protocols
generally. I don't have a good answer to this question.

Jesse Walker

-----Original Message-----
From: Skye Poier [mailto:skye@ffwd.com]
Sent: Tuesday, February 15, 2000 5:21 PM
To: ipsec@lists.tislabs.com
Subject: IPSec Complexity


Hello,

I just finished reading Niels Ferguson and Bruce Schneier's paper
"A Cryptographic Evaluation of IPSec".  They raise some interesting 
points, especially with regards to the complexity of the IPSec
specification.  I am working on a plan to integrate IPSec with our
product line and the major hurdle seems to be supporting the
different modes (tunnel vs transport) and protocols (AH vs ESP).

In conclusion the paper recommends adopting ESP/tunnel mode with
mandatory authentication and dropping the rest.  This certainly
appeals to me as we were already pondering the idea of using tunnel
mode everywhere (host-host, host-sg, sg-sg) for simplicity.

Has this topic already been discussed?  What is the current status
of the IPSec specification?  Is it an evolving standard?

I can't find any disadvantages to using tunnels mode everywhere, except
for a slight increase in bandwidth usage.  Comments?

Thanks
Skye

--
Clarity of thought should be accompanied by clarity of technique - Mondriaan
Powered by ffwd internet division   [ http://www.ffwd.com/ ]