Date: Mon, 28 Dec 1998 07:12:55 -0500 From: Christian Kuhtz <ck@ns1.adsu.bellsouth.com> To: Matt White <mwhite@cmu.edu>, freebsd-current@FreeBSD.ORG Subject: Re: PPTP and FreeBSD Message-ID: <19981228071255.S1333@ns1.adsu.bellsouth.com> In-Reply-To: <4281573128.914814639@DEIMOS.REM.CMU.EDU>; from Matt White on Mon, Dec 28, 1998 at 03:10:39AM -0500 References: <199812272119.QAA13600@o2.cs.rpi.edu> <4281573128.914814639@DEIMOS.REM.CMU.EDU>
next in thread | previous in thread | raw e-mail | index | archive | help
Matt,
With all due respect, I have rarely read such complete rubbish. Further note
that I am making these statements not as a representative for BellSouth in
my function as Sr.Network Architect and designer of many advanced VPN services
among other thing, although IMHO many of the reasons cited below might apply
to us. Now that we got that out of the way, let me address the issue:
L2TP is a functional merger of L2F and PPTP. It is essentially extending a
layer 2 connection service over layer 3. It is far far more than a corporate
VPN service. In fact, it is of immense value to service providers.
L2TP is not interoperable with L2F or PPTP.
On Mon, Dec 28, 1998 at 03:10:39AM -0500, Matt White wrote:
> L2TP is much the same way. The reason for this is that these protocols are
> not really designed for what we are using them for. Both PPTP and L2TP are
> ways of tunneling traffic received from a client by an ISP's remote access
> device back to a corporate network. There is only one control connection
> per corporate network endpoint.
There is at least one 'PPP over IP' (ergo L2F/L2TP) connection per NAS (LAC)
per HG (LNS), over which multiple users can ride. A lot of it has to do with
the exact fault-tolerance and/or load-sharing setup.
For what precisely is L2TP design to be used for that we aren't using it for?
That statement is complete garbage.
L2F is in widespread use by service providers to provide VPDN services to
customers. Yes, there happen to be several very large providers who are
running a very successful commercial offering and have major customers using
the service. It requires absolutely no changes on the client (because it is
NAS initiated). One of the possible uses is to allow people to outsource
their high cost high maintenance corporate dial pools to us, without having to
make any changes in their network design (addressing, authentication, etc)
It can also be used by wholesale dial providers to provide wholesale dial
pools to their customers, the LNS being on the provider's premises and the LAC
being in the wholesale dial provider's hands. How else would you provide this
service, considering that the last thing you want to do as a wholesale dial
provider is getting involved in somebody's layer 3 addressing etc. In fact,
all you have to do is maintain the pool for a given DNIS, and the
authentication (since it is all PPP) is done by the LNS..
> This has the advantage that the end user doesn't have to set anything up on
> their computer to take advantage of the tunneling...it is done
> automatically by the RAS.
Since it is PPP, that statement is a false. The LNS and LAC negotiate the
connection.
The LNS terminates a tunnel per LAC, which (can, but usually always
does) contain multiple users, from multiple NAS, which are bonded via MCMLPPP
to originate a tunnel from the LAC to the LNS.
> The difficulty is, of course, that arrangements
> for these tunnels must be made at all possible access points so I wonder
> how much L2TP is actually ever going to be used as intended.
That is complete BS. Several service provider VPN services, for instance, is
available in its entire territory, which contains a great many number of NAS
and even more dial up ports. L2F is in very wide spread use today, in the
process of migrating to L2TP, and will most likely grow massively in '99.
A lot of the reasons are regulatory on one hand, and on the other hand,
advanced VPN services, which may for instance consist of MPLS based
infrastructures, need L2TP for integration with roaming users as well as
plain integration with other networks which do not have capabilities such as
MPLS.
> As far as the amount of work required to implement L2TP or PPTP, I'm not
> sure about how bad it would be. Keep in mind that a good portion of both
> of these protocols are implemented elsewhere. It might be more of an issue
> of sewing the right modules together.
>
> Not that I'm going to spend the time to do it. My personal feeling is that
> VPNs are evil and yet another excuse to not properly secure one's systems
> (firewalls being the last excuse).
L2F/L2TP is the only large scale service provider way of providing VPN
services. In fact, because of regulatory restrictions, it is often the only
way for the 'phone company' part of an RBOC to provide certain services
(because they can't and don't want to over layer 3 services, but can (by
virtue of the FCC allowing them to) offer layer 2 services, at which point
L2F/L2TP comes in).
We have been struggling with supporting PPTP for some time now, and have tried
to avoid it like the plague because NT is your only option for termination
which is clearly not a service provider product at the present time not does it
offer a scalable solution methodology wise.
L2TP is the way to go. And having LNS functionality would be *VERY* interesting
to have.
Nice to read such BS in here every so often, though.
Cheers,
Chris
--
Frisbeetarianism, n.:
The belief that when you die, your soul goes up on the roof and gets stuck.
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19981228071255.S1333>