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

Jari Arkko <jari.arkko@piuha.net> Sat, 02 July 2011 09:24 UTC

Return-Path: <jari.arkko@piuha.net>
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 A00471F0C53; Sat, 2 Jul 2011 02:24:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.34
X-Spam-Level:
X-Spam-Status: No, score=-102.34 tagged_above=-999 required=5 tests=[AWL=0.259, BAYES_00=-2.599, 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 r3TEKXHxlIo2; Sat, 2 Jul 2011 02:24:44 -0700 (PDT)
Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by ietfa.amsl.com (Postfix) with ESMTP id 97BCF1F0C4B; Sat, 2 Jul 2011 02:24:43 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id B7EFD2CEFF; Sat, 2 Jul 2011 12:24:42 +0300 (EEST)
X-Virus-Scanned: amavisd-new at piuha.net
Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mOlPWxmWuO-N; Sat, 2 Jul 2011 12:24:41 +0300 (EEST)
Received: from [IPv6:::1] (p130.piuha.net [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 93B152CE66; Sat, 2 Jul 2011 12:24:41 +0300 (EEST)
Message-ID: <4E0EE3D8.9040500@piuha.net>
Date: Sat, 02 Jul 2011 11:24:40 +0200
From: Jari Arkko <jari.arkko@piuha.net>
User-Agent: Thunderbird 2.0.0.24 (X11/20101027)
MIME-Version: 1.0
To: Brian Weis <bew@cisco.com>
References: <571B7ACD-26B9-4A46-9791-0EA76134A585@cisco.com>
In-Reply-To: <571B7ACD-26B9-4A46-9791-0EA76134A585@cisco.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: quoted-printable
Cc: draft-ietf-6man-flow-ecmp.all@tools.ietf.org, 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: Sat, 02 Jul 2011 09:24:44 -0000

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
>