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

Tero Kivinen <kivinen@iki.fi> Wed, 21 July 2010 11:40 UTC

Return-Path: <kivinen@iki.fi>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost []) by core3.amsl.com (Postfix) with ESMTP id C6DE83A688B; Wed, 21 Jul 2010 04:40:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([]) by localhost (core3.amsl.com []) (amavisd-new, port 10024) with ESMTP id iwZbJCZsNyiu; Wed, 21 Jul 2010 04:40:35 -0700 (PDT)
Received: from mail.kivinen.iki.fi (fireball.acr.fi []) by core3.amsl.com (Postfix) with ESMTP id 43B193A6823; Wed, 21 Jul 2010 04:40:34 -0700 (PDT)
Received: from fireball.kivinen.iki.fi (localhost []) by mail.kivinen.iki.fi (8.14.3/8.14.3) with ESMTP id o6LBdhPq020547 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 21 Jul 2010 14:39:43 +0300 (EEST)
Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id o6LBdgB0019023; Wed, 21 Jul 2010 14:39:42 +0300 (EEST)
X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Message-ID: <19526.56446.871198.214543@fireball.kivinen.iki.fi>
Date: Wed, 21 Jul 2010 14:39:42 +0300
From: Tero Kivinen <kivinen@iki.fi>
To: iesg@ietf.org, secdir@ietf.org
X-Mailer: VM 7.19 under Emacs 21.4.1
X-Edit-Time: 11 min
X-Total-Time: 11 min
Cc: tom_klieber@cable.comcast.com, richard_woundy@cable.comcast.com, chris_bastian@cable.comcast.com, jason_livingood@cable.comcast.com, jim_mills@cable.comcast.com
Subject: [secdir] Review of draft-livingood-woundy-congestion-mgmt-05
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 21 Jul 2010 11:40:36 -0000

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.