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