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

RE: Windows 2000 and Cicsco router interoperability



And BTW, a global pre-shared key is the key technology that enables
centralized policy management, and the whole idea of the server
downloading policy to the dumb clients via modeconfig!!!!!!!!!!!! And this
supposedly also elimanates the overhead of double authentication, when
doing xauth!!!!!! So, if you think that you already know all the overheads
that these protocols eliminate, please think again.

    chinna

PS: I really don't know which arm of our marketing came up with this idea,
it could be either the inbound marketing or the outbound marketing, or the
product marketing, and we have a marketing organisation in each line of
buisiness. The best part of it is that they supposedly stole this
brilliant idea from the IPSec solution of a competitor. Wonder who that
is...


On Mon, 15 May 2000, CHINNA N.R. PELLACURU wrote:

> 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



Follow-Ups: References: