[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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: