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

RE: Windows 2000 and Cicsco router interoperability

sorry...

Just for the record, I would like to clarify some things:

First of all, if you step back and see, I wasn't the one who dragged you
into this particular sub thread.

Second of all, in whatever context you said the stuff that I quoted, it
still applies to this sub thread, and I guess was referred to first, not
by me.

Third of all, you don't want to get into this debate: point taken.

Lastly, for the good of everyone, let's follow atleast the basic email
etiquette.

    chinna

On Tue, 16 May 2000, Andrew Krywaniuk wrote:

> As Mister T. would say, "Stop you rantin, foo."
> 
> My bottom line (which may have inadvertently appeared at the top of my
> message) was:
> 
> "Sorry, but this has nothing to do with Config Mode or XAuth and very little
> to do with L2TP specifically."
> 
> If you want to turn this into a debate about everything and anything then
> you'll excuse me while I step outside.
> 
> Andrew
> --------------------------------------
> Beauty with out truth is insubstantial.
> Truth without beauty is unbearable.
> 
> 
> > -----Original Message-----
> > From: owner-ipsec@lists.tislabs.com
> > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of CHINNA
> > N.R. PELLACURU
> > Sent: Tuesday, May 16, 2000 2:31 AM
> > 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: