Re: Is TS agreement necessary?

["Chinna N.R. Pellacuru" <pcn@cisco.com>]

On Thu, 4 Apr 2002, Stephen Kent wrote:

> At 11:48 AM -0800 4/4/02, Chinna N.R. Pellacuru wrote:
> >On Thu, 4 Apr 2002, Stephen Kent wrote:
> >
> >>  At 6:54 PM -0800 4/3/02, Chinna N.R. Pellacuru wrote:
> >>  >On Wed, 3 Apr 2002, Stephen Kent wrote:
> >>  >>  Your descriptions have not yet convinced me, and others, that
> >>  >>  interoperability is achieved and at no loss of access control
> >>  >>  granularity.
> >>  >>
> >>  >
> >>  >I think we had a similar debate on this list about the access control
> >>  >granularity of IPsec, and what are the concequences of loosing it, when
> >>  >L2TP+IPsec (L2TP secured with IPsec to provide remote access) was
> >>  >discussed on this list a couple of years ago.
> >>  >
> >>  >First, we are talking about a peer that has successfully authenticated to
> >>  >us in phase1(or its equivalent), and we have successfully identified who
> >>  >the peer is. What is the point in someone strongly authenticating to us,
> >>  >and then attacking us using a secured channel which has traffic source
> >>  >authentication?
> >>
> >>  the answer is that merely because we have authenticated a peer, that
> >>  does not mean that we are prepared to allow that peer to have
> >>  unconstrained access to all resources behind the IPsec
> >>  implementation, whether the implementation is at an enclave perimeter
> >>  or a single machine.  what if one of the peers is an organization
> >>  that has just been compromised and thus traffic from that site is no
> >>  longer "friendly?" the point is that authentication and authorization
> >>  are distinct aspects of security and IPsec makes provisions to
> >>  support both, at variable granularities.
> >
> >Yes, all deployments should run a firewall and IDS even on traffic that
> >was IPsec secured. No one should be under the assumption that just because
> >some traffic was secured by IPsec, it is safe. So, all IPsec protected
> >traffic should be subjected to rigorous firewall and IDS if people want
> >serious security.
>
> You have not provided any rationale for this statement.  Unless you
> are assuming an IPsec implementation that is not making use of the
> access control facilities, your reasoning is not at all obviuous.

OK. Let me take this oppurtunity to describe what I think a firewall and
an Intrusion Detection System(IDS) should be able to do:

Firewall- a device that does access control based on certain parameters.
Parameters are what service (HTTP, Telnet, etc) and also parameters like
direction of traffic, in/out etc. The list of parameters is very
extensive.

A stateless firewall, as the name suggests does access control based on
the parameters, in a stateless way. There used to be some stateless
firewalls that were being sold a long time ago, and are obsolete and
deemed useless now. Some of the reasons for stateless firewalls becoming
obsolete are:

- statefull firewalls are orders of magnitude better than stateless
firewalls in terms of security, because to prevent a large class of
attacks, you need to maintain some state.

- stateless firewalls are harder to configure, and manage because all the
policies are statically determined, and cannot maintain any state. A
statefull firewall can do Context Based Access Control (CBAC), and much
easier to deploy. The policy could be as simple as allow only traffic that
is initiated from the inside. So, a "hole" is "poked" in the firewall for
all traffic that is initiated from the inside. There are "drop-in" (zero
config) implementations of statefull firewalls.

Intrusion Detection System (IDS) - detects any kind of malicious activity.

The different classes of malicious activities are:

- reconnaissance activity: Trying to find the network toplogy, what
servers are running on which machines, what OS(vendor, version) each of
the machine is running, what server implementation (vendor, version) is
being used. Based on that information, the attacker can pick an attack
that he is sure will work.

- Denial of Service (DOS) attacks: TCP SYN flooding, IP fragment based,
simple UDP, ICMP flooding, and the worst case Distributed DOS (DDOS),
where the typical number of attack machines involved are upto 200,000.
Blue Screen of Death (BSOD).

- Gaining control and stealing/destroying data etc.

The number of attack signatures taht can soley rely on IP source and IP
destination is negligible. There are upto 500 signatures that the Cisco
IDS solution implements, and some of the signatures are extremely CPU
intensive, because most of the algorithms for identifying an attack are
heuristic.

So, in the grand scheme of things, stateless firewall capability is
actually tending towards not having anything at all.

If you want to do all this in IPsec, then everything will just grind to a
halt. The specialized firewall and IDS boxes are built from the ground up,
designed to do the specific job of a firewall and IDS. Bundling IPsec and
firewall implementation on an end host does not mean that we can do that
in all cases. It does not scale. In order to identify DDOS attacks, the
whole network traffic needs to be considered, and the DDOS pattern needs
to be picked up by looking all the traffic on the network.

>
> >If you hold the above thought, I'll digress a bit here. By the virtue of
> >the attack traffic being secured by IPsec, which has traffic source
> >authentication, it is much easy to react to an attack, because we know
> >with strong cryptographic certainity where the traffic is coming from.
> >There was a scheme that someone was proposing to use IPsec to counter DDOS
> >attacks, based on this premise. This paragraph is a bit of digression from
> >the debate at hand.
>
> I agree that with authenticated traffic sources we're better off.
>
> >  > >Secondly, isn't access control and intrusion detection much more than
> >  > >looking at src/dst IP address, transport protocol and port? Yes, IPsec
> >>  >provides limited access control, but how many deployments deem the access
> >>  >control provided by IPsec sufficient, and not run Firewalls and IDS
> >>  >systems, on all traffic, including the traffic that arrived/sent on IPsec
> >>  >tunnels. The limited access control provided by IPsec may sometimes even
> >>  >be regarded as a false sense of security, if people are not running a
> >>  >firewall/IDS on the traffic that is protected by IPsec. We often see IPsec
> >>  >and firewalls bundled as a single product, because if you want serious
> >>  >access control and IDS, you should be running a firewall.
> >>
> >>  Access control and IDS can be effected at various layers in the
> >>  protocol stack. it is desirable to be able to enforce access control
> >>  at more than one layer and when doing this it is often appropriate to
> >>  distribute the enforcement to different devices, consistent with the
> >>  characteristics of each device. In the case of access controls based
> >>  on IP layer data, an IPsec implementation is an ideal location to
> >>  enforce such controls, consistent with the secure binding of
> >>  authentication data to the traffic, based on the SA via which the
> >>  traffic was received (looking) at this from a receiver's
> >  > perspective).  Transport layer controls might be enforced elsewhere,
> >>  but, as with firewalls, it generally is convenient to perform the
> >>  enforcement at the same place and at the same time because of the
> >>  proximity of the header info. Also, if access controls for these two
> >  > closely related layers are enforced at different points in the
> >>  system, there is a need for closer coordination of the management of
> >>  the access control databases at those different points.
> >>
> >>  I think the comments re IDS are irrelevant here. IPsec includes no
> >>  IDS provisions and we're not debating that functionality.
> >>
> >>  With regard to firewalls, IPsec already provides the functions of a
> >>  stateless packet filtering firewall, so putting another one behind an
> >>  IPsec device would be redundant. If we enhance IPsec to provide
> >>  stateful packet filtering, still at the IP and transport layers, then
> >>  the range of redundant configurations is even bigger. I agree that an
> >>  IPsec device is not a substitute for an application later proxy
> >>  firewall, but your comments above do not specify what flavor of
> >>  firewall you are referring to, so it's hard to tell what argument you
> >>  are making. If one bundles IPsec and a firewall as a single product,
> >>  then a vendor has flexibility in offering the IPsec access controls
> >>  within that product; there is no need for redundancy, a topic we have
> >>  discussed many times in the past.
> >
> >Although it is desirable to enforce access control at more than one layer,
> >it is not desirable to have layer violations. If IPsec wants to do access
> >control, it should only rely on fields in the IP header, which are limited
> >to IP source and destination address and protocol. IPsec should NOT rely
> >on fields in the trasport layer headers like source and destination ports.
> >I strongly object to this layer violation. I am profoundly concerned about
> >the the degeneration of the IP stack due to all the layer violations, and
> >we must avoid them. All the layer violations pollute the implemenations,
> >and greatly reduces performance.
>
> If you strongly object to layer violations, then your employer should
> never  offer "routers" that modify the TOS bits which were defined
> for end system use only (until we changed the definition), nor which
> try to classify traffic for diffserv purposes based on examining
> transport headers, and you should definitelu stop selling routers
> that implement NAT!
>
> I too am a big fan of layering, but firewalls often operate at
> multiple layers and decided long ago that there were good reasons
> (some of which I cited above) for providing firewall-style access
> controls in IPsec.

Stateless firewall-style access controls in IPsec are almost useless. We
should stop claiming that in the best interest of the user community. If
you are a big fan of layering, just go with your gut insticnt, if you
don't want to listen to me, just for this time.

>
> >IPsec should limit the packet filtering functionality to only fields in
> >the IP header.
> >
> >In IPv6, even the protocol information is not available most (99.99%) of
> >the time in the IPv6 header. We need to traverse the all the extension
> >headers to get to the transport layer header and even to find out what the
> >transport layer protocol is. So, even the transport layer protocol
> >information isn't easily accessable in IPv6. This is a big drag on the
> >IPv6 IPsec implementations and effect the performance immensely, if we
> >need to do access control on the transport layer protocol information
> >also. Even if the transport layer protocol information is in IPv6
> >extension header somewhere, it is not available in the IPv6 header almost
> >all the time. So, why not get rid of that requirement too? Afterall the
> >goal of IPv6 was to limit the intermediate gateways to have to look at
> >only the IPv6 header, and as little as possible of the extention headers.
> >
> >We will end up with only having to do packet filtering based on IP source
> >and IP destination address or take an enormous hit in performance if we
> >require that even the transport protocol needs to be considered.
>
> Yes, in the IPv6 environment it takes more effort to locate and
> process transport layer headers, but the extent of the performance
> impact will be a function of system design, just as it always is.
>

It tremendrously effects scalability and performance. If we don't have to
do it, we get a big jump in what data rates can be sustained. Afterall
that is the whole idea of IPv6 trying to restrict what fields intermediate
routers need to bother about. End hosts or small systems are not effected
by it very much, I agree.


> >  > >If an IPsec tunnel can be implemented in an interoperable manner to look
> >  > >like a virtual point-to-point link, it can have a lot of benefits. The
> >  > >IPsec secured virtual point-to-point link can be made visible to the
> >>  >routing protocols, and we can run routing on that link to automatically
> >>  >get the resiliency and all the other benefits provided by routing. No need
> >>  >to run keepalives or DPDs, which only provide information of connectivity
> >>  >to the IPsec gateways, and provide no information about the connectivity
> >>  >to the traffic destination. We can route multicast traffic across the
> >>  >point-to-point link too. Yes, we loose the limited access control that
> >>  >IPsec provides, but any serious deployment would not soley depend on the
> >>  >access control provided by IPsec.
> >>
> >>  We obviously differ in our views of whether the access controls
> >>  provided gy Ipsec are "limited" or not, and thus whether removing
> >>  them entirely, as you suggest, and substituting a simple IP layer
> >>  encryption and integrity service would be a good idea.
> >>
> >
> >Access control in IPsec should be limited to ideally only the IP source
> >and destination addresses, and may be to the transport layer protocol in
> >IPv4. I strongly object to any layer violations and hence limit the access
> >control functionality of IPsec. Upper layers can implement their access
> >control mechanisms with the full context available in those layers, and
> >IPsec should not to do the job of access control for the upper layers too.
> >It is redundant, inefficient, confusing and hard to manage if one layer
> >is trying to do the job of all the layers.
>
> see comments above. nothing you said here adds anything to your
> earlier comments.
>

I think I tried to articulate what I think a firewall and IDS is supposed
to do, and why I feel the stateless firewall functionality that IPsec
provides is useless.

> >  > >Isn't the simplicity derived from not having to negotiate traffic
> >>  >selectors in a key management/establishment protocol and not having to do
> >>  >the job of routing (DPD/Keepalive) and other benefits mentioned above
> >>  >worth sacrificing the limited access control provided by IPsec?
> >>
> >>  No.
> >>
> >>  Steve
> >>
> >
> >We should get rid of layer violations. The limited access control provided
> >by just looking at IP source and IP destination should be optional,
> >because it is very limited in nature, and upper layers have more context
> >about the user information etc, and can enforce a much rigourous access
> >control. By claiming access control in IPsec, I think it is creating a
> >false sense of security in the user community, and it is better if we can
> >acknowledge that the access control provided by IPsec is infact limited,
> >and people should run a real firewall if they are serious about access
> >control.
>
> I'll make a deal. You get cisco to stop selling products that violate
> layers in precisely the fashion you describe, a subset of which I
> gave as examples above, and I'll reconsider what I think is
> appropriate for IPsec security functionality.
>
> Steve
>

People do layer violations at their own peril. IETF should not try to
recommend that. It should be optional at the worst.

    chinna

chinna narasimha reddy pellacuru
s/w engineer