RE: [dhcwg] Last Call: <draft-ietf-dhc-anonymity-profile-06.txt> (Anonymity profile for DHCP clients) to Proposed Standard

"Christian Huitema" <huitema@huitema.net> Fri, 12 February 2016 22:09 UTC

Return-Path: <huitema@huitema.net>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99FD31A90DF for <ietf@ietfa.amsl.com>; Fri, 12 Feb 2016 14:09:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] 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 tlI0bXKf3kzw for <ietf@ietfa.amsl.com>; Fri, 12 Feb 2016 14:09:01 -0800 (PST)
Received: from xsmtp02.mail2web.com (xsmtp02.mail2web.com [168.144.250.215]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0948E1A90DA for <ietf@ietf.org>; Fri, 12 Feb 2016 14:09:01 -0800 (PST)
Received: from [10.5.2.13] (helo=xmail03.myhosting.com) by xsmtp02.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from <huitema@huitema.net>) id 1aULtb-00061f-05 for ietf@ietf.org; Fri, 12 Feb 2016 17:08:59 -0500
Received: (qmail 27137 invoked from network); 12 Feb 2016 22:08:58 -0000
Received: from unknown (HELO huitema2) (Authenticated-user:_huitema@huitema.net@[131.107.174.15]) (envelope-sender <huitema@huitema.net>) by xmail03.myhosting.com (qmail-ldap-1.03) with ESMTPA for <dhc-chairs@ietf.org>; 12 Feb 2016 22:08:57 -0000
From: "Christian Huitema" <huitema@huitema.net>
To: "'Templin, Fred L'" <Fred.L.Templin@boeing.com>, =?iso-2022-jp?B?JxskQj9ATEBDIzpIGyhCJw==?= <jinmei@wide.ad.jp>, <ietf@ietf.org>
References: <20160201142413.30288.23248.idtracker@ietfa.amsl.com> <CAJE_bqc8asj-i4FkzT2Oc-=atZasAr1cCDUpdNaJ_wOwkRcm1A@mail.gmail.com> <2134F8430051B64F815C691A62D983183396786F@XCH-BLV-105.nw.nos.boeing.com>
In-Reply-To: <2134F8430051B64F815C691A62D983183396786F@XCH-BLV-105.nw.nos.boeing.com>
Date: Fri, 12 Feb 2016 14:08:55 -0800
Message-ID: <0ee601d165e1$f7e59400$e7b0bc00$@huitema.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-2022-jp"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 15.0
Thread-Index: AQHRXPw+hnBWGjZojUCq/zi6nXc1Vp8o3G0AgAAWzwCAABNlYA==
Content-Language: en-us
Subject: RE: [dhcwg] Last Call: <draft-ietf-dhc-anonymity-profile-06.txt> (Anonymity profile for DHCP clients) to Proposed Standard
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf/C5HiubcaDQrzjmHC6nT7rIeTVgc>
Cc: dhc-chairs@ietf.org, draft-ietf-dhc-anonymity-profile@ietf.org, dhcwg@ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 12 Feb 2016 22:09:02 -0000

On Friday, February 12, 2016 12:48 PM, Fred Templin wrote
> > From: dhcwg [mailto:dhcwg-bounces@ietf.org] On Behalf Of ???? (> JINMEI,
Tatuya)
> >
> > Brian Carpenter called for an attention to Section 4.5.2 of the draft...
> > so I'm responding to it.
> >
> > 4.5.2.  Prefix delegation
> >
> >    The interaction between prefix delegation and anonymity require
> >    further study.  For now, the simple solution is to avoid using prefix
> >    delegation when striving for anonymity.  When using the anonymity
> >    profiles, clients SHOULD NOT use IA_PD, the prefix delegation form of
> >    address assignment.
> >
> > I'm not sure what Brian tried to indicate in his message, but at least
> > this section looks vague to me about the rationale for the "SHOULD
> > NOT".  It's not obvious to me how IA_PD is worse than IA_NA in terms
> > of privacy.  Is this a "SHOULD NOT" simply because the "interaction"
> > (is not yet fully understood and) requires further study?

Yes, exactly that. There was some anxiety that prefix delegation requires
understanding to whom the prefix is delegated. There are also potential side
effects if prefix are reassigned quickly to random nodes. All that needs
further study before we can make a recommendation. We can certainly add a
bit of text to make that more clear.

> I don't have a strong opinion on the "SHOULD NOT" in this paragraph, but
it is
> very important that this guidance not be taken out of context. This
document
> is only about clients that wish to remain anonymous, which does not apply
to
> all use cases.

Yes. Also, we can add text explaining that once these problems are better
understood and the IETF agrees on the proper way to handle anonymous prefix
delegation, clients MAY use the agreed upon solution. Which is kind of
redundant, but if you guys prefer it that way, why not.

-- Christian Huitema