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

Brian E Carpenter <brian.e.carpenter@gmail.com> Mon, 11 July 2011 20:54 UTC

Return-Path: <brian.e.carpenter@gmail.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E58C11E8130; Mon, 11 Jul 2011 13:54:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.599
X-Spam-Level:
X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KQdm6d5wT-aR; Mon, 11 Jul 2011 13:54:42 -0700 (PDT)
Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id C96C711E8117; Mon, 11 Jul 2011 13:54:39 -0700 (PDT)
Received: by vxi40 with SMTP id 40so4437237vxi.31 for <multiple recipients>; Mon, 11 Jul 2011 13:54:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=993dpZ3mqA6vmypVYVwgRZbr4FNcOi3L+YMEMEsqr7U=; b=DIbZh6g7340vyuYsgzArTkDqmdgAysrIkHOXuGR+PY6gX2kvyQLrj7h+O1hfjJog55 Gd2O8neIb/UNYQ//AT/wC1ZnxEU6mh7Ccu+6NTQUSDY9PGSASQgQl1z6gOjkedKtd/PV aGjaxX92tm2l6F/JcnZ0nK/sj79UARgAQ9kew=
Received: by 10.52.99.131 with SMTP id eq3mr789562vdb.51.1310417679283; Mon, 11 Jul 2011 13:54:39 -0700 (PDT)
Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz [130.216.38.124]) by mx.google.com with ESMTPS id dq5sm8294674vbb.16.2011.07.11.13.54.35 (version=SSLv3 cipher=OTHER); Mon, 11 Jul 2011 13:54:38 -0700 (PDT)
Message-ID: <4E1B6309.4050008@gmail.com>
Date: Tue, 12 Jul 2011 08:54:33 +1200
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Organization: University of Auckland
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: "Richard L. Barnes" <rbarnes@bbn.com>
References: <173612BD-2825-4A21-98C7-CA8BD5639368@bbn.com>
In-Reply-To: <173612BD-2825-4A21-98C7-CA8BD5639368@bbn.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Cc: secdir@ietf.org, draft-ietf-6man-flow-3697bis@tools.ietf.org, IETF Discussion <ietf@ietf.org>, The IESG <iesg@ietf.org>
Subject: Re: [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 20:54:43 -0000

Richard,

Thanks for the review.

On 2011-07-12 01:17, Richard L. Barnes 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 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.  

The difficulty about doing this is that (as the WG wanted) we
have dropped almost all of the discussion of flow state
establishment methods, which is really where these risks arise.
To be frank I think that anything we could add would be
hand-waving.

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

Yes, that makes sense when *not* in the stateless load
distribution scenario.

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

Agreed.

However - the I-D cutoff is upon us, so although I will post an
update in the next few minutes, I'm afraid these changes will
not be made before the IESG telechat.

Regards
   Brian Carpenter