[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Windows 2000 and Cicsco router interoperability
Chinna,
>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?" !!!
It's always a delight to see enthusiastic support for a position from
someone new to this WG. Unfortunately, such enthusiasm is often
unencumbered by knowledge of the WG history, or even technical depth,
on the issue in question. This seems to be such a case.
>
>Anyway, regarding access control:
>
>How many people beleive that the IPSec access control mechanism, is going
>to solve all our access control problems?
That's not the question before us. No single security mechanism is a
panacea. What we are discussing are the relative merits of two
different approaches to effecting a particular type of access control.
>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!
The "features that AAA provides?" AAA is a WG but there are no AAA
standards yet. In fact, the WG drafts so far focusing only on
requirements for the protocols that will be standardized, in the
future. So a reference to what "AAA provides" or to "customers who
are so fond of their AAA infrastructure" appears to be in the future,
optimistic tense.
AAA, when it exists, will encompass authentication as well as access
control. We are focusing on the access control aspect of IPsec.
Global pre-shared keys are an easy way to deploy IKE, but that does
not make them a good idea. It is understandable that customers want
to employ IPsec but also want to minimize the costs of deploying it.
The desire to make use of an existing user authentication
infrastructure is also understandable in this context, but is
separable from the access control mechanisms we are discussing.
>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?
You seem to have trouble distinguishing between access control
enforcement mechanisms and access control policies. The policies
that an IPsec implementation can enforce is limited to the inputs
available to an IPsec implementation. The set of information differs
in native host vs. security gateway implementations. I believe that
we're discussing the latter here.
The 5 primary selectors from the IP and TCP header are the only
inputs available to the SG for enforcement, on a steady state basis.
(I'm omitting the security labels, which are not required for most
implementations, and the user/system IDs that are not employed on a
steady state basis.) However, while RFC 2401 specifies a minimum
access control policy capability for any IPsec implementation, there
is no prohibition against more sophisticated policies being employed,
subject to the constraint that the enforcement parameters can be
translated into these selectors. For example, if one wants to include
time of day as an input to an access control decision, e.g., limiting
the times at which an SA can be established, one could do that
external to the enforcement mechanism.
Certainly one can usefully employ access control policies that are
application specific, and which cannot be enforced at the Internet
layer. However, that does not imply that Internet layer policies and
enforcement mechanisms are irrelevant.
Several folks have suggested that one might choose to enforce access
control at the IP layer, but not in the context of IPsec, e.g., by
passing SA info to a separate firewall for post IPsec checking. If
the firewall is part of the same device as the IPsec module, the this
can be effected in a local fashion that would be consistent with
2401, as the management interface for the combined firewall/SG would
have the necessary properties. However, if the firewall is in a
separate device, I think the required co-ordination would become very
expensive. For example, for outbound traffic, the SG must map
packets to SAs, or know when to create an SA for traffic. If the
firewall does this mapping for the SG, we would need to define a way
to pass the SPD entry info across a wire to the SG from the firewall.
Also, the SG would have to provide a reverse channel to keep the
firewall aware of the SA status, e.g., based on SA timeouts, IKE
failures, etc. Conversely, if the SG maintains the SPD locally (as
is the current practice), then there needs to be a new management
mechanism to synchronize these databases. In the reverse direction,
if the SG no longer performs the post processing access control
checks required by 2401, then it was suggested that we need to define
some means of passing SA data to the firewall. In fact, it appears
that we need to pass quite a bit of data. Just passing the SPI is not
sufficient, unless we introduce a reverse channel from the SG to the
firewall so that the firewall can mirror the SAD (not just the SPD).
Also, how do we pass the SPI or similar data for each packet? Is
there a way to do this without breaking the stack on the firewall,
and what will the performance impact be based on whatever way we find
to pass this info? I'm not saying that one cannot split the access
control checks between an SG and a firewall, but I do think that the
complexity associated with such a split has been underestimated.
>It's not just the access control folks that see IPSec as a nuance, but
"Nuance" vs. "nuisance?"
>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.
This argument is irrelevant to the discussion, but I'll respond
anyway. End-to-end encryption of any form (IPsec, SSL/TLS, SSH, or
S/MIME) interferes with network-based ID, but the host-based ID still
work. Since tests by Lincoln Labs show that network based ID is at
best about 80% effective at detecting KNOWN attacks, whereas the best
host-based systems are much better, I'm not too concerned by this
limitation.
>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.
The threat model you cite re TCP SYN flooding is unduly constrained,
and not very convincing. SYN flood attacks are effected by spoofing
the source address; in the case you cite, we know precisely where the
packets are coming from, and an analysis of the log at the targeted
host would show that, assuming that the packets emerging from the SA
were checked by IPsec to verify the source address consistency.
Your fear of the letter "x" seems to be getting the better of you,
i.e., it's distracting you from the argument at hand :-). There's
nothing to comment on in this last paragraph.
Steve
Follow-Ups:
References: