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

Re: Windows 2000 and Cicsco router interoperability



This discussion belongs on the IPSRA mailing list, if I'm not mistaken.

jan


On Thu, 11 May 2000, CHINNA N.R. PELLACURU wrote:

> I guess the bottom line is:
> 
> Do you want to understand all the subtilities of AAA and IPCP, and then
> massively hack IKE on an ongoing basis, to incorporate all that, (with
> stuff like open ended exchanges, and on top of that require that every
> client need a "personal firewall")
> 
> or
> 
> Do you want to leverage all the features of AAA and IPCP in a simple
> modular way, and not bother too much about them, and trust them in that
> they do their job well.
> 
> Isn't securing CHAP/SecureID etc. within an IKE exchange an overhead?
> 
>     chinna
> 
> On Thu, 11 May 2000, CHINNA N.R. PELLACURU wrote:
> 
> > Atleast we agree on one thing: we should strive for simplicity.
> > 
> > We are essentially talking about adding all the AAA and IPCP baggage to
> > IKE. And that you say is simple!
> > 
> > On top of that you want each IPSec client to have a "personal firewall"
> > too. I can see why people want to suggest that.
> > 
> > IMHO, it is much much simpler and modular to let L2TP/PPP deal with the
> > AAA and IPCP, and let IPSec protect L2TP.
> > 
> > L2TP is fully encapsulated in IPSec, and I don't see how that is less
> > secure.
> > 
> > I don't see how it is simple to introduce the AAA and IPCP baggage into
> > IKE. How many forms of Authenticataion do you already support. Do you
> > support Authorization and Accounting? How many features of IPCP do you
> > already support? Probably it is simple for you because your customer base
> > needs only a small subset of these features. But, once we open the flood
> > gates, then customers would like to have all the features that they have
> > come to enjoy in AAA and IPCP, and I guess we have to hack the protocol on
> > an ongoing basis to add in features.
> > 
> >     chinna
> > 
> > On Thu, 11 May 2000, Will Price wrote:
> > 
> > > Those goals may be able to be "achieved naturally" by use of L2TP/IPsec,
> > > but the issue to get back to Stephen's point is that there is a lot of
> > > overhead involved in doing that when the same thing can be accomplished
> > > much more simply (and I hope we all learned that simplicity is job #1 here
> > > after reading Bruce's paper) by just using IPsec correctly mixed the
> > > appropriate client side personal firewall and routing as you point out.
> > > 
> > > The latest version of our VPN client PGP 7.0 announced this week
> > > implements both of those solutions (centrally managed client side
> > > firewalling and the ability to direct all traffic to the secure gateway)
> > > along with mode-config to accomplish these goals without any of the
> > > overhead involved in trying to merge a complex protocol (L2TP) with
> > > another complex protocol (IKE/IPsec).  I can only imagine (and cringe at)
> > > the logistics involved in doing a security code review of both of those
> > > together.
> > > 
> > > 
> > > "CHINNA N.R. PELLACURU" wrote:
> > > > 
> > > > And one more benefit of using L2TP/IPSec is, it can support securing IP
> > > > multicast traffic, atleast over the vpn link. But if you are using native
> > > > IPSec with Mode-config/Xauth, you can't secure multicast traffic, and you
> > > > will need to have atleast GRE to do this.
> > > > 
> > > > I wonder how much benefit we can get out of "L2TP Header Compression".
> > > > 
> > > > Regarding access control, some customers raised concerns that, if a client
> > > > has a VPN link connected to the corporate intranet, and is also directly
> > > > connected to the Internet, then they can't enforce the corporate firewall
> > > > policy on that client, like they can if the client was actually in the
> > > > intranet. There were also concerns raised that if the client is
> > > > directly connected to the Internet, it could be hacked, and won't be able
> > > > to have the same protection that the corporate firewall provides.
> > > > 
> > > > There are atleast two ways of dealing with this:
> > > > 
> > > > 1. put an equalent of the corporate firewall on the client so that it can
> > > > defend itself, and also enforce the corporate firewall policy.
> > > > 
> > > > 2. have a very simple policy on the client that says all traffic will go
> > > > via the VPN link to the corporate network, and the client will accept/send
> > > > nothing else. This would be the true emulation of the Dial-in remote
> > > > access, and this can be acheived naturally using L2TP.
> > > > 
> > > >     chinna
> > > > 
> > > > On Thu, 11 May 2000, Stephen Kent wrote:
> > > > 
> > > > > At 2:54 PM -0700 5/10/00, CHINNA N.R. PELLACURU wrote:
> > > > > >I can't speak for the whole of Cisco, but the way I look at it is:
> > > > > >
> > > > > >Modeconfig/Xauth are being supported as quick hack to get something to
> > > > > >work, and get something to customers, until there is a client that can do
> > > > > >IPSec and L2TP.
> > > > > >
> > > > > >I beleive that it is not our long term vision, to ship Modeconfig/Xauth. I
> > > > > >beleive that Cisco's long term goal is to follow whatever is standardized
> > > > > >in the IPSRA WG, because that's what IPSRA WG is chartered to solve.
> > > > > >
> > > > >
> > > > > That's one view.
> > > > >
> > > > > Another perspective is that L2TP over IPsec represents an effort by
> > > > > Microsoft & Cisco to preserve a joint development investment in L2TP,
> > > > > irrespective of its technical merit in this context :-). If I am
> > > > > 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
> > > > > access controls that are an essential part of IPsec. One needs some
> > > > > means of dealing with bind time connection parameters, but use of
> > > > > L2TP on a continuing basis is an expensive means of achieving this
> > > > > goal.
> > > 
> > > 
> > > -- 
> > > Will Price, Director of Engineering
> > > PGP Security, Inc.
> > > a division of Network Associates, Inc.
> > > 
> > 
> > chinna narasimha reddy pellacuru
> > s/w engineer
> > 
> > 
> 
> chinna narasimha reddy pellacuru
> s/w engineer
> 
> 

 --
Jan Vilhuber                                            vilhuber@cisco.com
Cisco Systems, San Jose                                     (408) 527-0847



Follow-Ups: References: