[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Windows 2000 and Cicsco router interoperability
We could have something fairly crude for this : just 'I want multicast
please'.
Typically, we negotiate IPSEC clients to have wide-open access (dest
0.0.0.0) and
explicit src (the address assigned to the client). If further access
control is
needed, we use secondary access filters under the direction of the policy.
The intent of a wide-open policy is to connect the remote worker as if they
were in
the office. Surely this should include the use of multicast services.
Regards, Steve.
-----Original Message-----
From: Ari Huttunen [mailto:Ari.Huttunen@F-Secure.com]
Sent: Monday, May 15, 2000 9:47 AM
To: CHINNA N.R. PELLACURU
Cc: Mason, David; Will Price; Stephen Kent; ipsec@lists.tislabs.com
Subject: Re: Windows 2000 and Cicsco router interoperability
I fail to understand your point that the proponents of modeconfig/xauth
would be pushing for the paradigm of a "dumb client". A client is no dumber
depending on the method used to assign it any specific configuration
information
like an intranet IP address.
In my view the scenario of an average remote user just "powering up his
laptop and clicking a few icons" is a good state of affairs. We have
a centralized management system that includes modeconfig and distributed
firewalling, so those are definitely not contradictory paradigms.
I do think IPSec WG should define something to enable protection of
multicast traffic. Forcing everyone to use L2TP/IPSec is not a good way,
rather
it's an effort from some vendors to protect their existing investment, like
was already mentioned in here.
Ari
"CHINNA N.R. PELLACURU" wrote:
>
> 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
--
Ari Huttunen phone: +358 9 859 900
Senior Software Engineer fax : +358 9 8599 0452
F-Secure Corporation http://www.F-Secure.com
F-Secure products: Integrated Solutions for Enterprise Security