[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Windows 2000 and Cicsco router interoperability
This is true, however, more important than the client having a firewall is
having it enforce a policy commensurate with the security policy of the
corporate network. If there is no methodology for ensuring that the client
can not be (or is not already) compromised before a tunnel to the corporate
network is established, the utility of the personal firewall is effectively
zero.
At the least, not allowing split tunnels, is somewhat effective, but the
residual effect of routing all remote users Internet traffic through the
corporate firewalls/gateways may not be desirable.
-James
--------------------------------------------------------
The content of this message may contain private views
and opinions which do not constitute a formal disclosure
or commitment unless specifically stated.
--------------------------------------------------------
> -----Original Message-----
> From: owner-ipsec@lists.tislabs.com
> [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Mason, David
> Sent: Friday, May 12, 2000 6:44 AM
> To: 'CHINNA N.R. PELLACURU'; Will Price
> Cc: Stephen Kent; ipsec@lists.tislabs.com
> Subject: RE: Windows 2000 and Cicsco router interoperability
>
>
> 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
>
References: