[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: IPSec Complexity
On Fri, 18 Feb 2000, Frederic Detienne wrote:
> 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.
I agree to some degree. You certainly can implement a IPSEC tunnel interface.
Not sure how many SA's you have to set up though. Would you negotiate a new SA
for every new route you learned?. This would be very cumbersome for mesh
connectivity as it would lead to a huge set of SA's. On the other hand I guess
you could set your filters to encompass all traffic.
You also cannot assume at this point that your peer also implements a IPSEC
Tunnel interface design. There certainly is nothing in the current set of
standards which addresses this issue. With L2TP + IPSEC you know that both
peers have a PPP interface which is standardized so there are no
interoperability issues here.
>
> 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.
Not sure what you mean here. PPP supports a very robust negotiation protocol
for it's link layer characteristics (LCP), and it's network protocols (NCPs).
IPCP is the control protocol which PPP uses to set up IP. IPCP already supports
address, DNS, WINS, and Gateway assignment.
>
> > 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).
Very little difference depending on the header compression you use for the
tunneling protocol.
-Skip
>
>
> fred
>
Follow-Ups:
References: