Re: Consensus call on adopting: <draft-gont-6man-stable-privacy-addresses-01>

Fernando Gont <fgont@si6networks.com> Fri, 13 April 2012 21:10 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 7982211E810E for <ipv6@ietfa.amsl.com>; Fri, 13 Apr 2012 14:10:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.543
X-Spam-Level:
X-Spam-Status: No, score=-1.543 tagged_above=-999 required=5 tests=[AWL=-0.013, BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069]
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 7Pr7dzRHOZ4f for <ipv6@ietfa.amsl.com>; Fri, 13 Apr 2012 14:10:37 -0700 (PDT)
Received: from srv01.bbserve.nl (unknown [IPv6:2a02:27f8:1025:18::232]) by ietfa.amsl.com (Postfix) with ESMTP id BC8CD11E810F for <ipv6@ietf.org>; Fri, 13 Apr 2012 14:10:36 -0700 (PDT)
Received: from 130.41-14-84.ripe.coltfrance.com ([84.14.41.130] helo=[192.168.102.30]) by srv01.bbserve.nl with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from <fgont@si6networks.com>) id 1SInkj-0006RB-I2; Fri, 13 Apr 2012 23:10:05 +0200
Message-ID: <4F881FFF.5030409@si6networks.com>
Date: Fri, 13 Apr 2012 14:45:51 +0200
From: Fernando Gont <fgont@si6networks.com>
Organization: SI6 Networks
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.28) Gecko/20120313 Thunderbird/3.1.20
MIME-Version: 1.0
To: Tim Chown <tjc@ecs.soton.ac.uk>
Subject: Re: Consensus call on adopting: <draft-gont-6man-stable-privacy-addresses-01>
References: <E7607B61-9889-43A9-B86B-133BD4238BA2@gmail.com> <4F87D245.4000102@gmail.com> <95F65935-A316-4CFB-9A79-9B0AB7E33A10@ecs.soton.ac.uk> <EMEW3|09206087d5a8f81e80ca891498271ae5o3CBbj03tjc|ecs.soton.ac.uk|95F65935-A316-4CFB-9A79-9B0AB7E33A10@ecs.soton.ac.uk>
In-Reply-To: <EMEW3|09206087d5a8f81e80ca891498271ae5o3CBbj03tjc|ecs.soton.ac.uk|95F65935-A316-4CFB-9A79-9B0AB7E33A10@ecs.soton.ac.uk>
X-Enigmail-Version: 1.1.2
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Cc: 6man Chairs <6man-chairs@tools.ietf.org>, IPv6 WG Mailing List <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: Fri, 13 Apr 2012 21:10:37 -0000

Hi, Tim,

Thanks so much for your feedback! Please find my comments inline...

On 04/13/2012 12:37 PM, Tim Chown wrote:
> Extensions.  If I understand it correctly, essentially what you are
> defining is randomised stable-per-prefix public interface
> identifiers, 

Exactly.


> On 3484bis, if stable privacy addresses are alternative public (not
> temporary) identifiers for hosts then is there anything more to say?

Not that I can think of.


> Note that RFC4941 temporary addresses can also be stable, in that
> they do not change if the host stays on the same network; the
> specification only says identifiers SHOULD be regenerated at some
> defined interval.

Two things:

* If you do RFC 4941 but do not change the addresses over time (e.g. as
Windows does for their stable addresses), then you can be tracked
exactly in the same way as with MAC-based addresses. Such addreseses
mitigate only host-scanning attacks (i.e., they are unpredictable), but
since there's a constant identifier used across networks, tracking is
still possible. -- So at the time you implement RFC 4941 without
regenerating the addresses over time, they are not *privacy* extensions
anymore :-)

* IMO, it is a bit of a strech to say "RFC4941 temporary addresses can
also be stable", implying that stability is allowed. That would be the
case if "identifiers MAY be generated at some defined interval". But if
it's a SHOULD, and you go against it, you're not fully-compliant with
the specification. ("SHOULD" just means that there are specific cases in
which you're allowed to not follow the recommendation).



> Finally, it would be interesting to know what algorithm Windows uses
> to generate its identifiers; they are randomised, public and stable.
> I had thought they were based on the prefix, but Fernando's tests
> suggest not.

Dave Thaler commented on this one during the 6man wg meeting at IETF 83:
They do RFC4941, without changing the addresses over time. Hence, the
identifiers are constant across networks.

This means that they mitigate host scanning attacks, but as noted in
draft-gont-6man-stable-privacy-addresses-01 they are still subject to
host-tracking.

Thanks!

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