[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: IPSec Complexity
On Thu, 17 Feb 2000, Joe Touch wrote:
> > From owner-ipsec@lists.tislabs.com Tue Feb 15 17:44:09 2000
> > Date: Tue, 15 Feb 2000 17:21:28 -0800
> > From: Skye Poier <skye@ffwd.com>
> > 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.
>
> ...
>
> > I can't find any disadvantages to using tunnels mode everywhere, except
> > for a slight increase in bandwidth usage. Comments?
>
> Yipe. I've already found that I need to use transport mode subsequent
> to vanilla tunneling (IP in IP) to allow dynamic routing to run
> inside an IPSEC'd overlay (VPN, if you prefer).
I agree. One very nice thing about L2TP+IPSEC is that it looks like a network
interface with security features versus a IPSEC in tunnel mode which is a layer
3 security transport. Since there is a PPP interface on top of L2TP, all the of
the interface specific stuff runs transparent to IPSEC. There are no Routing
protocol issues and standardized, well deployed MIBs are available for the
interface. PPP and L2TP also give you built-in keepalives for interface
maintenance.
If we were to get rid of one mode for IPSEC, I certainly would cast my vote for
getting rid of Tunnel Mode. I think this is probably a moot point though, since
there are just too many implementations out there with tunnel mode.
-Skip
>
> The packets end up looking similar - just that
> vanilla_tunnel+transport IPSEC
> keys on the tunnel header, where transport keys on the inner header.
>
> This is how we got around the problem of integrating tunneling with
> routing. We let regular routing determine which vanilla tunnel
> to use, and the key rules remain static. Otherwise, we'd have
> to tie the key rules to the dynamic routing daemon, which is a pain.
>
> Has anyone else stumbled on this, and/or found this solution?
>
> (I can provide more detail if useful)
>
> Joe
>
>
Follow-Ups:
References: