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

Re: Windows 2000 and Cicsco router interoperability

> That would be a good point if it was possible.  In the case of PGP 7.0, it isn't.
> 
> Since the personal firewall and VPN client are one product, you can't
> uninstall one or the other, they come as a set.  Configuration options are
> handled centrally, and every single option, setting, rule, etc... can be
> individually locked down by the administrator such that the user is unable
> to change it.  If desired, it can be locked down so hard that the only
> thing the user can do pretty much is click "Connect", enter their
> authentication, and suddenly all their IP traffic goes to the VPN gateway.

Sounds like a well thought out design and based on your last sentence will
do exactly what the paranoid would want it to do.

Regards,
Michael Carney

> 
> 
> Mike Carney wrote:
> > 
> > If I was a suitably paranoid IT person who is about to deploy VPN clients,
> > the fact that the each client also had a personal firewall would not
> > be enough to turn my crank. Even if I personally configure each and
> > every client, the capability for my employees to disable or reconfigure
> > said firewalls makes me nervous.
> > 
> > What I would like to see is a non-bypassable configuration option
> > whereby when the VPN is enabled, ALL IP traffic goes out over the
> > VPN and is subsequently subjected to our corporate perimeter policy.
> > And all NON Protocol 50/51 traffic is blocked as well as non IP traffic.
> > 
> > And while this scheme has certain vulnerabilities as well, it strikes
> > me as less vulnerable.
> > 
> > Regards,
> > Michael Carney
> > 
> > > Frankly I like the notion of a personal firewall. I feel empowered, just
> > > by the thought that I have my own personal firewall. I agree with you that
> > > every one should have their personal firewall.
> > >
> > > But, that doesn't really fit into this paradigm of a "dumb client", that
> > > the proponents of modeconfig/xauth are pushing. The client is supposed to
> > > be dumb, and get even it's configuration parameters and phase2 policy, and
> > > if possible it's phase1 policy from the server. The average corporate
> > > executive (road warrior) is supposed to be so dumb that he is not expected
> > > to do anything other than powering up his laptop, and clicking a few
> > > icons. So, we push yet another policy to the client: the firewall policy.
> > > And if the "dumb client" wants to support securing multicast traffic, then
> > > we setup a logical GRE tunnel interface on the client, and push routing
> > > policy onto the client. So, we the client will be a dumb and powerful!
> > >
> > >     chinna
> > >
> > > On Fri, 12 May 2000, Mason, David wrote:
> > >
> > > > Every client should have a personal firewall regardless of
> > > > whether it's PPP+L2TP+IPSEC+IKE or just IPSEC+(MODECFG+IKE)
> > > > since they'll often be connecting directly to the Internet
> > > > without going through the corporate firewall (no VPN).
> > > > -dave
> > > >
> > > > -----Original Message-----
> > > > From: CHINNA N.R. PELLACURU [mailto:pcn@cisco.com]
> > > > Sent: Thursday, May 11, 2000 10:10 PM
> > > > To: Will Price
> > > > Cc: Stephen Kent; ipsec@lists.tislabs.com
> > > > Subject: Re: Windows 2000 and Cicsco router interoperability
> > > >
> > > >
> > > > 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
> > > >
> > >
> > > chinna narasimha reddy pellacuru
> > > s/w engineer
> > >
> 
> -- 
> 
> Will Price, Director of Engineering
> PGP Security, Inc.
> a division of Network Associates, Inc.
> Direct  (408)346-5906
References: