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

Re: PPP over IPSec (Re: Windows 2000 and Cicsco router interoperability)

Ari Huttunen wrote:
> 
> "W. Mark Townsley" wrote:
> >
> > Let's talk facts again. On a highly scaled, high bandwidth system,
> > header size becomes increasingly less important. Over slow dialup lines,
> > of course, it is worthwhile to try and get the header as small as
> > possible. Negotiate PPP ACFC and PFC, and you get 1 byte of PPP header.
> > L2TP's typical header for a voluntary tunnel would be either 6 bytes, or
> > perhaps even 1 byte if you perform l2tphc.
> >
> > 2 bytes (or even 7 bytes w/o l2tphc) of overhead for l2tp and ppp is
> > small potatoes compared to ESP tunnel mode on each packet.
> >
> > Also, you get all sorts of nifty things that PPP is working on to reduce
> > overhead. For instance, draft-ietf-pppext-pppmux-00.txt allows you to
> > frame small packets into a single PPP frame. Given IPsec's large header,
> > multiplexing small packets into a single frame before encrypting and
> > tunneling could result in a *significant* header overhead reduction.
> > Care to add that to IPsec's repertoire of features too?
> >
> 
> I agree fully that having PPP for remote access provides with
> tangible benefits. Something like IPX transport would even be useful
> in a gateway to gateway case. It would be very inefficient for IETF
> to respecify everything for IPSec without PPP. (This is not to say
> that some non-PPP, non-L2TP remote access solution should not be created.)
> 
> What I disagree with is putting L2TP between PPP and IPSec. So far
> the only reason I've been offered for doing so is that PPP breaks if
> the packets are re-ordered during transit. 

Not sure who offered that one to you. (1) L2TP sequencing is optional,
and will likely run disabled in the voluntary case with IPsec, (2) While
order is specified in RFC1661 as a basic assumption, in practice we have
seen little to no problems with current PPP stacks running without L2TP
sequencing. In fact, I personally have seen more problems when L2TP
tries to drop packets received out of order. This has been hashed out
many, many, times on the l2tp list (as he scrambles to grab the worms
and stuff them back into the can before anyone notices).

> L2TP has a lot of functionality,
> but it's all irrelevant if you just want to have a link where the IPSec
> and PPP endpoints coincide. 

True, a good portion of what L2TP offers is not applicable in the
voluntary case (largely the Proxy LCP/Auth features, Tunnel
authentication, and perhaps some of the calling number/id etc. AVPs).
Most of these are optional, so there is no need to implement them for
the voluntary case. 

> (Anyone wanting to do compulsory tunneling
> would of course be free to use PPP/L2TP/IPSec.)
> 
> I would be very happy to see a standards track RFC that describes
> a lightweight method for running PPP over IPSec, usable in a voluntary
> tunneling case. The PPP over IPSec combination should be negotiable
> through IKE, IKE access controls should apply to whatever traffic comes
> out of / goes into PPP, i.e. actual customer traffic.

So IPSec now carries a Layer 2 protocol directly? I thought we were
interested in making IPSec *less* complex, not more. I don't see why
adding 1 byte of header via l2tphc (which runs directly over IP) is such
a stumbling block. 

As for the L2TP signaling. I think it makes more sense to have one
protocol which, at the Gateway (LNS in L2TP terminology), there is no
significant distinction as to whether you are terminating a compulsory
session or a voluntary session. Why create a new protocol for every
deployment model when a subset of one you have will work fine as is? 

> 
> --
> Ari Huttunen                   phone: +358 9 859 900
> Senior Software Engineer       fax  : +358 9 8599 0452
> 
> F-Secure Corporation       http://www.F-Secure.com
> 
> F-Secure products: Integrated Solutions for Enterprise Security
Follow-Ups: References: