Re: Giving up security & privacy when manually configuring addresses - rfc4291bis text (Re: draft-bourbaki-6man-classless-ipv6-00)

Lorenzo Colitti <lorenzo@google.com> Fri, 09 June 2017 00:20 UTC

Return-Path: <lorenzo@google.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 7C5E8128CD5 for <ipv6@ietfa.amsl.com>; Thu, 8 Jun 2017 17:20:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uPa0eTezWr4j for <ipv6@ietfa.amsl.com>; Thu, 8 Jun 2017 17:20:23 -0700 (PDT)
Received: from mail-vk0-x229.google.com (mail-vk0-x229.google.com [IPv6:2607:f8b0:400c:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 89AD1129B69 for <ipv6@ietf.org>; Thu, 8 Jun 2017 17:20:23 -0700 (PDT)
Received: by mail-vk0-x229.google.com with SMTP id p85so22940523vkd.3 for <ipv6@ietf.org>; Thu, 08 Jun 2017 17:20:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=jthm0fqH7M+4PJMjSXuTDLOEvSN87MmhtN9dehsCuYU=; b=WmiuCbfk3f7YxuXsP3a5o7g5kbvb1tlLzG/3WRJ8ExRbKePqZgIXAmvG6qISVHxTIu LE9UNhin+rZwCLewwfXycgKm2sAnfnKClEa3Qud5wGEXy6MzGR5bcvSS9UGsRogdUiwk q+Vp92Rg8iuw+ZVc97pThWmXoTWnZx9BN96VbC84kaT+okStCxiDK5w7xKUQeuQIn0jq gMj5+T/1amIg2yZB5bHo5f+8MOGKECLTnfypG/ujy1dVwGF4xU2g2CjQY8RANK/OJqtc 40vtm1taWRaV/SGABptrOWKyeApuXarwyn4ndB3KfcX/oCSDR9HfzsO2bceT75AkqT5M H36g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=jthm0fqH7M+4PJMjSXuTDLOEvSN87MmhtN9dehsCuYU=; b=UjK6C8cxx/2am7TbWdVEahOEkzMFMZvp4KdhhGGx8SLZhazZ43PBU6aZOWfTXwg33b wEAjYchubGg7R6K1LKs+vK1qS4YHJ3m925Id4TemdUSXWB/0K1yN11hbXAfU+xsPFClg ekdYS+wBjh52BJAZDXpz/XL1Hk8NHrZot2nBSekV3WQkSjLKGsyS1EoKaaDwWWSRcPFo xj8Z3W1xggRtLXbMBZmrJ5R5ej1xreqquNDDJjFdxy2JTPdtmgiIhccGYWHBbR4+5+OH SbMJ8UQIfakss+VN86m1vMg51FCFmqn38abjDLO5Ikw0jZqOt2xD8fdVLAIpQMG1obRK NNjw==
X-Gm-Message-State: AODbwcCjg3i+r0bjHLpCeJ8fdgz0cuJzweK+SkNfI3owJ36JwPDPylUr Ssbd73yAQKJsJM5sMAynuKDEduA5+y8V
X-Received: by 10.31.210.1 with SMTP id j1mr19766645vkg.144.1496967622447; Thu, 08 Jun 2017 17:20:22 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.31.12.139 with HTTP; Thu, 8 Jun 2017 17:20:01 -0700 (PDT)
In-Reply-To: <bb3abd49-5ddc-076c-64a4-fe5f7dcd47d1@si6networks.com>
References: <CAO42Z2ziUZnK+n2f9N_Xvb5TZBppApXgNSmDsRLxaT1_taLvFw@mail.gmail.com> <4a6969ba-4cd3-ba30-2f3b-9ec4cc3fcf60@si6networks.com> <CAKD1Yr2x_EevJ37NnOg59Xk5+r3YYHmHEQKg_YCCSycuPpBzwA@mail.gmail.com> <bb3abd49-5ddc-076c-64a4-fe5f7dcd47d1@si6networks.com>
From: Lorenzo Colitti <lorenzo@google.com>
Date: Fri, 09 Jun 2017 09:20:01 +0900
Message-ID: <CAKD1Yr2ay5Hn_vdc14jJ7WQbgJzMZ_SE+n1S0ZpYMQ5CoPQ0sg@mail.gmail.com>
Subject: Re: Giving up security & privacy when manually configuring addresses - rfc4291bis text (Re: draft-bourbaki-6man-classless-ipv6-00)
To: Fernando Gont <fgont@si6networks.com>
Cc: Mark Smith <markzzzsmith@gmail.com>, Job Snijders <job@instituut.net>, Erik Kline <ek@google.com>, 6man WG <ipv6@ietf.org>
Content-Type: multipart/alternative; boundary="001a114bc9e261216b05517bef51"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/_GVuwF9LmAHNaDJc_oAj_zJRhaM>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
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: <https://mailarchive.ietf.org/arch/browse/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, 09 Jun 2017 00:20:25 -0000

On Fri, Jun 9, 2017 at 2:17 AM, Fernando Gont <fgont@si6networks.com> wrote:

> > I don't think you have measurements that prove this. You almost
> > certainly can make a statement that there are a number of low-entropy
> > addresses where the top bytes are all zeros, and that those are *likely*
> > statically configured.
>
> Are you assuming that such low-byte addresses are the result of
> automatic configuration? How come?
>

No, what I'm saying is: I don't think you can prove that high-entropy
addresses are *not* the result of manual configuration or DHCPv6 address
assignment.

That's the point: there are not a lot of high-entropy addresses. See the
> measurements in RFC7707.


Oh, I see. You're talking about publicly-accessible servers, not clients.

we have similar measurements in RFC7707. However, using the low-order 32
> bits in such way is equivalent to simply setting the low byte of the
> addresses.
>

Equivalent in what way? It provides 4 times more nonzero bits, does it not?


> The point is that when employing manual configuration, addresses always
> have small entropy. Hence employing a lot of bits doesn't buy much,
> because folks simply do not use them for additional entropy.


But they could. If the server had a /64 prefix, then it could store useful
information in the 64 bits. For example, SNI (which sends information in
the clear) might not be necessary any more.