[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Windows 2000 and Cicsco router interoperability
"W. Mark Townsley" wrote:
> > But, getting back to the point at hand, it seems to me that you have
> > provided a rather strong argument against using l2tp/ipsec for remote
> > access, as it does nothing to provide for this transition, and more
> > likely would impede it, since customers would have little motivation to
> > change their existing deployments.
> The idea is that "dialup" users and VPN users can live and access
> harmoniously beside one another, accessing the same services without
> having to update and maintain two databases, code paths, access server
> configuration, etc.
Ah, but they apparently can't. People are complaining that they cannot
get w2k to use ipsec in tunnel mode, apparently because the released
code assumes that l2tp is the right path. Again, the ipsra charter
explicitly lists a preference for solutions which encourage migration to
pk-based mechanisms. The simple password-based mechanisms used by many
existing deployments are simply not secure. This is a critical issue on
today's (and tomorrow's) internet.
A point that was made later in the email is that it seems that remote
access can be provided in a simpler, cleaner way using ipsec tunnel
mode. Granted, you don't get mlppp and a bunch of other things, but it
is not clear that anyone needs these for remote access, given that dsl
and cablemodems are likely to completely displace isdn, and given that
ipsec tunnel-mode may obviate the need for a ppp tunneling mechanism for
> In fact, the most popular L2TP/IPsec available *forces* one to use PKI for
> machine auth (much to the shagrin of many customers).
> > Maybe I have a misperception in the following, and if so, someone may
> > correct me. It seems to me that ppp and l2tp were constructed with a
> > particular model in mind, that being the dialup POTS user accessing the
> > corporate net first via a corporate modem pool, and then via a
> > user-local ISP. I would argue that we have found ourselves in a much
> L2TP was the culimination of what we had learned and deployed with L2F and
> PPTP. While L2F was primarily used in the manner you describe, PPTP had
> (has) a very large installed base of client access.
I don't understand what you are getting at - please elaborate. My point
was that the model has changed given dsl and catv access, and ppp/l2tp
are not necessarily the best fit for this new model.
> > different world with the deployment of dsl and cablemodems, one in which
> > remote access is taking on new meanings. While the ppp/l2tp efforts
> Talk to some DSL companies. DSL is a huge driver of L2TP.
If this is so, I think it may be due to the fact that the ipsra group is
just getting started. I don't see why many such deployments could not be
replaced by ipsec tunnel mode. Am I missing something?
> > While in the absence of a secure tunneling mechanism the l2tp solution
> > seemed to make sense, it now appears that a much simpler approach is
> > feasible. IPsec provides a tunneling mechanism. With PKI deployment,
> > user certs in ipsec pretty much solve the user authentication problem.
> But does it provide:
> - AAA user auth and access to legacy authorization and accounting?
As a number of existing deployments demonstrate, l2tp/ppp is not
required for access to legacy authorization mechanisms, and the aim of
this working group is to provide a migration path to more secure
mechanisms. Accounting support is likewise provided by a number of
vendors, though your later point about keepalives points up a
shortcoming in current deployments.
> - Multiprotocol support?
This shouldn't be a driving factor, since the need for it is fading
rapidly. However, there is already a standard mechanism (gre) for
providing this, one which requires no changes to ipsec.
> - Standard method of tunnel existance (e.g. "keepalives" or "heartbeats")
> (which is quite important for accounting)?
This is a valid issue for remote access.
> - Utilization of well tested methods (not to mention code)?
The methods and code have not been tested with respect to security, or
with respect to the 2^n potential interactions these features may have
with one another (including security features). On the other hand,
nobody is suggesting that all the methods and code be dumped. The
question at hand is, must we accept all the baggage of l2tp/ppp, or
should we just extract those components which we need?
> > It may be argued that under some circumstances a second-factor
> > authentication mechanism would be useful, but it is not at all clear
> > that all of the functionality of ppp/l2tp is required in order to
> > provide this.
> You will end up rewriting, redesigning, redeveloping a large portion of
> it. Guess that keeps programmers in business, but I am not sure it is the
> most efficient way of doing things.
Again, we could re-use already-developed code which provides required
functionality. This code could be directly lifted from existing ppp/l2tp
deployments and integrated. Adding 2-3 extra protocol layers to every
transaction is arguably inefficient, and very difficult to analyze in
terms of security, yet this does not seem to register with the l2tp
proponents of this discussion.
> > This brings us full circle, back to my original question: what
> > functional requirements have been overlooked in the requirements draft?
> Let me get back to you on that... Headed off for Memorial Day vacation
We really can't get off of square one until this is done.