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

Re: Windows 2000 and Cicsco router interoperability

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.
Follow-Ups: References: