Re: Is TS agreement necessary?

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

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.

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.

>
> >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.

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.

>
> >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.

> >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.

    chinna

chinna narasimha reddy pellacuru
s/w engineer