Re: 6man w.g. last call for <draft-ietf-6man-default-iids-11.txt>

joel jaeggli <joelja@bogus.com> Mon, 16 May 2016 21:15 UTC

Return-Path: <joelja@bogus.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 5C7E512DAA2 for <ipv6@ietfa.amsl.com>; Mon, 16 May 2016 14:15:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.326
X-Spam-Level:
X-Spam-Status: No, score=-8.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.426] 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 exX9syCIoXIN for <ipv6@ietfa.amsl.com>; Mon, 16 May 2016 14:15:42 -0700 (PDT)
Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) (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 BF89312DAB4 for <ipv6@ietf.org>; Mon, 16 May 2016 14:15:41 -0700 (PDT)
Received: from mb-2.local ([IPv6:2620:11a:c081:20:5dd6:919b:d3f7:5bc6]) (authenticated bits=0) by nagasaki.bogus.com (8.15.2/8.15.2) with ESMTPSA id u4GLFZNA050344 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT); Mon, 16 May 2016 21:15:35 GMT (envelope-from joelja@bogus.com)
X-Authentication-Warning: nagasaki.bogus.com: Host [IPv6:2620:11a:c081:20:5dd6:919b:d3f7:5bc6] claimed to be mb-2.local
Subject: Re: 6man w.g. last call for <draft-ietf-6man-default-iids-11.txt>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>, Alissa Cooper <alissa@cooperw.in>
References: <20160428004904.25189.43047.idtracker@ietfa.amsl.com> <89CA2C18-AE61-4D40-8997-221201835944@gmail.com> <6f2edbbc-d208-03a0-3c33-503a05c0bee8@gmail.com> <CAKD1Yr1So_tFFSr=sk8ew-UJG-dWK=U6N9mwJnwkZdNX=__SVQ@mail.gmail.com> <11cf3f90-e693-a640-a372-f419a8f7a1a0@gmail.com> <CAKD1Yr0OPuSmp-OWG-+ZjDsHucQYTG2PMZw7jdiU=4kQqK+tyQ@mail.gmail.com> <663debf7-cfba-b19b-92ef-89cc66b452d8@gmail.com> <CAKD1Yr2Km2A6XO8nvNv31Ti_Rr2j4gse1KLadJPcrgFMKyzszw@mail.gmail.com> <31E1F934-FEA2-4338-8F2C-04E7302F3170@cooperw.in> <04271b8d-efc9-7a3f-6200-42cbc3daf919@gmail.com>
From: joel jaeggli <joelja@bogus.com>
Message-ID: <291def3f-bc2b-47bf-ffc6-371bbdde0bfe@bogus.com>
Date: Mon, 16 May 2016 14:15:34 -0700
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.1
MIME-Version: 1.0
In-Reply-To: <04271b8d-efc9-7a3f-6200-42cbc3daf919@gmail.com>
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="qnveRLwUsdVTv8g1iRA86ft22CUL557UD"
Archived-At: <http://mailarchive.ietf.org/arch/msg/ipv6/uED2LvFzzPC_Z-cYp3qQTiFjicA>
Cc: IETF IPv6 Mailing List <ipv6@ietf.org>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.17
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: Mon, 16 May 2016 21:15:43 -0000

On 5/16/16 1:30 PM, Brian E Carpenter wrote:
> On 17/05/2016 05:29, Alissa Cooper wrote:
>> Hi Lorenzo,
>>
>>> On May 13, 2016, at 8:29 PM, Lorenzo Colitti <lorenzo@google.com> wrote:
> 
> ...
>>> any remote attacker anywhere on the Internet that ever exchanges a packet with that host can track it every time the host visits the same network, *forever*, with no recourse. Section 3 point 1.
>>>
>>> Either we fix that or we stop asserting that this draft is motivated by privacy considerations.
>>
>> I would frankly be thrilled if we could get away from stable addresses altogether. But I’m skeptical about the feasibility of achieving consensus around that at present. Defining the approach in this draft in the meantime is certainly motivated by consideration for privacy improvement for me, even if that improvement is incremental.
> 
> Exactly. There is a tussle between enterprise or campus network operators who
> have a strong desire for stable addresses (such that they can identify miscreants)
> and individuals who want to avoid tracking (such that they can avoid surveillance).
> That tussle is not going to go away any time soon, so stable client IIDs are not
> going away either.
> 
> I don't expect enterprise or campus operators to react well to pseudo-random MAC
> addresses, either.

So long as they're as long lived as your 802.1x or wpa2 enterprise
association, it's not really a big deal what your mac address is.
port-security methods already get tetchy when you abandon your previous
identity in favor of a new one without disconnecting or re-authentication.

>     Brian
> 
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>