IETF Logo Mail Archive

RE: A common problem with SLAAC in "renumbering" scenarios

"Manfredi (US), Albert E" <albert.e.manfredi@boeing.com> Sun, 17 February 2019 20:05 UTC

Return-Path: <albert.e.manfredi@boeing.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 30256128701 for <ipv6@ietfa.amsl.com>; Sun, 17 Feb 2019 12:05:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 UnerNi9CVALx for <ipv6@ietfa.amsl.com>; Sun, 17 Feb 2019 12:05:12 -0800 (PST)
Received: from clt-mbsout-02.mbs.boeing.net (clt-mbsout-02.mbs.boeing.net [130.76.144.163]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 91CE3126C7E for <ipv6@ietf.org>; Sun, 17 Feb 2019 12:05:11 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by clt-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id x1HK59Kv005547; Sun, 17 Feb 2019 15:05:09 -0500
Received: from XCH16-01-09.nos.boeing.com (xch16-01-09.nos.boeing.com [144.115.65.234]) by clt-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id x1HK54S5005262 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL); Sun, 17 Feb 2019 15:05:04 -0500
Received: from XCH16-01-11.nos.boeing.com (144.115.66.39) by XCH16-01-09.nos.boeing.com (144.115.65.234) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.1.1591.10; Sun, 17 Feb 2019 12:05:03 -0800
Received: from XCH16-01-11.nos.boeing.com ([fe80::a96c:5d85:1337:4323]) by XCH16-01-11.nos.boeing.com ([fe80::a96c:5d85:1337:4323%4]) with mapi id 15.01.1591.014; Sun, 17 Feb 2019 12:05:03 -0800
From: "Manfredi (US), Albert E" <albert.e.manfredi@boeing.com>
To: Tom Herbert <tom@herbertland.com>
CC: 6man <ipv6@ietf.org>
Subject: RE: A common problem with SLAAC in "renumbering" scenarios
Thread-Topic: A common problem with SLAAC in "renumbering" scenarios
Thread-Index: AQHUxCBHRRM+C8/2XkuG8rODXW4PVqXfllAAgAAFt4CAAAUwgIAAAy4AgAAM9oCAAAQqgP//9njQgADJZQCAAJC5gIAAGd2AgACnDwCAAB9bAIAACEMAgAB46ACAAMeBgIAAm3MAgACgVAA=
Date: Sun, 17 Feb 2019 20:05:03 +0000
Message-ID: <20c80a52c8db4beb8381b21b633bc7f7@boeing.com>
References: <60fabe4b-fd76-4b35-08d3-09adce43dd71@si6networks.com> <CAO42Z2zh7fKAgQJq9aLCTiFoSSsTeGM=pK3gXitg+gcxH=9fhQ@mail.gmail.com> <d38857c2-6e92-91d6-bb5d-d3eeeb61276a@gmail.com> <CAO42Z2yb47OyXk__Sz-kO00pfcBJgLAhff5DF=mpAddR0iCnAA@mail.gmail.com> <2612280f-195a-ae7a-b3b1-9022d9282fa7@foobar.org> <56F813F4-C512-40A9-8A68-1090C76A80F6@consulintel.es> <CAHL_VyCN8kU7qnLOphfGR25-xGBe_p6WeGTkKVXwU5uy5aJ8Dg@mail.gmail.com> <65DB4854-97D2-4C31-A691-2CD93812EF93@consulintel.es> <CAHL_VyCMpCcGkEQu+RV1GRf2QLB-HD0+AOOBV0YhfQ5sbydVzQ@mail.gmail.com> <8CE7A0CD-97D9-46A0-814D-CAF8788F9964@consulintel.es> <e3e0bf2273e04f15b792665d0f66dfe5@boeing.com> <4c5fab33-2bff-e5b5-fc1d-8f60a01a146d@go6.si> <b4525832-9151-20bf-7136-31d87ba6c88d@huitema.net> <463f15cf-2754-e2e8-609d-dc0f33448c6c@go6.si> <ff649810-7242-7bc2-d36f-3f998f7bdd71@asgard.org> <2839D69E-1AB8-485E-95C4-B2882A355217@thehobsons.co.uk> <alpine.DEB.2.20.1902160553370.23912@uplift.swm.pp.se> <d2704b05cf844ed181921636bd7b6b57@boeing.com> <CALx6S34Zyjz62fs3DZjW0oiYmmzuOoQj_2s7T1b-saqfTKmBVw@mail.gmail.com>
In-Reply-To: <CALx6S34Zyjz62fs3DZjW0oiYmmzuOoQj_2s7T1b-saqfTKmBVw@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [144.115.204.6]
x-tm-snts-smtp: E07672A6F94ADE43AF2E341F7D176B665F89FB8F6D1D6161A9BE2AAFCEDA1D562000:8
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-TM-AS-GCONF: 00
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/FV4RWVFGViJYmp2ZQU8btGhbSVc>
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: Sun, 17 Feb 2019 20:05:15 -0000

From: Tom Herbert <tom@herbertland.com> 

> That technique is easily defeated by "always connected" applications. After an address change, the application logs into the server and the server logs identity, address, and a timestamp. Then it's just a matter of applying the server logs to infer identities in unrelated traffic 
>
> Increasing frequency of address change might make it a little harder to track users, but I think it's mostly a false sense of security in reality. If a user really cares about privacy they want single use untrackable addresses.

Agreed, Tom. But that only strengthens the point that going to great lengths to make IPv6 prefixes stable, when we've spent so much time doing the opposite with respect to the IID, seems self-contradictory. It seems more productive to fix whatever breaks, when the prefix changes. For instance, Fernando's points about SLAAC timers. That should be the main focus of the IETF, IMO. Ensuring permanent prefixes should be the odd exception, done with more or less extraordinary measures.

Bert

v2.23.0 | Report a Bug | By Email