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

Brian Weis <bew@cisco.com> Fri, 01 July 2011 23:57 UTC

Return-Path: <bew@cisco.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 2C6001F0C4B; Fri, 1 Jul 2011 16:57:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
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 mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id Ux6ykXrGq1aQ; Fri, 1 Jul 2011 16:56:59 -0700 (PDT)
Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com []) by ietfa.amsl.com (Postfix) with ESMTP id DBA251F0C4C; Fri, 1 Jul 2011 16:56:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=bew@cisco.com; l=3062; q=dns/txt; s=iport; t=1309564594; x=1310774194; h=from:content-transfer-encoding:subject:date:message-id: cc:to:mime-version; bh=ccZjSCWGySwoyTLUR5HTBWfnnZg+x+w0Sa/ZubCvvXU=; b=Vt6BMwd7yoB/BCQSgMz7qoPJnege0COiIrg8T/7dCZyRh/xQrJPf5+nN fMy3KSCeZH1kcm4RLyccTew0TTxOaueRW2sXhDtAEVq88Q1CD/f0E6kDK +Uy+RVv1Pcp5AxlTOCwbZ9yVv/Skm13ffcTWe44EliUyRhhymQiYOpoaY 0=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av0EADxeDk6rRDoH/2dsb2JhbABSqAF3rGOdXoYyBIc+inSQUQ
X-IronPort-AV: E=Sophos;i="4.65,461,1304294400"; d="scan'208";a="473777489"
Received: from mtv-core-2.cisco.com ([]) by sj-iport-1.cisco.com with ESMTP; 01 Jul 2011 23:56:34 +0000
Received: from dhcp-128-107-147-1.cisco.com (dhcp-128-107-147-1.cisco.com []) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p61NuY9D003231; Fri, 1 Jul 2011 23:56:34 GMT
From: Brian Weis <bew@cisco.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Date: Fri, 1 Jul 2011 16:56:33 -0700
Message-Id: <571B7ACD-26B9-4A46-9791-0EA76134A585@cisco.com>
To: secdir@ietf.org, iesg@ietf.org
Mime-Version: 1.0 (Apple Message framework v1084)
X-Mailer: Apple Mail (2.1084)
Cc: draft-ietf-6man-flow-ecmp.all@tools.ietf.org
Subject: [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: Fri, 01 Jul 2011 23:57:00 -0000

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.