Re: Meta comment about "3484bis and privacy addresses"

Dominik Elsbroek <dominik.elsbroek@gmail.com> Tue, 27 March 2012 14:44 UTC

Return-Path: <dominik.elsbroek@gmail.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 89BFB21E81E8 for <ipv6@ietfa.amsl.com>; Tue, 27 Mar 2012 07:44:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level:
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
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 pgOon+GqqmF8 for <ipv6@ietfa.amsl.com>; Tue, 27 Mar 2012 07:44:54 -0700 (PDT)
Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9C42C21F898B for <ipv6@ietf.org>; Tue, 27 Mar 2012 07:44:54 -0700 (PDT)
Received: by iazz13 with SMTP id z13so11740819iaz.31 for <ipv6@ietf.org>; Tue, 27 Mar 2012 07:44:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=S/5UrdolacFmfBJJ1VaH+hxlS8P1sOezUsd2r3OSHVg=; b=UbYxcP5zu+YZDKYizKeU+djRZFR+l9gXjzBG1ZebiXXwAMf9XwKSSBYsryvJDupK1z 8njwZGiiW+gbbZ6ovloAL8nWcnZ/ZQ/DSgqgAmOAXC3sNxIJAHSq+pEdS4sFlq2ndvgD zPaE+JPa5yMBP5c/tJy8ZJdlvGK6RGCKOS25Baxs7BQCHW0CnM75anUGPcCY1GG+47DR NosZv4ZxWXamRaEUdAKSmWZv6k2/Z0A8KJijLgEKlBMZ674W3U9/dwdPJKPeejsUrbkY em2FsxEVtSgXs1L9ER5OoIX0T8XtUzylsqqn7tAcNCPmaykhGkMUYpJ5WC1qEXbFjs5z QS0Q==
MIME-Version: 1.0
Received: by 10.50.77.201 with SMTP id u9mr2013306igw.21.1332859493481; Tue, 27 Mar 2012 07:44:53 -0700 (PDT)
Received: by 10.50.33.74 with HTTP; Tue, 27 Mar 2012 07:44:53 -0700 (PDT)
In-Reply-To: <4F71B938.7030300@si6networks.com>
References: <4F71B938.7030300@si6networks.com>
Date: Tue, 27 Mar 2012 16:44:53 +0200
Message-ID: <CAAVMDnUNZ5GGc08WY+AMr2QuxksyRjw+D-GL6qcw-L-v0w+nkQ@mail.gmail.com>
Subject: Re: Meta comment about "3484bis and privacy addresses"
From: Dominik Elsbroek <dominik.elsbroek@gmail.com>
To: Fernando Gont <fgont@si6networks.com>
Content-Type: text/plain; charset=ISO-8859-1
Cc: "ipv6@ietf.org" <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, 27 Mar 2012 14:44:55 -0000

Hi Fernando,

since I got confused on the discussion in the plenary this morning: I
think we have to consider that having a temporary address like defined
in RFC 4941 does not prevent from or even mitigates the scanning
problem mentioned this morning in discussion. Scanning MAC-address
derived addresses on hosts using privacy extension keeps possible and
feasible since the privacy address is only an additional address. The
address derived by the MAC address is still reachable and a valid
address (like a have just tested on my macbook just to be sure). Thus
it is still possible to scan an IPv6 network by iterating over the
changing 24 bits.

So I don't agree with the sentence: "Clearly, temporary addresses can
help reduce the attack exposure   window, since the lifetime of each
IPv6 address is reduced when compared to that of addresses generated
with the method specified in this document." in
draft-gont-6man-stable-privacy-addresses-00.txt.

The only goal achieved by using a temporary address (_and_ using it)
is privacy in that way, a website, or any other third party service,
cannot track a user also in case of prefix changes. In my opinion
there is no security related reason to use privacy extension.

Cheers,
Dominik



On Tue, Mar 27, 2012 at 14:57, Fernando Gont <fgont@si6networks.com> wrote:
> Folks,
>
> I think that one error in which we have incurred at least in the couple
> of years (myself included) is that we focus our discussion on
> "mac-derived addresses vs privacy addresses" when the question should
> really be about "stable addresses vs. temporary addresses".
>
> Clearly, we don't want any privacy issues (whether temporary or not),
> and we should do something such that all addresses do not have any
> privacy issues. (FWIW, this
> <http://tools.ietf.org/html/draft-gont-6man-stable-privacy-addresses> is
> my proposal to tackle the problem of the privacy issues arising from our
> current "stable" mac-derived addresses).
>
> It is also clear that some folks may be arguing in favor of temporary
> addresses (RFC 4941) for the wrong reasons (albeit understandable):
> because we lack of stable addresses that do not have privacy issues.
>
> So I tend to think that our debate should probably be about "stable vs.
> temporary addresses", but our discussion is kind of blinded by the fact
> that we currently only have "stable but privacy-harmful addresses" on
> one hand, and "temporary and privacy-improved addresses" on the other.
>
> *This* fact is what has turned our discussion into being about "public
> versus privacy address", when it shouldn't: privacy should never be
> compromised.
>
> Thanks,
> --
> Fernando Gont
> SI6 Networks
> e-mail: fgont@si6networks.com
> PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
>
>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------