Re: Is TS agreement necessary?

[Stephen Kent <kent@bbn.com>]

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.

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

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

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

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