Re: [v6ops] A common problem with SLAAC in "renumbering" scenarios

Tom Herbert <tom@herbertland.com> Fri, 22 February 2019 01:13 UTC

Return-Path: <tom@herbertland.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 0DCB0130E7E for <ipv6@ietfa.amsl.com>; Thu, 21 Feb 2019 17:13:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.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 obizI69uefQC for <ipv6@ietfa.amsl.com>; Thu, 21 Feb 2019 17:13:25 -0800 (PST)
Received: from mail-qk1-x732.google.com (mail-qk1-x732.google.com [IPv6:2607:f8b0:4864:20::732]) (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 66DE312D4EF for <6man@ietf.org>; Thu, 21 Feb 2019 17:13:25 -0800 (PST)
Received: by mail-qk1-x732.google.com with SMTP id z13so263648qki.2 for <6man@ietf.org>; Thu, 21 Feb 2019 17:13:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=oyanN724oBkuyAULkKpri2Cd2PUKsuam/ZwQAr7+HmA=; b=Pkua0gt+YcmZjcs6lkKWtIZgMKCS29Gs5WNfK6qEHKVtnwH/xn8zZnglsVJrQmYkis 6REQkc7XArup/Yete/81h9GgGNSFbS1Aj9yXQ1nSr4EfytPPU4Utu3JG1Ll8hOUScctf 5UMMKporw7EbP2E//f7D2lHqFy7edC1KIDreRkcg+uly+e145pKaP+loVzUmsiwi6LUR Nhox0cd9lfU18irR701yWdkjz9VKG1QO4DHdS8VdaaC0DPaSQAkLtsp1Q1Fw0Du01UAc 1TwuvDM8USsRmcluRx8zwOAxEVDjHpmQ2BK8Gu65jQfRQzJO4ACMZehaO1wHKGerxfh9 Ob1g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=oyanN724oBkuyAULkKpri2Cd2PUKsuam/ZwQAr7+HmA=; b=KGIFP/y+2LYhp3+hxQaJ/tAB7bZY6ihtGzjslSuf4bEfE0wDyMy/F1nVLDn4Avvhww bObi4QVIgcMUdXB7OB6EZEv8b1aWrclZDe39nOCgJTTV/9QFAUSwrCn1TgnIWzOCKHXd Nn9iU3TOoWeByAAGdtMN6GlAMrSaDNJ9Difp+by559vqyfumW3twTvSKcJqRT3Nia07q 6jRGKtCUDwZ80niRktxcHMZEv9uQiEKysG79gvSok9oJddqJnf3F1Dn++y6ie/YHmokT hXfNnBdPAK8VfcOw2PbrndWA2gE5CvUGkK9Fffva/elyN1UMxCakm9ax7BVC6+uvOrWl 9oJg==
X-Gm-Message-State: AHQUAuacGNTvATcHjibf5DrbcupA6YDY1Rjhtrx6EDDMhwMVjKjlnPq0 5+zK3desS4O84AWkBodSpqJkv2xTzP/+P+iNzstYHA==
X-Google-Smtp-Source: AHgI3IZb3+sPAgmTIolQ6KUy4o6T3AEpOVcLOhvKnYVfgMda1fHX0YbWe3Glg+gIhboM0bpwgmaRXk46lr9V6G/sRN0=
X-Received: by 2002:a37:a147:: with SMTP id k68mr1135619qke.190.1550798004432; Thu, 21 Feb 2019 17:13:24 -0800 (PST)
MIME-Version: 1.0
References: <6D78F4B2-A30D-4562-AC21-E4D3DE019D90@consulintel.es> <B6E2EC33-EEAF-40D0-AFCC-BDAFA9134ACD@consulintel.es> <20190220113603.GK71606@Space.Net> <28fbc2c305c640c9afb3704050f6e8d7@boeing.com> <20190220213107.GS71606@Space.Net> <019c552eb1624d348641d6930829fd1f@boeing.com> <CAKD1Yr0HBG+rhyFWg9zh0t3mW486Mjx9umjn+CRqAZg4z9r0dg@mail.gmail.com> <20190221073530.GT71606@Space.Net> <CAO42Z2wmB2W52b4MZ2h9sW5E9cQKm-HRjyf--q8C26jezS7LXQ@mail.gmail.com> <a73818d31db7422b99a524bc431b00ed@boeing.com> <CAO42Z2z9-48Gbb_Exf+oWUqDO=axSLpZBtqeDcxkAoFq5OziGw@mail.gmail.com> <CALx6S3624hnGauG1HaSWPMvQw0t2Q5R3gb8W4R8w3kuK7dcrWQ@mail.gmail.com> <D1BACB13-1C00-4E23-A8BC-A669BFE73559@delong.com> <CALx6S37Ya0cRmh-KgOsc+CVJrvV8tbS8pMmzavcYcFTy3UYo6A@mail.gmail.com> <A3A4AF6B-9CFE-4099-8DE5-612E9D3D974D@delong.com>
In-Reply-To: <A3A4AF6B-9CFE-4099-8DE5-612E9D3D974D@delong.com>
From: Tom Herbert <tom@herbertland.com>
Date: Thu, 21 Feb 2019 17:13:13 -0800
Message-ID: <CALx6S36BZ=UhDW-BeG=PxrrgDY3OFz5aPSdzFKj56CPXna87Qg@mail.gmail.com>
Subject: Re: [v6ops] A common problem with SLAAC in "renumbering" scenarios
To: Owen DeLong <owen@delong.com>
Cc: Mark Smith <markzzzsmith@gmail.com>, "Manfredi (US), Albert E" <albert.e.manfredi@boeing.com>, IPv6 Operations <v6ops@ietf.org>, "6man@ietf.org" <6man@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/zKzwtVk49scCaI5P7lblHJTrtWk>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.29
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, 22 Feb 2019 01:13:27 -0000

On Thu, Feb 21, 2019 at 5:04 PM Owen DeLong <owen@delong.com> wrote:
>
>
>
> > On Feb 21, 2019, at 16:18 , Tom Herbert <tom@herbertland.com> wrote:
> >
> > On Thu, Feb 21, 2019 at 3:49 PM Owen DeLong <owen@delong.com> wrote:
> >>
> >>
> >> Mark,
> >>
> >> I agreee with that with one exception. I believe that NAT/IPv4 can
> >> offer better privacy in addressing than IPv6 given current addess
> >> allocation methods.
> >>
> >>
> >> Huh? Random 64 bit numbers are less private than semi-opaque translation of 32 bit numbers?
> >>
> >> In today’s world (where CGN is fortunately still mostly the exception rather than the rule), the
> >> 32 bit public number (mostly) identifies the household on a transient basis.
> >>
> > Owen,
> >
> > Privacy in CGN effectively if the device lives behind a NAT with
> > thousands of user. So if the an external external third party observes
> > two different flows that share the same NAT address, then the observer
> > can not infer that the two flows are sourced form the same device or
> > user.
> >
>
> Sure, but today, CGN is the exception, not the rule… Hopefully it will remain that way for the
> foreseeable future as CGN is really an awful awful thing for the end user.
>
> Also, due to CALEA constraints, most CGN implementations are going to quasi-static port
> reservations per household, so it’s not as private as you think it is. It will raise the bar
> slightly, forcing the third party to track an extra 32 bits per flow (2xport number), but that’s
> about it.
>
Owen,

To be clear, I was not advocating NAT. I was only pointing out that it
has some privacy properties to the extent that even law enforcement
has even expressed concerns about it. For those users for which
privacy is vital, I don't believe it's an adequate solution. If
privacy is essential then I believe we really want single use
untrackable addresses  (see
draft-herbert-ipv6-prefix-address-privacy-00).

Tom

>
> Owen
>