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 >>>> >>> >>> > >
- [secdir] Secdir review of draft-ietf-6man-flow-ec… Brian Weis
- Re: [secdir] Secdir review of draft-ietf-6man-flo… Jari Arkko
- Re: [secdir] Secdir review of draft-ietf-6man-flo… Brian E Carpenter
- Re: [secdir] Secdir review of draft-ietf-6man-flo… Brian Weis
- Re: [secdir] Secdir review of draft-ietf-6man-flo… Brian E Carpenter
- Re: [secdir] Secdir review of draft-ietf-6man-flo… Brian Weis