Re: [secdir] Secdir review of draft-ietf-6man-flow-ecmp-03

Brian E Carpenter <brian.e.carpenter@gmail.com> Tue, 05 July 2011 19:25 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 ECED921F8A14; Tue, 5 Jul 2011 12:25:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.576
X-Spam-Level:
X-Spam-Status: No, score=-103.576 tagged_above=-999 required=5 tests=[AWL=0.023, 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 Q2ZDiEJkvNgD; Tue, 5 Jul 2011 12:25:59 -0700 (PDT)
Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1E28B21F8A13; Tue, 5 Jul 2011 12:25:59 -0700 (PDT)
Received: by iwn39 with SMTP id 39so6766638iwn.31 for <multiple recipients>; Tue, 05 Jul 2011 12:25:58 -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=VaoWdqde2z5pnpPUNUaytqghleKTPywOdWR4PY2fx74=; b=btm2D33yFwhuM+pZhNLpvnJ8sHv/42smyc7IrjZYzDNdSRrWnsTspmqLlB62wvUNeM vC6gdb0bcSrYu6hPUEcJHFEb2lshftHaG1VAz2aKrmSKMa9BmVXniRQGk5iyrjr+hmPI grPOcftmdggqvIsoXtQXUDpKvmo5sDgm/tGVM=
Received: by 10.42.155.70 with SMTP id t6mr7127690icw.405.1309893958633; Tue, 05 Jul 2011 12:25:58 -0700 (PDT)
Received: from [10.255.25.118] (74-95-74-1-Indianapolis.hfc.comcastbusiness.net [74.95.74.1]) by mx.google.com with ESMTPS id j7sm7903241icq.14.2011.07.05.12.25.56 (version=SSLv3 cipher=OTHER); Tue, 05 Jul 2011 12:25:57 -0700 (PDT)
Message-ID: <4E13653F.5090707@gmail.com>
Date: Wed, 06 Jul 2011 07:25:51 +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: Brian Weis <bew@cisco.com>
References: <571B7ACD-26B9-4A46-9791-0EA76134A585@cisco.com> <4E0EE3D8.9040500@piuha.net> <4E0F0B53.2080809@gmail.com> <7CDA80AB-6144-4449-86AB-5F659AD97243@cisco.com>
In-Reply-To: <7CDA80AB-6144-4449-86AB-5F659AD97243@cisco.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Cc: draft-ietf-6man-flow-ecmp.all@tools.ietf.org, Jari Arkko <jari.arkko@piuha.net>, iesg@ietf.org, secdir@ietf.org
Subject: Re: [secdir] Secdir review of draft-ietf-6man-flow-ecmp-03
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: Tue, 05 Jul 2011 19:26:00 -0000

On 2011-07-06 06:22, Brian Weis wrote:
> Hi Brian C,
> 
> On Jul 2, 2011, at 5:13 AM, Brian E Carpenter wrote:
> 
>>> If the attacker can provide all of the inputs, and it knows the tunnel
>>> endpoint flow label calculation, then there doesn't seem to be any unpredictability. 
>> That's correct, and means that if you are concerned about this risk,
>> there needs to be an obfuscation step in the hash algorithm.
> 
> Right, but obfuscation is kind of a loaded word. Adding an input to the hash algorithm that the attacker is unlikely to guess will mitigate the risk, and this is probably what you meant.

Yes, I agree and that really belongs in the 3697bis draft, whose Last Call is
running a bit behind this one. I will come up with some wording before the
I-D cutoff.

     Brian

> Brian Weis 
> 
>>> (The I-D says to see [I-D.ietf-6man-flow-3697bis] for further discussion 
>>> of this threat. I can't seem to find it, but if it's there simply pointing 
>>> to that discussion would be fine too.)
>> I think it would be better to include any additional wording in 3697bis
>> - can we look at this when we get the security review of that draft?
>> I think Brian W is correct that it needs to be added.
>>
>> Regards
>>   Brian Carpenter
>>
>> On 2011-07-02 21:24, Jari Arkko wrote:
>>> Thanks for your review, Brian. I do agree that the issue that you
>>> mention should be explained better. Authors, please suggest some text.
>>>
>>> Jari
>>>
>>> Brian Weis kirjoitti:
>>>> 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.
>>>>
>>>> Intermediate systems in a routing system perform load balancing of
>>>> packets between a pair of nodes based on values in the packet. This
>>>> I-D defines a safe method by which the IPv6 flow label can be one of
>>>> those values. A necessary condition is that flow labels that have a
>>>> uniform distribution, and the method is restricting to use by IPv6
>>>> tunnel endpoints that are more trusted to apply this method to packets
>>>> they encapsulate.
>>>>
>>>> The Security Considerations section describes a single availability
>>>> attack, which is an attacker able to "selectively overload a
>>>> particular path". I assume that this can happen if the hash
>>>> calculation of the intermediate systems will send too many packets
>>>> down one path and overload it rather than properly load balancing
>>>> across the paths. The values used by the intermediate system come from
>>>> packet headers, and the calculation is deterministic. If the flow
>>>> label computed by the tunnel endpoint is included in the calculation,
>>>> and it is also deterministic, then it seems that an attacker knowing
>>>> the method used by the tunnel endpoint to create flow labels can
>>>> engage in this attack. That is, the attacker crafting packets that
>>>> will result in the tunnel end point computing one or more flow labels
>>>> that cause the intermediate system to include in its hash calculation,
>>>> which results in it routing over the same path. This may be feasible
>>>> for an informed attacker controlling a suitable size botnet. So making
>>>> the tunnel endpoint flow label calculation unpredictable would be
>>>> important to stop this attack.
>>>> The I-D recommends computing the flow label according to
>>>> [I-D.ietf-6man-flow-3697bis], and also states in Section 3 that the
>>>> result "will be hard for a malicious third party to predict". If so,
>>>> then this attack seems mitigated when the recommendation is taken. But
>>>> it would be helpful if the Security Considerations could also mention
>>>> the need for unpredictability, and perhaps also mention how the
>>>> unpredictability is added. As far as I can tell, the recommendation in
>>>> [I-D.ietf-6man-flow-3697bis] is to build the flow label from values in
>>>> the packet being encapsulated, which the attacker itself may have
>>>> generated. If the attacker can provide all of the inputs, and it knows
>>>> the tunnel endpoint flow label calculation, then there doesn't seem to
>>>> be any unpredictability. (The I-D says to see
>>>> [I-D.ietf-6man-flow-3697bis] for further discussion of this threat. I
>>>> can't seem to find it, but if it's there simply pointing to that
>>>> discussion would be fine too.)
>>>>
>>>> Other than clarifying how that attack is mitigated I do not see the
>>>> need for any changes.
>>>> Brian
>>>>
>>>
>>>
> 
>