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

Brian Weis <> Tue, 05 July 2011 19:44 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CB04221F87E6; Tue, 5 Jul 2011 12:44:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -110.599
X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id R2pJTbz2829E; Tue, 5 Jul 2011 12:44:36 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 1742521F8667; Tue, 5 Jul 2011 12:44:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=5249; q=dns/txt; s=iport; t=1309895076; x=1311104676; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=hh1uVqK38HpiIml9CdpZ1SjGxJqvn0MdmMBTLZpbZiw=; b=cvRlP1IF/OT3fOUW1eQNRRWXzJDzkpL4XpJnLCDyzlKbYGyPCUrrUpFU 5jhmL/xF5qV2ixEbYs18Jrj3oeZSnu8vHOwjuk0bkT92GYd+7PvtKv4CZ W6X2v+Aezel3362pbapHRHqdZ00vX1wjvOsvTzHLLBKuWPy4MI+leIdgZ s=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av0EAFhpE06rRDoH/2dsb2JhbABNBqgId4h6pHKeC4M7gnsEhz+Kd5BW
X-IronPort-AV: E=Sophos;i="4.65,481,1304294400"; d="scan'208";a="361654106"
Received: from ([]) by with ESMTP; 05 Jul 2011 19:44:35 +0000
Received: from ( []) by (8.14.3/8.14.3) with ESMTP id p65JiZpA014015; Tue, 5 Jul 2011 19:44:35 GMT
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset="us-ascii"
From: Brian Weis <>
In-Reply-To: <>
Date: Tue, 05 Jul 2011 12:44:34 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <>
To: Brian E Carpenter <>
X-Mailer: Apple Mail (2.1084)
Cc:, Jari Arkko <>,,
Subject: Re: [secdir] Secdir review of draft-ietf-6man-flow-ecmp-03
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 05 Jul 2011 19:44:36 -0000

On Jul 5, 2011, at 12:25 PM, Brian E Carpenter wrote:

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

That's fine with me.

Brian Weis

>     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

Brian Weis
Security Standards and Technology, SRTG, Cisco Systems
Telephone: +1 408 526 4796