Re: Is TS agreement necessary?

[Stephen Kent <kent@bbn.com>]

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.

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

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

>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