Re: [secdir] Review of draft-livingood-woundy-congestion-mgmt-05

[Jason Livingood <[e-mail]>]

Tero --

Tero - Thanks for the review and feedback.  All of this is now fixed in
draft-livingood-woundy-congestion-mgmt-06, which has been uploaded today and
is now available at
http://www.ietf.org/id/draft-livingood-woundy-congestion-mgmt-06.txt.

I've made specific replies inline below, if you are interested, to confirm
and show the changes.

Thank you,
Jason


On 7/21/10 7:39 AM, "Tero Kivinen" <[e-mail]> wrote:

> I have reviewed this document as part of the security directorate's
> ongoing effort to review all IETF documents being processed by the
> IESG.  These comments were written primarily for the benefit of the
> security area directors.  Document editors and WG chairs should treat
> these comments just like any other last call comments.
> 
> This document describes the congestion management system used by the
> comcast. As such it does not describe any specific protocol, just the
> architecture and management algorithms to manage congestion. The
> security considerations section says
> 
> ----------------------------------------------------------------------
> 12.  Security Considerations
> 
>    It is important that an ISP secure access to the Congestion
>    Management Servers and the QoS Servers, as well as QoS signaling to
>    the CMTSes, so that unauthorized users and/or hosts cannot make
>    unauthorized changes to QoS settings in the network.  It is also
>    important to secure access to the Statistics Collection Server since
>    this contains ISP-proprietary traffic data.
> ----------------------------------------------------------------------
> 
> and as such it seems to list the most obvious security threats i.e.
> the actual protocols run between the different nodes and that those
> protocols needs to be secured, altought I would not consider
> protecting the ISP-proprietary traffic data as the most important
> reason why statistics collection server access needs to be secured.
> The privacy issues (i.e from that statistics data it might be possible
> to find out who is making connections to where) and ability to protect
> against feeding false statistics information is more important than
> protecting ISP-proprietary traffic data.

That is a very good point and was an oversight on my part.  I have revised
the section as follows at the bottom of this email.  I have also explained
in there what the IPDR record stores, which is just bytes sent and bytes
received, over a given interval of time.  Thus there is not
source/destination data, etc.

> There is no description what happens to the statistics data after the
> inspection interval, i.e. whether it is stored for long time or
> whether it is immediately deleted. Getting access to statistics data
> later might allow all kind of traffic analysis etc and the document
> does not describe on what granularity the actual statistics are
> collected so the traffic analysis done afterwards might offer quite
> lot information. It should be enough to collect only per "cable modem"
> statistics, i.e. remove actual TCP flow or connection information from
> the statistics (not sure if that is done or not), and for the
> congestion management reasons it should be enough to keep only the
> last n minutes worth of statistics.

This is correct and is fact what IPDR data is restricted to collecting (in
the stats collection server).

Here's what I now have.  Please do advise if you wish additional changes or
clarifications and I will make them ASAP.

<start>

Security Considerations:

It is important that an ISP secure access to the Congestion Management
Servers and the QoS Servers, as well as QoS signaling to the CMTSes, so that
unauthorized users and/or hosts cannot make unauthorized changes to QoS
settings in the network.

It is also important to secure access to the Statistics Collection Server
since this contains IPDR-based byte transfer data which considered private
by end users on an individual basis. In addition this data is considered
ISP-proprietary traffic data on an aggregate basis. Access to the Statistics
Collection Server should also be secured so that false usage statistics
cannot be fed into the system. It is important to note that IPDR data
contain a count of bytes sent and bytes received, by cable modem MAC
address, over a given interval of time. This data does not contain things
such as the source and/or destination Internet address of that data, nor
does it contain the protocols used, ports used, etc.

<end>