[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Windows 2000 and Cicsco router interoperability
"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."
That pretty much sums up, what I was trying to say. If you loose
granularity of access control because you are tunneling traffic in L2TP
and you are protecting L2TP with IPSec, we can still enforce access
control outside of the context of IPSec, and let the trust/security flow
from one module in the system to the other. The main benefit here is that
we are leveraging services already provided by other modules in the
system, and don't have to do everything in IPSec.
I think that, this was the main point of contention when we started on
this thread.
If you feel that I am being paranoid of the letter x, I guess you are
paranoid about the L2TP protocol, and the whole myth that
L2TP=Microsoft+Cisco.
chinna
On Tue, 16 May 2000, Stephen Kent wrote:
> 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
>
>
chinna narasimha reddy pellacuru
s/w engineer
Follow-Ups:
References: