Re: I-D Action: draft-gont-6man-flowlabel-security-02.txt

Fernando Gont <fgont@si6networks.com> Tue, 24 January 2012 04:17 UTC

Return-Path: <fgont@si6networks.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FD9921F860F for <ipv6@ietfa.amsl.com>; Mon, 23 Jan 2012 20:17:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.156
X-Spam-Level:
X-Spam-Status: No, score=-0.156 tagged_above=-999 required=5 tests=[AWL=-0.457, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, MANGLED_OFF=2.3]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2DCWIMVh5umB for <ipv6@ietfa.amsl.com>; Mon, 23 Jan 2012 20:17:22 -0800 (PST)
Received: from srv01.bbserve.nl (unknown [IPv6:2a02:27f8:1025:18::232]) by ietfa.amsl.com (Postfix) with ESMTP id 6961B21F85CE for <ipv6@ietf.org>; Mon, 23 Jan 2012 20:17:22 -0800 (PST)
Received: from [190.48.228.56] (helo=[192.168.0.45]) by srv01.bbserve.nl with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from <fgont@si6networks.com>) id 1RpXot-00068s-Mx; Tue, 24 Jan 2012 05:17:21 +0100
Message-ID: <4F1E30C4.8020408@si6networks.com>
Date: Tue, 24 Jan 2012 01:17:08 -0300
From: Fernando Gont <fgont@si6networks.com>
Organization: SI6 Networks
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.24) Gecko/20111108 Thunderbird/3.1.16
MIME-Version: 1.0
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
Subject: Re: I-D Action: draft-gont-6man-flowlabel-security-02.txt
References: <20120113130238.26417.24991.idtracker@ietfa.amsl.com> <4F1E06DF.2090307@gmail.com> <4F1E1C38.1070901@si6networks.com> <4F1E1FC3.2000206@gmail.com>
In-Reply-To: <4F1E1FC3.2000206@gmail.com>
X-Enigmail-Version: 1.1.2
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Cc: 6man <ipv6@ietf.org>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 24 Jan 2012 04:17:23 -0000

On 01/24/2012 12:04 AM, Brian E Carpenter wrote:

>>> Effectively the equivalent algorithm in RFC 6437 is
>>>
>>>  Flow Label = F(Srce Addr, Dest Addr, Protocol #, Srce Port, Dest Port, Secret Key)
>>>
>>> which is less predictable, even if the port number is not randomized.
>>
>> If the attacker can predict the algorithm in
>> draft-gont-6man-flowlabel-security-02.txt, he knows the IPv6 addresses
>> of the two endpoints, and the secret key. So I don't see what'd be the
>> real improvement of this variant.
> 
> With your proposal, after observing label N, you can (with reasonable probability)
> predict label N+1; you don't need this to be 100% accurate to cause trouble.

If the attacker can *observe* labels, why would he bother to "guess" them?


>> Yes, now that the requirement of uniqueness has been relaxed, collisions
>> are less important... but I don't see what's the "gain" of the modified
>> expression you suggest above.
> 
> That label 4502 will essentially never be followed by label 4503,
> which your method explictly allows (your Table 1). Include the counter in
> the input to the hash function and this problem disappears.

Well, one should clearly state the threat model:
If you're thinking about off-path attackers, then the fact that flow
labels corresponding to the same set (src IP, dst IP) will be
incremental is irrelevant (the attacker knows that the Flow-IDs are a
monotonically-increasing sequence, but does not know where that sequence
is).

If the threat model is that we're concerned about on-path attacker,
then: game over: the attacker will always know the FlowLabel values,
regardless of the algorithm that we use.

That said, and as noted above, it is interesting to offer alternatives.
For example, if you implement the hash-based approach described in my
I-D, the first flow label is "expensive", but the rest are really cheap:
e.g., just add the counter to the value of F() that you have recorded in
the destinations cache. OTOH, randomizing every FlowLabel might be more
expensive.

I personally think that rather than enforcing a single algorithm, we
should offer a set of possible algorithms, and discuss the tradeoffs --
after all, not all implementations need to agree on the same algorithm.

Thanks,
-- 
Fernando Gont
SI6 Networks
e-mail: fgont@si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492