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

Brian E Carpenter <brian.e.carpenter@gmail.com> Sat, 02 July 2011 12:13 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 703BB11E80E5; Sat, 2 Jul 2011 05:13:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.569
X-Spam-Level:
X-Spam-Status: No, score=-103.569 tagged_above=-999 required=5 tests=[AWL=0.030, 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 X7iM4LjTati1; Sat, 2 Jul 2011 05:13:18 -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 9C14211E80E3; Sat, 2 Jul 2011 05:13:18 -0700 (PDT)
Received: by iwn39 with SMTP id 39so4282402iwn.31 for <multiple recipients>; Sat, 02 Jul 2011 05:13:18 -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=EfuGeDMmPQiqeLPeDo4ns8wzVKys7V45tZUCLApWSQ8=; b=nD9wKw02QwnO8zjlXZUNQGMf6L1f4S0vZEQhEye5T/zFCEeBuRQ9X0Geodj54vAvo0 xalguxet1DawyGjcTlA3JMgCrsEm2xcAZytHlGyvel0s6iqPNusHu7rxtw9lxksC15b0 fx/Hag9coJMTfqdoh3kYJvkqubh+4qVqoYod4=
Received: by 10.42.167.73 with SMTP id r9mr4917146icy.347.1309608798199; Sat, 02 Jul 2011 05:13:18 -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 d8sm4367025icy.21.2011.07.02.05.13.16 (version=SSLv3 cipher=OTHER); Sat, 02 Jul 2011 05:13:17 -0700 (PDT)
Message-ID: <4E0F0B53.2080809@gmail.com>
Date: Sun, 03 Jul 2011 00:13:07 +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: Jari Arkko <jari.arkko@piuha.net>
References: <571B7ACD-26B9-4A46-9791-0EA76134A585@cisco.com> <4E0EE3D8.9040500@piuha.net>
In-Reply-To: <4E0EE3D8.9040500@piuha.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
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 12:13:19 -0000

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

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