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

RE: L2TP+IPsec and IKE authentication

Title:
I wonder if we've lost the view of the remote access market from 3 years ago, and how much better off the situation is now - there are a variety of solutions and many of them and customers are using them to increase their business productivity and reduce direct dial costs.
 
From a technical perspective, perhaps L2TP/IPSec is more heavy-weight than some remote access usage requires.  I have high hopes that the IPSRA WG will get an RFC for a more optimal IPSec-only remote access solution, so customers who can use it will. 
 
It's not clear how long the remote access model VPN model will meet business communication requirements.  Perhaps the IPSec WG will focus on a solution for multicast & IPv6 that always uses IPSec, end-to-end, with some kind of authenticated gateway traversal, as an alternative to a VPN remote access model.  Customers will probably get in the way with those requirements...
 
3yrs ago, many many customers bitterly complained that Microsoft & Cisco didn't have a VPN protocol that worked together, that PPTP had security problems.  So our (MS) support for L2TP was by sheer customer (market) demand and technically acceptable for the wide class of problems it solves - a dial compatible, leveraged infrastructure for VPN remote access that was IETF standards based - that worked for all traffic types and could fully replace PPTP.  Fortunately L2TP made it to RFC in Aug 99 and requires another IETF standard for security which was already available in the IKE/IPSec RFCs in Dec 98 - which did not provide client remote access features. 
 
Now, MS & Cisco have both PPTP (with security fixes of course) and L2TP/IPSec support and customers can get on with their core business.
 
I see all the IPSec related support cases in Microsoft's call database - and I know that there are many practical issues with just unicast IP-only IPSec tunnel mode clients, particularly for Mom & Pop shops, small businesses and relatively unmanaged medium sized company networks - IP-only is network, end-system and application dependent.  Large business & enterprise are not so much restricted by IP only.  Though some large corporate business decision makers have actually asked us to commit to them that TCPIP is definitely the future, so they can phase out other transport protocols, which would still take a few years as they migrate applications & end-system configurations.  Such a question may sound crazy to network engineers & service providers, but it was an important question for the customer to decide to spend the money to migrate their internal infrastructure. 
 
Add to this the requirement that people want their end-user remote access experience to be as similar as their at-work desktop experience, existing applications to work and new internal web content delivery multicast applications to work - and we had to provide a solution for IP broadcast & multicast through a tunnel an interoperable, deployable way now, not next year.
 
 
-----Original Message-----
From: Stephen Kent [mailto:kent@bbn.com]
Sent: Wednesday, May 24, 2000 3:12 PM
To: gwz@cisco.com
Cc: ipsec@lists.tislabs.com
Subject: RE: L2TP+IPsec and IKE authentication

Glen,


<snip>




> So, what is disturbing

> about this argument is that we're making architectural accommodations

> for what would normally not be subject to an IETF standard. This is

> even more surprising because in most (if not all) of the other

> security standards I can think of, we are amazingly silent about

> these sorts of assurance issues. Thus I am forced to conclude that

> the departure from this precedent is driven more by market(ing)

> forces than by technology or security concerns.


God forbid we would allow reality to impinge upon the standardization

process.


Often those who disparage standards and cite (their version of) reality as the ultimate test of relevance are those who find solace in the ability of dominant market players to set de facto standards. Such standards need not undergo the scrutiny that the IETF usually imposes on proposals, making life easier for the developers, if not, ultimately, users.


It's so nice to see that the disregard for standards processes that you honed during your tenure at Microsoft has not been lost in your transition to Cisco.


Steve

Follow-Ups: