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

Re: Benefits of l2tp with ipsec?

Bernard Aboba wrote:

<extensively trimmed to focus on one point...> 

> > Purely from an efficiency in layering point of view, and a bits-consumed
> > point of view, this seems bad.
> Actually, this is a red herring. As noted in
> http://www.ietf.org/internet-drafts/draft-aboba-ipsra-req-00.txt
> IPSEC/L2TP with L2TPHC has only slightly larger overhead than
> IPSEC tunnel mode and IPSEC/L2TP with PPPMUX actually has *lower*
> overhead than IPSEC tunnel mode. It also will have lower latency
> at lower bit rates. It's worth keeping in mind though that this
> will probably only matter when doing audio over VPNs (which
> may be a shaky proposition for other reasons).

I'd like to make a distinction here which I've tried to make in previous
posts (as have others), but which has been apparently ignored. Bits on
the wire is a small component of the overhead concern, and not the one
we are most concerned with here. The added protocol layers are far more
troublesome, as they add a significant amount of complexity to the
devices at either end of the connection. This is, I think, the primary
issue with respect to overhead arguments.

So far, the response to this particular concern has been to note that
l2tp/ppp code is available either free or for a price to those that have
not implemented it, but this completely misses the point. We know that
it is available, and it is not the prospect of integrating this code in
our devices which bothers us. No matter what approach we choose, we will
be integrating code into our boxes. It is the prospect of adding a large
amount of code complexity (much more than might be necessary to solve
the problem at hand) which is far more troublesome.

While it is difficult to precisely quantify, it is generally agreed that
the probability of a security flaw is proportional to code complexity.
Therefore, as members of a security area working group (one of the
primary goals of which is to provide secure solutions), we tend to
insist that mechanisms be as simple as possible in order to minimize
this flaw probability. Obviously, there are design tradeoffs, but still,
complexity must weigh heavily in those decisions given its probable
impact on the resulting security. In general, we tend to select
solutions which provide no more than is necessary and sufficient to
solve the problem at hand.

The ppp/l2tp approach offers a great deal of functionality, most of
which is not mentioned in the current ipsra requirements draft. What
portion of this functionality is actually *required* for secure remote