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

Brian E Carpenter <brian.e.carpenter@gmail.com> Mon, 11 July 2011 21:28 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 0BCF321F8EB4; Mon, 11 Jul 2011 14:28:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.71
X-Spam-Level:
X-Spam-Status: No, score=-103.71 tagged_above=-999 required=5 tests=[AWL=-0.111, 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 eKHBa7s2+L1Y; Mon, 11 Jul 2011 14:28:34 -0700 (PDT)
Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0110121F8F63; Mon, 11 Jul 2011 14:28:33 -0700 (PDT)
Received: by vws12 with SMTP id 12so4499537vws.31 for <multiple recipients>; Mon, 11 Jul 2011 14:28:33 -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=0vnKNnbuWJr2NIb/SM1xc5Ox2FrQh9FltesXt75A0XY=; b=lGsxsszBbygpDw7yJTJryM+97VOHDUcK+1rZqjq4LMzRephCq3krdH+QxjsuZLKY5b /wi20c73O3hmrw0WCkuDu65qtyVuUZMFhJWmqsFZbwzyNah8c8wNIvrdHB/1nNzkEslZ Q04RTKFtsa6wCpJhHXYdDpOPylh8JdGQ2g+mQ=
Received: by 10.52.169.1 with SMTP id aa1mr6044249vdc.143.1310419713301; Mon, 11 Jul 2011 14:28:33 -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 w16sm2168429vco.29.2011.07.11.14.28.30 (version=SSLv3 cipher=OTHER); Mon, 11 Jul 2011 14:28:32 -0700 (PDT)
Message-ID: <4E1B6AFC.9050009@gmail.com>
Date: Tue, 12 Jul 2011 09:28:28 +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: Sean Turner <turners@ieca.com>
References: <173612BD-2825-4A21-98C7-CA8BD5639368@bbn.com> <4E1B6309.4050008@gmail.com> <4E1B64B8.2020607@ieca.com>
In-Reply-To: <4E1B64B8.2020607@ieca.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Cc: draft-ietf-6man-flow-3697bis@tools.ietf.org, The IESG <iesg@ietf.org>, secdir@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 21:28:35 -0000

On 2011-07-12 09:01, Sean Turner wrote:
> On 7/11/11 4:54 PM, Brian E Carpenter wrote:
>> 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.
> 
> Plan B, which some people hate, is to write up an RFC editor note (i.e.,
> OLD/NEW) for Jari.

We've got two DISCUSSes to handle too; I think it's going to be
sufficiently complicated to need a new version. Of course, we'll
do what Jari advises...

Regards
   Brian Carpenter