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

RE: Getting the features chart going



The alternatives to XAUTH/ISAKMP-config of which I'm aware are documented in
http://www.ietf.org/internet-drafts/draft-ietf-ipsec-isakmp-hybrid-auth-02.t
xt and http://www.ietf.org/internet-drafts/draft-ietf-ipsec-dhcp-01.txt;
there may be others.  The major benefits of L2TP over hacking IKE are pretty
obvious, I think, but include _real_ interoperability, the use of
well-understood protocols for both authentication and remote node
configuration.  A more interesting question is why anyone would favor the
invention of novel extensions to a protocol that is already far too complex
over the use of widely-deployed, proven techniques.  I understand that
firewall vendors have generally not implemented PPP, but building a basic,
interoperable implementation of either PPP or L2TP is simple enough to be a
college CS project.

 -----Original Message-----
From: 	Stephane Beaulieu [mailto:sbeaulieu@TimeStep.com] 
Sent:	Friday, June 25, 1999 6:12 AM
To:	Glen Zorn; Stephane Beaulieu; Stephane Beaulieu; Paul Hoffman /
VPNC; vpnc-technical@vpnc.org
Cc:	ipsec
Subject:	RE: Getting the features chart going

> I'm glad you appreciate constructive input (abandoning a 
> fruitless approach
> is often the first step toward basic sanity).  I note that you do not
> dispute my characterization of XAUTH as "proprietary", 
> doubtless because
> that assertion is undeniable. 

XAUTH is an attempt at creating a standard to solve a real-world problem,
and is being implemented by mulitiple vendors.  At last count 5 vendors are
implementing it.  Mind you, I don't believe any have it "off-the shelf" yet.

 I am sure that _you_ are aware 
> that (even in
> the IPSec WG) there are alternatives to XAUTH and/or 
> ISAKMP-Config. 

The only other way that I know of is to do L2TP over IPSec.  If there are
others, then please forward links to me.

Implementing L2TP seems like an aweful lot of work to accomplish something
as simple as being able to tunnel into a private network.  It seems to me
that finding a way to allocate an IP address from your internal pool and
doing IP in IP (or in our case IPSec tunneling) is a much more viable
solution.  


 Even if
> I were to be somehow convinced that IPSec tunnel mode was a 
> reasonable way
> to do remote access across the Internet, it still is not at 
> all clear that
> XAUTH and/or ISAKMP-Config is the right way to do it. I am 
> aware that there
> was an "IPSec-RAS" BOF in Minneapolis; I'm unaware of any 
> progress since
> then.  BTW, there is a Proposed Standard method for tunneled 
> remote access:
> L2TP/IPSec.  Perhaps that doesn't solve _your_ problems, but 
> it seems to
> solve those of my customers.

I'm curious to know what you believe the advantages to L2TP tunneling are
over IPSec? 

Perhaps we should move this discussion to the IPSec list though.

Stephane.

>  -----Original Message-----
> From: 	Stephane Beaulieu [mailto:sbeaulieu@TimeStep.com] 
> Sent:	Thursday, June 24, 1999 9:43 AM
> To:	Glen Zorn; Stephane Beaulieu; Paul Hoffman / VPNC;
> vpnc-technical@vpnc.org
> Subject:	RE: Getting the features chart going
> 
> Glen,
> 
> 	Thank you for your constructive opinions.  I believe there are
> enough vendors interested in implementing/testing both 
> Isakmp-Config and
> XAUTH even though you may not be.  I'm sure that you are well 
> aware that
> there is an effort to form an IP Secure Remote Access group.  
> If you have
> something to contribute to try to get something 
> "standards-based" be it
> Isakmp-Config and/or XAUTH or something else, the rest of us 
> would be happy
> to hear it.
> 
> For the mean time, if one of the goals we're trying to 
> achieve is a chart
> denoting interoperability features, then I believe that as 
> long as a handful
> of vendors wish to support it as their method for solving the 
> problems that
> we are faced with, then they should be included.
> 
> > -----Original Message-----
> > From: Glen Zorn [mailto:glennz@microsoft.com]
> > Sent: Wednesday, June 23, 1999 7:32 PM
> > To: Stephane Beaulieu; Paul Hoffman / VPNC; vpnc-technical@vpnc.org
> > Subject: RE: Getting the features chart going
> > 
> > 
> > I would be opposed to "interop" testing proprietary hacks.  
> > 
> >  -----Original Message-----
> > From: 	Stephane Beaulieu [mailto:sbeaulieu@TimeStep.com] 
> > Sent:	Wednesday, June 23, 1999 5:28 AM
> > To:	Paul Hoffman / VPNC; vpnc-technical@vpnc.org
> > Subject:	RE: Getting the features chart going
> > 
> > I would like to see Isakmp-Config and XAUTH added.  Hopefully 
> > these can be
> > further tested for interop at the next bakeoff.
> > 
> > > -----Original Message-----
> > > From: Paul Hoffman / VPNC [mailto:paul.hoffman@vpnc.org]
> > > Sent: Tuesday, June 22, 1999 11:13 PM
> > > To: vpnc-technical@vpnc.org
> > > Subject: Getting the features chart going
> > > 
> > > 
> > > OK, one of our first deliverables is a chart whose rows are 
> > the VPNC 
> > > members and whose columns are important VPN features that are 
> > > or are not 
> > > supported by individual members. The chart will be a "green 
> > > checkmark" 
> > > chart, which is easy for the press and customers to go 
> > > through. The company 
> > > names will have links to company info.
> > > 
> > > So, what features do we want? I'd like the feature names to 
> > > be five or 
> > > fewer words, and there will be a legend that will explain 
> > > what we mean 
> > > below the chart. Here's my first guess, which probably has 
> > > wrong things in 
> > > it, and most certainly doesn't have all that we want:
> > > 
> > > IPsec gateway
> > > IPsec client for Windows
> > > IPsec client for Unix
> > > IPsec client for Macintosh
> > > L2TP/IPsec (as in you do both parts)
> > > PPTP with RC4
> > > Can do aggressive mode
> > > IKE X.509 certificates
> > > IPPCP compression
> > > TripleDES encryption
> > > 
> > > My guess is that we will probably want at least five more 
> > > columns, at least 
> > > some of them related to IKE. I didn't include "shared 
> > secret" because 
> > > everyone does it; there's no reason for a column where 
> > > everyone gets a 
> > > check mark. Similarly, I would rather not have columns where 
> > > only one or 
> > > two companies get checks (unless we believe that more will 
> > get checks 
> > > within a month or two).
> > > 
> > > Again, I may have messed up some of the above, and I want a 
> > > bunch more 
> > > columns. Start suggesting!
> > > 
> > > --Paul Hoffman, Director
> > > --VPN Consortium
> > > 
> > 
>