Re: [v6ops] Interesting problems with using IPv6

Owen DeLong <owen@delong.com> Sat, 13 September 2014 03:25 UTC

Return-Path: <owen@delong.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1198A1A02D1 for <v6ops@ietfa.amsl.com>; Fri, 12 Sep 2014 20:25:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.643
X-Spam-Level:
X-Spam-Status: No, score=-2.643 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-1.652, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham
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 GAtbHXZgHvBU for <v6ops@ietfa.amsl.com>; Fri, 12 Sep 2014 20:25:14 -0700 (PDT)
Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id AE2091A02BC for <v6ops@ietf.org>; Fri, 12 Sep 2014 20:25:14 -0700 (PDT)
Received: from [10.5.16.184] ([209.63.144.18]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.2) with ESMTP id s8D3O6gH000684 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 12 Sep 2014 20:24:07 -0700
X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com s8D3O6gH000684
DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1410578647; bh=NRjro0OsnAAy9WwsLPBqXSU9X1w=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=f54w6ougQCyrx4bTnGmRSFEm9xyCbIrXr8DTz77aU+1R/JPrlks2qEdZGKNKai+p2 GkhJZ/NiiAPOT4nmnmpxJqYSUyXyP/j1ibcthu8zgVfy+50TPZ+2/p/8VhCs7g4sII KgaQ1LFQoCTifiNAhgGpcvpeaHzet+/X9OUownSY=
Content-Type: text/plain; charset="windows-1252"
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Owen DeLong <owen@delong.com>
In-Reply-To: <5413A448.2030104@gont.com.ar>
Date: Fri, 12 Sep 2014 20:23:39 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <0E61F8D0-22C6-4E37-93E2-9D9B13254055@delong.com>
References: <1410082125488.85722@surrey.ac.uk> <540CB702.3000605@gmail.com> <20140908183339.GB98785@ricotta.doit.wisc.edu> <540E26D9.3070907@gmail.com> <1410227735.13436.YahooMailNeo@web162204.mail.bf1.yahoo.com> <540ECB9E.9000102@foobar.org> <CAKD1Yr1_sCLHv=D3MeCe47Fa0dxXTXH5B+=wOKpvmEDFkJFiZw@mail.gmail.com> <75B6FA9F576969419E42BECB86CB1B89155AF364@xmb-rcd-x06.cisco.com> <20140909142226.GP15839@angus.ind.WPI.EDU> <101C89B1-019B-4E51-B869-FABC534E6D3D@delong.com> <5413A448.2030104@gont.com.ar>
To: Fernando Gont <fernando@gont.com.ar>
X-Mailer: Apple Mail (2.1878.6)
Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/oMKIyMA8wsiLnzPuhNEQKijr3bI
Cc: v6ops@ietf.org
Subject: Re: [v6ops] Interesting problems with using IPv6
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/v6ops/>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 13 Sep 2014 03:25:16 -0000

On Sep 12, 2014, at 6:56 PM, Fernando Gont <fernando@gont.com.ar> wrote:

> On 09/12/2014 07:33 PM, Owen DeLong wrote:
>> A potential improvement could be if privacy addressing created a
>> persistent random lower 24 bits and only rehashed the upper 40 bits
>> of the suffix with each address rotation. In that way, you’d only
>> have ~2 ND multicast groups per host.
> 
> That would break the sole purpose of privacy addresses. If the lower
> 24-bits are kept the same, an attacker can correlate the activities of a
> node along time.

The purpose of privacy addresses is broken by so many things as to render them an absurd waste in general.

We’ve had this argument before. We’ve agreed to disagree before.

I suppose another viable solution would be to require all privacy addresses to use a common lower 24 bit string. In this way, you’d still have anonymity within the subnet which is all you really get from privacy addresses to begin with.

Owen