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

RE: Windows 2000 and Cicsco router interoperability

When we use L2TP to provide a VPN link to a user into the private network,
it is just emulating as if the user is on the private network. When a user
requests for VPN access, he has to authenticate and prove his credentials
before he can gain access to private network.

Once the user has gained access, he is virtually on the private network.
He can do whatever he would be normally allowed to do when he is
physically on the private network. So, if your private network allows one
user to easily spoof other users, then that is _not_ a failure of the VPN
technology, but your security infrastructure in the private network.

If anyone else other than the authenticated user, is able to gain access
into the private network, then that would be a failure of the VPN
technology.

That is the beauty of layered security architectures. Each layer does it
job, and does it well. No single technology is going to solve all the
problems, and I guess no one wants to put all their eggs in one basket.

    chinna

On Tue, 16 May 2000, CHINNA N.R. PELLACURU wrote:

> I think that is what most of us feel.
> 
>     chinna
> 
> On Tue, 16 May 2000, Chris Trobridge wrote:
> 
> > > From: CHINNA N.R. PELLACURU [mailto:pcn@cisco.com]
> > > Sent: 16 May 2000 17:06
> > > To: Chris Trobridge
> > > Cc: Stephen Kent; Andrew Krywaniuk; 'Jan Vilhuber';
> > > ipsec@lists.tislabs.com
> > > Subject: RE: Windows 2000 and Cicsco router interoperability
> > > 
> > > 
> > > So, you want filtering in IPSec, but you really think the filtering in
> > > IPSec is primitive, and really feel that it should be handled 
> > > elsewhere!
> > 
> > That's not what I wrote!
> > 
> > There already is strongly coupled filtering, if a little primitive, in
> > IPSEC.  It is stronger because the filtering ties up the IP addresses with
> > the SA selector.  This information may be lost if the checking is done
> > later.  The filtering is primitive because the selector rules don't cope
> > with policy like "ftp to host A, pop3 or smtp to host B, or http to hosts C
> > or D" - they allow a limited specification of ranges/wildcards.
> > 
> > I don't think the filtering should be done in IPSEC but it should take
> > account of the IPSEC SA.  I think the principle role of IPSEC should be to
> > provide secure communications between two points - eg provide services for
> > traffic confidentiality, authentication and integrity between two points.
> > Access control etc I think should be elsewhere.
> > 
> > Chris
> > 
> > >     chinna
> > > 
> > > On Tue, 16 May 2000, Chris Trobridge wrote:
> > > 
> > > > The point is that with an IPSEC SA traffic is only allowed 
> > > that matches the
> > > > selector for that SA.  In the access control case this 
> > > means you can enforce
> > > > that anyone who connects via an IPSEC tunnel can only send 
> > > or receive
> > > > datagrams associated with his client address.  This 
> > > prevents him from
> > > > spoofing other clients or hosts and from receiving traffic 
> > > not addressed to
> > > > him.
> > > > 
> > > > The moment you tunnel L2TP through an SA IPSEC loses its 
> > > ability to perform
> > > > this filtering.  Depending on the whether 'extra' work has 
> > > been done, once
> > > > IPSEC processing has been completed the L2TP layer will not 
> > > know via which
> > > > SA a datagram was received, allowing a client to spoof 
> > > other addresses.
> > > > 
> > > > However, I agree with Andrew:  The packet filtering in 
> > > IPSEC is rather
> > > > primitive and would be better provided via an IPSEC aware firewall.
> > > > 
> > > > Chris
> > 
> 
> chinna narasimha reddy pellacuru
> s/w engineer
> 
> 

chinna narasimha reddy pellacuru
s/w engineer
References: