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

RE: Windows 2000 and Cicsco router interoperability



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
>
>
>
>
>
>



Follow-Ups: References: