[secdir] secdir review of draft-ietf-6man-flow-3697bis

"Richard L. Barnes" <rbarnes@bbn.com> Mon, 11 July 2011 13:17 UTC

Return-Path: <rbarnes@bbn.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 1329921F8B64; Mon, 11 Jul 2011 06:17:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.599
X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id r+hqyy0DUOD8; Mon, 11 Jul 2011 06:17:35 -0700 (PDT)
Received: from smtp.bbn.com (smtp.bbn.com []) by ietfa.amsl.com (Postfix) with ESMTP id 661D421F8B3D; Mon, 11 Jul 2011 06:17:35 -0700 (PDT)
Received: from [] (port=57724 helo=col-dhcp-192-1-255-156.bbn.com) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from <rbarnes@bbn.com>) id 1QgGMY-000Odn-QN; Mon, 11 Jul 2011 09:17:27 -0400
From: "Richard L. Barnes" <rbarnes@bbn.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Date: Mon, 11 Jul 2011 09:17:24 -0400
Message-Id: <173612BD-2825-4A21-98C7-CA8BD5639368@bbn.com>
To: IETF Discussion <ietf@ietf.org>, The IESG <iesg@ietf.org>, secdir@ietf.org, draft-ietf-6man-flow-3697bis@tools.ietf.org
Mime-Version: 1.0 (Apple Message framework v1082)
X-Mailer: Apple Mail (2.1082)
Subject: [secdir] secdir review of draft-ietf-6man-flow-3697bis
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Mon, 11 Jul 2011 13:17: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 how end hosts and intermediate nodes should populate and handle the IPv6 flow label field.  The document spends a fair bit of time discussing security considerations related to the flow label and its relation to IPsec in particular.  Overall, the document does a thorough job of discussing security considerations, and I don't think there's anything they've clearly missed.  

The only request I would have would be for the authors to add a little more discussion around the "theft of service" threat.  It would be helpful to detail the assumptions/circumstances under which this threat aries -- namely that networks provide resources based on flow label and flow label values are set by end hosts.  Given the risks that this document discusses, it might be worth considering a recommendation that networks SHOULD NOT make resource allocation decisions based on flow labels without some external means of assurance.  Or some similar warning against making resource decisions on a completely unsecured field.

Also, purely from a terminology perspective, I found the phrase "unintended service" confusing and less accurate than the "better service" phrase used in RFC 3697.  It might be better to spell this out: 
... an adversary may be able to obtain a class of service that the network did not intend to provide ...