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

Re: Windows 2000 and Cicsco router interoperability



Stephen Kent wrote:
> 
> >Mark,
> 
> >Please allow me to dispose of this view with some facts. First, L2TP is
> >a standards track document that has support of many vendors, of which
> >cisco and Microsoft are only two.
> >
> >Further, the fact that L2TP exists and is supported by both companies
> >you single out is actually a tribute to support of IETF standards by
> >each in the face of significant opposing development efforts. Clearly,
> >if either were to try and capitalize on past development efforts as you
> >suggest, L2TP would not exist and the world would have to choose between
> >cisco's support of L2F and Microsoft's support of PPTP (each joint
> >development efforts in their own right). No IETF. No standard RFC.
> 
> My understanding of the history, is that L2TP represents a detente
> agreement between MS and Cisco in this arena, which was then brought
> to the IETF for standardization.  PPTP, and it's impressive security

Ultimately, MS and Cisco agreed to do what the IESG suggested. That is,
create L2TP and let it go through the standards process for all to be a
part of. MS and cisco were the initial driving force, but L2TP rapdily
took on a life of its own. 

> complement, MPPEP, make for a laughable combination.  I don't know
> what Cisco envisioned as security for L2F, but it is clear that the
> IESG mandated that L2TP not progress without a credible security
> component, and so LT2P adopted IPsec, but in a fashion that is
> architectually questionable.

More than one proposal was presented for security, this was the one that
was agreed upon at the time. Believe it or not, the the idea was to
support IPsec in its efforts rather than duplicating security work
within pppext. Too bad the reverse was not chapioned within IPsec early
on (that is, letting IPsec rely upon pppext for remote access concerns). 

> 
> >Creation of L2TP and support of it is precisely the opposite of what you
> >are claiming. Here Microsoft and cisco are both championing support of
> >an IETF standard protocol, in direct opposition to that which each
> >developed in-house and deployed first, and you are still being branding
> >both as evil?
> 
> Calling MS evil would be stating the obvious, as so many recent
> events have illustrated :-).
> 
> >
> >  > sending non-IP packets, L2TP is appropriate, but if I am sending IP,
> >  > then the extra headers introduced by L2TP are not only wasteful of
> >  > bandwidth on a continuing basis, but they also interfere with the
> >
> >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?
> 
> Reasonable points re my per packet overhead criticism, although the
> excess is still just wasted space, whereas the ESP header is

2 bytes and you get multiprotocol capability. Heck, it would not be too
difficult to even reduce this to 0 bytes if one is *that* concerned and
does not mind limiting oneself to a single NCP within PPP. 

> essential for the function in question. Still, from a single, dialup
> host, it's not clear under what circumstances the multi-packet muxing
> will be invoked.

The driving force for ppp mux as I remember is for voice packets at
aggregation points in a wireless network. There could be others, but the
point I was really making is that there are all sorts of things that the
pppext WG has done for point to point remote access connections. What
makes a secure tunnelled point to point connection so special? I see a
VPN connection stepping in to replace what was traditionally a dialup or
leased line. Utilizing the facilities that are in place and expanding
upon them makes a great deal practical sense.

> 
> Steve
Follow-Ups: References: