[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: IPSec Complexity
Skip Booth wrote:
>
> 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.
I think the presence of an IPSec tunnel interface is a matter of implementation. Nothing prevents you a priori from having such an interface and you could very well have the traffic run independent of the IPSec thing.
But I agree L2TP has some advantages; it would help in not re-inventing the wheel with IPSec (thinking here of mode config). L2TP however does not have an inherent "configuration" advantage over an IPSec tunnel.
> 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.
Yes. Though Transport mode has some drawbacks too. Especially when it comes to TCP. Look at an IPSec'ed TCP packet:
IP ESP[transport] TCP payload
Remember the TCP checksum is also calculated over a pseudo IP header. What now, if the packet is NATed ? The ip header is changed but the TCP checksum can not be recomputed since the NAT device may not have access to the TCP payload (or may not be able to recompute the authentication).
This of course is only valid for end to end communication only.
Notice I did not use AH since the AH authentication carries on a pseudo IP header too => inherently incompatible with NAT.
In a tunnel, you do not have that problem:
IP ESP[tunnel] IP TCP payload
In this case, only the outmost IP header would be NATed and that would not harm the TCP checksum calculation.
If you get rid of Tunnel mode, you have to use an other tunnel type (e.g. pptp or GRE or ...) and the packet would look like
IP ESP[transport] GRE IP TCP payload
In this case, things are still fine but you lose some bandwidth. (extra header).
fred
Follow-Ups:
References: