Last Call Review of draft-livingood-woundy-congestion-mgmt-

Request Review of draft-livingood-woundy-congestion-mgmt
Requested rev. no specific revision (document currently at 09)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2010-08-10
Requested 2010-07-15
Authors Chris Bastian, Jason Livingood, Jim Mills, Richard Woundy, Tom Klieber
Draft last updated 2010-07-30
Completed reviews Secdir Last Call review of -?? by Tero Kivinen
Assignment Reviewer Tero Kivinen
State Completed
Review review-livingood-woundy-congestion-mgmt-secdir-lc-kivinen-2010-07-30
Review completed: 2010-07-30


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.

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