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

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!

    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
> 
> > -----Original Message-----
> > From: CHINNA N.R. PELLACURU [mailto:pcn@cisco.com]
> > Sent: 16 May 2000 07:31
> > To: Stephen Kent
> > Cc: Andrew Krywaniuk; 'Jan Vilhuber'; ipsec@lists.tislabs.com
> > Subject: RE: Windows 2000 and Cicsco router interoperability
> > 
> > 
> > Frankly, I don't understand what Andrew is trying to tell me. 
> > His bottom
> > line was:
> > 
> > "IMHO, the idea with the most technical merit is to remove packet
> > filtering from IPsec and make the firewalls IPsec aware. (No, I'm not
> > saying we should rewrite all the specs; that's just the 
> > *ideal* solution
> > in my mind.)
> > 
> > All clear now?"  !!!
> > 
> > Anyway, regarding access control:
> > 
> > How many people beleive that the IPSec access control 
> > mechanism, is going
> > to solve all our access control problems?
> > 
> > If people beleived that IPSec access control mechanism solves 
> > all their
> > access control problems, then I guess we wouldn't have a need 
> > to leverage
> > the access control features that AAA provides. I have seen 
> > customers who
> > are so fond of their AAA infrastructure, that they by-pass IKE
> > authentication by using an equivalent of a global pre-shared key! and
> > totally base their authentication on AAA authentication(and 
> > if you do this
> > via xauth, that doesn't authenticate the DH exchange)! Let's 
> > face it, how
> > many implementations support some form of global pre-shared key?
> > Supposedly the customers wants this badly, and if we dont 
> > provide this,
> > there are implementations that already provide this! 
> > 
> > To investigate the cryptographic binding between a packet 
> > that has been
> > decapsulated, and to which the IPSec selector has to be applied, lets
> > start by how the binding took form at the encapsulation side 
> > in the first
> > place. At the encapsulation side, in the context on an IPSec
> > implementaion, we have a selector based on IP Addresses, protocol and
> > ports. Once a packet matches this selector, it is 
> > encapsulated, and that
> > is all IPSec can truly enforce. Are you saying that this is 
> > all we need to
> > enforce all kinds of access control requirements, and complex policies
> > that any corporation can have?
> > 
> > It's not just the access control folks that see IPSec as a nuance, but
> > there are the Intrution Detection (ID) folks. If we do end to end
> > security, IE from the client of some service to the server of that
> > service, the ID folks don't like that. If we had an IPSec 
> > selector that
> > says all traffic from any TCP high port to port 21 needs to be secured
> > with a certain policy, it doesn't stop a legitimate user/a hacker who
> > gained control of the system to do a simple TCP SYN flood 
> > attack. If this
> > traffic was encrypted using IPSec, then there is no way that 
> > the Intrution
> > Detection System (IDS), is going to detect this. So, these guys have a
> > requirement that all IPSec tunnels should terminate on the 
> > perimeter of
> > the network, so that these guys can do their job. I guess, someone is
> > busy, out there trying to integrate ID into IPSec. xids? Then 
> > we can have
> > xauth, xauthr, xacc, xids, mode config etc... and we can update these
> > documents once every 6 months, to incorporate/support more and more
> > features of these protocols. There are supposedly 6 
> > versions(revisions) of
> > the draft that we already have, and different vendors support 
> > different
> > versions. I leart today that we support version 3 on the cisco router.
> > I guess we are just waiting for some customer to bang on our heads,
> > demanding that they want version 6 because it has a feature x 
> > that version
> > 3 cannot support.
> > 
> >     chinna
> > 
> > On Tue, 16 May 2000, Stephen Kent wrote:
> > 
> > > Chinna,
> > > 
> > > Go back an reread the last few messages I have sent describing the 
> > > difference between what native IPsec does vs. what any 
> > standard says 
> > > about L2TP over IPsec re access control.  That is the basis for my 
> > > comments and those of Andrew.
> > > 
> > > Steve
> > > 
> > 
> > chinna narasimha reddy pellacuru
> > s/w engineer
> > 
> > 
> > 
> > 
> > 
> 

chinna narasimha reddy pellacuru
s/w engineer
References: