From nobody Mon Feb 1 06:24:15 2016 Return-Path: X-Original-To: dhcwg@ietf.org Delivered-To: dhcwg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 414801A914D; Mon, 1 Feb 2016 06:24:13 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.13.0 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20160201142413.30288.23248.idtracker@ietfa.amsl.com> Date: Mon, 01 Feb 2016 06:24:13 -0800 Archived-At: Cc: dhc-chairs@ietf.org, volz@cisco.com, draft-ietf-dhc-anonymity-profile@ietf.org, dhcwg@ietf.org Subject: [dhcwg] Last Call: (Anonymity profile for DHCP clients) to Proposed Standard X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@ietf.org List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Feb 2016 14:24:13 -0000 The IESG has received a request from the Dynamic Host Configuration WG (dhc) to consider the following document: - 'Anonymity profile for DHCP clients' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2016-02-15. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract Some DHCP options carry unique identifiers. These identifiers can enable device tracking even if the device administrator takes care of randomizing other potential identifications like link-layer addresses or IPv6 addresses. The anonymity profile is designed for clients that wish to remain anonymous to the visited network. The profile provides guidelines on the composition of DHCP or DHCPv6 requests, designed to minimize disclosure of identifying information. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-dhc-anonymity-profile/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-dhc-anonymity-profile/ballot/ The following IPR Declarations may be related to this I-D: https://datatracker.ietf.org/ipr/2654/ From nobody Mon Feb 1 12:14:20 2016 Return-Path: X-Original-To: dhcwg@ietf.org Delivered-To: dhcwg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D2B4E1B35E7; Mon, 1 Feb 2016 12:14:17 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.13.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160201201417.6104.27405.idtracker@ietfa.amsl.com> Date: Mon, 01 Feb 2016 12:14:17 -0800 Archived-At: Cc: dhcwg@ietf.org Subject: [dhcwg] I-D Action: draft-ietf-dhc-access-network-identifier-13.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Feb 2016 20:14:18 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Dynamic Host Configuration Working Group of the IETF. Title : Access Network Identifier Option in DHCP Authors : Shwetha Bhandari Sri Gundavelli Mark Grayson Bernie Volz Jouni Korhonen Filename : draft-ietf-dhc-access-network-identifier-13.txt Pages : 20 Date : 2016-02-01 Abstract: This document specifies the format and mechanism that is to be used for encoding access network identifiers in DHCPv4 and DHCPv6 messages by defining new access network identifier options and sub-options. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dhc-access-network-identifier/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-dhc-access-network-identifier-13 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dhc-access-network-identifier-13 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Feb 2 01:24:13 2016 Return-Path: X-Original-To: dhcwg@ietf.org Delivered-To: dhcwg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BE0CA1ACD1C; Tue, 2 Feb 2016 01:24:08 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Benoit Claise" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.13.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160202092408.30383.87178.idtracker@ietfa.amsl.com> Date: Tue, 02 Feb 2016 01:24:08 -0800 Archived-At: Cc: dhc-chairs@ietf.org, draft-ietf-dhc-access-network-identifier@ietf.org, dhcwg@ietf.org Subject: [dhcwg] Benoit Claise's No Objection on draft-ietf-dhc-access-network-identifier-13: (with COMMENT) X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Feb 2016 09:24:08 -0000 Benoit Claise has entered the following ballot position for draft-ietf-dhc-access-network-identifier-13: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dhc-access-network-identifier/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for solving my DISCUSS From nobody Tue Feb 2 08:39:11 2016 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B86061B2D36; Tue, 2 Feb 2016 08:39:07 -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, RP_MATCHES_RCVD=-0.001] 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 Z9TOirFVHPsi; Tue, 2 Feb 2016 08:39:06 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 CBEC31B2D38; Tue, 2 Feb 2016 08:39:00 -0800 (PST) Received: from unnumerable.local (pool-173-57-158-165.dllstx.fios.verizon.net [173.57.158.165]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id u12GcxlW064731 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=OK); Tue, 2 Feb 2016 10:38:59 -0600 (CST) (envelope-from rjsparks@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host pool-173-57-158-165.dllstx.fios.verizon.net [173.57.158.165] claimed to be unnumerable.local To: General Area Review Team , "ietf@ietf.org" , "dhcwg@ietf.org" , draft-ietf-dhc-dhcpv6-privacy.all@ietf.org From: Robert Sparks Message-ID: <56B0DBA3.2050406@nostrum.com> Date: Tue, 2 Feb 2016 10:38:59 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [dhcwg] Gen-ART LC review: draft-ietf-dhc-dhcpv6-privacy-03 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Feb 2016 16:39:08 -0000 I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at . Document: draft-ietf-dhc-dhcpv6-privacy-03 Reviewer: Robert Sparks Review Date: 2Feb2015 IETF LC End Date:4Feb2015 IESG Telechat date: Not yet scheduled Summary: Ready with nits that should be addressed before publication The reference to ietf-6man-ivp6-address-generation-privacy should be normative, and when this document is pointing to it because it is discussing a field carrying a generated address, it should be more explicit about why it's making the reference. In section 4.3 the paragraph on Hash allocation should note that even a well implemented hash does not mitigate the threat of correlation over time. In section 4.3, the paragraph on Random allocation comments on the poor performance of a specific simplistic implementation of random selection. More efficient algorithms exist. But the discussion is mostly irrelevant to the document. Please simplify this paragraph to focus on the benefits of random allocation. Should section 5.3 also call out mapping IP addresses into geolocation? Why doesn't section 5.5 also talk about things like MAC addresses? Section 5.6 could probably borrow words from RFC7258 - it should at least reference it (currently there is only a reference from the introduction.) From nobody Tue Feb 2 09:44:52 2016 Return-Path: X-Original-To: dhcwg@ietf.org Delivered-To: dhcwg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 755E11B2DB7; Tue, 2 Feb 2016 09:44:49 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.13.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160202174449.7310.13313.idtracker@ietfa.amsl.com> Date: Tue, 02 Feb 2016 09:44:49 -0800 Archived-At: Cc: dhcwg@ietf.org Subject: [dhcwg] I-D Action: draft-ietf-dhc-rfc3315bis-03.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Feb 2016 17:44:49 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Dynamic Host Configuration Working Group of the IETF. Title : Dynamic Host Configuration Protocol for IPv6 (DHCPv6) bis Authors : Tomek Mrugalski Marcin Siodelski Bernie Volz Andrew Yourtchenko Michael C. Richardson Sheng Jiang Ted Lemon Filename : draft-ietf-dhc-rfc3315bis-03.txt Pages : 127 Date : 2016-02-02 Abstract: This document describes the Dynamic Host Configuration Protocol for IPv6 (DHCPv6): an extensible mechanism for configuring hosts with network configuration parameters, IP addresses, and prefixes. Parameters can be provided statelessly, or in combination with stateful assignment of one or more IPv6 addresses and/or IPv6 prefixes. DHCPv6 can operate either in place of or in addition to stateless address autoconfiguration (SLAAC). This document updates the text from RFC 3315, the original DHCPv6 specification, and incorporates the stateless DHCPv6 extensions (RFC 3736) and prefix delegation (RFC 3633), clarifying the interactions between these modes of operation (RFC 7550) and providing a mechanism for throttling DHCPv6 clients when DHCPv6 service is not available (RFC 7083). As such, this document obsoletes RFC3315, RFC3633, RFC3736, RFC7083, RFC7550. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dhc-rfc3315bis/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-dhc-rfc3315bis-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dhc-rfc3315bis-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Feb 2 09:55:57 2016 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 362B31B2E16; Tue, 2 Feb 2016 09:55:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] 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 KEabyZJY2sy2; Tue, 2 Feb 2016 09:55:52 -0800 (PST) Received: from mail-lf0-x233.google.com (mail-lf0-x233.google.com [IPv6:2a00:1450:4010:c07::233]) (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 29A851B2E13; Tue, 2 Feb 2016 09:55:52 -0800 (PST) Received: by mail-lf0-x233.google.com with SMTP id j78so54140223lfb.1; Tue, 02 Feb 2016 09:55:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-type:content-transfer-encoding; bh=aNrSbKOC7Xx+TVFf1fQcjwfIVuQ86Pj1tGhQtDUsPe4=; b=QNr5kiWflAL6wXlmL/p8d+Ota3tqTWlpKZBADc5IQZdNQ+mBTtZansak1DJogNEg4b fpYZKcaSNpKCIDBBxHQZmEs5JezowRtweWdoeRxDeHT1gSJcLYUaQvHyil9WY76q0opV b6uzUsx+xaadODyLe3T2A5YCv40k0+SRF1FzHuS1vvvBP1oWjMcJa4tdbI27+tHrh4Gh sEjDeSHfG1155MYzAvBy3YsMFTZbs8yrTgyijR9RRp4uPXpWk7nCrKNvTVmsf51qjJi+ j2546TuUa1+BXlBF4QNOMVQBoywn5grE9O3R7xuKiytcRP2IL/FFgqnOg218wdEMMuel n67w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=aNrSbKOC7Xx+TVFf1fQcjwfIVuQ86Pj1tGhQtDUsPe4=; b=ce1QzFp2yhPYwzMs/WiD1+JBoWq9LFxYikmX+ULa9+aYibTl94e+YELVi9d3BLnJE3 BvdOR/xlRotRssdoEoaabPuth+b+nWwgfdttBFaz53JtylIt44dC/swlr2BabcF3f+lT ehuOKgaYBC/JmTgic7VFaRetzyZXhJ1Dr5yko9kbDfdejX1+aIQHJF8sjI7OT8FAhRk0 0oyN/frpAAj+VLUHNl9WMidyZkJbaVRTIvWVsxmXrrWRqD5wo9EmEh0fz+wLjyx2FIfh uv0lj62gWmeJBw0TQt50xT9pyvZFmCU2tzw5o0uRTcReYSXrVLDG2N2rWYWm2EgPqsFH 0Jiw== X-Gm-Message-State: AG10YORjZ7EYez50DG0DAwhHBAJ0vyoYL6f1Y2gYlDwb8CGnF3qQ4k7jHvai4IucQg14Gw== X-Received: by 10.25.170.203 with SMTP id t194mr9416494lfe.48.1454435750417; Tue, 02 Feb 2016 09:55:50 -0800 (PST) Received: from [10.0.0.100] (109107011157.gdansk.vectranet.pl. [109.107.11.157]) by smtp.googlemail.com with ESMTPSA id jr10sm361529lbc.42.2016.02.02.09.55.48 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 02 Feb 2016 09:55:49 -0800 (PST) To: dhcwg@ietf.org, "dhcpv6bis@ietf.org" References: <20160202174449.7310.13313.idtracker@ietfa.amsl.com> From: Tomek Mrugalski X-Enigmail-Draft-Status: N1110 Message-ID: <56B0EDA4.4080209@gmail.com> Date: Tue, 2 Feb 2016 18:55:48 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <20160202174449.7310.13313.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-rfc3315bis-03.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Feb 2016 17:55:54 -0000 Hi, A new revision of the rfc3315bis has been published. It addresses several of the issues raised. If you are interested, we maintain Appendix A with notable changes. Here's what has changed since -02: 57. Reorganized text about Reply processing on the client side (ticket #140). 58. Revised the "Creation and Transmission of Release Messages" section to clarify what a client must do before initiating a Release (ticket #151). 59. Privacy considerations added (ticket #145). 60. Abstract updated (#133). 61. Removed references to the text that server was allowed to cache its replies (#80). If you are interested in background of those changes, feel free to visit (and comment in!) our issue tracker here: https://wiki.tools.ietf.org/group/dhcpv6bis/ You can also see the open tickets there. Their number is going down steadily, but we still have 17 open tickets to go. If there are things that bother you in DHCPv6 and the new draft doesn't address them, feel free to discuss them on dhcpv6bis list. Thanks a lot to everyone who contributed to this effort. Tomek p.s. There's an upcoming dhcpv6bis authors meeting tomorrow at 14:00 CET. Details were posted to the dhcpv6bis list if you're interested. On 02.02.2016 18:44, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Dynamic Host Configuration Working Group of the IETF. > > Title : Dynamic Host Configuration Protocol for IPv6 (DHCPv6) bis > Authors : Tomek Mrugalski > Marcin Siodelski > Bernie Volz > Andrew Yourtchenko > Michael C. Richardson > Sheng Jiang > Ted Lemon > Filename : draft-ietf-dhc-rfc3315bis-03.txt > Pages : 127 > Date : 2016-02-02 > > Abstract: > This document describes the Dynamic Host Configuration Protocol for > IPv6 (DHCPv6): an extensible mechanism for configuring hosts with > network configuration parameters, IP addresses, and prefixes. > Parameters can be provided statelessly, or in combination with > stateful assignment of one or more IPv6 addresses and/or IPv6 > prefixes. DHCPv6 can operate either in place of or in addition to > stateless address autoconfiguration (SLAAC). > > This document updates the text from RFC 3315, the original DHCPv6 > specification, and incorporates the stateless DHCPv6 extensions (RFC > 3736) and prefix delegation (RFC 3633), clarifying the interactions > between these modes of operation (RFC 7550) and providing a mechanism > for throttling DHCPv6 clients when DHCPv6 service is not available > (RFC 7083). As such, this document obsoletes RFC3315, RFC3633, > RFC3736, RFC7083, RFC7550. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-dhc-rfc3315bis/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-dhc-rfc3315bis-03 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-dhc-rfc3315bis-03 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg > From nobody Tue Feb 2 15:31:42 2016 Return-Path: X-Original-To: dhcwg@ietf.org Delivered-To: dhcwg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8ACCB1A909F; Tue, 2 Feb 2016 15:31:40 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Alissa Cooper" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.13.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160202233140.29443.95096.idtracker@ietfa.amsl.com> Date: Tue, 02 Feb 2016 15:31:40 -0800 Archived-At: Cc: dhc-chairs@ietf.org, draft-ietf-dhc-access-network-identifier@ietf.org, dhcwg@ietf.org Subject: [dhcwg] Alissa Cooper's No Objection on draft-ietf-dhc-access-network-identifier-13: (with COMMENT) X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Feb 2016 23:31:40 -0000 Alissa Cooper has entered the following ballot position for draft-ietf-dhc-access-network-identifier-13: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dhc-access-network-identifier/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for handling my DISCUSS. From nobody Wed Feb 3 05:43:12 2016 Return-Path: X-Original-To: dhcwg@ietf.org Delivered-To: dhcwg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AB3E1AC3F4 for ; Wed, 3 Feb 2016 05:43:10 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: X-Test-IDTracker: no X-IETF-IDTracker: 6.13.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160203134310.24405.23835.idtracker@ietfa.amsl.com> Date: Wed, 03 Feb 2016 05:43:10 -0800 From: IETF Secretariat Archived-At: Subject: [dhcwg] Milestones changed for dhc WG X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Feb 2016 13:43:10 -0000 Deleted milestone "WG last call draft-ietf-dhc-stable-privacy-addresses". Changed milestone "WG last call on DHCP privacy drafts", resolved as "Done". Changed milestone "Submit draft-ietf-dhc-topo-conf to IESG", set due date to April 2016 from August 2015. Changed milestone "WG last call on 331bis draft", set due date to April 2016 from January 2016. Changed milestone "Submit 3315bis draft to IESG", set due date to June 2016 from April 2016. URL: https://datatracker.ietf.org/wg/dhc/charter/ From nobody Wed Feb 3 05:44:30 2016 Return-Path: X-Original-To: dhcwg@ietf.org Delivered-To: dhcwg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A14F41AC3F5 for ; Wed, 3 Feb 2016 05:44:29 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: X-Test-IDTracker: no X-IETF-IDTracker: 6.13.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160203134429.24981.8706.idtracker@ietfa.amsl.com> Date: Wed, 03 Feb 2016 05:44:29 -0800 From: IETF Secretariat Archived-At: Subject: [dhcwg] Milestones changed for dhc WG X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Feb 2016 13:44:29 -0000 Changed milestone "Submit DHCP privacy drafts to IESG", set due date to January 2016 from November 2015. Changed milestone "WG last call revised draft-ietf-dhc-dhcpv6-failover-design", set due date to April 2016 from December 2015. URL: https://datatracker.ietf.org/wg/dhc/charter/ From nobody Wed Feb 3 05:46:53 2016 Return-Path: X-Original-To: dhcwg@ietf.org Delivered-To: dhcwg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6801E1AC3F3 for ; Wed, 3 Feb 2016 05:46:52 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: X-Test-IDTracker: no X-IETF-IDTracker: 6.13.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160203134652.28664.60870.idtracker@ietfa.amsl.com> Date: Wed, 03 Feb 2016 05:46:52 -0800 From: IETF Secretariat Archived-At: Subject: [dhcwg] Milestones changed for dhc WG X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Feb 2016 13:46:52 -0000 Changed milestone "WG last call on 331bis draft", added draft-ietf-dhc-rfc3315bis to milestone, removed draft-dhcwg-dhc-rfc3315bis from milestone. Changed milestone "Submit 3315bis draft to IESG", added draft-ietf-dhc-rfc3315bis to milestone, removed draft-dhcwg-dhc-rfc3315bis from milestone. URL: https://datatracker.ietf.org/wg/dhc/charter/ From nobody Wed Feb 3 05:48:26 2016 Return-Path: X-Original-To: dhcwg@ietf.org Delivered-To: dhcwg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id F1C8C1AC3F5 for ; Wed, 3 Feb 2016 05:48:25 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: X-Test-IDTracker: no X-IETF-IDTracker: 6.13.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160203134825.21748.14381.idtracker@ietfa.amsl.com> Date: Wed, 03 Feb 2016 05:48:25 -0800 From: IETF Secretariat Archived-At: Subject: [dhcwg] Milestones changed for dhc WG X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Feb 2016 13:48:26 -0000 Changed milestone "WG last call revised draft-ietf-dhc-dhcpv6-failover-design", added draft-ietf-dhc-dhcpv6-failover-protocol to milestone, removed draft-ietf-dhc-dhcpv6-failover-design from milestone. Changed milestone "Submit dhcpv6-failover-design to IESG", added draft-ietf-dhc-dhcpv6-failover-protocol to milestone, removed draft-ietf-dhc-dhcpv6-failover-design from milestone. URL: https://datatracker.ietf.org/wg/dhc/charter/ From nobody Fri Feb 5 06:06:54 2016 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44ED11B3921 for ; Fri, 5 Feb 2016 06:06:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 sfsJWJcOt8wS for ; Fri, 5 Feb 2016 06:06:50 -0800 (PST) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 73FCE1B3918 for ; Fri, 5 Feb 2016 06:06:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=20968; q=dns/txt; s=iport; t=1454681210; x=1455890810; h=from:to:subject:date:message-id:references:mime-version; bh=LZlz5HOqWJgePY37bumXBBrQvFOw0X2JZYD4FH26JxU=; b=fszNkWO2i/TbCJ/S1cpJmFHSexuhq79ivNqeZnbHcJYDesRH0sAxAfqY L03fP7Hv+mqX+oa7LG86No9MTsKrjlJFe4L49wZI+6wZh64k+M4d5NfBt r1wohDyYjqAhZxi/Rkmf4DMdO3ihcBv2uqAIf1qvs08Wb2DhYQSUWfwxR M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AdAgAqq7RW/5ldJa1egm5MUm0GiFWue?= =?us-ascii?q?oITAQ2BZiGFbAKBMDgUAQEBAQEBAX8LhEEBAQEELVwCAQgRBAEBIQcHMhQJCAE?= =?us-ascii?q?BBBMIiBMOv18BAQEBAQEBAQEBAQEBAQEBAQEBAQERBIpJhF8JhAQFh12GeYgfA?= =?us-ascii?q?YVLh32BYoRDiFWFbohPAR4BAUKCAxmBSGqJAHwBAQE?= X-IronPort-AV: E=Sophos;i="5.22,400,1449532800"; d="scan'208,217";a="233838610" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 05 Feb 2016 14:06:49 +0000 Received: from XCH-ALN-003.cisco.com (xch-aln-003.cisco.com [173.36.7.13]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id u15E6nID021211 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Fri, 5 Feb 2016 14:06:49 GMT Received: from xch-aln-003.cisco.com (173.36.7.13) by XCH-ALN-003.cisco.com (173.36.7.13) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Fri, 5 Feb 2016 08:06:48 -0600 Received: from xch-aln-003.cisco.com ([173.36.7.13]) by XCH-ALN-003.cisco.com ([173.36.7.13]) with mapi id 15.00.1104.009; Fri, 5 Feb 2016 08:06:48 -0600 From: "Bernie Volz (volz)" To: "dhcwg@ietf.org" Thread-Topic: WG Session @ IETF-95 (Buenos Aires) Agenda Requests - Deadline 2/14/2016 Thread-Index: AdFHORD4y95fMyRVQ56UWvb6lX4DVgQbpvJgAh2sP8A= Date: Fri, 5 Feb 2016 14:06:48 +0000 Message-ID: <0bf34ed92a34400f98edf4c48151750c@XCH-ALN-003.cisco.com> References: <005134edeb9e4550b55a23776afaef15@XCH-ALN-003.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.98.1.195] Content-Type: multipart/alternative; boundary="_000_0bf34ed92a34400f98edf4c48151750cXCHALN003ciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [dhcwg] WG Session @ IETF-95 (Buenos Aires) Agenda Requests - Deadline 2/14/2016 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Feb 2016 14:06:53 -0000 --_000_0bf34ed92a34400f98edf4c48151750cXCHALN003ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi: The current agenda requests are at https://github.com/dhcwg/wg/wiki/IETF-95= -(Buenos-Aires)-DHC-WG-Agenda. We need all requests for time to be submitted by 2/14 so we can determine a= ppropriate time to request for the IETF-95 slot. Thanks to those that have send their requests. - Bernie From: Bernie Volz (volz) Sent: Monday, January 25, 2016 2:41 PM To: dhcwg@ietf.org Subject: RE: WG Session @ IETF-95 (Buenos Aires) Agenda Requests - Deadline= 2/14/2016 Just a reminder about requesting agenda slots! We have only one request: - DHCPv6 bis I would think we MAY want to discuss: - Secure DHCPv6 (and draft-li-dhc-secure-dhcpv6-deployment) - DHCPv6 Prefix Length Hint Issues (though perhaps we'll just want= to try to WGLC this?) - Yang model? - Failover? - Relay Initiated Release (though this would need an update based = on the IETF-94 discussions)?? - Bernie From: dhcwg [mailto:dhcwg-bounces@ietf.org] On Behalf Of Bernie Volz (volz) Sent: Monday, January 04, 2016 4:45 PM To: dhcwg@ietf.org Subject: [dhcwg] WG Session @ IETF-95 (Buenos Aires) Agenda Requests - Dead= line 2/14/2016 Importance: High Hi: The scheduling requests for meeting slots for IETF-95 in Buenos Aires have = opened up (we must submit a request before 2/19/2016). Our plan for IETF-95 will be the same as we did for IETF-94: - We are encouraging agenda requests NOW thru February= 14th, 2016 (this will give us a few days to organize the agenda and decide= on the session length request). - We will submit our time request for IETF-95 based on= the RECEIVED agenda requests (by the February 14th deadline). - Requests after February 14th will most likely be REJ= ECTED (once the time slot is filled). In the past we have been more accommo= dating, but because of the pressure on IETF meeting time, we are being aske= d to justify our time slot request. And meeting time should be used to disc= uss and resolve issues, not present overviews of drafts or status updates. Therefore, please submit requests as soon as you can (and well before 2/14)= if you do plan to present at the DHC WG session in Buenos Aires. As in the past, please provide: Title Of Session: Presenter: Related Drafts: Time Required: Purpose of Session: We do want to remind those requesting time that you should focus on discuss= ing key issues that need resolution to move a draft forward. We are 3 months from that next meeting. - Tomek & Bernie --_000_0bf34ed92a34400f98edf4c48151750cXCHALN003ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi:<= /p>

 

The current agenda req= uests are at https://github.com/dhcwg/wg/wiki/IETF-95-(Buenos-Aires)-DHC-WG-Agend= a.

 

We need all requests f= or time to be submitted by 2/14 so we can determine appropriate time to req= uest for the IETF-95 slot.

 

Thanks to those that h= ave send their requests.

 

-&nb= sp;         Bernie

 

From: Bernie Volz (volz)
Sent: Monday, January 25, 2016 2:41 PM
To: dhcwg@ietf.org
Subject: RE: WG Session @ IETF-95 (Buenos Aires) Agenda Requests - D= eadline 2/14/2016

 

Just a reminder about = requesting agenda slots!

 

We have only one reque= st:

-&nb= sp;         DHCPv6 bis

 

I would think we MAY w= ant to discuss:

-&nb= sp;         Secure DHCPv6 = (and draft-li-dhc-secure-dhcpv6-deployment)

-&nb= sp;         DHCPv6 Prefix = Length Hint Issues (though perhaps we’ll just want to try to WGLC thi= s?)

-&nb= sp;         Yang model?

-&nb= sp;         Failover?=

-&nb= sp;         Relay Initiate= d Release (though this would need an update based on the IETF-94 discussion= s)??

 

-&nb= sp;         Bernie

 

From: dhcwg [mailto:dhcwg-bounces@ietf.org] On Behalf Of Bernie Volz (volz)
Sent: Monday, January 04, 2016 4:45 PM
To: dhcwg@ietf.org
Subject: [dhcwg] WG Session @ IETF-95 (Buenos Aires) Agenda Requests= - Deadline 2/14/2016
Importance: High

 

Hi:

 

The scheduling requests for meeting slots for IETF-9= 5 in Buenos Aires have opened up (we must submit a request before 2/19/2016= ).

 

Our plan for IETF-95 will be the same as we did for = IETF-94:

-       = ;            &n= bsp;  We are encouraging agenda requests NOW thru Februar= y 14th, 2016 (this will give us a few days to organize the agenda and decid= e on the session length request).

-       = ;            &n= bsp;  We will submit our time request for IETF-95 based o= n the RECEIVED agenda requests (by the February 14th deadline).<= /p>

-       = ;            &n= bsp;  Requests after February 14th will most likely be RE= JECTED (once the time slot is filled). In the past we have been more accomm= odating, but because of the pressure on IETF meeting time, we are being ask= ed to justify our time slot request. And meeting time should be used to discuss and resolve issues, not present= overviews of drafts or status updates.

 

Therefore, please submit requests as soon as you can= (and well before 2/14) if you do plan to present at the DHC WG session in = Buenos Aires.

 

As in the past, please provide:

 

Title Of Session:

Presenter:

Related Drafts:

Time Required:

Purpose of Session:

 

We do want to remind those requesting time that you = should focus on discussing key issues that need resolution to move a draft = forward.

 

We are 3 months from that next meeting.

 

-     &= nbsp;    Tomek & Bernie

 

--_000_0bf34ed92a34400f98edf4c48151750cXCHALN003ciscocom_-- From nobody Mon Feb 8 04:11:41 2016 Return-Path: X-Original-To: dhcwg@ietf.org Delivered-To: dhcwg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A8C71B29AC; Mon, 8 Feb 2016 04:11:40 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Stephen Farrell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.14.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160208121140.8235.49754.idtracker@ietfa.amsl.com> Date: Mon, 08 Feb 2016 04:11:40 -0800 Archived-At: Cc: dhc-chairs@ietf.org, draft-ietf-dhc-access-network-identifier@ietf.org, dhcwg@ietf.org Subject: [dhcwg] Stephen Farrell's Discuss on draft-ietf-dhc-access-network-identifier-13: (with DISCUSS and COMMENT) X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Feb 2016 12:11:40 -0000 Stephen Farrell has entered the following ballot position for draft-ietf-dhc-access-network-identifier-13: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dhc-access-network-identifier/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Thanks for the changes made in response to my and, in particular, Alissa's discuss ballots. Having looked back at the email thread I don't believe I got any answer to the question "Did the DHC working group consider how this information, when sent without adequate protection between relay and dhcp server, could help in pervasive monitoring?" I think the focus of the discussion has been on the applicability of this being limited to "typically" one operator's network, which does of course mean that the traffic is less at risk than had it transited many networks. However, we have seen (Belgacom) that the PM threat also applies within a single operator's network. So I am still interested in the answer to the above question. The DHC WG might consider this threat and still conclude that a SHOULD statement about IPsec is the best we can do in practice, but that isn't clear to me at present, so I'd still like to chat about the PM threat. (Note: it's the WG's consideration of the threat I'd like to chat about, not only about the potential of IPsec to mitigate that threat.) ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- OLD DISCUSS TEXT BELOW: (Sent mail 2016-01-10, checking on change vs. discuss) (1) Did the DHC working group consider how this information, when sent without adequate protection between relay and dhcp server, could help in pervasive monitoring? If so, what was the conclusion reached? We have seen http header field information sent between infrastructure nodes being intercepted for that purpose, so this has to be similarly at risk. If the answer is that this is only to be used within a single network operator's setup (or a roaming arrangement) then that needs to be justified (as practical) and, if it can be justified (I'm not sure tbh), also made explicit. (2) I had a DISCUSS on the draft that became rfc 6757 about protection of this kind of data. In that context I think I was assured that everything (in PMIPv6) was IPsec protected so it was fine. Why, in what we now know is a more threated environment, is it ok to now have weaker protection when I was assured then that IPsec was in fact quite usable in PMIPv6? I think you maybe need to put in a MUST use IPsec requirement for this to be as safe. (3) section 7: MAY store - this is possibly sensitive information so you ought say that it SHOULD NOT be stored unless needed, and if stored, SHOULD be deleted as soon as possible. Storing sensitive information when not needed just shouldn't be considered acceptable anymore I think - is that reasonable? OLD COMMENT TEXT BELOW - I (strongly) support Alissa's DISCUSS and will be interested in watching how that is resolved. Some of my DISCUSS points do overlap though so from my POV feel free to mix'n'match the discussions. Or to process first one then the other, whatever you think is best. - RFC6757 defines exactly this for PMIPv6. That implies that PMIPv6 should not be used to illustrate or motivate this, as that problem is solved. Perhaps you would be better off if you limited the scope of this to be used for networks that are some kind of extension to PMIPv6 only? (You'd need to define what kind I think.) From nobody Mon Feb 8 09:44:15 2016 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 233201B2FE7; Mon, 8 Feb 2016 09:44:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 bJb6VZDSzDZT; Mon, 8 Feb 2016 09:44:12 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F86E1B2FCF; Mon, 8 Feb 2016 09:44:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5367; q=dns/txt; s=iport; t=1454953451; x=1456163051; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=Ljn1O5qC1DNby8qkcvRX621cnr0vJImW04kXB4QTguo=; b=UI+Q+9VwAso6Nq+Vxhp6o8Ua2v8wW7a5i8qXfDVZeNBGlCPIFAV8vDiu Ly6fc9Ay34/WYmBTyHc8nvMQEupxx0OTow55qAtm/vzarm64r9BnOSIQ/ C7GQLzT+t3oevYdlRKMWlOAhr5KYpOJzlGkfcJPw7FMV8ZlSPI6onAYKX Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D/AQDG0rhW/4QNJK1egzpSbQaIVa57g?= =?us-ascii?q?hMBDYFmI4VqAoEvOBQBAQEBAQEBgQqEQgEBBDo/EAIBCDYFCzIlAgQBDQWIGw6?= =?us-ascii?q?9JgEBAQEBAQEBAQEBAQEBAQEBAQETBIYSgzx7hAIKBgIBBUqECAWHU48iAYVLi?= =?us-ascii?q?ASBW4RDgyaFL449AR4BAUKCAxkUgTRqAYcZPXwBAQE?= X-IronPort-AV: E=Sophos;i="5.22,417,1449532800"; d="scan'208";a="71377364" Received: from alln-core-10.cisco.com ([173.36.13.132]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 08 Feb 2016 17:44:10 +0000 Received: from XCH-ALN-008.cisco.com (xch-aln-008.cisco.com [173.36.7.18]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id u18HiAe7026658 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 8 Feb 2016 17:44:10 GMT Received: from xch-aln-007.cisco.com (173.36.7.17) by XCH-ALN-008.cisco.com (173.36.7.18) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 8 Feb 2016 11:44:09 -0600 Received: from xch-aln-007.cisco.com ([173.36.7.17]) by XCH-ALN-007.cisco.com ([173.36.7.17]) with mapi id 15.00.1104.009; Mon, 8 Feb 2016 11:44:09 -0600 From: "Sri Gundavelli (sgundave)" To: Stephen Farrell , The IESG Thread-Topic: Stephen Farrell's Discuss on draft-ietf-dhc-access-network-identifier-13: (with DISCUSS and COMMENT) Thread-Index: AQHRYphQFWIC9raxVkyLJ60SydOYTg== Date: Mon, 8 Feb 2016 17:44:09 +0000 Message-ID: References: <20160208121140.8235.49754.idtracker@ietfa.amsl.com> In-Reply-To: <20160208121140.8235.49754.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.0.151221 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.32.246.213] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "dhc-chairs@ietf.org" , "draft-ietf-dhc-access-network-identifier@ietf.org" , "dhcwg@ietf.org" Subject: Re: [dhcwg] Stephen Farrell's Discuss on draft-ietf-dhc-access-network-identifier-13: (with DISCUSS and COMMENT) X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Feb 2016 17:44:14 -0000 Thanks Stephen. If I read this correctly, I assume this is the only pending DISCUSS point. > "Did the DHC working group consider how this information, when sent >without adequate protection between relay and dhcp server, could help in >pervasive monitoring?" I will let chairs answer this question. But, from my point view: 1.) we have identified the information elements that are sensitive in nature from privacy point of view 2.) we have identified the interfaces where these information elements can possibly get exposed; interfaces where threats can be activated 3.) we have listed the deployment context (Ex: Single operator) 4.) we have listed considerations on how to entities have to deal with this data; points such as not to store the data at DHCP server ..etc. 4.) we have listed the existing tools that are available for the operator to mitigate that threat All of these points were discussed in the DHC WG and there were no explicit comments either supporting, or disagreeing with these views. Regards Sri On 2/8/16, 4:11 AM, "Stephen Farrell" wrote: >Stephen Farrell has entered the following ballot position for >draft-ietf-dhc-access-network-identifier-13: Discuss > >When responding, please keep the subject line intact and reply to all >email addresses included in the To and CC lines. (Feel free to cut this >introductory paragraph, however.) > > >Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html >for more information about IESG DISCUSS and COMMENT positions. > > >The document, along with other ballot positions, can be found here: >https://datatracker.ietf.org/doc/draft-ietf-dhc-access-network-identifier/ > > > >---------------------------------------------------------------------- >DISCUSS: >---------------------------------------------------------------------- > > >Thanks for the changes made in response to my and, in particular, >Alissa's discuss ballots. > >Having looked back at the email thread I don't believe I got any >answer to the question "Did the DHC working group consider how >this information, when sent without adequate protection between >relay and dhcp server, could help in pervasive monitoring?" > >I think the focus of the discussion has been on the applicability of >this being limited to "typically" one operator's network, which >does of course mean that the traffic is less at risk than had it >transited many networks. However, we have seen (Belgacom) that >the PM threat also applies within a single operator's network. >So I am still interested in the answer to the above question. > >The DHC WG might consider this threat and still conclude that >a SHOULD statement about IPsec is the best we can do in practice, >but that isn't clear to me at present, so I'd still like to chat about >the PM threat. (Note: it's the WG's consideration of the threat >I'd like to chat about, not only about the potential of IPsec to >mitigate that threat.) > > >---------------------------------------------------------------------- >COMMENT: >---------------------------------------------------------------------- > > > > >OLD DISCUSS TEXT BELOW: > >(Sent mail 2016-01-10, checking on change vs. discuss) > >(1) Did the DHC working group consider how this information, >when sent without adequate protection between relay and dhcp >server, could help in pervasive monitoring? If so, what was the >conclusion reached? We have seen http header field information >sent between infrastructure nodes being intercepted for that >purpose, so this has to be similarly at risk. If the answer is >that this is only to be used within a single network operator's >setup (or a roaming arrangement) then that needs to be >justified (as practical) and, if it can be justified (I'm not >sure tbh), also made explicit. > >(2) I had a DISCUSS on the draft that became rfc 6757 about >protection of this kind of data. In that context I think I was >assured that everything (in PMIPv6) was IPsec protected so it >was fine. Why, in what we now know is a more threated >environment, is it ok to now have weaker protection when I was >assured then that IPsec was in fact quite usable in PMIPv6? I >think you maybe need to put in a MUST use IPsec requirement for >this to be as safe. > >(3) section 7: MAY store - this is possibly sensitive >information so you ought say that it SHOULD NOT be stored >unless needed, and if stored, SHOULD be deleted as soon as >possible. Storing sensitive information when not needed just >shouldn't be considered acceptable anymore I think - is that >reasonable? > >OLD COMMENT TEXT BELOW > >- I (strongly) support Alissa's DISCUSS and will be interested >in watching how that is resolved. Some of my DISCUSS points do >overlap though so from my POV feel free to mix'n'match the >discussions. Or to process first one then the other, whatever >you think is best. > >- RFC6757 defines exactly this for PMIPv6. That implies that >PMIPv6 should not be used to illustrate or motivate this, as >that problem is solved. Perhaps you would be better off if you >limited the scope of this to be used for networks that are some >kind of extension to PMIPv6 only? (You'd need to define what >kind I think.) > > From nobody Mon Feb 8 10:09:03 2016 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCD8B1B3072; Mon, 8 Feb 2016 10:09:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 Ofz97v4_4YXQ; Mon, 8 Feb 2016 10:08:59 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7048C1B3076; Mon, 8 Feb 2016 10:08:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5930; q=dns/txt; s=iport; t=1454954939; x=1456164539; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=7IG5RLrfJLFfQnaK8uIIxqBX+QadESSO220pWDwy87A=; b=OZhDK1xV3jxChQZXKl953wWOPJFZwf0BBWPy51xzZ6HXl//XSgPEEX1H iGsDo75bTs5dH7iJ/WV+L8KEK4oEab43lm+sLUw1ozW0dq9XvPoKwlbX8 3kbzdWCvo2Nj2MawsaYaEfiSpZ/wS73paekpDRB84acdDQVrLLcZFSqa7 s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D1AQAG2bhW/4YNJK1egzpSXg+IW657g?= =?us-ascii?q?hMBDYFmI4VqAoEvOBQBAQEBAQEBgQqEQQEBAQMBOj8FCwIBCBgeBQsyJQIEDgW?= =?us-ascii?q?IEwgOvTQBAQEBAQEBAQEBAQEBAQEBAQEBAQERBId/gU97hAIKBgIBBRY0gnmBD?= =?us-ascii?q?wWHU48iAYVLiASBW4RDgyaFL449AR4BAUKCAxkUgTRqAYcZgTkBAQE?= X-IronPort-AV: E=Sophos;i="5.22,417,1449532800"; d="scan'208";a="74974171" Received: from alln-core-12.cisco.com ([173.36.13.134]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 08 Feb 2016 18:08:58 +0000 Received: from XCH-RCD-010.cisco.com (xch-rcd-010.cisco.com [173.37.102.20]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id u18I8wx2016717 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 8 Feb 2016 18:08:58 GMT Received: from xch-aln-003.cisco.com (173.36.7.13) by XCH-RCD-010.cisco.com (173.37.102.20) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 8 Feb 2016 12:08:57 -0600 Received: from xch-aln-003.cisco.com ([173.36.7.13]) by XCH-ALN-003.cisco.com ([173.36.7.13]) with mapi id 15.00.1104.009; Mon, 8 Feb 2016 12:08:57 -0600 From: "Bernie Volz (volz)" To: "Sri Gundavelli (sgundave)" Thread-Topic: Stephen Farrell's Discuss on draft-ietf-dhc-access-network-identifier-13: (with DISCUSS and COMMENT) Thread-Index: AQHRYphQFWIC9raxVkyLJ60SydOYTp8icl7l Date: Mon, 8 Feb 2016 18:08:57 +0000 Message-ID: <8B7BDF27-834F-4D9C-A546-0C42AE6F0949@cisco.com> References: <20160208121140.8235.49754.idtracker@ietfa.amsl.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "dhc-chairs@ietf.org" , The IESG , "dhcwg@ietf.org" , Stephen Farrell , "draft-ietf-dhc-access-network-identifier@ietf.org" Subject: Re: [dhcwg] Stephen Farrell's Discuss on draft-ietf-dhc-access-network-identifier-13: (with DISCUSS and COMMENT) X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Feb 2016 18:09:01 -0000 Agree with Sri's points. DHC wg would like to advance draft. - Bernie (from iPhone) > On Feb 8, 2016, at 12:44 PM, Sri Gundavelli (sgundave) wrote: >=20 >=20 > Thanks Stephen. If I read this correctly, I assume this is the only > pending DISCUSS point. >=20 >=20 >> "Did the DHC working group consider how this information, when sent >> without adequate protection between relay and dhcp server, could help in >> pervasive monitoring?" >=20 > I will let chairs answer this question. >=20 >=20 > But, from my point view: >=20 > 1.) we have identified the information elements that are sensitive in > nature from privacy point of view > 2.) we have identified the interfaces where these information elements ca= n > possibly get exposed; interfaces where threats can be activated > 3.) we have listed the deployment context (Ex: Single operator) > 4.) we have listed considerations on how to entities have to deal with > this data; points such as not to store the data at DHCP server ..etc. > 4.) we have listed the existing tools that are available for the operator > to mitigate that threat >=20 > All of these points were discussed in the DHC WG and there were no > explicit comments either supporting, or disagreeing with these views. >=20 >=20 > Regards > Sri >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >> On 2/8/16, 4:11 AM, "Stephen Farrell" wrote: >>=20 >> Stephen Farrell has entered the following ballot position for >> draft-ietf-dhc-access-network-identifier-13: Discuss >>=20 >> When responding, please keep the subject line intact and reply to all >> email addresses included in the To and CC lines. (Feel free to cut this >> introductory paragraph, however.) >>=20 >>=20 >> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.htm= l >> for more information about IESG DISCUSS and COMMENT positions. >>=20 >>=20 >> The document, along with other ballot positions, can be found here: >> https://datatracker.ietf.org/doc/draft-ietf-dhc-access-network-identifie= r/ >>=20 >>=20 >>=20 >> ---------------------------------------------------------------------- >> DISCUSS: >> ---------------------------------------------------------------------- >>=20 >>=20 >> Thanks for the changes made in response to my and, in particular, >> Alissa's discuss ballots. >>=20 >> Having looked back at the email thread I don't believe I got any >> answer to the question "Did the DHC working group consider how >> this information, when sent without adequate protection between >> relay and dhcp server, could help in pervasive monitoring?" >>=20 >> I think the focus of the discussion has been on the applicability of >> this being limited to "typically" one operator's network, which >> does of course mean that the traffic is less at risk than had it >> transited many networks. However, we have seen (Belgacom) that >> the PM threat also applies within a single operator's network. >> So I am still interested in the answer to the above question. >>=20 >> The DHC WG might consider this threat and still conclude that >> a SHOULD statement about IPsec is the best we can do in practice, >> but that isn't clear to me at present, so I'd still like to chat about >> the PM threat. (Note: it's the WG's consideration of the threat >> I'd like to chat about, not only about the potential of IPsec to >> mitigate that threat.) >>=20 >>=20 >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >>=20 >>=20 >>=20 >>=20 >> OLD DISCUSS TEXT BELOW: >>=20 >> (Sent mail 2016-01-10, checking on change vs. discuss) >>=20 >> (1) Did the DHC working group consider how this information, >> when sent without adequate protection between relay and dhcp >> server, could help in pervasive monitoring? If so, what was the >> conclusion reached? We have seen http header field information >> sent between infrastructure nodes being intercepted for that >> purpose, so this has to be similarly at risk. If the answer is >> that this is only to be used within a single network operator's >> setup (or a roaming arrangement) then that needs to be >> justified (as practical) and, if it can be justified (I'm not >> sure tbh), also made explicit. >>=20 >> (2) I had a DISCUSS on the draft that became rfc 6757 about >> protection of this kind of data. In that context I think I was >> assured that everything (in PMIPv6) was IPsec protected so it >> was fine. Why, in what we now know is a more threated >> environment, is it ok to now have weaker protection when I was >> assured then that IPsec was in fact quite usable in PMIPv6? I >> think you maybe need to put in a MUST use IPsec requirement for >> this to be as safe. >>=20 >> (3) section 7: MAY store - this is possibly sensitive >> information so you ought say that it SHOULD NOT be stored >> unless needed, and if stored, SHOULD be deleted as soon as >> possible. Storing sensitive information when not needed just >> shouldn't be considered acceptable anymore I think - is that >> reasonable? >>=20 >> OLD COMMENT TEXT BELOW >>=20 >> - I (strongly) support Alissa's DISCUSS and will be interested >> in watching how that is resolved. Some of my DISCUSS points do >> overlap though so from my POV feel free to mix'n'match the >> discussions. Or to process first one then the other, whatever >> you think is best. >>=20 >> - RFC6757 defines exactly this for PMIPv6. That implies that >> PMIPv6 should not be used to illustrate or motivate this, as >> that problem is solved. Perhaps you would be better off if you >> limited the scope of this to be used for networks that are some >> kind of extension to PMIPv6 only? (You'd need to define what >> kind I think.) >=20 From nobody Mon Feb 8 10:39:46 2016 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 858111B3133; Mon, 8 Feb 2016 10:39:44 -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 XoDJjkQNWdfb; Mon, 8 Feb 2016 10:39:42 -0800 (PST) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 82A701B3132; Mon, 8 Feb 2016 10:39:42 -0800 (PST) Received: from clairseach.fuaim.com (clairseach-high.fuaim.com [206.197.161.158]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id 463D58812C; Mon, 8 Feb 2016 10:39:42 -0800 (PST) Received: from clemson.local (unknown [76.21.129.88]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id 3DC5A328081A; Mon, 8 Feb 2016 10:39:41 -0800 (PST) To: "Bernie Volz (volz)" , "Sri Gundavelli (sgundave)" References: <20160208121140.8235.49754.idtracker@ietfa.amsl.com> <8B7BDF27-834F-4D9C-A546-0C42AE6F0949@cisco.com> From: Brian Haberman Message-ID: <56B8E0EC.9040908@innovationslab.net> Date: Mon, 8 Feb 2016 13:39:40 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <8B7BDF27-834F-4D9C-A546-0C42AE6F0949@cisco.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="L0CCDcxHoT2xC2QRc7UNEVBU5nqWd4gCO" Archived-At: Cc: "dhc-chairs@ietf.org" , The IESG , "dhcwg@ietf.org" , Stephen Farrell , "draft-ietf-dhc-access-network-identifier@ietf.org" Subject: Re: [dhcwg] Stephen Farrell's Discuss on draft-ietf-dhc-access-network-identifier-13: (with DISCUSS and COMMENT) X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Feb 2016 18:39:44 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --L0CCDcxHoT2xC2QRc7UNEVBU5nqWd4gCO Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Bernie & Sri, On 2/8/16 1:08 PM, Bernie Volz (volz) wrote: > Agree with Sri's points. DHC wg would like to advance draft. >=20 > - Bernie (from iPhone) >=20 >> On Feb 8, 2016, at 12:44 PM, Sri Gundavelli (sgundave) wrote: >> >> >> Thanks Stephen. If I read this correctly, I assume this is the only >> pending DISCUSS point. >> >> >>> "Did the DHC working group consider how this information, when sent >>> without adequate protection between relay and dhcp server, could help= in >>> pervasive monitoring?" >> >> I will let chairs answer this question. I would like a chair to explicitly answer Stephen's question above and provide a pointer to the mailing list archives or meeting minutes where this point was discussed. Specifically, did the WG reach a consensus on the sensitive information elements and their vulnerability to pervasive monitoring? Regards, Brian >> >> >> But, from my point view: >> >> 1.) we have identified the information elements that are sensitive in >> nature from privacy point of view >> 2.) we have identified the interfaces where these information elements= can >> possibly get exposed; interfaces where threats can be activated >> 3.) we have listed the deployment context (Ex: Single operator) >> 4.) we have listed considerations on how to entities have to deal with= >> this data; points such as not to store the data at DHCP server ..etc. >> 4.) we have listed the existing tools that are available for the opera= tor >> to mitigate that threat >> >> All of these points were discussed in the DHC WG and there were no >> explicit comments either supporting, or disagreeing with these views. >> >> >> Regards >> Sri >> >> >> >> >> >> >> >> >> >>> On 2/8/16, 4:11 AM, "Stephen Farrell" wro= te: >>> >>> Stephen Farrell has entered the following ballot position for >>> draft-ietf-dhc-access-network-identifier-13: Discuss >>> >>> When responding, please keep the subject line intact and reply to all= >>> email addresses included in the To and CC lines. (Feel free to cut th= is >>> introductory paragraph, however.) >>> >>> >>> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.= html >>> for more information about IESG DISCUSS and COMMENT positions. >>> >>> >>> The document, along with other ballot positions, can be found here: >>> https://datatracker.ietf.org/doc/draft-ietf-dhc-access-network-identi= fier/ >>> >>> >>> >>> ---------------------------------------------------------------------= - >>> DISCUSS: >>> ---------------------------------------------------------------------= - >>> >>> >>> Thanks for the changes made in response to my and, in particular, >>> Alissa's discuss ballots. >>> >>> Having looked back at the email thread I don't believe I got any >>> answer to the question "Did the DHC working group consider how >>> this information, when sent without adequate protection between >>> relay and dhcp server, could help in pervasive monitoring?" >>> >>> I think the focus of the discussion has been on the applicability of >>> this being limited to "typically" one operator's network, which >>> does of course mean that the traffic is less at risk than had it >>> transited many networks. However, we have seen (Belgacom) that >>> the PM threat also applies within a single operator's network. >>> So I am still interested in the answer to the above question. >>> >>> The DHC WG might consider this threat and still conclude that >>> a SHOULD statement about IPsec is the best we can do in practice, >>> but that isn't clear to me at present, so I'd still like to chat abou= t >>> the PM threat. (Note: it's the WG's consideration of the threat >>> I'd like to chat about, not only about the potential of IPsec to >>> mitigate that threat.) >>> >>> >>> ---------------------------------------------------------------------= - >>> COMMENT: >>> ---------------------------------------------------------------------= - >>> >>> >>> >>> >>> OLD DISCUSS TEXT BELOW: >>> >>> (Sent mail 2016-01-10, checking on change vs. discuss) >>> >>> (1) Did the DHC working group consider how this information, >>> when sent without adequate protection between relay and dhcp >>> server, could help in pervasive monitoring? If so, what was the >>> conclusion reached? We have seen http header field information >>> sent between infrastructure nodes being intercepted for that >>> purpose, so this has to be similarly at risk. If the answer is >>> that this is only to be used within a single network operator's >>> setup (or a roaming arrangement) then that needs to be >>> justified (as practical) and, if it can be justified (I'm not >>> sure tbh), also made explicit. >>> >>> (2) I had a DISCUSS on the draft that became rfc 6757 about >>> protection of this kind of data. In that context I think I was >>> assured that everything (in PMIPv6) was IPsec protected so it >>> was fine. Why, in what we now know is a more threated >>> environment, is it ok to now have weaker protection when I was >>> assured then that IPsec was in fact quite usable in PMIPv6? I >>> think you maybe need to put in a MUST use IPsec requirement for >>> this to be as safe. >>> >>> (3) section 7: MAY store - this is possibly sensitive >>> information so you ought say that it SHOULD NOT be stored >>> unless needed, and if stored, SHOULD be deleted as soon as >>> possible. Storing sensitive information when not needed just >>> shouldn't be considered acceptable anymore I think - is that >>> reasonable? >>> >>> OLD COMMENT TEXT BELOW >>> >>> - I (strongly) support Alissa's DISCUSS and will be interested >>> in watching how that is resolved. Some of my DISCUSS points do >>> overlap though so from my POV feel free to mix'n'match the >>> discussions. Or to process first one then the other, whatever >>> you think is best. >>> >>> - RFC6757 defines exactly this for PMIPv6. That implies that >>> PMIPv6 should not be used to illustrate or motivate this, as >>> that problem is solved. Perhaps you would be better off if you >>> limited the scope of this to be used for networks that are some >>> kind of extension to PMIPv6 only? (You'd need to define what >>> kind I think.) >> --L0CCDcxHoT2xC2QRc7UNEVBU5nqWd4gCO Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2 iQEcBAEBCAAGBQJWuODsAAoJEBOZRqCi7goqkggH/1mb2Mwb3wwcvEuxSZZRXoic Z37M7EW2MLy9Dx9BcDHY79AmkDYWrYX0cESpF6gc2qiav+3qpOvwr3CFfgKHpF5z LlwXZD3soJoHcWz5/yiEeXmP2XE8qCWiQvKXxWsbeu4STe/3/AwJCmSViACbIZDv DYs4yaaesJ7bTIKMM8WpUinqMs6UtMGxGGCLXy/qx1YPJxbXcc3JKj6a1eZgjejL 3D/xeQcRfs5dzI8KJa06GNc3ON/W1ZfR9E2OofJJ8aAaVkloIen5FWXp2l3Nj9jp wTYWHFfvO8W/RIp8lmYpCXKdvAlSL/RP3jpcKYCnYlRXxFw8O4Vmv/n4w9hNics= =iRSi -----END PGP SIGNATURE----- --L0CCDcxHoT2xC2QRc7UNEVBU5nqWd4gCO-- From nobody Mon Feb 8 11:42:20 2016 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 717091B324B; Mon, 8 Feb 2016 11:42:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 dAtbw6_aExUK; Mon, 8 Feb 2016 11:42:16 -0800 (PST) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 835071B3242; Mon, 8 Feb 2016 11:42:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8994; q=dns/txt; s=iport; t=1454960536; x=1456170136; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=f3AKT5kaydWy6pJlgihk7F+5J9klPU6KqXKO9zDRFiE=; b=ddIkmkz8RThOEOMJMs+1/lHYG8gfXmmCK3ZElIzKv4uZ/xHIqvf/iuB9 orGxX9lGCi1FKWm0EDzTEKxQY4MpSaN5qW/kTdBDI9oHxlItTi+JL+Wqu eI44BtHBCzpyvTWkwI/VpNOh9+Gc2TVeNhN70aGnA+t0r1pi38Jg11T+f E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D2AQDP7rhW/51dJa1egzpSbQaIVa57g?= =?us-ascii?q?hMBDYFmI4VqAoEvOBQBAQEBAQEBgQqEQQEBAQQ6NAsMBAIBCBEEAQEBHgUEBzI?= =?us-ascii?q?UCQgCBAENBQiIEw4DvV0BAQEBAQEBAQEBAQEBAQEBAQEBAQERBIlOe4QCCgYCA?= =?us-ascii?q?QVKhAgFh1OPIgGFS4d9gWKEQ4MmhS+OPQEeAQFCggMZFIE0agGHGT18AQEB?= X-IronPort-AV: E=Sophos;i="5.22,417,1449532800"; d="scan'208";a="236221423" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 08 Feb 2016 19:42:15 +0000 Received: from XCH-RCD-008.cisco.com (xch-rcd-008.cisco.com [173.37.102.18]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id u18JgFtS017401 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 8 Feb 2016 19:42:15 GMT Received: from xch-aln-003.cisco.com (173.36.7.13) by XCH-RCD-008.cisco.com (173.37.102.18) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 8 Feb 2016 13:42:14 -0600 Received: from xch-aln-003.cisco.com ([173.36.7.13]) by XCH-ALN-003.cisco.com ([173.36.7.13]) with mapi id 15.00.1104.009; Mon, 8 Feb 2016 13:42:14 -0600 From: "Bernie Volz (volz)" To: Brian Haberman , "Sri Gundavelli (sgundave)" Thread-Topic: Stephen Farrell's Discuss on draft-ietf-dhc-access-network-identifier-13: (with DISCUSS and COMMENT) Thread-Index: AQHRYphQFWIC9raxVkyLJ60SydOYTp8icl7lgABtKQD//6bzQA== Date: Mon, 8 Feb 2016 19:42:14 +0000 Message-ID: References: <20160208121140.8235.49754.idtracker@ietfa.amsl.com> <8B7BDF27-834F-4D9C-A546-0C42AE6F0949@cisco.com> <56B8E0EC.9040908@innovationslab.net> In-Reply-To: <56B8E0EC.9040908@innovationslab.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.98.1.195] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "dhc-chairs@ietf.org" , The IESG , "dhcwg@ietf.org" , Stephen Farrell , "draft-ietf-dhc-access-network-identifier@ietf.org" Subject: Re: [dhcwg] Stephen Farrell's Discuss on draft-ietf-dhc-access-network-identifier-13: (with DISCUSS and COMMENT) X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Feb 2016 19:42:19 -0000 Brian: I am not aware of such a specific discussion in the record ... that doesn't= mean it wasn't had, but just that I am not aware of any specific record. N= ote that these emails and others regarding Stephen's discusses were sent to= the DHC WG mailing list but did not generate any comments (except those fr= om the co-authors). We generally view the information that is exchanged between a relay and ser= ver are in "one" operator's domain and that this can be (and should be) sec= ured (such as using IPsec and/or VPNs -- RFC 3315 already outlines IPsec us= age). And, that if some third party can monitor this flow, there is a lot m= ore that they can gather that is much more sensitive than these particular = options. The current privacy drafts (draft-ietf-dhc-dhcpv6-privacy-03, draft-ietf-dh= c-dhcp-privacy-03, draft-ietf-dhc-anonymity-profile-06) have focused on the= client interaction as that is viewed as being the most susceptible to perv= asive monitoring (as typically it requires just listening for packets, or e= ntering promiscuous mode). We did send notification of those 3 privacy draf= ts to the pervasive monitoring mailing list and receive absolutely no feedb= ack on them (https://mailarchive.ietf.org/arch/msg/perpass/oFlTXR0LZalQZy9W= 5nKs2ZVfVFM) - good or bad. The WG has been working on seDhcpv6 but that has been a challenging documen= t and has been sent back to the WG several times now - but this work also p= rimarily focuses on the client to server communication. Finally, these options, as all relay and client options are just hitching a= ride on the DHCP exchange. So if this is a serious issue that the IESG and= /or Int Area Directors feel the DHC WG needs to address, we can discuss at = IETF-95 to see if there is interest from the WG to attempt to address the r= elay to server communication channel to assure it is secure and prevents pe= rvasive monitoring. - Bernie -----Original Message----- From: Brian Haberman [mailto:brian@innovationslab.net]=20 Sent: Monday, February 08, 2016 1:40 PM To: Bernie Volz (volz) ; Sri Gundavelli (sgundave) Cc: Stephen Farrell ; The IESG ; = draft-ietf-dhc-access-network-identifier@ietf.org; dhc-chairs@ietf.org; jia= ngsheng@huawei.com; dhcwg@ietf.org Subject: Re: Stephen Farrell's Discuss on draft-ietf-dhc-access-network-ide= ntifier-13: (with DISCUSS and COMMENT) Hi Bernie & Sri, On 2/8/16 1:08 PM, Bernie Volz (volz) wrote: > Agree with Sri's points. DHC wg would like to advance draft. >=20 > - Bernie (from iPhone) >=20 >> On Feb 8, 2016, at 12:44 PM, Sri Gundavelli (sgundave) wrote: >> >> >> Thanks Stephen. If I read this correctly, I assume this is the only=20 >> pending DISCUSS point. >> >> >>> "Did the DHC working group consider how this information, when sent=20 >>> without adequate protection between relay and dhcp server, could=20 >>> help in pervasive monitoring?" >> >> I will let chairs answer this question. I would like a chair to explicitly answer Stephen's question above and prov= ide a pointer to the mailing list archives or meeting minutes where this po= int was discussed. Specifically, did the WG reach a consensus on the sensitive information ele= ments and their vulnerability to pervasive monitoring? Regards, Brian >> >> >> But, from my point view: >> >> 1.) we have identified the information elements that are sensitive in=20 >> nature from privacy point of view >> 2.) we have identified the interfaces where these information=20 >> elements can possibly get exposed; interfaces where threats can be=20 >> activated >> 3.) we have listed the deployment context (Ex: Single operator) >> 4.) we have listed considerations on how to entities have to deal=20 >> with this data; points such as not to store the data at DHCP server ..et= c. >> 4.) we have listed the existing tools that are available for the=20 >> operator to mitigate that threat >> >> All of these points were discussed in the DHC WG and there were no=20 >> explicit comments either supporting, or disagreeing with these views. >> >> >> Regards >> Sri >> >> >> >> >> >> >> >> >> >>> On 2/8/16, 4:11 AM, "Stephen Farrell" wrote= : >>> >>> Stephen Farrell has entered the following ballot position for >>> draft-ietf-dhc-access-network-identifier-13: Discuss >>> >>> When responding, please keep the subject line intact and reply to=20 >>> all email addresses included in the To and CC lines. (Feel free to=20 >>> cut this introductory paragraph, however.) >>> >>> >>> Please refer to=20 >>> https://www.ietf.org/iesg/statement/discuss-criteria.html >>> for more information about IESG DISCUSS and COMMENT positions. >>> >>> >>> The document, along with other ballot positions, can be found here: >>> https://datatracker.ietf.org/doc/draft-ietf-dhc-access-network-ident >>> ifier/ >>> >>> >>> >>> -------------------------------------------------------------------- >>> -- >>> DISCUSS: >>> -------------------------------------------------------------------- >>> -- >>> >>> >>> Thanks for the changes made in response to my and, in particular,=20 >>> Alissa's discuss ballots. >>> >>> Having looked back at the email thread I don't believe I got any=20 >>> answer to the question "Did the DHC working group consider how this=20 >>> information, when sent without adequate protection between relay and=20 >>> dhcp server, could help in pervasive monitoring?" >>> >>> I think the focus of the discussion has been on the applicability of=20 >>> this being limited to "typically" one operator's network, which does=20 >>> of course mean that the traffic is less at risk than had it=20 >>> transited many networks. However, we have seen (Belgacom) that the=20 >>> PM threat also applies within a single operator's network. >>> So I am still interested in the answer to the above question. >>> >>> The DHC WG might consider this threat and still conclude that a=20 >>> SHOULD statement about IPsec is the best we can do in practice, but=20 >>> that isn't clear to me at present, so I'd still like to chat about=20 >>> the PM threat. (Note: it's the WG's consideration of the threat I'd=20 >>> like to chat about, not only about the potential of IPsec to=20 >>> mitigate that threat.) >>> >>> >>> -------------------------------------------------------------------- >>> -- >>> COMMENT: >>> -------------------------------------------------------------------- >>> -- >>> >>> >>> >>> >>> OLD DISCUSS TEXT BELOW: >>> >>> (Sent mail 2016-01-10, checking on change vs. discuss) >>> >>> (1) Did the DHC working group consider how this information, when=20 >>> sent without adequate protection between relay and dhcp server,=20 >>> could help in pervasive monitoring? If so, what was the conclusion=20 >>> reached? We have seen http header field information sent between=20 >>> infrastructure nodes being intercepted for that purpose, so this has=20 >>> to be similarly at risk. If the answer is that this is only to be=20 >>> used within a single network operator's setup (or a roaming=20 >>> arrangement) then that needs to be justified (as practical) and, if=20 >>> it can be justified (I'm not sure tbh), also made explicit. >>> >>> (2) I had a DISCUSS on the draft that became rfc 6757 about=20 >>> protection of this kind of data. In that context I think I was=20 >>> assured that everything (in PMIPv6) was IPsec protected so it was=20 >>> fine. Why, in what we now know is a more threated environment, is=20 >>> it ok to now have weaker protection when I was assured then that=20 >>> IPsec was in fact quite usable in PMIPv6? I think you maybe need to=20 >>> put in a MUST use IPsec requirement for this to be as safe. >>> >>> (3) section 7: MAY store - this is possibly sensitive information so=20 >>> you ought say that it SHOULD NOT be stored unless needed, and if=20 >>> stored, SHOULD be deleted as soon as possible. Storing sensitive=20 >>> information when not needed just shouldn't be considered acceptable=20 >>> anymore I think - is that reasonable? >>> >>> OLD COMMENT TEXT BELOW >>> >>> - I (strongly) support Alissa's DISCUSS and will be interested in=20 >>> watching how that is resolved. Some of my DISCUSS points do overlap=20 >>> though so from my POV feel free to mix'n'match the discussions. Or=20 >>> to process first one then the other, whatever you think is best. >>> >>> - RFC6757 defines exactly this for PMIPv6. That implies that >>> PMIPv6 should not be used to illustrate or motivate this, as that=20 >>> problem is solved. Perhaps you would be better off if you limited=20 >>> the scope of this to be used for networks that are some kind of=20 >>> extension to PMIPv6 only? (You'd need to define what kind I think.) >> From nobody Mon Feb 8 14:19:38 2016 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E8741B33FE; Mon, 8 Feb 2016 14:19:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.302 X-Spam-Level: X-Spam-Status: No, score=-3.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_BACKHAIR_56=1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] 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 DZOE98WdEPQ9; Mon, 8 Feb 2016 14:19:30 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 67D661B3419; Mon, 8 Feb 2016 14:19:30 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 67CA4BE58; Mon, 8 Feb 2016 22:19:28 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XWtdoIwkHRDx; Mon, 8 Feb 2016 22:19:22 +0000 (GMT) Received: from [10.87.48.75] (unknown [86.46.17.89]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 2F59BBE4C; Mon, 8 Feb 2016 22:19:21 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1454969961; bh=dusXhN5TngfpNPqBunwKcLDEn3aedK+bHwtKXoeC/gI=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=lsksW/x8jhZK2Vbc59eMMTnE3hjZWSlDoCS4lWQL7MjZR+WtSejZQD6smfOlsCPqq IB6qzdUd7AvONn5qYgX38HHA/SX+5amNh5GABwwFzSqUQjfLWsIUcqpILlrrd+dKy8 D7MRlPZ+Mm5sHAVTFqhdQZMgYnYo2O2U9vU/X0UM= To: "Bernie Volz (volz)" , Brian Haberman , "Sri Gundavelli (sgundave)" References: <20160208121140.8235.49754.idtracker@ietfa.amsl.com> <8B7BDF27-834F-4D9C-A546-0C42AE6F0949@cisco.com> <56B8E0EC.9040908@innovationslab.net> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= X-Enigmail-Draft-Status: N1110 Message-ID: <56B91468.3070408@cs.tcd.ie> Date: Mon, 8 Feb 2016 22:19:20 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: "dhc-chairs@ietf.org" , The IESG , "dhcwg@ietf.org" , "draft-ietf-dhc-access-network-identifier@ietf.org" Subject: Re: [dhcwg] Stephen Farrell's Discuss on draft-ietf-dhc-access-network-identifier-13: (with DISCUSS and COMMENT) X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Feb 2016 22:19:34 -0000 Hi Bernie, On 08/02/16 19:42, Bernie Volz (volz) wrote: > Brian: > > I am not aware of such a specific discussion in the record ... Thanks for clarifying. > that > doesn't mean it wasn't had, but just that I am not aware of any > specific record. Note that these emails and others regarding > Stephen's discusses were sent to the DHC WG mailing list but did not > generate any comments (except those from the co-authors). Yeah, that's a fair comment. I would hope that if list members had opinions, they'd express them. > We generally view the information that is exchanged between a relay > and server are in "one" operator's domain and that this can be (and > should be) secured (such as using IPsec and/or VPNs -- RFC 3315 > already outlines IPsec usage). And, that if some third party can > monitor this flow, there is a lot more that they can gather that is > much more sensitive than these particular options. > > The current privacy drafts (draft-ietf-dhc-dhcpv6-privacy-03, > draft-ietf-dhc-dhcp-privacy-03, draft-ietf-dhc-anonymity-profile-06) > have focused on the client interaction as that is viewed as being the > most susceptible to pervasive monitoring (as typically it requires > just listening for packets, or entering promiscuous mode). We did > send notification of those 3 privacy drafts to the pervasive > monitoring mailing list and receive absolutely no feedback on them > (https://mailarchive.ietf.org/arch/msg/perpass/oFlTXR0LZalQZy9W5nKs2ZVfVFM) > - good or bad. Yes, getting more comment is often hard but I think those drafts were discussed a little on the perpass list before they were adopted by the DHCWG. If if helps I could ask again and see if that gets any more comment, happy to do that if you want, just let me know. > > The WG has been working on seDhcpv6 but that has been a challenging > document and has been sent back to the WG several times now - but > this work also primarily focuses on the client to server > communication. > > Finally, these options, as all relay and client options are just > hitching a ride on the DHCP exchange. So if this is a serious issue > that the IESG and/or Int Area Directors feel the DHC WG needs to > address, we can discuss at IETF-95 to see if there is interest from > the WG to attempt to address the relay to server communication > channel to assure it is secure and prevents pervasive monitoring. That sounds reasonable too, thanks. I'm fine to clear this discuss and see how that conversation goes. FWIW, while I'd personally not argue that DHCP relay<->server poses the absolutely most important privacy problem on the Internet, I do think the conversation could be useful - given this WG has already done the privacy and nymity drafts you mention above, it could be that this set of participants are more aware of the issues. (Or maybe not, but good if we find out:-) Thanks, S. > > - Bernie > > -----Original Message----- From: Brian Haberman > [mailto:brian@innovationslab.net] Sent: Monday, February 08, 2016 > 1:40 PM To: Bernie Volz (volz) ; Sri Gundavelli > (sgundave) Cc: Stephen Farrell > ; The IESG ; > draft-ietf-dhc-access-network-identifier@ietf.org; > dhc-chairs@ietf.org; jiangsheng@huawei.com; dhcwg@ietf.org Subject: > Re: Stephen Farrell's Discuss on > draft-ietf-dhc-access-network-identifier-13: (with DISCUSS and > COMMENT) > > Hi Bernie & Sri, > > On 2/8/16 1:08 PM, Bernie Volz (volz) wrote: >> Agree with Sri's points. DHC wg would like to advance draft. >> >> - Bernie (from iPhone) >> >>> On Feb 8, 2016, at 12:44 PM, Sri Gundavelli (sgundave) >>> wrote: >>> >>> >>> Thanks Stephen. If I read this correctly, I assume this is the >>> only pending DISCUSS point. >>> >>> >>>> "Did the DHC working group consider how this information, when >>>> sent without adequate protection between relay and dhcp server, >>>> could help in pervasive monitoring?" >>> >>> I will let chairs answer this question. > > I would like a chair to explicitly answer Stephen's question above > and provide a pointer to the mailing list archives or meeting minutes > where this point was discussed. > > Specifically, did the WG reach a consensus on the sensitive > information elements and their vulnerability to pervasive > monitoring? > > Regards, Brian > >>> >>> >>> But, from my point view: >>> >>> 1.) we have identified the information elements that are >>> sensitive in nature from privacy point of view 2.) we have >>> identified the interfaces where these information elements can >>> possibly get exposed; interfaces where threats can be activated >>> 3.) we have listed the deployment context (Ex: Single operator) >>> 4.) we have listed considerations on how to entities have to deal >>> with this data; points such as not to store the data at DHCP >>> server ..etc. 4.) we have listed the existing tools that are >>> available for the operator to mitigate that threat >>> >>> All of these points were discussed in the DHC WG and there were >>> no explicit comments either supporting, or disagreeing with these >>> views. >>> >>> >>> Regards Sri >>> >>> >>> >>> >>> >>> >>> >>> >>> >>>> On 2/8/16, 4:11 AM, "Stephen Farrell" >>>> wrote: >>>> >>>> Stephen Farrell has entered the following ballot position for >>>> draft-ietf-dhc-access-network-identifier-13: Discuss >>>> >>>> When responding, please keep the subject line intact and reply >>>> to all email addresses included in the To and CC lines. (Feel >>>> free to cut this introductory paragraph, however.) >>>> >>>> >>>> Please refer to >>>> https://www.ietf.org/iesg/statement/discuss-criteria.html for >>>> more information about IESG DISCUSS and COMMENT positions. >>>> >>>> >>>> The document, along with other ballot positions, can be found >>>> here: >>>> https://datatracker.ietf.org/doc/draft-ietf-dhc-access-network-ident >>>> >>>> ifier/ >>>> >>>> >>>> >>>> -------------------------------------------------------------------- >>>> >>>> -- >>>> DISCUSS: >>>> -------------------------------------------------------------------- >>>> >>>> -- >>>> >>>> >>>> Thanks for the changes made in response to my and, in >>>> particular, Alissa's discuss ballots. >>>> >>>> Having looked back at the email thread I don't believe I got >>>> any answer to the question "Did the DHC working group consider >>>> how this information, when sent without adequate protection >>>> between relay and dhcp server, could help in pervasive >>>> monitoring?" >>>> >>>> I think the focus of the discussion has been on the >>>> applicability of this being limited to "typically" one >>>> operator's network, which does of course mean that the traffic >>>> is less at risk than had it transited many networks. However, >>>> we have seen (Belgacom) that the PM threat also applies within >>>> a single operator's network. So I am still interested in the >>>> answer to the above question. >>>> >>>> The DHC WG might consider this threat and still conclude that a >>>> SHOULD statement about IPsec is the best we can do in >>>> practice, but that isn't clear to me at present, so I'd still >>>> like to chat about the PM threat. (Note: it's the WG's >>>> consideration of the threat I'd like to chat about, not only >>>> about the potential of IPsec to mitigate that threat.) >>>> >>>> >>>> -------------------------------------------------------------------- >>>> >>>> -- >>>> COMMENT: >>>> -------------------------------------------------------------------- >>>> >>>> -- >>>> >>>> >>>> >>>> >>>> OLD DISCUSS TEXT BELOW: >>>> >>>> (Sent mail 2016-01-10, checking on change vs. discuss) >>>> >>>> (1) Did the DHC working group consider how this information, >>>> when sent without adequate protection between relay and dhcp >>>> server, could help in pervasive monitoring? If so, what was the >>>> conclusion reached? We have seen http header field information >>>> sent between infrastructure nodes being intercepted for that >>>> purpose, so this has to be similarly at risk. If the answer is >>>> that this is only to be used within a single network operator's >>>> setup (or a roaming arrangement) then that needs to be >>>> justified (as practical) and, if it can be justified (I'm not >>>> sure tbh), also made explicit. >>>> >>>> (2) I had a DISCUSS on the draft that became rfc 6757 about >>>> protection of this kind of data. In that context I think I was >>>> assured that everything (in PMIPv6) was IPsec protected so it >>>> was fine. Why, in what we now know is a more threated >>>> environment, is it ok to now have weaker protection when I was >>>> assured then that IPsec was in fact quite usable in PMIPv6? I >>>> think you maybe need to put in a MUST use IPsec requirement for >>>> this to be as safe. >>>> >>>> (3) section 7: MAY store - this is possibly sensitive >>>> information so you ought say that it SHOULD NOT be stored >>>> unless needed, and if stored, SHOULD be deleted as soon as >>>> possible. Storing sensitive information when not needed just >>>> shouldn't be considered acceptable anymore I think - is that >>>> reasonable? >>>> >>>> OLD COMMENT TEXT BELOW >>>> >>>> - I (strongly) support Alissa's DISCUSS and will be interested >>>> in watching how that is resolved. Some of my DISCUSS points do >>>> overlap though so from my POV feel free to mix'n'match the >>>> discussions. Or to process first one then the other, whatever >>>> you think is best. >>>> >>>> - RFC6757 defines exactly this for PMIPv6. That implies that >>>> PMIPv6 should not be used to illustrate or motivate this, as >>>> that problem is solved. Perhaps you would be better off if you >>>> limited the scope of this to be used for networks that are some >>>> kind of extension to PMIPv6 only? (You'd need to define what >>>> kind I think.) >>> > From nobody Mon Feb 8 14:32:36 2016 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B3551B3422; Mon, 8 Feb 2016 14:32:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.502 X-Spam-Level: X-Spam-Status: No, score=-13.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_BACKHAIR_56=1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 TojYpT1CCeyR; Mon, 8 Feb 2016 14:32:29 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F283F1B3426; Mon, 8 Feb 2016 14:32:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=16068; q=dns/txt; s=iport; t=1454970749; x=1456180349; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=w5A/otGISgAvppGicnVH567lD6nA4K5e7n8U69DWkFk=; b=Yjy2555BrTwayjTLlth0B+Jtkub6gE7BHclctKTO/z8vrCiX1A6CSJzC b6AA7NoZ5mS3q0A6PiK5YYRsGgUPpwzwNWN1S7zGpxov1xvoQL4phYzUR ZBL9LanA7hT5llArWy7PvI0k/Fo0sWNokUFbsKSYSFlrZiZRentIbAfHn w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D3AQATF7lW/51dJa1egzpSbQaIVa5+g?= =?us-ascii?q?hMBDYFmI4VqAhyBEzgUAQEBAQEBAYEKhEEBAQEDASMEDToLBQcEAgEIEQQBAQE?= =?us-ascii?q?CAh8EAwICAjAUAQgIAgQBDQUIiAsIDq8CjnABAQEBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QERBHuIU3uEAgoGAgEFLoJqgToFh1OLG4QHAYVLh32BYoRDgyaFL449AR4BAUK?= =?us-ascii?q?CAxkUgTRqAYcZPXwBAQE?= X-IronPort-AV: E=Sophos;i="5.22,418,1449532800"; d="scan'208";a="71404595" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 08 Feb 2016 22:32:27 +0000 Received: from XCH-RCD-009.cisco.com (xch-rcd-009.cisco.com [173.37.102.19]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id u18MWRqB010240 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 8 Feb 2016 22:32:27 GMT Received: from xch-aln-003.cisco.com (173.36.7.13) by XCH-RCD-009.cisco.com (173.37.102.19) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 8 Feb 2016 16:32:26 -0600 Received: from xch-aln-003.cisco.com ([173.36.7.13]) by XCH-ALN-003.cisco.com ([173.36.7.13]) with mapi id 15.00.1104.009; Mon, 8 Feb 2016 16:32:26 -0600 From: "Bernie Volz (volz)" To: Stephen Farrell , Brian Haberman , "Sri Gundavelli (sgundave)" Thread-Topic: Stephen Farrell's Discuss on draft-ietf-dhc-access-network-identifier-13: (with DISCUSS and COMMENT) Thread-Index: AQHRYphQFWIC9raxVkyLJ60SydOYTp8icl7lgABtKQD//6bzQIAAlm0A//+dqVA= Date: Mon, 8 Feb 2016 22:32:26 +0000 Message-ID: References: <20160208121140.8235.49754.idtracker@ietfa.amsl.com> <8B7BDF27-834F-4D9C-A546-0C42AE6F0949@cisco.com> <56B8E0EC.9040908@innovationslab.net> <56B91468.3070408@cs.tcd.ie> In-Reply-To: <56B91468.3070408@cs.tcd.ie> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.98.1.195] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "dhc-chairs@ietf.org" , The IESG , "dhcwg@ietf.org" , "draft-ietf-dhc-access-network-identifier@ietf.org" Subject: Re: [dhcwg] Stephen Farrell's Discuss on draft-ietf-dhc-access-network-identifier-13: (with DISCUSS and COMMENT) X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Feb 2016 22:32:32 -0000 SGkgU3RlcGhlbiBhbmQgQnJpYW46DQoNCkkndmUgYWRkZWQgYW4gaXRlbSB0byB0aGUgbGlzdCBv ZiBhZ2VuZGEgcmVxdWVzdHMgcmVnYXJkaW5nIHRoaXMuIFNlZSBodHRwczovL2dpdGh1Yi5jb20v ZGhjd2cvd2cvd2lraS9JRVRGLTk1LShCdWVub3MtQWlyZXMpLURIQy1XRy1BZ2VuZGE6DQoNCkRI Q1AgUmVsYXkgLyBTZXJ2ZXIgQ29tbXVuaWNhdGlvbiBhbmQgUGVydmFzaXZlIE1vbml0b3Jpbmcg LSAxMCBtaW51dGVzDQoNClRpdGxlIG9mIHNlc3Npb246IERIQ1AgUmVsYXkgLyBTZXJ2ZXIgQ29t bXVuaWNhdGlvbiBhbmQgUGVydmFzaXZlIE1vbml0b3JpbmcNClByZXNlbnRlcjogVEJEIChMaWtl bHkgQmVybmllIFZvbHopDQpSZWxhdGVkIERyYWZ0czogTm9uZQ0KVGltZSBSZXF1aXJlZDogMTAg bWluDQpQdXJwb3NlIG9mIFNlc3Npb246IFRoZXJlIHdlcmUgc2V2ZXJhbCBJRVNHIGRpc2N1c3Nl cyByZWdhcmRpbmcgZHJhZnQtaWV0Zi1kaGMtYWNjZXNzLW5ldHdvcmstaWRlbnRpZmllciBhbmQg dGhlIHNlY3VyaXR5IGltcGxpY2F0aW9ucyBvZiBSZWxheSB0byBTZXJ2ZXIgY29tbXVuaWNhdGlv biwgZXNwZWNpYWxseSB3aXRoIHJlZ2FyZCB0byBQZXJ2YXNpdmUgTW9uaXRvcmluZy4gQXMgdGhl IFdHIHJlY2VudGx5IGRldmVsb3BlZCB0aGUgcHJpdmFjeSBkcmFmdHMgd2hpY2ggZm9jdXNlZCBw cmltYXJpbHkgb24gY2xpZW50L3NlcnZlciBpbnRlcmFjdGlvbiwgZG9lcyB0aGUgV0cgd2FudCB0 byB0YWtlIG9uIHdyaXRpbmcgYSBkb2N1bWVudCB0byByZXZpZXcgdGhlIFJlbGF5L1NlcnZlciBz ZWN1cml0eSBpbXBsaWNhdGlvbnMgYW5kIGhvdyBiZXN0IHRvIG1pdGlnYXRlIHRoZW0uIFNlZSBo dHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWRoYy1hY2Nlc3MtbmV0 d29yay1pZGVudGlmaWVyL2JhbGxvdC8gZm9yIG1vcmUgZGV0YWlscy4NClN1Ym1pdHRlcjogQmVy bmllIFZvbHoNCg0KLSBCZXJuaWUNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206 IFN0ZXBoZW4gRmFycmVsbCBbbWFpbHRvOnN0ZXBoZW4uZmFycmVsbEBjcy50Y2QuaWVdIA0KU2Vu dDogTW9uZGF5LCBGZWJydWFyeSAwOCwgMjAxNiA1OjE5IFBNDQpUbzogQmVybmllIFZvbHogKHZv bHopIDx2b2x6QGNpc2NvLmNvbT47IEJyaWFuIEhhYmVybWFuIDxicmlhbkBpbm5vdmF0aW9uc2xh Yi5uZXQ+OyBTcmkgR3VuZGF2ZWxsaSAoc2d1bmRhdmUpIDxzZ3VuZGF2ZUBjaXNjby5jb20+DQpD YzogVGhlIElFU0cgPGllc2dAaWV0Zi5vcmc+OyBkcmFmdC1pZXRmLWRoYy1hY2Nlc3MtbmV0d29y ay1pZGVudGlmaWVyQGlldGYub3JnOyBkaGMtY2hhaXJzQGlldGYub3JnOyBqaWFuZ3NoZW5nQGh1 YXdlaS5jb207IGRoY3dnQGlldGYub3JnDQpTdWJqZWN0OiBSZTogU3RlcGhlbiBGYXJyZWxsJ3Mg RGlzY3VzcyBvbiBkcmFmdC1pZXRmLWRoYy1hY2Nlc3MtbmV0d29yay1pZGVudGlmaWVyLTEzOiAo d2l0aCBESVNDVVNTIGFuZCBDT01NRU5UKQ0KDQoNCkhpIEJlcm5pZSwNCg0KT24gMDgvMDIvMTYg MTk6NDIsIEJlcm5pZSBWb2x6ICh2b2x6KSB3cm90ZToNCj4gQnJpYW46DQo+IA0KPiBJIGFtIG5v dCBhd2FyZSBvZiBzdWNoIGEgc3BlY2lmaWMgZGlzY3Vzc2lvbiBpbiB0aGUgcmVjb3JkIC4uLiAN Cg0KVGhhbmtzIGZvciBjbGFyaWZ5aW5nLg0KDQo+IHRoYXQNCj4gZG9lc24ndCBtZWFuIGl0IHdh c24ndCBoYWQsIGJ1dCBqdXN0IHRoYXQgSSBhbSBub3QgYXdhcmUgb2YgYW55IA0KPiBzcGVjaWZp YyByZWNvcmQuIE5vdGUgdGhhdCB0aGVzZSBlbWFpbHMgYW5kIG90aGVycyByZWdhcmRpbmcgU3Rl cGhlbidzIA0KPiBkaXNjdXNzZXMgd2VyZSBzZW50IHRvIHRoZSBESEMgV0cgbWFpbGluZyBsaXN0 IGJ1dCBkaWQgbm90IGdlbmVyYXRlIA0KPiBhbnkgY29tbWVudHMgKGV4Y2VwdCB0aG9zZSBmcm9t IHRoZSBjby1hdXRob3JzKS4NCg0KWWVhaCwgdGhhdCdzIGEgZmFpciBjb21tZW50LiBJIHdvdWxk IGhvcGUgdGhhdCBpZiBsaXN0IG1lbWJlcnMgaGFkIG9waW5pb25zLCB0aGV5J2QgZXhwcmVzcyB0 aGVtLg0KDQo+IFdlIGdlbmVyYWxseSB2aWV3IHRoZSBpbmZvcm1hdGlvbiB0aGF0IGlzIGV4Y2hh bmdlZCBiZXR3ZWVuIGEgcmVsYXkgDQo+IGFuZCBzZXJ2ZXIgYXJlIGluICJvbmUiIG9wZXJhdG9y J3MgZG9tYWluIGFuZCB0aGF0IHRoaXMgY2FuIGJlIChhbmQgDQo+IHNob3VsZCBiZSkgc2VjdXJl ZCAoc3VjaCBhcyB1c2luZyBJUHNlYyBhbmQvb3IgVlBOcyAtLSBSRkMgMzMxNSANCj4gYWxyZWFk eSBvdXRsaW5lcyBJUHNlYyB1c2FnZSkuIEFuZCwgdGhhdCBpZiBzb21lIHRoaXJkIHBhcnR5IGNh biANCj4gbW9uaXRvciB0aGlzIGZsb3csIHRoZXJlIGlzIGEgbG90IG1vcmUgdGhhdCB0aGV5IGNh biBnYXRoZXIgdGhhdCBpcyANCj4gbXVjaCBtb3JlIHNlbnNpdGl2ZSB0aGFuIHRoZXNlIHBhcnRp Y3VsYXIgb3B0aW9ucy4NCj4gDQo+IFRoZSBjdXJyZW50IHByaXZhY3kgZHJhZnRzIChkcmFmdC1p ZXRmLWRoYy1kaGNwdjYtcHJpdmFjeS0wMywNCj4gZHJhZnQtaWV0Zi1kaGMtZGhjcC1wcml2YWN5 LTAzLCBkcmFmdC1pZXRmLWRoYy1hbm9ueW1pdHktcHJvZmlsZS0wNikNCj4gaGF2ZSBmb2N1c2Vk IG9uIHRoZSBjbGllbnQgaW50ZXJhY3Rpb24gYXMgdGhhdCBpcyB2aWV3ZWQgYXMgYmVpbmcgdGhl IA0KPiBtb3N0IHN1c2NlcHRpYmxlIHRvIHBlcnZhc2l2ZSBtb25pdG9yaW5nIChhcyB0eXBpY2Fs bHkgaXQgcmVxdWlyZXMgDQo+IGp1c3QgbGlzdGVuaW5nIGZvciBwYWNrZXRzLCBvciBlbnRlcmlu ZyBwcm9taXNjdW91cyBtb2RlKS4gV2UgZGlkIHNlbmQgDQo+IG5vdGlmaWNhdGlvbiBvZiB0aG9z ZSAzIHByaXZhY3kgZHJhZnRzIHRvIHRoZSBwZXJ2YXNpdmUgbW9uaXRvcmluZyANCj4gbWFpbGlu ZyBsaXN0IGFuZCByZWNlaXZlIGFic29sdXRlbHkgbm8gZmVlZGJhY2sgb24gdGhlbQ0KPiAoaHR0 cHM6Ly9tYWlsYXJjaGl2ZS5pZXRmLm9yZy9hcmNoL21zZy9wZXJwYXNzL29GbFRYUjBMWmFsUVp5 OVc1bktzMlpWDQo+IGZWRk0pDQo+IC0gZ29vZCBvciBiYWQuDQoNClllcywgZ2V0dGluZyBtb3Jl IGNvbW1lbnQgaXMgb2Z0ZW4gaGFyZCBidXQgSSB0aGluayB0aG9zZSBkcmFmdHMgd2VyZSBkaXNj dXNzZWQgYSBsaXR0bGUgb24gdGhlIHBlcnBhc3MgbGlzdCBiZWZvcmUgdGhleSB3ZXJlIGFkb3B0 ZWQgYnkgdGhlIERIQ1dHLiBJZiBpZiBoZWxwcyBJIGNvdWxkIGFzayBhZ2FpbiBhbmQgc2VlIGlm IHRoYXQgZ2V0cyBhbnkgbW9yZSBjb21tZW50LCBoYXBweSB0byBkbyB0aGF0IGlmIHlvdSB3YW50 LCBqdXN0IGxldCBtZSBrbm93Lg0KDQo+IA0KPiBUaGUgV0cgaGFzIGJlZW4gd29ya2luZyBvbiBz ZURoY3B2NiBidXQgdGhhdCBoYXMgYmVlbiBhIGNoYWxsZW5naW5nIA0KPiBkb2N1bWVudCBhbmQg aGFzIGJlZW4gc2VudCBiYWNrIHRvIHRoZSBXRyBzZXZlcmFsIHRpbWVzIG5vdyAtIGJ1dCB0aGlz IA0KPiB3b3JrIGFsc28gcHJpbWFyaWx5IGZvY3VzZXMgb24gdGhlIGNsaWVudCB0byBzZXJ2ZXIg Y29tbXVuaWNhdGlvbi4NCj4gDQo+IEZpbmFsbHksIHRoZXNlIG9wdGlvbnMsIGFzIGFsbCByZWxh eSBhbmQgY2xpZW50IG9wdGlvbnMgYXJlIGp1c3QgDQo+IGhpdGNoaW5nIGEgcmlkZSBvbiB0aGUg REhDUCBleGNoYW5nZS4gU28gaWYgdGhpcyBpcyBhIHNlcmlvdXMgaXNzdWUgDQo+IHRoYXQgdGhl IElFU0cgYW5kL29yIEludCBBcmVhIERpcmVjdG9ycyBmZWVsIHRoZSBESEMgV0cgbmVlZHMgdG8g DQo+IGFkZHJlc3MsIHdlIGNhbiBkaXNjdXNzIGF0IElFVEYtOTUgdG8gc2VlIGlmIHRoZXJlIGlz IGludGVyZXN0IGZyb20gDQo+IHRoZSBXRyB0byBhdHRlbXB0IHRvIGFkZHJlc3MgdGhlIHJlbGF5 IHRvIHNlcnZlciBjb21tdW5pY2F0aW9uIGNoYW5uZWwgDQo+IHRvIGFzc3VyZSBpdCBpcyBzZWN1 cmUgYW5kIHByZXZlbnRzIHBlcnZhc2l2ZSBtb25pdG9yaW5nLg0KDQpUaGF0IHNvdW5kcyByZWFz b25hYmxlIHRvbywgdGhhbmtzLiBJJ20gZmluZSB0byBjbGVhciB0aGlzIGRpc2N1c3MgYW5kIHNl ZSBob3cgdGhhdCBjb252ZXJzYXRpb24gZ29lcy4NCg0KRldJVywgd2hpbGUgSSdkIHBlcnNvbmFs bHkgbm90IGFyZ3VlIHRoYXQgREhDUCByZWxheTwtPnNlcnZlciBwb3NlcyB0aGUgYWJzb2x1dGVs eSBtb3N0IGltcG9ydGFudCBwcml2YWN5IHByb2JsZW0gb24gdGhlIEludGVybmV0LCBJIGRvIHRo aW5rIHRoZSBjb252ZXJzYXRpb24gY291bGQgYmUgdXNlZnVsIC0gZ2l2ZW4gdGhpcyBXRyBoYXMg YWxyZWFkeSBkb25lIHRoZSBwcml2YWN5IGFuZCBueW1pdHkgZHJhZnRzIHlvdSBtZW50aW9uIGFi b3ZlLCBpdCBjb3VsZCBiZSB0aGF0IHRoaXMgc2V0IG9mIHBhcnRpY2lwYW50cyBhcmUgbW9yZSBh d2FyZSBvZiB0aGUgaXNzdWVzLiAoT3IgbWF5YmUgbm90LCBidXQgZ29vZCBpZiB3ZSBmaW5kIG91 dDotKQ0KDQpUaGFua3MsDQpTLg0KDQoNCj4gDQo+IC0gQmVybmllDQo+IA0KPiAtLS0tLU9yaWdp bmFsIE1lc3NhZ2UtLS0tLSBGcm9tOiBCcmlhbiBIYWJlcm1hbiANCj4gW21haWx0bzpicmlhbkBp bm5vdmF0aW9uc2xhYi5uZXRdIFNlbnQ6IE1vbmRheSwgRmVicnVhcnkgMDgsIDIwMTYNCj4gMTo0 MCBQTSBUbzogQmVybmllIFZvbHogKHZvbHopIDx2b2x6QGNpc2NvLmNvbT47IFNyaSBHdW5kYXZl bGxpDQo+IChzZ3VuZGF2ZSkgPHNndW5kYXZlQGNpc2NvLmNvbT4gQ2M6IFN0ZXBoZW4gRmFycmVs bCANCj4gPHN0ZXBoZW4uZmFycmVsbEBjcy50Y2QuaWU+OyBUaGUgSUVTRyA8aWVzZ0BpZXRmLm9y Zz47IA0KPiBkcmFmdC1pZXRmLWRoYy1hY2Nlc3MtbmV0d29yay1pZGVudGlmaWVyQGlldGYub3Jn Ow0KPiBkaGMtY2hhaXJzQGlldGYub3JnOyBqaWFuZ3NoZW5nQGh1YXdlaS5jb207IGRoY3dnQGll dGYub3JnIFN1YmplY3Q6DQo+IFJlOiBTdGVwaGVuIEZhcnJlbGwncyBEaXNjdXNzIG9uDQo+IGRy YWZ0LWlldGYtZGhjLWFjY2Vzcy1uZXR3b3JrLWlkZW50aWZpZXItMTM6ICh3aXRoIERJU0NVU1Mg YW5kDQo+IENPTU1FTlQpDQo+IA0KPiBIaSBCZXJuaWUgJiBTcmksDQo+IA0KPiBPbiAyLzgvMTYg MTowOCBQTSwgQmVybmllIFZvbHogKHZvbHopIHdyb3RlOg0KPj4gQWdyZWUgd2l0aCBTcmkncyBw b2ludHMuIERIQyB3ZyB3b3VsZCBsaWtlIHRvIGFkdmFuY2UgZHJhZnQuDQo+PiANCj4+IC0gQmVy bmllIChmcm9tIGlQaG9uZSkNCj4+IA0KPj4+IE9uIEZlYiA4LCAyMDE2LCBhdCAxMjo0NCBQTSwg U3JpIEd1bmRhdmVsbGkgKHNndW5kYXZlKSANCj4+PiA8c2d1bmRhdmVAY2lzY28uY29tPiB3cm90 ZToNCj4+PiANCj4+PiANCj4+PiBUaGFua3MgU3RlcGhlbi4gIElmIEkgcmVhZCB0aGlzIGNvcnJl Y3RseSwgSSBhc3N1bWUgdGhpcyBpcyB0aGUgb25seSANCj4+PiBwZW5kaW5nIERJU0NVU1MgcG9p bnQuDQo+Pj4gDQo+Pj4gDQo+Pj4+ICJEaWQgdGhlIERIQyB3b3JraW5nIGdyb3VwIGNvbnNpZGVy IGhvdyB0aGlzIGluZm9ybWF0aW9uLCB3aGVuIHNlbnQgDQo+Pj4+IHdpdGhvdXQgYWRlcXVhdGUg cHJvdGVjdGlvbiBiZXR3ZWVuIHJlbGF5IGFuZCBkaGNwIHNlcnZlciwgY291bGQgDQo+Pj4+IGhl bHAgaW4gcGVydmFzaXZlIG1vbml0b3Jpbmc/Ig0KPj4+IA0KPj4+IEkgd2lsbCBsZXQgY2hhaXJz IGFuc3dlciB0aGlzIHF1ZXN0aW9uLg0KPiANCj4gSSB3b3VsZCBsaWtlIGEgY2hhaXIgdG8gZXhw bGljaXRseSBhbnN3ZXIgU3RlcGhlbidzIHF1ZXN0aW9uIGFib3ZlIGFuZCANCj4gcHJvdmlkZSBh IHBvaW50ZXIgdG8gdGhlIG1haWxpbmcgbGlzdCBhcmNoaXZlcyBvciBtZWV0aW5nIG1pbnV0ZXMg DQo+IHdoZXJlIHRoaXMgcG9pbnQgd2FzIGRpc2N1c3NlZC4NCj4gDQo+IFNwZWNpZmljYWxseSwg ZGlkIHRoZSBXRyByZWFjaCBhIGNvbnNlbnN1cyBvbiB0aGUgc2Vuc2l0aXZlIA0KPiBpbmZvcm1h dGlvbiBlbGVtZW50cyBhbmQgdGhlaXIgdnVsbmVyYWJpbGl0eSB0byBwZXJ2YXNpdmUgbW9uaXRv cmluZz8NCj4gDQo+IFJlZ2FyZHMsIEJyaWFuDQo+IA0KPj4+IA0KPj4+IA0KPj4+IEJ1dCwgZnJv bSBteSBwb2ludCB2aWV3Og0KPj4+IA0KPj4+IDEuKSB3ZSBoYXZlIGlkZW50aWZpZWQgdGhlIGlu Zm9ybWF0aW9uIGVsZW1lbnRzIHRoYXQgYXJlIHNlbnNpdGl2ZSANCj4+PiBpbiBuYXR1cmUgZnJv bSBwcml2YWN5IHBvaW50IG9mIHZpZXcgMi4pIHdlIGhhdmUgaWRlbnRpZmllZCB0aGUgDQo+Pj4g aW50ZXJmYWNlcyB3aGVyZSB0aGVzZSBpbmZvcm1hdGlvbiBlbGVtZW50cyBjYW4gcG9zc2libHkg Z2V0IA0KPj4+IGV4cG9zZWQ7IGludGVyZmFjZXMgd2hlcmUgdGhyZWF0cyBjYW4gYmUgYWN0aXZh dGVkDQo+Pj4gMy4pIHdlIGhhdmUgbGlzdGVkIHRoZSBkZXBsb3ltZW50IGNvbnRleHQgKEV4OiBT aW5nbGUgb3BlcmF0b3IpDQo+Pj4gNC4pIHdlIGhhdmUgbGlzdGVkIGNvbnNpZGVyYXRpb25zIG9u IGhvdyB0byBlbnRpdGllcyBoYXZlIHRvIGRlYWwgIA0KPj4+IHdpdGggdGhpcyBkYXRhOyBwb2lu dHMgc3VjaCBhcyBub3QgdG8gc3RvcmUgdGhlIGRhdGEgYXQgREhDUCBzZXJ2ZXIgDQo+Pj4gLi5l dGMuIDQuKSB3ZSBoYXZlIGxpc3RlZCB0aGUgZXhpc3RpbmcgdG9vbHMgdGhhdCBhcmUgYXZhaWxh YmxlIGZvciANCj4+PiB0aGUgb3BlcmF0b3IgdG8gbWl0aWdhdGUgdGhhdCB0aHJlYXQNCj4+PiAN Cj4+PiBBbGwgb2YgdGhlc2UgcG9pbnRzIHdlcmUgZGlzY3Vzc2VkIGluIHRoZSBESEMgV0cgYW5k IHRoZXJlIHdlcmUgbm8gDQo+Pj4gZXhwbGljaXQgY29tbWVudHMgZWl0aGVyIHN1cHBvcnRpbmcs IG9yIGRpc2FncmVlaW5nIHdpdGggdGhlc2UgDQo+Pj4gdmlld3MuDQo+Pj4gDQo+Pj4gDQo+Pj4g UmVnYXJkcyBTcmkNCj4+PiANCj4+PiANCj4+PiANCj4+PiANCj4+PiANCj4+PiANCj4+PiANCj4+ PiANCj4+PiANCj4+Pj4gT24gMi84LzE2LCA0OjExIEFNLCAiU3RlcGhlbiBGYXJyZWxsIg0KPj4+ PiA8c3RlcGhlbi5mYXJyZWxsQGNzLnRjZC5pZT4gd3JvdGU6DQo+Pj4+IA0KPj4+PiBTdGVwaGVu IEZhcnJlbGwgaGFzIGVudGVyZWQgdGhlIGZvbGxvd2luZyBiYWxsb3QgcG9zaXRpb24gZm9yDQo+ Pj4+IGRyYWZ0LWlldGYtZGhjLWFjY2Vzcy1uZXR3b3JrLWlkZW50aWZpZXItMTM6IERpc2N1c3MN Cj4+Pj4gDQo+Pj4+IFdoZW4gcmVzcG9uZGluZywgcGxlYXNlIGtlZXAgdGhlIHN1YmplY3QgbGlu ZSBpbnRhY3QgYW5kIHJlcGx5IHRvIA0KPj4+PiBhbGwgZW1haWwgYWRkcmVzc2VzIGluY2x1ZGVk IGluIHRoZSBUbyBhbmQgQ0MgbGluZXMuIChGZWVsIGZyZWUgdG8gDQo+Pj4+IGN1dCB0aGlzIGlu dHJvZHVjdG9yeSBwYXJhZ3JhcGgsIGhvd2V2ZXIuKQ0KPj4+PiANCj4+Pj4gDQo+Pj4+IFBsZWFz ZSByZWZlciB0bw0KPj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9pZXNnL3N0YXRlbWVudC9kaXNj dXNzLWNyaXRlcmlhLmh0bWwgZm9yIG1vcmUgDQo+Pj4+IGluZm9ybWF0aW9uIGFib3V0IElFU0cg RElTQ1VTUyBhbmQgQ09NTUVOVCBwb3NpdGlvbnMuDQo+Pj4+IA0KPj4+PiANCj4+Pj4gVGhlIGRv Y3VtZW50LCBhbG9uZyB3aXRoIG90aGVyIGJhbGxvdCBwb3NpdGlvbnMsIGNhbiBiZSBmb3VuZA0K Pj4+PiBoZXJlOiANCj4+Pj4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQt aWV0Zi1kaGMtYWNjZXNzLW5ldHdvcmstaWRlbg0KPj4+PiB0DQo+Pj4+DQo+Pj4+IA0KaWZpZXIv DQo+Pj4+IA0KPj4+PiANCj4+Pj4gDQo+Pj4+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4+Pj4gLQ0KPj4+Pg0KPj4+ PiANCi0tDQo+Pj4+IERJU0NVU1M6IA0KPj4+PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+Pj4+IC0NCj4+Pj4NCj4+ Pj4gDQotLQ0KPj4+PiANCj4+Pj4gDQo+Pj4+IFRoYW5rcyBmb3IgdGhlIGNoYW5nZXMgbWFkZSBp biByZXNwb25zZSB0byBteSBhbmQsIGluIHBhcnRpY3VsYXIsIA0KPj4+PiBBbGlzc2EncyBkaXNj dXNzIGJhbGxvdHMuDQo+Pj4+IA0KPj4+PiBIYXZpbmcgbG9va2VkIGJhY2sgYXQgdGhlIGVtYWls IHRocmVhZCBJIGRvbid0IGJlbGlldmUgSSBnb3QgYW55IA0KPj4+PiBhbnN3ZXIgdG8gdGhlIHF1 ZXN0aW9uICJEaWQgdGhlIERIQyB3b3JraW5nIGdyb3VwIGNvbnNpZGVyIGhvdyB0aGlzIA0KPj4+ PiBpbmZvcm1hdGlvbiwgd2hlbiBzZW50IHdpdGhvdXQgYWRlcXVhdGUgcHJvdGVjdGlvbiBiZXR3 ZWVuIHJlbGF5IA0KPj4+PiBhbmQgZGhjcCBzZXJ2ZXIsIGNvdWxkIGhlbHAgaW4gcGVydmFzaXZl IG1vbml0b3Jpbmc/Ig0KPj4+PiANCj4+Pj4gSSB0aGluayB0aGUgZm9jdXMgb2YgdGhlIGRpc2N1 c3Npb24gaGFzIGJlZW4gb24gdGhlIGFwcGxpY2FiaWxpdHkgDQo+Pj4+IG9mIHRoaXMgYmVpbmcg bGltaXRlZCB0byAidHlwaWNhbGx5IiBvbmUgb3BlcmF0b3IncyBuZXR3b3JrLCB3aGljaCANCj4+ Pj4gZG9lcyBvZiBjb3Vyc2UgbWVhbiB0aGF0IHRoZSB0cmFmZmljIGlzIGxlc3MgYXQgcmlzayB0 aGFuIGhhZCBpdCANCj4+Pj4gdHJhbnNpdGVkIG1hbnkgbmV0d29ya3MuIEhvd2V2ZXIsIHdlIGhh dmUgc2VlbiAoQmVsZ2Fjb20pIHRoYXQgdGhlIA0KPj4+PiBQTSB0aHJlYXQgYWxzbyBhcHBsaWVz IHdpdGhpbiBhIHNpbmdsZSBvcGVyYXRvcidzIG5ldHdvcmsuIFNvIEkgYW0gDQo+Pj4+IHN0aWxs IGludGVyZXN0ZWQgaW4gdGhlIGFuc3dlciB0byB0aGUgYWJvdmUgcXVlc3Rpb24uDQo+Pj4+IA0K Pj4+PiBUaGUgREhDIFdHIG1pZ2h0IGNvbnNpZGVyIHRoaXMgdGhyZWF0IGFuZCBzdGlsbCBjb25j bHVkZSB0aGF0IGEgIA0KPj4+PiBTSE9VTEQgc3RhdGVtZW50IGFib3V0IElQc2VjIGlzIHRoZSBi ZXN0IHdlIGNhbiBkbyBpbiBwcmFjdGljZSwgYnV0IA0KPj4+PiB0aGF0IGlzbid0IGNsZWFyIHRv IG1lIGF0IHByZXNlbnQsIHNvIEknZCBzdGlsbCBsaWtlIHRvIGNoYXQgYWJvdXQgDQo+Pj4+IHRo ZSBQTSB0aHJlYXQuIChOb3RlOiBpdCdzIHRoZSBXRydzIGNvbnNpZGVyYXRpb24gb2YgdGhlIHRo cmVhdCBJJ2QgDQo+Pj4+IGxpa2UgdG8gY2hhdCBhYm91dCwgbm90IG9ubHkgYWJvdXQgdGhlIHBv dGVudGlhbCBvZiBJUHNlYyB0byANCj4+Pj4gbWl0aWdhdGUgdGhhdCB0aHJlYXQuKQ0KPj4+PiAN Cj4+Pj4gDQo+Pj4+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4+Pj4gLQ0KPj4+Pg0KPj4+PiANCi0tDQo+Pj4+IENP TU1FTlQ6IA0KPj4+PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+Pj4+IC0NCj4+Pj4NCj4+Pj4gDQotLQ0KPj4+PiAN Cj4+Pj4gDQo+Pj4+IA0KPj4+PiANCj4+Pj4gT0xEIERJU0NVU1MgVEVYVCBCRUxPVzoNCj4+Pj4g DQo+Pj4+IChTZW50IG1haWwgMjAxNi0wMS0xMCwgY2hlY2tpbmcgb24gY2hhbmdlIHZzLiBkaXNj dXNzKQ0KPj4+PiANCj4+Pj4gKDEpIERpZCB0aGUgREhDIHdvcmtpbmcgZ3JvdXAgY29uc2lkZXIg aG93IHRoaXMgaW5mb3JtYXRpb24sIHdoZW4gDQo+Pj4+IHNlbnQgd2l0aG91dCBhZGVxdWF0ZSBw cm90ZWN0aW9uIGJldHdlZW4gcmVsYXkgYW5kIGRoY3Agc2VydmVyLCANCj4+Pj4gY291bGQgaGVs cCBpbiBwZXJ2YXNpdmUgbW9uaXRvcmluZz8gSWYgc28sIHdoYXQgd2FzIHRoZSBjb25jbHVzaW9u IA0KPj4+PiByZWFjaGVkPyBXZSBoYXZlIHNlZW4gaHR0cCBoZWFkZXIgZmllbGQgaW5mb3JtYXRp b24gc2VudCBiZXR3ZWVuIA0KPj4+PiBpbmZyYXN0cnVjdHVyZSBub2RlcyBiZWluZyBpbnRlcmNl cHRlZCBmb3IgdGhhdCBwdXJwb3NlLCBzbyB0aGlzIA0KPj4+PiBoYXMgdG8gYmUgc2ltaWxhcmx5 IGF0IHJpc2suICBJZiB0aGUgYW5zd2VyIGlzIHRoYXQgdGhpcyBpcyBvbmx5IHRvIA0KPj4+PiBi ZSB1c2VkIHdpdGhpbiBhIHNpbmdsZSBuZXR3b3JrIG9wZXJhdG9yJ3Mgc2V0dXAgKG9yIGEgcm9h bWluZyANCj4+Pj4gYXJyYW5nZW1lbnQpIHRoZW4gdGhhdCBuZWVkcyB0byBiZSBqdXN0aWZpZWQg KGFzIHByYWN0aWNhbCkgYW5kLCBpZiANCj4+Pj4gaXQgY2FuIGJlIGp1c3RpZmllZCAoSSdtIG5v dCBzdXJlIHRiaCksIGFsc28gbWFkZSBleHBsaWNpdC4NCj4+Pj4gDQo+Pj4+ICgyKSBJIGhhZCBh IERJU0NVU1Mgb24gdGhlIGRyYWZ0IHRoYXQgYmVjYW1lIHJmYyA2NzU3IGFib3V0IA0KPj4+PiBw cm90ZWN0aW9uIG9mIHRoaXMga2luZCBvZiBkYXRhLiBJbiB0aGF0IGNvbnRleHQgSSB0aGluayBJ IHdhcyAgDQo+Pj4+IGFzc3VyZWQgdGhhdCBldmVyeXRoaW5nIChpbiBQTUlQdjYpIHdhcyBJUHNl YyBwcm90ZWN0ZWQgc28gaXQgd2FzIA0KPj4+PiBmaW5lLiAgV2h5LCBpbiB3aGF0IHdlIG5vdyBr bm93IGlzIGEgbW9yZSB0aHJlYXRlZCBlbnZpcm9ubWVudCwgaXMgDQo+Pj4+IGl0IG9rIHRvIG5v dyBoYXZlIHdlYWtlciBwcm90ZWN0aW9uIHdoZW4gSSB3YXMgYXNzdXJlZCB0aGVuIHRoYXQgDQo+ Pj4+IElQc2VjIHdhcyBpbiBmYWN0IHF1aXRlIHVzYWJsZSBpbiBQTUlQdjY/IEkgdGhpbmsgeW91 IG1heWJlIG5lZWQgdG8gDQo+Pj4+IHB1dCBpbiBhIE1VU1QgdXNlIElQc2VjIHJlcXVpcmVtZW50 IGZvciB0aGlzIHRvIGJlIGFzIHNhZmUuDQo+Pj4+IA0KPj4+PiAoMykgc2VjdGlvbiA3OiBNQVkg c3RvcmUgLSB0aGlzIGlzIHBvc3NpYmx5IHNlbnNpdGl2ZSBpbmZvcm1hdGlvbiANCj4+Pj4gc28g eW91IG91Z2h0IHNheSB0aGF0IGl0IFNIT1VMRCBOT1QgYmUgc3RvcmVkIHVubGVzcyBuZWVkZWQs IGFuZCBpZiANCj4+Pj4gc3RvcmVkLCBTSE9VTEQgYmUgZGVsZXRlZCBhcyBzb29uIGFzIHBvc3Np YmxlLiBTdG9yaW5nIHNlbnNpdGl2ZSANCj4+Pj4gaW5mb3JtYXRpb24gd2hlbiBub3QgbmVlZGVk IGp1c3Qgc2hvdWxkbid0IGJlIGNvbnNpZGVyZWQgYWNjZXB0YWJsZSANCj4+Pj4gYW55bW9yZSBJ IHRoaW5rIC0gaXMgdGhhdCByZWFzb25hYmxlPw0KPj4+PiANCj4+Pj4gT0xEIENPTU1FTlQgVEVY VCBCRUxPVw0KPj4+PiANCj4+Pj4gLSBJIChzdHJvbmdseSkgc3VwcG9ydCBBbGlzc2EncyBESVND VVNTIGFuZCB3aWxsIGJlIGludGVyZXN0ZWQgaW4gDQo+Pj4+IHdhdGNoaW5nIGhvdyB0aGF0IGlz IHJlc29sdmVkLiBTb21lIG9mIG15IERJU0NVU1MgcG9pbnRzIGRvIG92ZXJsYXAgDQo+Pj4+IHRo b3VnaCBzbyBmcm9tIG15IFBPViBmZWVsIGZyZWUgdG8gbWl4J24nbWF0Y2ggdGhlIGRpc2N1c3Np b25zLiBPciANCj4+Pj4gdG8gcHJvY2VzcyBmaXJzdCBvbmUgdGhlbiB0aGUgb3RoZXIsIHdoYXRl dmVyIHlvdSB0aGluayBpcyBiZXN0Lg0KPj4+PiANCj4+Pj4gLSBSRkM2NzU3IGRlZmluZXMgZXhh Y3RseSB0aGlzIGZvciBQTUlQdjYuIFRoYXQgaW1wbGllcyB0aGF0DQo+Pj4+IFBNSVB2NiBzaG91 bGQgbm90IGJlIHVzZWQgdG8gaWxsdXN0cmF0ZSBvciBtb3RpdmF0ZSB0aGlzLCBhcyB0aGF0IA0K Pj4+PiBwcm9ibGVtIGlzIHNvbHZlZC4gUGVyaGFwcyB5b3Ugd291bGQgYmUgYmV0dGVyIG9mZiBp ZiB5b3UgbGltaXRlZCANCj4+Pj4gdGhlIHNjb3BlIG9mIHRoaXMgdG8gYmUgdXNlZCBmb3IgbmV0 d29ya3MgdGhhdCBhcmUgc29tZSBraW5kIG9mIA0KPj4+PiBleHRlbnNpb24gdG8gUE1JUHY2IG9u bHk/IChZb3UnZCBuZWVkIHRvIGRlZmluZSB3aGF0IGtpbmQgSSB0aGluay4pDQo+Pj4gDQo+IA0K From nobody Mon Feb 8 14:35:55 2016 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F3CA1B3445; Mon, 8 Feb 2016 14:35:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.302 X-Spam-Level: X-Spam-Status: No, score=-3.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_BACKHAIR_56=1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] 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 r0rdj20ERDlt; Mon, 8 Feb 2016 14:35:51 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 334921B343A; Mon, 8 Feb 2016 14:35:51 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id CC7ADBE64; Mon, 8 Feb 2016 22:35:49 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rILRfHFAWZEi; Mon, 8 Feb 2016 22:35:46 +0000 (GMT) Received: from [10.87.48.75] (unknown [86.46.17.89]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 47C53BE58; Mon, 8 Feb 2016 22:35:45 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1454970946; bh=vPmL4c8dI1B6IRpFPiw92eTiswfdSp0mgDssmRCOBKs=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=SwafPFS/ShESvxjklM2ueVON2A6XQKdicRhVbVRKz9T4Urv5BX2+Toj48PQ/wr7C/ 4hHgLjb4Y96ipbWpgkysuIDDG6tvmaB+4zQUh2JV2iv2OanSvazeHDqt+I83I4BvL+ h/Akad8vxGk26dJ9Y88aGAtbYCkj+N+goQRbfhPk= To: "Bernie Volz (volz)" , Brian Haberman , "Sri Gundavelli (sgundave)" References: <20160208121140.8235.49754.idtracker@ietfa.amsl.com> <8B7BDF27-834F-4D9C-A546-0C42AE6F0949@cisco.com> <56B8E0EC.9040908@innovationslab.net> <56B91468.3070408@cs.tcd.ie> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <56B91821.80301@cs.tcd.ie> Date: Mon, 8 Feb 2016 22:35:13 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "draft-ietf-dhc-access-network-identifier@ietf.org" , "dhc-chairs@ietf.org" , The IESG , "dhcwg@ietf.org" Subject: Re: [dhcwg] Stephen Farrell's Discuss on draft-ietf-dhc-access-network-identifier-13: (with DISCUSS and COMMENT) X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Feb 2016 22:35:54 -0000 On 08/02/16 22:32, Bernie Volz (volz) wrote: > Hi Stephen and Brian: > > I've added an item to the list of agenda requests regarding this. See > https://github.com/dhcwg/wg/wiki/IETF-95-(Buenos-Aires)-DHC-WG-Agenda: > > DHCP Relay / Server Communication and Pervasive Monitoring - 10 > minutes > > Title of session: DHCP Relay / Server Communication and Pervasive > Monitoring Presenter: TBD (Likely Bernie Volz) Related Drafts: None > Time Required: 10 min Purpose of Session: There were several IESG > discusses regarding draft-ietf-dhc-access-network-identifier and the > security implications of Relay to Server communication, especially > with regard to Pervasive Monitoring. As the WG recently developed the > privacy drafts which focused primarily on client/server interaction, > does the WG want to take on writing a document to review the > Relay/Server security implications and how best to mitigate them. See > https://datatracker.ietf.org/doc/draft-ietf-dhc-access-network-identifier/ballot/ > for more details. Submitter: Bernie Volz Great, thanks. Let me know if I can help. Cheers, S. > > - Bernie > > -----Original Message----- From: Stephen Farrell > [mailto:stephen.farrell@cs.tcd.ie] Sent: Monday, February 08, 2016 > 5:19 PM To: Bernie Volz (volz) ; Brian Haberman > ; Sri Gundavelli (sgundave) > Cc: The IESG ; > draft-ietf-dhc-access-network-identifier@ietf.org; > dhc-chairs@ietf.org; jiangsheng@huawei.com; dhcwg@ietf.org Subject: > Re: Stephen Farrell's Discuss on > draft-ietf-dhc-access-network-identifier-13: (with DISCUSS and > COMMENT) > > > Hi Bernie, > > On 08/02/16 19:42, Bernie Volz (volz) wrote: >> Brian: >> >> I am not aware of such a specific discussion in the record ... > > Thanks for clarifying. > >> that doesn't mean it wasn't had, but just that I am not aware of >> any specific record. Note that these emails and others regarding >> Stephen's discusses were sent to the DHC WG mailing list but did >> not generate any comments (except those from the co-authors). > > Yeah, that's a fair comment. I would hope that if list members had > opinions, they'd express them. > >> We generally view the information that is exchanged between a relay >> and server are in "one" operator's domain and that this can be >> (and should be) secured (such as using IPsec and/or VPNs -- RFC >> 3315 already outlines IPsec usage). And, that if some third party >> can monitor this flow, there is a lot more that they can gather >> that is much more sensitive than these particular options. >> >> The current privacy drafts (draft-ietf-dhc-dhcpv6-privacy-03, >> draft-ietf-dhc-dhcp-privacy-03, >> draft-ietf-dhc-anonymity-profile-06) have focused on the client >> interaction as that is viewed as being the most susceptible to >> pervasive monitoring (as typically it requires just listening for >> packets, or entering promiscuous mode). We did send notification of >> those 3 privacy drafts to the pervasive monitoring mailing list and >> receive absolutely no feedback on them >> (https://mailarchive.ietf.org/arch/msg/perpass/oFlTXR0LZalQZy9W5nKs2ZV >> >> fVFM) >> - good or bad. > > Yes, getting more comment is often hard but I think those drafts were > discussed a little on the perpass list before they were adopted by > the DHCWG. If if helps I could ask again and see if that gets any > more comment, happy to do that if you want, just let me know. > >> >> The WG has been working on seDhcpv6 but that has been a challenging >> document and has been sent back to the WG several times now - but >> this work also primarily focuses on the client to server >> communication. >> >> Finally, these options, as all relay and client options are just >> hitching a ride on the DHCP exchange. So if this is a serious issue >> that the IESG and/or Int Area Directors feel the DHC WG needs to >> address, we can discuss at IETF-95 to see if there is interest from >> the WG to attempt to address the relay to server communication >> channel to assure it is secure and prevents pervasive monitoring. > > That sounds reasonable too, thanks. I'm fine to clear this discuss > and see how that conversation goes. > > FWIW, while I'd personally not argue that DHCP relay<->server poses > the absolutely most important privacy problem on the Internet, I do > think the conversation could be useful - given this WG has already > done the privacy and nymity drafts you mention above, it could be > that this set of participants are more aware of the issues. (Or maybe > not, but good if we find out:-) > > Thanks, S. > > >> >> - Bernie >> >> -----Original Message----- From: Brian Haberman >> [mailto:brian@innovationslab.net] Sent: Monday, February 08, 2016 >> 1:40 PM To: Bernie Volz (volz) ; Sri Gundavelli >> (sgundave) Cc: Stephen Farrell >> ; The IESG ; >> draft-ietf-dhc-access-network-identifier@ietf.org; >> dhc-chairs@ietf.org; jiangsheng@huawei.com; dhcwg@ietf.org >> Subject: Re: Stephen Farrell's Discuss on >> draft-ietf-dhc-access-network-identifier-13: (with DISCUSS and >> COMMENT) >> >> Hi Bernie & Sri, >> >> On 2/8/16 1:08 PM, Bernie Volz (volz) wrote: >>> Agree with Sri's points. DHC wg would like to advance draft. >>> >>> - Bernie (from iPhone) >>> >>>> On Feb 8, 2016, at 12:44 PM, Sri Gundavelli (sgundave) >>>> wrote: >>>> >>>> >>>> Thanks Stephen. If I read this correctly, I assume this is the >>>> only pending DISCUSS point. >>>> >>>> >>>>> "Did the DHC working group consider how this information, >>>>> when sent without adequate protection between relay and dhcp >>>>> server, could help in pervasive monitoring?" >>>> >>>> I will let chairs answer this question. >> >> I would like a chair to explicitly answer Stephen's question above >> and provide a pointer to the mailing list archives or meeting >> minutes where this point was discussed. >> >> Specifically, did the WG reach a consensus on the sensitive >> information elements and their vulnerability to pervasive >> monitoring? >> >> Regards, Brian >> >>>> >>>> >>>> But, from my point view: >>>> >>>> 1.) we have identified the information elements that are >>>> sensitive in nature from privacy point of view 2.) we have >>>> identified the interfaces where these information elements can >>>> possibly get exposed; interfaces where threats can be >>>> activated 3.) we have listed the deployment context (Ex: Single >>>> operator) 4.) we have listed considerations on how to entities >>>> have to deal with this data; points such as not to store the >>>> data at DHCP server ..etc. 4.) we have listed the existing >>>> tools that are available for the operator to mitigate that >>>> threat >>>> >>>> All of these points were discussed in the DHC WG and there were >>>> no explicit comments either supporting, or disagreeing with >>>> these views. >>>> >>>> >>>> Regards Sri >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>>> On 2/8/16, 4:11 AM, "Stephen Farrell" >>>>> wrote: >>>>> >>>>> Stephen Farrell has entered the following ballot position >>>>> for draft-ietf-dhc-access-network-identifier-13: Discuss >>>>> >>>>> When responding, please keep the subject line intact and >>>>> reply to all email addresses included in the To and CC lines. >>>>> (Feel free to cut this introductory paragraph, however.) >>>>> >>>>> >>>>> Please refer to >>>>> https://www.ietf.org/iesg/statement/discuss-criteria.html for >>>>> more information about IESG DISCUSS and COMMENT positions. >>>>> >>>>> >>>>> The document, along with other ballot positions, can be >>>>> found here: >>>>> https://datatracker.ietf.org/doc/draft-ietf-dhc-access-network-iden >>>>> >>>>> t >>>>> >>>>> > ifier/ >>>>> >>>>> >>>>> >>>>> ------------------------------------------------------------------- >>>>> >>>>> - >>>>> >>>>> > -- >>>>> DISCUSS: >>>>> ------------------------------------------------------------------- >>>>> >>>>> - >>>>> >>>>> > -- >>>>> >>>>> >>>>> Thanks for the changes made in response to my and, in >>>>> particular, Alissa's discuss ballots. >>>>> >>>>> Having looked back at the email thread I don't believe I got >>>>> any answer to the question "Did the DHC working group >>>>> consider how this information, when sent without adequate >>>>> protection between relay and dhcp server, could help in >>>>> pervasive monitoring?" >>>>> >>>>> I think the focus of the discussion has been on the >>>>> applicability of this being limited to "typically" one >>>>> operator's network, which does of course mean that the >>>>> traffic is less at risk than had it transited many networks. >>>>> However, we have seen (Belgacom) that the PM threat also >>>>> applies within a single operator's network. So I am still >>>>> interested in the answer to the above question. >>>>> >>>>> The DHC WG might consider this threat and still conclude that >>>>> a SHOULD statement about IPsec is the best we can do in >>>>> practice, but that isn't clear to me at present, so I'd still >>>>> like to chat about the PM threat. (Note: it's the WG's >>>>> consideration of the threat I'd like to chat about, not only >>>>> about the potential of IPsec to mitigate that threat.) >>>>> >>>>> >>>>> ------------------------------------------------------------------- >>>>> >>>>> - >>>>> >>>>> > -- >>>>> COMMENT: >>>>> ------------------------------------------------------------------- >>>>> >>>>> - >>>>> >>>>> > -- >>>>> >>>>> >>>>> >>>>> >>>>> OLD DISCUSS TEXT BELOW: >>>>> >>>>> (Sent mail 2016-01-10, checking on change vs. discuss) >>>>> >>>>> (1) Did the DHC working group consider how this information, >>>>> when sent without adequate protection between relay and dhcp >>>>> server, could help in pervasive monitoring? If so, what was >>>>> the conclusion reached? We have seen http header field >>>>> information sent between infrastructure nodes being >>>>> intercepted for that purpose, so this has to be similarly at >>>>> risk. If the answer is that this is only to be used within a >>>>> single network operator's setup (or a roaming arrangement) >>>>> then that needs to be justified (as practical) and, if it can >>>>> be justified (I'm not sure tbh), also made explicit. >>>>> >>>>> (2) I had a DISCUSS on the draft that became rfc 6757 about >>>>> protection of this kind of data. In that context I think I >>>>> was assured that everything (in PMIPv6) was IPsec protected >>>>> so it was fine. Why, in what we now know is a more threated >>>>> environment, is it ok to now have weaker protection when I >>>>> was assured then that IPsec was in fact quite usable in >>>>> PMIPv6? I think you maybe need to put in a MUST use IPsec >>>>> requirement for this to be as safe. >>>>> >>>>> (3) section 7: MAY store - this is possibly sensitive >>>>> information so you ought say that it SHOULD NOT be stored >>>>> unless needed, and if stored, SHOULD be deleted as soon as >>>>> possible. Storing sensitive information when not needed just >>>>> shouldn't be considered acceptable anymore I think - is that >>>>> reasonable? >>>>> >>>>> OLD COMMENT TEXT BELOW >>>>> >>>>> - I (strongly) support Alissa's DISCUSS and will be >>>>> interested in watching how that is resolved. Some of my >>>>> DISCUSS points do overlap though so from my POV feel free to >>>>> mix'n'match the discussions. Or to process first one then the >>>>> other, whatever you think is best. >>>>> >>>>> - RFC6757 defines exactly this for PMIPv6. That implies that >>>>> PMIPv6 should not be used to illustrate or motivate this, as >>>>> that problem is solved. Perhaps you would be better off if >>>>> you limited the scope of this to be used for networks that >>>>> are some kind of extension to PMIPv6 only? (You'd need to >>>>> define what kind I think.) >>>> >> From nobody Mon Feb 8 14:42:00 2016 Return-Path: X-Original-To: dhcwg@ietf.org Delivered-To: dhcwg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EA5CB1B3429; Mon, 8 Feb 2016 14:41:58 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Stephen Farrell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.14.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160208224158.19305.54354.idtracker@ietfa.amsl.com> Date: Mon, 08 Feb 2016 14:41:58 -0800 Archived-At: Cc: dhc-chairs@ietf.org, draft-ietf-dhc-access-network-identifier@ietf.org, dhcwg@ietf.org Subject: [dhcwg] Stephen Farrell's No Objection on draft-ietf-dhc-access-network-identifier-13: (with COMMENT) X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Feb 2016 22:41:59 -0000 Stephen Farrell has entered the following ballot position for draft-ietf-dhc-access-network-identifier-13: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dhc-access-network-identifier/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I look forward to the planned discussion to see if we can further improve the privacy and security properties of DHCP. Thanks for being willing to have that discussion. OLD DISCUSS TEXT BELOW: (Sent mail 2016-01-10, checking on change vs. discuss) (1) Did the DHC working group consider how this information, when sent without adequate protection between relay and dhcp server, could help in pervasive monitoring? If so, what was the conclusion reached? We have seen http header field information sent between infrastructure nodes being intercepted for that purpose, so this has to be similarly at risk. If the answer is that this is only to be used within a single network operator's setup (or a roaming arrangement) then that needs to be justified (as practical) and, if it can be justified (I'm not sure tbh), also made explicit. (2) I had a DISCUSS on the draft that became rfc 6757 about protection of this kind of data. In that context I think I was assured that everything (in PMIPv6) was IPsec protected so it was fine. Why, in what we now know is a more threated environment, is it ok to now have weaker protection when I was assured then that IPsec was in fact quite usable in PMIPv6? I think you maybe need to put in a MUST use IPsec requirement for this to be as safe. (3) section 7: MAY store - this is possibly sensitive information so you ought say that it SHOULD NOT be stored unless needed, and if stored, SHOULD be deleted as soon as possible. Storing sensitive information when not needed just shouldn't be considered acceptable anymore I think - is that reasonable? OLD COMMENT TEXT BELOW - I (strongly) support Alissa's DISCUSS and will be interested in watching how that is resolved. Some of my DISCUSS points do overlap though so from my POV feel free to mix'n'match the discussions. Or to process first one then the other, whatever you think is best. - RFC6757 defines exactly this for PMIPv6. That implies that PMIPv6 should not be used to illustrate or motivate this, as that problem is solved. Perhaps you would be better off if you limited the scope of this to be used for networks that are some kind of extension to PMIPv6 only? (You'd need to define what kind I think.) From nobody Tue Feb 9 06:59:23 2016 Return-Path: X-Original-To: dhcwg@ietf.org Delivered-To: dhcwg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 26A7F1A9095; Tue, 9 Feb 2016 06:59:21 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.14.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160209145921.21443.53789.idtracker@ietfa.amsl.com> Date: Tue, 09 Feb 2016 06:59:21 -0800 Archived-At: Cc: dhc-chairs@ietf.org, The IESG , dhcwg@ietf.org, draft-ietf-dhc-access-network-identifier@ietf.org, rfc-editor@rfc-editor.org Subject: [dhcwg] Protocol Action: 'Access Network Identifier Option in DHCP' to Proposed Standard (draft-ietf-dhc-access-network-identifier-13.txt) X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Feb 2016 14:59:21 -0000 The IESG has approved the following document: - 'Access Network Identifier Option in DHCP' (draft-ietf-dhc-access-network-identifier-13.txt) as Proposed Standard This document is the product of the Dynamic Host Configuration Working Group. The IESG contact persons are Brian Haberman and Terry Manderson. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-dhc-access-network-identifier/ Technical Summary: This document defines new DHCPv4 and DHCPv6 options for access network identification that is added by Relay agent s in the DHCPv4 or DHCPv6 messages towards the server. This information can be used to provide differentiated services and policing of traffic based on the access network to which a client is attached. Working Group Summary: This document was called draft-bhandari-dhc-access-network-identifier prior to its adoption. There was unanimous support for it in favor of adoption (and none against), so this document was adopted in May 2013. There was interest in this work posts since its adoption. There was never any opposition for this work. This document went through a relevant long document development period (10 months for individual document period, 21 month for WG document period) due to the authors lack of the DHC background expertise. The DHC expert, Bernie Volz, has joined in latest version so that the maturity of this document can be reached. Document Quality: This document went through multiple reviews by multiple WG participants. The options, relay's and server's behaviors are clearly defined. I'm not aware of any existing implementations. Personnel: Sheng Jiang is the document shepherd. Brian Haberman is the responsible AD. From nobody Tue Feb 9 10:09:08 2016 Return-Path: X-Original-To: dhcwg@ietf.org Delivered-To: dhcwg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 89E1A1ACDE3 for ; Tue, 9 Feb 2016 10:09:06 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: X-Test-IDTracker: no X-IETF-IDTracker: 6.14.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160209180906.3789.27391.idtracker@ietfa.amsl.com> Date: Tue, 09 Feb 2016 10:09:06 -0800 From: IETF Secretariat Archived-At: Subject: [dhcwg] Milestones changed for dhc WG X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Feb 2016 18:09:06 -0000 Changed milestone "Submit stable-privacy-addresses to IESG", resolved as "Abandoned document". URL: https://datatracker.ietf.org/wg/dhc/charter/ From nobody Fri Feb 12 11:26:02 2016 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 358DF1A88F0; Fri, 12 Feb 2016 11:26:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.978 X-Spam-Level: X-Spam-Status: No, score=-0.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=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 xvikD7Q7221O; Fri, 12 Feb 2016 11:25:59 -0800 (PST) Received: from mail-io0-x236.google.com (mail-io0-x236.google.com [IPv6:2607:f8b0:4001:c06::236]) (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 A3D311A88EA; Fri, 12 Feb 2016 11:25:59 -0800 (PST) Received: by mail-io0-x236.google.com with SMTP id 9so102258973iom.1; Fri, 12 Feb 2016 11:25:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=unA7ThUL79Ab8pzgjRpfaGOllEZ8QwaLZ9t8wP/wwBI=; b=Nf/aS7p2uFZDOXtzJ34KBwTj+/72iV6jJFyAgn12Pic2Vcc37ZottEpS2TMGQ0ug+9 MlM9z2m85bnVYw7x1b1MFkHvGVahMt+i/Zw9UQwK4wFRlzSjFOMRrZdKjR6y1rfeNhB+ Ek/5kO4tgMtzkG0PseoUny1U0jpHCbkBskrXi/E9pDz962/TP7OHNN8hGB2YiDjpCF2I fXGKeC6356JQHRqmRoiGypliuz3ZjDxMo2HDLBrT9c/z/MyYcGE/0Y34CHqwjUyXXcwa UjjCT7mp1UmU30mUOxfdCMpwzUXoltx3ayfOY4ySOKDZKcIZKTaPqvOIGdGI6STjUNYv 5JUw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=unA7ThUL79Ab8pzgjRpfaGOllEZ8QwaLZ9t8wP/wwBI=; b=Ped0VuQQGBbT/HL3kRUH1I1gv8WKjhi7e/HOCCUhV9w1Z3TEVwB/iUFy1jITaL17kG /Q8gMaowtplfxdf4IUmjtoY8vurihY/EEg4/4dFQEL0oX6GZT5nSN4u4CQHOojqSTIO6 TnIXjkunQXOrmFwbym9JRfiEPogMS4Ds39OKUHsxm1BxjEOlb3xtnC7eOVNoZ9YXpr9o wPdnjJtZ3cgWEYQp/y1yu9GPSrfkASdqexlwy/SH9hTz5dXu/ZCgh3wSqYSFxnGplzKF aN3daVXrUVVA+jb4TKKHMMIeuG1YOe5uSc/nUAaFmw0/qstM65WpUn1WC5Wcr4X42VR5 8tRA== X-Gm-Message-State: AG10YORgd40zzNRTocJlBd42pT+OIQKngLPhA6HPZkRFXLPUUtsPOBfEYMvAmh1xG27MmnNw1ZVTPmgIZA29IA== MIME-Version: 1.0 X-Received: by 10.107.184.135 with SMTP id i129mr5341777iof.4.1455305159055; Fri, 12 Feb 2016 11:25:59 -0800 (PST) Sender: jinmei.tatuya@gmail.com Received: by 10.107.169.35 with HTTP; Fri, 12 Feb 2016 11:25:58 -0800 (PST) In-Reply-To: <20160201142413.30288.23248.idtracker@ietfa.amsl.com> References: <20160201142413.30288.23248.idtracker@ietfa.amsl.com> Date: Fri, 12 Feb 2016 11:25:58 -0800 X-Google-Sender-Auth: 8-9HM-kg4R6n_f_IVs2ZP_n3pCQ Message-ID: From: =?UTF-8?B?56We5piO6YGU5ZOJ?= To: ietf@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: draft-ietf-dhc-anonymity-profile@ietf.org, dhc-chairs@ietf.org, "Bernie Volz \(volz\)" , IETF-Announce , "dhcwg@ietf.org" Subject: Re: [dhcwg] Last Call: (Anonymity profile for DHCP clients) to Proposed Standard X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Feb 2016 19:26:01 -0000 On Mon, Feb 1, 2016 at 6:24 AM, The IESG wrote: > The IESG has received a request from the Dynamic Host Configuration WG > (dhc) to consider the following document: > - 'Anonymity profile for DHCP clients' > as Proposed Standard > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to the > ietf@ietf.org mailing lists by 2016-02-15. Exceptionally, comments may be > sent to iesg@ietf.org instead. In either case, please retain the > beginning of the Subject line to allow automated sorting. Brian Carpenter called for an attention to Section 4.5.2 of the draft: https://mailarchive.ietf.org/arch/msg/ipv6/J_SnGxd2JunlpOeL4JprV03UA7s 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? -- JINMEI, Tatuya From nobody Fri Feb 12 12:47:48 2016 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A726C1A89E9; Fri, 12 Feb 2016 12:47:45 -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 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 TQ3mwri0TJQA; Fri, 12 Feb 2016 12:47:44 -0800 (PST) Received: from phx-mbsout-01.mbs.boeing.net (phx-mbsout-01.mbs.boeing.net [130.76.184.178]) (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 12A001A89E1; Fri, 12 Feb 2016 12:47:43 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id u1CKlh2d007197; Fri, 12 Feb 2016 13:47:43 -0700 Received: from XCH-BLV-505.nw.nos.boeing.com (xch-blv-505.nw.nos.boeing.com [130.247.25.195]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id u1CKlcdM007149 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Fri, 12 Feb 2016 13:47:39 -0700 Received: from XCH-BLV-105.nw.nos.boeing.com ([169.254.5.221]) by XCH-BLV-505.nw.nos.boeing.com ([169.254.5.220]) with mapi id 14.03.0235.001; Fri, 12 Feb 2016 12:47:37 -0800 From: "Templin, Fred L" To: =?iso-2022-jp?B?GyRCP0BMQEMjOkgbKEI=?= , "ietf@ietf.org" Thread-Topic: [dhcwg] Last Call: (Anonymity profile for DHCP clients) to Proposed Standard Thread-Index: AQHRZctBgE9kBkyHpEOuEoRx/lWCxp8o3/xA Date: Fri, 12 Feb 2016 20:47:36 +0000 Message-ID: <2134F8430051B64F815C691A62D983183396786F@XCH-BLV-105.nw.nos.boeing.com> References: <20160201142413.30288.23248.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Cc: "dhc-chairs@ietf.org" , IETF-Announce , "Bernie Volz \(volz\)" , "draft-ietf-dhc-anonymity-profile@ietf.org" , "dhcwg@ietf.org" Subject: Re: [dhcwg] Last Call: (Anonymity profile for DHCP clients) to Proposed Standard X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Feb 2016 20:47:45 -0000 Hi, > -----Original Message----- > From: dhcwg [mailto:dhcwg-bounces@ietf.org] On Behalf Of ???? > Sent: Friday, February 12, 2016 11:26 AM > To: ietf@ietf.org > Cc: draft-ietf-dhc-anonymity-profile@ietf.org; dhc-chairs@ietf.org; Berni= e Volz (volz); IETF-Announce; dhcwg@ietf.org > Subject: Re: [dhcwg] Last Call: = (Anonymity profile for DHCP clients) to Proposed Standard >=20 > On Mon, Feb 1, 2016 at 6:24 AM, The IESG wrote: >=20 > > The IESG has received a request from the Dynamic Host Configuration WG > > (dhc) to consider the following document: > > - 'Anonymity profile for DHCP clients' > > as Proposed Standard > > > > The IESG plans to make a decision in the next few weeks, and solicits > > final comments on this action. Please send substantive comments to the > > ietf@ietf.org mailing lists by 2016-02-15. Exceptionally, comments may = be > > sent to iesg@ietf.org instead. In either case, please retain the > > beginning of the Subject line to allow automated sorting. >=20 > Brian Carpenter called for an attention to Section 4.5.2 of the draft: > https://mailarchive.ietf.org/arch/msg/ipv6/J_SnGxd2JunlpOeL4JprV03UA7s >=20 > so I'm responding to it. >=20 > 4.5.2. Prefix delegation >=20 > 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. >=20 > 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? 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. Thanks - Fred fred.l.templin@boeing.com =20 > -- > JINMEI, Tatuya >=20 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg From nobody Fri Feb 12 14:09:04 2016 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 794881A90D9 for ; Fri, 12 Feb 2016 14:09:03 -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=unavailable 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 0AwYJjxxZaxZ for ; Fri, 12 Feb 2016 14:09:02 -0800 (PST) Received: from xsmtp04.mail2web.com (xsmtp24.mail2web.com [168.144.250.190]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 235BB1A90DC for ; Fri, 12 Feb 2016 14:09:01 -0800 (PST) Received: from [10.5.2.13] (helo=xmail03.myhosting.com) by xsmtp04.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1aULtb-0006MV-2C for dhcwg@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 ) by xmail03.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 12 Feb 2016 22:08:57 -0000 From: "Christian Huitema" To: "'Templin, Fred L'" , =?iso-2022-jp?B?JxskQj9ATEBDIzpIGyhCJw==?= , References: <20160201142413.30288.23248.idtracker@ietfa.amsl.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 Archived-At: Cc: dhc-chairs@ietf.org, "'Bernie Volz \(volz\)'" , draft-ietf-dhc-anonymity-profile@ietf.org, dhcwg@ietf.org Subject: Re: [dhcwg] Last Call: (Anonymity profile for DHCP clients) to Proposed Standard X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Feb 2016 22:09:03 -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 From nobody Fri Feb 12 14:15:39 2016 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 425C11A9100; Fri, 12 Feb 2016 14:15:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=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 5aoVD2UR26WD; Fri, 12 Feb 2016 14:15:36 -0800 (PST) Received: from mail-pa0-x231.google.com (mail-pa0-x231.google.com [IPv6:2607:f8b0:400e:c03::231]) (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 EC7401A90FF; Fri, 12 Feb 2016 14:15:35 -0800 (PST) Received: by mail-pa0-x231.google.com with SMTP id fy10so13559660pac.1; Fri, 12 Feb 2016 14:15:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=QjX1x8u89AHG+g5Zf1iyY6GVudVaVU9uyIivDYhy0pM=; b=SYA2GgDCq8qH9DWqonXjz1/0a9MIn2KQw8ZuRFVsj2Xi9tqnn0pXq4ok3eJNtwqhp5 WInbdvJUInSZ4YkbstMY2Kl6v+FDs5ltdBoPier2KqmURvMpCp2q7lFn+sUywW64kMbN et34EQlvf6XnPnC2Z3PIGAHgQ3qjFDlYwVhNpZINN7//QgPE69xhFNF4OI++mhEUHmUN IFA9LRSEtGWxaJ6cc9EATJ4/pS/7KktDsP82UbmHmxZSkH1vwS5SfPjsaVP7QizZG84W fKi4SStJMUoqYwickCyczuXw+el6rol8LA/mmWxfXGJEw9qFSg4I7b82es23qUE6yM/q kjBg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=QjX1x8u89AHG+g5Zf1iyY6GVudVaVU9uyIivDYhy0pM=; b=dYBCqFF2zEidyGisP4J/TIwYfaa47QMMHpp1JsW45LktyHfUJVEkbUwOECaPHZcfYM yoI4gBprYRonkRAq9Mk0OzByHvBEiXKvTsVct7bBxWy9Quw4gFW+93OBc672JWwtcwDl 26isQrGgjdt4zDYS+HCOssKN07FxpyFrAv7hXTFiupvZh5cJW4noT4rOz+cVpV1KAwDk pHqYRKz/KGf8PVlX8IaALR/U7gHwkVN3mlINASnYXW7lLmoauYviGuvRayMBgTDJstzk TE1vgoCQJQUOxa8e+yVgO2ilHcCuJv+5xpESRPcvdC8Cf+N1WKmy2DQIfjzhguCAQaKg NnZQ== X-Gm-Message-State: AG10YOS1XxkZl2RDFUpmQa0vXgRf3YdxvDqdAdP6QJ/k4b7ab0QKt9bKHwMIVq6xEDNHWQ== X-Received: by 10.66.190.40 with SMTP id gn8mr5606054pac.64.1455315335574; Fri, 12 Feb 2016 14:15:35 -0800 (PST) Received: from ?IPv6:2406:e007:7084:1:28cc:dc4c:9703:6781? ([2406:e007:7084:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id l62sm21660542pfj.7.2016.02.12.14.15.31 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 12 Feb 2016 14:15:34 -0800 (PST) To: Christian Huitema , "'Templin, Fred L'" , =?UTF-8?B?J+elnuaYjumBlA==?= =?UTF-8?B?5ZOJJw==?= , ietf@ietf.org References: <20160201142413.30288.23248.idtracker@ietfa.amsl.com> <2134F8430051B64F815C691A62D983183396786F@XCH-BLV-105.nw.nos.boeing.com> <0ee601d165e1$f7e59400$e7b0bc00$@huitema.net> From: Brian E Carpenter Organization: University of Auckland Message-ID: <56BE598F.1010906@gmail.com> Date: Sat, 13 Feb 2016 11:15:43 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <0ee601d165e1$f7e59400$e7b0bc00$@huitema.net> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: dhc-chairs@ietf.org, draft-ietf-dhc-anonymity-profile@ietf.org, dhcwg@ietf.org Subject: Re: [dhcwg] Last Call: (Anonymity profile for DHCP clients) to Proposed Standard X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Feb 2016 22:15:37 -0000 On 13/02/2016 11:08, Christian Huitema wrote: > 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. To be clear, I don't have a strong opinion on this; it simply seemed like something the IPv6 community should be aware of before it ends up in an RFC. I also noticed this morning that it might impact draft-ietf-v6ops-host-addr-availability. Brian From nobody Fri Feb 12 23:37:36 2016 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BFFD1B2DDD for ; Fri, 12 Feb 2016 23:37:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.379 X-Spam-Level: X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=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 5ytbB2MQSmRE for ; Fri, 12 Feb 2016 23:37:33 -0800 (PST) Received: from mail-yw0-x233.google.com (mail-yw0-x233.google.com [IPv6:2607:f8b0:4002:c05::233]) (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 C258A1B2DEF for ; Fri, 12 Feb 2016 23:37:33 -0800 (PST) Received: by mail-yw0-x233.google.com with SMTP id h129so81912282ywb.1 for ; Fri, 12 Feb 2016 23:37:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=WUcUeZgYrLHOEojfvz1nO1TkhU41qVvD4Gno95djcpc=; b=kcmivCmQcdKM/x3gE8pPS+J68HtY8kuhCRWePqmu/TIZFFkFyZ2KJ8bYRBo+BEXSMt hNwA+SJ0RqGWkTw7Lnq6LcdY5fYfyZGM+RaTdVA3Ad55sCsXwe86+EoxXG+PHsobD+5R EonvQNJcHeGUdxjPL0G06s3nfTHDNDn5G4ztuiLiTcI5iplSEdVg3YykkBnO4SF66Vxm dF7fqXku0RRQVixGEkXEyUROXDmcNQgCbME+k4nu+QH4L60f4lLhWB5/6SYvEIP6waHP 2ONPoOpGM9ebLSYfZIAYXEoJNT6EwP6dFmL09u4DUvG0EhHba15RHiaHMZy7D2D9hblM JYAw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=WUcUeZgYrLHOEojfvz1nO1TkhU41qVvD4Gno95djcpc=; b=m1p/T5y0onpi2jn4jV20yL7K3PFFxM+D3qRA7/JJytp8WImxhdAmZ10CaGL/7545pw USLdFpXYJ8/EbVRVIugGeLDFAm8x84/lIPtda6j3wG6Y/5KywPX9ylNcL1sHJKDdwDdx sVuPDe9nEx78JPIqmxqYfDneTnYfQTfgZyr2ct+jYP1h7BzuZEUG7OhG7RFvK7ZyOVM3 ZkAy05sza5n0NA0FaEWPYmogyi/LY6ME0U0j980bMYDig420S9KqADXZmTooi2lXxS7C QJZfNKUCKj5TWWM1gMP5HnYtXh8yUialTduX6NOZWhKVyqFZrAUxWXH1+diqg1U+Sbm8 7haA== X-Gm-Message-State: AG10YOTzA9INXICjpQ5aTSVc6Y9Ex0wGsirv0gXdcoH8pPf1RJFWnY2FP136dKJWxlpVBV1i57/9fab/N5V5vH+N X-Received: by 10.129.96.213 with SMTP id u204mr3318549ywb.307.1455349052885; Fri, 12 Feb 2016 23:37:32 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.13.204 with HTTP; Fri, 12 Feb 2016 23:37:13 -0800 (PST) In-Reply-To: <56BE598F.1010906@gmail.com> References: <20160201142413.30288.23248.idtracker@ietfa.amsl.com> <2134F8430051B64F815C691A62D983183396786F@XCH-BLV-105.nw.nos.boeing.com> <0ee601d165e1$f7e59400$e7b0bc00$@huitema.net> <56BE598F.1010906@gmail.com> From: Lorenzo Colitti Date: Sat, 13 Feb 2016 08:37:13 +0100 Message-ID: To: Brian E Carpenter Content-Type: multipart/alternative; boundary=001a114926e852cb5d052ba1db4b Archived-At: Cc: IETF Discussion , dhc-chairs@ietf.org, =?UTF-8?B?56We5piO6YGU5ZOJ?= , Christian Huitema , draft-ietf-dhc-anonymity-profile@ietf.org, "dhcwg@ietf.org" Subject: Re: [dhcwg] Last Call: (Anonymity profile for DHCP clients) to Proposed Standard X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Feb 2016 07:37:35 -0000 --001a114926e852cb5d052ba1db4b Content-Type: text/plain; charset=UTF-8 On Fri, Feb 12, 2016 at 11:15 PM, Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > > 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. > > To be clear, I don't have a strong opinion on this; it simply seemed like > something the IPv6 community should be aware of before it ends up in an > RFC. > I also noticed this morning that it might impact > draft-ietf-v6ops-host-addr-availability. > +1 to the other comments here. I see no reason why prefix delegation should be worse for anonymity than address assignment. In fact, using prefix delegation instead of address assignments provides benefits for anonymity against off-link attackers, because delegating a prefix to a client allows that client to use many different addresses (potentially, even a different address for every remote host it connects to, or a different address for every new TCP connection). As Brian says, there are many other reasons why a network would want to provide a dedicated prefix to the host; see draft-ietf-v6ops-host-addr-availability . I would instead say something like: ==== The anonymity properties of DHCPv6 Prefix Delegation, which use IA_PD identity associations, are similar to those of of DHCPv6 address assignment using IA_NA identity associations. Because current host OS implementations do not typically request prefixes, clients that wish to use DHCPv6 PD - just like clients that wish to use any DHCP or DHCPv6 option that is not currently widely used - should recognize that doing so will serve as a form of fingerprinting unless or until client use of DHCPv6 PD becomes more widespread. ==== --001a114926e852cb5d052ba1db4b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
=C2= =A0On Fri, Feb 12, 2016 at 11:15 PM, Brian E Carpenter &l= t;brian.e.= carpenter@gmail.com> wrote:
>= ; 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 p= refix
> delegation, clients MAY use the agreed upon solution. Which is kind of=
> redundant, but if you guys prefer it that way, why not.

To be clear, I don't have a strong opinion on this; it simp= ly seemed like
something the IPv6 community should be aware of before it ends up in an RFC= .
I also noticed this morning that it might impact draft-ietf-v6ops-host-addr= -availability.

+1 to the other comments= here.

I see no reason why prefix delegation shoul= d be worse for anonymity than address assignment. In fact, using prefix del= egation instead of address assignments provides benefits for anonymity agai= nst off-link attackers, because delegating a prefix to a client allows that= client to use many different addresses (potentially, even a different addr= ess for every remote host it connects to, or a different address for every = new TCP connection).

As Brian says, there are many= other reasons why a network would want to provide a dedicated prefix to th= e host; see=C2=A0draft-ietf-v6ops-host-addr-availability .

I would instead say something like:

=3D= =3D=3D=3D
The anonymity properties of DHCPv6 Prefix Delegation, w= hich use IA_PD identity associations, are similar to those of of DHCPv6 add= ress assignment using IA_NA identity associations.

Because current host OS implementations do not typically request prefixes,= clients that wish to use DHCPv6 PD - just like clients that wish to use an= y DHCP or DHCPv6 option that is not currently widely used - should recogniz= e that doing so will serve as a form of fingerprinting unless or until clie= nt use of DHCPv6 PD becomes more widespread.
=3D=3D=3D=3D
--001a114926e852cb5d052ba1db4b-- From nobody Sat Feb 13 11:51:27 2016 Return-Path: X-Original-To: dhcwg@ietf.org Delivered-To: dhcwg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F0821A1BF3; Sat, 13 Feb 2016 11:51:25 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Meeting Session Request Tool\"" To: X-Test-IDTracker: no X-IETF-IDTracker: 6.14.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160213195125.25427.93054.idtracker@ietfa.amsl.com> Date: Sat, 13 Feb 2016 11:51:25 -0800 Archived-At: Cc: dhc-chairs@ietf.org, volz@cisco.com, dhcwg@ietf.org Subject: [dhcwg] dhc - New Meeting Session Request for IETF 95 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Feb 2016 19:51:25 -0000 A new meeting session request has just been submitted by Bernie Volz, a Chair of the dhc working group. --------------------------------------------------------- Working Group Name: Dynamic Host Configuration Area Name: Internet Area Session Requester: Bernie Volz Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 50 Conflicts to Avoid: First Priority: v6ops 6man mif softwire homenet Second Priority: dnsop dnssd sunset4 pcp abfab curdle dane kitten openpgp tls tokbind trans Third Priority: ace acme cose dots httpauth i2nsf ipsecme jose mile oauth sacm Special Requests: We would be willing to take a 2.5 hour slot if that helps with the scheduling. And, we would definitely prefer a 2.5 hour slot over two slots if the single session request must be split. --------------------------------------------------------- From nobody Sun Feb 14 12:36:51 2016 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AADA41A0024; Sun, 14 Feb 2016 12:36:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.698 X-Spam-Level: X-Spam-Status: No, score=0.698 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] 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 zjerRUCpxXfQ; Sun, 14 Feb 2016 12:36:48 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0121.outbound.protection.outlook.com [207.46.100.121]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 56DEE1A00A8; Sun, 14 Feb 2016 12:36:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=cmdcimqRMF+JaO7PIGFGt7q8B5crWdAeLzVhsgwYvfM=; b=IzkFAGsaQDTcWyHT5ptOfxPEnEBVbxOjpe7ymT0uzNBuU4QszElYpiYARGMMkooxWgUSoCeXGPWfl6B4VFr4xyHMvP6asP3sMZ38oU798amrMwhvZ2opQJE8BSyA4x2Fi5BmdyejayFaASqyy93WcqCnRLStGv/3EA6iN+oek44= Received: from DM2PR0301MB0655.namprd03.prod.outlook.com (10.160.96.17) by DM2PR0301MB0656.namprd03.prod.outlook.com (10.160.96.18) with Microsoft SMTP Server (TLS) id 15.1.403.16; Sun, 14 Feb 2016 20:36:47 +0000 Received: from DM2PR0301MB0655.namprd03.prod.outlook.com ([10.160.96.17]) by DM2PR0301MB0655.namprd03.prod.outlook.com ([10.160.96.17]) with mapi id 15.01.0403.019; Sun, 14 Feb 2016 20:36:47 +0000 From: Christian Huitema To: "Ray Hunter (v6ops)" , "draft-ietf-dhc-anonymity-profile@ietf.org" Thread-Topic: Mail regarding draft-ietf-dhc-anonymity-profile Thread-Index: AQHRZxr7Bmg5h4fO10KJAwfaor6wpJ8r/TEg Date: Sun, 14 Feb 2016 20:36:47 +0000 Message-ID: References: <56C06511.4020006@globis.net> In-Reply-To: <56C06511.4020006@globis.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: globis.net; dkim=none (message not signed) header.d=none;globis.net; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [2601:600:8900:31e1:910d:6a49:b2b9:55cf] x-ms-office365-filtering-correlation-id: 7137f261-add9-4e3c-cc50-08d3357e8f2d x-microsoft-exchange-diagnostics: 1; DM2PR0301MB0656; 5:mM62APx6udQ2ryuvM3TeJ2k316LuUm53KIpGix4hL+tUJ5bw4ppjHt3ljwZSVuBnLuQnmapBINybH2Y9Z4GVVj24mdCfEPTfphq5PNJDy2+Y0HvvFSIqyDMl4aY5IeF8Rk1TGzbT51iSTOuCRlBAmQ==; 24:q6SfIPH2D4woePE/42u7Dy8oqTjUv64KNY6hilwChML4yu2gGQZxtXj3Erm38JhH13Z7xro3+AY+t90se39n3I6WAxmFg4OjXK9HDPOTqhU= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR0301MB0656; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(61426038)(61427038); SRVR:DM2PR0301MB0656; BCL:0; PCL:0; RULEID:; SRVR:DM2PR0301MB0656; x-forefront-prvs: 0852EB6797 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(377454003)(5005710100001)(54356999)(50986999)(76176999)(5001770100001)(74316001)(92566002)(5002640100001)(77096005)(2950100001)(2900100001)(87936001)(5003600100002)(86362001)(106116001)(99286002)(11100500001)(6116002)(40100003)(10090500001)(5001960100002)(2501003)(76576001)(4326007)(1220700001)(102836003)(586003)(189998001)(1096002)(5004730100002)(122556002)(5008740100001)(230783001)(2906002)(8990500004)(33656002)(10290500002)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR0301MB0656; H:DM2PR0301MB0655.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Feb 2016 20:36:47.1010 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0301MB0656 Archived-At: Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] Mail regarding draft-ietf-dhc-anonymity-profile X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Feb 2016 20:36:50 -0000 On Sunday, February 14, 2016 3:29 AM, Ray Hunter > I have now read this draft, which is now in IETF last call, after this wa= s brought to the attention of the 6man list. > >> The interaction between prefix delegation and anonymity require >=A0=A0 further study.=A0 For now, the simple solution is to avoid using pr= efix >=A0=A0 delegation when striving for anonymity.=A0 When using the anonymity >=A0=A0 profiles, clients SHOULD NOT use IA_PD, the prefix delegation form = of >=A0=A0 address assignment. > > IMHO whilst the privacy concern may be valid, this document provides poor= advice (based on current knowledge). > > Advising having IA_PD disabled as default behavior will break a lot of cu= rrent and upcoming functionality,=20 > whilst the case that it is harmful has not yet been proven. > > e.g. Homenet is being built on automatic prefix delegation, including add= ress space delegation from the upstream ISP via IA_PD. The draft only describes the case where anonymity is desired, which typical= ly corresponds to mobile devices visiting a hot spot or similar location. I= don't believe that it covers the "home net router" scenario - these device= s are neither mobile nor anonymous. > Plus mitigation of privacy concerns are likely be just as feasible within= IA_PD as IA_NA, without it having to be disabled. Yes. This is consistent with feedback from other IPv6 developers, notably L= orenzo. Based on their feedback, we are rewriting the IA_PD guidance to rea= d: 4.5.2. Prefix delegation The use of DHCPv6 address assignment option for Prefix Delegation is defined in [RFC3633]. Because current host OS implementations do not typically request prefixes, clients that wish to use DHCPv6 PD - just like clients that wish to use any DHCP or DHCPv6 option that is not currently widely used - should recognize that doing so will serve as a form of fingerprinting unless or until client use of DHCPv6 PD becomes more widespread. The anonymity properties of DHCPv6 Prefix Delegation, which use IA_PD identity associations, are similar to those of of DHCPv6 address assignment using IA_NA identity associations. The IAID could potentially be used to identify the client, and a prefix hint sent in the IA_PD Prefix option could be used to track the client's previous location. Clients that desire anonymity and never request more than one prefix SHOULD set the IAID value to zero, as authorized in section 6 of [RFC3633], and SHOULD NOT document any previously assigned prefix in the IA_PD Prefix option. I hope this will ease your concerns. > In any case, no matter what mechanism is used to delegate individual addr= esses,=20 > name space, or prefixes, the mere fact that someone connecting to a netwo= rk has=20 > to accept a piece of information assigned, or correlated to items, from u= pstream > leads to an ability to track the device receiving the delegation or using= the upstream=20 > address space: there are many more ways to fingerprint a device than dire= ct ones=20 > such as IA-PD. Until such time as IP(v6) provides a means of devices to c= hoose their=20 > own addresses, and for this to be scalable to Internet-wide use, that's a= fact of life.=20 The point of the draft is to mitigate the use of DHCP for "meta-data correl= ation." There are clearly other sources of such correlations. Some of that = is already being addressed, e.g. the work on opaque identifiers in IPv6 add= resses. But there are certainly other sources of leakage, and we have to pl= ug them.=20 > e.g. RFC6740 ILNP '8+8' is even worse in this respect, as the identifier = portion is invariant as nodes relocate. Yes. The same could be said of many Mobile-IP schemes. But this is clearly = not the point of the DHCP anonymity profile draft. -- Christian Huitema From nobody Sun Feb 14 16:53:50 2016 Return-Path: X-Original-To: dhcwg@ietf.org Delivered-To: dhcwg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 540AE1ACE30; Sun, 14 Feb 2016 16:53:49 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.14.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160215005349.12755.52466.idtracker@ietfa.amsl.com> Date: Sun, 14 Feb 2016 16:53:49 -0800 Archived-At: Cc: dhcwg@ietf.org Subject: [dhcwg] I-D Action: draft-ietf-dhc-dhcp-privacy-04.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Feb 2016 00:53:49 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Dynamic Host Configuration of the IETF. Title : Privacy considerations for DHCP Authors : Sheng Jiang Suresh Krishnan Tomek Mrugalski Filename : draft-ietf-dhc-dhcp-privacy-04.txt Pages : 14 Date : 2016-02-14 Abstract: DHCP is a protocol that is used to provide addressing and configuration information to IPv4 hosts. This document discusses the various identifiers used by DHCP and the potential privacy issues. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dhc-dhcp-privacy/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-dhc-dhcp-privacy-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dhc-dhcp-privacy-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Feb 15 03:08:48 2016 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2B2B1B31F3; Mon, 15 Feb 2016 03:08:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.98 X-Spam-Level: **** X-Spam-Status: No, score=4.98 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_NET=0.611, HOST_EQ_NL=1.545, HOST_EQ_STATIC=1.172, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 ZdJswWCpeArF; Mon, 15 Feb 2016 03:08:44 -0800 (PST) Received: from globis01.globis.net (092-111-140-212.static.chello.nl [92.111.140.212]) by ietfa.amsl.com (Postfix) with ESMTP id 60B1B1B31EB; Mon, 15 Feb 2016 03:08:44 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 67C34401B2; Mon, 15 Feb 2016 12:08:43 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at globis01.globis.net Received: from globis01.globis.net ([127.0.0.1]) by localhost (mail.globis.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ur0n9JG7vBxU; Mon, 15 Feb 2016 12:08:40 +0100 (CET) Received: from Rays-MacBook-Pro.local (178-84-244-32.dynamic.upc.nl [178.84.244.32]) (Authenticated sender: v6ops@globis.net) by globis01.globis.net (Postfix) with ESMTPA id 8AD534016F; Mon, 15 Feb 2016 12:08:40 +0100 (CET) Message-ID: <56C1B1BB.3070306@globis.net> Date: Mon, 15 Feb 2016 12:08:43 +0100 From: "Ray Hunter (v6ops)" User-Agent: Postbox 4.0.8 (Macintosh/20151105) MIME-Version: 1.0 To: Christian Huitema References: <56C06511.4020006@globis.net> In-Reply-To: Content-Type: multipart/alternative; boundary="------------080609000608000203020104" Archived-At: Cc: "dhcwg@ietf.org" , "draft-ietf-dhc-anonymity-profile@ietf.org" Subject: Re: [dhcwg] Mail regarding draft-ietf-dhc-anonymity-profile X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Feb 2016 11:08:47 -0000 This is a multi-part message in MIME format. --------------080609000608000203020104 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit inline. > Christian Huitema > 14 Feb 2016 21:36 > On Sunday, February 14, 2016 3:29 AM, Ray Hunter > >> I have now read this draft, which is now in IETF last call, after this was brought to the attention of the 6man list. >> >>> 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. >> >> IMHO whilst the privacy concern may be valid, this document provides poor advice (based on current knowledge). >> >> Advising having IA_PD disabled as default behavior will break a lot of current and upcoming functionality, >> whilst the case that it is harmful has not yet been proven. >> >> e.g. Homenet is being built on automatic prefix delegation, including address space delegation from the upstream ISP via IA_PD. > > The draft only describes the case where anonymity is desired, which typically corresponds to mobile devices visiting a hot spot or similar location. I don't believe that it covers the "home net router" scenario - these devices are neither mobile nor anonymous. My opinion is that distinction will blur. Mobile devices will become mobile routers. But that's just my opinion. >> Plus mitigation of privacy concerns are likely be just as feasible within IA_PD as IA_NA, without it having to be disabled. > > Yes. This is consistent with feedback from other IPv6 developers, notably Lorenzo. Based on their feedback, we are rewriting the IA_PD guidance to read: > > 4.5.2. Prefix delegation > > The use of DHCPv6 address assignment option for Prefix Delegation is > defined in [RFC3633]. Because current host OS implementations do not > typically request prefixes, clients that wish to use DHCPv6 PD - just > like clients that wish to use any DHCP or DHCPv6 option that is not > currently widely used - should recognize that doing so will serve as > a form of fingerprinting unless or until client use of DHCPv6 PD > becomes more widespread. > > The anonymity properties of DHCPv6 Prefix Delegation, which use IA_PD > identity associations, are similar to those of of DHCPv6 address > assignment using IA_NA identity associations. The IAID could > potentially be used to identify the client, and a prefix hint sent in > the IA_PD Prefix option could be used to track the client's previous > location. Clients that desire anonymity and never request more than > one prefix SHOULD set the IAID value to zero, as authorized in > section 6 of [RFC3633], and SHOULD NOT document any previously > assigned prefix in the IA_PD Prefix option. > > I hope this will ease your concerns. Yes. I think that's much better text. >> In any case, no matter what mechanism is used to delegate individual addresses, >> name space, or prefixes, the mere fact that someone connecting to a network has >> to accept a piece of information assigned, or correlated to items, from upstream >> leads to an ability to track the device receiving the delegation or using the upstream >> address space: there are many more ways to fingerprint a device than direct ones >> such as IA-PD. Until such time as IP(v6) provides a means of devices to choose their >> own addresses, and for this to be scalable to Internet-wide use, that's a fact of life. > > The point of the draft is to mitigate the use of DHCP for "meta-data correlation." There are clearly other sources of such correlations. Some of that is already being addressed, e.g. the work on opaque identifiers in IPv6 addresses. But there are certainly other sources of leakage, and we have to plug them. >> e.g. RFC6740 ILNP '8+8' is even worse in this respect, as the identifier portion is invariant as nodes relocate. > > Yes. The same could be said of many Mobile-IP schemes. But this is clearly not the point of the DHCP anonymity profile draft. > > -- Christian Huitema > ACK. > Ray Hunter (v6ops) > 14 Feb 2016 12:29 > I have now read this draft, which is now in IETF last call, after this > was brought to the attention of the 6man list. > > > 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. > > IMHO whilst the privacy concern may be valid, this document provides > poor advice (based on current knowledge). > > Advising having IA_PD disabled as default behavior will break a lot of > current and upcoming functionality, whilst the case that it is harmful > has not yet been proven. > > e.g. Homenet is being built on automatic prefix delegation, including > address space delegation from the upstream ISP via IA_PD. > > Plus mitigation of privacy concerns are likely be just as feasible > within IA_PD as IA_NA, without it having to be disabled. > > In any case, no matter what mechanism is used to delegate individual > addresses, name space, or prefixes, the mere fact that someone > connecting to a network has to accept a piece of information assigned, > or correlated to items, from upstream leads to an ability to track the > device receiving the delegation or using the upstream address space: > there are many more ways to fingerprint a device than direct ones such > as IA-PD. Until such time as IP(v6) provides a means of devices to > choose their own addresses, and for this to be scalable to > Internet-wide use, that's a fact of life. e.g. RFC6740 ILNP '8+8' is > even worse in this respect, as the identifier portion is invariant as > nodes relocate. > -- regards, RayH --------------080609000608000203020104 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit inline.

14 Feb 2016 21:36
On Sunday, February 14, 2016 3:29 AM, Ray Hunter


I have now read this draft, which is now in IETF last call, after this was brought to the attention of the 6man list.


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.

IMHO whilst the privacy concern may be valid, this document provides poor advice (based on current knowledge).

Advising having IA_PD disabled as default behavior will break a lot of current and upcoming functionality, 
whilst the case that it is harmful has not yet been proven.

e.g. Homenet is being built on automatic prefix delegation, including address space delegation from the upstream ISP via IA_PD.


The draft only describes the case where anonymity is desired, which typically corresponds to mobile devices visiting a hot spot or similar location. I don't believe that it covers the "home net router" scenario - these devices are neither mobile nor anonymous.
My opinion is that distinction will blur. Mobile devices will become mobile routers. But that's just my opinion.


Plus mitigation of privacy concerns are likely be just as feasible within IA_PD as IA_NA, without it having to be disabled.


Yes. This is consistent with feedback from other IPv6 developers, notably Lorenzo. Based on their feedback, we are rewriting the IA_PD guidance to read:

    4.5.2.  Prefix delegation

   The use of DHCPv6 address assignment option for Prefix Delegation is
   defined in [RFC3633].  Because current host OS implementations do not
   typically request prefixes, clients that wish to use DHCPv6 PD - just
   like clients that wish to use any DHCP or DHCPv6 option that is not
   currently widely used - should recognize that doing so will serve as
   a form of fingerprinting unless or until client use of DHCPv6 PD
   becomes more widespread.

   The anonymity properties of DHCPv6 Prefix Delegation, which use IA_PD
   identity associations, are similar to those of of DHCPv6 address
   assignment using IA_NA identity associations.  The IAID could
   potentially be used to identify the client, and a prefix hint sent in
   the IA_PD Prefix option could be used to track the client's previous
   location.  Clients that desire anonymity and never request more than
   one prefix SHOULD set the IAID value to zero, as authorized in
   section 6 of [RFC3633], and SHOULD NOT document any previously
   assigned prefix in the IA_PD Prefix option.

I hope this will ease your concerns.




Yes. I think that's much better text.



  

    


In any case, no matter what mechanism is used to delegate individual addresses, 
name space, or prefixes, the mere fact that someone connecting to a network has 
to accept a piece of information assigned, or correlated to items, from upstream
leads to an ability to track the device receiving the delegation or using the upstream 
address space: there are many more ways to fingerprint a device than direct ones 
such as IA-PD. Until such time as IP(v6) provides a means of devices to choose their 
own addresses, and for this to be scalable to Internet-wide use, that's a fact of life. 


The point of the draft is to mitigate the use of DHCP for "meta-data correlation." There are clearly other sources of such correlations. Some of that is already being addressed, e.g. the work on opaque identifiers in IPv6 addresses. But there are certainly other sources of leakage, and we have to plug them. 






  

    


e.g. RFC6740 ILNP '8+8' is even worse in this respect, as the identifier portion is invariant as nodes relocate.


Yes. The same could be said of many Mobile-IP schemes. But this is clearly not the point of the DHCP anonymity profile draft.

-- Christian Huitema





ACK.



  

    

  

  
      
     14 
Feb 2016 12:29
    

  


I have now read this draft, which is now in IETF last call, after this 
was brought to the attention of the 6man list.

  

> 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.

  

IMHO whilst the privacy concern may be valid, this document provides 
poor advice (based on current knowledge).

  

Advising having IA_PD disabled as default behavior will break a lot of 
current and upcoming functionality, whilst the case that it is harmful 
has not yet been proven.

  

e.g. Homenet is being built on automatic prefix delegation, including 
address space delegation from the upstream ISP via IA_PD.

  

Plus mitigation of privacy concerns are likely be just as feasible 
within IA_PD as IA_NA, without it having to be disabled.

  

In any case, no matter what mechanism is used to delegate individual 
addresses, name space, or prefixes, the mere fact that someone 
connecting to a network has to accept a piece of information assigned, 
or correlated to items, from upstream leads to an ability to track the 
device receiving the delegation or using the upstream address space: 
there are many more ways to fingerprint a device than direct ones such 
as IA-PD. Until such time as IP(v6) provides a means of devices to 
choose their own addresses, and for this to be scalable to Internet-wide
 use, that's a fact of life. e.g. RFC6740 ILNP '8+8' is even worse in 
this respect, as the identifier portion is invariant as nodes relocate.

  

  
  






-- 


regards,

RayH

  





--------------080609000608000203020104--


From nobody Mon Feb 15 09:48:30 2016
Return-Path: 
X-Original-To: dhcwg@ietf.org
Delivered-To: dhcwg@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B588A1A90BB; Mon, 15 Feb 2016 09:48:26 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: 
X-Test-IDTracker: no
X-IETF-IDTracker: 6.14.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20160215174826.14913.73786.idtracker@ietfa.amsl.com>
Date: Mon, 15 Feb 2016 09:48:26 -0800
Archived-At: 
Cc: dhcwg@ietf.org
Subject: [dhcwg] I-D Action: draft-ietf-dhc-anonymity-profile-07.txt
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.15
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 15 Feb 2016 17:48:26 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Dynamic Host Configuration of the IETF.

        Title           : Anonymity profile for DHCP clients
        Authors         : Christian Huitema
                          Tomek Mrugalski
                          Suresh Krishnan
	Filename        : draft-ietf-dhc-anonymity-profile-07.txt
	Pages           : 27
	Date            : 2016-02-15

Abstract:
   Some DHCP options carry unique identifiers.  These identifiers can
   enable device tracking even if the device administrator takes care of
   randomizing other potential identifications like link-layer addresses
   or IPv6 addresses.  The anonymity profile is designed for clients
   that wish to remain anonymous to the visited network.  The profile
   provides guidelines on the composition of DHCP or DHCPv6 requests,
   designed to minimize disclosure of identifying information.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dhc-anonymity-profile/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-dhc-anonymity-profile-07

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-dhc-anonymity-profile-07


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From nobody Mon Feb 15 10:44:47 2016
Return-Path: 
X-Original-To: dhcwg@ietf.org
Delivered-To: dhcwg@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A1251AC3D9; Mon, 15 Feb 2016 10:44:46 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: "Stephen Farrell" 
To: "The IESG" 
X-Test-IDTracker: no
X-IETF-IDTracker: 6.14.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20160215184446.21276.88187.idtracker@ietfa.amsl.com>
Date: Mon, 15 Feb 2016 10:44:46 -0800
Archived-At: 
Cc: dhc-chairs@ietf.org, volz@cisco.com, draft-ietf-dhc-anonymity-profile@ietf.org, dhcwg@ietf.org
Subject: [dhcwg] Stephen Farrell's Yes on draft-ietf-dhc-anonymity-profile-07: (with COMMENT)
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.15
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 15 Feb 2016 18:44:46 -0000

Stephen Farrell has entered the following ballot position for
draft-ietf-dhc-anonymity-profile-07: Yes

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dhc-anonymity-profile/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------


Thank you for doing this work. I think it's important and an
excellent example. 

- general: I have a question for which I think it'd be good if
the answer were visible to others doing similar work later. That
could be recorded in email that can be referenced (via an
archive URL) or it could be in this document. Perhaps the latter
is better, not sure.  Anyway, the question is: what was the
methodology used to identify the various DHCP related anonymity
issues that need to be tackled, and to consider/test proposed
mitigations? I think it may be worth including some text on
methodology in this document (maybe a new appendix or as a
section 2.8?) so that we can use this as a self-contained
example when other folks are doing similar work.  (Sorry for
trying to add work.) If a part of that answer is e.g. "I bought
Ralph a G&T" that is IMO also worth including in some anonymised
form:-)

- The IPR declaration makes me a bit sad, but I think the WG
did process it according to our processes.

- abstract: Is "anonymous to the visited network" the right
goal? Perhaps also "not be identified as the same entity as
previously connected to this or another network" is more like
it, but too wordy;-) If you can figure a way to include the
"another network" aspect in the abstract that'd be good I think,
as that might help motivate network admins to want this profile,
as they're not only protecting their users from themselves, but
from other network admins as well.

- section 2: In the introductory text, you could update this to
refer to IEEE's ongoing work here, which I think is now more
official than it was perhaps when this text was written.

- 2.5: The Guy Fawkes reference might not be meaningful in a
few years. I'd suggest deleting that sentence.

- 3.5: So this says to do the opposite of 4361, which is
correct.  I wonder does that mean this UPDATEs 4361? (But don't
care about the answer;-) Same issue may arise wrt 3315 I guess.
(And I still don't care about the answer:-)

- 3.7: typo, "SOULD"

- 4.3: "from the previous year" - that's neat! Don't think I've
seen that before.

- 4.5: typo, "indemtified"

- 4.5.2: This still seems a bit too negative to me. Can't PD
assist privacy in some cases even if further study is needed.
E.g. if a home router is given a prefix via PD and that changes
now and then.

- DHCPv6: is there really nothing to say about link local
addresses? (I'm not sure how those are used in DHCPv6, if they
are, but they do often contain MACs.)

- The secdir review of the dhcp-privacy draft [1] suggested some
additional text for the security considerations text there that
might be better here.

   [1]
https://www.ietf.org/mail-archive/web/secdir/current/msg06338.html

(PS: This review was done on -06 with a quick look at the diff
vs. -07. I think it all still applies though.)



From nobody Mon Feb 15 10:45:54 2016
Return-Path: 
X-Original-To: dhcwg@ietf.org
Delivered-To: dhcwg@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 075A31A92BD; Mon, 15 Feb 2016 10:45:52 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: "Stephen Farrell" 
To: "The IESG" 
X-Test-IDTracker: no
X-IETF-IDTracker: 6.14.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20160215184552.21276.30492.idtracker@ietfa.amsl.com>
Date: Mon, 15 Feb 2016 10:45:52 -0800
Archived-At: 
Cc: dhc-chairs@ietf.org, draft-ietf-dhc-dhcpv6-privacy@ietf.org, dhcwg@ietf.org, volz@cisco.com
Subject: [dhcwg] Stephen Farrell's Yes on draft-ietf-dhc-dhcpv6-privacy-03: (with COMMENT)
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.15
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 15 Feb 2016 18:45:52 -0000

Stephen Farrell has entered the following ballot position for
draft-ietf-dhc-dhcpv6-privacy-03: Yes

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6-privacy/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------


More thanks for this work. Most of my comments ended up
being about the client profile for now.



From nobody Mon Feb 15 10:46:13 2016
Return-Path: 
X-Original-To: dhcwg@ietf.org
Delivered-To: dhcwg@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 714661A8ABC; Mon, 15 Feb 2016 10:46:13 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: "Stephen Farrell" 
To: "The IESG" 
X-Test-IDTracker: no
X-IETF-IDTracker: 6.14.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20160215184613.18852.55323.idtracker@ietfa.amsl.com>
Date: Mon, 15 Feb 2016 10:46:13 -0800
Archived-At: 
Cc: dhc-chairs@ietf.org, draft-ietf-dhc-dhcpv6-privacy@ietf.org, dhcwg@ietf.org, volz@cisco.com
Subject: [dhcwg] Stephen Farrell's Yes on draft-ietf-dhc-dhcpv6-privacy-03: (with COMMENT)
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.15
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 15 Feb 2016 18:46:13 -0000

Stephen Farrell has entered the following ballot position for
draft-ietf-dhc-dhcpv6-privacy-03: Yes

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6-privacy/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------


More thanks for this work. Most of my comments ended up
being about the client profile for now.

- DHCPv6: is there really nothing to say about link local
addresses? (I'm not sure how those are used in DHCPv6, if
they are, but they do often contain MACs.)



From nobody Mon Feb 15 10:47:04 2016
Return-Path: 
X-Original-To: dhcwg@ietf.org
Delivered-To: dhcwg@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 955FC1A9041; Mon, 15 Feb 2016 10:47:01 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: "Stephen Farrell" 
To: "The IESG" 
X-Test-IDTracker: no
X-IETF-IDTracker: 6.14.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20160215184701.22828.23096.idtracker@ietfa.amsl.com>
Date: Mon, 15 Feb 2016 10:47:01 -0800
Archived-At: 
Cc: dhc-chairs@ietf.org, draft-ietf-dhc-dhcp-privacy@ietf.org, volz@cisco.com, dhcwg@ietf.org
Subject: [dhcwg] Stephen Farrell's Yes on draft-ietf-dhc-dhcp-privacy-04: (with COMMENT)
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.15
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 15 Feb 2016 18:47:01 -0000

Stephen Farrell has entered the following ballot position for
draft-ietf-dhc-dhcp-privacy-04: Yes

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dhc-dhcp-privacy/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------


More thanks for this work. Most of my comments ended up
being about the client profile for now.



From nobody Mon Feb 15 12:45:53 2016
Return-Path: 
X-Original-To: dhcwg@ietfa.amsl.com
Delivered-To: dhcwg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 472151A898A; Mon, 15 Feb 2016 12:45:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.6
X-Spam-Level: 
X-Spam-Status: No, score=-0.6 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] 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 BCZWsXjPxwor; Mon, 15 Feb 2016 12:45:49 -0800 (PST)
Received: from mail-lb0-x22e.google.com (mail-lb0-x22e.google.com [IPv6:2a00:1450:4010:c04::22e]) (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 E09EC1B29A5; Mon, 15 Feb 2016 12:45:48 -0800 (PST)
Received: by mail-lb0-x22e.google.com with SMTP id x1so5837386lbj.3; Mon, 15 Feb 2016 12:45:48 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-type:content-transfer-encoding; bh=uJN0xpXpWUZ1Ey7Vk6xenPkRJ+Cp0xBhSJXMca3wj7g=; b=Y513C4Js0zcQLym3ROXZOhbg1POjvbYdCH8sUO3deNMFQ28MAduAtmYxJIpvUtw7Mx rES2jjh6Vo9SmioZaa6orRJmGlybaSCC1HCvpGO/AgHfE9/8FtA8hFqFfNi7HriYS0HC d7hbZmIgib43J1w+M0ixWBe4AD+789d2NHv5Zs3x3uEVy0LUIZCy0YLZFW05Jv5uYoFx qDUKHk2oepY6JXyvhD2vFoPKrt5a/CMIxhvJPhbwMBCkA0VeVstbvddXb3UIGYdCLRUA SmM/q7wtBewr4UJR8wAt3PU0BNvXr6cC0T4/fTn6oQ1XEqsdS0bgrrl13tAzw4q9uDtR a3Rw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=uJN0xpXpWUZ1Ey7Vk6xenPkRJ+Cp0xBhSJXMca3wj7g=; b=JHZ0ar5Fl0bWf81jyoW9v2fGuPiYfQCLkBP76DqlnP+jkgzE25CK2LCBKUI1jAskBg TCyABN273sQlAqjnr9fsjZUIilSlscEXEv8gbWWBLQ+b/cf8/VmKhLnRFdusu4YfP2BC H6k6OJsuMWxIXmc3RC2eL/h5kJYqaIKNsX41bdMFm72swr/gCLg/lZlu/p+UEGao/B/I lBbllvXo1UcAIwENCedweUUR7uUuhlJDzrc8hJxCguSR6T1HiXsWL8Xzs8d2nGfI8J2m Bxe64iX3olGIAvojW9cYxfaygW4D+1Hstu0RsW2UrSI+mFTo1HKQFuXH5l1sN7jYt+9I k1SQ==
X-Gm-Message-State: AG10YOSu/9HJjXZN/wOxpSm5Ljah8wmsI9FdDhBm0JWqLhc88XCNnRO80wd0PartBVaNFQ==
X-Received: by 10.112.198.162 with SMTP id jd2mr1313896lbc.53.1455569147138; Mon, 15 Feb 2016 12:45:47 -0800 (PST)
Received: from [10.0.0.100] (109107011157.gdansk.vectranet.pl. [109.107.11.157]) by smtp.googlemail.com with ESMTPSA id y63sm3882694lfd.10.2016.02.15.12.45.45 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 15 Feb 2016 12:45:46 -0800 (PST)
To: Robert Sparks , General Area Review Team , "ietf@ietf.org" , "dhcwg@ietf.org" , draft-ietf-dhc-dhcpv6-privacy.all@ietf.org
References: <56B0DBA3.2050406@nostrum.com>
From: Tomek Mrugalski 
X-Enigmail-Draft-Status: N1110
Message-ID: <56C238F8.4040400@gmail.com>
Date: Mon, 15 Feb 2016 21:45:44 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1
MIME-Version: 1.0
In-Reply-To: <56B0DBA3.2050406@nostrum.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Archived-At: 
Subject: Re: [dhcwg] Gen-ART LC review: draft-ietf-dhc-dhcpv6-privacy-03
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 15 Feb 2016 20:45:51 -0000

On 02.02.2016 17:38, Robert Sparks wrote:
> Document: draft-ietf-dhc-dhcpv6-privacy-03 Reviewer: Robert Sparks 
> Review Date: 2Feb2015 IETF LC End Date:4Feb2015 IESG Telechat date:
> Not yet scheduled
> 
> Summary: Ready with nits that should be addressed before publication
Thanks for your thorough review. I did my best to address your comments.
The soon to be published -04 is available here:

https://github.com/dhcwg/privacy/blob/master/draft-ietf-dhc-dhcpv6-privacy-04.txt

You can see the diff here:
https://github.com/dhcwg/privacy/commit/11d08e981fc503d11f31938af05316b7e881bfd6
(scroll down to draft-ietf-dhc-dhcpv6-privacy.xml to see the actual
changes).

> The reference to ietf-6man-ivp6-address-generation-privacy should be 
> normative, and when this document is pointing to it because it is 
> discussing a field carrying a generated address, it should be more 
> explicit about why it's making the reference.
It is normative now. Every reference to this I-D mentions specific
section (See Section 3.2 of ...) and explains that the reference was
made to point to an extended description of each type of attacks. If
this is not sufficient, can you point to specific section or text that
requires further improvement?

> In section 4.3 the paragraph on Hash allocation should note that even
> a well implemented hash does not mitigate the threat of correlation
> over time.
Added. Also added an explanation about the performance. See my response
below why I think it's appropriate.

> In section 4.3, the paragraph on Random allocation comments on the
> poor performance of a specific simplistic implementation of random
> selection. More efficient algorithms exist. But the discussion is
> mostly irrelevant to the document. Please simplify this paragraph to
> focus on the benefits of random allocation.
I somewhat disagree. First, there are more efficient algorithms known,
but they are not always used. This document is a analysis, so we tried
to provide an analysis of what's actually happening in actual
implementations. In an ideal world where privacy is the top priority
every implementation would use truly random allocation using hardware
entropy generators. Sadly, the reality of DHCP servers market is that
performance matters a lot. Lowered performance is a price for better
privacy. This fact directly affects DHCP server implementors, which are
the target audience for this document. These are my arguments why the
discussion about performance penalty is there and should stay in my opinion.

But I think I see your point. The performance aspect was raised only in
random allocation, so it may be mis-interpreted as a way to discredit
random strategy. It is not. I added similar discussion to hash
allocation and added a bit of clarification text. Hopefully it is not
biased in any direction.

BTW This strategy is called random, but the text now explains that it's
really pseudo-random. I can envision a way to hook a hardware random
number generator to a device running DHCP server, but I never heard
about such a solution. Therefore I think pseudo-random is the right word
to use here.

Please let me know if the updated text is satisfactory for you. If not,
I'd love to know which part requires further work.

> Should section 5.3 also call out mapping IP addresses into
> geolocation?
Added a paragraph. I'm not a geolocation expert by any stretch of
imagination, so please correct me if I got it wrong. In general, any
global address assigned by DHCP (or SLAAC for that matter) is
susceptible to the geolocation procedures and the text now clearly
mentions that.

> Why doesn't section 5.5 also talk about things like MAC addresses?
Because there are no MAC addresses in DHCPv6, at least not in the
general case. This is a common surprise, so I added a clarification text
that tries explains it, without going into too much details (it's a
broad topic). Please let me know if the text is sufficient or you want
me work on it further.

> Section 5.6 could probably borrow words from RFC7258 - it should at 
> least reference it (currently there is only a reference from the 
> introduction.)
Good point. It now borrows heavily and references RFC7258.

Also updated one out of date reference.

Thanks a lot for your review and comments.

Tomek


From nobody Mon Feb 15 13:15:30 2016
Return-Path: 
X-Original-To: dhcwg@ietfa.amsl.com
Delivered-To: dhcwg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E3D71B2BD0; Mon, 15 Feb 2016 13:15:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.906
X-Spam-Level: 
X-Spam-Status: No, score=-1.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.006] 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 V0g5-H5c8tMI; Mon, 15 Feb 2016 13:15:25 -0800 (PST)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 ECCE51B2BD1; Mon, 15 Feb 2016 13:15:24 -0800 (PST)
Received: from unnumerable.local (pool-173-57-158-165.dllstx.fios.verizon.net [173.57.158.165]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id u1FLFIIB044573 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=OK); Mon, 15 Feb 2016 15:15:19 -0600 (CST) (envelope-from rjsparks@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host pool-173-57-158-165.dllstx.fios.verizon.net [173.57.158.165] claimed to be unnumerable.local
To: Tomek Mrugalski , General Area Review Team , "ietf@ietf.org" , "dhcwg@ietf.org" , draft-ietf-dhc-dhcpv6-privacy.all@ietf.org
References: <56B0DBA3.2050406@nostrum.com> <56C238F8.4040400@gmail.com>
From: Robert Sparks 
Message-ID: <56C23FE6.5000207@nostrum.com>
Date: Mon, 15 Feb 2016 15:15:18 -0600
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.5.1
MIME-Version: 1.0
In-Reply-To: <56C238F8.4040400@gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [dhcwg] Gen-ART LC review: draft-ietf-dhc-dhcpv6-privacy-03
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 15 Feb 2016 21:15:29 -0000

Hi Tomek -

Thanks for these edits. My points are all addressed, though I wish to 
push a little more on changing the focus of the following in the document:

On 2/15/16 2:45 PM, Tomek Mrugalski wrote:


>
>> In section 4.3, the paragraph on Random allocation comments on the
>> poor performance of a specific simplistic implementation of random
>> selection. More efficient algorithms exist. But the discussion is
>> mostly irrelevant to the document. Please simplify this paragraph to
>> focus on the benefits of random allocation.
> I somewhat disagree. First, there are more efficient algorithms known,
> but they are not always used. This document is a analysis, so we tried
> to provide an analysis of what's actually happening in actual
> implementations. In an ideal world where privacy is the top priority
> every implementation would use truly random allocation using hardware
> entropy generators. Sadly, the reality of DHCP servers market is that
> performance matters a lot. Lowered performance is a price for better
> privacy. This fact directly affects DHCP server implementors, which are
> the target audience for this document. These are my arguments why the
> discussion about performance penalty is there and should stay in my opinion.
Then I suggest this variation:

"In deployed systems, address allocation strategies such as choosing the 
next
sequentially available address are chosen over strategies such as 
pseudo-random
allocation across the available address pool because the latter are more 
difficult
to implement efficiently."

To be very clear (and I do _not_ want to put this discussion in the 
document), an implementation could keep a structure (probably a 
linked-list) of blocks of unallocated addresses, and very efficiently 
select an address pseudo-randomly from the addresses in that structure, 
modifying the structure to make the next selection just as efficient 
(similarly modifying the structure when addresses are returned to the pool).
This would not have the performance degradation that the simple strategy 
you currently discuss has.
While they're entertaining, I think discussing _either_ way of 
approaching such a random selection algorithm distracts the reader from 
the point of understanding the privacy implications.
>
>




RjS


From nobody Mon Feb 15 13:37:09 2016
Return-Path: 
X-Original-To: dhcwg@ietfa.amsl.com
Delivered-To: dhcwg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F4271ACDC0; Mon, 15 Feb 2016 13:37:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.507
X-Spam-Level: 
X-Spam-Status: No, score=-14.507 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 utnsW-9Y5ESe; Mon, 15 Feb 2016 13:37:04 -0800 (PST)
Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C9C0B1A8A11; Mon, 15 Feb 2016 13:37:03 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4176; q=dns/txt; s=iport; t=1455572223; x=1456781823; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=MFF5iZm8BBKuo1/0fOwLfRT7oMpNXb59o4aThW3JTCo=; b=fMwDe7HU7TQCPxlsKABYKzpJ7drjbbFEsUvBaLICJOz1DvVdlFVQfW5j T+trDz5WWjdt7G51jehjAaFAr8SH7H0bhecH3FDpGihv1w4abOlgLFC68 yOKhQXiErIrnYW0O0xgS7VdddUGgZeZNtoWqP8S6JWlZNhPMlN09XwvWJ M=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ACAgCNRMJW/4MNJK1egzqBPwa6FgENg?= =?us-ascii?q?WeGDQIcgRw4FAEBAQEBAQGBCoRBAQEBBCMRUQQCAQgOAwQBAQMCIwMCAgIfERQ?= =?us-ascii?q?BCAgCBAESCId9AxKoTYoDDYRWAQEBAQEBAQEBAQEBAQEBAQEBAQEBFXuIUHuCN?= =?us-ascii?q?4FjgxiBOgWWeQGLYYFsgWOEQ4hVhn6HPwEeAQFCg2Nqh1N8AQEB?=
X-IronPort-AV: E=Sophos;i="5.22,452,1449532800"; d="scan'208";a="76362276"
Received: from alln-core-1.cisco.com ([173.36.13.131]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 15 Feb 2016 21:37:02 +0000
Received: from XCH-RCD-004.cisco.com (xch-rcd-004.cisco.com [173.37.102.14]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u1FLb2sQ021426 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 15 Feb 2016 21:37:02 GMT
Received: from xch-aln-003.cisco.com (173.36.7.13) by XCH-RCD-004.cisco.com (173.37.102.14) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 15 Feb 2016 15:37:02 -0600
Received: from xch-aln-003.cisco.com ([173.36.7.13]) by XCH-ALN-003.cisco.com ([173.36.7.13]) with mapi id 15.00.1104.009; Mon, 15 Feb 2016 15:37:01 -0600
From: "Bernie Volz (volz)" 
To: Robert Sparks , Tomek Mrugalski , General Area Review Team , "ietf@ietf.org" , "dhcwg@ietf.org" , "draft-ietf-dhc-dhcpv6-privacy.all@ietf.org" 
Thread-Topic: Gen-ART LC review: draft-ietf-dhc-dhcpv6-privacy-03
Thread-Index: AQHRaDHdLqFZqGv4dUC+QRkipz148J8uACIA//+gK0A=
Date: Mon, 15 Feb 2016 21:37:01 +0000
Message-ID: <3990c04ce860428ab90d0142102b7bfc@XCH-ALN-003.cisco.com>
References: <56B0DBA3.2050406@nostrum.com> <56C238F8.4040400@gmail.com> <56C23FE6.5000207@nostrum.com>
In-Reply-To: <56C23FE6.5000207@nostrum.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.98.1.200]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: 
Subject: Re: [dhcwg] Gen-ART LC review: draft-ietf-dhc-dhcpv6-privacy-03
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 15 Feb 2016 21:37:05 -0000

UGVyaGFwcyB3ZSBzaG91bGQgZ2V0IGF3YXkgZnJvbSB3aGV0aGVyIHNvbWV0aGluZyBpcyBlYXN5
IG9yIGRpZmZpY3VsdCB0byBpbXBsZW1lbnQgb3Igd2hldGhlciB0aGUgYWxnb3JpdGhtIG1heSBi
ZSBtb3JlIChvciBsZXNzKSBlZmZpY2llbnQuDQoNCkkgdGhpbmsgdGhlIHBvaW50IG9mIHRoaXMg
bWF0ZXJpYWwgaXMgdG8gRU5DT1VSQUdFIHJhbmRvbSBhc3NpZ25tZW50IHJhdGhlciB0aGFuIHNl
cXVlbnRpYWwgdG8gaW1wcm92ZSBwcml2YWN5LSBzbyBrZWVwIGl0IGF0IHRoYXQuIExldCBpbXBs
ZW1lbnRlcnMgd29ycnkgYWJvdXQgaG93IGVmZmljaWVudCBhbiBhbGdvcml0aG0gaXM/DQoNCi0g
QmVybmllDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBSb2JlcnQgU3Bhcmtz
IFttYWlsdG86cmpzcGFya3NAbm9zdHJ1bS5jb21dIA0KU2VudDogTW9uZGF5LCBGZWJydWFyeSAx
NSwgMjAxNiA0OjE1IFBNDQpUbzogVG9tZWsgTXJ1Z2Fsc2tpIDx0b21hc3oubXJ1Z2Fsc2tpQGdt
YWlsLmNvbT47IEdlbmVyYWwgQXJlYSBSZXZpZXcgVGVhbSA8Z2VuLWFydEBpZXRmLm9yZz47IGll
dGZAaWV0Zi5vcmc7IGRoY3dnQGlldGYub3JnOyBkcmFmdC1pZXRmLWRoYy1kaGNwdjYtcHJpdmFj
eS5hbGxAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBHZW4tQVJUIExDIHJldmlldzogZHJhZnQtaWV0
Zi1kaGMtZGhjcHY2LXByaXZhY3ktMDMNCg0KSGkgVG9tZWsgLQ0KDQpUaGFua3MgZm9yIHRoZXNl
IGVkaXRzLiBNeSBwb2ludHMgYXJlIGFsbCBhZGRyZXNzZWQsIHRob3VnaCBJIHdpc2ggdG8gcHVz
aCBhIGxpdHRsZSBtb3JlIG9uIGNoYW5naW5nIHRoZSBmb2N1cyBvZiB0aGUgZm9sbG93aW5nIGlu
IHRoZSBkb2N1bWVudDoNCg0KT24gMi8xNS8xNiAyOjQ1IFBNLCBUb21layBNcnVnYWxza2kgd3Jv
dGU6DQoNCjxzbmlwLz4NCj4NCj4+IEluIHNlY3Rpb24gNC4zLCB0aGUgcGFyYWdyYXBoIG9uIFJh
bmRvbSBhbGxvY2F0aW9uIGNvbW1lbnRzIG9uIHRoZSANCj4+IHBvb3IgcGVyZm9ybWFuY2Ugb2Yg
YSBzcGVjaWZpYyBzaW1wbGlzdGljIGltcGxlbWVudGF0aW9uIG9mIHJhbmRvbSANCj4+IHNlbGVj
dGlvbi4gTW9yZSBlZmZpY2llbnQgYWxnb3JpdGhtcyBleGlzdC4gQnV0IHRoZSBkaXNjdXNzaW9u
IGlzIA0KPj4gbW9zdGx5IGlycmVsZXZhbnQgdG8gdGhlIGRvY3VtZW50LiBQbGVhc2Ugc2ltcGxp
ZnkgdGhpcyBwYXJhZ3JhcGggdG8gDQo+PiBmb2N1cyBvbiB0aGUgYmVuZWZpdHMgb2YgcmFuZG9t
IGFsbG9jYXRpb24uDQo+IEkgc29tZXdoYXQgZGlzYWdyZWUuIEZpcnN0LCB0aGVyZSBhcmUgbW9y
ZSBlZmZpY2llbnQgYWxnb3JpdGhtcyBrbm93biwgDQo+IGJ1dCB0aGV5IGFyZSBub3QgYWx3YXlz
IHVzZWQuIFRoaXMgZG9jdW1lbnQgaXMgYSBhbmFseXNpcywgc28gd2UgdHJpZWQgDQo+IHRvIHBy
b3ZpZGUgYW4gYW5hbHlzaXMgb2Ygd2hhdCdzIGFjdHVhbGx5IGhhcHBlbmluZyBpbiBhY3R1YWwg
DQo+IGltcGxlbWVudGF0aW9ucy4gSW4gYW4gaWRlYWwgd29ybGQgd2hlcmUgcHJpdmFjeSBpcyB0
aGUgdG9wIHByaW9yaXR5IA0KPiBldmVyeSBpbXBsZW1lbnRhdGlvbiB3b3VsZCB1c2UgdHJ1bHkg
cmFuZG9tIGFsbG9jYXRpb24gdXNpbmcgaGFyZHdhcmUgDQo+IGVudHJvcHkgZ2VuZXJhdG9ycy4g
U2FkbHksIHRoZSByZWFsaXR5IG9mIERIQ1Agc2VydmVycyBtYXJrZXQgaXMgdGhhdCANCj4gcGVy
Zm9ybWFuY2UgbWF0dGVycyBhIGxvdC4gTG93ZXJlZCBwZXJmb3JtYW5jZSBpcyBhIHByaWNlIGZv
ciBiZXR0ZXIgDQo+IHByaXZhY3kuIFRoaXMgZmFjdCBkaXJlY3RseSBhZmZlY3RzIERIQ1Agc2Vy
dmVyIGltcGxlbWVudG9ycywgd2hpY2ggDQo+IGFyZSB0aGUgdGFyZ2V0IGF1ZGllbmNlIGZvciB0
aGlzIGRvY3VtZW50LiBUaGVzZSBhcmUgbXkgYXJndW1lbnRzIHdoeSANCj4gdGhlIGRpc2N1c3Np
b24gYWJvdXQgcGVyZm9ybWFuY2UgcGVuYWx0eSBpcyB0aGVyZSBhbmQgc2hvdWxkIHN0YXkgaW4g
bXkgb3Bpbmlvbi4NClRoZW4gSSBzdWdnZXN0IHRoaXMgdmFyaWF0aW9uOg0KDQoiSW4gZGVwbG95
ZWQgc3lzdGVtcywgYWRkcmVzcyBhbGxvY2F0aW9uIHN0cmF0ZWdpZXMgc3VjaCBhcyBjaG9vc2lu
ZyB0aGUgbmV4dCBzZXF1ZW50aWFsbHkgYXZhaWxhYmxlIGFkZHJlc3MgYXJlIGNob3NlbiBvdmVy
IHN0cmF0ZWdpZXMgc3VjaCBhcyBwc2V1ZG8tcmFuZG9tIGFsbG9jYXRpb24gYWNyb3NzIHRoZSBh
dmFpbGFibGUgYWRkcmVzcyBwb29sIGJlY2F1c2UgdGhlIGxhdHRlciBhcmUgbW9yZSBkaWZmaWN1
bHQgdG8gaW1wbGVtZW50IGVmZmljaWVudGx5LiINCg0KVG8gYmUgdmVyeSBjbGVhciAoYW5kIEkg
ZG8gX25vdF8gd2FudCB0byBwdXQgdGhpcyBkaXNjdXNzaW9uIGluIHRoZSBkb2N1bWVudCksIGFu
IGltcGxlbWVudGF0aW9uIGNvdWxkIGtlZXAgYSBzdHJ1Y3R1cmUgKHByb2JhYmx5IGENCmxpbmtl
ZC1saXN0KSBvZiBibG9ja3Mgb2YgdW5hbGxvY2F0ZWQgYWRkcmVzc2VzLCBhbmQgdmVyeSBlZmZp
Y2llbnRseSBzZWxlY3QgYW4gYWRkcmVzcyBwc2V1ZG8tcmFuZG9tbHkgZnJvbSB0aGUgYWRkcmVz
c2VzIGluIHRoYXQgc3RydWN0dXJlLCBtb2RpZnlpbmcgdGhlIHN0cnVjdHVyZSB0byBtYWtlIHRo
ZSBuZXh0IHNlbGVjdGlvbiBqdXN0IGFzIGVmZmljaWVudCAoc2ltaWxhcmx5IG1vZGlmeWluZyB0
aGUgc3RydWN0dXJlIHdoZW4gYWRkcmVzc2VzIGFyZSByZXR1cm5lZCB0byB0aGUgcG9vbCkuDQpU
aGlzIHdvdWxkIG5vdCBoYXZlIHRoZSBwZXJmb3JtYW5jZSBkZWdyYWRhdGlvbiB0aGF0IHRoZSBz
aW1wbGUgc3RyYXRlZ3kgeW91IGN1cnJlbnRseSBkaXNjdXNzIGhhcy4NCldoaWxlIHRoZXkncmUg
ZW50ZXJ0YWluaW5nLCBJIHRoaW5rIGRpc2N1c3NpbmcgX2VpdGhlcl8gd2F5IG9mIGFwcHJvYWNo
aW5nIHN1Y2ggYSByYW5kb20gc2VsZWN0aW9uIGFsZ29yaXRobSBkaXN0cmFjdHMgdGhlIHJlYWRl
ciBmcm9tIHRoZSBwb2ludCBvZiB1bmRlcnN0YW5kaW5nIHRoZSBwcml2YWN5IGltcGxpY2F0aW9u
cy4NCj4NCj4NCg0KPHNuaXAvPg0KDQoNClJqUw0K


From nobody Mon Feb 15 13:43:21 2016
Return-Path: 
X-Original-To: dhcwg@ietfa.amsl.com
Delivered-To: dhcwg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D7D11B2AB4; Mon, 15 Feb 2016 13:43:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.002
X-Spam-Level: 
X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] 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 BgIF_pDHbwP6; Mon, 15 Feb 2016 13:43:13 -0800 (PST)
Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0128.outbound.protection.outlook.com [65.55.169.128]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C93601B2A87; Mon, 15 Feb 2016 13:43:12 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=s+nBIFQFvTAzI7bm8xyaZNjo62g+byyueE1etVdO+uQ=; b=WWhbtp30LOmJxVt9b9VMYIxeK0F5v5euqYVAY40KUtuJtuP1Nfh6Ezu/qhEPiZjWVIr/LEnTbjVWFBMUpEsdJ/vCIlU6v6mdeh5ZbkT5yj5ZkHXBAXEwPu0dcubabi7n45qqbi+Hkk1WfJ57pNYVSl1Dnfbfj0BDwvXB2bkmgOU=
Received: from CY1PR0301MB0649.namprd03.prod.outlook.com (10.160.158.143) by CY1PR0301MB0650.namprd03.prod.outlook.com (10.160.158.144) with Microsoft SMTP Server (TLS) id 15.1.403.16; Mon, 15 Feb 2016 21:43:10 +0000
Received: from CY1PR0301MB0649.namprd03.prod.outlook.com ([10.160.158.143]) by CY1PR0301MB0649.namprd03.prod.outlook.com ([10.160.158.143]) with mapi id 15.01.0403.019; Mon, 15 Feb 2016 21:43:10 +0000
From: Christian Huitema 
To: Stephen Farrell , The IESG 
Thread-Topic: Stephen Farrell's Yes on draft-ietf-dhc-anonymity-profile-07: (with COMMENT)
Thread-Index: AQHRaCDyJAficsYps06tOl4SL6kZa58tmgWg
Date: Mon, 15 Feb 2016 21:43:10 +0000
Message-ID: 
References: <20160215184446.21276.88187.idtracker@ietfa.amsl.com>
In-Reply-To: <20160215184446.21276.88187.idtracker@ietfa.amsl.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: cs.tcd.ie; dkim=none (message not signed) header.d=none;cs.tcd.ie; dmarc=none action=none header.from=microsoft.com;
x-originating-ip: [24.16.156.113]
x-ms-office365-filtering-correlation-id: dc2fa95a-c274-4a15-e4b7-08d33650ffec
x-microsoft-exchange-diagnostics: 1; CY1PR0301MB0650; 5:INZo+FJsj95lry2WDY/oyDLiebuiu+4jYciygkDwU+jVjpMshBZc84XVO6WTotudwXJVArVo3zRnCyI4vp0m/7suD98JCgwoErGpaemxjtmyygu2vqBOWp+EnQwInE+ukGCnuYHPgbOjpG5HdGWTAA==; 24:al2VfJCoW69IKThkbjvPQXhln5wNJwk8GtfD+Q2UtShNgi/JgSk43OQKMsgostsG7drWvzIpDU1Hw2V/jphpnVAJbOMBDXoD9xzJF7xTYys=
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR0301MB0650;
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(61426038)(61427038); SRVR:CY1PR0301MB0650; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0301MB0650; 
x-forefront-prvs: 08534B37A7
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(377454003)(24454002)(106116001)(8990500004)(3280700002)(10290500002)(5003600100002)(230783001)(5004730100002)(122556002)(5001960100002)(92566002)(40100003)(86362001)(86612001)(2906002)(5001770100001)(74316001)(77096005)(76176999)(2950100001)(189998001)(99286002)(11100500001)(10090500001)(66066001)(586003)(5005710100001)(10400500002)(87936001)(50986999)(4326007)(3660700001)(2900100001)(54356999)(5008740100001)(1096002)(1220700001)(5002640100001)(3846002)(33656002)(102836003)(6116002)(76576001)(19580395003); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0301MB0650; H:CY1PR0301MB0649.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; 
spamdiagnosticoutput: 1:23
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Feb 2016 21:43:10.6026 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0301MB0650
Archived-At: 
Cc: "dhc-chairs@ietf.org" , "volz@cisco.com" , "draft-ietf-dhc-anonymity-profile@ietf.org" , "dhcwg@ietf.org" 
Subject: Re: [dhcwg] Stephen Farrell's Yes on draft-ietf-dhc-anonymity-profile-07: (with COMMENT)
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 15 Feb 2016 21:43:17 -0000

T24gTW9uZGF5LCBGZWJydWFyeSAxNSwgMjAxNiAxMDo0NSBBTSwgU3RlcGhlbiBGYXJyZWxsIHdy
b3RlOg0KPiANCj4gVGhhbmsgeW91IGZvciBkb2luZyB0aGlzIHdvcmsuIEkgdGhpbmsgaXQncyBp
bXBvcnRhbnQgYW5kIGFuDQo+IGV4Y2VsbGVudCBleGFtcGxlLg0KDQo6LSkNCg0KPiAtIGdlbmVy
YWw6IEkgaGF2ZSBhIHF1ZXN0aW9uIGZvciB3aGljaCBJIHRoaW5rIGl0J2QgYmUgZ29vZCBpZg0K
PiB0aGUgYW5zd2VyIHdlcmUgdmlzaWJsZSB0byBvdGhlcnMgZG9pbmcgc2ltaWxhciB3b3JrIGxh
dGVyLiBUaGF0DQo+IGNvdWxkIGJlIHJlY29yZGVkIGluIGVtYWlsIHRoYXQgY2FuIGJlIHJlZmVy
ZW5jZWQgKHZpYSBhbg0KPiBhcmNoaXZlIFVSTCkgb3IgaXQgY291bGQgYmUgaW4gdGhpcyBkb2N1
bWVudC4gUGVyaGFwcyB0aGUgbGF0dGVyDQo+IGlzIGJldHRlciwgbm90IHN1cmUuICBBbnl3YXks
IHRoZSBxdWVzdGlvbiBpczogd2hhdCB3YXMgdGhlDQo+IG1ldGhvZG9sb2d5IHVzZWQgdG8gaWRl
bnRpZnkgdGhlIHZhcmlvdXMgREhDUCByZWxhdGVkIGFub255bWl0eQ0KPiBpc3N1ZXMgdGhhdCBu
ZWVkIHRvIGJlIHRhY2tsZWQsIGFuZCB0byBjb25zaWRlci90ZXN0IHByb3Bvc2VkDQo+IG1pdGln
YXRpb25zPyBJIHRoaW5rIGl0IG1heSBiZSB3b3J0aCBpbmNsdWRpbmcgc29tZSB0ZXh0IG9uDQo+
IG1ldGhvZG9sb2d5IGluIHRoaXMgZG9jdW1lbnQgKG1heWJlIGEgbmV3IGFwcGVuZGl4IG9yIGFz
IGENCj4gc2VjdGlvbiAyLjg/KSBzbyB0aGF0IHdlIGNhbiB1c2UgdGhpcyBhcyBhIHNlbGYtY29u
dGFpbmVkDQo+IGV4YW1wbGUgd2hlbiBvdGhlciBmb2xrcyBhcmUgZG9pbmcgc2ltaWxhciB3b3Jr
LiAgKFNvcnJ5IGZvcg0KPiB0cnlpbmcgdG8gYWRkIHdvcmsuKSBJZiBhIHBhcnQgb2YgdGhhdCBh
bnN3ZXIgaXMgZS5nLiAiSSBib3VnaHQNCj4gUmFscGggYSBHJlQiIHRoYXQgaXMgSU1PIGFsc28g
d29ydGggaW5jbHVkaW5nIGluIHNvbWUgYW5vbnltaXNlZA0KPiBmb3JtOi0pDQoNClRoZXJlIGFy
ZSBzZXZlcmFsIHBhcnRzIHRvIHRoaXMuIE9uZSBpcyAiaG93IGRvIHlvdSBnZXQgYSB3b3JraW5n
IGdyb3VwIHRvIHRha2Ugb24gdGhlIHdvcms/IiBUaGF0IGluY2x1ZGVzIG9mIGNvdXJzZSBhIG1p
eCBvZiB0ZWNobmljYWwgYXJndW1lbnRzIGFuZCBwZXJzb25hbCByZWxhdGlvbnMuIFRoaXMgaXMg
bm90IGRpZmZlcmVudCBmcm9tIGFueSBJRVRGIHdvcmssIHdpdGggaW5kaXZpZHVhbCBkcmFmdCBz
dWJtaXNzaW9ucyBwcm9ncmVzc2luZyB0byBXRyBhZG9wdGlvbi4gDQoNClRoZSBzZWNvbmQgcGFy
dCBpcyAiaG93IGRvIHlvdSBpZGVudGlmeSBwcml2YWN5IGlzc3VlcyBpbiBhbiBleGlzdGluZyBw
cm90b2NvbC4iIElmIEkgd3JvdGUgYSBwcm9jZXNzIGRvY3VtZW50LCBJIHdvdWxkIGRlc2NyaWJl
IHNvbWV0aGluZyBzaW1pbGFyIHRvIHNlY3VyaXR5IGFuYWx5c2VzOiBkZXNjcmliZSB0aGUgc3lz
dGVtIGFyY2hpdGVjdHVyZSwgZGVzY3JpYmUgdGhlICJwcml2YWN5IGFzc2V0cywiIGFuYWx5emUg
dGhlIGF0dGFja3MsIHByb3ZpZGUgbWl0aWdhdGlvbnMuIEJ1dCB0aGVyZSBhcmUgYWxzbyBndXQg
ZmVlbGluZ3MgYW5kIGEgbG9uZyBoaXN0b3J5LiANCg0KV2UgaGF2ZSBrbm93biBzaW5jZSB0aGUg
ZWFybHkgOTAncyB0aGF0IGNhcnJ5aW5nIHVuaXF1ZSBpZGVudGlmaWVycyBpbiBNQUMgYWRkcmVz
c2VzIG9mIG1vYmlsZSBkZXZpY2VzIGNvdWxkIGhhdmUgcHJpdmFjeSBpbXBsaWNhdGlvbnMuIFdl
IGhhdmUgcmVmcmFpbmVkIGZyb20gZG9pbmcgYW55dGhpbmcgYWJvdXQgaXQgZm9yIG1hbnkgeWVh
cnMgYmFzZSBvbiB0aGUgIm11bHRpcGxlIGxlYWtzIiB0aGVvcnk6IHdoeSByYW5kb21pemUgdGhl
IE1BQyBhZGRyZXNzZXMgaWYgREhDUCBpcyBnb2luZyB0byBkaXZ1bGdlIHRoZSBtYWNoaW5lJ3Mg
RE5TIG5hbWU/IEFuZCB3aHkgcHJvdGVjdCBESENQIGlmIHRoZSBETlMgdHJhZmZpYyBpcyBhbHNv
IGdvaW5nIHRvIHJldmVhbCB0aGUgdXNlcidzIGlkZW50aXR5PyBBbmQgd2hhdCBhYm91dCBlbWFp
bCBpbiBjbGVhciB0ZXh0PyBPciB0aGUgdXNlciB0cmFja2luZyB0aHJvdWdoIHdlYiBjb29raWVz
Pw0KDQpJIHRoaW5rIHdlIHNhdyBhIGJpZyBjaGFuZ2Ugb2YgYXR0aXR1ZGUgaW4gMjAxMywgdGhh
dCBkcml2ZXMgdXMgdG8gcGx1ZyBhcyBtYW55IGxlYWtzIGFzIHdlIGNhbi4NCg0KPiAtIFRoZSBJ
UFIgZGVjbGFyYXRpb24gbWFrZXMgbWUgYSBiaXQgc2FkLCBidXQgSSB0aGluayB0aGUgV0cNCj4g
ZGlkIHByb2Nlc3MgaXQgYWNjb3JkaW5nIHRvIG91ciBwcm9jZXNzZXMuDQo+IA0KPiAtIGFic3Ry
YWN0OiBJcyAiYW5vbnltb3VzIHRvIHRoZSB2aXNpdGVkIG5ldHdvcmsiIHRoZSByaWdodA0KPiBn
b2FsPyBQZXJoYXBzIGFsc28gIm5vdCBiZSBpZGVudGlmaWVkIGFzIHRoZSBzYW1lIGVudGl0eSBh
cw0KPiBwcmV2aW91c2x5IGNvbm5lY3RlZCB0byB0aGlzIG9yIGFub3RoZXIgbmV0d29yayIgaXMg
bW9yZSBsaWtlDQo+IGl0LCBidXQgdG9vIHdvcmR5Oy0pIElmIHlvdSBjYW4gZmlndXJlIGEgd2F5
IHRvIGluY2x1ZGUgdGhlDQo+ICJhbm90aGVyIG5ldHdvcmsiIGFzcGVjdCBpbiB0aGUgYWJzdHJh
Y3QgdGhhdCdkIGJlIGdvb2QgSSB0aGluaywNCj4gYXMgdGhhdCBtaWdodCBoZWxwIG1vdGl2YXRl
IG5ldHdvcmsgYWRtaW5zIHRvIHdhbnQgdGhpcyBwcm9maWxlLA0KPiBhcyB0aGV5J3JlIG5vdCBv
bmx5IHByb3RlY3RpbmcgdGhlaXIgdXNlcnMgZnJvbSB0aGVtc2VsdmVzLCBidXQNCj4gZnJvbSBv
dGhlciBuZXR3b3JrIGFkbWlucyBhcyB3ZWxsLg0KPiANCj4gLSBzZWN0aW9uIDI6IEluIHRoZSBp
bnRyb2R1Y3RvcnkgdGV4dCwgeW91IGNvdWxkIHVwZGF0ZSB0aGlzIHRvDQo+IHJlZmVyIHRvIElF
RUUncyBvbmdvaW5nIHdvcmsgaGVyZSwgd2hpY2ggSSB0aGluayBpcyBub3cgbW9yZQ0KPiBvZmZp
Y2lhbCB0aGFuIGl0IHdhcyBwZXJoYXBzIHdoZW4gdGhpcyB0ZXh0IHdhcyB3cml0dGVuLg0KDQpX
ZSBjYW4gY2VydGFpbmx5IGNoYW5nZSB0aGUgcmVmZXJlbmNlIHRvIHBvaW50IHRvIHRoZSBJRUVF
IGVmZm9ydC4NCg0KPiAtIDIuNTogVGhlIEd1eSBGYXdrZXMgcmVmZXJlbmNlIG1pZ2h0IG5vdCBi
ZSBtZWFuaW5nZnVsIGluIGENCj4gZmV3IHllYXJzLiBJJ2Qgc3VnZ2VzdCBkZWxldGluZyB0aGF0
IHNlbnRlbmNlLg0KDQpXZSB3ZW50IGJhY2sgYW5kIGZvcnRoIG9uIHRoaXMgb25lLCBsb29raW5n
IGF0IHRoZSAiY3VsdHVyYWwgcmVmZXJlbmNlIiBhcmd1bWVudC4gVGhlIGRlY2lzaW9uIHRvIGtl
ZXAgaXQgd2FzIHZlcnkgY29uc2Npb3VzLg0KDQo+IC0gMy41OiBTbyB0aGlzIHNheXMgdG8gZG8g
dGhlIG9wcG9zaXRlIG9mIDQzNjEsIHdoaWNoIGlzDQo+IGNvcnJlY3QuICBJIHdvbmRlciBkb2Vz
IHRoYXQgbWVhbiB0aGlzIFVQREFURXMgNDM2MT8gKEJ1dCBkb24ndA0KPiBjYXJlIGFib3V0IHRo
ZSBhbnN3ZXI7LSkgU2FtZSBpc3N1ZSBtYXkgYXJpc2Ugd3J0IDMzMTUgSSBndWVzcy4NCj4gKEFu
ZCBJIHN0aWxsIGRvbid0IGNhcmUgYWJvdXQgdGhlIGFuc3dlcjotKQ0KDQpUaGF0IHRvbyB3YXMg
YWN0aXZlbHkgZGlzY3Vzc2VkLiBUaGUgaW5pdGlhbCB2ZXJzaW9ucyBvZiB0aGUgZHJhZnQgbWVu
dGlvbmVkICJ1cGRhdGUgNDM2MSwiIGJ1dCB0aGF0IHJlZmVyZW5jZSB3YXMgcmVtb3ZlZCBhZnRl
ciBXRyBmZWVkYmFjay4gVGhlIHBvaW50IGlzIHRoYXQgd2UgZG8gbm90IHVwZGF0ZSBhbnkgc3Bl
Y2lmaWMgcG9ydGlvbiBvZiA0MzYxLiBJbnN0ZWFkLCB3ZSBwcm92aWRlIGd1aWRhbmNlIG9uIGhv
dyB0byBpbnRlcnByZXQgb3IgdXNlIDQzNjEuDQoNCj4gLSAzLjc6IHR5cG8sICJTT1VMRCINCg0K
RGFuZy4gV2lsbCBmaXggaW4gbmV4dCBlZGl0Lg0KDQo+IC0gNC4zOiAiZnJvbSB0aGUgcHJldmlv
dXMgeWVhciIgLSB0aGF0J3MgbmVhdCEgRG9uJ3QgdGhpbmsgSSd2ZQ0KPiBzZWVuIHRoYXQgYmVm
b3JlLg0KPiANCj4gLSA0LjU6IHR5cG8sICJpbmRlbXRpZmllZCINCg0KV2lsbCBmaXguDQoNCj4g
LSA0LjUuMjogVGhpcyBzdGlsbCBzZWVtcyBhIGJpdCB0b28gbmVnYXRpdmUgdG8gbWUuIENhbid0
IFBEDQo+IGFzc2lzdCBwcml2YWN5IGluIHNvbWUgY2FzZXMgZXZlbiBpZiBmdXJ0aGVyIHN0dWR5
IGlzIG5lZWRlZC4NCj4gRS5nLiBpZiBhIGhvbWUgcm91dGVyIGlzIGdpdmVuIGEgcHJlZml4IHZp
YSBQRCBhbmQgdGhhdCBjaGFuZ2VzDQo+IG5vdyBhbmQgdGhlbi4NCg0KVGhlcmUgaXMgbm90IGEg
bG90IG9mIGRlcGxveW1lbnQgZXhwZXJpZW5jZSB3aXRoICJjbGllbnQgUEQsIiBvciBtb2JpbGUg
ZGV2aWNlcyByb2FtaW5nIHRvIGEgaG90IHNwb3QgYW5kIGFza2luZyBmb3IgZGVsZWdhdGlvbiBv
ZiBhIHByZWZpeC4gV2hhdCB5b3UgZGVzY3JpYmUgaGVyZSBwcm9iYWJseSBiZWxvbmdzIHRvIGEg
ZGlmZmVyZW50IGVmZm9ydDogcm90YXRpbmcgYWRkcmVzc2VzIGFuZCBwcmVmaXhlcyBpbiBob21l
IG5ldHdvcmtzLCB3aXRoIHRoZSBjb29wZXJhdGlvbiBvZiB0aGUgSVNQLCBpbiBvcmRlciB0byBw
cmV2ZW50IHRyYWNraW5nIG9mIHRyYWZmaWMgYnkgYWRkcmVzc2VzLiBMb29rcyBsaWtlIHNvbWV0
aGluZyBmb3IgSU5UQVJFQSwgbm90IERIQ1AuIA0KDQo+IC0gREhDUHY2OiBpcyB0aGVyZSByZWFs
bHkgbm90aGluZyB0byBzYXkgYWJvdXQgbGluayBsb2NhbA0KPiBhZGRyZXNzZXM/IChJJ20gbm90
IHN1cmUgaG93IHRob3NlIGFyZSB1c2VkIGluIERIQ1B2NiwgaWYgdGhleQ0KPiBhcmUsIGJ1dCB0
aGV5IGRvIG9mdGVuIGNvbnRhaW4gTUFDcy4pDQoNCkxvY2FsIGFkZHJlc3NlcyBhcmUgYXNzaWdu
ZWQgYnkgdGhlIGhvc3QgYmVmb3JlIHN0YXJ0aW5nIERIQ1B2Ni4gVGhpcyBpcyBhbiBJUHY2IGlz
c3VlLCBhbmQgdGhlIGRyYWZ0IHBvaW50cyB0byB0aGUgb25nb2luZyB3b3JrIGluIDZNQU46IGRy
YWZ0LWlldGYtNm1hbi1pcHY2LWFkZHJlc3MtZ2VuZXJhdGlvbi1wcml2YWN5Lg0KDQo+IC0gVGhl
IHNlY2RpciByZXZpZXcgb2YgdGhlIGRoY3AtcHJpdmFjeSBkcmFmdCBbMV0gc3VnZ2VzdGVkIHNv
bWUNCj4gYWRkaXRpb25hbCB0ZXh0IGZvciB0aGUgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgdGV4
dCB0aGVyZSB0aGF0DQo+IG1pZ2h0IGJlIGJldHRlciBoZXJlLg0KPiANCj4gICAgWzFdIGh0dHBz
Oi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvc2VjZGlyL2N1cnJlbnQvbXNnMDYzMzgu
aHRtbA0KPiANCj4gKFBTOiBUaGlzIHJldmlldyB3YXMgZG9uZSBvbiAtMDYgd2l0aCBhIHF1aWNr
IGxvb2sgYXQgdGhlIGRpZmYNCj4gdnMuIC0wNy4gSSB0aGluayBpdCBhbGwgc3RpbGwgYXBwbGll
cyB0aG91Z2guKQ0KDQotLSBDaHJpc3RpYW4gSHVpdGVtYQ0KDQoNCg0KDQo=


From nobody Mon Feb 15 14:04:12 2016
Return-Path: 
X-Original-To: dhcwg@ietfa.amsl.com
Delivered-To: dhcwg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65E1C1B2D4E; Mon, 15 Feb 2016 14:04:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.307
X-Spam-Level: 
X-Spam-Status: No, score=-4.307 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] 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 HxetBWAXszDq; Mon, 15 Feb 2016 14:04:09 -0800 (PST)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 810241B2D44; Mon, 15 Feb 2016 14:04:09 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id C53A6BE3F; Mon, 15 Feb 2016 22:04:07 +0000 (GMT)
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nMbeEIYUT3r0; Mon, 15 Feb 2016 22:04:06 +0000 (GMT)
Received: from [172.16.22.120] (unknown [216.127.117.40]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id B2022BE33; Mon, 15 Feb 2016 22:04:04 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1455573846; bh=EGkRogbo1NQxARs3OQhBmf4SiTujFhdil+AksMvXCM8=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=WSmqdgZqfLt5M5hjXOG0Q8Y57gYS7rf+DnW47oENeHsJLbHeA5goO7T7OJAazW6ke tuv9OLFIkhGkNKTECV0xpLPseCJ1SYM+5NfwTX4T3qX/GeNpxPCRVdRaxO7bK898U/ Yi5NK/CFy02MuC69OAqO2HXudsqZ5TC/LFpaGyaQ=
To: Christian Huitema , The IESG 
References: <20160215184446.21276.88187.idtracker@ietfa.amsl.com> 
From: Stephen Farrell 
Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
X-Enigmail-Draft-Status: N1110
Message-ID: <56C24B52.6060008@cs.tcd.ie>
Date: Mon, 15 Feb 2016 22:04:02 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms060906080605060904050408"
Archived-At: 
Cc: "dhc-chairs@ietf.org" , "volz@cisco.com" , "draft-ietf-dhc-anonymity-profile@ietf.org" , "dhcwg@ietf.org" 
Subject: Re: [dhcwg] Stephen Farrell's Yes on draft-ietf-dhc-anonymity-profile-07: (with COMMENT)
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 15 Feb 2016 22:04:11 -0000

This is a cryptographically signed message in MIME format.

--------------ms060906080605060904050408
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


Hiya,

(Trimming to the interesting bit.)

On 15/02/16 21:43, Christian Huitema wrote:
> On Monday, February 15, 2016 10:45 AM, Stephen Farrell wrote:
>>=20
>> - general: I have a question for which I think it'd be good if the
>> answer were visible to others doing similar work later. That could
>> be recorded in email that can be referenced (via an archive URL) or
>> it could be in this document. Perhaps the latter is better, not
>> sure.  Anyway, the question is: what was the methodology used to
>> identify the various DHCP related anonymity issues that need to be
>> tackled, and to consider/test proposed mitigations? I think it may
>> be worth including some text on methodology in this document (maybe
>> a new appendix or as a section 2.8?) so that we can use this as a
>> self-contained example when other folks are doing similar work.
>> (Sorry for trying to add work.) If a part of that answer is e.g. "I
>> bought Ralph a G&T" that is IMO also worth including in some
>> anonymised form:-)
>=20
> There are several parts to this. One is "how do you get a working
> group to take on the work?" That includes of course a mix of
> technical arguments and personal relations. This is not different
> from any IETF work, with individual draft submissions progressing to
> WG adoption.

Agreed. I don't think there's anything to include here about this.

>=20
> The second part is "how do you identify privacy issues in an existing
> protocol." If I wrote a process document, I would describe something
> similar to security analyses: describe the system architecture,
> describe the "privacy assets," analyze the attacks, provide
> mitigations. But there are also gut feelings and a long history.
>=20
> We have known since the early 90's that carrying unique identifiers
> in MAC addresses of mobile devices could have privacy implications.
> We have refrained from doing anything about it for many years base on
> the "multiple leaks" theory: why randomize the MAC addresses if DHCP
> is going to divulge the machine's DNS name? And why protect DHCP if
> the DNS traffic is also going to reveal the user's identity? And what
> about email in clear text? Or the user tracking through web cookies?
>=20
> I think we saw a big change of attitude in 2013, that drives us to
> plug as many leaks as we can.

So, from watching this, I think I saw the following "method" being
applied (or something similar) and I continue to wonder if describing
something like this might help the next set of folks who take on
doing similarly good work.

Trying to cast this as text that could be the starting point for
inclusion as a new section 2.8 or appendix, maybe that'd be
something like:

"In outline, the process leading to this specification, was to,
within the usual IETF consensus process [BCP9]:

1. Get some level of agreement that there are privacy issues to
   address with protocol  and assemble people willing to help,
   some who know about  and some who know about privacy.
2. Identify relevant issues by surveying RFCs, implementations and
   deployments.
3. Discuss (in a WG or wherever) how one might mitigate those
   privacy issues, and the effects of mitigations (including
   ways in which mitigations may break things done today).
4. Figure out which mitigations can be deployed without breaking
   things badly and that do usefully improve privacy.
5. Write a profile of  and/or update  to be more
   privacy friendly, documenting #2-#4.

While this sequence can take some time (a year or two), it should
lead to results that are more likely to get widely deployed, compared
to simply developing an implementation of  that includes your
own preferred set of privacy enhancements."

I think the above is reasonably accurate, but I'm really not sure
how much it's utterly obvious or if it'd be useful for a new set
of people working on privacy issues of the next .

Cheers,
S.


>=20


--------------ms060906080605060904050408
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC
CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ
BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD
ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll
bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw
aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA
Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra
C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3
rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5
R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r
dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt
3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw
MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ
QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv
BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5
BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu
Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll
bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc
MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE
MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG
9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD
C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9
U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM
aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai
9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC
BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE
BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs
IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g
QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC
SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj
YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC
ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv
mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm
VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4
D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI
dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu
N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE
FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp
MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE
WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG
JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+
SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g
BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv
bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY
0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF
NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9
uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p
6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv
Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu
mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7
RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO
/ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN
JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM
MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG
A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0
Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA
oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjAyMTUy
MjA0MDJaMC8GCSqGSIb3DQEJBDEiBCD9FxDDmUA2Uqspkxq5qYJ/yGarO9ko6o8pHn1Y89yo
jzBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN
AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC
AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0
Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw
IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB
nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t
IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD
VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq
hkiG9w0BAQEFAASCAQBbot0H6mKmSrkyxceABTgkmVNyo9ySJY+idMxLO3O3ib/7ldWJ4Lgs
yVBKhGmGGBIvq20DsSLRsslV2rc4l+Qe9jdj6iN/QIVfAWKlFR4+dkba7YUf9ac1y1C6J8Kq
yZXJ9cUvUvXrN29H6EJ05xAWHXw34xLWzQfxU/tifvFegaODP3qarJH8iNkhDIqwHr03plVv
gmzBnx9pHCKbNzmQnxVvb7qzgy/pj6LDsE9YscjBylIyHjS66P/DqoIhNQaRgIfx6eBD6lSM
c3CcHK0Y4X6xOqhCWo9GEsMOmkUZCwJLv1hnH10nKICAe14+tFb6DQBZxEqGh9/jwzzKp1WN
AAAAAAAA
--------------ms060906080605060904050408--


From nobody Mon Feb 15 14:10:30 2016
Return-Path: 
X-Original-To: dhcwg@ietfa.amsl.com
Delivered-To: dhcwg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A7761B2EE7; Mon, 15 Feb 2016 14:10:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.906
X-Spam-Level: 
X-Spam-Status: No, score=-1.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.006] 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 KEWmJFOctuJd; Mon, 15 Feb 2016 14:10:27 -0800 (PST)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 9C1A41B2EE4; Mon, 15 Feb 2016 14:10:27 -0800 (PST)
Received: from unnumerable.local (pool-173-57-158-165.dllstx.fios.verizon.net [173.57.158.165]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id u1FMAJjr049173 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=OK); Mon, 15 Feb 2016 16:10:20 -0600 (CST) (envelope-from rjsparks@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host pool-173-57-158-165.dllstx.fios.verizon.net [173.57.158.165] claimed to be unnumerable.local
To: "Bernie Volz (volz)" , Tomek Mrugalski , General Area Review Team , "ietf@ietf.org" , "dhcwg@ietf.org" , "draft-ietf-dhc-dhcpv6-privacy.all@ietf.org" 
References: <56B0DBA3.2050406@nostrum.com> <56C238F8.4040400@gmail.com> <56C23FE6.5000207@nostrum.com> <3990c04ce860428ab90d0142102b7bfc@XCH-ALN-003.cisco.com>
From: Robert Sparks 
Message-ID: <56C24CCB.9060802@nostrum.com>
Date: Mon, 15 Feb 2016 16:10:19 -0600
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.5.1
MIME-Version: 1.0
In-Reply-To: <3990c04ce860428ab90d0142102b7bfc@XCH-ALN-003.cisco.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [dhcwg] Gen-ART LC review: draft-ietf-dhc-dhcpv6-privacy-03
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 15 Feb 2016 22:10:29 -0000

On 2/15/16 3:37 PM, Bernie Volz (volz) wrote:
> Perhaps we should get away from whether something is easy or difficult to implement or whether the algorithm may be more (or less) efficient.
>
> I think the point of this material is to ENCOURAGE random assignment rather than sequential to improve privacy- so keep it at that. Let implementers worry about how efficient an algorithm is?
Right - that's where I'm trying to get the document to go.
>
> - Bernie
>
> -----Original Message-----
> From: Robert Sparks [mailto:rjsparks@nostrum.com]
> Sent: Monday, February 15, 2016 4:15 PM
> To: Tomek Mrugalski ; General Area Review Team ; ietf@ietf.org; dhcwg@ietf.org; draft-ietf-dhc-dhcpv6-privacy.all@ietf.org
> Subject: Re: Gen-ART LC review: draft-ietf-dhc-dhcpv6-privacy-03
>
> Hi Tomek -
>
> Thanks for these edits. My points are all addressed, though I wish to push a little more on changing the focus of the following in the document:
>
> On 2/15/16 2:45 PM, Tomek Mrugalski wrote:
>
> 
>>> In section 4.3, the paragraph on Random allocation comments on the
>>> poor performance of a specific simplistic implementation of random
>>> selection. More efficient algorithms exist. But the discussion is
>>> mostly irrelevant to the document. Please simplify this paragraph to
>>> focus on the benefits of random allocation.
>> I somewhat disagree. First, there are more efficient algorithms known,
>> but they are not always used. This document is a analysis, so we tried
>> to provide an analysis of what's actually happening in actual
>> implementations. In an ideal world where privacy is the top priority
>> every implementation would use truly random allocation using hardware
>> entropy generators. Sadly, the reality of DHCP servers market is that
>> performance matters a lot. Lowered performance is a price for better
>> privacy. This fact directly affects DHCP server implementors, which
>> are the target audience for this document. These are my arguments why
>> the discussion about performance penalty is there and should stay in my opinion.
> Then I suggest this variation:
>
> "In deployed systems, address allocation strategies such as choosing the next sequentially available address are chosen over strategies such as pseudo-random allocation across the available address pool because the latter are more difficult to implement efficiently."
>
> To be very clear (and I do _not_ want to put this discussion in the document), an implementation could keep a structure (probably a
> linked-list) of blocks of unallocated addresses, and very efficiently select an address pseudo-randomly from the addresses in that structure, modifying the structure to make the next selection just as efficient (similarly modifying the structure when addresses are returned to the pool).
> This would not have the performance degradation that the simple strategy you currently discuss has.
> While they're entertaining, I think discussing _either_ way of approaching such a random selection algorithm distracts the reader from the point of understanding the privacy implications.
>>
> 
>
>
> RjS


From nobody Mon Feb 15 17:11:51 2016
Return-Path: 
X-Original-To: dhcwg@ietfa.amsl.com
Delivered-To: dhcwg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 594881A893A; Mon, 15 Feb 2016 17:11:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.002
X-Spam-Level: 
X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] 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 BOJgoLnyuwLH; Mon, 15 Feb 2016 17:11:48 -0800 (PST)
Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0139.outbound.protection.outlook.com [207.46.100.139]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 56B0B1A6F98; Mon, 15 Feb 2016 17:11:48 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=09fX1or52IxmcJ9hQ2JLO+9g3wZMo4G2dVmJw/t1HR0=; b=HPLo4yDVkZYxDbaHoi+DwMo4a9Qw2Gs/q2J9+ehSwXcObnuzBbHG0tIbCjKbce550Z5PDsA/EtwfEOl4HYKgS9nk4qoUy0KtieJk3cB0DQeQ1QqNs+nTO/tDb2KiY3nwUE9NzfoWmspTEC3pRsGmkjHSvE6CVJhLsyhd4K0fneE=
Received: from CY1PR0301MB0649.namprd03.prod.outlook.com (10.160.158.143) by CY1PR0301MB0651.namprd03.prod.outlook.com (10.160.158.145) with Microsoft SMTP Server (TLS) id 15.1.403.16; Tue, 16 Feb 2016 01:11:45 +0000
Received: from CY1PR0301MB0649.namprd03.prod.outlook.com ([10.160.158.143]) by CY1PR0301MB0649.namprd03.prod.outlook.com ([10.160.158.143]) with mapi id 15.01.0403.019; Tue, 16 Feb 2016 01:11:45 +0000
From: Christian Huitema 
To: Stephen Farrell , The IESG 
Thread-Topic: Stephen Farrell's Yes on draft-ietf-dhc-anonymity-profile-07: (with COMMENT)
Thread-Index: AQHRaCDyJAficsYps06tOl4SL6kZa58tmgWggAAPRwCAADJdsA==
Date: Tue, 16 Feb 2016 01:11:45 +0000
Message-ID: 
References: <20160215184446.21276.88187.idtracker@ietfa.amsl.com>  <56C24B52.6060008@cs.tcd.ie>
In-Reply-To: <56C24B52.6060008@cs.tcd.ie>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: cs.tcd.ie; dkim=none (message not signed) header.d=none;cs.tcd.ie; dmarc=none action=none header.from=microsoft.com;
x-originating-ip: [24.16.156.113]
x-ms-office365-filtering-correlation-id: 3c781915-0033-49fb-6503-08d3366e232c
x-microsoft-exchange-diagnostics: 1; CY1PR0301MB0651; 5:EimPQx60U8cJPh1zdKvx3FeY3HDsPIR+qNrGKvgYQDvWMDt2f/oQaugIhNz5NomaElOMrTXQAgfXzKPuftg6y+HPw3o13PypAdu+Q+kBSOUwEtDBgUaguTLQ4PEDaOArhQS6LaIxa3u5QTNq5Kj4Iw==; 24:WWJR5xgttOwTeewrlKiFLy5SQKqmjxcLgna1sc3NAwleUGHGSRlVqS3ZYg+A3trtEjF3l8GmRScWKA+iUDbEZ1jxdrRU/q41K/eKRpc2Bjg=
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR0301MB0651;
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(61426038)(61427038); SRVR:CY1PR0301MB0651; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0301MB0651; 
x-forefront-prvs: 0854128AF0
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(24454002)(377454003)(122556002)(76576001)(10090500001)(40100003)(92566002)(11100500001)(230783001)(74316001)(87936001)(5005710100001)(10400500002)(189998001)(86362001)(3660700001)(3280700002)(77096005)(5001770100001)(54356999)(50986999)(5008740100001)(33656002)(2950100001)(2906002)(5001960100002)(5002640100001)(66066001)(1096002)(3846002)(4326007)(586003)(6116002)(102836003)(10290500002)(5003600100002)(86612001)(106116001)(99286002)(1220700001)(76176999); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0301MB0651; H:CY1PR0301MB0649.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; 
spamdiagnosticoutput: 1:23
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Feb 2016 01:11:45.1286 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0301MB0651
Archived-At: 
Cc: "dhc-chairs@ietf.org" , "volz@cisco.com" , "draft-ietf-dhc-anonymity-profile@ietf.org" , "dhcwg@ietf.org" 
Subject: Re: [dhcwg] Stephen Farrell's Yes on draft-ietf-dhc-anonymity-profile-07: (with COMMENT)
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 16 Feb 2016 01:11:50 -0000

T24gTW9uZGF5LCBGZWJydWFyeSAxNSwgMjAxNiAyOjA0IFBNLCBTdGVwaGVuIEZhcnJlbGwgd3Jv
dGU6IA0KPiAoVHJpbW1pbmcgdG8gdGhlIGludGVyZXN0aW5nIGJpdC4pDQo+IC4uLg0KPiBTbywg
ZnJvbSB3YXRjaGluZyB0aGlzLCBJIHRoaW5rIEkgc2F3IHRoZSBmb2xsb3dpbmcgIm1ldGhvZCIg
YmVpbmcNCj4gYXBwbGllZCAob3Igc29tZXRoaW5nIHNpbWlsYXIpIGFuZCBJIGNvbnRpbnVlIHRv
IHdvbmRlciBpZiBkZXNjcmliaW5nDQo+IHNvbWV0aGluZyBsaWtlIHRoaXMgbWlnaHQgaGVscCB0
aGUgbmV4dCBzZXQgb2YgZm9sa3Mgd2hvIHRha2Ugb24NCj4gZG9pbmcgc2ltaWxhcmx5IGdvb2Qg
d29yay4NCj4gDQo+IFRyeWluZyB0byBjYXN0IHRoaXMgYXMgdGV4dCB0aGF0IGNvdWxkIGJlIHRo
ZSBzdGFydGluZyBwb2ludCBmb3INCj4gaW5jbHVzaW9uIGFzIGEgbmV3IHNlY3Rpb24gMi44IG9y
IGFwcGVuZGl4LCBtYXliZSB0aGF0J2QgYmUNCj4gc29tZXRoaW5nIGxpa2U6DQo+IA0KPiAiSW4g
b3V0bGluZSwgdGhlIHByb2Nlc3MgbGVhZGluZyB0byB0aGlzIHNwZWNpZmljYXRpb24sIHdhcyB0
bywNCj4gd2l0aGluIHRoZSB1c3VhbCBJRVRGIGNvbnNlbnN1cyBwcm9jZXNzIFtCQ1A5XToNCj4g
DQo+IDEuIEdldCBzb21lIGxldmVsIG9mIGFncmVlbWVudCB0aGF0IHRoZXJlIGFyZSBwcml2YWN5
IGlzc3VlcyB0bw0KPiAgICBhZGRyZXNzIHdpdGggcHJvdG9jb2wgPGZvbz4gYW5kIGFzc2VtYmxl
IHBlb3BsZSB3aWxsaW5nIHRvIGhlbHAsDQo+ICAgIHNvbWUgd2hvIGtub3cgYWJvdXQgPGZvbz4g
YW5kIHNvbWUgd2hvIGtub3cgYWJvdXQgcHJpdmFjeS4NCj4gMi4gSWRlbnRpZnkgcmVsZXZhbnQg
aXNzdWVzIGJ5IHN1cnZleWluZyBSRkNzLCBpbXBsZW1lbnRhdGlvbnMgYW5kDQo+ICAgIGRlcGxv
eW1lbnRzLg0KPiAzLiBEaXNjdXNzIChpbiBhIFdHIG9yIHdoZXJldmVyKSBob3cgb25lIG1pZ2h0
IG1pdGlnYXRlIHRob3NlDQo+ICAgIHByaXZhY3kgaXNzdWVzLCBhbmQgdGhlIGVmZmVjdHMgb2Yg
bWl0aWdhdGlvbnMgKGluY2x1ZGluZw0KPiAgICB3YXlzIGluIHdoaWNoIG1pdGlnYXRpb25zIG1h
eSBicmVhayB0aGluZ3MgZG9uZSB0b2RheSkuDQo+IDQuIEZpZ3VyZSBvdXQgd2hpY2ggbWl0aWdh
dGlvbnMgY2FuIGJlIGRlcGxveWVkIHdpdGhvdXQgYnJlYWtpbmcNCj4gICAgdGhpbmdzIGJhZGx5
IGFuZCB0aGF0IGRvIHVzZWZ1bGx5IGltcHJvdmUgcHJpdmFjeS4NCj4gNS4gV3JpdGUgYSBwcm9m
aWxlIG9mIDxmb28+IGFuZC9vciB1cGRhdGUgPGZvbz4gdG8gYmUgbW9yZQ0KPiAgICBwcml2YWN5
IGZyaWVuZGx5LCBkb2N1bWVudGluZyAjMi0jNC4NCj4gDQo+IFdoaWxlIHRoaXMgc2VxdWVuY2Ug
Y2FuIHRha2Ugc29tZSB0aW1lIChhIHllYXIgb3IgdHdvKSwgaXQgc2hvdWxkDQo+IGxlYWQgdG8g
cmVzdWx0cyB0aGF0IGFyZSBtb3JlIGxpa2VseSB0byBnZXQgd2lkZWx5IGRlcGxveWVkLCBjb21w
YXJlZA0KPiB0byBzaW1wbHkgZGV2ZWxvcGluZyBhbiBpbXBsZW1lbnRhdGlvbiBvZiA8Zm9vPiB0
aGF0IGluY2x1ZGVzIHlvdXINCj4gb3duIHByZWZlcnJlZCBzZXQgb2YgcHJpdmFjeSBlbmhhbmNl
bWVudHMuIg0KPiANCj4gSSB0aGluayB0aGUgYWJvdmUgaXMgcmVhc29uYWJseSBhY2N1cmF0ZSwg
YnV0IEknbSByZWFsbHkgbm90IHN1cmUNCj4gaG93IG11Y2ggaXQncyB1dHRlcmx5IG9idmlvdXMg
b3IgaWYgaXQnZCBiZSB1c2VmdWwgZm9yIGEgbmV3IHNldA0KPiBvZiBwZW9wbGUgd29ya2luZyBv
biBwcml2YWN5IGlzc3VlcyBvZiB0aGUgbmV4dCA8Zm9vPi4NCg0KTG9va2luZyBhdCAibWV0YWRh
dGEgbWluaW1pemF0aW9uLCIgd2UgaGF2ZSB0aHJlZSBvciBmb3VyIHN1Y2Nlc3NmdWwgZXhwZXJp
ZW5jZXMgc28gZmFyLCBhbmQgb25lIHNwZWN0YWN1bGFyIGZhaWx1cmUuIFdlIHNlZSB3b3JrIHBy
b2dyZXNzaW5nIHdlbGwgYW5kIGVhcmx5IGRlcGxveW1lbnRzIGZvciBESENQIHByaXZhY3ksIElQ
djYgYWRkcmVzcyBwcml2YWN5LCBETlMgbWluaW1pemF0aW9uIGFuZCBETlMgcHJpdmFjeS4gV2Ug
YWxzbyBzZWUgdGhlIGVhcmx5IGVmZm9ydCBvbiBlbWFpbCBtZXRhZGF0YSBtaW5pbWl6YXRpb24g
c3RhbGxlZCBhZnRlciBhIHNwZWN0YWN1bGFyIGZsYW1lIGZlc3QuIFJhdGhlciB0aGFuIGp1c3Qg
Zm9jdXNpbmcgb24gREhDUCwgbWF5IEkgc3VnZ2VzdCB0aGF0IHdlIHdvcmsgb24gYSBzZXBhcmF0
ZSBkcmFmdCBjb21wYXJpbmcgd2hhdCB3b3JrZWQgYW5kIHdoYXQgZGlkIG5vdD8NCg0KLS0gQ2hy
aXN0aWFuIEh1aXRlbWENCg0KDQoNCg==


From nobody Mon Feb 15 17:22:26 2016
Return-Path: 
X-Original-To: dhcwg@ietfa.amsl.com
Delivered-To: dhcwg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 102AA1A09CF; Mon, 15 Feb 2016 17:22:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.307
X-Spam-Level: 
X-Spam-Status: No, score=-4.307 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] 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 5K7pvB3c4MKE; Mon, 15 Feb 2016 17:22:20 -0800 (PST)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D4A131A0AC8; Mon, 15 Feb 2016 17:22:19 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id C9827BE3E; Tue, 16 Feb 2016 01:22:17 +0000 (GMT)
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ApTP0tpt4QXu; Tue, 16 Feb 2016 01:22:16 +0000 (GMT)
Received: from [172.16.22.120] (unknown [216.127.117.40]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id C8F70BE2D; Tue, 16 Feb 2016 01:22:14 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1455585736; bh=49GuplhGt7z+K4bJraT0oCrETyrzpFJt6+gfLgr7Z24=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=3h9eMb1IiOPCSt6NEDfLXskqHwPS9Xq2ZW8N0Q5+Ia7h2MM/T5izpIH28wLEENe/I 3xKl89wRwdSE5YRqk1I1jYI8p9mKZsY/SefsEUMqfs7BPNeSivT7Q+CyKfRYnIiarH I2qpTpMYc8FuoNYU3DKSqXtK15ZdrMAd2aGADC70=
To: Christian Huitema , The IESG 
References: <20160215184446.21276.88187.idtracker@ietfa.amsl.com>  <56C24B52.6060008@cs.tcd.ie> 
From: Stephen Farrell 
Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Message-ID: <56C279C4.2080308@cs.tcd.ie>
Date: Tue, 16 Feb 2016 01:22:12 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms010601090004090705010102"
Archived-At: 
Cc: "dhc-chairs@ietf.org" , "volz@cisco.com" , "draft-ietf-dhc-anonymity-profile@ietf.org" , "dhcwg@ietf.org" 
Subject: Re: [dhcwg] Stephen Farrell's Yes on draft-ietf-dhc-anonymity-profile-07: (with COMMENT)
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 16 Feb 2016 01:22:22 -0000

This is a cryptographically signed message in MIME format.

--------------ms010601090004090705010102
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


Hiya,

On 16/02/16 01:11, Christian Huitema wrote:
> Looking at "metadata minimization," we have three or four successful
> experiences so far, and one spectacular failure. We see work
> progressing well and early deployments for DHCP privacy, IPv6 address
> privacy, DNS minimization and DNS privacy. We also see the early
> effort on email metadata minimization stalled after a spectacular
> flame fest. Rather than just focusing on DHCP, may I suggest that we
> work on a separate draft comparing what worked and what did not?

That does sound better, yes. But also more work. However, if you're
up for it... maybe let's chat about that separate from this
document, say on the perpass list?

I'd still argue it may be worth capturing what's worked well in this
case though, as I think it'd be fine to have that in this document
too. But, this isn't meant to be anything like blocking, so I'm
fine with whatever you (authors, chairs, responsible AD) prefer.

Cheers,
S.


--------------ms010601090004090705010102
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC
CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ
BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD
ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll
bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw
aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA
Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra
C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3
rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5
R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r
dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt
3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw
MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ
QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv
BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5
BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu
Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll
bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc
MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE
MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG
9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD
C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9
U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM
aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai
9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC
BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE
BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs
IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g
QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC
SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj
YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC
ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv
mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm
VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4
D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI
dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu
N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE
FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp
MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE
WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG
JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+
SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g
BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv
bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY
0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF
NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9
uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p
6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv
Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu
mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7
RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO
/ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN
JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM
MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG
A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0
Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA
oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjAyMTYw
MTIyMTJaMC8GCSqGSIb3DQEJBDEiBCDhuu+lnNMjK9Q1P14ZwNbQI8eqLWQQr+dTxULw5LwX
oDBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN
AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC
AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0
Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw
IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB
nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t
IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD
VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq
hkiG9w0BAQEFAASCAQAStY9/by0ZGUBB8sDeI/bgKs8Sehl9Kk5ZMICifKW83L4kjrEHDm13
TcGJpfYwFmuptq93ZnfInLY3MBdpD8m8kdhlp/1Nb6qsUoM9br949c6kDMD62r76JxWebzYO
SraTmaBQx8j9uce/NVzsyEzvnwkFDaGYLnYncdLRRLF2T/I+jNTT8x71DGVc1VXe6knO3PeE
7lw6y//L4p5riHu6bm1AH4nZR4nvQ7vTROLNQGZoF3FP/qpZODdinJ0/jjBmHCeZV4x5GjHP
4DhSf5fOu66lTGplDbHAIrbl+CbTGPtk4EihNPNpiYwVQy9Nq59hvjVx8IwPv+yrcT9yTvrS
AAAAAAAA
--------------ms010601090004090705010102--


From nobody Mon Feb 15 18:53:31 2016
Return-Path: 
X-Original-To: dhcwg@ietfa.amsl.com
Delivered-To: dhcwg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1B721B32FF for ; Mon, 15 Feb 2016 18:53:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.384
X-Spam-Level: 
X-Spam-Status: No, score=-1.384 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=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 NfaJXqb6VtSu for ; Mon, 15 Feb 2016 18:53:28 -0800 (PST)
Received: from mail-yw0-x229.google.com (mail-yw0-x229.google.com [IPv6:2607:f8b0:4002:c05::229]) (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 7333B1B32F9 for ; Mon, 15 Feb 2016 18:53:28 -0800 (PST)
Received: by mail-yw0-x229.google.com with SMTP id g127so129163070ywf.2 for ; Mon, 15 Feb 2016 18:53:28 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=k6L0NH//M3KxeDYYDrEOh2kZfIG7akiGUFoAj1JBlBM=; b=OcvjKj5GRFC4JdJz7CwFtiX32c02ssAj4cfOSN+tO8TMATNlMcXZDVfv82LKsFQbVB 4HZENzFvTMsFB+6d6cGEBVfSuwNHJFlGmmUO6Rp5metn9rnKnHLBtNoSxxFwafMviC4c ERbz281eCZi6SLvqDneEYbXijPKRn7jPlvR0buPQHNTGKYeUp1+ba9E4BAeXG3Fzen84 U0DMjtrpQhR1z5Tat0+l6HdNQdwof3fy5Es8iGxO8hFS3+qTi8N0cwNVGU5n1I3e1nNl HpNycJJwAXi5rCjIZqm/TfqVVTIYndKT9uIDBFBgsRCKM/NQJTAZsK+UQ4MnJS5SmIDZ uPcQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=k6L0NH//M3KxeDYYDrEOh2kZfIG7akiGUFoAj1JBlBM=; b=WUPQQnCjMoGc2tihDD2S79c3o+prHsohqKryBQE06+3am+klmDRn7rKvzAHOBtu+XP PjHRT1U/lWpuhXBSeV78CN4RN94Ps4fnTVtxvn+pvoUQW+qfdQ0oK2QmIheQb+iRB+pM FRG3RPoaFf0ItQrwJW1Rp2LI67KL0Du1NWNUB+dToyd1jHlL/ErAmMsmWk7Yi/UKlY5G y31olnfRHV+B1GF5gafdM1jEkHngR1nj1oxIA4NWPY0ZWh9F6Q4nWf7r9jYOJ5pm1Vwm /8uQQtSOed3VCWJX+BQxYMPS/mae74Sp/xvRytAs7DmMhXHSwi5fHiSwpLmUz+A7CAlf HUwQ==
X-Gm-Message-State: AG10YOTbNhVqc5Bg0HSlJhnQjTyMKsTnt1ZJpsXtTSDNOqDBMeYIOY9nCUnzsMPTwTX+4Y3fGsF8URI5MBzsZSpf
X-Received: by 10.129.96.213 with SMTP id u204mr10771488ywb.307.1455591207573;  Mon, 15 Feb 2016 18:53:27 -0800 (PST)
MIME-Version: 1.0
Received: by 10.37.55.80 with HTTP; Mon, 15 Feb 2016 18:53:07 -0800 (PST)
In-Reply-To: <20160201142413.30288.23248.idtracker@ietfa.amsl.com>
References: <20160201142413.30288.23248.idtracker@ietfa.amsl.com>
From: Lorenzo Colitti 
Date: Tue, 16 Feb 2016 11:53:07 +0900
Message-ID: 
To: IETF Discussion 
Content-Type: multipart/alternative; boundary=001a114926e8de2c0b052bda3c0a
Archived-At: 
Cc: dhc-chairs@ietf.org, "dhcwg@ietf.org" , iesg@ietf.org, draft-ietf-dhc-anonymity-profile@ietf.org, "Bernie Volz \(volz\)" 
Subject: Re: [dhcwg] Last Call:  (Anonymity profile for DHCP clients) to Proposed Standard
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 16 Feb 2016 02:53:29 -0000

--001a114926e8de2c0b052bda3c0a
Content-Type: text/plain; charset=UTF-8

On Mon, Feb 1, 2016 at 11:24 PM, The IESG  wrote:

> The IESG has received a request from the Dynamic Host Configuration WG
> (dhc) to consider the following document:
> - 'Anonymity profile for DHCP clients'
>    as Proposed Standard
>
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action. Please send substantive comments to the
> ietf@ietf.org mailing lists by 2016-02-15.


Christian et al., thanks for taking on this work. But I think an important
point here is missing.

It seems to me that fundamental design of DHCP relies on the client blindly
broadcasting information to anyone that happens to be on link, or on the
path between relay and server. This information is both explicit - e.g.,
previous IP addresses assigned, hostnames, etc. - and implicit - e.g., via
implementation behaviour and unique combinations of options.

It's true that this profile mitigates the amount of information that can be
collected. But in IPv6 we have other configuration methods - such as SLAAC
- that broadcast way less information than stateless DHCPv6, which in turn
broadcasts less information than stateless DHCPv6.

This document should recognize that at least on IPv6-only networks, it is
an option not to use DHCP at all, and that option has substantial privacy
benefits that are in many cases above what this profile can provide.

--001a114926e8de2c0b052bda3c0a
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


On M=
on, Feb 1, 2016 at 11:24 PM, The IESG <iesg-secretary@ietf.org&g=
t; wrote:
The IESG has received a request from t=
he Dynamic Host Configuration WG

(dhc) to consider the following document:

- 'Anonymity profile for DHCP clients'

=C2=A0 <draft-ietf-dhc-anonymity-profile-06.txt> as Proposed Standard=




The IESG plans to make a decision in the next few weeks, and solicits

final comments on this action. Please send substantive comments to the

ietf@ietf.org mailin=
g lists by 2016-02-15.

Christian et al., th=
anks for taking on this work. But I think an important point here is missin=
g.

It seems to me that fundamental design of DHCP =
relies on the client blindly broadcasting information to anyone that happen=
s to be on link, or on the path between relay and server. This information =
is both explicit - e.g., previous IP addresses assigned, hostnames, etc. - =
and implicit - e.g., via implementation behaviour and unique combinations o=
f options.

It's true that this profile mitigat=
es the amount of information that can be collected. But in IPv6 we have oth=
er configuration methods - such as SLAAC - that broadcast way less informat=
ion than stateless DHCPv6, which in turn broadcasts less information than s=
tateless DHCPv6.

This document should recogni=
ze that at least on IPv6-only networks, it is an option not to use DHCP at =
all, and that option has substantial privacy benefits that are in many case=
s above what this profile can provide.


--001a114926e8de2c0b052bda3c0a--


From nobody Mon Feb 15 19:55:19 2016
Return-Path: 
X-Original-To: dhcwg@ietf.org
Delivered-To: dhcwg@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F4C11B340D; Mon, 15 Feb 2016 19:55:17 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: "Spencer Dawkins" 
To: "The IESG" 
X-Test-IDTracker: no
X-IETF-IDTracker: 6.14.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20160216035517.20621.9472.idtracker@ietfa.amsl.com>
Date: Mon, 15 Feb 2016 19:55:17 -0800
Archived-At: 
Cc: dhc-chairs@ietf.org, volz@cisco.com, draft-ietf-dhc-anonymity-profile@ietf.org, dhcwg@ietf.org
Subject: [dhcwg] Spencer Dawkins' Yes on draft-ietf-dhc-anonymity-profile-07: (with COMMENT)
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.15
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 16 Feb 2016 03:55:17 -0000

Spencer Dawkins has entered the following ballot position for
draft-ietf-dhc-anonymity-profile-07: Yes

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dhc-anonymity-profile/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thank you for producing this document. It's important. I do have a couple
of observations for you to consider.

In this text:

   We can also
   assume that privacy conscious users will attempt to evade this
   monitoring, for example by ensuring that low level identifiers such
   as link-layer addresses are "randomized," so that the devices do not
   broadcast a unique identifier in every location that they visit.
   
it would be clearer to me if it said "broadcast the same unique
identifier".

I really like 

   Declaring a preference for
   anonymity is a bit like walking around with a Guy Fawkes mask.
   
but I do wonder if that's accessible for a global audience. Is there a
reference, or a short explanation that would work?



From nobody Mon Feb 15 21:26:15 2016
Return-Path: 
X-Original-To: dhcwg@ietfa.amsl.com
Delivered-To: dhcwg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CA941AD1A6 for ; Mon, 15 Feb 2016 21:26:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.001
X-Spam-Level: 
X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, 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 srm5r9IS2E82 for ; Mon, 15 Feb 2016 21:26:11 -0800 (PST)
Received: from xsmtp11.mail2web.com (xsmtp31.mail2web.com [168.144.250.234]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A4EE1A1DBD for ; Mon, 15 Feb 2016 21:26:11 -0800 (PST)
Received: from [10.5.2.31] (helo=xmail09.myhosting.com) by xsmtp11.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1aVY9J-0001Yy-LL for dhcwg@ietf.org; Tue, 16 Feb 2016 00:26:10 -0500
Received: (qmail 13933 invoked from network); 16 Feb 2016 05:26:08 -0000
Received: from unknown (HELO huitema1) (Authenticated-user:_huitema@huitema.net@[24.16.156.113]) (envelope-sender ) by xmail09.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 16 Feb 2016 05:26:07 -0000
From: "Christian Huitema" 
To: "'Lorenzo Colitti'" , "'IETF Discussion'" 
References: <20160201142413.30288.23248.idtracker@ietfa.amsl.com> 
In-Reply-To: 
Date: Mon, 15 Feb 2016 21:26:16 -0800
Message-ID: <003001d1687a$926ab2e0$b74018a0$@huitema.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 15.0
Thread-Index: AQJtbhbfm6E5go4z/5mQ+0EwmlPxoQJwz8dcneKO0vA=
Content-Language: en-us
Archived-At: 
Cc: dhc-chairs@ietf.org, iesg@ietf.org, draft-ietf-dhc-anonymity-profile@ietf.org, dhcwg@ietf.org
Subject: Re: [dhcwg] Last Call:  (Anonymity profile for DHCP clients) to Proposed Standard
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 16 Feb 2016 05:26:13 -0000

On Monday, February 15, 2016 6:53 PM, Lorenzo Colitti wrote:
>
> It's true that this profile mitigates the amount of information that =
can be collected.=20
> But in IPv6 we have other configuration methods - such as SLAAC - that =
broadcast=20
> way less information than stateless DHCPv6, which in turn broadcasts =
less information=20
> than stateless DHCPv6.
>
> This document should recognize that at least on IPv6-only networks, it =
is an option=20
> not to use DHCP at all, and that option has substantial privacy =
benefits that are in=20
> many cases above what this profile can provide.

Well, section 4 of draft-ietf-dhc-anonymity-profile-07 says:

   The choice between the stateful and stateless scenarios depends on
   flag and prefix options published by the "Router Advertisement"
   messages of local routers, as specified in [RFC4861].  When these
   options enable stateless address configuration hosts using the
   anonymity profile SHOULD choose it over stateful address
   configuration, because stateless configuration requires fewer=09
   information disclosures than stateful configuration.

That seems pretty close from what you want, at least as far as "stateful =
DHCPv6" is concerned.

-- Christian Huitema

=20



From nobody Mon Feb 15 21:51:02 2016
Return-Path: 
X-Original-To: dhcwg@ietfa.amsl.com
Delivered-To: dhcwg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 804121A8BC2; Mon, 15 Feb 2016 21:51:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.002
X-Spam-Level: 
X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] 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 eE0LglmLF5Ng; Mon, 15 Feb 2016 21:50:58 -0800 (PST)
Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0130.outbound.protection.outlook.com [65.55.169.130]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EAD751A1B56; Mon, 15 Feb 2016 21:50:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=v2njyx0chdRgLTcy5OgXqNlN4NP8cF/ZkdhLjnyvi40=; b=W5/25YMFlNkHSCmiseCG+vSBJ+BxQW+7KQMOd5gP7i5gxeSAT3JPURm6QR+m0TzwML8lpgOOkNw4sfclymI4xWxZPHk5klI4wqNCMsHCgsSYtzrIlI4Ahpk1QFIjuxy5R4T+qmEgeUUMya7S7qu2/jmnFnuuOJKRgRH6BBzNd3s=
Received: from DM2PR0301MB0655.namprd03.prod.outlook.com (10.160.96.17) by DM2PR0301MB0655.namprd03.prod.outlook.com (10.160.96.17) with Microsoft SMTP Server (TLS) id 15.1.409.15; Tue, 16 Feb 2016 05:50:55 +0000
Received: from DM2PR0301MB0655.namprd03.prod.outlook.com ([10.160.96.17]) by DM2PR0301MB0655.namprd03.prod.outlook.com ([10.160.96.17]) with mapi id 15.01.0409.017; Tue, 16 Feb 2016 05:50:55 +0000
From: Christian Huitema 
To: Spencer Dawkins , The IESG 
Thread-Topic: Spencer Dawkins' Yes on draft-ietf-dhc-anonymity-profile-07: (with COMMENT)
Thread-Index: AQHRaG3bpczO5kMBEkuCTb9k3jQpg58uKjnQ
Date: Tue, 16 Feb 2016 05:50:54 +0000
Message-ID: 
References: <20160216035517.20621.9472.idtracker@ietfa.amsl.com>
In-Reply-To: <20160216035517.20621.9472.idtracker@ietfa.amsl.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=microsoft.com;
x-originating-ip: [24.16.156.113]
x-ms-office365-filtering-correlation-id: d38aff7f-5f1f-4386-1ddd-08d3369522e5
x-microsoft-exchange-diagnostics: 1; DM2PR0301MB0655; 5:femor1sm58nKzTxrbRjl0RljTwLd94um6S2qEjJI8E8ksD4Cx9S0otePz5gmHynyLicfOSdeA//wonqI1KoBLDg+zzwxIs2VElutHhPOBQsMbOfF9w7nqP2h6XE2cd2MuzlmJp3Nb7oUoqHUkVTMXA==; 24:+6jt05msbfbb9F45AWzFt6xE17Eiat4ZcPLQFwyDbWQDkEJYIcPtVeAIiFRFnSGrRp/vBjeabsyV+DcunyCFgZBmLJR0bf31x628PO7SvwY=
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR0301MB0655;
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(61426038)(61427038); SRVR:DM2PR0301MB0655; BCL:0; PCL:0; RULEID:; SRVR:DM2PR0301MB0655; 
x-forefront-prvs: 0854128AF0
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(11905935001)(92566002)(33656002)(15395725005)(74316001)(3280700002)(4326007)(11100500001)(3660700001)(2906002)(5008740100001)(50986999)(66066001)(86362001)(5004730100002)(76176999)(54356999)(586003)(1220700001)(1096002)(19580395003)(3846002)(102836003)(6116002)(76576001)(5003600100002)(5001960100002)(5002640100001)(77096005)(106116001)(99286002)(15975445007)(2900100001)(2950100001)(189998001)(5001770100001)(10090500001)(5005710100001)(10400500002)(122556002)(40100003)(10290500002)(87936001)(230783001); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR0301MB0655; H:DM2PR0301MB0655.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; 
spamdiagnosticoutput: 1:23
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Feb 2016 05:50:54.5495 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0301MB0655
Archived-At: 
Cc: "dhc-chairs@ietf.org" , "volz@cisco.com" , "draft-ietf-dhc-anonymity-profile@ietf.org" , "dhcwg@ietf.org" 
Subject: Re: [dhcwg] Spencer Dawkins' Yes on draft-ietf-dhc-anonymity-profile-07: (with COMMENT)
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 16 Feb 2016 05:51:00 -0000

PiBUaGFuayB5b3UgZm9yIHByb2R1Y2luZyB0aGlzIGRvY3VtZW50LiBJdCdzIGltcG9ydGFudC4g
SSBkbyBoYXZlIGEgY291cGxlDQo+IG9mIG9ic2VydmF0aW9ucyBmb3IgeW91IHRvIGNvbnNpZGVy
Lg0KPiANCj4gSW4gdGhpcyB0ZXh0Og0KPiANCj4gICAgV2UgY2FuIGFsc28NCj4gICAgYXNzdW1l
IHRoYXQgcHJpdmFjeSBjb25zY2lvdXMgdXNlcnMgd2lsbCBhdHRlbXB0IHRvIGV2YWRlIHRoaXMN
Cj4gICAgbW9uaXRvcmluZywgZm9yIGV4YW1wbGUgYnkgZW5zdXJpbmcgdGhhdCBsb3cgbGV2ZWwg
aWRlbnRpZmllcnMgc3VjaA0KPiAgICBhcyBsaW5rLWxheWVyIGFkZHJlc3NlcyBhcmUgInJhbmRv
bWl6ZWQsIiBzbyB0aGF0IHRoZSBkZXZpY2VzIGRvIG5vdA0KPiAgICBicm9hZGNhc3QgYSB1bmlx
dWUgaWRlbnRpZmllciBpbiBldmVyeSBsb2NhdGlvbiB0aGF0IHRoZXkgdmlzaXQuDQo+IA0KPiBp
dCB3b3VsZCBiZSBjbGVhcmVyIHRvIG1lIGlmIGl0IHNhaWQgImJyb2FkY2FzdCB0aGUgc2FtZSB1
bmlxdWUNCj4gaWRlbnRpZmllciIuDQoNCk9LLCB3aWxsIGZpeCBpbiBuZXh0IGVkaXQuDQoNCj4g
SSByZWFsbHkgbGlrZQ0KPiANCj4gICAgRGVjbGFyaW5nIGEgcHJlZmVyZW5jZSBmb3INCj4gICAg
YW5vbnltaXR5IGlzIGEgYml0IGxpa2Ugd2Fsa2luZyBhcm91bmQgd2l0aCBhIEd1eSBGYXdrZXMg
bWFzay4NCj4gDQo+IGJ1dCBJIGRvIHdvbmRlciBpZiB0aGF0J3MgYWNjZXNzaWJsZSBmb3IgYSBn
bG9iYWwgYXVkaWVuY2UuIElzIHRoZXJlIGENCj4gcmVmZXJlbmNlLCBvciBhIHNob3J0IGV4cGxh
bmF0aW9uIHRoYXQgd291bGQgd29yaz8NCg0KV2UgY291bGQgY2VydGFpbmx5IGFkZCBhIHBvaW50
ZXIgdG8gdGhlIFdpa2lwZWRpYSBwYWdlOiBodHRwczovL2VuLndpa2lwZWRpYS5vcmcvd2lraS9H
dXlfRmF3a2VzX21hc2suIE9yIG1heWJlIHRvIG9uZSBvZiB0aGUgcHJpbnQgYXJ0aWNsZXMgdGhh
dCB0aGUgcGFnZSByZWZlcmVuY2VzLCBlLmcuIGh0dHA6Ly90aGV3ZWVrLmNvbS9hcnRpY2xlcy80
NjMxNTEvYnJpZWYtaGlzdG9yeS1ndXktZmF3a2VzLW1hc2suIEFueSBwcmVmZXJlbmNlPw0KDQot
LSBDaHJpc3RpYW4gSHVpdGVtYQ0KDQoNCg0KDQo=


From nobody Mon Feb 15 23:38:24 2016
Return-Path: 
X-Original-To: dhcwg@ietfa.amsl.com
Delivered-To: dhcwg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DFF21ACE54 for ; Mon, 15 Feb 2016 23:38:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.384
X-Spam-Level: 
X-Spam-Status: No, score=-1.384 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=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 EblDbvd9wSng for ; Mon, 15 Feb 2016 23:38:20 -0800 (PST)
Received: from mail-yw0-x229.google.com (mail-yw0-x229.google.com [IPv6:2607:f8b0:4002:c05::229]) (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 26DA41ACE8C for ; Mon, 15 Feb 2016 23:38:20 -0800 (PST)
Received: by mail-yw0-x229.google.com with SMTP id h129so133078550ywb.1 for ; Mon, 15 Feb 2016 23:38:20 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=p6OLAVocNYUImaZyjUc9+Q+pGPWiuIvvfQMHmmdmvvM=; b=HcUoUTreOJfwqBtGubL6vR5PHLKxcGd0Zld1dt11iUCKNR1I07u3WXtMahQD0O1iY5 m7Ui2Tb4S3xTCEeTDJug2IkTDx2ibHGRpGc8rjYNybWtPuA++fVZE0Nlb0y6TywhO37s pDaiEg9aMbXJ5H3UAXiWB3xV0LJSXpHPWYVK25UThuqct+YeYwH3gh79TKxhGETPEmnS II3TklgDwTY1HP5M3Pd71+GLGpRUPs7agGOVw1P1IzdvsrftTbo+wisa7KkOIFYXKS66 aRWinYexEwZjXNha0/+E3Fh03oQWilE1/a/hL+FvcPQxiHNqCsnuPcVQdSz3QPOwXWIM +cbw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=p6OLAVocNYUImaZyjUc9+Q+pGPWiuIvvfQMHmmdmvvM=; b=DQC5VKTUvbIwMGgcX9oCTzWAD2c8QY2Mas/DWLb8F180rfFGA+otdg/j4MnuCePKJB bQkuOc+aO05brR4Fq3xIldWSWc8uOmrVtsyIIWj3BxQuWv5jbVvcIqmXEHidtAOqZwlY rYapWvWz4dpUCA+fdkvQM8NO/7+zcZ+jpsjgwk0jbhP1U4HD1oGZz5NMfI8puDk1hQtW G3JAZN2xJQEkBfroYxY0K3r7CVRYIVEtcSxKpQX/XmVybImRw9clpplb9vUFRqpTOyes PzxLfoNkU5TYbC8CgpcuP/M+fxUM5/jjYPVUoCWpChgyN32rBoZpOeulQ/5xJDh5VeOY nQBw==
X-Gm-Message-State: AG10YOS3SIkXDl4Y6CcWsc5twrn/aVq7EcEym/7oBi+emjnYcMC00exh8cctAY04NptiG979QX/usgbUoXtm0qQn
X-Received: by 10.13.238.194 with SMTP id x185mr12373640ywe.35.1455608299304;  Mon, 15 Feb 2016 23:38:19 -0800 (PST)
MIME-Version: 1.0
Received: by 10.37.55.80 with HTTP; Mon, 15 Feb 2016 23:37:59 -0800 (PST)
In-Reply-To: <003001d1687a$926ab2e0$b74018a0$@huitema.net>
References: <20160201142413.30288.23248.idtracker@ietfa.amsl.com>  <003001d1687a$926ab2e0$b74018a0$@huitema.net>
From: Lorenzo Colitti 
Date: Tue, 16 Feb 2016 16:37:59 +0900
Message-ID: 
To: Christian Huitema 
Content-Type: multipart/alternative; boundary=94eb2c0310949d38ff052bde378e
Archived-At: 
Cc: iesg@ietf.org, dhc-chairs@ietf.org, IETF Discussion , draft-ietf-dhc-anonymity-profile@ietf.org, "dhcwg@ietf.org" 
Subject: Re: [dhcwg] Last Call:  (Anonymity profile for DHCP clients) to Proposed Standard
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 16 Feb 2016 07:38:21 -0000

--94eb2c0310949d38ff052bde378e
Content-Type: text/plain; charset=UTF-8

On Tue, Feb 16, 2016 at 2:26 PM, Christian Huitema 
wrote:

> Well, section 4 of draft-ietf-dhc-anonymity-profile-07 says:
>
>    The choice between the stateful and stateless scenarios depends on
>    flag and prefix options published by the "Router Advertisement"
>    messages of local routers, as specified in [RFC4861].  When these
>    options enable stateless address configuration hosts using the
>    anonymity profile SHOULD choose it over stateful address
>    configuration, because stateless configuration requires fewer
>    information disclosures than stateful configuration.
>
> That seems pretty close from what you want, at least as far as "stateful
> DHCPv6" is concerned.
>

Urg. That statement is pretty hard to understand. In fact, I misunderstood
it for a full 10 minutes until someone explained it to me. I think I
understand it now, and if my understanding is indeed correct, then I would
suggest you clarify it as follows:

   When these options enable stateless address configuration (i.e., when
   the A flag in a Prefix Information Option is set to 1) hosts using the
   anonymity profile SHOULD perform Stateless Address Configuration
   and SHOULD NOT use stateful DHCPv6, because stateless configuration
   requires fewer information disclosures than stateful configuration.

--94eb2c0310949d38ff052bde378e
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


On T=
ue, Feb 16, 2016 at 2:26 PM, Christian Huitema <huitema@huitema.net&=
gt; wrote:
Well, section 4 of draft-ietf-dhc-ano=
nymity-profile-07 says:



=C2=A0 =C2=A0The choice between the stateful and stateless scenarios depend=
s on

=C2=A0 =C2=A0flag and prefix options published by the "Router Advertis=
ement"

=C2=A0 =C2=A0messages of local routers, as specified in [RFC4861].=C2=A0 Wh=
en these

=C2=A0 =C2=A0options enable stateless address configuration hosts using the=


=C2=A0 =C2=A0anonymity profile SHOULD choose it over stateful address

=C2=A0 =C2=A0configuration, because stateless configuration requires fewer<=
br>
=C2=A0 =C2=A0information disclosures than stateful configuration.



That seems pretty close from what you want, at least as far as "statef=
ul DHCPv6" is concerned.

Urg. That=
 statement is pretty hard to understand. In fact, I misunderstood it for a =
full 10 minutes until someone explained it to me. I think I understand it n=
ow, and if my understanding is indeed correct, then I would suggest you cla=
rify it as follows:

=C2=A0 =C2=A0When the=
se options enable stateless address configuration (i.e., when
=C2=
=A0 =C2=A0the A flag in a Prefix Information Option is set to 1) hosts usin=
g the
=C2=A0 =C2=A0anonymity profile SHOULD perform Stateless Add=
ress Configuration
=C2=A0 =C2=A0and SHOULD NOT use stateful DHCPv=
6, because stateless configuration
=C2=A0 =C2=A0requires fewer in=
formation disclosures than stateful configuration.
<=
/div>

--94eb2c0310949d38ff052bde378e--


From nobody Tue Feb 16 02:42:10 2016
Return-Path: 
X-Original-To: dhcwg@ietfa.amsl.com
Delivered-To: dhcwg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AE4B1B2CEF; Tue, 16 Feb 2016 02:42:08 -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, SPF_PASS=-0.001] autolearn=unavailable
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 syguo5lV1pIx; Tue, 16 Feb 2016 02:41:56 -0800 (PST)
Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F6A51B2A90; Tue, 16 Feb 2016 02:41:56 -0800 (PST)
Received: from [192.168.2.101] (unknown [181.165.125.191]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 5333185284; Tue, 16 Feb 2016 11:41:51 +0100 (CET)
To: "Bernie Volz (volz)" , Robert Sparks , Tomek Mrugalski , General Area Review Team , "ietf@ietf.org" , "dhcwg@ietf.org" , "draft-ietf-dhc-dhcpv6-privacy.all@ietf.org" 
References: <56B0DBA3.2050406@nostrum.com> <56C238F8.4040400@gmail.com> <56C23FE6.5000207@nostrum.com> <3990c04ce860428ab90d0142102b7bfc@XCH-ALN-003.cisco.com>
From: Fernando Gont 
X-Enigmail-Draft-Status: N1110
Message-ID: <56C2EE40.1060701@si6networks.com>
Date: Tue, 16 Feb 2016 06:39:12 -0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1
MIME-Version: 1.0
In-Reply-To: <3990c04ce860428ab90d0142102b7bfc@XCH-ALN-003.cisco.com>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [dhcwg] [Gen-art] Gen-ART LC review: draft-ietf-dhc-dhcpv6-privacy-03
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 16 Feb 2016 10:42:08 -0000

Bernie,

On 02/15/2016 06:37 PM, Bernie Volz (volz) wrote:
> Perhaps we should get away from whether something is easy or
> difficult to implement or whether the algorithm may be more (or less)
> efficient.
> 
> I think the point of this material is to ENCOURAGE random assignment
> rather than sequential to improve privacy- so keep it at that. Let
> implementers worry about how efficient an algorithm is?

There are a number of operational and security/privacy considerations
that depend on the actual algorithm that you employ.

I'm not sure what you mean by "random". IID=random() everytime an
address has to be leased? -- or do you really mean "unpredictable"?.

At the end of the day, what you want is to specify desired properties.

Besides, assignment of sequential addresses should be banned. They have
always been a bad idea (see
) and
they shouldn't even be considered an option.

Thanks,
-- 
Fernando Gont
SI6 Networks
e-mail: fgont@si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492





From nobody Tue Feb 16 04:29:39 2016
Return-Path: 
X-Original-To: dhcwg@ietfa.amsl.com
Delivered-To: dhcwg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 224381B3503; Tue, 16 Feb 2016 04:29:33 -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 UQRgznjaMPu6; Tue, 16 Feb 2016 04:29:32 -0800 (PST)
Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A6FB91B3587; Tue, 16 Feb 2016 04:29:21 -0800 (PST)
Received: from clairseach.fuaim.com (clairseach-high.fuaim.com [206.197.161.158]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id 858DF880E6; Tue, 16 Feb 2016 04:29:21 -0800 (PST)
Received: from clemson.local (unknown [76.21.129.88]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id 9C1E5328081A; Tue, 16 Feb 2016 04:29:20 -0800 (PST)
To: Christian Huitema , 'Lorenzo Colitti' , 'IETF Discussion' 
References: <20160201142413.30288.23248.idtracker@ietfa.amsl.com>  <003001d1687a$926ab2e0$b74018a0$@huitema.net>
From: Brian Haberman 
Message-ID: <56C3161F.3070301@innovationslab.net>
Date: Tue, 16 Feb 2016 07:29:19 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.5.1
MIME-Version: 1.0
In-Reply-To: <003001d1687a$926ab2e0$b74018a0$@huitema.net>
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="9Oqtq3oE4GsVB19rgH23Jr5M2BBDHnN9Q"
Archived-At: 
Cc: dhc-chairs@ietf.org, iesg@ietf.org, draft-ietf-dhc-anonymity-profile@ietf.org, dhcwg@ietf.org
Subject: Re: [dhcwg] Last Call:  (Anonymity profile for DHCP clients) to Proposed Standard
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 16 Feb 2016 12:29:33 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--9Oqtq3oE4GsVB19rgH23Jr5M2BBDHnN9Q
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable



On 2/16/16 12:26 AM, Christian Huitema wrote:
> On Monday, February 15, 2016 6:53 PM, Lorenzo Colitti wrote:
>>
>> It's true that this profile mitigates the amount of information that c=
an be collected.=20
>> But in IPv6 we have other configuration methods - such as SLAAC - that=
 broadcast=20
>> way less information than stateless DHCPv6, which in turn broadcasts l=
ess information=20
>> than stateless DHCPv6.
>>
>> This document should recognize that at least on IPv6-only networks, it=
 is an option=20
>> not to use DHCP at all, and that option has substantial privacy benefi=
ts that are in=20
>> many cases above what this profile can provide.
>=20
> Well, section 4 of draft-ietf-dhc-anonymity-profile-07 says:
>=20
>    The choice between the stateful and stateless scenarios depends on
>    flag and prefix options published by the "Router Advertisement"
>    messages of local routers, as specified in [RFC4861].  When these
>    options enable stateless address configuration hosts using the
>    anonymity profile SHOULD choose it over stateful address
>    configuration, because stateless configuration requires fewer=09
>    information disclosures than stateful configuration.
>=20
> That seems pretty close from what you want, at least as far as "statefu=
l DHCPv6" is concerned.

I would agree that the above text covers what I interpret as Lorenzo's
concern.

Regards,
Brian


--9Oqtq3oE4GsVB19rgH23Jr5M2BBDHnN9Q
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2

iQEcBAEBCAAGBQJWwxYfAAoJEBOZRqCi7goqjswH/iVYavnLAZD/Coj2CalvvOi4
Uu7J2Ak1sc5gNkj4NdI69RimRrhs3bkC9bTERvD9OCe4jJNYFkElrsAY1MNlEuGi
x0a5H350NBOIyRly1s9OlZggScZ6/EYTPj46CItSCQbpSx5SSaF8pdFA5uLcF/uT
/9IS3G0rLZ4unO2oziSvl0DJaNch7UeDW8MuPm5NxFY/Vr9TzIvQOaSe6OP40DDh
lSY+mtxmhZ6Bk691/Z/7yWEjSJsv+26Hg+Tpq/vo5W5jjJWGevpmRylfvLBMleau
bjZmN1U7Qk172j1R6n62M7UfKWwlxhXnBmK0fTCFFeH32jdjfcDGosUdmXDzpCM=
=kZOp
-----END PGP SIGNATURE-----

--9Oqtq3oE4GsVB19rgH23Jr5M2BBDHnN9Q--


From nobody Tue Feb 16 07:16:23 2016
Return-Path: 
X-Original-To: dhcwg@ietf.org
Delivered-To: dhcwg@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 26C391A88DA; Tue, 16 Feb 2016 07:16:21 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: 
X-Test-IDTracker: no
X-IETF-IDTracker: 6.14.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20160216151621.16630.14579.idtracker@ietfa.amsl.com>
Date: Tue, 16 Feb 2016 07:16:21 -0800
Archived-At: 
Cc: dhcwg@ietf.org
Subject: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-privacy-04.txt
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.15
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 16 Feb 2016 15:16:21 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Dynamic Host Configuration of the IETF.

        Title           : Privacy considerations for DHCPv6
        Authors         : Suresh Krishnan
                          Tomek Mrugalski
                          Sheng Jiang
	Filename        : draft-ietf-dhc-dhcpv6-privacy-04.txt
	Pages           : 17
	Date            : 2016-02-16

Abstract:
   DHCPv6 is a protocol that is used to provide addressing and
   configuration information to IPv6 hosts.  This document describes the
   privacy issues associated with the use of DHCPv6 by the Internet
   users.  It is intended to be an analysis of the present situation and
   does not propose any solutions.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6-privacy/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-privacy-04

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-dhc-dhcpv6-privacy-04


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From nobody Tue Feb 16 07:35:45 2016
Return-Path: 
X-Original-To: dhcwg@ietfa.amsl.com
Delivered-To: dhcwg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BA351B2DD8; Tue, 16 Feb 2016 07:35:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] 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 3ADfwGDwyN0z; Tue, 16 Feb 2016 07:35:39 -0800 (PST)
Received: from mail-lb0-x230.google.com (mail-lb0-x230.google.com [IPv6:2a00:1450:4010:c04::230]) (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 DC2BF1B2DD5; Tue, 16 Feb 2016 07:35:38 -0800 (PST)
Received: by mail-lb0-x230.google.com with SMTP id bc4so97578850lbc.2; Tue, 16 Feb 2016 07:35:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-type:content-transfer-encoding; bh=fg5AxvYldkKQjhuziSFclwdzU83eELYEumEXITcB1NE=; b=C+19AvaH5d8w8Cr8qfRmSv2uCZmB5oH4aySXo7jxpWqRbEDysHj9UG9FBWac15b/1a UkiM1YIxrejuYfJopS7gBwtzSUbuMc5NVVzo1hcVp3TvnCiqSWGquH0dz0BzKM4mooKB XRivpnVvTD1zI7KQdRD/DZiMF130nDY9vIoF5v770nU8kePK1h01WTosSR6dsX1Xb/KQ BPXCvi8y59Cd7vI6y2UGRIvGHThUbBCnPAAx0CSswf8RJDnw1UIUcnmu4kOafTsJpDJ2 n6mkZcuM7v9ku+irYnFRM10kNyEhYmAmn44ANKW3bR4A8H3g90tW8npxCy6PE5A6/09R 3qSQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=fg5AxvYldkKQjhuziSFclwdzU83eELYEumEXITcB1NE=; b=jwwKPbWl7851wTRq4MDy2RpEJVAclbEpoofKqpOS7mPE4mBwmSth++ORgOZWCHOzzf 4fT3mbKzx16krlSYFYmwt4tH1il9Si5oF9VE1/GOHkjShXXRHBBYmNaFj0zxQKPXXyav K7ST9C6T7p8BWpBwVn5oCDAZNQkme5cqcTZlUPxE8RjVwr5mSQDsn8rcX5B/b7Wvul+P q5tNfpv8ZcMm4dYF2bwQWTZLlprAHOVPqFhqmzzKJOFuMdxUV/sRL8N8mBMq4ac+H2Hk 1JFbqoQOM9XWlEjdwxwAkNBG7safJLg9MKMCsYzTXWLbeeo7C2YlwOPcZdikdePzl3vX mqDA==
X-Gm-Message-State: AG10YOQlDpnyqDO3DuBio43xTBtK7QnX4KTlYbknWHlzaK/vsGAMAOvjYnJOLj9Y/ZbxkQ==
X-Received: by 10.112.138.166 with SMTP id qr6mr10192138lbb.106.1455636937112;  Tue, 16 Feb 2016 07:35:37 -0800 (PST)
Received: from [10.0.0.100] (109107011157.gdansk.vectranet.pl. [109.107.11.157]) by smtp.googlemail.com with ESMTPSA id ei4sm4408482lbb.18.2016.02.16.07.35.34 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 16 Feb 2016 07:35:35 -0800 (PST)
To: Robert Sparks , "Bernie Volz (volz)" , General Area Review Team , "ietf@ietf.org" , "dhcwg@ietf.org" , "draft-ietf-dhc-dhcpv6-privacy.all@ietf.org" 
References: <56B0DBA3.2050406@nostrum.com> <56C238F8.4040400@gmail.com> <56C23FE6.5000207@nostrum.com> <3990c04ce860428ab90d0142102b7bfc@XCH-ALN-003.cisco.com> <56C24CCB.9060802@nostrum.com>
From: Tomek Mrugalski 
X-Enigmail-Draft-Status: N1110
Message-ID: <56C341C5.3080905@gmail.com>
Date: Tue, 16 Feb 2016 16:35:33 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1
MIME-Version: 1.0
In-Reply-To: <56C24CCB.9060802@nostrum.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Archived-At: 
Subject: Re: [dhcwg] Gen-ART LC review: draft-ietf-dhc-dhcpv6-privacy-03
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 16 Feb 2016 15:35:41 -0000

On 15.02.2016 23:10, Robert Sparks wrote:
> On 2/15/16 3:37 PM, Bernie Volz (volz) wrote:
>> Perhaps we should get away from whether something is easy or difficult
>> to implement or whether the algorithm may be more (or less) efficient.
>>
>> I think the point of this material is to ENCOURAGE random assignment
>> rather than sequential to improve privacy- so keep it at that. Let
>> implementers worry about how efficient an algorithm is?
> Right - that's where I'm trying to get the document to go.

This document doesn't encourage anything. It's an analysis and that is
clearly stated in the abstract. Anyway, it seems that people prefer the
performance text to disappear, so it's now gone.

In fact, this topic may be a material for another draft altogether.
Those two drafts (dhcp-privacy and dhcpv6-privacy) analysed the
situation mostly from the client perspective and dhc-anonymity-profile
attempts to address the issues raised on the client side. The whole
paragraph about allocation strategy is just an attempt to cover aspects
that, while implemented on the server side, still affect the client. I
suppose we could consider a draft that would provide similar
recommendations for privacy conscious DHCP server. It's not immediately
clear whether there's enough topics for a separate draft, but this
remains to be seen.

Anyway, I just uploaded -04 that hopefully is acceptable. It does not
contain the performance discussion. The direct link is:
https://www.ietf.org/id/draft-ietf-dhc-dhcpv6-privacy-04.txt

Tomek


From nobody Tue Feb 16 07:45:39 2016
Return-Path: 
X-Original-To: dhcwg@ietfa.amsl.com
Delivered-To: dhcwg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D42CE1B2CE4; Tue, 16 Feb 2016 07:45:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] 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 K_polb543-z4; Tue, 16 Feb 2016 07:45:36 -0800 (PST)
Received: from mail-lb0-x229.google.com (mail-lb0-x229.google.com [IPv6:2a00:1450:4010:c04::229]) (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 2886E1B2C82; Tue, 16 Feb 2016 07:45:36 -0800 (PST)
Received: by mail-lb0-x229.google.com with SMTP id of3so5963594lbc.1; Tue, 16 Feb 2016 07:45:36 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=GGRethT6iCEw0Gil2NgT0idzJOkLS6zLU5fKSjR8r6Q=; b=aej4LWMeu15RQP849O5405uJtiw04nTYfeVtyAQOjczve8JzYFetcEOxXvkvrcvbYP uQK3M34JBJV3HYpQ9tp8kSBu9Wk+Djs0aBbJuEMY0sApJBADZYSRkjgrvyU46itIWrFW +IQ7McE8xmqG1dEQo1WHL1jQoX0RMbDm4hkTZXFjL/UhU9cMTvu7t2odl8zGPOhQVst6 UZC/Ny6bxD+IFLMldMsm3tvXAxmo/rF5rMgwZDW/IXXQkEfuBObVRKTlEk45K1qH68U1 BWRxdr9SsxvzRaxT/AmTdbyEGmNiTsSouYeMRotaOjnyYfDwR2NNAPd0AImBTX5AwkcE 9KvQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=GGRethT6iCEw0Gil2NgT0idzJOkLS6zLU5fKSjR8r6Q=; b=RpFHLGphJxvcgGwdL+CntzWneN0u5uKxgx3I8poqoGUn7t+HBn3bbUk8wzgX7NEQZa zVpp/xPp6JerGAPJwSq8r4oNUhC1O8RRPySSmAnd5tChVMb+m8pkRLc/N3o2eLGGvvJn IyRpLSID+qAh4fkSFVrPXYe1uLUcrGpU9c21e7QuT1CmNrqfhGt7riCR3PApU8JG4eKJ C/m8CU7WMjP/yAqHw4LyfjQHU7I1AODjPLyonAOneaDMIG6IbeP1+VYmGwjbgBR5Nzb0 r387u8gJWnFAyFOPwOYqIQhI7Fv4rfRZ6FmUP2bl7QMTIo3+g/zx+9Y1QAYAVP7pFM1t Wn6g==
X-Gm-Message-State: AG10YORt8xZ5LuqWjkyqF4KK0fUEhR5SXXpoHp0jxeM+GisM1ZgSDJ1urR4ggzpvEPM8Wg==
X-Received: by 10.112.129.233 with SMTP id nz9mr10103592lbb.82.1455637534411;  Tue, 16 Feb 2016 07:45:34 -0800 (PST)
Received: from [10.0.0.100] (109107011157.gdansk.vectranet.pl. [109.107.11.157]) by smtp.googlemail.com with ESMTPSA id b10sm4276933lbs.37.2016.02.16.07.45.32 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 16 Feb 2016 07:45:33 -0800 (PST)
To: Stephen Farrell , The IESG 
References: <20160215184613.18852.55323.idtracker@ietfa.amsl.com>
From: Tomek Mrugalski 
X-Enigmail-Draft-Status: N1110
Message-ID: <56C3441B.1080102@gmail.com>
Date: Tue, 16 Feb 2016 16:45:31 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1
MIME-Version: 1.0
In-Reply-To: <20160215184613.18852.55323.idtracker@ietfa.amsl.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Archived-At: 
Cc: dhc-chairs@ietf.org, draft-ietf-dhc-dhcpv6-privacy@ietf.org, dhcwg@ietf.org
Subject: Re: [dhcwg] Stephen Farrell's Yes on draft-ietf-dhc-dhcpv6-privacy-03: (with COMMENT)
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 16 Feb 2016 15:45:38 -0000

On 15.02.2016 19:46, Stephen Farrell wrote:
> Stephen Farrell has entered the following ballot position for
> draft-ietf-dhc-dhcpv6-privacy-03: Yes
> 
> - DHCPv6: is there really nothing to say about link local
> addresses? (I'm not sure how those are used in DHCPv6, if
> they are, but they do often contain MACs.)
I have just uploaded -04 with a new section 3.1 that is dedicated to the
link local addresses. Technically they're not part of the DHCPv6
protocol, but most of the DHCPv6 traffic is sent from a link local
address. Also, the original source address of a packet is stored in the
Relay-forward message if the traffic is relayed.

Please let me know if the text is sufficient or further clarifications
or corrections are needed.

Thanks for reviewing this draft and your yes vote :)

Tomek


From nobody Tue Feb 16 08:36:48 2016
Return-Path: 
X-Original-To: dhcwg@ietfa.amsl.com
Delivered-To: dhcwg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA9B21A0334; Tue, 16 Feb 2016 08:36:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.307
X-Spam-Level: 
X-Spam-Status: No, score=-4.307 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] 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 y3fcIRM325x9; Tue, 16 Feb 2016 08:36:42 -0800 (PST)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A63A1A0146; Tue, 16 Feb 2016 08:36:42 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id EC14FBE32; Tue, 16 Feb 2016 16:36:39 +0000 (GMT)
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YU32w4Y7m_X4; Tue, 16 Feb 2016 16:36:38 +0000 (GMT)
Received: from [172.16.22.120] (unknown [216.127.117.40]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 34862BE33; Tue, 16 Feb 2016 16:36:37 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1455640598; bh=+WegsA8OFNExzglBSahfbrz5qQaYAbkSZIWUo2cbvkg=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=3IEhqO1jzBuJAg7XA6X2kqPhoWxR3JqY7XLZ58xoC5HTFVN1qsqu6VRCcblmflz2N cDAS2qgqxZUBggQ3rpC1nIvkBoqY2CveyHsNvMdXK88aVdKESBLzUKVyWkubKioYam SHsd5Fcme6PCsJvFTW1vBKQmTMdT2ZN66ayeZwmg=
To: Tomek Mrugalski , The IESG 
References: <20160215184613.18852.55323.idtracker@ietfa.amsl.com> <56C3441B.1080102@gmail.com>
From: Stephen Farrell 
Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Message-ID: <56C35010.1080805@cs.tcd.ie>
Date: Tue, 16 Feb 2016 16:36:32 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1
MIME-Version: 1.0
In-Reply-To: <56C3441B.1080102@gmail.com>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms050106080403040107070801"
Archived-At: 
Cc: dhc-chairs@ietf.org, draft-ietf-dhc-dhcpv6-privacy@ietf.org, dhcwg@ietf.org
Subject: Re: [dhcwg] Stephen Farrell's Yes on draft-ietf-dhc-dhcpv6-privacy-03: (with COMMENT)
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 16 Feb 2016 16:36:45 -0000

This is a cryptographically signed message in MIME format.

--------------ms050106080403040107070801
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


Hiya,

On 16/02/16 15:45, Tomek Mrugalski wrote:
> On 15.02.2016 19:46, Stephen Farrell wrote:
>> Stephen Farrell has entered the following ballot position for
>> draft-ietf-dhc-dhcpv6-privacy-03: Yes
>>
>> - DHCPv6: is there really nothing to say about link local
>> addresses? (I'm not sure how those are used in DHCPv6, if
>> they are, but they do often contain MACs.)
> I have just uploaded -04 with a new section 3.1 that is dedicated to th=
e
> link local addresses. Technically they're not part of the DHCPv6
> protocol, but most of the DHCPv6 traffic is sent from a link local
> address. Also, the original source address of a packet is stored in the=

> Relay-forward message if the traffic is relayed.
>=20
> Please let me know if the text is sufficient or further clarifications
> or corrections are needed.

Looks good to me, thanks,
S.

>=20
> Thanks for reviewing this draft and your yes vote :)
>=20
> Tomek
>=20


--------------ms050106080403040107070801
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC
CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ
BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD
ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll
bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw
aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA
Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra
C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3
rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5
R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r
dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt
3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw
MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ
QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv
BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5
BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu
Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll
bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc
MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE
MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG
9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD
C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9
U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM
aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai
9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC
BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE
BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs
IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g
QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC
SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj
YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC
ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv
mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm
VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4
D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI
dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu
N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE
FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp
MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE
WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG
JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+
SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g
BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv
bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY
0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF
NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9
uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p
6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv
Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu
mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7
RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO
/ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN
JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM
MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG
A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0
Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA
oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjAyMTYx
NjM2MzJaMC8GCSqGSIb3DQEJBDEiBCAvAj08skZTHRwrylhDZ00OtdXWCKwSGmO+XTLAJHts
eTBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN
AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC
AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0
Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw
IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB
nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t
IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD
VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq
hkiG9w0BAQEFAASCAQB+n/4cIEKzO+VCGz8hss/HR+WssJl5uIssX5uvEY42jmqjy1jtP2aW
EAv4rTsipshnmf5JtbsW22c7A/jYhUeeUKM0oC8/npZRz69pwfXa5YealMze1LJhzva9IZSr
D5Ye/b3dmY3JdLJjOwpVQXn+2ygwsdb6lwSUo3BH3rBv/FL6N0NbFHuVYwLkLX8GttTjhWPj
MXDSAhsshdBGUEwgUxDjJpOT8pEvunVnlW9T6EGtTSxQYMvFN2LsRWEGLhlQ815qieNfI8nE
tluvcnn7TsvsDAm5wHBkgbqm7ale2otOJuuMfltRx9B+qtJE78VtnpoQ0rz30veFPpJ1bsJx
AAAAAAAA
--------------ms050106080403040107070801--


From nobody Tue Feb 16 08:41:56 2016
Return-Path: 
X-Original-To: dhcwg@ietfa.amsl.com
Delivered-To: dhcwg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 309621A899E; Tue, 16 Feb 2016 08:41:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.507
X-Spam-Level: 
X-Spam-Status: No, score=-14.507 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 D3m5G3rGZJoX; Tue, 16 Feb 2016 08:41:51 -0800 (PST)
Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE7571A1EF1; Tue, 16 Feb 2016 08:41:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1800; q=dns/txt; s=iport; t=1455640904; x=1456850504; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=xIWzVcesE1x7o28INsGd7bN+pXhZCY62vT6IeZnK/+c=; b=HQt8MvsMBH8x1MQqST8Mg4EKOI3yxR08E29IfR0wY/OlV2mDwl2DioJs twUeGc6SrimWEQw/lNAcyYFnkjyatxEErayfimc4off4Cw/yL8UuVkSHA KJs6IAkfVeEtfKNSGlggecCeoqrpdJmU3cYR1p2Qq5n3jfu+VdE0FXBix M=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D1AQC1UMNW/40NJK1dgzpSbQa6KAENg?= =?us-ascii?q?WchhWwCgTs4FAEBAQEBAQGBCoRBAQEBBDpLBAIBCA4DBAEBAR4JByERFAkIAgQ?= =?us-ascii?q?BEgiHfQMSDrV5DYRXAQEBAQEBAQEBAQEBAQEBAQEBAQEBEQSJS3uCN4Y1BZZ/A?= =?us-ascii?q?YVShhOBbI56hn+HQAEeAQFCggIZgUhqh2B8AQEB?=
X-IronPort-AV: E=Sophos;i="5.22,456,1449532800"; d="scan'208";a="239040847"
Received: from alln-core-8.cisco.com ([173.36.13.141]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 16 Feb 2016 16:41:43 +0000
Received: from XCH-ALN-005.cisco.com (xch-aln-005.cisco.com [173.36.7.15]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id u1GGfheL015065 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 16 Feb 2016 16:41:43 GMT
Received: from xch-aln-003.cisco.com (173.36.7.13) by XCH-ALN-005.cisco.com (173.36.7.15) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 16 Feb 2016 10:41:42 -0600
Received: from xch-aln-003.cisco.com ([173.36.7.13]) by XCH-ALN-003.cisco.com ([173.36.7.13]) with mapi id 15.00.1104.009; Tue, 16 Feb 2016 10:41:42 -0600
From: "Bernie Volz (volz)" 
To: Fernando Gont , Robert Sparks , Tomek Mrugalski , "General Area Review Team" , "ietf@ietf.org" , "dhcwg@ietf.org" , "draft-ietf-dhc-dhcpv6-privacy.all@ietf.org" 
Thread-Topic: [Gen-art] Gen-ART LC review: draft-ietf-dhc-dhcpv6-privacy-03
Thread-Index: AQHRaDHdLqFZqGv4dUC+QRkipz148J8uACIA//+gK0CAAS+tAIAAEB1g
Date: Tue, 16 Feb 2016 16:41:42 +0000
Message-ID: <15aafca59a4e494ca0d02bc5b04128ab@XCH-ALN-003.cisco.com>
References: <56B0DBA3.2050406@nostrum.com> <56C238F8.4040400@gmail.com> <56C23FE6.5000207@nostrum.com> <3990c04ce860428ab90d0142102b7bfc@XCH-ALN-003.cisco.com> <56C2EE40.1060701@si6networks.com>
In-Reply-To: <56C2EE40.1060701@si6networks.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.131.78.78]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: 
Subject: Re: [dhcwg] [Gen-art] Gen-ART LC review: draft-ietf-dhc-dhcpv6-privacy-03
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 16 Feb 2016 16:41:53 -0000

Technically unpredictable is probably a better term, but random implies tha=
t. I'll leave it to the authors to determine the best language. (I'm ok wit=
h what the 04 draft now says.)

- Bernie

-----Original Message-----
From: Fernando Gont [mailto:fgont@si6networks.com]=20
Sent: Tuesday, February 16, 2016 4:39 AM
To: Bernie Volz (volz) ; Robert Sparks ; Tomek Mrugalski ; General Area Review Team =
; ietf@ietf.org; dhcwg@ietf.org; draft-ietf-dhc-dhcpv6-pr=
ivacy.all@ietf.org
Subject: Re: [Gen-art] Gen-ART LC review: draft-ietf-dhc-dhcpv6-privacy-03

Bernie,

On 02/15/2016 06:37 PM, Bernie Volz (volz) wrote:
> Perhaps we should get away from whether something is easy or difficult=20
> to implement or whether the algorithm may be more (or less) efficient.
>=20
> I think the point of this material is to ENCOURAGE random assignment=20
> rather than sequential to improve privacy- so keep it at that. Let=20
> implementers worry about how efficient an algorithm is?

There are a number of operational and security/privacy considerations that =
depend on the actual algorithm that you employ.

I'm not sure what you mean by "random". IID=3Drandom() everytime an address=
 has to be leased? -- or do you really mean "unpredictable"?.

At the end of the day, what you want is to specify desired properties.

Besides, assignment of sequential addresses should be banned. They have alw=
ays been a bad idea (see
) and they=
 shouldn't even be considered an option.

Thanks,
--
Fernando Gont
SI6 Networks
e-mail: fgont@si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492





From nobody Tue Feb 16 10:14:00 2016
Return-Path: 
X-Original-To: dhcwg@ietfa.amsl.com
Delivered-To: dhcwg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3526B1B3099 for ; Tue, 16 Feb 2016 10:13:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.6
X-Spam-Level: 
X-Spam-Status: No, score=-1.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=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 D_COKGARzZPK for ; Tue, 16 Feb 2016 10:13:58 -0800 (PST)
Received: from xsmtp12.mail2web.com (xsmtp32.mail2web.com [168.144.250.235]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E1211B31DB for ; Tue, 16 Feb 2016 10:13:57 -0800 (PST)
Received: from internal.xmail06.myhosting.com ([10.5.2.16] helo=xmail06.myhosting.com) by xsmtp12.mail2web.com with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1aVk8F-0006KE-M5 for dhcwg@ietf.org; Tue, 16 Feb 2016 13:13:55 -0500
Received: (qmail 1268 invoked from network); 16 Feb 2016 18:13:50 -0000
Received: from unknown (HELO huitema2) (Authenticated-user:_huitema@huitema.net@[131.107.174.247]) (envelope-sender ) by xmail06.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 16 Feb 2016 18:13:49 -0000
From: "Christian Huitema" 
To: =?UTF-8?B?J+elnuaYjumBlOWTiSc=?= , 
References: <20160201142413.30288.23248.idtracker@ietfa.amsl.com> 
In-Reply-To: 
Date: Tue, 16 Feb 2016 10:13:49 -0800
Message-ID: <163001d168e5$c9a63ed0$5cf2bc70$@huitema.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 15.0
Thread-Index: AQJtbhbfm6E5go4z/5mQ+0EwmlPxoQG1MG4fnelFLRA=
Content-Language: en-us
Archived-At: 
Cc: dhc-chairs@ietf.org, 'IETF-Announce' , draft-ietf-dhc-anonymity-profile@ietf.org, dhcwg@ietf.org
Subject: Re: [dhcwg] Last Call:  (Anonymity profile for DHCP clients) to Proposed Standard
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 16 Feb 2016 18:13:59 -0000

On Friday, February 12, 2016 11:26 AM, JINMEI, Tatuya wrote:
> Brian Carpenter called for an attention to Section 4.5.2 of the draft:
> https://mailarchive.ietf.org/arch/msg/ipv6/J_SnGxd2JunlpOeL4JprV03UA7s
>=20
> so I'm responding to it.
>=20
> 4.5.2.  Prefix delegation
>=20
>    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.
>=20
> 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?

This section was rewritten in draft-07, following the feedback received =
during IETF last call. Basically, we stopped being lazy and actually did =
the study. And took a lot of the text that Lorenzo provided.

-- Christian Huitema





From nobody Tue Feb 16 10:23:40 2016
Return-Path: 
X-Original-To: dhcwg@ietfa.amsl.com
Delivered-To: dhcwg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E33D51B32A1 for ; Tue, 16 Feb 2016 10:23:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.871
X-Spam-Level: 
X-Spam-Status: No, score=-0.871 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, LOCALPART_IN_SUBJECT=1.107, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=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 DZqNjIDuduty for ; Tue, 16 Feb 2016 10:23:36 -0800 (PST)
Received: from mail-lb0-f179.google.com (mail-lb0-f179.google.com [209.85.217.179]) (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 E34D11B31F8 for ; Tue, 16 Feb 2016 10:23:35 -0800 (PST)
Received: by mail-lb0-f179.google.com with SMTP id of3so10704620lbc.1 for ; Tue, 16 Feb 2016 10:23:35 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to:content-type; bh=vfmCfUMGtacQofakS/Qvl9KGKptFstK5t/hwFbgfTmY=; b=S+H9mz7AkF7RFputV2V2Pl1jIqNL3eW8Z+6DwUsZxOvyIX35QGb8zAYs5EnCAnmDYW aFt+6lltHDYkCSwxBPLRWoRa2x6OKHLx4hkdNLZWhJQg/FA50Hrp+JNuGLVpM8bBLwSG J/ZbI6+q/0xbIoBlkt65GH9kXfmAh+SZSrf4ZCHTnvQfWBI50ILAQDr4KKf6KtMbXVAr lGb5jXsqEkBmnvRxcOQuOV1/pHZVUajtzTtZeg8u+2wGxF1c4o2Dy7X4haFh4fGXDHIe vhRKdGHJNUoso7IHlvx3lYDS3FKAxVbupzjDYGEOGO1G9JgeKLYM5ZHFEmlUtA24FOfn eCQQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-type; bh=vfmCfUMGtacQofakS/Qvl9KGKptFstK5t/hwFbgfTmY=; b=hpih7WN2IEc2T9ilmNt3Q8OD+nvFtXKRh0noKbzeETfrAflDlxoEjQDKrnbrjL77hW bZa1BGahoojJWFQOWdFTfSd9F61U5eUAHpQ3RRHrQddxI+oAHCINZDizUwW5rHeWmkIb QhC3EXV/HsGl8Y+5wIgLh7DT/JObLqkqgC9y4wdYdwVI0Xcfl/gRHzQDq/FexYVC40xP plyVPeeZghGUzxNW1euXa8yEN2omfq4CgEdZOfUjcA0DvhPTUe6shmcNdXSY3+ykRVJc rTGLctFY9To8G8fyPAS+ivG3/luplDhra2ljWmsBuRdciRz+eU/WY+SpHDSzuy7FG/3P adOg==
X-Gm-Message-State: AG10YORYkxE/R9D+Zlft+l6kd+v4v7AlYAs2/Gct2rUxy/PBhDYvVcDeryV/L74RLOn7D2scd64yiVEEsZki4Q==
X-Received: by 10.25.87.149 with SMTP id l143mr10274333lfb.145.1455647013663;  Tue, 16 Feb 2016 10:23:33 -0800 (PST)
MIME-Version: 1.0
Received: by 10.25.29.149 with HTTP; Tue, 16 Feb 2016 10:22:54 -0800 (PST)
X-Originating-IP: [71.233.41.235]
From: Ted Lemon 
Date: Tue, 16 Feb 2016 13:22:54 -0500
Message-ID: 
To: draft-ypal-sfc-dhcp-option-for-nsh-for-sfp@ietf.org, dhcwg@ietfa.amsl.com
Content-Type: multipart/alternative; boundary=001a1141ad222b08fa052be73b03
Archived-At: 
Subject: [dhcwg] draft-ypal-sfc-dhcp-option-for-nsh-for-sfp
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 16 Feb 2016 18:23:40 -0000

--001a1141ad222b08fa052be73b03
Content-Type: text/plain; charset=UTF-8

>
>    The NSH SFP option can be used by the client and server during the
>    initial four message exchanges (DHCPDISCOVER, DHCPOFFER, DHCPREQUEST,
>    and DHCPACK) or during two message exchange (DHCPINFORM and DHCPACK)
>    to configure the SFP details to SFF DHCP clients (i.e SFF will
>    receive SFP details along with other DHCP configuration parameters).


When would a client ever use the SFP option?   I think what you mean here
is something more like this:

The NSH SFP option can be used by DHCP servers to communicate SFP
information to  DHCP clients, either in a stateful DHCP address
configuration or renewal transaction, or in a stateless information request
(DHCPINFORM).

I would really suggest that you take out as much descriptive language about
how DHCP works as possible, because it's not clear to me that the model you
are using for DHCP behavior is correct, and I think readers will find it
confusing, and may feel that they need to make inappropriate changes to
their client or server implementations to support this option.   In
particular, it's entirely possible that an SFP option might be added to the
server's configuration and that clients might receive it during a stateful
IP address renewal.   This is perfectly reasonable and should not be
excluded, but the above language does exclude it.

A client configured from beginning to act as SFF MUST include the
> OPTION_NSH_SFP option in both DHCPDISCOVER and DHCPREQUEST to inform
> the server about the options client is interested in. Whereas, if the
> client is configured latter to act as SFF after initial exchanges, it
> MUST include OPTION_NSH_SFP option in the DHCPINFORM message to inform
> the server.


This isn't how DHCP works.   Clients need only mention the option code for
the option in the parameter request list.   There is no need to send the
option as well, and the server would need to be specially modified to
handle that behavior.   You mention this in the previous paragraph.   Also,
the client can either do a DHCPINFORM or simply renew its lease to request
the new information.   Which is done should be left up to the
implementation, so I would reword this paragraph as follows:

DHCP clients that support the SFF option must handle the case where SFF
functionality is configured after the client has been started.   This can
be handled by the client either by renewing its lease when SFF
functionality is configured, or by sending a DHCPINFORM message.   The
details of how this is implemented are implementation-dependent.

The above suggestion also applies to section 5.3.1.

   A DHCPv4 server if configured to handle service chaining, SHOULD
>    provision the SFF clients with SFP, as per its administrative policy.
>    A server can receive requests for OPTION_NSH_SFP option from clients
>    in different message (DHCPDISCOVER and DHCPREQUEST) exchanges.


This is how DHCP works, and there is no need to repeat it here.  It's also
incomplete, and I don't think you should try to make it complete.   Please
just rely on the base protocol specification to say how this works.

   DHCPv4 server SHOULD inform the client with the option OPTION_NSH_SFP
>    and SFP information in both DHCPOFFER and DHCPACK messages as a response
>    to the DHCP client's DHCPDISCOVER and DHCPREQUEST respectively. If the
>    DHCPv4 server receives the option OPTION_NSH_SFP during DHCPINFORM
>    exchange, it SHOULD process and respond back as per administrative
>    policy (server MAY choose to act as per the host requirement document).
>    NSH SFP option sent to client is detailed in section 4.1.1


Again, you are incorrectly specifying what is already specified in the base
protocol spec.   Please just delete this text.

    DHCPv4 server SHOULD inform the client with the option OPTION_NSH_SFP
>    and SFP information in both DHCPOFFER and DHCPACK messages as a response
>    to the DHCP client's DHCPDISCOVER and DHCPREQUEST respectively. If the
>    DHCPv4 server receives the option OPTION_NSH_SFP during DHCPINFORM
>    exchange, it SHOULD process and respond back as per administrative
>    policy (server MAY choose to act as per the host requirement document).
>    NSH SFP option sent to client is detailed in section 4.1.1


Same issue.   Please delete.

   Whenever server detects any change is required in the SFP path, it
>    will inform the clients using Reconfigure Message.


DHCP servers don't detect that changes are required in the SFP path.   They
are reconfigured with new information.   What they do then is up to the
agent that is doing the reconfiguring, not up to the DHCP server.   I would
suggest that you put it this way instead:

When a DHCP server has been configured with different SFP parameters, the
administrator or agent that updated the configuration should trigger
Reconfigure messages for any clients that now have stale configurations.
How such clients are identified is implementation-dependent.   Such
reconfiguration may not be possible in practice.

You should also require (or at least recommend) that clients that use the
SFP option support reconfigure, since reconfigure support in clients is not
guaranteed.   That said, if you are depending on this DHCP option as a way
to get clients to switch away from no-longer-valid paths, you are probably
asking too much of DHCP.

   A server receiving the option OPTION_NSH_SFP in Solicit, Request, Renew,
>    Rebind, Confirm or Information-request will process this request and
>    SHOULD respond back to exchange with NSH SFP option as detailed in

   section 4.2.1


I think this is incorrect, and should be reworded as follows:

Clients do not send OPTION_NSH_SFP to servers; therefore, servers that
receive this option should take no special action as a result of having
received it.

>
> 5.5. Geolocation Based SFP
>    In certain cloud deployment scenarios, operator will like to know the
>    details of SFF location to provide information to local authority
> towards
>    integrity of resources and data moving across the SFF. In such
> scenarios,
>    SFF sends option OPTION_NSH_SFP along with geolocation option to DHCP
>    server.
>    In order to achieve this, the DHCP SFF clients SHOULD include the
>    GeoConf option as per RFC6225 and OPTION_GEOCONF_CIVIC option as per
>    RFC4776 for DHCPv4 and DHCPv6 respectively, along with the
> OPTION_NSH_SFP
>    option in DHCPDISCOVER, DHCPREQUEST, DHCPINFORM requests of DHCPv4 and
>    in Solicit, Request, Renew, Rebind, Confirm or Information-request in
>    DHCPv6 exchanges.


The privacy implications of this section are breathtaking.   This text
should not survive IESG review.   I recommend you take it out now and avoid
the fight.

>
>     To minimize the unintended exposure of SFP, the OPTION_NSH_SFP
>    option SHOULD be returned by DHCP servers only when the DHCP client
>    has included this option in its request (Section 3.5 of [RFC2131],
>    Section 9.8 of [RFC2132]).


Again, confusion about ORO/PRL versus sending the actual option.   Please
change "has included this option" to "has requested this option".   Also,
obviously you should not reference section 3.5 of RFC 2131--section 9.8 of
RFC 2132 is the only applicable reference.

   Where critical decisions might be based on the value of this option,
>    DHCP authentication as defined in "Authentication for DHCP Messages"
>    [RFC3118] and "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)"
>    [RFC3315] SHOULD be used to protect the integrity of the DHCP

options.


Neither of these choices is actually available to implementations.   RFC
3118 didn't catch on, and the mechanism defined in 3315 didn't either, and
is effectively deprecated.   If your document needs to rely on integrity
protection for DHCP4, you are out of luck.   For DHCPv6, there is work in
progress that you could reference, but there is no existing standard to
reference.

   Link-layer confidentiality and integrity protection may also be
>    employed to reduce the risk of location disclosure and tampering.


I would reword this as follows:

Networks where this option is used SHOULD use link-layer security and
integrity protection.    Additionally, such networks should filter out
rogue DHCP messages (RFC 7610).

Your IANA considerations section is inadequate.   Take a look at:
https://tools.ietf.org/html/rfc5226

Sorry for all the criticism, but the goal is to help you succeed.   :}

--001a1141ad222b08fa052be73b03
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


=C2=A0 =C2=A0The NSH SFP option can be us=
ed by the client and server during the
=C2=A0 =C2=A0initial four message=
 exchanges (DHCPDISCOVER, DHCPOFFER, DHCPREQUEST,
=C2=A0 =C2=A0and DHCPA=
CK) or during two message exchange (DHCPINFORM and DHCPACK)
=C2=A0 =C2=
=A0to configure the SFP details to SFF DHCP clients (i.e SFF will
=C2=A0=
 =C2=A0receive SFP details along with other DHCP configuration parameters).=


When would a client ever use the SFP optio=
n? =C2=A0 I think what you mean here is something more like this:

The NSH SFP option can be used by DHCP servers to communica=
te SFP information to =C2=A0DHCP clients, either in a stateful DHCP address=
 configuration or renewal transaction, or in a stateless information reques=
t (DHCPINFORM).

I would really suggest that you ta=
ke out as much descriptive language about how DHCP works as possible, becau=
se it's not clear to me that the model you are using for DHCP behavior =
is correct, and I think readers will find it confusing, and may feel that t=
hey need to make inappropriate changes to their client or server implementa=
tions to support this option. =C2=A0 In particular, it's entirely possi=
ble that an SFP option might be added to the server's configuration and=
 that clients might receive it during a stateful IP address renewal. =C2=A0=
 This is perfectly reasonable and should not be excluded, but the above lan=
guage does exclude it.

   A clien=
t configured from beginning to act as SFF MUST include the
   OPTION_NSH=
_SFP option in both DHCPDISCOVER and DHCPREQUEST to inform
   the server=
 about the options client is interested in. Whereas, if the
   client is=
 configured latter to act as SFF after initial exchanges, it
   MUST inc=
lude OPTION_NSH_SFP option in the DHCPINFORM message to inform
   the se=
rver.

This isn't how DHCP works. =C2=A0=
 Clients need only mention the option code for the option in the parameter =
request list. =C2=A0 There is no need to send the option as well, and the s=
erver would need to be specially modified to handle that behavior. =C2=A0 Y=
ou mention this in the previous paragraph. =C2=A0 Also, the client can eith=
er do a DHCPINFORM or simply renew its lease to request the new information=
. =C2=A0 Which is done should be left up to the implementation, so I would =
reword this paragraph as follows:

DHCP clien=
ts that support the SFF option must handle the case where SFF functionality=
 is configured after the client has been started. =C2=A0 This can be handle=
d by the client either by renewing its lease when SFF functionality is conf=
igured, or by sending a DHCPINFORM message. =C2=A0 The details of how this =
is implemented are implementation-dependent.

The a=
bove suggestion also applies to section 5.3.1.

=C2=A0 =C2=A0A DHCPv4 server if configured to handle service chain=
ing, SHOULD
=C2=A0 =C2=A0provision the SFF clients with SFP, as per its =
administrative policy.
=C2=A0 =C2=A0A server can receive requests for OP=
TION_NSH_SFP option from clients
=C2=A0 =C2=A0in different message (DHCP=
DISCOVER and DHCPREQUEST) exchanges.

This i=
s how DHCP works, and there is no need to repeat it here.=C2=A0 It's al=
so incomplete, and I don't think you should try to make it complete. =
=C2=A0 Please just rely on the base protocol specification to say how this =
works.

=C2=A0 =C2=A0DHCPv4 server=
 SHOULD inform the client with the option OPTION_NSH_SFP
=C2=A0 =C2=A0an=
d SFP information in both DHCPOFFER and DHCPACK messages as a response
=
=C2=A0 =C2=A0to the DHCP client's DHCPDISCOVER and DHCPREQUEST respecti=
vely. If the
=C2=A0 =C2=A0DHCPv4 server receives the option OPTION_NSH_S=
FP during DHCPINFORM
=C2=A0 =C2=A0exchange, it SHOULD process and respon=
d back as per administrative
=C2=A0 =C2=A0policy (server MAY choose to a=
ct as per the host requirement document).
=C2=A0 =C2=A0NSH SFP option se=
nt to client is detailed in section 4.1.1

A=
gain, you are incorrectly specifying what is already specified in the base =
protocol spec. =C2=A0 Please just delete this text.

=C2=A0 =C2=A0 DHCPv4 server SHOULD inform the client with the=
 option OPTION_NSH_SFP
=C2=A0 =C2=A0and SFP information in both DHCPOFFE=
R and DHCPACK messages as a response
=C2=A0 =C2=A0to the DHCP client'=
;s DHCPDISCOVER and DHCPREQUEST respectively. If the
=C2=A0 =C2=A0DHCPv4=
 server receives the option OPTION_NSH_SFP during DHCPINFORM
=C2=A0 =C2=
=A0exchange, it SHOULD process and respond back as per administrative
=
=C2=A0 =C2=A0policy (server MAY choose to act as per the host requirement d=
ocument).
=C2=A0 =C2=A0NSH SFP option sent to client is detailed in sect=
ion 4.1.1

Same issue. =C2=A0 Please delete.=


=C2=A0 =C2=A0Whenever server detects =
any change is required in the SFP path, it
=C2=A0 =C2=A0will inform the =
clients using Reconfigure Message.
=C2=A0
=
DHCP servers don't detect that changes are required in the SFP path. =
=C2=A0 They are reconfigured with new information. =C2=A0 What they do then=
 is up to the agent that is doing the reconfiguring, not up to the DHCP ser=
ver. =C2=A0 I would suggest that you put it this way instead:
When a DHCP server has been configured with different SFP param=
eters, the administrator or agent that updated the configuration should tri=
gger Reconfigure messages for any clients that now have stale configuration=
s. =C2=A0 How such clients are identified is implementation-dependent. =C2=
=A0 Such reconfiguration may not be possible in practice.

You should also require (or at least recommend) that clients that u=
se the SFP option support reconfigure, since reconfigure support in clients=
 is not guaranteed. =C2=A0 That said, if you are depending on this DHCP opt=
ion as a way to get clients to switch away from no-longer-valid paths, you =
are probably asking too much of DHCP.

=C2=A0 =C2=A0A server receiving the option OPTION_NSH_SFP in Solicit, =
Request, Renew,
=C2=A0 =C2=A0Rebind, Confirm or Information-request will=
 process this request and
=C2=A0 =C2=A0SHOULD respond back to exchange w=
ith NSH SFP option as detailed in
=C2=A0 =C2=
=A0section 4.2.1

I think this is incorrect,=
 and should be reworded as follows:

Clients do not=
 send OPTION_NSH_SFP to servers; therefore, servers that receive this optio=
n should take no special action as a result of having received it.

5.5. Geolocation Based SFP
=C2=A0 =C2=A0In certa=
in cloud deployment scenarios, operator will like to know the
=C2=A0 =C2=
=A0details of SFF location to provide information to local authority toward=
s
=C2=A0 =C2=A0integrity of resources and data moving across the SFF. In=
 such scenarios,
=C2=A0 =C2=A0SFF sends option OPTION_NSH_SFP along with=
 geolocation option to DHCP
=C2=A0 =C2=A0server.
=C2=A0 =C2=A0In orde=
r to achieve this, the DHCP SFF clients SHOULD include the
=C2=A0 =C2=A0=
GeoConf option as per RFC6225 and OPTION_GEOCONF_CIVIC option as per
=C2=
=A0 =C2=A0RFC4776 for DHCPv4 and DHCPv6 respectively, along with the OPTION=
_NSH_SFP
=C2=A0 =C2=A0option in DHCPDISCOVER, DHCPREQUEST, DHCPINFORM re=
quests of DHCPv4 and
=C2=A0 =C2=A0in Solicit, Request, Renew, Rebind, Co=
nfirm or Information-request in
=C2=A0 =C2=A0DHCPv6 exchanges.

The privacy implications of this section are breatht=
aking. =C2=A0 This text should not survive IESG review. =C2=A0 I recommend =
you take it out now and avoid the fight.

=C2=A0 =
=C2=A0 To minimize the unintended exposure of SFP, the OPTION_NSH_SFP
=
=C2=A0 =C2=A0option SHOULD be returned by DHCP servers only when the DHCP c=
lient
=C2=A0 =C2=A0has included this option in its request (Section 3.5 =
of [RFC2131],
=C2=A0 =C2=A0Section 9.8 of [RFC2132]).
<=
br>
Again, confusion about ORO/PRL versus sending the actual opti=
on. =C2=A0 Please change "has included this option" to "has =
requested this option". =C2=A0 Also, obviously you should not referenc=
e section 3.5 of RFC 2131--section 9.8 of RFC 2132 is the only applicable r=
eference.

=C2=A0 =C2=A0Where cri=
tical decisions might be based on the value of this option,
=C2=A0 =C2=
=A0DHCP authentication as defined in "Authentication for DHCP Messages=
"
=C2=A0 =C2=A0[RFC3118] and "Dynamic Host Configuration Proto=
col for IPv6 (DHCPv6)"
=C2=A0 =C2=A0[RFC3315] SHOULD be used to protect the integrity of =
the DHCP
   options.
=


Neither of these choices is actually available to imple=
mentations. =C2=A0 RFC 3118 didn't catch on, and the mechanism defined =
in 3315 didn't either, and is effectively deprecated. =C2=A0 If your do=
cument needs to rely on integrity protection for DHCP4, you are out of luck=
. =C2=A0 For DHCPv6, there is work in progress that you could reference, bu=
t there is no existing standard to reference.

=C2=A0 =C2=A0Link-layer confidentiality and integrity protection ma=
y also be
=C2=A0 =C2=A0employed to reduce the risk of location disclosur=
e and tampering.

I would reword this as fol=
lows:

Networks where this option is used SHOULD us=
e link-layer security and integrity protection. =C2=A0 =C2=A0Additionally, =
such networks should filter out rogue DHCP messages (RFC 7610).
<=
br>
Your IANA considerations section is inadequate. =C2=A0 Take a=
 look at:=C2=A0https://tool=
s.ietf.org/html/rfc5226

Sorry for all the crit=
icism, but the goal is to help you succeed. =C2=A0 :}

<=
/div>

--001a1141ad222b08fa052be73b03--


From nobody Tue Feb 16 10:26:16 2016
Return-Path: 
X-Original-To: dhcwg@ietfa.amsl.com
Delivered-To: dhcwg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56F691A90FB; Tue, 16 Feb 2016 10:26:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.978
X-Spam-Level: 
X-Spam-Status: No, score=-0.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=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 h8qytRKIoFqj; Tue, 16 Feb 2016 10:26:14 -0800 (PST)
Received: from mail-ig0-x233.google.com (mail-ig0-x233.google.com [IPv6:2607:f8b0:4001:c05::233]) (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 C7FC81A876B; Tue, 16 Feb 2016 10:25:57 -0800 (PST)
Received: by mail-ig0-x233.google.com with SMTP id g6so37735939igt.1; Tue, 16 Feb 2016 10:25:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=k6sHXdUDgWa8mntRvvgxlUn0keHKierozy9u/mutpYU=; b=obxU1O5bwSNCrEKXEfDWdcAA+YZEQvvUxIqPRPx8ulHjkXRc0QTKiP6YonNn+cqIYU f5QeEOYobXNmu7t70nJOjo4FBV1MBF+RYaqlnozNhDbj1bWgfu7mZZwoA9RFibSZDyaT 2cStk1DrurTMnLKS9ljQ84RrRTg20obphImZCtQyHmATGjifj/mwlSKP1aBZX4rOL/EX +jCiKqSyrYnMyCscjnYmU8M6hBpPuMOCKunq1rbBvIphfgxHwB8BKVe6gYbZy0KQX+tm VPSRMeeKOFutpvSxTIDwGxY1+qtG5y3EBstmCJIM5H2GY00UD7nyTRbH41nC4nbRO6aM VoEQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=k6sHXdUDgWa8mntRvvgxlUn0keHKierozy9u/mutpYU=; b=ORhodFTt3Km9OHxRQJHnW5g4LGLQLkEOso5mIEGewd7NiH5MtquOFpv7tvtRbPmDdI n4ELoErr/R10/O8DMdEnzNyy3nN/5TLVCtOrnzhyj1h37b6dvwcnDx7stEFcq3frtbE2 UwAWE1tHrHQM5rlOPUU0XIBLyJR1IZ2BtxFNlXPbZ+scbsXL65GvE3Iau/4HiushC6tn 1gESv+efuvj2fsqbJpDDjA7zix62Wag03WHshYz/9nnPiKktO6jGipt5pZ2kkT8myI99 +yUo9Z770o23ycl6IEHjTXHJkqsVCvnAlPlumI9/7X1umLdx+4ZO+du8o9ed+o9kQdKh tQHA==
X-Gm-Message-State: AG10YOS7dp3OU4MwiIpOFLbspI0tR8J05mY+z2eqyJC5YOzlIRXGbhWLcPTIJhiogGFZiENPz2+Gnq0YxDJtew==
MIME-Version: 1.0
X-Received: by 10.50.43.226 with SMTP id z2mr1155520igl.78.1455647157140; Tue, 16 Feb 2016 10:25:57 -0800 (PST)
Sender: jinmei.tatuya@gmail.com
Received: by 10.107.169.35 with HTTP; Tue, 16 Feb 2016 10:25:57 -0800 (PST)
In-Reply-To: <163001d168e5$c9a63ed0$5cf2bc70$@huitema.net>
References: <20160201142413.30288.23248.idtracker@ietfa.amsl.com>  <163001d168e5$c9a63ed0$5cf2bc70$@huitema.net>
Date: Tue, 16 Feb 2016 10:25:57 -0800
X-Google-Sender-Auth: rnhAmZGPhgR9nXGryi54hJVp3mc
Message-ID: 
From: =?UTF-8?B?56We5piO6YGU5ZOJ?= 
To: Christian Huitema 
Content-Type: text/plain; charset=UTF-8
Archived-At: 
Cc: draft-ietf-dhc-anonymity-profile@ietf.org, dhc-chairs@ietf.org, ietf@ietf.org, IETF-Announce , "dhcwg@ietf.org" 
Subject: Re: [dhcwg] Last Call:  (Anonymity profile for DHCP clients) to Proposed Standard
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 16 Feb 2016 18:26:15 -0000

At Tue, 16 Feb 2016 10:13:49 -0800,
"Christian Huitema"  wrote:

> > 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?
>
> This section was rewritten in draft-07, following the feedback received during IETF last call. Basically, we stopped being lazy and actually did the study. And took a lot of the text that Lorenzo provided.

I didn't intend to make my comment as a blocking issue for the last
call, but just to be clear: The revised section 4.5.2 of rev 07 looks
good to me.

--
JINMEI, Tatuya


From nobody Tue Feb 16 12:48:00 2016
Return-Path: 
X-Original-To: dhcwg@ietfa.amsl.com
Delivered-To: dhcwg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2AF41ACF08; Tue, 16 Feb 2016 12:47:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.906
X-Spam-Level: 
X-Spam-Status: No, score=-1.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.006] 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 OPopfQo1Q4nn; Tue, 16 Feb 2016 12:47:55 -0800 (PST)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 13A271ACDBD; Tue, 16 Feb 2016 12:47:54 -0800 (PST)
Received: from unnumerable.local (pool-173-57-158-165.dllstx.fios.verizon.net [173.57.158.165]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id u1GKlrau076384 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=OK); Tue, 16 Feb 2016 14:47:53 -0600 (CST) (envelope-from rjsparks@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host pool-173-57-158-165.dllstx.fios.verizon.net [173.57.158.165] claimed to be unnumerable.local
To: General Area Review Team , "ietf@ietf.org" , "dhcwg@ietf.org" , draft-ietf-dhc-dhcpv6-privacy.all@ietf.org
References: <56B0DBA3.2050406@nostrum.com>
From: Robert Sparks 
Message-ID: <56C38AF9.7030303@nostrum.com>
Date: Tue, 16 Feb 2016 14:47:53 -0600
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.5.1
MIME-Version: 1.0
In-Reply-To: <56B0DBA3.2050406@nostrum.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: [dhcwg] Gen-Art review: draft-ietf-dhc-dhcpv6-privacy-04
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 16 Feb 2016 20:47:57 -0000

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair. Please wait for direction from your
document shepherd or AD before posting a new version of the draft.

For more information, please see the FAQ at

.

Document: draft-ietf-dhc-dhcpv6-privacy-04
Reviewer: Robert Sparks
Review Date: 16Feb2015
IETF LC End Date: past
IESG Telechat date: 18Feb2015

Summary: Ready for publication as an Informational RFC

All of the nits from my LC review have been addressed. Thanks!

RjS

On 2/2/16 10:38 AM, Robert Sparks wrote:
> I am the assigned Gen-ART reviewer for this draft. The General Area
> Review Team (Gen-ART) reviews all IETF documents being processed
> by the IESG for the IETF Chair.  Please treat these comments just
> like any other last call comments.
>
> For more information, please see the FAQ at
>
> .
>
> Document: draft-ietf-dhc-dhcpv6-privacy-03
> Reviewer: Robert Sparks
> Review Date: 2Feb2015
> IETF LC End Date:4Feb2015
> IESG Telechat date: Not yet scheduled
>
> Summary: Ready with nits that should be addressed before publication
>
> The reference to ietf-6man-ivp6-address-generation-privacy should be 
> normative, and when this document is pointing to it because it is 
> discussing a field carrying a generated address, it should be more 
> explicit about why it's making the reference.
>
> In section 4.3 the paragraph on Hash allocation should note that even 
> a well implemented hash does not mitigate the threat of correlation 
> over time.
>
> In section 4.3, the paragraph on Random allocation comments on the 
> poor performance of a specific simplistic implementation of random 
> selection. More efficient algorithms exist. But the discussion is 
> mostly irrelevant to the document. Please simplify this paragraph to 
> focus on the benefits of random allocation.
>
> Should section 5.3 also call out mapping IP addresses into geolocation?
>
> Why doesn't section 5.5 also talk about things like MAC addresses?
>
> Section 5.6 could probably borrow words from RFC7258 - it should at 
> least reference it (currently there is only a reference from the 
> introduction.)
>
> _______________________________________________
> Gen-art mailing list
> Gen-art@ietf.org
> https://www.ietf.org/mailman/listinfo/gen-art


From nobody Tue Feb 16 18:10:10 2016
Return-Path: 
X-Original-To: dhcwg@ietf.org
Delivered-To: dhcwg@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id F26D81B3372; Tue, 16 Feb 2016 18:10:08 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: "Ben Campbell" 
To: "The IESG" 
X-Test-IDTracker: no
X-IETF-IDTracker: 6.14.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20160217021008.17111.65342.idtracker@ietfa.amsl.com>
Date: Tue, 16 Feb 2016 18:10:08 -0800
Archived-At: 
Cc: dhc-chairs@ietf.org, volz@cisco.com, draft-ietf-dhc-anonymity-profile@ietf.org, dhcwg@ietf.org
Subject: [dhcwg] Ben Campbell's Yes on draft-ietf-dhc-anonymity-profile-07: (with COMMENT)
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.15
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 Feb 2016 02:10:09 -0000

Ben Campbell has entered the following ballot position for
draft-ietf-dhc-anonymity-profile-07: Yes

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dhc-anonymity-profile/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thanks for doing this. I have some comments, most of which can be safely
ignored:

*** Substantive ***
- 2.6, 2nd paragraph:
It seems like the "if servers do not object" part goes against the spirit
of section 2.5.

- 3 (top level)

-- There's a lot of normative language about things people MUST or MAY
put into DHCP messages (as opposed to the SHOULD NOTs). Are those new
requirements created by this profile, or statements of fact about DHCP in
general? If the latter, please consider dropping the 2119 keywords.

-- "It SHOULD NOT contain any other option"
This language repeats several times. But there’s a fair amount of text
later in the subsections that talks about specific “other options†that
SHOULD NOT be included. That seems redundant. I wonder if there's an
opportunity to simplify things?

-- 2nd to last paragraph:
It seems odd to say things SHOULD follow the dhcp standard; that's kind
of implied by being dhcp.

- 3 and subsections:
There are a lot of SHOULDs that I am surprised are not MUSTs. I
understand that the entire profile is optional, but it seems like some of
the guidance could be stronger for clients that use the profile in the
first place.

- 3.1, last paragraph:
Please describe the consequences of not following that SHOULD. For
example, doesn’t the MAY alternative _add_ a fingerprinting opportunity?
- 3.2, 2nd to last paragraph: "DHCP clients should ensure"
Should that be SHOULD?
-3.3, 2nd paragraph: "They MUST use the option when mandated by the DHCP
protocol..."
That seems more like a statement of fact.

-3.7, third paragraph:
What’s the point of allowing the sending of an obfuscated host name,
rather than just saying MUST NOT send the host name in the first place?

- 4.3, 3rd paragraph:
Isn't the randomization of link-layer addresses a fundamental premise of
this draft?

*** Editorial ***

- 3, 2nd to last paragraph:
Can the "following sections" be more specific? That is, list the section
numbers, or mention "The remaining subsections"?

- 3.1, 2nd to last paragraph:
Are we really talking about clients "willing" to protect privacy, or
clients "wishing" or "intending" to protect privacy?

- 3.4:
The document already spent several pages motivating the randomization of
link-layer addresses. It seems unnecessary to do it again here.

-3.5, 2nd to last paragraph:
“based solely†seems ambiguous. Do I understand correctly that this means
the client MUST NOT use client identifiers that persist across changes in
the link layer address?
The assertion that this will ensure that no privacy leaks occur seems
overstated. I suspect there are other ways clients can leak private
information.

- 3.6:
The guidance on ordering seems redundant with 3.1.

- 3.9, 2nd paragraph, last sentence: "If only for privacy reasons..."
I suggest removing the clause. It weakens the following normative
requirement. 

- 4.5, first paragraph: "indemtified"
identified?



From nobody Wed Feb 17 13:01:59 2016
Return-Path: 
X-Original-To: dhcwg@ietf.org
Delivered-To: dhcwg@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 44C471B2D17; Wed, 17 Feb 2016 13:01:57 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: "Alissa Cooper" 
To: "The IESG" 
X-Test-IDTracker: no
X-IETF-IDTracker: 6.14.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20160217210157.24922.8163.idtracker@ietfa.amsl.com>
Date: Wed, 17 Feb 2016 13:01:57 -0800
Archived-At: 
Cc: dhc-chairs@ietf.org, JuanCarlos.Zuniga@InterDigital.com, volz@cisco.com, draft-ietf-dhc-anonymity-profile@ietf.org, dhcwg@ietf.org
Subject: [dhcwg] Alissa Cooper's Yes on draft-ietf-dhc-anonymity-profile-07: (with COMMENT)
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.15
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 Feb 2016 21:01:57 -0000

Alissa Cooper has entered the following ballot position for
draft-ietf-dhc-anonymity-profile-07: Yes

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dhc-anonymity-profile/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Great work, thanks.

= General =

This document seems to use the term "link-layer address randomization" to
describe the situation where a link-layer address is randomly generated
AND changes over time. While this seems the likely way that such
addresses may be standardized in the future, it's not guaranteed. An
address could be randomly generated (or otherwise semantically opaque,
e.g. not containing an OUI) but permanent for the life of the
device/interface, in which case the privacy benefits of what is specified
in this draft are not the same. Therefore I think it's worth explicitly
stating the interpretation of "random address" that is being used here.

= Section 1 =

s/Reports surfaced recently/There have been reports/

= Section 2 =

Would be good to update the references to work going on in IEEE 802.1.
Also there were experiments at multiple IEEE and IETF meetings. 

= Section 3 =

Section 3.1 says:

"The client willing to protect its privacy SHOULD limit the subset of
   options sent in messages to the subset listed in the following
   sections."

Then all the subsections discuss specific options and considerations for
using them, except 3.9, which basically says "don't use these." I would
assume there are a bunch of other options that clients definitely
shouldn't use if they want to maintain anonymity (I was thinking of 123
and 144, geolocation). So why are only the PXE options mentioned here,
when the text in 3.1 seemed to be saying that clients should avoid all
other options not mentioned?



From nobody Wed Feb 17 15:07:19 2016
Return-Path: 
X-Original-To: dhcwg@ietf.org
Delivered-To: dhcwg@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 02A711A874E; Wed, 17 Feb 2016 15:07:18 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: "Ben Campbell" 
To: "The IESG" 
X-Test-IDTracker: no
X-IETF-IDTracker: 6.14.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20160217230718.32558.47975.idtracker@ietfa.amsl.com>
Date: Wed, 17 Feb 2016 15:07:18 -0800
Archived-At: 
Cc: dhc-chairs@ietf.org, draft-ietf-dhc-dhcpv6-privacy@ietf.org, dhcwg@ietf.org, volz@cisco.com
Subject: [dhcwg] Ben Campbell's Yes on draft-ietf-dhc-dhcpv6-privacy-04: (with COMMENT)
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.15
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 Feb 2016 23:07:18 -0000

Ben Campbell has entered the following ballot position for
draft-ietf-dhc-dhcpv6-privacy-04: Yes

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6-privacy/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

-2:
If this is strictly an analysis with no proposed solution, why does it
need 2119 keywords? Actually, I only found one MAY, and that seemed more
a statement of fact than a new requirement.

-5.6:
This seems to talk about pervasive monitoring in a very general sense.
Can you say something about how that specifically relates to dhcpv6?



From nobody Wed Feb 17 15:08:13 2016
Return-Path: 
X-Original-To: dhcwg@ietf.org
Delivered-To: dhcwg@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D2D6F1B312B; Wed, 17 Feb 2016 15:08:11 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: "Ben Campbell" 
To: "The IESG" 
X-Test-IDTracker: no
X-IETF-IDTracker: 6.14.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20160217230811.28279.30018.idtracker@ietfa.amsl.com>
Date: Wed, 17 Feb 2016 15:08:11 -0800
Archived-At: 
Cc: dhc-chairs@ietf.org, draft-ietf-dhc-dhcp-privacy@ietf.org, volz@cisco.com, dhcwg@ietf.org
Subject: [dhcwg] Ben Campbell's Yes on draft-ietf-dhc-dhcp-privacy-04: (with COMMENT)
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.15
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 Feb 2016 23:08:12 -0000

Ben Campbell has entered the following ballot position for
draft-ietf-dhc-dhcp-privacy-04: Yes

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dhc-dhcp-privacy/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

If this is strictly an analysis with no proposed solution, why does it
need 2119 keywords? Actually, I only found one MAY, and that seemed more
a statement of fact than a new requirement.



From nobody Thu Feb 18 03:02:18 2016
Return-Path: 
X-Original-To: dhcwg@ietf.org
Delivered-To: dhcwg@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B20951B36C7; Thu, 18 Feb 2016 03:02:16 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: "Benoit Claise" 
To: "The IESG" 
X-Test-IDTracker: no
X-IETF-IDTracker: 6.14.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20160218110216.27192.24027.idtracker@ietfa.amsl.com>
Date: Thu, 18 Feb 2016 03:02:16 -0800
Archived-At: 
Cc: dhc-chairs@ietf.org, volz@cisco.com, draft-ietf-dhc-anonymity-profile@ietf.org, dhcwg@ietf.org
Subject: [dhcwg] Benoit Claise's Yes on draft-ietf-dhc-anonymity-profile-07: (with COMMENT)
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.15
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 18 Feb 2016 11:02:16 -0000

Benoit Claise has entered the following ballot position for
draft-ietf-dhc-anonymity-profile-07: Yes

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dhc-anonymity-profile/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thanks. Happy to see this work, along with the trade-off analysis.



From nobody Thu Feb 18 05:38:00 2016
Return-Path: 
X-Original-To: dhcwg@ietfa.amsl.com
Delivered-To: dhcwg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9305C1A1B3F; Thu, 18 Feb 2016 05:37:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.906
X-Spam-Level: 
X-Spam-Status: No, score=-1.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.006] 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 D8b2J_THYC72; Thu, 18 Feb 2016 05:37:58 -0800 (PST)
Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by ietfa.amsl.com (Postfix) with ESMTP id 388661A1B20; Thu, 18 Feb 2016 05:37:58 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 8C6972CCBF; Thu, 18 Feb 2016 15:37:57 +0200 (EET) (envelope-from jari.arkko@piuha.net)
X-Virus-Scanned: amavisd-new at piuha.net
Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HOnaILnBr2iz; Thu, 18 Feb 2016 15:37:57 +0200 (EET)
Received: from [127.0.0.1] (p130.piuha.net [IPv6:2a00:1d50:2::130]) by p130.piuha.net (Postfix) with ESMTP id 29F182CC9A; Thu, 18 Feb 2016 15:37:57 +0200 (EET) (envelope-from jari.arkko@piuha.net)
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
Content-Type: multipart/signed; boundary="Apple-Mail=_40B7DADB-CF54-4DDB-AB2A-4F9EBF6E48A0"; protocol="application/pgp-signature"; micalg=pgp-sha512
X-Pgp-Agent: GPGMail 2.5.2
From: Jari Arkko 
In-Reply-To: <56C38AF9.7030303@nostrum.com>
Date: Thu, 18 Feb 2016 15:37:56 +0200
Message-Id: <9658D03D-F3F4-4F09-B552-FEB1253FC396@piuha.net>
References: <56B0DBA3.2050406@nostrum.com> <56C38AF9.7030303@nostrum.com>
To: Robert Sparks 
X-Mailer: Apple Mail (2.1878.6)
Archived-At: 
Cc: "dhcwg@ietf.org" , General Area Review Team , draft-ietf-dhc-dhcpv6-privacy.all@ietf.org, "ietf@ietf.org" 
Subject: Re: [dhcwg] Gen-Art review: draft-ietf-dhc-dhcpv6-privacy-04
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 18 Feb 2016 13:37:59 -0000

--Apple-Mail=_40B7DADB-CF54-4DDB-AB2A-4F9EBF6E48A0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset=us-ascii

Thanks Robert & Tomek!

Jari


--Apple-Mail=_40B7DADB-CF54-4DDB-AB2A-4F9EBF6E48A0
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - https://gpgtools.org

iQIcBAEBCgAGBQJWxck0AAoJEM80gCTQU46qkgkQAL7LJKgr+Y/hmS2llwNZqBII
g/IzMrE4fJ6Q+A1nv9H20FpxLaY21RCXKoSxIqOr47AC6CoZmd7lHd5wfCYlcM6O
ix/nDm9+626ga9csg9s4CD0RaIUV4Ybmf6OX/LFm7UBJfC3WJzFifIhiCldk2bIL
a7AocVkrJlcTlX5R8oz/sQuU/hsZSbuHgV8BZ/AwNbT7z7FK/A+fq0DUHCcvW/sg
Fi9JChJZEmlK/rNKElL26uzuLA0YFILu5QvjCSZ023kBWUbqO8l4XmpB0ixLIBBw
GC8IMeOjPrNBITJtIeZQtCy3l94UFuDHPJ1I7dTFTCE0YmFccxXLuFoQZnVOTbar
0sl5gvqj5i81udx59r2mShj5pBw2tvOKCJRwq8KRSG6PboMx3ZeuD21tMic+MO/e
rwWmDI1UgoJMije9CzaqJ7/0IoOWPzS0XcVKZJfOA2BLaxg9q86Mn8ElcT5cc5Sg
44wUn5C+MFdsHzMaDQh9wds0zGA4JFNvoWRtSuwgJe801GfePhBJGfN4ay3PlKyp
J3+63BRNBsjBNgQ+gPfOd/Ko1l1elP3gt7zLLndA9KFYBaxr9W3obTSu1dQSLdJ/
1W2uOX52cnfBMiO2WPBwyfiupDfDIcVPdIrkZFkbKHDbZ02lLUYCSBGWoVWQs3/A
03n8dixcScdSd0DymUyD
=uqCH
-----END PGP SIGNATURE-----

--Apple-Mail=_40B7DADB-CF54-4DDB-AB2A-4F9EBF6E48A0--


From nobody Fri Feb 19 12:58:56 2016
Return-Path: 
X-Original-To: dhcwg@ietfa.amsl.com
Delivered-To: dhcwg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFC7C1B3520; Fri, 19 Feb 2016 12:58:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.002
X-Spam-Level: 
X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] 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 SIzb2vyyPvtA; Fri, 19 Feb 2016 12:58:49 -0800 (PST)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0714.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::714]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 639FC1B351F; Fri, 19 Feb 2016 12:58:48 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=WiCj39FuWDqnZL3LFon4nDPZL0XHnq7bpMwkwN5Fmjw=; b=YC5+8Ze8gwdALHquhTzKOVtJz3IXDA7euY86zFYMTFif+Alu0KxnYIGN4chff9YZts4MhPBPXbb+vj5+Kl9QVByTncqAZph2QQVDZ6v8bg149g5WVFNIyuBcMrpY588Fay16FnRRLb3vCDNyWIX+qe6xQGYJlocpkl98EaPmYdI=
Received: from DM2PR0301MB0655.namprd03.prod.outlook.com (10.160.96.17) by DM2PR0301MB0656.namprd03.prod.outlook.com (10.160.96.18) with Microsoft SMTP Server (TLS) id 15.1.409.15; Fri, 19 Feb 2016 20:58:30 +0000
Received: from DM2PR0301MB0655.namprd03.prod.outlook.com ([10.160.96.17]) by DM2PR0301MB0655.namprd03.prod.outlook.com ([10.160.96.17]) with mapi id 15.01.0409.017; Fri, 19 Feb 2016 20:58:30 +0000
From: Christian Huitema 
To: Ben Campbell , The IESG 
Thread-Topic: Ben Campbell's Yes on draft-ietf-dhc-anonymity-profile-07: (with COMMENT)
Thread-Index: AQHRaShXolUb80HWIEy0z+tnE4mU8p8zzY0Q
Date: Fri, 19 Feb 2016 20:58:30 +0000
Message-ID: 
References: <20160217021008.17111.65342.idtracker@ietfa.amsl.com>
In-Reply-To: <20160217021008.17111.65342.idtracker@ietfa.amsl.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: nostrum.com; dkim=none (message not signed) header.d=none;nostrum.com; dmarc=none action=none header.from=microsoft.com;
x-originating-ip: [2001:4898:80e8:e::409]
x-ms-office365-filtering-correlation-id: 6b88aca3-471c-4a70-d7f7-08d3396f6bf7
x-microsoft-exchange-diagnostics: 1; DM2PR0301MB0656; 5:wcso+R1XZA7AiKE52d4uZO0ZttOBlb7j8WL7xzs19ysHnSashrb2xuYoTZ/+WjADqli01uPzgpLChRbYD9690av3nVbU2Gq7KlbT8gzK9K55aR8VhKm8rBESJK9yVu+l3Nv425Gx9ZoUQZ5IxSC03g==; 24:5CcUYv9yKKhT+6Dthz2T12g0myRCIy632oLskiD58gBbM15VzbF+hDkZlPWw613f2kmQ6FowC6BMOQDDPFoWlJXfTj0rKmV0HnIWtueFrSs=
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR0301MB0656;
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(61426038)(61427038); SRVR:DM2PR0301MB0656; BCL:0; PCL:0; RULEID:; SRVR:DM2PR0301MB0656; 
x-forefront-prvs: 08572BD77F
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(51914003)(24454002)(377454003)(4326007)(586003)(5008740100001)(5001770100001)(77096005)(3280700002)(33656002)(11100500001)(1220700001)(1096002)(2906002)(5004730100002)(8990500004)(122556002)(74316001)(99286002)(5001960100002)(40100003)(189998001)(230783001)(76576001)(106116001)(10400500002)(5005710100001)(5003600100002)(2950100001)(2900100001)(10290500002)(5002640100001)(86362001)(87936001)(50986999)(54356999)(76176999)(3660700001)(92566002)(102836003)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR0301MB0656; H:DM2PR0301MB0655.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; 
spamdiagnosticoutput: 1:23
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Feb 2016 20:58:30.2898 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0301MB0656
Archived-At: 
Cc: "dhc-chairs@ietf.org" , "volz@cisco.com" , "draft-ietf-dhc-anonymity-profile@ietf.org" , "dhcwg@ietf.org" 
Subject: Re: [dhcwg] Ben Campbell's Yes on draft-ietf-dhc-anonymity-profile-07: (with COMMENT)
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 19 Feb 2016 20:58:53 -0000

T24gVHVlc2RheSwgRmVicnVhcnkgMTYsIDIwMTYgNjoxMCBQTSwgQmVuIENhbXBiZWxsIHdyb3Rl
Og0KDQo+Li4uDQo+ICoqKiBTdWJzdGFudGl2ZSAqKioNCj4gLSAyLjYsIDJuZCBwYXJhZ3JhcGg6
DQo+IEl0IHNlZW1zIGxpa2UgdGhlICJpZiBzZXJ2ZXJzIGRvIG5vdCBvYmplY3QiIHBhcnQgZ29l
cyBhZ2FpbnN0IHRoZSBzcGlyaXQgb2YNCj4gc2VjdGlvbiAyLjUuDQoNCkkgZ3Vlc3Mgd2UgY2Fu
IHN1cHByZXNzIHRoZSAiaWYgc2VydmVyIGRvIG5vdCBvYmplY3QiIHBhcnQuIFNlcnZlcnMgY291
bGQgZG8gYWxsIGtpbmQgb2YgdGhpbmdzLCBidXQgdGhpcyBzcGVjaWZpY2F0aW9uIGlzIHJlYWxs
eSBmb3IgY2xpZW50cy4NCg0KVGhlcmUgaXMgYW4gZXhhbXBsZSBpbiBzZWN0aW9uIDUgb2YgaG93
IHNlcnZlcnMgbWlnaHQgb2JqZWN0IC0tIGJ5IGVuZm9yY2luZyBhIHdoaXRlIGxpc3Qgb2YgTUFD
IGFkZHJlc3Nlcy4gUHJvYmFibHkgbm8gbmVlZCB0byBzYXkgdGhhdCBhZ2FpbiBpbiAyLjYuDQoN
Cj4gLSAzICh0b3AgbGV2ZWwpDQo+IA0KPiAtLSBUaGVyZSdzIGEgbG90IG9mIG5vcm1hdGl2ZSBs
YW5ndWFnZSBhYm91dCB0aGluZ3MgcGVvcGxlIE1VU1Qgb3IgTUFZIHB1dA0KPiBpbnRvIERIQ1Ag
bWVzc2FnZXMgKGFzIG9wcG9zZWQgdG8gdGhlIFNIT1VMRCBOT1RzKS4gQXJlIHRob3NlIG5ldw0K
PiByZXF1aXJlbWVudHMgY3JlYXRlZCBieSB0aGlzIHByb2ZpbGUsIG9yIHN0YXRlbWVudHMgb2Yg
ZmFjdCBhYm91dCBESENQIGluDQo+IGdlbmVyYWw/IElmIHRoZSBsYXR0ZXIsIHBsZWFzZSBjb25z
aWRlciBkcm9wcGluZyB0aGUgMjExOSBrZXl3b3Jkcy4NCg0KVGhlIHBhcnQgc3BlY2lmaWMgdG8g
dGhlIGFub255bWl0eSBwcm9maWxlIGlzIHRoZSByZXN0cmljdGlvbiwgInNob3VsZCBub3QgY29u
dGFpbiBtb3JlIG9wdGlvbnMuIiBUaGUgTVVTVCBwYXJ0IGlzIGxhcmdlbHkgYSByZXBlYXQgb2Yg
dGhlIG1haW4gc3BlYy4NCg0KPiAtLSAiSXQgU0hPVUxEIE5PVCBjb250YWluIGFueSBvdGhlciBv
cHRpb24iDQo+IFRoaXMgbGFuZ3VhZ2UgcmVwZWF0cyBzZXZlcmFsIHRpbWVzLiBCdXQgdGhlcmXi
gJlzIGEgZmFpciBhbW91bnQgb2YgdGV4dCBsYXRlciBpbg0KPiB0aGUgc3Vic2VjdGlvbnMgdGhh
dCB0YWxrcyBhYm91dCBzcGVjaWZpYyDigJxvdGhlciBvcHRpb25z4oCdIHRoYXQgU0hPVUxEIE5P
VA0KPiBiZSBpbmNsdWRlZC4gVGhhdCBzZWVtcyByZWR1bmRhbnQuIEkgd29uZGVyIGlmIHRoZXJl
J3MgYW4gb3Bwb3J0dW5pdHkgdG8NCj4gc2ltcGxpZnkgdGhpbmdzPw0KDQpXZSB3ZW50IHRocm91
Z2ggc2V2ZXJhbCBpdGVyYXRpb25zIG9mIHRoaXMgdGV4dCwgYW5kIGl0IHdhcyB0aG9yb3VnaGx5
IHJldmlld2VkLiBJIGFtIGNvbmNlcm5lZCB0aGF0IGNoYW5naW5nIHNvbWV0aGluZyBub3cgd291
bGQgcmVxdWlyZSBnb2luZyBiYWNrIHRvIHRoZSBXRy4NCg0KPiAtLSAybmQgdG8gbGFzdCBwYXJh
Z3JhcGg6DQo+IEl0IHNlZW1zIG9kZCB0byBzYXkgdGhpbmdzIFNIT1VMRCBmb2xsb3cgdGhlIGRo
Y3Agc3RhbmRhcmQ7IHRoYXQncyBraW5kIG9mDQo+IGltcGxpZWQgYnkgYmVpbmcgZGhjcC4NCg0K
WWVzLiBXaGF0IGlzIG1lYW50IGlzIHRoYXQgc2luY2UgdGhpcyBpcyBESENQLCB3ZSB3aWxsIG9m
IGNvdXJzZSBmb2xsb3cgdGhlIHN0YW5kYXJkLCBidXQgd2UgYXJlIGdvaW5nIHRvIGhhdmUgc29t
ZSBkZXZpYXRpb25zIGFuZCBjaG9pY2VzLCBhcyBleHBsYWluZWQgaW4gdGhlIHJlbWFpbmluZyBz
dWJzZWN0aW9ucy4gRG8geW91IGhhdmUgYSBiZXR0ZXIgdGV4dD8NCg0KPiAtIDMgYW5kIHN1YnNl
Y3Rpb25zOg0KPiBUaGVyZSBhcmUgYSBsb3Qgb2YgU0hPVUxEcyB0aGF0IEkgYW0gc3VycHJpc2Vk
IGFyZSBub3QgTVVTVHMuIEkgdW5kZXJzdGFuZA0KPiB0aGF0IHRoZSBlbnRpcmUgcHJvZmlsZSBp
cyBvcHRpb25hbCwgYnV0IGl0IHNlZW1zIGxpa2Ugc29tZSBvZiB0aGUgZ3VpZGFuY2UNCj4gY291
bGQgYmUgc3Ryb25nZXIgZm9yIGNsaWVudHMgdGhhdCB1c2UgdGhlIHByb2ZpbGUgaW4gdGhlIGZp
cnN0IHBsYWNlLg0KDQpUaGUgcHJvYmxlbSBpcyB0aGF0IGluIG1hbnkgY2FzZSB0aGVyZSBpcyBh
IGNvbmZsaWN0IGJldHdlZW4gcGVyZmVjdGlvbiBhbmQgdXNhYmlsaXR5LCBhcyB3ZWxsIGFzIGRv
dWJ0cyBhYm91dCBob3cgZmFyIHRvIGdvIHRvIGF2b2lkIGZpbmdlcnByaW50aW5nLg0KIA0KPiAt
IDMuMSwgbGFzdCBwYXJhZ3JhcGg6DQo+IFBsZWFzZSBkZXNjcmliZSB0aGUgY29uc2VxdWVuY2Vz
IG9mIG5vdCBmb2xsb3dpbmcgdGhhdCBTSE9VTEQuIEZvcg0KPiBleGFtcGxlLCBkb2VzbuKAmXQg
dGhlIE1BWSBhbHRlcm5hdGl2ZSBfYWRkXyBhIGZpbmdlcnByaW50aW5nIG9wcG9ydHVuaXR5Pw0K
DQpXZSBjYW4gZGViYXRlIHRoYXQuIFdoYXQgeW91IHNlZSB0aGVyZSBpcyBhIGNvbXByb21pc2Ug
YmV0d2VlbiB0aGVvcnkgYW5kIHByYWN0aWNlLiBPdXIgV2luZG93cyAxMCBpbXBsZW1lbnRhdGlv
biBhY3R1YWxseSB1c2VzIHRoZSBmaXggb3JkZXIsIGJlY2F1c2UgdGhhdCBjYW4gYmUgc2V0IGF0
IGNvbXBpbGUgdGltZS4gQWxzbywgd2UgdXNlIHRoZSBzYW1lIGZpeGVkIG9yZGVyIHdoZXRoZXIg
b3Igbm90IHRoZSBjbGllbnQgaXMgdXNpbmcgYW5vbnltaXR5IHByb2ZpbGUuIFNvIHlvdSBjb3Vs
ZCBzYXkgdGhhdCBub3QgcmFuZG9taXppbmcgZmluZ2VycHJpbnRzIHRoZSBkZXZpY2UgYXMgInJ1
bm5pbmcgd2luZG93cyAxMCIsIHdoaWxlIHJhbmRvbWl6aW5nIHdvdWxkIGZpbmdlcnByaW50IGFz
ICJ1c2luZyB0aGUgYW5vbnltaXR5IHByb2ZpbGUuIg0KDQo+IC0gMy4yLCAybmQgdG8gbGFzdCBw
YXJhZ3JhcGg6ICJESENQIGNsaWVudHMgc2hvdWxkIGVuc3VyZSINCj4gU2hvdWxkIHRoYXQgYmUg
U0hPVUxEPw0KDQpZZXMuDQoNCj4gLTMuMywgMm5kIHBhcmFncmFwaDogIlRoZXkgTVVTVCB1c2Ug
dGhlIG9wdGlvbiB3aGVuIG1hbmRhdGVkIGJ5IHRoZQ0KPiBESENQIHByb3RvY29sLi4uIg0KPiBU
aGF0IHNlZW1zIG1vcmUgbGlrZSBhIHN0YXRlbWVudCBvZiBmYWN0Lg0KDQpZZXMuIFdlIHdlcmUg
Y29uY2VybmVkIHRoYXQgaW1wbGVtZW50ZXJzIHdvdWxkIHNjcmF0Y2ggdGhlaXIgaGVhZCBhbmQg
d29uZGVyIGhvdyB0byBiYWxhbmNlIHRoZSBhbm9ueW1pdHkgc3RhdGVtZW50ICJ0aGlzIGlzIHNv
bWV0aW1lcyBkYW5nZXJvdXMiIHZlcnN1cyB0aGUgREhDUCBzcGVjaWZpY2F0aW9uLiBEbyB5b3Ug
c3VnZ2VzdCB0byBkcm9wIHRoZSBzZW50ZW5jZT8NCg0KPiAtMy43LCB0aGlyZCBwYXJhZ3JhcGg6
DQo+IFdoYXTigJlzIHRoZSBwb2ludCBvZiBhbGxvd2luZyB0aGUgc2VuZGluZyBvZiBhbiBvYmZ1
c2NhdGVkIGhvc3QgbmFtZSwgcmF0aGVyDQo+IHRoYW4ganVzdCBzYXlpbmcgTVVTVCBOT1Qgc2Vu
ZCB0aGUgaG9zdCBuYW1lIGluIHRoZSBmaXJzdCBwbGFjZT8NCg0KV2VsbCwgd2Ugc2F5ICJTSE9V
TEQgTk9UIiBzZW5kIHRoZSBob3N0IG5hbWUuIFRoaXMgaXMgd2hhdCB0aGUgV2luZG93cyAxMCBp
bXBsZW1lbnRhdGlvbiBkb2VzLCBhbmQgd2UgaGF2ZSB2ZXJpZmllZCB0aGF0IGl0IGRvZXMgbm90
IGNhdXNlIHByb2JsZW1zIGluIHByYWN0aWNlLiBCdXQgZHVyaW5nIHRoZSBkcmFmdCBkZXZlbG9w
bWVudCB3ZSB3ZXJlIHJlYWxseSBjb25jZXJuZWQgdGhhdCBzb21lIG5ldHdvcmsgZnVuY3Rpb25h
bGl0eSBtaWdodCByZXF1aXJlIHNlbmRpbmcgYSBuYW1lIHZhbHVlIGluIERIQ1AuIA0KDQpJIGFt
IGNvbmNlcm5lZCB0aGF0IGNoYW5naW5nIHRoYXQgbm93IHdpbGwgcmVxdWlyZSBXRyBmZWVkYmFj
ay4NCg0KPiAtIDQuMywgM3JkIHBhcmFncmFwaDoNCj4gSXNuJ3QgdGhlIHJhbmRvbWl6YXRpb24g
b2YgbGluay1sYXllciBhZGRyZXNzZXMgYSBmdW5kYW1lbnRhbCBwcmVtaXNlIG9mIHRoaXMNCj4g
ZHJhZnQ/DQoNClRoaXMgaXMgbWVhbnQgZm9yIGV4YW1wbGUgZm9yIGFub255bW91cyBWUE4gbGlu
a3MuIFRoZXJlIHdhcyBzcGVjaWZpYyBXRyBmZWVkYmFjayByZXF1ZXN0aW5nIHRoYXQuDQoNCj4g
KioqIEVkaXRvcmlhbCAqKioNCj4gDQo+IC0gMywgMm5kIHRvIGxhc3QgcGFyYWdyYXBoOg0KPiBD
YW4gdGhlICJmb2xsb3dpbmcgc2VjdGlvbnMiIGJlIG1vcmUgc3BlY2lmaWM/IFRoYXQgaXMsIGxp
c3QgdGhlIHNlY3Rpb24NCj4gbnVtYmVycywgb3IgbWVudGlvbiAiVGhlIHJlbWFpbmluZyBzdWJz
ZWN0aW9ucyI/DQoNCiJUaGUgcmVtYWluaW5nIHN1YnNlY3Rpb25zIiBsb29rcyBnb29kLg0KDQo+
IC0gMy4xLCAybmQgdG8gbGFzdCBwYXJhZ3JhcGg6DQo+IEFyZSB3ZSByZWFsbHkgdGFsa2luZyBh
Ym91dCBjbGllbnRzICJ3aWxsaW5nIiB0byBwcm90ZWN0IHByaXZhY3ksIG9yIGNsaWVudHMNCj4g
Indpc2hpbmciIG9yICJpbnRlbmRpbmciIHRvIHByb3RlY3QgcHJpdmFjeT8NCg0KImludGVuZGlu
ZyIgaXMgZmluZS4NCg0KPiAtIDMuNDoNCj4gVGhlIGRvY3VtZW50IGFscmVhZHkgc3BlbnQgc2V2
ZXJhbCBwYWdlcyBtb3RpdmF0aW5nIHRoZSByYW5kb21pemF0aW9uIG9mDQo+IGxpbmstbGF5ZXIg
YWRkcmVzc2VzLiBJdCBzZWVtcyB1bm5lY2Vzc2FyeSB0byBkbyBpdCBhZ2FpbiBoZXJlLg0KDQpU
aGVyZSBpcyBhIGtleSByZXF1aXJlbWVudCB0byBpbXBsZW1lbnRlcnMgdGhlcmU6IGRvIG5vdCBw
aWNrIGEgc3RhdGljIHZhbHVlIGF0IGJvb3QgdGltZSwgYnV0IGluc3RlYWQgYWx3YXlzIGNoZWNr
IHdoZXRoZXIgaXQgaGFzIGNoYW5nZWQuIEJ1dCBJIHN1cHBvc2Ugd2UgY291bGQgc3VwcHJlc3Mg
dGhlIG1pZGRsZSBzZW50ZW5jZSBvZiB0aGUgMm5kIHBhcmFncmFwaC4gDQoNCj4gLTMuNSwgMm5k
IHRvIGxhc3QgcGFyYWdyYXBoOg0KPiDigJxiYXNlZCBzb2xlbHnigJ0gc2VlbXMgYW1iaWd1b3Vz
LiBEbyBJIHVuZGVyc3RhbmQgY29ycmVjdGx5IHRoYXQgdGhpcyBtZWFucw0KPiB0aGUgY2xpZW50
IE1VU1QgTk9UIHVzZSBjbGllbnQgaWRlbnRpZmllcnMgdGhhdCBwZXJzaXN0IGFjcm9zcyBjaGFu
Z2VzIGluIHRoZQ0KPiBsaW5rIGxheWVyIGFkZHJlc3M/DQoNCiJiYXNlZCBzb2xlbHkiIGlzIGEg
ZGVsaWJlcmF0ZSByZXBlYXQgb2YgdGhlIHRleHQgaW4gUkZDIDQzNjEsIGV4cGxhaW5pbmcgdGhh
dCB3ZSByZWNvbW1lbmQgZXhhY3RseSB3aGF0IFJGQyA0MzYxIHJlY29tbWVuZHMgYWdhaW5zdC4g
DQoNCj4gVGhlIGFzc2VydGlvbiB0aGF0IHRoaXMgd2lsbCBlbnN1cmUgdGhhdCBubyBwcml2YWN5
IGxlYWtzIG9jY3VyIHNlZW1zDQo+IG92ZXJzdGF0ZWQuIEkgc3VzcGVjdCB0aGVyZSBhcmUgb3Ro
ZXIgd2F5cyBjbGllbnRzIGNhbiBsZWFrIHByaXZhdGUNCj4gaW5mb3JtYXRpb24uDQoNClRoZSB0
ZXh0IGRvZXMgbm90IHNheSAibm8gcHJpdmFjeSBsZWFrLCIgaXQgaXMgbW9yZSBjYXV0aW91cyB0
aGFuIHRoYXQuIEJ1dCB5ZXMsIHdlIGNvdWxkIGJlIG1vcmUgc3BlY2lmaWMsIHNheSDigJ13aWxs
IG5vdCBiZSBudWxsaWZpZWQgYnkgdGhlIENsaWVudCBJZGVudGlmaWVyIE9wdGlvbiIgaW5zdGVh
ZCBvZiAid2lsbCBub3QgYmUgbnVsbGlmaWVkIGJ5IERIQ1Agb3B0aW9ucy4iDQoNCj4gLSAzLjY6
DQo+IFRoZSBndWlkYW5jZSBvbiBvcmRlcmluZyBzZWVtcyByZWR1bmRhbnQgd2l0aCAzLjEuDQoN
Ckl0IGlzIGFjdHVhbGx5IGRpZmZlcmVudC4gMy4xIGRlc2NyaWJlIHRoZSBhcnJhbmdlbWVudCBv
ZiB0aGUgdmFyaW91cyBvcHRpb25zIGluIHRoZSBtZXNzYWdlLCAzLjYgZGVzY3JpYmVzIHRoZSBh
cnJhbmdlbWVudCBvZiB0aGUgcmVxdWVzdGVkIG9wdGlvbiBudW1iZXJzIGluc2lkZSB0aGUgUFJM
IG9wdGlvbi4NCg0KPiAtIDMuOSwgMm5kIHBhcmFncmFwaCwgbGFzdCBzZW50ZW5jZTogIklmIG9u
bHkgZm9yIHByaXZhY3kgcmVhc29ucy4uLiINCj4gSSBzdWdnZXN0IHJlbW92aW5nIHRoZSBjbGF1
c2UuIEl0IHdlYWtlbnMgdGhlIGZvbGxvd2luZyBub3JtYXRpdmUNCj4gcmVxdWlyZW1lbnQuDQoN
Ck9LLg0KDQo+IC0gNC41LCBmaXJzdCBwYXJhZ3JhcGg6ICJpbmRlbXRpZmllZCINCj4gaWRlbnRp
ZmllZD8NCg0KWWVzLg0KDQpUaGFua3MgZm9yIHRoZSBmZWVkYmFjayENCg0KLS0gQ2hyaXN0aWFu
IEh1aXRlbWENCg0KDQoNCg0K


From nobody Fri Feb 19 13:50:37 2016
Return-Path: 
X-Original-To: dhcwg@ietfa.amsl.com
Delivered-To: dhcwg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F30C1B3423; Fri, 19 Feb 2016 13:50:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.002
X-Spam-Level: 
X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] 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 RvrDdh9qZ8LX; Fri, 19 Feb 2016 13:50:29 -0800 (PST)
Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0105.outbound.protection.outlook.com [65.55.169.105]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB08D1B3439; Fri, 19 Feb 2016 13:50:28 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=eC3stUI9YUeu5+fY75zGzhpUA4gKa0WnUAn2MgGdUqM=; b=UFHlmvXc1ftoiyJrnR5ANITpWpY2tRsxF6cjPZPb4j3y3rtnoL0PO7sU1oUr8vt+q2VuI+8ZEoNJGabJMai1FetejZzU4cW/TFu1EE7s2zaqaVJ32SA+P1a7Su+jeRHPRO5DeHzLZ+kcTUhsqm3sNqcW/vbBvEgv9PBeqGnBUMA=
Received: from DM2PR0301MB0655.namprd03.prod.outlook.com (10.160.96.17) by DM2PR0301MB0654.namprd03.prod.outlook.com (10.160.96.16) with Microsoft SMTP Server (TLS) id 15.1.409.15; Fri, 19 Feb 2016 21:50:25 +0000
Received: from DM2PR0301MB0655.namprd03.prod.outlook.com ([10.160.96.17]) by DM2PR0301MB0655.namprd03.prod.outlook.com ([10.160.96.17]) with mapi id 15.01.0409.017; Fri, 19 Feb 2016 21:50:25 +0000
From: Christian Huitema 
To: Alissa Cooper , The IESG 
Thread-Topic: Alissa Cooper's Yes on draft-ietf-dhc-anonymity-profile-07: (with COMMENT)
Thread-Index: AQHRacZxDTRaHnuRC0a/Iv6IJ2DGOZ8z5hkA
Date: Fri, 19 Feb 2016 21:50:25 +0000
Message-ID: 
References: <20160217210157.24922.8163.idtracker@ietfa.amsl.com>
In-Reply-To: <20160217210157.24922.8163.idtracker@ietfa.amsl.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: cooperw.in; dkim=none (message not signed) header.d=none;cooperw.in; dmarc=none action=none header.from=microsoft.com;
x-originating-ip: [2001:4898:80e8:e::409]
x-ms-office365-filtering-correlation-id: ca624dfe-a210-48f8-2662-08d33976acdb
x-microsoft-exchange-diagnostics: 1; DM2PR0301MB0654; 5:4a6jju3T/24+m5KLQ9Os4IAxrZDL9j4Z/JoX95Lw/EKAKd0SivGY0oje+vGDe8CIWe1dN4gjC8jZw51Gr13AnUdKY8ZKrJynnv8P+QTI92x85dkg6ByRDlMouEGtDnazbTUkgAzRePwkktPYs6RsLA==; 24:8Tryaqou5nXqHiW66b5KzSzJHGYfHjhW3pXclcZf4V1xuTsKCiH7KgZPWJuz09nVjODMJXwKynGg+FNp7q0+eKX1EfQj9ibmt3PqAU50iBo=
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR0301MB0654;
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(61426038)(61427038); SRVR:DM2PR0301MB0654; BCL:0; PCL:0; RULEID:; SRVR:DM2PR0301MB0654; 
x-forefront-prvs: 08572BD77F
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(377454003)(24454002)(5008740100001)(11100500001)(5003600100002)(3280700002)(33656002)(5001770100001)(74316001)(230783001)(1096002)(5002640100001)(1220700001)(87936001)(76176999)(122556002)(50986999)(5005710100001)(189998001)(106116001)(10400500002)(586003)(5001960100002)(102836003)(40100003)(86362001)(10290500002)(76576001)(92566002)(99286002)(2906002)(3660700001)(77096005)(5004730100002)(2950100001)(8990500004)(4326007)(54356999)(2900100001)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR0301MB0654; H:DM2PR0301MB0655.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; 
spamdiagnosticoutput: 1:23
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Feb 2016 21:50:25.4433 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0301MB0654
Archived-At: 
Cc: "dhc-chairs@ietf.org" , "JuanCarlos.Zuniga@InterDigital.com" , "volz@cisco.com" , "draft-ietf-dhc-anonymity-profile@ietf.org" , "dhcwg@ietf.org" 
Subject: Re: [dhcwg] Alissa Cooper's Yes on draft-ietf-dhc-anonymity-profile-07: (with COMMENT)
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 19 Feb 2016 21:50:32 -0000

T24gV2VkbmVzZGF5LCBGZWJydWFyeSAxNywgMjAxNiAxOjAyIFBNLCBBbGlzc2EgQ29vcGVyIHdy
b3RlOg0KPiAuLi4NCj4gDQo+IFRoaXMgZG9jdW1lbnQgc2VlbXMgdG8gdXNlIHRoZSB0ZXJtICJs
aW5rLWxheWVyIGFkZHJlc3MgcmFuZG9taXphdGlvbiIgdG8NCj4gZGVzY3JpYmUgdGhlIHNpdHVh
dGlvbiB3aGVyZSBhIGxpbmstbGF5ZXIgYWRkcmVzcyBpcyByYW5kb21seSBnZW5lcmF0ZWQgQU5E
DQo+IGNoYW5nZXMgb3ZlciB0aW1lLiBXaGlsZSB0aGlzIHNlZW1zIHRoZSBsaWtlbHkgd2F5IHRo
YXQgc3VjaCBhZGRyZXNzZXMgbWF5DQo+IGJlIHN0YW5kYXJkaXplZCBpbiB0aGUgZnV0dXJlLCBp
dCdzIG5vdCBndWFyYW50ZWVkLiBBbiBhZGRyZXNzIGNvdWxkIGJlDQo+IHJhbmRvbWx5IGdlbmVy
YXRlZCAob3Igb3RoZXJ3aXNlIHNlbWFudGljYWxseSBvcGFxdWUsIGUuZy4gbm90IGNvbnRhaW5p
bmcNCj4gYW4gT1VJKSBidXQgcGVybWFuZW50IGZvciB0aGUgbGlmZSBvZiB0aGUgZGV2aWNlL2lu
dGVyZmFjZSwgaW4gd2hpY2ggY2FzZSB0aGUNCj4gcHJpdmFjeSBiZW5lZml0cyBvZiB3aGF0IGlz
IHNwZWNpZmllZCBpbiB0aGlzIGRyYWZ0IGFyZSBub3QgdGhlIHNhbWUuIFRoZXJlZm9yZQ0KPiBJ
IHRoaW5rIGl0J3Mgd29ydGggZXhwbGljaXRseSBzdGF0aW5nIHRoZSBpbnRlcnByZXRhdGlvbiBv
ZiAicmFuZG9tIGFkZHJlc3MiIHRoYXQNCj4gaXMgYmVpbmcgdXNlZCBoZXJlLg0KDQpXb3VsZCB5
b3UgYWRkIHNvbWV0aGluZyB0byBzZWN0aW9uIDIuMSwgTUFDIGFkZHJlc3MgUmFuZG9taXphdGlv
biBoeXBvdGhlc2VzPw0KDQo+ID0gU2VjdGlvbiAxID0NCj4gDQo+IHMvUmVwb3J0cyBzdXJmYWNl
ZCByZWNlbnRseS9UaGVyZSBoYXZlIGJlZW4gcmVwb3J0cy8NCg0KT0suDQoNCj4gPSBTZWN0aW9u
IDIgPQ0KPiANCj4gV291bGQgYmUgZ29vZCB0byB1cGRhdGUgdGhlIHJlZmVyZW5jZXMgdG8gd29y
ayBnb2luZyBvbiBpbiBJRUVFIDgwMi4xLg0KPiBBbHNvIHRoZXJlIHdlcmUgZXhwZXJpbWVudHMg
YXQgbXVsdGlwbGUgSUVFRSBhbmQgSUVURiBtZWV0aW5ncy4NCg0KWWVzLCB3aWxsIGFkZCBhIHJl
ZmVyZW5jZSB0byB0aGUgSUVFRSB3b3JrLg0KDQo+ID0gU2VjdGlvbiAzID0NCj4gDQo+IFNlY3Rp
b24gMy4xIHNheXM6DQo+IA0KPiAiVGhlIGNsaWVudCB3aWxsaW5nIHRvIHByb3RlY3QgaXRzIHBy
aXZhY3kgU0hPVUxEIGxpbWl0IHRoZSBzdWJzZXQgb2YNCj4gICAgb3B0aW9ucyBzZW50IGluIG1l
c3NhZ2VzIHRvIHRoZSBzdWJzZXQgbGlzdGVkIGluIHRoZSBmb2xsb3dpbmcNCj4gICAgc2VjdGlv
bnMuIg0KPiANCj4gVGhlbiBhbGwgdGhlIHN1YnNlY3Rpb25zIGRpc2N1c3Mgc3BlY2lmaWMgb3B0
aW9ucyBhbmQgY29uc2lkZXJhdGlvbnMgZm9yIHVzaW5nDQo+IHRoZW0sIGV4Y2VwdCAzLjksIHdo
aWNoIGJhc2ljYWxseSBzYXlzICJkb24ndCB1c2UgdGhlc2UuIiBJIHdvdWxkIGFzc3VtZQ0KPiB0
aGVyZSBhcmUgYSBidW5jaCBvZiBvdGhlciBvcHRpb25zIHRoYXQgY2xpZW50cyBkZWZpbml0ZWx5
IHNob3VsZG4ndCB1c2UgaWYgdGhleQ0KPiB3YW50IHRvIG1haW50YWluIGFub255bWl0eSAoSSB3
YXMgdGhpbmtpbmcgb2YgMTIzIGFuZCAxNDQsIGdlb2xvY2F0aW9uKS4gU28NCj4gd2h5IGFyZSBv
bmx5IHRoZSBQWEUgb3B0aW9ucyBtZW50aW9uZWQgaGVyZSwgd2hlbiB0aGUgdGV4dCBpbiAzLjEg
c2VlbWVkDQo+IHRvIGJlIHNheWluZyB0aGF0IGNsaWVudHMgc2hvdWxkIGF2b2lkIGFsbCBvdGhl
ciBvcHRpb25zIG5vdCBtZW50aW9uZWQ/DQoNClRoZSByZWFsIHJlcXVpcmVtZW50IGlzICJkbyBu
b3QgYWR2ZXJ0aXNlIHVuaXF1ZSBpZGVudGlmaWVycyBvciBwcmV2aW91c2x5IGFzc2lnbmVkIHBh
cmFtZXRlcnMuIiBXZSBzY3J1dGluaXplZCB0aGUgb3B0aW9ucyB0aGF0IGRpZCB0aGF0LCBhbmQg
UFhFIGlzIG9uZSBvZiB0aGVtLiBBbmQgd2UgbGltaXQgdGhlIGxpc3Qgb2Ygb3B0aW9ucyBhbmQg
dmFsdWVzIHRoYXQgY2FuIGJlIGluc2VydGVkIGluIGNsaWVudCBtZXNzYWdlcy4gQnV0IHdlIGRv
IG5vdCBsaW1pdCB0aGUgbnVtYmVyIG9mIG9wdGlvbnMgdGhhdCBjYW4gYmUgcmVxdWVzdGVkIGJ5
IHRoZSBjbGllbnRzLg0KDQpUaGUgZHJhZnQgZG9lcyBub3QgcHJlY2x1ZGUgYWRkaW5nIHJlcXVl
c3QgY29kZXMgaW4gdGhlIFBhcmFtZXRlciBSZXF1ZXN0IExpc3QuIFJGQyA2MjI1IHNheXMgIkRI
Q1B2NCBjbGllbnRzIHJlcXVlc3QgdGhlIERIQ1B2NCBzZXJ2ZXIgdG8gc2VuZCBHZW9Db25mIE9w
dGlvbiAxMjMsIEdlb0xvYyBPcHRpb24gMTQ0LCBvciBib3RoIHZpYSBpbmNsdXNpb24gb2YgdGhl
IFBhcmFtZXRlciBSZXF1ZXN0IExpc3Qgb3B0aW9uLiIgVGhhdCdzIGZpbmUuIFRoZSBjbGllbnQg
aXMgbm90IGRpc2Nsb3NpbmcgYW55dGhpbmcsIGV4Y2VwdCBpdHMgd2lsbGluZ25lc3MgdG8gcmVh
ZCB0aGUgaW5mb3JtYXRpb24gcHJvdmlkZWQgYnkgdGhlIHNlcnZlci4gDQoNClRoZSBtYWluIGlz
c3VlIGlzIHRoYXQgdGhlIGdlb2xvYyBvcHRpb24gdmFsdWVzIGNhbiBiZSBzZW50IGJhY2sgYnkg
dGhlIHNlcnZlciBpbiBjbGVhciB0ZXh0LCBhbmQgdGh1cyBtb25pdG9yZWQuIE1vbml0b3Jpbmcg
anVzdCB0aGUgbG9jYWwgbGluayB3aWxsIHJldmVhbCB0aGUgbG9jYXRpb24gb2YgdGhlIGxvY2Fs
IGxpbmssIHdoaWNoIGlzIG5vdCB0aGF0IGJpZyBhIGRlYWwuIE1vbml0b3JpbmcgaGFwcGVucyBi
ZXR3ZWVuIGEgcHJveHkgYW5kIGEgY2VudHJhbGl6ZWQgc2VydmVyIGlzIG9mIGNvdXJzZSBtb3Jl
ICJpbnRlcmVzdGluZy4iIEJ1dCB0aGUgYW5vbnltaXR5IHByb2ZpbGUgcHJvdmlkZXMgYSBtaXRp
Z2F0aW9uIGFnYWluc3QgYm90aDogc3VyZSwgdGhlIG1vbml0b3IgY2FuIHJlYWQgdGhlIGdlb2xv
YyBpbmZvcm1hdGlvbjsgYnV0IHNpbmNlIHRoZSBkZXZpY2UgaXMgYW5vbnltb3VzLCB0aGUgbW9u
aXRvciBkb2VzIG5vdCBrbm93IHdobyB0cmF2ZWxsZWQgYXQgdGhhdCBsb2NhdGlvbi4NCg0KLS0g
Q2hyaXN0aWFuIEh1aXRlbWENCg0KDQoNCg0K


From nobody Fri Feb 19 17:06:28 2016
Return-Path: 
X-Original-To: dhcwg@ietf.org
Delivered-To: dhcwg@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 677A71A0378; Fri, 19 Feb 2016 17:06:27 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: 
X-Test-IDTracker: no
X-IETF-IDTracker: 6.14.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20160220010627.26943.29619.idtracker@ietfa.amsl.com>
Date: Fri, 19 Feb 2016 17:06:27 -0800
Archived-At: 
Cc: dhcwg@ietf.org
Subject: [dhcwg] I-D Action: draft-ietf-dhc-anonymity-profile-08.txt
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.15
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 20 Feb 2016 01:06:27 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Dynamic Host Configuration of the IETF.

        Title           : Anonymity profile for DHCP clients
        Authors         : Christian Huitema
                          Tomek Mrugalski
                          Suresh Krishnan
	Filename        : draft-ietf-dhc-anonymity-profile-08.txt
	Pages           : 28
	Date            : 2016-02-19

Abstract:
   Some DHCP options carry unique identifiers.  These identifiers can
   enable device tracking even if the device administrator takes care of
   randomizing other potential identifications like link-layer addresses
   or IPv6 addresses.  The anonymity profile is designed for clients
   that wish to remain anonymous to the visited network.  The profile
   provides guidelines on the composition of DHCP or DHCPv6 requests,
   designed to minimize disclosure of identifying information.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dhc-anonymity-profile/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-dhc-anonymity-profile-08

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-dhc-anonymity-profile-08


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From nobody Sun Feb 21 18:00:17 2016
Return-Path: 
X-Original-To: dhcwg@ietf.org
Delivered-To: dhcwg@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 279321B2B97; Sun, 21 Feb 2016 18:00:15 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: 
X-Test-IDTracker: no
X-IETF-IDTracker: 6.14.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20160222020015.22585.66775.idtracker@ietfa.amsl.com>
Date: Sun, 21 Feb 2016 18:00:15 -0800
Archived-At: 
Cc: dhcwg@ietf.org
Subject: [dhcwg] I-D Action: draft-ietf-dhc-dhcp-privacy-05.txt
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.15
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 22 Feb 2016 02:00:15 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Dynamic Host Configuration of the IETF.

        Title           : Privacy considerations for DHCP
        Authors         : Suresh Krishnan
                          Tomek Mrugalski
                          Sheng Jiang
	Filename        : draft-ietf-dhc-dhcp-privacy-05.txt
	Pages           : 14
	Date            : 2016-02-21

Abstract:
   DHCP is a protocol that is used to provide addressing and
   configuration information to IPv4 hosts.  This document discusses the
   various identifiers used by DHCP and the potential privacy issues.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dhc-dhcp-privacy/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-dhc-dhcp-privacy-05

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-dhc-dhcp-privacy-05


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From nobody Sun Feb 21 18:18:22 2016
Return-Path: 
X-Original-To: dhcwg@ietfa.amsl.com
Delivered-To: dhcwg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B5091B2B4F for ; Sun, 21 Feb 2016 18:18:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.384
X-Spam-Level: 
X-Spam-Status: No, score=-1.384 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=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 lgjlbmOMhaHt for ; Sun, 21 Feb 2016 18:18:13 -0800 (PST)
Received: from mail-yk0-x231.google.com (mail-yk0-x231.google.com [IPv6:2607:f8b0:4002:c07::231]) (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 3C59B1B2B5B for ; Sun, 21 Feb 2016 18:18:11 -0800 (PST)
Received: by mail-yk0-x231.google.com with SMTP id r207so56787827ykd.2 for ; Sun, 21 Feb 2016 18:18:11 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=ZRHExFtdvtw5WP25XoAmaIQJn7YB3TWd3mq3+e6xxjc=; b=W/7ymCjHsFtacXMIimYxkGX7T0THNWmXzOhRyugt0KD6ibNglN9ykjDayavdp9Yfrt k2nNhvVglV9XniZ0jBTnfLsadpkjYA/JMWSeoeUnp1HI1/7vI4M0Ag/Scz+zQc2RgJxe rW0tiCLYzjerDtgXzhpA/vf6DePi/RB+hRoDitr3ENO+6RM4a0TFu6khQvJf/Gux2xFz 6ARbBdn5seql9GrN+Ln4LYdpYoBtnx3D0AnfJXj7+FCyT9xuDY4qEJdW7ENMsVmtZnHt g70wC6RJvWKA4RJ7ilsHa2ETQC0U6n1OWF0N4antkdcyxGqXHJZ9sLFean3fWiYekb1N 101w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=ZRHExFtdvtw5WP25XoAmaIQJn7YB3TWd3mq3+e6xxjc=; b=CTOAHOJDbx8Qj5ozw3lU404/l+hGxjXcT21ywxPGTz0cEjf0iWSk8NOqOAuv7A5JaU wgZMUN5P+dszuXEpTbhxpsT1hzElqe3zDjlnECqAmxJoPLV1cHDc/iKqbXgZ/6lvp3vk PlpfHyGZ2hWrWJsVmt1WLCs1qKwDYN2loSsxtKapNCLuzqMJwW2RvGWbu9RDJVRvCLmQ VnEI3AImAhPILRRfHbyD2eMMdrWkgPGSe+PGF02tS0L04PgXiQWXlrM1Omzv9C/Tshls gxcHGM/PryoCOXA2dElFr60Q7VAFayr+8ghWkrnOG1FjbPguVu99radzjpos5rXpUMnC 05dA==
X-Gm-Message-State: AG10YOTfK3C10nTx9Yoyoid7nozKtBONO45nm97NKBy8rHhPceP6BQqfONHCAm1uGA1jEmIVqeLKXle0E6cZfHl6
X-Received: by 10.37.65.211 with SMTP id o202mr2119685yba.185.1456107490292; Sun, 21 Feb 2016 18:18:10 -0800 (PST)
MIME-Version: 1.0
Received: by 10.37.19.65 with HTTP; Sun, 21 Feb 2016 18:17:50 -0800 (PST)
In-Reply-To: <56C3161F.3070301@innovationslab.net>
References: <20160201142413.30288.23248.idtracker@ietfa.amsl.com>  <003001d1687a$926ab2e0$b74018a0$@huitema.net> <56C3161F.3070301@innovationslab.net>
From: Lorenzo Colitti 
Date: Mon, 22 Feb 2016 11:17:50 +0900
Message-ID: 
To: Brian Haberman 
Content-Type: multipart/alternative; boundary=001a11c00034b73625052c5271d2
Archived-At: 
Cc: IETF Discussion , dhc-chairs@ietf.org, Christian Huitema , iesg@ietf.org, draft-ietf-dhc-anonymity-profile@ietf.org, "dhcwg@ietf.org" 
Subject: Re: [dhcwg] Last Call:  (Anonymity profile for DHCP clients) to Proposed Standard
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 22 Feb 2016 02:18:15 -0000

--001a11c00034b73625052c5271d2
Content-Type: text/plain; charset=UTF-8

On Tue, Feb 16, 2016 at 9:29 PM, Brian Haberman 
wrote:

> > Well, section 4 of draft-ietf-dhc-anonymity-profile-07 says:
> >
> >    The choice between the stateful and stateless scenarios depends on
> >    flag and prefix options published by the "Router Advertisement"
> >    messages of local routers, as specified in [RFC4861].  When these
> >    options enable stateless address configuration hosts using the
> >    anonymity profile SHOULD choose it over stateful address
> >    configuration, because stateless configuration requires fewer
> >    information disclosures than stateful configuration.
> >
> > That seems pretty close from what you want, at least as far as "stateful
> DHCPv6" is concerned.
>
> I would agree that the above text covers what I interpret as Lorenzo's
> concern.
>

My concern is not with the intent, it's with the wording.

The business of this draft is to provide guidance to implementers. I am an
implementer: I wrote the DHCP client currently used in a host OS, and while
said OS does not yet support DHCPv6, I am likely to involved with that as
well if/when that happens. So I am squarely in the target audience for this
document - but as has become clear from this thread, I did not understand
the text correctly, even though I was actually paying attention It took a
specific response from Christian and an explanation from a colleague before
I actually understood what the implications were for host behaviour. We
should try to ensure other implementers do not misunderstand the text like
I did, by making it clearer.

Let me suggest text again:

   When these options enable stateless address configuration (i.e., when
   the A flag in a Prefix Information Option is set to 1) hosts using the
   anonymity profile SHOULD perform stateless address configuration
   and SHOULD NOT use stateful DHCPv6, because stateless configuration

I don't see how that text is different from the text that's already in the
draft, except it actually provides clear guidance. Why not use it?

--001a11c00034b73625052c5271d2
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


On T=
ue, Feb 16, 2016 at 9:29 PM, Brian Haberman <brian@innovationslab=
.net> wrote:
> Well, =
section 4 of draft-ietf-dhc-anonymity-profile-07 says:

>

>=C2=A0 =C2=A0 The choice between the stateful and stateless scenarios d=
epends on

>=C2=A0 =C2=A0 flag and prefix options published by the "Router Adv=
ertisement"

>=C2=A0 =C2=A0 messages of local routers, as specified in [RFC4861].=C2=
=A0 When these

>=C2=A0 =C2=A0 options enable stateless address configuration hosts usin=
g the

>=C2=A0 =C2=A0 anonymity profile SHOULD choose it over stateful address<=
br>
>=C2=A0 =C2=A0 configuration, because stateless configuration requires f=
ewer

>=C2=A0 =C2=A0 information disclosures than stateful configuration.

>

> That seems pretty close from what you want, at least as far as "s=
tateful DHCPv6" is concerned.



I would agree that the above text covers what I interpret as Lorenzo=
's

concern.

My concern is not with the int=
ent, it's with the wording.

The business of th=
is draft is to provide guidance to implementers. I am an implementer: I wro=
te the DHCP client currently used in a host OS, and while said OS does not =
yet support DHCPv6, I am likely to involved with that as well if/when that =
happens. So I am squarely in the target audience for this document - but as=
 has become clear from this thread, I did not understand the text correctly=
, even though I was actually paying attention It took a specific response f=
rom Christian and an explanation from a colleague before I actually underst=
ood what the implications were for host behaviour. We should try to ensure =
other implementers do not misunderstand the text like I did, by making it c=
learer.

Let me suggest text again:

<=
/div>
=C2=A0 =C2=A0When these options enable stateless address con=
figuration (i.e., when
=C2=A0 =C2=A0the A flag in a Prefix Inform=
ation Option is set to 1) hosts using the
=C2=A0 =C2=A0anonymity =
profile SHOULD perform stateless address configuration
=C2=A0 =C2=
=A0and SHOULD NOT use stateful DHCPv6, because stateless configuration

I don't see how that text is different from =
the text that's already in the draft, except it actually provides clear=
 guidance. Why not use it?


--001a11c00034b73625052c5271d2--


From nobody Sun Feb 21 22:33:19 2016
Return-Path: 
X-Original-To: dhcwg@ietfa.amsl.com
Delivered-To: dhcwg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58E131B3593 for ; Sun, 21 Feb 2016 22:33:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.384
X-Spam-Level: 
X-Spam-Status: No, score=-1.384 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=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 4_JYNYbKIRhU for ; Sun, 21 Feb 2016 22:33:15 -0800 (PST)
Received: from mail-yk0-x235.google.com (mail-yk0-x235.google.com [IPv6:2607:f8b0:4002:c07::235]) (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 AE1A61B3596 for ; Sun, 21 Feb 2016 22:33:14 -0800 (PST)
Received: by mail-yk0-x235.google.com with SMTP id r207so58345334ykd.2 for ; Sun, 21 Feb 2016 22:33:14 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=t+qgZsdp5QMZcf8aYIeuUVZkVKaQnt9WKZPJPQm1gxA=; b=CIGI6QZpJ8YsSWVuphOR6wKdcMunqi3wUAG6qZxeVOhlov9zVNsv3QqocvPB3YCiSv rm8r2QY8JBelYsiG3R24ppX5LLWgtf7wRJ5Ldm4U8Y2qH/Wq9lOCjmtlP1cQnmOAz+c0 zdbVQU8WaVBu0MzLDkFRAH0xlJWKBPDLq6QsNDzW28BVMymHIamLs5qzXAMlVKhEptWz S0KTpLsxxcrM2650aZX7GJsHioGhoJIdHoGG3GW0fkpLUo6VOvEAeA4dNUxpRrtVakDd EoAExmSKaKi3Tqu915XtfnjpmbInqTDgSKedRjgfE7PD23S1A3cVbdUPL+67d+DGPzWP 9BDA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=t+qgZsdp5QMZcf8aYIeuUVZkVKaQnt9WKZPJPQm1gxA=; b=Q+AavBSejFehX4gjLKnpDzpdvLoAQue0rXuXN9JxcEf0cptCHJNiY8ANSuqK7w5zQn c/BiqNEhHWeaFQhvxPVWQruHDrAhb7uJPj7CnyCPm2G158VD+D/c7a5oV2jzO5B2McI0 mcaxAYbnMrPGdJVVkQNHo1M2rULLCg8tWHjh4ttnvPMgzISEOJbjHkA8LmhkA/WA8dM0 pWkrvPfa6FRlDfKP7BEKkskUnUvh2eHvjiqrpLvGWgGTYzK1PXHVTrPvuU70Rt10tMLj S63nx4duU2o7dqgs+R28s6lVgs8wsUVcZRfjGpXsqPG5uR8rn19PHPDFLC7K8w8/FaWC 887A==
X-Gm-Message-State: AG10YOSnXEHV3/38thiULqQw/Na+/+6Q8A8gd8+gO8CEVHxLi/RI/pKHV42KApdJBQBBGq+Pk++MeDJfKNn8dZTu
X-Received: by 10.37.2.150 with SMTP id 144mr10668454ybc.44.1456122793805; Sun, 21 Feb 2016 22:33:13 -0800 (PST)
MIME-Version: 1.0
Received: by 10.37.19.65 with HTTP; Sun, 21 Feb 2016 22:32:54 -0800 (PST)
In-Reply-To: 
References: <20160201142413.30288.23248.idtracker@ietfa.amsl.com>  <003001d1687a$926ab2e0$b74018a0$@huitema.net> <56C3161F.3070301@innovationslab.net> 
From: Lorenzo Colitti 
Date: Mon, 22 Feb 2016 15:32:54 +0900
Message-ID: 
To: Brian Haberman 
Content-Type: multipart/alternative; boundary=001a113d43d0e061f1052c560150
Archived-At: 
Cc: IETF Discussion , dhc-chairs@ietf.org, Christian Huitema , iesg@ietf.org, draft-ietf-dhc-anonymity-profile@ietf.org, "dhcwg@ietf.org" 
Subject: Re: [dhcwg] Last Call:  (Anonymity profile for DHCP clients) to Proposed Standard
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 22 Feb 2016 06:33:16 -0000

--001a113d43d0e061f1052c560150
Content-Type: text/plain; charset=UTF-8

On Mon, Feb 22, 2016 at 11:17 AM, Lorenzo Colitti 
wrote:
>
> I don't see how that text is different from the text that's already in the
> draft, except it actually provides clear guidance. Why not use it?
>

Christian pointed out that this text has been revised in -08. When I read
the new text, "When these options enable stateless address configuration
hosts using the anonymity profile SHOULD use stateless address
configuration instead of stateful address configuration", as an implementer
I know what to do. Thank you.

--001a113d43d0e061f1052c560150
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


On M=
on, Feb 22, 2016 at 11:17 AM, Lorenzo Colitti <lorenzo@google.com>=
 wrote:
=

I don't see how that text is different =
from the text that's already in the draft, except it actually provides =
clear guidance. Why not use it?



Christian pointed o=
ut that this text has been revised in -08. When I read the new text, "=
When these options enable stateless address configuration hosts using the a=
nonymity profile SHOULD use stateless address configuration instead of stat=
eful address configuration", as an implementer I know what to do. Than=
k you.


--001a113d43d0e061f1052c560150--


From nobody Mon Feb 22 11:54:03 2016
Return-Path: 
X-Original-To: dhcwg@ietf.org
Delivered-To: dhcwg@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F7861A0181; Mon, 22 Feb 2016 11:54:01 -0800 (PST)
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: The IESG 
To: "IETF-Announce" 
X-Test-IDTracker: no
X-IETF-IDTracker: 6.14.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20160222195401.4690.83346.idtracker@ietfa.amsl.com>
Date: Mon, 22 Feb 2016 11:54:01 -0800
Archived-At: 
Cc: draft-ietf-dhc-dhcp-privacy@ietf.org, volz@cisco.com, dhc-chairs@ietf.org, The IESG , dhcwg@ietf.org, rfc-editor@rfc-editor.org
Subject: [dhcwg] Document Action: 'Privacy considerations for DHCP' to Informational RFC (draft-ietf-dhc-dhcp-privacy-05.txt)
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.15
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 22 Feb 2016 19:54:01 -0000

The IESG has approved the following document:
- 'Privacy considerations for DHCP'
  (draft-ietf-dhc-dhcp-privacy-05.txt) as Informational RFC

This document is the product of the Dynamic Host Configuration Working
Group.

The IESG contact persons are Brian Haberman and Terry Manderson.

A URL of this Internet Draft is:
https://datatracker.ietf.org/doc/draft-ietf-dhc-dhcp-privacy/




Technical Summary: 

This document describes the privacy issues associated with the use of
DHCPv4 (RFC 2131).


Working Group Summary: 

This document analyzes the privacy issues associated with the use of
DHCPv4.

Document Quality: 

This document has had thorough reviews by many interested and
knowledgeable folks (beyond those mentioned in the acknowledgements
section). There were no significant points of difficulty or
controversy with the contents of the document.

Personnel: 

Bernie Volz is the document shepherd. Brian Haberman is the responsible AD. 


From nobody Mon Feb 22 14:21:22 2016
Return-Path: 
X-Original-To: dhcwg@ietfa.amsl.com
Delivered-To: dhcwg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADA291B2C48; Mon, 22 Feb 2016 14:21:15 -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, SPF_PASS=-0.001] 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 CT2arz3AvrEV; Mon, 22 Feb 2016 14:21:13 -0800 (PST)
Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 30C381B2C51; Mon, 22 Feb 2016 14:21:12 -0800 (PST)
Received: from [192.168.3.107] (unknown [181.165.125.191]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 32ED88017A; Mon, 22 Feb 2016 23:21:05 +0100 (CET)
To: Lorenzo Colitti , Brian Haberman 
References: <20160201142413.30288.23248.idtracker@ietfa.amsl.com>  <003001d1687a$926ab2e0$b74018a0$@huitema.net> <56C3161F.3070301@innovationslab.net> 
From: Fernando Gont 
X-Enigmail-Draft-Status: N1110
Message-ID: <56CB891E.6060902@si6networks.com>
Date: Mon, 22 Feb 2016 19:18:06 -0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: IETF Discussion , dhc-chairs@ietf.org, Christian Huitema , iesg@ietf.org, draft-ietf-dhc-anonymity-profile@ietf.org, "dhcwg@ietf.org" 
Subject: Re: [dhcwg] Last Call:  (Anonymity profile for DHCP clients) to Proposed Standard
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 22 Feb 2016 22:21:15 -0000

On 02/21/2016 11:17 PM, Lorenzo Colitti wrote:
> Let me suggest text again:
> 
>    When these options enable stateless address configuration (i.e., when
>    the A flag in a Prefix Information Option is set to 1) hosts using the
>    anonymity profile SHOULD perform stateless address configuration
>    and SHOULD NOT use stateful DHCPv6, because stateless configuration
> 
> I don't see how that text is different from the text that's already in
> the draft, except it actually provides clear guidance. Why not use it?

The above text (or any similar text already in the I-D) suggests that
this document should be updating RFC4862. Because it is not only
specifying that to do when you do DHCPv6, but also whether to do
SLAAC/DHCPv6 in the fist place.

Thanks,
-- 
Fernando Gont
SI6 Networks
e-mail: fgont@si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492





From nobody Mon Feb 22 15:52:14 2016
Return-Path: 
X-Original-To: dhcwg@ietfa.amsl.com
Delivered-To: dhcwg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F04341B2C51 for ; Mon, 22 Feb 2016 15:52:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.384
X-Spam-Level: 
X-Spam-Status: No, score=-1.384 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=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 IbLrxcOYDFwP for ; Mon, 22 Feb 2016 15:52:08 -0800 (PST)
Received: from mail-yw0-x234.google.com (mail-yw0-x234.google.com [IPv6:2607:f8b0:4002:c05::234]) (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 0684F1A8907 for ; Mon, 22 Feb 2016 15:52:06 -0800 (PST)
Received: by mail-yw0-x234.google.com with SMTP id h129so133242562ywb.1 for ; Mon, 22 Feb 2016 15:52:05 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=gm6rBmjs6ZRiwi3YFIaLUM+Icd5GgpqOyrFGe4RgsOs=; b=Z+OUM9BEi641mFww68jKNXyECj4NiTNpferi3otTjPFJlHGGwP1wWflakJQKInGhkL BbQDDH0YJUX7hrtxoL3+tV/4c4ZGx/GC00POYpK5fPm5Ois93W55mjr55cBejfwbMvGm 27MDmI8HbJUfF4pHfUIWoLkdP2P1uMdkUtw6IUg/YEwYvKBnbanyV7POfX8pz/Y2P6se IQc7Hp65eaZ/0u2ZRZdykO2JCOWBdUFKGTjYE+emu0sy9kPzFdCeSqtundA0ZxrtFYbu Foq0QQK/A3+0cihU5vMl4Y7rIi1fpJSkxXXDTLVQsCAAnNQRNRKjOmDOt2rRycGH/a5k o1jg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=gm6rBmjs6ZRiwi3YFIaLUM+Icd5GgpqOyrFGe4RgsOs=; b=gFNBEL+XEXYcKVHJOuZMg8vAXlM6APDbHpeqZtCkbHDU1624a/ihXGKlDnXEKjvcgX cu4w8jWTBW3xc5IqmSVMWsinseFaZ1vvc+/r+xK4OygC4/BuXVNE9XH0KThBmQUSXcRV bBoq2NT5mY42uwU6YTAFqn2gLWe422yqCkK8h+60w4Z2rXkgCbFDcqkiT8EazwUpE2b1 grydGkLaB+7+K0zRA5snobf7sSI9H19vq5F3givE4zOEw6OqVu77AJCEKx4NbaeYdlU2 1cmfM7OnOM/FNjYbY2mtLliUbIrhLD8vbXxW+zOLlsrx1W5wS1aidvwXPmbEucJ3JBVv 8S/g==
X-Gm-Message-State: AG10YOTl1S5+RifebdeDZP23sxRHTV5InGXF3Lu2IZnqT9KA4E19TEpHmqMUGClGlDu+gwORGRIun7DDzME7ABHR
X-Received: by 10.13.202.16 with SMTP id m16mr15082507ywd.160.1456185125162; Mon, 22 Feb 2016 15:52:05 -0800 (PST)
MIME-Version: 1.0
Received: by 10.37.19.65 with HTTP; Mon, 22 Feb 2016 15:51:45 -0800 (PST)
In-Reply-To: <56CB891E.6060902@si6networks.com>
References: <20160201142413.30288.23248.idtracker@ietfa.amsl.com>  <003001d1687a$926ab2e0$b74018a0$@huitema.net> <56C3161F.3070301@innovationslab.net>  <56CB891E.6060902@si6networks.com>
From: Lorenzo Colitti 
Date: Tue, 23 Feb 2016 08:51:45 +0900
Message-ID: 
To: Fernando Gont 
Content-Type: multipart/alternative; boundary=001a114f00fa1d4b04052c6485ae
Archived-At: 
Cc: IETF Discussion , dhc-chairs@ietf.org, Christian Huitema , iesg@ietf.org, draft-ietf-dhc-anonymity-profile@ietf.org, "dhcwg@ietf.org" 
Subject: Re: [dhcwg] Last Call:  (Anonymity profile for DHCP clients) to Proposed Standard
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 22 Feb 2016 23:52:09 -0000

--001a114f00fa1d4b04052c6485ae
Content-Type: text/plain; charset=UTF-8

On Tue, Feb 23, 2016 at 7:18 AM, Fernando Gont 
wrote:

> >    When these options enable stateless address configuration (i.e., when
> >    the A flag in a Prefix Information Option is set to 1) hosts using the
> >    anonymity profile SHOULD perform stateless address configuration
> >    and SHOULD NOT use stateful DHCPv6, because stateless configuration
> >
> > I don't see how that text is different from the text that's already in
> > the draft, except it actually provides clear guidance. Why not use it?
>
> The above text (or any similar text already in the I-D) suggests that
> this document should be updating RFC4862. Because it is not only
> specifying that to do when you do DHCPv6, but also whether to do
> SLAAC/DHCPv6 in the fist place.
>

I don't see why. I don't recall a statement in RFC 4862 specifying whether
hosts should use one or the other.

--001a114f00fa1d4b04052c6485ae
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


On T=
ue, Feb 23, 2016 at 7:18 AM, Fernando Gont <fgont@si6networks.com&=
gt; wrote:
>=
=C2=A0 =C2=A0 When these options enable stateless address configuration (i.=
e., when

>=C2=A0 =C2=A0 the A flag in a Prefix Information Option is set to 1) ho=
sts using the

>=C2=A0 =C2=A0 anonymity profile SHOULD perform stateless address config=
uration

>=C2=A0 =C2=A0 and SHOULD NOT use stateful DHCPv6, because stateless con=
figuration

>

> I don't see how that text is different from the text that's al=
ready in

> the draft, except it actually provides clear guidance. Why not use it?=




The above text (or any similar text already in the I-D) suggests tha=
t

this document should be updating RFC4862. Because it is not only

specifying that to do when you do DHCPv6, but also whether to do

SLAAC/DHCPv6 in the fist place.

I don&#=
39;t see why. I don't recall a statement in RFC 4862 specifying whether=
 hosts should use one or the other.


--001a114f00fa1d4b04052c6485ae--


From nobody Mon Feb 22 16:09:15 2016
Return-Path: 
X-Original-To: dhcwg@ietfa.amsl.com
Delivered-To: dhcwg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FC461B3299; Mon, 22 Feb 2016 16:09:10 -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, SPF_PASS=-0.001] 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 yrKJtsvLaYJ7; Mon, 22 Feb 2016 16:09:09 -0800 (PST)
Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5041D1B327C; Mon, 22 Feb 2016 16:09:09 -0800 (PST)
Received: from [192.168.3.107] (unknown [181.165.125.191]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 049F780DB0; Tue, 23 Feb 2016 01:09:03 +0100 (CET)
To: Lorenzo Colitti 
References: <20160201142413.30288.23248.idtracker@ietfa.amsl.com>  <003001d1687a$926ab2e0$b74018a0$@huitema.net> <56C3161F.3070301@innovationslab.net>  <56CB891E.6060902@si6networks.com> 
From: Fernando Gont 
X-Enigmail-Draft-Status: N1110
Message-ID: <56CBA305.1050400@si6networks.com>
Date: Mon, 22 Feb 2016 21:08:37 -0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: IETF Discussion , dhc-chairs@ietf.org, Christian Huitema , iesg@ietf.org, draft-ietf-dhc-anonymity-profile@ietf.org, "dhcwg@ietf.org" 
Subject: Re: [dhcwg] Last Call:  (Anonymity profile for DHCP clients) to Proposed Standard
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 23 Feb 2016 00:09:10 -0000

On 02/22/2016 08:51 PM, Lorenzo Colitti wrote:
> On Tue, Feb 23, 2016 at 7:18 AM, Fernando Gont  > wrote:
> 
>     >    When these options enable stateless address configuration (i.e., when
>     >    the A flag in a Prefix Information Option is set to 1) hosts using the
>     >    anonymity profile SHOULD perform stateless address configuration
>     >    and SHOULD NOT use stateful DHCPv6, because stateless configuration
>     >
>     > I don't see how that text is different from the text that's already in
>     > the draft, except it actually provides clear guidance. Why not use it?
> 
>     The above text (or any similar text already in the I-D) suggests that
>     this document should be updating RFC4862. Because it is not only
>     specifying that to do when you do DHCPv6, but also whether to do
>     SLAAC/DHCPv6 in the fist place.
> 
> 
> I don't see why. I don't recall a statement in RFC 4862 specifying
> whether hosts should use one or the other.

But the authors are making such statement here. i.e., if you are going
to implement SLAAC/DHCPv6, then this statement affects your
implementation. Hence, an appropriate tag should be included (i.e., such
that if I look at RFC4862 or RFC3315, it's clear that I should look at
this document, too).

Thanks,
-- 
Fernando Gont
SI6 Networks
e-mail: fgont@si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492





From nobody Mon Feb 22 16:35:56 2016
Return-Path: 
X-Original-To: dhcwg@ietfa.amsl.com
Delivered-To: dhcwg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27D7F1A6FE7 for ; Mon, 22 Feb 2016 16:35:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.384
X-Spam-Level: 
X-Spam-Status: No, score=-1.384 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=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 jdrk3vG0c5lj for ; Mon, 22 Feb 2016 16:35:53 -0800 (PST)
Received: from mail-io0-x230.google.com (mail-io0-x230.google.com [IPv6:2607:f8b0:4001:c06::230]) (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 2F7131A6F91 for ; Mon, 22 Feb 2016 16:35:53 -0800 (PST)
Received: by mail-io0-x230.google.com with SMTP id 9so198269482iom.1 for ; Mon, 22 Feb 2016 16:35:53 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=Kaa/fPGDUSdm/BE8AoTlWyfQoNl8BqYv6AUK6eVZ65E=; b=mHp3fKYkXHjqMgmes1/mDEKOqxGSCpT4YJgaWXieP1cCYw6QcGQ39A8yIfcu3RNf+x Vo2cjpsohVOhZAGqqwbL509nW52LWUrilKoud6uitu7AGISOM4vvI5+n1pd/hKu5ABDC uZiEJmtH5x59IqtUr/XHcWbjo7G65S23qXhngU5dTgenidtbGTJ7nsRSV5dXz/cEFMj4 FpkRO4u3HzM35WyT6BAumQ5AKCsRQKbaP5atVDStxXk0JU2fF7YCkUawWTTof+P/gyoe iuckh92EhsG84IXqVZxo8TTDzg18qVohomOKf/XcNS1BjjRMEwOrdlAqXZvKgp4DjL4L Z7ow==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=Kaa/fPGDUSdm/BE8AoTlWyfQoNl8BqYv6AUK6eVZ65E=; b=m7vXQIen6DuDUTcF8WvdhQxd3HIBCnNjjBc75N/NDn7vO2yQEqrn5ATb9oBwZQcW7a Ur4HLaFxwW7GJ/8/7cCvayljh4D5IR0BiGIyFZeB9dbtRyskrkxd1m+FtxZ6qZUpnZVW iUiKFj2mD5RK5LWXvmer/MOfsf7o2qbJuBVRoqdQ2xwVEUmJj1Ic/lRA5dKswI5N5R4C DeQrzuWn6XoUciSrlvareYZWSJDr9zf1gidZ5lW8iTMugxFctbVAyt5Io6ypleZDm8ku Y0cVOxSoGDDOStCDSF1IQTQpaGJfK+rBh3N7FYOlf+967HV7CvsME5VF//EYUcW7tGhP oR4Q==
X-Gm-Message-State: AG10YOT/fbw22UyLoKNsYeQdYeIIriWgv+D8lpdeTdpT10oPBFAJ72WEx9K4kkpAkJalr+18dO/Gk+LNcAbC+Sts
X-Received: by 10.107.150.2 with SMTP id y2mr32595339iod.113.1456187752476; Mon, 22 Feb 2016 16:35:52 -0800 (PST)
MIME-Version: 1.0
Received: by 10.64.2.168 with HTTP; Mon, 22 Feb 2016 16:35:32 -0800 (PST)
In-Reply-To: <56CBA305.1050400@si6networks.com>
References: <20160201142413.30288.23248.idtracker@ietfa.amsl.com>  <003001d1687a$926ab2e0$b74018a0$@huitema.net> <56C3161F.3070301@innovationslab.net>  <56CB891E.6060902@si6networks.com>  <56CBA305.1050400@si6networks.com>
From: Lorenzo Colitti 
Date: Tue, 23 Feb 2016 09:35:32 +0900
Message-ID: 
To: Fernando Gont 
Content-Type: multipart/alternative; boundary=001a1140ed3ab6f0df052c6521da
Archived-At: 
Cc: IETF Discussion , dhc-chairs@ietf.org, Christian Huitema , iesg@ietf.org, draft-ietf-dhc-anonymity-profile@ietf.org, "dhcwg@ietf.org" 
Subject: Re: [dhcwg] Last Call:  (Anonymity profile for DHCP clients) to Proposed Standard
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 23 Feb 2016 00:35:54 -0000

--001a1140ed3ab6f0df052c6521da
Content-Type: text/plain; charset=UTF-8

On Tue, Feb 23, 2016 at 9:08 AM, Fernando Gont 
wrote:

> >     The above text (or any similar text already in the I-D) suggests that
> >     this document should be updating RFC4862. Because it is not only
> >     specifying that to do when you do DHCPv6, but also whether to do
> >     SLAAC/DHCPv6 in the fist place.
> >
> >
> > I don't see why. I don't recall a statement in RFC 4862 specifying
> > whether hosts should use one or the other.
>
> But the authors are making such statement here. i.e., if you are going
> to implement SLAAC/DHCPv6, then this statement affects your
> implementation. Hence, an appropriate tag should be included (i.e., such
> that if I look at RFC4862 or RFC3315, it's clear that I should look at
> this document, too).


I still don't see why this document needs to formally "updates: RFC 4862"
if it doesn't affect any text in it.

--001a1140ed3ab6f0df052c6521da
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


On T=
ue, Feb 23, 2016 at 9:08 AM, Fernando Gont <fgont@si6networks.com&=
gt; wrote:
>=
=C2=A0 =C2=A0 =C2=A0The above text (or any similar text already in the I-D)=
 suggests that

>=C2=A0 =C2=A0 =C2=A0this document should be updating RFC4862. Because i=
t is not only

>=C2=A0 =C2=A0 =C2=A0specifying that to do when you do DHCPv6, but also =
whether to do

>=C2=A0 =C2=A0 =C2=A0SLAAC/DHCPv6 in the fist place.

>

>

> I don't see why. I don't recall a statement in RFC 4862 specif=
ying

> whether hosts should use one or the other.



But the authors are making such statement here. i.e., if you are goi=
ng

to implement SLAAC/DHCPv6, then this statement affects your

implementation. Hence, an appropriate tag should be included (i.e., such
that if I look at RFC4862 or RFC3315, it's clear that I should look at<=
br>
this document, too).

I still don't see =
why this document needs to formally "updates: RFC 4862" if it doe=
sn't affect any text in it.


--001a1140ed3ab6f0df052c6521da--


From nobody Mon Feb 22 18:45:50 2016
Return-Path: 
X-Original-To: dhcwg@ietfa.amsl.com
Delivered-To: dhcwg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F2BF1B3B8F; Mon, 22 Feb 2016 18:45:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.106
X-Spam-Level: *
X-Spam-Status: No, score=1.106 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, FRT_BIGGERMEM1=2.555, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=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 M_7amxayb4tn; Mon, 22 Feb 2016 18:45:43 -0800 (PST)
Received: from mail-lb0-x236.google.com (mail-lb0-x236.google.com [IPv6:2a00:1450:4010:c04::236]) (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 AAD771B3D5B; Mon, 22 Feb 2016 18:45:42 -0800 (PST)
Received: by mail-lb0-x236.google.com with SMTP id bc4so93207337lbc.2; Mon, 22 Feb 2016 18:45:42 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Y+ZN46SXg0ZLFQcl71V41uCAoqCzif7V+Rw5dB2zwuc=; b=sRNxU/y39XMnmsCv09zqlz1UjbYVQh7N0U5X2IN1IeBEfr6rRav588Eb40FWlRoi1o CoGElaW8OFMGeKtLO6dAQLMkMRw4EEDSpQJ3u2LKUXL30mSaNEZzUFXO0zaI5Si4M/Wd lyWRQpcBF30j2TECA1drbGDzT1WFcm/n7Shjz/noJNbuAXJU8zhzlQ5I4SLNv66a1cGh UVBvJn8KUilUm4ktmQ7JXh9fE90czEczuLDIkgACBSiltjz95zzdpgh8rOovN88tf+2E NA65i5wiSuUqShaYWL1GNMyL7P3rn887eBTWVF8epJsGqZPjuPtX8M+qy65m69m9O/Ui hYFw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Y+ZN46SXg0ZLFQcl71V41uCAoqCzif7V+Rw5dB2zwuc=; b=gVvZdkq5X+CbYgW6XMj6mvEHEm46ZIvG7tWEqdj6NekIWxlZKmoTAJOmWWMFjl+E79 MdQ9BgS8yjl4CMmzlalZ1/NEWHNtzjavLFlQA4idRcXeuIqgzQUf4zvpAJsOrjB1eETS PeCk/anS25gVSXSMWPwKAEwkYb1libTsRhWeYEG4aFc+kKRnuTMjt6CJ8ijhcH4zE1vY dcBbp2jOca3S+xXcrN76fyJyGHu5MSU/racC3IUtyA87NxhSG4DKkylAqoKFInzt+lrh 7aI8ldES4wjRks0uWc0+X4p9XOTElzImCGHYXI/VgXb15C0klx+0W6TqahBgLxRLwvGY ItKg==
X-Gm-Message-State: AG10YOSilQJkLrVul+6eVbfd3HqWS0cfGCR+a0zDna4YluuV0XkIvlgoK1y7Y/xO/geToJy5hSs7g84InfWP2Q==
MIME-Version: 1.0
X-Received: by 10.112.12.98 with SMTP id x2mr11409046lbb.76.1456195540903; Mon, 22 Feb 2016 18:45:40 -0800 (PST)
Received: by 10.114.79.194 with HTTP; Mon, 22 Feb 2016 18:45:40 -0800 (PST)
In-Reply-To: 
References:     
Date: Tue, 23 Feb 2016 10:45:40 +0800
Message-ID: 
From: Lishan Li 
To: =?UTF-8?B?56We5piO6YGU5ZOJ?= 
Content-Type: multipart/alternative; boundary=001a11c39ea8f0727a052c66f1a7
Archived-At: 
Cc: "dhcwg@ietf.org" , draft-ietf-dhc-sedhcpv6@ietf.org
Subject: Re: [dhcwg] comments on draft-ietf-dhc-sedhcpv6-10.txt
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 23 Feb 2016 02:45:48 -0000

--001a11c39ea8f0727a052c66f1a7
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

2016-01-30 3:30 GMT+08:00 =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89 :

> At Thu, 21 Jan 2016 23:27:03 +0800,
> Lishan Li  wrote:
>
> > > Maybe my points weren't clear enough.  First off, I didn't talk about
> > > timestamp at all; let's focus on the signature option.  Secondly, I
> > > don't see why encryption is not enough in the server-to-client case
> > > for message integrity.
> > >
> > [LS]:In the server-to-client case, the Reply message is transmitted in
> > cleartext not encryption, which contains the server's certificate
> > information.
> > So I think that it is better to contain the signature option for the
> Reply
> > message integrity check.
> > Looking forward to your further guidance.
>
> I'm still not sure if my point was made clear...so let me be more
> specific: in the following message exchanges:
>
> 1. Information-request from client to server(s)
> 2. Reply to the Information-request from server(s) to client
> 3. Encryption-Query from client to server
> 4. Encryption-Response from server to client
>
> did you mean the Reply message of exchange #2?
>
> If so, do you at least agree that it makes almost no sense to include
> the explicit separate signature in messages 3 and 4?
>
> [LS]: Yes, I mean the Reply message of exchange #2. The reply message
contains the signature option and timestamp option for message integrity
check. In the #3 and #4 messages, the DHCPv6 messages are encrypted, so the
signature and timestamp option are not contained.
What do you think of it?

> > > [LS]: In the current version, TOFU is out of scope. The client and
> server
> > > > use  certificates for authentication, not public key. So I think th=
e
> > > certificate
> > > > option is enough. The public key option is removed.
> > >
> > > I don't understand that.  We should still be able to manually
> > > configure public keys on clients and servers (see also the
> > > applicability discussion), so simply because we removed the TOFU mode
> > > shouldn't me we should remove the public key option.
> > >
> > > [LS]: If the device is pre-configured with public key not certificate=
,
> it
> > can
> > generate the self-signed certificate for authentication.
>
> Right, but this argument also holds even if we have TOFU...
>
> > So, I think that
> > the certificate option is enough for authentication.
> > Looking forward to your further guidance.
>
> ...so these don't explain why we should now remove the public key
> option.  One obvious, though possibly relatively minor, drawback of
> only having a certificate is that it will make the message size even
> bigger when we actually only need the public key.
>
> I'm not necessarily opposed to removing the public key option if we
> cover all such discussions and reach consensus, but I don't think I've
> seen it yet.
>
> [LS]: In consideration of the support of TOFU and the add of all such
discussions and consensus, the better way for us is to add the public key
option as the before secure DHCPv6 version.
Am I correct?

> > >Some specific comments on the draft text follow:
> > > > >
> > > > >- Section 4
> > > > >
> > > > >   authentication method.  However, this method provides little
> message
> > > > >   integrity or source integrity check, and it protects only the
> > > > >   Reconfigure message.  This key is transmitted in plaintext.
> [...]
> > > This one still has the same problem.  Why does this method
> > > (=3DReconfigure Key Authentication Protocol) provide little message
> > > integrity or source integrity?
> > >
> > > [LS]: The authentication mechanism defined in RFC3315 can provide for
> the
> > authentication of the client and server, and for the integrity of
> messages
> > delivered between DHCPv6 clients and servers.
> > So, how about the following text:
> > [...]  However, this method protects only the Reconfigure message. In
> > addition,
> > the key is transmitted in plaintext to the client in earlier exchanges.
> > [...]
>
> I'm not sure if my point was really taken, but I'm okay with removing
> the text in question anyway.  I'd add "...and so this method is
> vulnerable to active attacks" to the second sentence.
>
> [LS]: Agree.


> > > >- Section 5.4: in general, I think this section is still quite weak
> > > > >  and/or insufficient. [...]
> [...]
> > > I'd first like to know whether we (the wg in general including
> > > yourself) agree on my points and understanding of previous feedback.
> > > On top of that, I'll probably offer my own proposed text on these.
> > >
> > > [LS]: I agree with your proposed point. Looking forward to your
> proposed
> > text on this.
>
> Okay, will do separately.
>
> > > >- Section 5.4:
> > > > >
> > > > >   [...]  In enterprise network, the security policy is
> > > > >   strict and the clients are stable terminals.  The PKI model is
> used
> > > > >
> > > > >  What does 'stable' mean?  A desktop PC would be considered a
> "stable
> > > > >  terminal", but what about laptops?  How about smart phones
> connected
> > > > >  to the enterprise network based on the BYOD policy?
> > >
> > > This point isn't answered.
> > >
> > > [LS]: In the secure DHCPv6 deployment draft, we mainly consider two
> > different
> > scenario: stable client with strict security policy and roaming client
> with
> > loose
> > security policy.
> > For the stable clients, such as the desktop PC in enterprise network,
> they
> > are
> > pre-configured the trusted servers' certificates or the trusted CAs'
> > certificates
> > for server authentication.
> > For the roaming clients, such as the smart phones in coffee room, it is
> > difficult
> > to be pre-configured the trusted certificates for authentication.
> > What do you think of the scenario classification?
>
> I basically just asked the definition of "stable".  From the above
> text it seems to mean DHCP clients like desktop PCs, excluding laptops
> and smart phones with a BYOD policy.  If so, I'd say "In enterprise
> network, the security policy is strict and the clients are stable
> terminals" is not a realistic statement.
>
> [LS]: Agree. Will modify it.


> > > >- Section 6
> > > > >
> > > > >   non-security options assigned to it.  The Option Request option
> in
> > > > >   the Information-request message MUST contain the option code of
> > > > >   certificate option, signature option, timestamp option, and
> server
> > > > >   identifier option.
> > > > >
> > > > >  Should we really need to include all of these?  The certificate
> > > > >  option should surely be specified, but the need for the others
> seem
> > > > >  to be almost automatically derived from the specification.
> > > > >
> > > > [LS]: The signature option and timestamp option are used for the
> message
> > > > integrity check. The Reply message is transmitted in clear text. So
> in
> > > > order to protect the Reply message integrity, I think the timestamp
> > > > and signature option MUST be contained.
> > >
> > > We are probably talking about different things.  My question and poin=
t
> > > are whether timestamp and signature are specified in the "option
> > > request option".  Your response doesn't seem to answer that point.
> > >
> > > [LS]: The certificate option "MUST" be contained, and the signature
> option
> > and timestamp option "SHOULD" be contained.
> > Have I got what you mean?
>
> I'm afraid not.  I talked about option request options, but your
> answer seems to talk about something else.  Let's be very specific:
> according to the original draft text, the initial Information-request
> message MUST contain an option request option whose codes fields
> include:
>
> 1. code of certificate option
> 2. code of signature option
> 3. code of timestamp option
>
> What I tried to say is that 2 and 3 are redundant, since requesting a
> certificate option should imply a request of signature and timestamp
> option (in this context I'm forgetting the other discussion of whether
> we really need the signature option).
>
> [LS]: So we don't need to specify whether the ORO contains the signature
and timestamp options.
Because of the certificate option request, the Reply message (#2 message)
will contain the signature and timestamp options.

> > > >- Section 6
> > > > >
> > > > >   o  Upon receiving a SignatureFail error status code, the client
> MAY
> > > > >      resend the message following normal retransmission routines
> > > > >      defined in [RFC3315].
> > > > >
> > > > >  What's the rationale of this behavior?
> > > >
> > > > >
> > > > [LS]: In the new version, the client will not send the signature
> option
> > > and
> > > > timestamp option. So we will delete these sentence.
> > >
> > > Deleting it is probably fine, but it doesn't answer my point.  We'll
> > > still need to answer what the client should do if the server indicate=
s
> > > a failure in decryption (which is equivalent to SignatureFail).
> > >
> > > [LS]: In the current version, we consider the scenario where the serv=
er
> > indicates a failure in authentication. If the message fails certificate
> > validation, the DHCPv6 server SHOULD reply with an AuthenticationFail
> > error status code to the client.
> > So, you suggest to define a new error status code: DecryptionFail error
> > status code. If the DHCPv6 server fails decryption, the DHCPv6 server
> > SHOULD reply with an DecryptionFail error status code to the client.
> > Could you please check whether my understanding is correct?
>
> Introducing a new error code is related but a minor point.  My
> question was about what the client should do if it sees that code (or
> whatever signal that indicates this kind of failure).
>
[LS]: As you said before, the DecryptionFail failure is equivalent to
SignatureFail. So if the client sees that code, the client MAY resend the
message following normal retransmission routines defined in [RFC3315].
Am I correct?

>
> > > >- Section 7
> > > > >
> > > > >   [...]  Depending on server's local policy, the message without =
a
> > > > >   Timestamp option MAY be acceptable or rejected.  If the server
> > > > >   rejects such a message, a TimestampFail error status code,
> defined in
> > > > >   Section 10.3, should be sent back to the client.  [...]
> > > > >
> > > > >  To be sure: is the TimestampFail supposed to be returned when a
> > > > >  message from the client doesn't have Timestamp but the server
> wanted
> > > > >  it?
> > > > >
> > > > [LS]: Yes. Maybe the above sentences are not clear. How about the
> > > following
> > > > sentences:
> > > > [...]  Depending on server's local policy, the message without a
> > > > Timestamp option MAY be accepted or rejected.  If the server
> > > > rejects such a message without Timestamp option, then a TimestampFa=
il
> > > > error status code, defined in Section 10.3, should be sent
> > > > back to the client.  [...]
> > >
> > > Doesn't the original text (also) cover the case where Timestamp is
> > > included but the check on it fails?  If so, the new text now loses it=
s
> > > original sense.
> > >
> > > [LS]: The original text covers the scenario where the timestamp check
> > fails. But the lack of timestamp and timestamp check failure are two
> > different scenario. So I don't understand why the new text now loses
> > its original sense. Looking forward to the further guidance.
>
> Let me rephrase my question: consider the following two cases:
>
> 1. the client includes the timestamp option but server fails to
>    validate it
> 2. the client doesn't include the timestamp option but server wanted
>    to have it
>
> my original question was whether TimestampFail is included in the
> response from the server for both cases.  I assumed the answer was
> yes.  Am I correct?  If I am, your latest text seemed to lose the
> coverage for case 1 since it only talks about case 2: "If the server
> rejects such a message without Timestamp option".  Is it clearer?
>
> [LS]: I have got what you mean. I will modify this sentence to cover the
two cases.

> > >- Section 10.1.2
> > > > >
> > > > >   Note: if both signature and authentication option are present,
> > > > >   signature option does not protect the Authentication Option.  I=
t
> > > > >
> > > > >  Should we still worry about it?  The only possible reason for
> having
> > > > >  both that I can see is to allow a newer client implementation to
> > > > >  work with both new and old server implementations.  But now that
> the
> > > > >  message is encrypted in a way that older implementations don't
> > > > >  understand, it's completely impossible anymore.  I think we can
> now
> > > > >  simply say Authentication Option shouldn't be used with Secure
> > > > >  DHCPv6 (and if it's used the behavior is undefined).
> > > >
> > > > >
> > > > [LS]: I agree. So we replce this section with the following
> sentences:
> > > > If the Secure DHCPv6 is applied, then the Authentication Option
> shouldn't
> > > > be used.
> > >
> > > It should also describe the rationale.  Also, we might consider using
> > > an RFC2119 keyword, either SHOULD NOT or MUST NOT.
> >
> > [LS]: How about the following text=EF=BC=9B
> > If Secure DHCPv6 is used, the DHCPv6 message is encrypted in a way that
> > the authentication mechanism defined in RFC3315 don't understand. So, t=
he
> > Authentication option SHOULD NOT be used if Secure DHCPv6 is applied.
>
> I'd probably want to suggest something slightly different, but I'd
> like to first discuss whether we really need a signature option.
> Depending on the result of it this point may become even more moot.
> Note also that if we at least don't include the signature option in
> encrypted message, the coexistence issue doesn't exist in this case in
> the first place.
>
> [LS]: Agree. The signature option is not contained in encrypted message.
So the coexistence issue will not exist.


> p.s. there's another bigger open issue I separated from the rest of
> the discussions:
> https://mailarchive.ietf.org/arch/msg/dhcwg/-tZBpeMs-EiVyMm0MLBpj3dFYNI
>
> [LS]: Another open isssue is that:
If the server receives the Information-request message but it does not
support this work, what should the server do?
In my opinion, if the server don't support this work, it has two choices:
1. drop the received Information-request message;
In this way, the client will not receive any message which illustrate the
server don't support secure DHCPv6. If there is no authenticated DHCPv6
server, the client may resend the Information-request message;
2. send the Reply message with the corresponding error status code to the
client=EF=BC=9B
This way will introduce the downgrade attack, a third party may send the
Reply message with the corresponding error status code. And then the DHCPv6
configuration process may be unsecured.
I prefer the first one solution. Which one would you prefer? Looking
forward to your guidance.

Best Regards,
Lishan

--001a11c39ea8f0727a052c66f1a7
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


2016=
-01-30 3:30 GMT+08:00 =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89 <jinmei@wide.ad=
.jp>:
At Thu, 21 Jan 2016 23:27:03 +0800,=


Lishan Li <lili=
shan48@gmail.com> wrote:



> > Maybe my points weren't clear enough.=C2=A0 First off, I didn=
't talk about

> > timestamp at all; let's focus on the signature option.=C2=A0 =
Secondly, I

> > don't see why encryption is not enough in the server-to-clien=
t case

> > for message integrity.

> >

> [LS]:In the server-to-client case, the Reply message is transmitted in=


> cleartext not encryption, which contains the server's certificate<=
br>
> information.

> So I think that it is better to contain the signature option for the R=
eply

> message integrity check.

> Looking forward to your further guidance.



I'm still not sure if my point was made clear...so let me be mor=
e

specific: in the following message exchanges:



1. Information-request from client to server(s)

2. Reply to the Information-request from server(s) to client

3. Encryption-Query from client to server

4. Encryption-Response from server to client



did you mean the Reply message of exchange #2?



If so, do you at least agree that it makes almost no sense to include

the explicit separate signature in messages 3 and 4?


[LS]: Yes, I mean the Reply m=
essage of exchange #2. The reply message contains the signature option and =
timestamp option for message integrity check. In the #3 and #4 messages, th=
e DHCPv6 messages are encrypted, so the signature and timestamp option are =
not contained.=C2=A0
What do you think of it?=C2=A0

> > > [LS]: In the current version, TOFU is out of scope. The clie=
nt and server

> > > use=C2=A0 certificates for authentication, not public key. S=
o I think the

> > certificate

> > > option is enough. The public key option is removed.

> >

> > I don't understand that.=C2=A0 We should still be able to man=
ually

> > configure public keys on clients and servers (see also the

> > applicability discussion), so simply because we removed the TOFU =
mode

> > shouldn't me we should remove the public key option.

> >

> > [LS]: If the device is pre-configured with public key not certifi=
cate, it

> can

> generate the self-signed certificate for authentication.



Right, but this argument also holds even if we have TOFU...



> So, I think that

> the certificate option is enough for authentication.

> Looking forward to your further guidance.



...so these don't explain why we should now remove the public ke=
y

option.=C2=A0 One obvious, though possibly relatively minor, drawback of
only having a certificate is that it will make the message size even

bigger when we actually only need the public key.



I'm not necessarily opposed to removing the public key option if we

cover all such discussions and reach consensus, but I don't think I'=
;ve

seen it yet.


[LS]: In consideration of the=
 support of TOFU and the add of all such discussions and consensus, the bet=
ter way for us is to add the public key option as the before secure DHCPv6 =
version.
Am I correct?=C2=A0


> > >Some specific comments on the draft text follow:

> > > >

> > > >- Section 4

> > > >

> > > >=C2=A0 =C2=A0authentication method.=C2=A0 However, this =
method provides little message

> > > >=C2=A0 =C2=A0integrity or source integrity check, and it=
 protects only the

> > > >=C2=A0 =C2=A0Reconfigure message.=C2=A0 This key is tran=
smitted in plaintext.

[...]

> > This one still has the same problem.=C2=A0 Why does this method
> > (=3DReconfigure Key Authentication Protocol) provide little messa=
ge

> > integrity or source integrity?

> >

> > [LS]: The authentication mechanism defined in RFC3315 can provide=
 for the

> authentication of the client and server, and for the integrity of mess=
ages

> delivered between DHCPv6 clients and servers.

> So, how about the following text:

> [...]=C2=A0 However, this method protects only the Reconfigure message=
. In

> addition,

> the key is transmitted in plaintext to the client in earlier exchanges=
.

> [...]



I'm not sure if my point was really taken, but I'm okay with=
 removing

the text in question anyway.=C2=A0 I'd add "...and so this method =
is

vulnerable to active attacks" to the second sentence.


[LS]: Agree.
=C2=A0=


> > >- Section 5.4: in general, I think this section is still quit=
e weak

> > > >=C2=A0 and/or insufficient. [...]

[...]

> > I'd first like to know whether we (the wg in=
 general including

> > yourself) agree on my points and understanding of previous feedba=
ck.

> > On top of that, I'll probably offer my own proposed text on t=
hese.

> >

> > [LS]: I agree with your proposed point. Looking forward to your p=
roposed

> text on this.



Okay, will do separately.



> > >- Section 5.4:

> > > >

> > > >=C2=A0 =C2=A0[...]=C2=A0 In enterprise network, the secu=
rity policy is

> > > >=C2=A0 =C2=A0strict and the clients are stable terminals=
.=C2=A0 The PKI model is used

> > > >

> > > >=C2=A0 What does 'stable' mean?=C2=A0 A desktop =
PC would be considered a "stable

> > > >=C2=A0 terminal", but what about laptops?=C2=A0 How=
 about smart phones connected

> > > >=C2=A0 to the enterprise network based on the BYOD polic=
y?

> >

> > This point isn't answered.

> >

> > [LS]: In the secure DHCPv6 deployment draft, we mainly consider t=
wo

> different

> scenario: stable client with strict security policy and roaming client=
 with

> loose

> security policy.

> For the stable clients, such as the desktop PC in enterprise network, =
they

> are

> pre-configured the trusted servers' certificates or the trusted CA=
s'

> certificates

> for server authentication.

> For the roaming clients, such as the smart phones in coffee room, it i=
s

> difficult

> to be pre-configured the trusted certificates for authentication.

> What do you think of the scenario classification?



I basically just asked the definition of "stable".=C2=A0 F=
rom the above

text it seems to mean DHCP clients like desktop PCs, excluding laptops

and smart phones with a BYOD policy.=C2=A0 If so, I'd say "In ente=
rprise

network, the security policy is strict and the clients are=
 stable

terminals" is not a realistic statement.


[LS]: Agree. Will modify it.<=
/div>
=C2=A0

> > >- Section 6

> > > >

> > > >=C2=A0 =C2=A0non-security options assigned to it.=C2=A0 =
The Option Request option in

> > > >=C2=A0 =C2=A0the Information-request message MUST contai=
n the option code of

> > > >=C2=A0 =C2=A0certificate option, signature option, times=
tamp option, and server

> > > >=C2=A0 =C2=A0identifier option.

> > > >

> > > >=C2=A0 Should we really need to include all of these?=C2=
=A0 The certificate

> > > >=C2=A0 option should surely be specified, but the need f=
or the others seem

> > > >=C2=A0 to be almost automatically derived from the speci=
fication.

> > > >

> > > [LS]: The signature option and timestamp option are used for=
 the message

> > > integrity check. The Reply message is transmitted in clear t=
ext. So in

> > > order to protect the Reply message integrity, I think the ti=
mestamp

> > > and signature option MUST be contained.

> >

> > We are probably talking about different things.=C2=A0 My question=
 and point

> > are whether timestamp and signature are specified in the "op=
tion

> > request option".=C2=A0 Your response doesn't seem to ans=
wer that point.

> >

> > [LS]: The certificate option "MUST" be contained, and t=
he signature option

> and timestamp option "SHOULD" be contained.

> Have I got what you mean?



I'm afraid not.=C2=A0 I talked about option request options, but=
 your

answer seems to talk about something else.=C2=A0 Let's be very specific=
:

according to the original draft text, the initial Information-request

message MUST contain an option request option whose codes fields

include:



1. code of certificate option

2. code of signature option

3. code of timestamp option



What I tried to say is that 2 and 3 are redundant, since requesting a

certificate option should imply a request of signature and timestamp

option (in this context I'm forgetting the other discussion of whether<=
br>
we really need the signature option).


[LS]: So we don't need to=
 specify whether the ORO contains the signature and timestamp options.
Because of the certificate option request, the Reply message (#2 mess=
age) will contain the signature and timestamp options. =C2=A0

> > > >- Section 6

> > > >

> > > >=C2=A0 =C2=A0o=C2=A0 Upon receiving a SignatureFail erro=
r status code, the client MAY

> > > >=C2=A0 =C2=A0 =C2=A0 resend the message following normal=
 retransmission routines

> > > >=C2=A0 =C2=A0 =C2=A0 defined in [RFC3315].

> > > >

> > > >=C2=A0 What's the rationale of this behavior?

> > >

> > > >

> > > [LS]: In the new version, the client will not send the signa=
ture option

> > and

> > > timestamp option. So we will delete these sentence.

> >

> > Deleting it is probably fine, but it doesn't answer my point.=
=C2=A0 We'll

> > still need to answer what the client should do if the server indi=
cates

> > a failure in decryption (which is equivalent to SignatureFail).
> >

> > [LS]: In the current version, we consider the scenario where the =
server

> indicates a failure in authentication. If the message fails certificat=
e

> validation, the DHCPv6 server SHOULD reply with an AuthenticationFail<=
br>
> error status code to the client.

> So, you suggest to define a new error status code: DecryptionFail erro=
r

> status code. If the DHCPv6 server fails decryption, the DHCPv6 server<=
br>
> SHOULD reply with an DecryptionFail error status code to the client.
> Could you please check whether my understanding is correct?



Introducing a new error code is related but a minor point.=C2=A0 My<=
br>
question was about what the client should do if it sees that code (or

whatever signal that indicates this kind of failure).


[LS]: As you said before, the Dec=
ryptionFail failure is equivalent to SignatureFail. So if the client sees t=
hat code, the client MAY resend the message following normal retransmission=
 routines defined in [RFC3315].
Am I correct?=C2=A0
>

> > >- Section 7

> > > >

> > > >=C2=A0 =C2=A0[...]=C2=A0 Depending on server's local=
 policy, the message without a

> > > >=C2=A0 =C2=A0Timestamp option MAY be acceptable or rejec=
ted.=C2=A0 If the server

> > > >=C2=A0 =C2=A0rejects such a message, a TimestampFail err=
or status code, defined in

> > > >=C2=A0 =C2=A0Section 10.3, should be sent back to the cl=
ient.=C2=A0 [...]

> > > >

> > > >=C2=A0 To be sure: is the TimestampFail supposed to be r=
eturned when a

> > > >=C2=A0 message from the client doesn't have Timestam=
p but the server wanted

> > > >=C2=A0 it?

> > > >

> > > [LS]: Yes. Maybe the above sentences are not clear. How abou=
t the

> > following

> > > sentences:

> > > [...]=C2=A0 Depending on server's local policy, the mess=
age without a

> > > Timestamp option MAY be accepted or rejected.=C2=A0 If the s=
erver

> > > rejects such a message without Timestamp option, then a Time=
stampFail

> > > error status code, defined in Section 10.3, should be sent
> > > back to the client.=C2=A0 [...]

> >

> > Doesn't the original text (also) cover the case where Timesta=
mp is

> > included but the check on it fails?=C2=A0 If so, the new text now=
 loses its

> > original sense.

> >

> > [LS]: The original text covers the scenario where the timestamp c=
heck

> fails. But the lack of timestamp and timestamp check failure are two
> different scenario. So I don't understand why the new text now los=
es

> its original sense. Looking forward to the further guidance.



Let me rephrase my question: consider the following two cases:



1. the client includes the timestamp option but server fails to

=C2=A0 =C2=A0validate it

2. the client doesn't include the timestamp option but server wanted
=C2=A0 =C2=A0to have it



my original question was whether TimestampFail is included in the

response from the server for both cases.=C2=A0 I assumed the answer was

yes.=C2=A0 Am I correct?=C2=A0 If I am, your latest text seemed to lose the=


coverage for case 1 since it only talks about case 2: "If the server
rejects such a message without Timestamp option".=C2=A0 Is it clearer?=



[LS]: I have got what you mea=
n. I will modify this sentence to cover the two cases.=C2=A0

=


> > >- Section 10.1.2

> > > >

> > > >=C2=A0 =C2=A0Note: if both signature and authentication =
option are present,

> > > >=C2=A0 =C2=A0signature option does not protect the Authe=
ntication Option.=C2=A0 It

> > > >

> > > >=C2=A0 Should we still worry about it?=C2=A0 The only po=
ssible reason for having

> > > >=C2=A0 both that I can see is to allow a newer client im=
plementation to

> > > >=C2=A0 work with both new and old server implementations=
.=C2=A0 But now that the

> > > >=C2=A0 message is encrypted in a way that older implemen=
tations don't

> > > >=C2=A0 understand, it's completely impossible anymor=
e.=C2=A0 I think we can now

> > > >=C2=A0 simply say Authentication Option shouldn't be=
 used with Secure

> > > >=C2=A0 DHCPv6 (and if it's used the behavior is unde=
fined).

> > >

> > > >

> > > [LS]: I agree. So we replce this section with the following =
sentences:

> > > If the Secure DHCPv6 is applied, then the Authentication Opt=
ion shouldn't

> > > be used.

> >

> > It should also describe the rationale.=C2=A0 Also, we might consi=
der using

> > an RFC2119 keyword, either SHOULD NOT or MUST NOT.

>

> [LS]: How about the following text=EF=BC=9B

> If Secure DHCPv6 is used, the DHCPv6 message is encrypted in a way tha=
t

> the authentication mechanism defined in RFC3315 don't understand. =
So, the

> Authentication option SHOULD NOT be used if Secure DHCPv6 is applied.<=
br>


I'd probably want to suggest something slightly different, but I=
'd

like to first discuss whether we really need a signature option.

Depending on the result of it this point may become even more moot.

Note also that if we at least don't include the signature option in

encrypted message, the coexistence issue doesn't exist in this case in<=
br>
the first place.


[LS]: Agree. The signature option is not contained in=
 encrypted message.
So the coexistence issue will not exist.
=C2=A0

p.s. there's another bigger open issue I separated from the rest of

the discussions:

https://mailarchive.ietf.org/=
arch/msg/dhcwg/-tZBpeMs-EiVyMm0MLBpj3dFYNI


[LS]: Another open isssue is that:
If =
the server receives the Information-request message but it does not support=
 this work, what should the server do?=C2=A0
In my opinion, if th=
e server don't support this work, it has two choices:
1. drop=
 the received Information-request message;
In this way, the clien=
t will not receive any message which illustrate the server don't suppor=
t secure DHCPv6. If there is no authenticated DHCPv6 server, the client may=
 resend the Information-request message;
2. send the Reply messag=
e with the corresponding error status code to the client=EF=BC=9B
This way will introduce the downgrade attack, a third party may send the R=
eply message with the corresponding error status code. And then the DHCPv6 =
configuration process may be unsecured.
I prefer the first one so=
lution. Which one would you prefer? Looking forward to your guidance.=C2=A0=


Best Regards,
Lishan
<=
/div>


--001a11c39ea8f0727a052c66f1a7--


From nobody Tue Feb 23 01:37:40 2016
Return-Path: 
X-Original-To: dhcwg@ietfa.amsl.com
Delivered-To: dhcwg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B15F1B404C for ; Tue, 23 Feb 2016 01:37:39 -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=unavailable
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 m0-jLOCx_4NT for ; Tue, 23 Feb 2016 01:37:38 -0800 (PST)
Received: from xsmtp11.mail2web.com (xsmtp11.mail2web.com [168.144.250.181]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3DFBC1B4040 for ; Tue, 23 Feb 2016 01:37:38 -0800 (PST)
Received: from [10.5.2.12] (helo=xmail02.myhosting.com) by xsmtp11.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1aY9Na-0005xh-K5 for dhcwg@ietf.org; Tue, 23 Feb 2016 04:37:37 -0500
Received: (qmail 9050 invoked from network); 23 Feb 2016 09:35:37 -0000
Received: from unknown (HELO huitema1) (Authenticated-user:_huitema@huitema.net@[90.54.87.107]) (envelope-sender ) by xmail02.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 23 Feb 2016 09:35:37 -0000
From: "Christian Huitema" 
To: "'Lorenzo Colitti'" , "'Fernando Gont'" 
References: <20160201142413.30288.23248.idtracker@ietfa.amsl.com>  <003001d1687a$926ab2e0$b74018a0$@huitema.net> <56C3161F.3070301@innovationslab.net>  <56CB891E.6060902@si6networks.com>  <56CBA305.1050400@si6networks.com> 
In-Reply-To: 
Date: Tue, 23 Feb 2016 01:35:50 -0800
Message-ID: <019301d16e1d$979ed1d0$c6dc7570$@huitema.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 15.0
Thread-Index: AQJtbhbfm6E5go4z/5mQ+0EwmlPxoQJwz8dcAUDZ/DcA/X5PlgGjMnfIAecIhmQCo2YSXwEVLMSWAdKeHuedkzeAEA==
Content-Language: en-us
Archived-At: 
Cc: dhc-chairs@ietf.org, dhcwg@ietf.org, 'IETF Discussion' , draft-ietf-dhc-anonymity-profile@ietf.org, iesg@ietf.org
Subject: Re: [dhcwg] Last Call:  (Anonymity profile for DHCP clients) to Proposed Standard
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 23 Feb 2016 09:37:39 -0000

On Monday, February 22, 2016 4:36 PM, Lorenzo Colitti wrote:
> On Tue, Feb 23, 2016 at 9:08 AM, Fernando Gont  =
wrote:
> ...
>> But the authors are making such statement here. i.e., if you are =
going
>> to implement SLAAC/DHCPv6, then this statement affects your
>> implementation. Hence, an appropriate tag should be included (i.e., =
such
>> that if I look at RFC4862 or RFC3315, it's clear that I should look =
at
>> this document, too).
>
> I still don't see why this document needs to formally "updates: RFC =
4862" if it doesn't affect any > text in it.

We actually had an extensive discussion on a related topic, whether to =
state that the document was "updating RFC 4361." We concluded that no, =
it wasn't, using precisely the test that Lorenzo mentions. The consensus =
was that an RFC can only update another one if it replaces some of the =
original text. You have to be able to say something like "in section X =
of RFC Y, replace the sentence so and so by this and that," or "add this =
paragraph."=20

-- Christian Huitema

=20


From nobody Tue Feb 23 03:00:24 2016
Return-Path: 
X-Original-To: dhcwg@ietfa.amsl.com
Delivered-To: dhcwg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CAF81B3ABC; Tue, 23 Feb 2016 03:00:17 -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, SPF_PASS=-0.001] 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 s1Lco9pXe_2q; Tue, 23 Feb 2016 03:00:15 -0800 (PST)
Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0BC991B416C; Tue, 23 Feb 2016 03:00:15 -0800 (PST)
Received: from [192.168.3.107] (unknown [181.165.125.191]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 860B380D61; Tue, 23 Feb 2016 12:00:08 +0100 (CET)
To: Lorenzo Colitti 
References: <20160201142413.30288.23248.idtracker@ietfa.amsl.com>  <003001d1687a$926ab2e0$b74018a0$@huitema.net> <56C3161F.3070301@innovationslab.net>  <56CB891E.6060902@si6networks.com>  <56CBA305.1050400@si6networks.com> 
From: Fernando Gont 
X-Enigmail-Draft-Status: N1110
Message-ID: <56CC3BA3.2050303@si6networks.com>
Date: Tue, 23 Feb 2016 07:59:47 -0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: IETF Discussion , dhc-chairs@ietf.org, Christian Huitema , iesg@ietf.org, draft-ietf-dhc-anonymity-profile@ietf.org, "dhcwg@ietf.org" 
Subject: Re: [dhcwg] Last Call:  (Anonymity profile for DHCP clients) to Proposed Standard
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 23 Feb 2016 11:00:17 -0000

On 02/22/2016 09:35 PM, Lorenzo Colitti wrote:
> On Tue, Feb 23, 2016 at 9:08 AM, Fernando Gont  > wrote:
> 
>     >     The above text (or any similar text already in the I-D) suggests that
>     >     this document should be updating RFC4862. Because it is not only
>     >     specifying that to do when you do DHCPv6, but also whether to do
>     >     SLAAC/DHCPv6 in the fist place.
>     >
>     >
>     > I don't see why. I don't recall a statement in RFC 4862 specifying
>     > whether hosts should use one or the other.
> 
>     But the authors are making such statement here. i.e., if you are going
>     to implement SLAAC/DHCPv6, then this statement affects your
>     implementation. Hence, an appropriate tag should be included (i.e., such
>     that if I look at RFC4862 or RFC3315, it's clear that I should look at
>     this document, too).
> 
> 
> I still don't see why this document needs to formally "updates: RFC
> 4862" if it doesn't affect any text in it.

RFC4861/RFC4862 say that when M=1 you do SLAAC. Here you are saying that
if you have a PIO with A=1, you should not do DHCPv6. That's an update
to the existing specs.

I'm not saying the above is good or bad, but that's an update, and
deserves a corresponding "update tag".

-- 
Fernando Gont
SI6 Networks
e-mail: fgont@si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492





From nobody Tue Feb 23 03:07:25 2016
Return-Path: 
X-Original-To: dhcwg@ietfa.amsl.com
Delivered-To: dhcwg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6F241B2A53; Tue, 23 Feb 2016 03:07:23 -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, SPF_PASS=-0.001] 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 L7_8VTRMQazb; Tue, 23 Feb 2016 03:07:22 -0800 (PST)
Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6546D1AD362; Tue, 23 Feb 2016 03:07:22 -0800 (PST)
Received: from [192.168.3.107] (unknown [181.165.125.191]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id D2AB880DA8; Tue, 23 Feb 2016 12:07:15 +0100 (CET)
To: Christian Huitema , 'Lorenzo Colitti' 
References: <20160201142413.30288.23248.idtracker@ietfa.amsl.com>  <003001d1687a$926ab2e0$b74018a0$@huitema.net> <56C3161F.3070301@innovationslab.net>  <56CB891E.6060902@si6networks.com>  <56CBA305.1050400@si6networks.com>  <019301d16e1d$979ed1d0$c6dc7570$@huitema.net>
From: Fernando Gont 
X-Enigmail-Draft-Status: N1110
Message-ID: <56CC3D31.6000403@si6networks.com>
Date: Tue, 23 Feb 2016 08:06:25 -0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1
MIME-Version: 1.0
In-Reply-To: <019301d16e1d$979ed1d0$c6dc7570$@huitema.net>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: dhc-chairs@ietf.org, dhcwg@ietf.org, 'IETF Discussion' , draft-ietf-dhc-anonymity-profile@ietf.org, iesg@ietf.org
Subject: Re: [dhcwg] Last Call:  (Anonymity profile for DHCP clients) to Proposed Standard
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 23 Feb 2016 11:07:23 -0000

On 02/23/2016 06:35 AM, Christian Huitema wrote:
> On Monday, February 22, 2016 4:36 PM, Lorenzo Colitti wrote:
>> On Tue, Feb 23, 2016 at 9:08 AM, Fernando Gont
>>  wrote: ...
>>> But the authors are making such statement here. i.e., if you are
>>> going to implement SLAAC/DHCPv6, then this statement affects
>>> your implementation. Hence, an appropriate tag should be included
>>> (i.e., such that if I look at RFC4862 or RFC3315, it's clear that
>>> I should look at this document, too).
>> 
>> I still don't see why this document needs to formally "updates: RFC
>> 4862" if it doesn't affect any > text in it.
> 
> We actually had an extensive discussion on a related topic, whether
> to state that the document was "updating RFC 4361." We concluded that
> no, it wasn't, using precisely the test that Lorenzo mentions. The
> consensus was that an RFC can only update another one if it replaces
> some of the original text. You have to be able to say something like
> "in section X of RFC Y, replace the sentence so and so by this and
> that," or "add this paragraph."

Please see my response to Lorenzo.

Essentially, Lorenzo is saying that even if M=1, if you have a PIO with
A=1 you SHOULD do SLAAC and SHOULD NOT do DHCPv6. That's an update to
the existing specs.

Similarly, your text says:
    The choice between the stateful and stateless scenarios depends on
    flag and prefix options published by the "Router Advertisement"
    messages of local routers, as specified in [RFC4861].  When these
    options enable stateless address configuration hosts using the
    anonymity profile SHOULD choose it over stateful address
    configuration, because stateless configuration requires fewer	
    information disclosures than stateful configuration.

That's actually the contrary of what the specs say today: if M=1 you do
DHCPv6, not SLAAC.

I'm not arguing that what you propose is incorrect. I'm just saying
that, procedurally speaking, you're updating SLAAC. Hence your document
should have an appropriate "Update" tag, and note in the abstract the
specs it is updating.

Thanks,
-- 
Fernando Gont
SI6 Networks
e-mail: fgont@si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492





From nobody Tue Feb 23 04:45:39 2016
Return-Path: 
X-Original-To: dhcwg@ietfa.amsl.com
Delivered-To: dhcwg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 023A71AC3F1 for ; Tue, 23 Feb 2016 04:45:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.384
X-Spam-Level: 
X-Spam-Status: No, score=-1.384 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=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 A28Iuiu87b97 for ; Tue, 23 Feb 2016 04:45:38 -0800 (PST)
Received: from mail-yw0-x22d.google.com (mail-yw0-x22d.google.com [IPv6:2607:f8b0:4002:c05::22d]) (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 E4C791AC3B1 for ; Tue, 23 Feb 2016 04:45:37 -0800 (PST)
Received: by mail-yw0-x22d.google.com with SMTP id g127so145245751ywf.2 for ; Tue, 23 Feb 2016 04:45:37 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=W4MkB/yD4SSjQ+rBoZ0RLylSwlSJGtlibcDLqTct2nc=; b=RfHfft7IgjO8qm4+Q5oQkpyAUDknuK5WTcWkyxbG1uPzM1gt5P9uRHKtU9RAzaUWB+ /eJFiqBNtIwK95grJc9sHgHCiaayIdrF5SeJrirOcFhtV5qc+yKBTqxJsQLdMuuxTmHW z5KigDP8X2Ccb5JJOZbU1QXwiFMg0hCYRcAjn8uIh7c95rQyThaJAE6zohNqiEkS3UyP zPDgbfJBcpcMprz38P26td6YmM2m8E6abroSpW/tOhYquxwOJa1pHY3REQAZInG/SqMv OADBd1aBKQMNhHDUn9hjeWWbweZhHq9aX8a+JEEzSIRDB+By1qAf2Pukg8U1+mMklSD3 UVow==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=W4MkB/yD4SSjQ+rBoZ0RLylSwlSJGtlibcDLqTct2nc=; b=lf8HDA5Lkc0X6bARJhNdOo+ZzqxAXOeT+YlfPk53zk/HgH6Ma4RZlm5fO4Azj3tPhu K0iA72YCP5W4hsJjocqI92EfzAKK7hfbbSkJy5ueQA0iil+mi7zUlGbgDKT8LQ95Lx+Z efVBvyYi3u3Ca93YcX6+4Ak+JLO00idDWcUEq2dY0FMXD0bd3R+WF2XdCHj1ZMGV5Dx9 jNWxEeYM2Ry7mjSZwrXnMJlxjE3PqwewkPJdq+v7I2AUeY2O6xBQkWw2+lzxe8Otz9vN 8mRr+r9N+2YxjcbCb9bW0/nIAw/rWYdOFKmmWLCPrTPsG6MftdQ46qO9aJF5YrfAaCeC y5YA==
X-Gm-Message-State: AG10YOQ7HQsdrVCbeB46Z78tNSb+jmZeQqfwsAzaoS1FJlazLvMIU1F/012BKcV60jylWcCSbvlrnsPC6pzwoFta
X-Received: by 10.129.96.213 with SMTP id u204mr16176361ywb.307.1456231537148;  Tue, 23 Feb 2016 04:45:37 -0800 (PST)
MIME-Version: 1.0
Received: by 10.37.19.65 with HTTP; Tue, 23 Feb 2016 04:45:17 -0800 (PST)
In-Reply-To: <56CC3BA3.2050303@si6networks.com>
References: <20160201142413.30288.23248.idtracker@ietfa.amsl.com>  <003001d1687a$926ab2e0$b74018a0$@huitema.net> <56C3161F.3070301@innovationslab.net>  <56CB891E.6060902@si6networks.com>  <56CBA305.1050400@si6networks.com>  <56CC3BA3.2050303@si6networks.com>
From: Lorenzo Colitti 
Date: Tue, 23 Feb 2016 21:45:17 +0900
Message-ID: 
To: Fernando Gont 
Content-Type: multipart/alternative; boundary=001a114926e87bf462052c6f53ae
Archived-At: 
Cc: IETF Discussion , dhc-chairs@ietf.org, Christian Huitema , iesg@ietf.org, draft-ietf-dhc-anonymity-profile@ietf.org, "dhcwg@ietf.org" 
Subject: Re: [dhcwg] Last Call:  (Anonymity profile for DHCP clients) to Proposed Standard
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 23 Feb 2016 12:45:39 -0000

--001a114926e87bf462052c6f53ae
Content-Type: text/plain; charset=UTF-8

On Tue, Feb 23, 2016 at 7:59 PM, Fernando Gont 
wrote:

> > I still don't see why this document needs to formally "updates: RFC
> > 4862" if it doesn't affect any text in it.
>
> RFC4861/RFC4862 say that when M=1 you do SLAAC. Here you are saying that
> if you have a PIO with A=1, you should not do DHCPv6. That's an update
> to the existing specs.
>

Cite RFC4861/4862 text or your statement is unsupported and unactionable.

--001a114926e87bf462052c6f53ae
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


On T=
ue, Feb 23, 2016 at 7:59 PM, Fernando Gont <fgont@si6networks.com&=
gt; wrote:
> I=
 still don't see why this document needs to formally "updates: RFC=


> 4862" if it doesn't affect any text in it.



RFC4861/RFC4862 say that when M=3D1 you do SLAAC. Here you are sayin=
g that

if you have a PIO with A=3D1, you should not do DHCPv6. That's an updat=
e

to the existing specs.

Cite RFC4861/486=
2 text or your statement is unsupported and unactionable.
=



--001a114926e87bf462052c6f53ae--


From nobody Tue Feb 23 04:47:25 2016
Return-Path: 
X-Original-To: dhcwg@ietfa.amsl.com
Delivered-To: dhcwg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4FB41A8AFA for ; Tue, 23 Feb 2016 04:47:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.384
X-Spam-Level: 
X-Spam-Status: No, score=-1.384 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=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 ZlRo0IPTTSoy for ; Tue, 23 Feb 2016 04:47:23 -0800 (PST)
Received: from mail-yw0-x22f.google.com (mail-yw0-x22f.google.com [IPv6:2607:f8b0:4002:c05::22f]) (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 BCADA1A7028 for ; Tue, 23 Feb 2016 04:47:23 -0800 (PST)
Received: by mail-yw0-x22f.google.com with SMTP id e63so144604891ywc.3 for ; Tue, 23 Feb 2016 04:47:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=ttqySEVE4gnVEC6kLK42jy5njM0eM3DAFr+aiutPzg4=; b=V+sdVTPyb0a7azSvaBNfeOJqKwmvVFrwQPQINdc/cfWcekyZ3T41pnYXJdW9NA/+eo E8kkuQBxjNC0Sqi/d+4cWRNjQnnrREWnsK+nSTcHo+ZJervnESaEkmEBKa9wJCIS8NIN t+x6ClU63t4CWA8U/3LhupKma/CoaS6iS9PIf+i9OTtw/I2Uivu7IwufCh/WMk0HcKAd IO//Ipb8o2YLI6Fgh1pmzmkbuoMPGR+JmeAAMEjq9lAIuVSyKfHlp+BANKQe73X2uddX u4ZgDPKDF6XO+WunMCQnkWlAvDFEjK9KkrtaxOJOAOMOBErNnXcg/lvAJ3BIhIrsCjLE UQbA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=ttqySEVE4gnVEC6kLK42jy5njM0eM3DAFr+aiutPzg4=; b=U06k6p7P8xpGFAoINzu8BBf2mVgppCewHeMrusihY1mmawtXxU5nkKhQlhhdw/Zy2O pYXCN26+ZeV7YZzh5J3sLoCYzabclf2g2Ri2OBdHm1w8T2/OE2VL5qLCqZXkW80BKk1+ wL2stRExJTLXVvErjtrhWRkq0uwB+eVL2WU+LwPXMpHphfSAgRVKDC2HJzaxtHMBjXGG ilZ23keRFyH3ZYvM+Omyy0iLY0wqLzsk2NfFL/VPBvcuK0l5irzQCE8Nk8BFRqx8EYcN 0CirlzCjujCYrUUETX5ElwZYAvCqet5mkQdXCoSNjfyQZmdHzlJ7rpN7VuptNfR1sOX+ G5Cw==
X-Gm-Message-State: AG10YOQ3dfxBtFIHfYMHdwT9lr+ZyOEOeHmPORvWN0USijlqRdhnx/wjCdPe8AVh2slAB50ddh4yASOFaE2Pb2II
X-Received: by 10.129.41.150 with SMTP id p144mr18305193ywp.123.1456231643057;  Tue, 23 Feb 2016 04:47:23 -0800 (PST)
MIME-Version: 1.0
Received: by 10.37.19.65 with HTTP; Tue, 23 Feb 2016 04:47:03 -0800 (PST)
In-Reply-To: <56CC3D31.6000403@si6networks.com>
References: <20160201142413.30288.23248.idtracker@ietfa.amsl.com>  <003001d1687a$926ab2e0$b74018a0$@huitema.net> <56C3161F.3070301@innovationslab.net>  <56CB891E.6060902@si6networks.com>  <56CBA305.1050400@si6networks.com>  <019301d16e1d$979ed1d0$c6dc7570$@huitema.net> <56CC3D31.6000403@si6networks.com>
From: Lorenzo Colitti 
Date: Tue, 23 Feb 2016 21:47:03 +0900
Message-ID: 
To: Fernando Gont 
Content-Type: multipart/alternative; boundary=001a11421f00cc150b052c6f5905
Archived-At: 
Cc: IETF Discussion , dhc-chairs@ietf.org, Christian Huitema , iesg@ietf.org, draft-ietf-dhc-anonymity-profile@ietf.org, "dhcwg@ietf.org" 
Subject: Re: [dhcwg] Last Call:  (Anonymity profile for DHCP clients) to Proposed Standard
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 23 Feb 2016 12:47:24 -0000

--001a11421f00cc150b052c6f5905
Content-Type: text/plain; charset=UTF-8

On Tue, Feb 23, 2016 at 8:06 PM, Fernando Gont 
wrote:

> That's actually the contrary of what the specs say today: if M=1 you do
> DHCPv6, not SLAAC.
>

I don't see any statement in 4861 that says that. Per 4861, M=1 means
"DHCPv6 is available", not "nodes should do DHCPv6". Relevant text:

      M              1-bit "Managed address configuration" flag.  When
                     set, it indicates that addresses are available via
                     Dynamic Host Configuration Protocol [DHCPv6].

--001a11421f00cc150b052c6f5905
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


On T=
ue, Feb 23, 2016 at 8:06 PM, Fernando Gont <fgont@si6networks.com&=
gt; wrote:
That's actually the contrary of w=
hat the specs say today: if M=3D1 you do

DHCPv6, not SLAAC.

I don't see any =
statement in 4861 that says that. Per 4861, M=3D1 means "DHCPv6 is ava=
ilable", not "nodes should do DHCPv6". Relevant text:
<=
div>
=C2=A0 =C2=A0 =C2=A0 M =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A01-bit "Managed address configuration" flag.=
=C2=A0 When
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0set, it indicates that addresses are available via<=
/div>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0Dynamic Host Configuration Protocol [DHCPv6].


--001a11421f00cc150b052c6f5905--


From nobody Tue Feb 23 04:50:23 2016
Return-Path: 
X-Original-To: dhcwg@ietfa.amsl.com
Delivered-To: dhcwg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21A2B1ACDED; Tue, 23 Feb 2016 04:50:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.226
X-Spam-Level: 
X-Spam-Status: No, score=-1.226 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.006, SPF_NEUTRAL=0.779] autolearn=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 Swvowp49TjtM; Tue, 23 Feb 2016 04:50:19 -0800 (PST)
Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 506441ACDE1; Tue, 23 Feb 2016 04:50:19 -0800 (PST)
Received: from falcon.ecs.soton.ac.uk (localhost [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id u1NCo5t9007093; Tue, 23 Feb 2016 12:50:05 GMT
X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk u1NCo5t9007093
DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=201304; t=1456231806; bh=BM59Aqbgg6tTIUJR37qVeT601+s=; h=Mime-Version:Subject:From:In-Reply-To:Date:Cc:References:To; b=OX5+8hl8KSaPOvo+5u7sG81YQnGTiMFLk1zVOA4mhsPLd/T2RSA0nxi6hTxHsmmwA 1FmX6r65Vso/9P86p4DzCg6750IdIFGk+LlzthcOAAimGSjxMcoblCFcPN+J1zRZd6 8o3RvXOBHT5Z2xrjZXnibPtE5MbWa2hs9XjUFHlI=
Received: from gander.ecs.soton.ac.uk (gander.ecs.soton.ac.uk [2001:630:d0:f102::25d]) by falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [2001:630:d0:f102::25e]) envelope-from  with ESMTP (valid=N/A) id s1MCo51795907509VO ret-id none; Tue, 23 Feb 2016 12:50:06 +0000
Received: from [145.100.47.106] ([145.100.47.106]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id u1NCo0ix028879 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 23 Feb 2016 12:50:01 GMT
Content-Type: multipart/alternative; boundary="Apple-Mail=_8B54EC66-FA65-4ACC-B4EF-B051126095B8"
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
From: Tim Chown 
In-Reply-To: 
Date: Tue, 23 Feb 2016 12:50:01 +0000
Message-ID: 
References: <20160201142413.30288.23248.idtracker@ietfa.amsl.com>  <003001d1687a$926ab2e0$b74018a0$@huitema.net> <56C3161F.3070301@innovationslab.net>  <56CB891E.6060902@si6networks.com>  <56CBA305.1050400@si6networks.com>  <019301d16e1d$979ed1d0$c6dc7570$@huitema.net> <56CC3D31.6000403@si6networks.com>  <36ECA639-8F30-4DBF-94EF-55685B28E953@ecs.soton.ac.uk>
To: Lorenzo Colitti 
X-Mailer: Apple Mail (2.3112)
X-ECS-MailScanner: Found to be clean, Found to be clean
X-smtpf-Report: sid=s1MCo5179590750900; tid=s1MCo51795907509VO; client=relay,ipv6; mail=; rcpt=; nrcpt=8:0; fails=0
X-ECS-MailScanner-Information: Please contact the ISP for more information
X-ECS-MailScanner-ID: u1NCo5t9007093
X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk
Archived-At: 
Cc: IETF Discussion , dhc-chairs@ietf.org, Christian Huitema , iesg@ietf.org, draft-ietf-dhc-anonymity-profile@ietf.org, "dhcwg@ietf.org" 
Subject: Re: [dhcwg] Last Call:  (Anonymity profile for DHCP clients) to Proposed Standard
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 23 Feb 2016 12:50:21 -0000

--Apple-Mail=_8B54EC66-FA65-4ACC-B4EF-B051126095B8
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

> On 23 Feb 2016, at 12:47, Lorenzo Colitti  wrote:
>=20
> On Tue, Feb 23, 2016 at 8:06 PM, Fernando Gont > wrote:
> That's actually the contrary of what the specs say today: if M=3D1 you =
do
> DHCPv6, not SLAAC.
>=20
> I don't see any statement in 4861 that says that. Per 4861, M=3D1 =
means "DHCPv6 is available", not "nodes should do DHCPv6". Relevant =
text:
>=20
>       M              1-bit "Managed address configuration" flag.  When
>                      set, it indicates that addresses are available =
via
>                      Dynamic Host Configuration Protocol [DHCPv6]

I agree. It=E2=80=99s always just been a hint, no more, no less. And =
it=E2=80=99s been discussed many times...

Tim=

--Apple-Mail=_8B54EC66-FA65-4ACC-B4EF-B051126095B8
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8


On =
23 Feb 2016, at 12:47, Lorenzo Colitti <lorenzo@google.com> =
wrote:

On Tue, Feb 23, 2016 at 8:06 PM, Fernando Gont =
<fgont@si6networks.com> =
wrote:
That's actually the contrary of what the =
specs say today: if M=3D1 you do

DHCPv6, not SLAAC.

I don't see any statement in 4861 that =
says that. Per 4861, M=3D1 means "DHCPv6 is available", not "nodes =
should do DHCPv6". Relevant text:

      M =
             1-bit "Managed address =
configuration" flag.  When
    =
                 set, it =
indicates that addresses are available via
  =
                  =
 Dynamic Host Configuration Protocol =
[DHCPv6]

I agree. It=E2=80=99s always just been a hint, no =
more, no less. And it=E2=80=99s been discussed many =
times...

Tim
=

--Apple-Mail=_8B54EC66-FA65-4ACC-B4EF-B051126095B8--


From nobody Tue Feb 23 05:18:42 2016
Return-Path: 
X-Original-To: dhcwg@ietfa.amsl.com
Delivered-To: dhcwg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11C401B2B65; Tue, 23 Feb 2016 05:18:39 -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 9tAATZ3n_Ffz; Tue, 23 Feb 2016 05:18:34 -0800 (PST)
Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D38061B2B69; Tue, 23 Feb 2016 05:18:34 -0800 (PST)
Received: from clairseach.fuaim.com (clairseach-high.fuaim.com [206.197.161.158]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id AEE3B88155; Tue, 23 Feb 2016 05:18:34 -0800 (PST)
Received: from clemson.jhuapl.edu (swifi-nat.jhuapl.edu [128.244.87.133]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id D9514328081A; Tue, 23 Feb 2016 05:18:33 -0800 (PST)
To: Tim Chown , Lorenzo Colitti 
References: <20160201142413.30288.23248.idtracker@ietfa.amsl.com>  <003001d1687a$926ab2e0$b74018a0$@huitema.net> <56C3161F.3070301@innovationslab.net>  <56CB891E.6060902@si6networks.com>  <56CBA305.1050400@si6networks.com>  <019301d16e1d$979ed1d0$c6dc7570$@huitema.net> <56CC3D31.6000403@si6networks.com>  <36ECA639-8F30-4DBF-94EF-55685B28E953@ecs.soton.ac.uk> 
From: Brian Haberman 
Message-ID: <56CC5C23.4070401@innovationslab.net>
Date: Tue, 23 Feb 2016 08:18:27 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.6.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="e4B4PgFlS7xsbwAC1fu7cSHapAiHDvo6k"
Archived-At: 
Cc: IETF Discussion , dhc-chairs@ietf.org, Christian Huitema , iesg@ietf.org, draft-ietf-dhc-anonymity-profile@ietf.org, "dhcwg@ietf.org" 
Subject: Re: [dhcwg] Last Call:  (Anonymity profile for DHCP clients) to Proposed Standard
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 23 Feb 2016 13:18:39 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--e4B4PgFlS7xsbwAC1fu7cSHapAiHDvo6k
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

All,

On 2/23/16 7:50 AM, Tim Chown wrote:
>> On 23 Feb 2016, at 12:47, Lorenzo Colitti  wrote:
>>
>> On Tue, Feb 23, 2016 at 8:06 PM, Fernando Gont > wrote:
>> That's actually the contrary of what the specs say today: if M=3D1 you=
 do
>> DHCPv6, not SLAAC.
>>
>> I don't see any statement in 4861 that says that. Per 4861, M=3D1 mean=
s "DHCPv6 is available", not "nodes should do DHCPv6". Relevant text:
>>
>>       M              1-bit "Managed address configuration" flag.  When=

>>                      set, it indicates that addresses are available vi=
a
>>                      Dynamic Host Configuration Protocol [DHCPv6]
>=20
> I agree. It=E2=80=99s always just been a hint, no more, no less. And it=
=E2=80=99s been discussed many times...
>=20

As shepherding AD, I believe the consensus is that there is not a need
to have this document update RFC 4861/4862.

Regards,
Brian



--e4B4PgFlS7xsbwAC1fu7cSHapAiHDvo6k
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQEcBAEBCAAGBQJWzFwoAAoJEBOZRqCi7goqi+oIAL16T4UFo3gTUsKe42Y2j9he
RXMrtKYro0cSGZV92oA52OBCOCfGuM2i0cNOeVAtmib51VwH/pQ/RUNd6Ftgu2IO
BBLZoZOu2oXqmzUvYFi6HyAUI7yRmSBNo/dCGyNQzf9XRQoojyOg8YPysKYea+JH
MKsnw8Oid8f5T4MX5c9eBxjypE6l8DXFLGbJv6TApEkYH+Uf1R1BPeeNXv+x93aD
nMNhWPoYmEKqEE/HpkvSW969Zs/VfbNPcuUUiySKDuhCLtGyJKE9Nq9q89WGWuwK
xHxhpKXuyDUh0VHfWONRnPtEFYzo17lLIPA5/LEblniaCO5HA6W7GBK5adKyLaM=
=8rkG
-----END PGP SIGNATURE-----

--e4B4PgFlS7xsbwAC1fu7cSHapAiHDvo6k--


From nobody Tue Feb 23 05:35:01 2016
Return-Path: 
X-Original-To: dhcwg@ietfa.amsl.com
Delivered-To: dhcwg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 073E51B2D2B; Tue, 23 Feb 2016 05:34:55 -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, SPF_PASS=-0.001] 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 V6MZpIwPD7H5; Tue, 23 Feb 2016 05:34:52 -0800 (PST)
Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9398C1B2D0A; Tue, 23 Feb 2016 05:34:52 -0800 (PST)
Received: from [192.168.3.107] (unknown [181.165.125.191]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 0C04980DBB; Tue, 23 Feb 2016 14:34:46 +0100 (CET)
To: Lorenzo Colitti 
References: <20160201142413.30288.23248.idtracker@ietfa.amsl.com>  <003001d1687a$926ab2e0$b74018a0$@huitema.net> <56C3161F.3070301@innovationslab.net>  <56CB891E.6060902@si6networks.com>  <56CBA305.1050400@si6networks.com>  <019301d16e1d$979ed1d0$c6dc7570$@huitema.net> <56CC3D31.6000403@si6networks.com> 
From: Fernando Gont 
X-Enigmail-Draft-Status: N1110
Message-ID: <56CC5FDB.5020108@si6networks.com>
Date: Tue, 23 Feb 2016 10:34:19 -0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: IETF Discussion , dhc-chairs@ietf.org, Christian Huitema , iesg@ietf.org, draft-ietf-dhc-anonymity-profile@ietf.org, "dhcwg@ietf.org" 
Subject: Re: [dhcwg] Last Call:  (Anonymity profile for DHCP clients) to Proposed Standard
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 23 Feb 2016 13:34:55 -0000

On 02/23/2016 09:47 AM, Lorenzo Colitti wrote:
> On Tue, Feb 23, 2016 at 8:06 PM, Fernando Gont  > wrote:
> 
>     That's actually the contrary of what the specs say today: if M=1 you do
>     DHCPv6, not SLAAC.
> 
> 
> I don't see any statement in 4861 that says that. Per 4861, M=1 means
> "DHCPv6 is available", not "nodes should do DHCPv6". Relevant text:
> 
>       M              1-bit "Managed address configuration" flag.  When
>                      set, it indicates that addresses are available via
>                      Dynamic Host Configuration Protocol [DHCPv6].

This is the first one I found:

   Moreover, information
   may also be obtained through other dynamic means like DHCPv6.  Hosts
   accept the union of all received information; the receipt of a Router
   Advertisement MUST NOT invalidate all information received in a
   previous advertisement or from another source.

If you want, take this as a "may". But your text says SHOULD NOT, and
may != SHOULD NOT.

Besides, what if say, there's different address information available
via RA vs DHCPv6? --the text I cited above suggests that you accept the
union, but you suggest that you accept only the info provided by the RAs.

Again, I don't disagree (per se) with the proposal to do SLAAC rather
than DHCPv6 . But, I just think the behavior being suggested differs
from what we currently have -- hence the suggested "Update".

-- 
Fernando Gont
SI6 Networks
e-mail: fgont@si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492





From nobody Tue Feb 23 05:45:59 2016
Return-Path: 
X-Original-To: dhcwg@ietfa.amsl.com
Delivered-To: dhcwg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 592111A1B56 for ; Tue, 23 Feb 2016 05:45:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.384
X-Spam-Level: 
X-Spam-Status: No, score=-1.384 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=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 wIElhnYUlcPw for ; Tue, 23 Feb 2016 05:45:55 -0800 (PST)
Received: from mail-yw0-x236.google.com (mail-yw0-x236.google.com [IPv6:2607:f8b0:4002:c05::236]) (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 B679F1A8846 for ; Tue, 23 Feb 2016 05:45:54 -0800 (PST)
Received: by mail-yw0-x236.google.com with SMTP id h129so146286572ywb.1 for ; Tue, 23 Feb 2016 05:45:54 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=aIMuojA+LsupLTL7YOJK9O9/3YNWJHnmbqZrX9IdQBo=; b=Cr7UNgiwwUG0ojGU4uyTGl0oXjscyBbpJZdiCOOmh1uEwxAs+MhjrpVJVrlTUdRsdz SQulxsJBk7pwLnx33XGtYwRPVLk2zxwpwuvbhrUz+gYklQkrmgNTaD2/9n3RmZhaEKQg WI3lL+Bx+taXY7hw4CytEoDgS1/iUs66GvfKDnzFwDoRVB0P5H4Z2gv0MdRgGZamZwqW DAWL2fU0LKpCv/oaNR8824prLoQ3fttOqQEDJo+fs9ITqRmnyDZRgnq/6A46SnQuHuVE X1MAQflUKne2VSFrL1X0VkKh4h2pcPOKFLf85wle7711FYBTX07FvqVp35uBxnPiSLqu Pu0A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=aIMuojA+LsupLTL7YOJK9O9/3YNWJHnmbqZrX9IdQBo=; b=mZo5p/MtXWpAHFYOrDWInIBH6uSFCgOSH3QJx7srP7NPUGDVHkLpJ7nKbyRPBuQuRr ioDAd90v5Zg0+OZ2Mt3s5aYx27hOeYibIt7KpYgi4g0rAMjdrRcXxjf4fsFb6viF9EK1 7nxlx2YYBLHnsoqwcrYbusSA+YJ0zd23k231jT+tZMzYV4MhRz/vBSteXwPhNz/eTLZl aXW2EUIFrg2hPLGTkX3WeTwpWxZ1KiLHkCURjo3QromiyJq/tZtYI88jHDXhJOh028xE Bm5df7uJoNfY+9kLm34tiBJyNTELLCMZgaiS+hhJZ3vijEl6ptrobccAnjxgvNQueGRD WFIQ==
X-Gm-Message-State: AG10YOSvdmCRga96m+ZT0gZ/0bszA+VBa9JV7Y1REL5O14XZL+VenrV8cc6/IGK/Af24N/vPa/aPORu9UXiXDDwg
X-Received: by 10.13.202.16 with SMTP id m16mr16374926ywd.160.1456235153908; Tue, 23 Feb 2016 05:45:53 -0800 (PST)
MIME-Version: 1.0
Received: by 10.37.19.65 with HTTP; Tue, 23 Feb 2016 05:45:34 -0800 (PST)
In-Reply-To: <56CC5FDB.5020108@si6networks.com>
References: <20160201142413.30288.23248.idtracker@ietfa.amsl.com>  <003001d1687a$926ab2e0$b74018a0$@huitema.net> <56C3161F.3070301@innovationslab.net>  <56CB891E.6060902@si6networks.com>  <56CBA305.1050400@si6networks.com>  <019301d16e1d$979ed1d0$c6dc7570$@huitema.net> <56CC3D31.6000403@si6networks.com>  <56CC5FDB.5020108@si6networks.com>
From: Lorenzo Colitti 
Date: Tue, 23 Feb 2016 22:45:34 +0900
Message-ID: 
To: Fernando Gont 
Content-Type: multipart/alternative; boundary=001a114f00fa0f6642052c702b4b
Archived-At: 
Cc: IETF Discussion , dhc-chairs@ietf.org, Christian Huitema , iesg@ietf.org, draft-ietf-dhc-anonymity-profile@ietf.org, "dhcwg@ietf.org" 
Subject: Re: [dhcwg] Last Call:  (Anonymity profile for DHCP clients) to Proposed Standard
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 23 Feb 2016 13:45:56 -0000

--001a114f00fa0f6642052c702b4b
Content-Type: text/plain; charset=UTF-8

On Tue, Feb 23, 2016 at 10:34 PM, Fernando Gont 
wrote:

> This is the first one I found:
>
>    Moreover, information
>    may also be obtained through other dynamic means like DHCPv6.  Hosts
>    accept the union of all received information; the receipt of a Router
>    Advertisement MUST NOT invalidate all information received in a
>    previous advertisement or from another source.
>

This text is also unaffected by the current draft. The draft says that the
host should decide whether or not to do DHCPv6 based on the information in
Router Advertisements. That does not contradict RFC 4861: since DHCPv6
requires an explicit request from the host before anything happens,
choosing *not to start* DHCPv6 does not "invalidate" anything obtained from
DHCPv6. If DHCPv6 was not started, then the host will have received nothing
from DHCPv6, and there is nothing to invalidate.


> Besides, what if say, there's different address information available
> via RA vs DHCPv6? --the text I cited above suggests that you accept the
> union, but you suggest that you accept only the info provided by the RAs.
>

The draft doesn't say that the host shouldn't accept information provided
by DHCPv6. It says that the host shouldn't request such information if it
has all it needs from something else.


> Again, I don't disagree (per se) with the proposal to do SLAAC rather
> than DHCPv6 . But, I just think the behavior being suggested differs
> from what we currently have -- hence the suggested "Update".


The behaviour that we currently have is due to what implementations chose
to do, not to what standards track RFCs say.

--001a114f00fa0f6642052c702b4b
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


On T=
ue, Feb 23, 2016 at 10:34 PM, Fernando Gont <fgont@si6networks.com> wrote:
This is the first on=
e I found:



=C2=A0 =C2=A0Moreover, information

=C2=A0 =C2=A0may also be obtained through other dynamic means like DHCPv6.=
=C2=A0 Hosts

=C2=A0 =C2=A0accept the union of all received information; the receipt of a=
 Router

=C2=A0 =C2=A0Advertisement MUST NOT invalidate all information received in =
a

=C2=A0 =C2=A0previous advertisement or from another source.

This text is also unaffected by the current draft. The=
 draft says that the host should decide whether or not to do DHCPv6 based o=
n the information in Router Advertisements. That does not contradict RFC 48=
61: since DHCPv6 requires an explicit request from the host before anything=
 happens, choosing *not to start* DHCPv6 does not "invalidate" an=
ything obtained from DHCPv6. If DHCPv6 was not started, then the host will =
have received nothing from DHCPv6, and there is nothing to invalidate.
=C2=A0
Besides, what if say, ther=
e's different address information available

via RA vs DHCPv6? --the text I cited above suggests that you accept the

union, but you suggest that you accept only the info provided by the RAs.

The draft doesn't say that the host =
shouldn't accept information provided by DHCPv6. It says that the host =
shouldn't request such information if it has all it needs from somethin=
g else.
=C2=A0

Again, I don't disagree (per se) with the proposal to do SLAAC rather
than DHCPv6 . But, I just think the behavior being suggested differs

from what we currently have -- hence the suggested "Update".

The behaviour that we currently have is due to what implem=
entations chose to do, not to what standards track RFCs say.


--001a114f00fa0f6642052c702b4b--


From nobody Tue Feb 23 06:17:03 2016
Return-Path: 
X-Original-To: dhcwg@ietfa.amsl.com
Delivered-To: dhcwg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D5671B2EDB; Tue, 23 Feb 2016 06:17:00 -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, SPF_PASS=-0.001] 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 3o3WfS2sPF52; Tue, 23 Feb 2016 06:16:58 -0800 (PST)
Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A2D431B2ED7; Tue, 23 Feb 2016 06:16:58 -0800 (PST)
Received: from [192.168.2.101] (unknown [181.165.125.191]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id B4FC180DA3; Tue, 23 Feb 2016 15:16:51 +0100 (CET)
To: Lorenzo Colitti 
References: <20160201142413.30288.23248.idtracker@ietfa.amsl.com>  <003001d1687a$926ab2e0$b74018a0$@huitema.net> <56C3161F.3070301@innovationslab.net>  <56CB891E.6060902@si6networks.com>  <56CBA305.1050400@si6networks.com>  <019301d16e1d$979ed1d0$c6dc7570$@huitema.net> <56CC3D31.6000403@si6networks.com>  <56CC5FDB.5020108@si6networks.com> 
From: Fernando Gont 
X-Enigmail-Draft-Status: N1110
Message-ID: <56CC691D.7000904@si6networks.com>
Date: Tue, 23 Feb 2016 11:13:49 -0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: IETF Discussion , dhc-chairs@ietf.org, Christian Huitema , iesg@ietf.org, draft-ietf-dhc-anonymity-profile@ietf.org, "dhcwg@ietf.org" 
Subject: Re: [dhcwg] Last Call:  (Anonymity profile for DHCP clients) to Proposed Standard
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 23 Feb 2016 14:17:00 -0000

On 02/23/2016 10:45 AM, Lorenzo Colitti wrote:
>     Besides, what if say, there's different address information available
>     via RA vs DHCPv6? --the text I cited above suggests that you accept the
>     union, but you suggest that you accept only the info provided by the
>     RAs.
> 
> 
> The draft doesn't say that the host shouldn't accept information
> provided by DHCPv6. It says that the host shouldn't request such
> information if it has all it needs from something else.

Say you only receive a ULA/64 in the RA. Is that "all you needed"?
(particularly if there was a GUA available via DHCPv6)


>     Again, I don't disagree (per se) with the proposal to do SLAAC rather
>     than DHCPv6 . But, I just think the behavior being suggested differs
>     from what we currently have -- hence the suggested "Update".
> 
> The behaviour that we currently have is due to what implementations
> chose to do, not to what standards track RFCs say.

... what implementations chose to do, within ambiguity in the specs. See
draft-ietf-v6ops-dhcpv6-slaac-problem-06.

Thanks,
-- 
Fernando Gont
SI6 Networks
e-mail: fgont@si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492





From nobody Tue Feb 23 06:30:59 2016
Return-Path: 
X-Original-To: dhcwg@ietfa.amsl.com
Delivered-To: dhcwg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D82C41B2FB9 for ; Tue, 23 Feb 2016 06:30:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.384
X-Spam-Level: 
X-Spam-Status: No, score=-1.384 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=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 isvRs_Lwa6QF for ; Tue, 23 Feb 2016 06:30:57 -0800 (PST)
Received: from mail-yw0-x236.google.com (mail-yw0-x236.google.com [IPv6:2607:f8b0:4002:c05::236]) (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 F2B641B2FC2 for ; Tue, 23 Feb 2016 06:30:54 -0800 (PST)
Received: by mail-yw0-x236.google.com with SMTP id h129so147433158ywb.1 for ; Tue, 23 Feb 2016 06:30:54 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=G4ahw32h/+veguOBGYF/w74Hvv+hdV67SEu6ZUz3ns0=; b=jBtxai3Y3lq3+2AmZ3G3tmjBHqmATmRcIlv6WBhToq5db7LqPLHVUcryXyW3fhI49J bUGg7R5KydNQBrVHNJctKhpjm/lA8dJUO7wO2QFJkiNftEvN+AcSNHktY6Zrk3XOUrm2 GfMCj6n//a9ikDzzA/FdpI9DiOlxxSQqtaCeJdkAiub3zzuv5ylTqsIamWSMfiRMLhv9 0wfMP/tGurBbbgbtwmo/sU1k4ceCKHFIDTW6f6TtMBVgeIqVP7NqTEu9dD4nrheovnwG 19WT94+ZY9gcNsrU5lHf3q58IhGdHqrUtJlKZaF+9/9tBCE+oLls6XqNggJ3hxZNYe6I YM6Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=G4ahw32h/+veguOBGYF/w74Hvv+hdV67SEu6ZUz3ns0=; b=IVByivW7V4D88sDCMEOJhYIDFz2rC1I8JlaEKkca8jkABDsDUFHxUbYsgSC2bbfDoz T6jZhkTQd84tZDeuW4VUHFJFVb6SqqqECCe34odyPqLEuRR8IjqkQNxxzF0/PeEYm115 r3WH0FpaKIH2+D7lkZr8J4oj/OTTj2AAtOs7MMw0bzUjqbPH6S5vYdtkCVOp/U4Wl0rS qtW4zRDCoAlTTx53onhqng97mQ9Ol8nt/lTRVi7sYuHVA6n3PTefBlA+LwCcKp2GUPkX tM6s4XissfpzJzzOKROAuXykQIw8eZFvHH4fqSD2m4QMLFdkz5o4XzUs6HasWDC5MZgd ZviQ==
X-Gm-Message-State: AG10YOT67Vqz5mUD/FW7nXmpDpipcfCnEAc6l8/Ah976V01O4YPJlpaT6nyh9LCylvh/3tE5UlUNfxBCxhBujwYe
X-Received: by 10.13.202.16 with SMTP id m16mr16513936ywd.160.1456237854223; Tue, 23 Feb 2016 06:30:54 -0800 (PST)
MIME-Version: 1.0
Received: by 10.37.19.65 with HTTP; Tue, 23 Feb 2016 06:30:34 -0800 (PST)
In-Reply-To: <56CC691D.7000904@si6networks.com>
References: <20160201142413.30288.23248.idtracker@ietfa.amsl.com>  <003001d1687a$926ab2e0$b74018a0$@huitema.net> <56C3161F.3070301@innovationslab.net>  <56CB891E.6060902@si6networks.com>  <56CBA305.1050400@si6networks.com>  <019301d16e1d$979ed1d0$c6dc7570$@huitema.net> <56CC3D31.6000403@si6networks.com>  <56CC5FDB.5020108@si6networks.com>  <56CC691D.7000904@si6networks.com>
From: Lorenzo Colitti 
Date: Tue, 23 Feb 2016 23:30:34 +0900
Message-ID: 
To: Fernando Gont 
Content-Type: multipart/alternative; boundary=001a114f00fa02e201052c70cc89
Archived-At: 
Cc: IETF Discussion , dhc-chairs@ietf.org, Christian Huitema , iesg@ietf.org, draft-ietf-dhc-anonymity-profile@ietf.org, "dhcwg@ietf.org" 
Subject: Re: [dhcwg] Last Call:  (Anonymity profile for DHCP clients) to Proposed Standard
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 23 Feb 2016 14:30:58 -0000

--001a114f00fa02e201052c70cc89
Content-Type: text/plain; charset=UTF-8

On Tue, Feb 23, 2016 at 11:13 PM, Fernando Gont 
wrote:

> > The draft doesn't say that the host shouldn't accept information
> > provided by DHCPv6. It says that the host shouldn't request such
> > information if it has all it needs from something else.
>
> Say you only receive a ULA/64 in the RA. Is that "all you needed"?

(particularly if there was a GUA available via DHCPv6)
>

I don't see what question that has to do with whether this document updates
RFC 4861 or not. Happy to discuss that question in another thread, but not
here. (The "all you needed" words aren't even in the draft - they are mine).

--001a114f00fa02e201052c70cc89
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable



--001a114f00fa02e201052c70cc89--


From nobody Tue Feb 23 09:36:01 2016
Return-Path: 
X-Original-To: dhcwg@ietfa.amsl.com
Delivered-To: dhcwg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6500B1B3150; Tue, 23 Feb 2016 09:35:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.978
X-Spam-Level: 
X-Spam-Status: No, score=-0.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=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 tlfjdnvyWr1y; Tue, 23 Feb 2016 09:35:56 -0800 (PST)
Received: from mail-io0-x22d.google.com (mail-io0-x22d.google.com [IPv6:2607:f8b0:4001:c06::22d]) (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 EFD251ACD4E; Tue, 23 Feb 2016 09:35:55 -0800 (PST)
Received: by mail-io0-x22d.google.com with SMTP id 9so222707233iom.1; Tue, 23 Feb 2016 09:35:55 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=FspTmB5v9nZFuhcXEONehE8PoJ2fvxkxQDM8LcZcUgw=; b=kq/1+ej9phS1klIjbs0pgnxYJUg8TWlMMybH6b/IOM6xbdhqwLs6UOdCtkFYAis+tJ dx4hEOhWlBlgYXGTZp5ab7FIFgkNlhi5A6sFdOQ6eylwwrN+Go67+pzzEqPmUKPQjHSr rzd8seOfpsZbBqOQyyrYpsKPmMSg6DPrzS/zeu+nx7yScvYoxVpL6Sipu9QWaXJxYPAI UCe/YQYNG49DPQq6OxBNW5sA8CIX8/uuW1opRFiZ3Y1ET9468SycCFz00FKQ1C2ZHEE8 Puaxu2qsZwFvQ6+b/zdC+vbpqBL7s1Y9WiqhjaSyI3Gcu+xCMt5X0qTsrN4JwSSwDTmU ZaGw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=FspTmB5v9nZFuhcXEONehE8PoJ2fvxkxQDM8LcZcUgw=; b=U4pGEntaijDFzU4DwElFza5JBOltpnhzFj9DOzSEu3JcMHHzKEH0B5/IrH8FgWkw2s 2bD8s/KQOLPnjLdaBhQiNSVOLpx8JR3RLSDxfixetrf49ixTCsjVwjwJ6t7uoO56pqgH u6B+kkZBQmOoAkJOZv0pwqWPuSYoYmjf7BFenN8lsF5bQCB1B40OxIiOY6usWNhr9Njb IGg5AcaKGCBBHjlqHYDCpz300Xga5dudiOtuLDjM5UwGFdei5t9/626ARm4XTiqI5qLG yJnaWBzjX4k8DPaC1N+OhMS8ImXlwg/XmDS4oHHjAtRn6ZDhJcldlFvwlZzSmQAdX8ye NxZw==
X-Gm-Message-State: AG10YORa7Aya95wtJLiwZfpAk/Q+ix8/S83L6OvYkHghLwxPItGBj3xd28yOJiSuJccaM5n22Usg3swvg/JCEA==
MIME-Version: 1.0
X-Received: by 10.107.137.142 with SMTP id t14mr38546191ioi.172.1456248955428;  Tue, 23 Feb 2016 09:35:55 -0800 (PST)
Sender: jinmei.tatuya@gmail.com
Received: by 10.107.169.35 with HTTP; Tue, 23 Feb 2016 09:35:55 -0800 (PST)
In-Reply-To: 
References: <20160201142413.30288.23248.idtracker@ietfa.amsl.com>  <003001d1687a$926ab2e0$b74018a0$@huitema.net> <56C3161F.3070301@innovationslab.net>  <56CB891E.6060902@si6networks.com>  <56CBA305.1050400@si6networks.com>  <019301d16e1d$979ed1d0$c6dc7570$@huitema.net> <56CC3D31.6000403@si6networks.com> <36ECA639-8F30-4DBF-94EF-55685B28E953@ecs.soton.ac.uk>  
Date: Tue, 23 Feb 2016 09:35:55 -0800
X-Google-Sender-Auth: IYfZKK89EQyZkWzrkzpNwTS9IKA
Message-ID: 
From: =?UTF-8?B?56We5piO6YGU5ZOJ?= 
To: Tim Chown 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Cc: IETF Discussion , dhc-chairs@ietf.org, Christian Huitema , The IESG , draft-ietf-dhc-anonymity-profile@ietf.org, "dhcwg@ietf.org" 
Subject: Re: [dhcwg] Last Call:  (Anonymity profile for DHCP clients) to Proposed Standard
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 23 Feb 2016 17:35:57 -0000

At Tue, 23 Feb 2016 12:50:01 +0000,
Tim Chown  wrote:

> > That's actually the contrary of what the specs say today: if M=3D1 you =
do
> > DHCPv6, not SLAAC.
> >
> > I don't see any statement in 4861 that says that. Per 4861, M=3D1 means=
 "DHCPv6 is available", not "nodes should do DHCPv6". Relevant text:
> >
> >       M              1-bit "Managed address configuration" flag.  When
> >                      set, it indicates that addresses are available via
> >                      Dynamic Host Configuration Protocol [DHCPv6]
>
> I agree. It=E2=80=99s always just been a hint, no more, no less. And it=
=E2=80=99s been discussed many times...

+1.  I understand it may look subtle and could be confusing probably
because it was a kind of compromise as we could reach consensus on how
M/A flags should actually work.  But, however it looks, I'm pretty
sure that the intent of RFC4861 is that we do NOT say "if M=3D1 you do
DHCPv6", and that was intentional.  Let alone RFC4862 (for which I
happen to be a document editor): it even removed references to the M/O
flags:

   o  Removed the text regarding the M and O flags, considering the
      maturity of implementations and operational experiences.
      ManagedFlag and OtherConfigFlag were removed accordingly.  (Note
      that this change does not mean the use of these flags is
      deprecated.)

As such, I don't see the need for adding the "update: RFC 4682" mark
because of the proposed text.  (I don't have a particular opinion on
the text itself, btw).

--
JINMEI, Tatuya


From nobody Tue Feb 23 10:29:15 2016
Return-Path: 
X-Original-To: dhcwg@ietfa.amsl.com
Delivered-To: dhcwg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E807A1B402E; Tue, 23 Feb 2016 10:29:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.307
X-Spam-Level: 
X-Spam-Status: No, score=-4.307 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] 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 cHJJFNhIBwbU; Tue, 23 Feb 2016 10:29:05 -0800 (PST)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD2091B404A; Tue, 23 Feb 2016 10:29:05 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 9CCD7BE7D; Tue, 23 Feb 2016 18:29:03 +0000 (GMT)
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IkYjuw7z2LOF; Tue, 23 Feb 2016 18:29:02 +0000 (GMT)
Received: from [172.25.1.31] (rrcs-67-52-140-5.west.biz.rr.com [67.52.140.5]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 8B872BDD0; Tue, 23 Feb 2016 18:29:00 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1456252142; bh=oDBsiY+VT30tmX7O2nL2jUnFU9MTqyAr4gn8bzvSCDQ=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=uzhHSAbk0bdSvIX04ptA3TF41JK/KWbR85tEg7O+jvzIczDOpsvaDoM8GF/w8CJVv L/y8FOU5Xlfg3VU+nN4Yh3JMqUUGQC6ZBZobNXxWbX7fdUXuLvSQeRg8TAQXvz+ECX 8dMFxSlCELRrBs9RUQtBo8HB3hXHhudjkf291jIA=
To: Fernando Gont , Lorenzo Colitti 
References: <20160201142413.30288.23248.idtracker@ietfa.amsl.com>  <003001d1687a$926ab2e0$b74018a0$@huitema.net> <56C3161F.3070301@innovationslab.net>  <56CB891E.6060902@si6networks.com>  <56CBA305.1050400@si6networks.com>  <56CC3BA3.2050303@si6networks.com>
From: Stephen Farrell 
Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Message-ID: <56CCA4EA.1020709@cs.tcd.ie>
Date: Tue, 23 Feb 2016 18:28:58 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1
MIME-Version: 1.0
In-Reply-To: <56CC3BA3.2050303@si6networks.com>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms050003040308080004000804"
Archived-At: 
Cc: IETF Discussion , dhc-chairs@ietf.org, Christian Huitema , iesg@ietf.org, draft-ietf-dhc-anonymity-profile@ietf.org, "dhcwg@ietf.org" 
Subject: Re: [dhcwg] Last Call:  (Anonymity profile for DHCP clients) to Proposed Standard
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 23 Feb 2016 18:29:08 -0000

This is a cryptographically signed message in MIME format.

--------------ms050003040308080004000804
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable



On 23/02/16 10:59, Fernando Gont wrote:
>=20
> I'm not saying the above is good or bad, but that's an update, and
> deserves a corresponding "update tag".

FWIW, I've no opinion here but please be aware that different working
definitions of the "updates" relationship are concurrently in use in
different bits of the IETF. For some, it means "you really need to
read this" for others its "a new implementer of the old thing really
needs to also include the new code" and those aren't always the same.
There are probably other not-unreasonable meanings one could come up
with too. I'd not get hung up on it generally myself.

S.


--------------ms050003040308080004000804
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC
CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ
BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD
ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll
bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw
aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA
Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra
C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3
rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5
R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r
dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt
3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw
MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ
QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv
BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5
BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu
Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll
bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc
MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE
MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG
9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD
C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9
U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM
aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai
9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC
BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE
BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs
IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g
QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC
SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj
YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC
ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv
mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm
VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4
D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI
dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu
N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE
FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp
MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE
WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG
JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+
SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g
BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv
bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY
0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF
NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9
uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p
6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv
Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu
mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7
RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO
/ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN
JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM
MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG
A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0
Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA
oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjAyMjMx
ODI4NThaMC8GCSqGSIb3DQEJBDEiBCC4lH2SXWoAsL1BhQQJDBw+uiy+HRNv4LFMaKerJ5hX
iDBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN
AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC
AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0
Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw
IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB
nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t
IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD
VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq
hkiG9w0BAQEFAASCAQB1QUdoCEh95qux/cPJllwWI6Lq7QlUqzooY25u+apgNFoD5pL3lOwm
D2Z8IYap0Nigh/KmNW2rOHGNTEtWbP5NnqU6EgXKPfOQH/pM6rPoKUO+rl+cyI/qsa+Td4mO
D/dsdEx1OBia1fWlMUl0oAbZl7jso4Pp8yYIJVHKowTbVNafntFeq1C9Rqb2HFhV8bL46VRa
xTtBsiZxEokdJ3sVuOYYcq/rz8pDFM6/iOwGNfGiYa/BNl5aAXgnRGaSv2X5MbhF0MVwT8py
QH3Np+2e6jrwhVjGGZGfju3XT1ooX4ZfWIyJbNkVAJ1aYfr09MRoKH1fqLtvpM6mEVtyWYQy
AAAAAAAA
--------------ms050003040308080004000804--


From nobody Tue Feb 23 10:37:41 2016
Return-Path: 
X-Original-To: dhcwg@ietfa.amsl.com
Delivered-To: dhcwg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB98F1A0854; Tue, 23 Feb 2016 10:37:38 -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, SPF_PASS=-0.001] 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 u22TjEjoEQs3; Tue, 23 Feb 2016 10:37:36 -0800 (PST)
Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 638671A0469; Tue, 23 Feb 2016 10:37:36 -0800 (PST)
Received: from [192.168.2.101] (unknown [181.165.125.191]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 2305580D48; Tue, 23 Feb 2016 19:37:29 +0100 (CET)
To: Stephen Farrell , Lorenzo Colitti 
References: <20160201142413.30288.23248.idtracker@ietfa.amsl.com>  <003001d1687a$926ab2e0$b74018a0$@huitema.net> <56C3161F.3070301@innovationslab.net>  <56CB891E.6060902@si6networks.com>  <56CBA305.1050400@si6networks.com>  <56CC3BA3.2050303@si6networks.com> <56CCA4EA.1020709@cs.tcd.ie>
From: Fernando Gont 
X-Enigmail-Draft-Status: N1110
Message-ID: <56CCA6A8.3030305@si6networks.com>
Date: Tue, 23 Feb 2016 15:36:24 -0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1
MIME-Version: 1.0
In-Reply-To: <56CCA4EA.1020709@cs.tcd.ie>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: IETF Discussion , dhc-chairs@ietf.org, Christian Huitema , iesg@ietf.org, draft-ietf-dhc-anonymity-profile@ietf.org, "dhcwg@ietf.org" 
Subject: Re: [dhcwg] Last Call:  (Anonymity profile for DHCP clients) to Proposed Standard
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 23 Feb 2016 18:37:39 -0000

Stephen,

On 02/23/2016 03:28 PM, Stephen Farrell wrote:
> 
> 
> On 23/02/16 10:59, Fernando Gont wrote:
>>
>> I'm not saying the above is good or bad, but that's an update, and
>> deserves a corresponding "update tag".
> 
> FWIW, I've no opinion here but please be aware that different working
> definitions of the "updates" relationship are concurrently in use in
> different bits of the IETF. For some, it means "you really need to
> read this" for others its "a new implementer of the old thing really
> needs to also include the new code" and those aren't always the same.
> There are probably other not-unreasonable meanings one could come up
> with too. I'd not get hung up on it generally myself.

Thanks for the note, and I agree with your view.

That said... isn't this an indication that we should converge on
*something* regarding the meaning of "updates"? (i.e., it should be
clear what it means, and what rules should be applied when deciding when
a "Updates" tag is warranted or not)

Cheers,
-- 
Fernando Gont
SI6 Networks
e-mail: fgont@si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492





From nobody Tue Feb 23 10:44:26 2016
Return-Path: 
X-Original-To: dhcwg@ietfa.amsl.com
Delivered-To: dhcwg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB6091A1BD9; Tue, 23 Feb 2016 10:44:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.307
X-Spam-Level: 
X-Spam-Status: No, score=-4.307 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] 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 k6z4VPuWr0OF; Tue, 23 Feb 2016 10:44:20 -0800 (PST)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 56F901A1BDF; Tue, 23 Feb 2016 10:44:20 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 1FD77BDD0; Tue, 23 Feb 2016 18:44:19 +0000 (GMT)
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MOn1vb-VropJ; Tue, 23 Feb 2016 18:44:17 +0000 (GMT)
Received: from [172.25.1.31] (rrcs-67-52-140-5.west.biz.rr.com [67.52.140.5]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id E7DCEBDF9; Tue, 23 Feb 2016 18:44:15 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1456253057; bh=o0/acfKeHez/CelNBi8pX15ZTJfMMd54Oo/Gq+TX5MU=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=XWw1QsPyQBIYo9iDt87IqxjiVyeBxktyhLk5PWIpDtPhQzjMRnhZTDl6qSYOPYfVC TuSSnS1vHoubz7lK8x1hGZ8KwWOg+ZQcGMEeXIFSpJCXySlJ6ILw3DaTxJ5UL53NtM AtQE9r31LMwYgmtSp0BdECVXC93QcbayLXbKUzGs=
To: Fernando Gont , Lorenzo Colitti 
References: <20160201142413.30288.23248.idtracker@ietfa.amsl.com>  <003001d1687a$926ab2e0$b74018a0$@huitema.net> <56C3161F.3070301@innovationslab.net>  <56CB891E.6060902@si6networks.com>  <56CBA305.1050400@si6networks.com>  <56CC3BA3.2050303@si6networks.com> <56CCA4EA.1020709@cs.tcd.ie> <56CCA6A8.3030305@si6networks.com>
From: Stephen Farrell 
Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Message-ID: <56CCA87E.8040409@cs.tcd.ie>
Date: Tue, 23 Feb 2016 18:44:14 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1
MIME-Version: 1.0
In-Reply-To: <56CCA6A8.3030305@si6networks.com>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms000603020909060709090704"
Archived-At: 
Cc: IETF Discussion , dhc-chairs@ietf.org, Christian Huitema , iesg@ietf.org, draft-ietf-dhc-anonymity-profile@ietf.org, "dhcwg@ietf.org" 
Subject: Re: [dhcwg] Last Call:  (Anonymity profile for DHCP clients) to Proposed Standard
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 23 Feb 2016 18:44:22 -0000

This is a cryptographically signed message in MIME format.

--------------ms000603020909060709090704
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


Hiya,

On 23/02/16 18:36, Fernando Gont wrote:
>=20
> That said... isn't this an indication that we should converge on
> *something* regarding the meaning of "updates"? (i.e., it should be
> clear what it means, and what rules should be applied when deciding whe=
n
> a "Updates" tag is warranted or not)

In theory, yes. I don't find it to be something that I'd prioritise
myself. I suspect attempts to "fix" this would open a can of worms
about the general semantics of relationships between RFCs and would
likely end up being very hard to get done, and with not much benefit
at the end.

S.


--------------ms000603020909060709090704
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC
CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ
BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD
ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll
bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw
aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA
Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra
C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3
rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5
R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r
dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt
3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw
MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ
QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv
BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5
BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu
Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll
bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc
MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE
MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG
9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD
C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9
U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM
aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai
9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC
BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE
BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs
IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g
QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC
SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj
YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC
ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv
mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm
VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4
D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI
dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu
N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE
FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp
MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE
WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG
JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+
SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g
BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv
bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY
0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF
NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9
uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p
6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv
Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu
mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7
RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO
/ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN
JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM
MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG
A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0
Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA
oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjAyMjMx
ODQ0MTRaMC8GCSqGSIb3DQEJBDEiBCBoo/fi7505su+3ikabjfUC80JnL366UGPI877/bEZZ
HzBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN
AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC
AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0
Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw
IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB
nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t
IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD
VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq
hkiG9w0BAQEFAASCAQBUb5te0C+ZurE0idervk41Yk6JPRsl/jJSLsS4bwTpdOY46XVcD2Bn
ImuJktMj6BNIj5bl81CX8PwqzkiCV/jrvWmfSk3Ol5cdyqXR+IrOYznJkSaJRjDERQtcMjOm
28YWWKsf59AYP+n0kD8ROeKDKUZ6Z1nc79iYJhHVt5Zlu+3FtrhH9Czy5a3mH7T/eHnIhU2I
tcpe1q5DOPdzT8xZN4c1uVUz6p6cxqFJMY3YM4UYhn3JdbcdoCs6fCdBctk8qedJZQQuE1WO
gmjiA3Y+ov9wxFEG1jjADRWIeKFT7W33Sq0Sm42kOxN+HI4UA7ZDNs3LOWUSg2Y18+e4S2fr
AAAAAAAA
--------------ms000603020909060709090704--


From nobody Tue Feb 23 11:02:55 2016
Return-Path: 
X-Original-To: dhcwg@ietfa.amsl.com
Delivered-To: dhcwg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C35C81A8896; Tue, 23 Feb 2016 11:02:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] 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 Zjs06HhljWIa; Tue, 23 Feb 2016 11:02:42 -0800 (PST)
Received: from mail-pf0-x236.google.com (mail-pf0-x236.google.com [IPv6:2607:f8b0:400e:c00::236]) (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 3419D1A88D1; Tue, 23 Feb 2016 11:02:42 -0800 (PST)
Received: by mail-pf0-x236.google.com with SMTP id c10so120734799pfc.2; Tue, 23 Feb 2016 11:02:42 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=qXGP03muA8/QQOALYBJ9aWCZvx2BP2Je18AtaZILuyo=; b=qbStRwA3wM1ry53ea79j84PdjDwG5F/0fapkZ69lXZAiNp8vVS3OwpuY3g3rA41BJq sRuLa2PGn/bh7VUEnYqfnFXuKHVB3OhVoWfV+RD2zT98EHLFLYU5JklzboknF9nG65Wy OOSbM66+5iceLDmxjxzgIJpecW44DNVGo+jinQB+8ty4EDaq2BIUON2aUQN3LSG8Vnki mHk0SDSdFyzJaV3Em1PlovohrWMNsTOgJOANsf3R5iL3u7W+LWG+Q3ZbDSFH0n3381M7 Fvs4Kt8Z+1SXQBE+ZBYm0xO2YxvqhM5VoqcX/joe6Qvr3GABlZDFfiOzE9+F9VF/e4wh FSpA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=qXGP03muA8/QQOALYBJ9aWCZvx2BP2Je18AtaZILuyo=; b=JFUdjacede2Bt6FI7iFzDyNjIBLjzspm7gm1eyb0t8MfrlwS+AUB1p0AXwZwgjBq+7 0C5gTBEBRBaME9NWBXIvN0Tml+XIM+yTYbxN4750dVrK9VwVAtLE6LHD68m8CfDwN2cZ sFYmmM0tEs1LUhPULR5IhLwwUxGgmKo6cz4jUDa4CObs1WfQFYyx8RjvGRx117adGbaL B2it9PkPvA8dyhDeFWIsCzTz1SOTQSR1Bi4wtbsno0/k2ujp4dmoDuzEqqY1cFzeRnN/ vuXA3pzISjHShR2qk9cjkZQOq5DpaMPk6TLLC+3Ell7dQYEvfJcy4EIeWshNCeaYryBo dr0w==
X-Gm-Message-State: AG10YORb8YLVKdRF0ybIQQ+gXVO5sELZYrLni0B/FnoGdHjo7nDAx5J1iJ7C6F7NR57QxA==
X-Received: by 10.98.33.70 with SMTP id h67mr48056092pfh.54.1456254161818; Tue, 23 Feb 2016 11:02:41 -0800 (PST)
Received: from ?IPv6:2406:e007:4394:1:28cc:dc4c:9703:6781? ([2406:e007:4394:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id ud10sm46106352pab.27.2016.02.23.11.02.36 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 23 Feb 2016 11:02:40 -0800 (PST)
To: Stephen Farrell , Fernando Gont , Lorenzo Colitti 
References: <20160201142413.30288.23248.idtracker@ietfa.amsl.com>  <003001d1687a$926ab2e0$b74018a0$@huitema.net> <56C3161F.3070301@innovationslab.net>  <56CB891E.6060902@si6networks.com>  <56CBA305.1050400@si6networks.com>  <56CC3BA3.2050303@si6networks.com> <56CCA4EA.1020709@cs.tcd.ie> <56CCA6A8.3030305@si6networks.com> <56CCA87E.8040409@cs.tcd.ie>
From: Brian E Carpenter 
Organization: University of Auckland
Message-ID: <56CCACD0.2050707@gmail.com>
Date: Wed, 24 Feb 2016 08:02:40 +1300
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0
MIME-Version: 1.0
In-Reply-To: <56CCA87E.8040409@cs.tcd.ie>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: IETF Discussion , dhc-chairs@ietf.org, Christian Huitema , iesg@ietf.org, draft-ietf-dhc-anonymity-profile@ietf.org, "dhcwg@ietf.org" 
Subject: [dhcwg] ISDs [was: Last Call:  (Anonymity profile for DHCP clients) to Proposed Standard]
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 23 Feb 2016 19:02:47 -0000

On 24/02/2016 07:44, Stephen Farrell wrote:
> 
> Hiya,
> 
> On 23/02/16 18:36, Fernando Gont wrote:
>>
>> That said... isn't this an indication that we should converge on
>> *something* regarding the meaning of "updates"? (i.e., it should be
>> clear what it means, and what rules should be applied when deciding when
>> a "Updates" tag is warranted or not)
> 
> In theory, yes. I don't find it to be something that I'd prioritise
> myself. I suspect attempts to "fix" this would open a can of worms
> about the general semantics of relationships between RFCs and would
> likely end up being very hard to get done, and with not much benefit
> at the end.

It's clear that there is a problem with "updates", "obsoletes", "normative
reference" and "informative reference" being the only clearly defined
relationships between documents. Sometimes you just need to read a group
of documents with none of these relationships to get the whole picture.

We have a draft solution:
https://tools.ietf.org/html/draft-klensin-isdbis-00

    Brian


From nobody Tue Feb 23 13:21:12 2016
Return-Path: 
X-Original-To: dhcwg@ietfa.amsl.com
Delivered-To: dhcwg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4D771B2D42 for ; Tue, 23 Feb 2016 13:21:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.908
X-Spam-Level: 
X-Spam-Status: No, score=-106.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.006, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 G6v7B6Z9U9ef for ; Tue, 23 Feb 2016 13:21:09 -0800 (PST)
Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D52A1ACD94 for ; Tue, 23 Feb 2016 13:21:09 -0800 (PST)
Received: by rfc-editor.org (Postfix, from userid 30) id C812E180013; Tue, 23 Feb 2016 13:20:36 -0800 (PST)
To: michael.johnston@intel.com, venaas@uninett.no, brian@innovationslab.net, terry.manderson@icann.org, volz@cisco.com, tomasz.mrugalski@gmail.com
X-PHP-Originating-Script: 30:errata_mail_lib.php
From: RFC Errata System 
Message-Id: <20160223212036.C812E180013@rfc-editor.org>
Date: Tue, 23 Feb 2016 13:20:36 -0800 (PST)
Archived-At: 
Cc: dhcwg@ietf.org, dave@natulte.net, rfc-editor@rfc-editor.org
Subject: [dhcwg] [Technical Errata Reported] RFC4578 (4624)
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 23 Feb 2016 21:21:10 -0000

The following errata report has been submitted for RFC4578,
"Dynamic Host Configuration Protocol (DHCP) Options for the Intel Preboot eXecution Environment (PXE)".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=4578&eid=4624

--------------------------------------
Type: Technical
Reported by: David Anderson 

Section: 2.1

Original Text
-------------
            Type   Architecture Name
            ----   -----------------
              0    Intel x86PC
              1    NEC/PC98
              2    EFI Itanium
              3    DEC Alpha
              4    Arc x86
              5    Intel Lean Client
              6    EFI IA32
              7    EFI BC
              8    EFI Xscale
              9    EFI x86-64


Corrected Text
--------------
            Type   Architecture Name
            ----   -----------------
              0    Intel x86PC
              1    NEC/PC98
              2    EFI Itanium
              3    DEC Alpha
              4    Arc x86
              5    Intel Lean Client
              6    EFI IA32
              7    EFI x86-64
              8    EFI Xscale
              9    EFI BC


Notes
-----
The values for EFI BC and EFI x86-64 should be swapped. UEFI imeplementations use value 7 to report EFI x86-64, not value 9. The IANA registry for DHCPv6 options (http://www.iana.org/assignments/dhcpv6-parameters/dhcpv6-parameters.xhtml#processor-architecture) correctly reflects reality, with values 7 and 9 swapped compared to RFC 4578.

Instructions:
-------------
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC4578 (draft-ietf-dhc-pxe-options-03)
--------------------------------------
Title               : Dynamic Host Configuration Protocol (DHCP) Options for the Intel Preboot eXecution Environment (PXE)
Publication Date    : November 2006
Author(s)           : M. Johnston, S. Venaas, Ed.
Category            : INFORMATIONAL
Source              : Dynamic Host Configuration
Area                : Internet
Stream              : IETF
Verifying Party     : IESG


From nobody Wed Feb 24 04:34:53 2016
Return-Path: 
X-Original-To: dhcwg@ietfa.amsl.com
Delivered-To: dhcwg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0A171ACE21; Tue, 23 Feb 2016 15:38:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] 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 cJny4ki361In; Tue, 23 Feb 2016 15:38:04 -0800 (PST)
Received: from mail-yk0-x234.google.com (mail-yk0-x234.google.com [IPv6:2607:f8b0:4002:c07::234]) (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 2F6EE1AC3E2; Tue, 23 Feb 2016 15:38:04 -0800 (PST)
Received: by mail-yk0-x234.google.com with SMTP id u9so862270ykd.1; Tue, 23 Feb 2016 15:38:04 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=8kc4wbI/EJdFnbSwPoh4IeNjFtEOcsQ2PSjfblJ2Vbc=; b=EWV+QrFUT0VJdTy6qJANQ6uaoMWTbv64qoOkdNqJe8MeSqPffGSzpnrwRsVCU0xxIV 6OyJG+YMbQ01qxUxJ8Pq3AjtgWKQCqpTwpHg5sytwmN8a4EGRKGpsPUhDdoPdsR1Aumk 8XI0Y05Sc0CkdwUfM4feG3X1wqA278hXcbujInOKzyFGwMccPBZMVKOB8yxUCSTWEEMr dEPpjFVuC84pPwpl4sUpJpxfdlevgpdO2wRAQlHA8rLOjhqZebg+a/nstAFhcdConyT2 W/zYHZ1LGtbrS0wShdcHxsF1pHfyCF3D9fAvCvb/JQzJo5fcPlBV+nn+MrubkGoG5xjT 0Esw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=8kc4wbI/EJdFnbSwPoh4IeNjFtEOcsQ2PSjfblJ2Vbc=; b=PTITfo65IkgcU0MsKU5G97CzNZE5H6HstW2lWNEFdUG4DfBVV3PX93tP9UWdNpipTT /VIFJocEMNiXQBpvAHGIb6zlfTHBTiiZEODNRXRFbZn1mCM9kDSc/yYBSULm0dhbPi63 bGEA/m2xT6tSrwz8oPv/CXZ3PerUdnkHztE4xtqV0gOBXOCN/PCFXkQVom4phQdwuw68 vs1GYxowZLXLsUVPDxbDDxas8TcanC7eNW+oNaafXhu9X5xNbQXaDIrvLI5bIztzg2// sA9wuGw6+LOYgcG7it5pP0r5JFKnQL7cNk/4/Tf8jk81oQjHfLo5jJfvoDScX/quADKB 2FLw==
X-Gm-Message-State: AG10YOTS8MseC01GQGmWZPvxvlK6DLrRzX3Nad9/y1LAnfC0INS3NoTgHC5CLgpkD+63TjBXiBS1+mUkTtv7Wg==
MIME-Version: 1.0
X-Received: by 10.37.42.87 with SMTP id q84mr8672214ybq.5.1456270683475; Tue, 23 Feb 2016 15:38:03 -0800 (PST)
Received: by 10.37.99.65 with HTTP; Tue, 23 Feb 2016 15:38:03 -0800 (PST)
In-Reply-To: <56CCACD0.2050707@gmail.com>
References: <20160201142413.30288.23248.idtracker@ietfa.amsl.com>  <003001d1687a$926ab2e0$b74018a0$@huitema.net> <56C3161F.3070301@innovationslab.net>  <56CB891E.6060902@si6networks.com>  <56CBA305.1050400@si6networks.com>  <56CC3BA3.2050303@si6networks.com> <56CCA4EA.1020709@cs.tcd.ie> <56CCA6A8.3030305@si6networks.com> <56CCA87E.8040409@cs.tcd.ie> <56CCACD0.2050707@gmail.com>
Date: Tue, 23 Feb 2016 17:38:03 -0600
Message-ID: 
From: Spencer Dawkins at IETF 
To: Brian E Carpenter 
Content-Type: multipart/alternative; boundary=001a114405b6c91c33052c787044
Archived-At: 
X-Mailman-Approved-At: Wed, 24 Feb 2016 04:34:51 -0800
Cc: IETF Discussion , dhc-chairs@ietf.org, Christian Huitema , "iesg@ietf.org" , draft-ietf-dhc-anonymity-profile@ietf.org, "dhcwg@ietf.org" , Stephen Farrell 
Subject: Re: [dhcwg] ISDs [was: Last Call:  (Anonymity profile for DHCP clients) to Proposed Standard]
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 23 Feb 2016 23:38:06 -0000

--001a114405b6c91c33052c787044
Content-Type: text/plain; charset=UTF-8

Hi, Brian,

On Tue, Feb 23, 2016 at 1:02 PM, Brian E Carpenter <
brian.e.carpenter@gmail.com> wrote:

> On 24/02/2016 07:44, Stephen Farrell wrote:
> >
> > Hiya,
> >
> > On 23/02/16 18:36, Fernando Gont wrote:
> >>
> >> That said... isn't this an indication that we should converge on
> >> *something* regarding the meaning of "updates"? (i.e., it should be
> >> clear what it means, and what rules should be applied when deciding when
> >> a "Updates" tag is warranted or not)
> >
> > In theory, yes. I don't find it to be something that I'd prioritise
> > myself. I suspect attempts to "fix" this would open a can of worms
> > about the general semantics of relationships between RFCs and would
> > likely end up being very hard to get done, and with not much benefit
> > at the end.
>
> It's clear that there is a problem with "updates", "obsoletes", "normative
> reference" and "informative reference" being the only clearly defined
> relationships between documents. Sometimes you just need to read a group
> of documents with none of these relationships to get the whole picture.
>
> We have a draft solution:
> https://tools.ietf.org/html/draft-klensin-isdbis-00
>

I remember ISDs, and liked them when we discussed them back in the mists of
history.

I agree that we do try from time to time to use the mechanisms we've got,
to accomplish some of the things ISDs would accomplish.

Spencer

--001a114405b6c91c33052c787044
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Hi, Brian,

On Tue, Feb 23, 2016 at 1:02 PM, Brian E Carpenter <br=
ian.e.carpenter@gmail.com> wrote:
On 24/02/2016 07:44, Stephen Farrell wrote:

>

> Hiya,

>

> On 23/02/16 18:36, Fernando Gont wrote:

>>

>> That said... isn't this an indication that we should converge =
on

>> *something* regarding the meaning of "updates"? (i.e., i=
t should be

>> clear what it means, and what rules should be applied when decidin=
g when

>> a "Updates" tag is warranted or not)

>

> In theory, yes. I don't find it to be something that I'd prior=
itise

> myself. I suspect attempts to "fix" this would open a can of=
 worms

> about the general semantics of relationships between RFCs and would
> likely end up being very hard to get done, and with not much benefit
> at the end.



It's clear that there is a problem with "updates", "obso=
letes", "normative

reference" and "informative reference" being the only clearl=
y defined

relationships between documents. Sometimes you just need to read a group
of documents with none of these relationships to get the whole picture.



We have a draft solution:

https://tools.ietf.org/html/draft-klensin-isdbis-=
00

I remember ISDs, and liked them =
when we discussed them back in the mists of history.

I agree that we do try from time to time to use the mechanisms we've=
 got, to accomplish some of the things ISDs would accomplish.
Spencer=C2=A0



--001a114405b6c91c33052c787044--


From nobody Wed Feb 24 05:16:39 2016
Return-Path: 
X-Original-To: dhcwg@ietfa.amsl.com
Delivered-To: dhcwg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3DE81A0018; Wed, 24 Feb 2016 05:16:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] 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 Aqt_Srsb9vZH; Wed, 24 Feb 2016 05:16:37 -0800 (PST)
Received: from mail-lf0-x22d.google.com (mail-lf0-x22d.google.com [IPv6:2a00:1450:4010:c07::22d]) (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 6A3DF1A03A6; Wed, 24 Feb 2016 05:16:36 -0800 (PST)
Received: by mail-lf0-x22d.google.com with SMTP id l143so11508487lfe.2; Wed, 24 Feb 2016 05:16:36 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=XLCX9U8qZqQ7DDIzQKJJiDh3RF7ii2Jg0GpocSfKc9s=; b=mIUY93+PQjqt9mHxyDa3kMMt1Sko08XcHKq1IC2KUtGiNZD5A6cmwoRhdQzQ3hPMxH wWCPPmHOClGVPD7Z6JeMR9sYwtRlRa9aK4jp04VJbZ6XCTFWDW8LWJh46WXM/d0M9e3a S1rTzJ6l90zstz4eaotRb5ADwkMYNte8TAsvTfTzHDjsukUevQ1TUU5cWHfj1GqmstEW Tvuz8aEfCvXLukrdpyerxMbn689BasVtIFymSUHOl8z+U32DJJ/zCxi2xjz4WHEJbJkA nbx1GDY20u02hPOr9MqRTf5nGlqtTBz4Ci2tGw85FN+/477lHdYlpLizCtTPKM9i4tn0 SWBw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=XLCX9U8qZqQ7DDIzQKJJiDh3RF7ii2Jg0GpocSfKc9s=; b=aWxrD55WiS80H48TPufjjnDns91rtvnwCH1YkUc5IdKQgI1jj7zfn92u7HYA1MvCpF ML4RqiQA6KHLpe377boNwgNZTPzK6hU4+CwWcMoScPoTIeohMPsefz4pcFAiVpHDa9EX vXORpMkzRAgnjE4GhXTMFFjFwGLDAkHTPWSV05K0B+14LYq98r4O8Xi0u4EcUJjfd+4n crJnfsT3x3cwRfLJE9in5Dd2Kq4jpAOfrJoHHLo5kI/hJBRx4E3HfaTTTo7U6+X9qqAT Eo9ewK4CoEQEA1seNhKnk4kSFpzuwGGg7M4A+mXsCc0nO9dQWcuLAi+tDRpGaooX7o1U TIhw==
X-Gm-Message-State: AG10YOTymkBHxIgsJ9yMpmCjPfrGyNBDjTC+jU4e6ULG/QGaDDeamvqgFwGADA7fRcxfqQ==
X-Received: by 10.25.21.29 with SMTP id l29mr11866562lfi.123.1456319794680; Wed, 24 Feb 2016 05:16:34 -0800 (PST)
Received: from [10.0.0.100] (109107011157.gdansk.vectranet.pl. [109.107.11.157]) by smtp.googlemail.com with ESMTPSA id f184sm378712lfe.6.2016.02.24.05.16.32 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 24 Feb 2016 05:16:33 -0800 (PST)
To: Ben Campbell , The IESG 
References: <20160217230718.32558.47975.idtracker@ietfa.amsl.com>
From: Tomek Mrugalski 
X-Enigmail-Draft-Status: N1110
Message-ID: <56CDAD2F.9070505@gmail.com>
Date: Wed, 24 Feb 2016 14:16:31 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1
MIME-Version: 1.0
In-Reply-To: <20160217230718.32558.47975.idtracker@ietfa.amsl.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Archived-At: 
Cc: dhc-chairs@ietf.org, draft-ietf-dhc-dhcpv6-privacy@ietf.org, dhcwg@ietf.org
Subject: Re: [dhcwg] Ben Campbell's Yes on draft-ietf-dhc-dhcpv6-privacy-04: (with COMMENT)
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 24 Feb 2016 13:16:38 -0000

Oops, seems nobody answered this comment yet.

On 18.02.2016 00:07, Ben Campbell wrote:
> Ben Campbell has entered the following ballot position for
> draft-ietf-dhc-dhcpv6-privacy-04: Yes
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> -2:
> If this is strictly an analysis with no proposed solution, why does it
> need 2119 keywords? Actually, I only found one MAY, and that seemed more
> a statement of fact than a new requirement.
2119 references removed, normative language removed (MAY is now lower case).

> -5.6:
> This seems to talk about pervasive monitoring in a very general sense.
> Can you say something about how that specifically relates to dhcpv6?
Sure. Here's the proposed text for section 5.6. The first paragraph
comes from RFC7258 (this addressed a comment made earlier that suggested
to borrow the text directly rather than try to describe PM with our own
words). The last two paragraphs are new. Are they sufficient?

5.6.  Pervasive monitoring

   Pervasive Monitoring (PM) is widespread (and often covert)
   surveillance through intrusive gathering of protocol artefacts,
   including application content, or protocol metadata such as headers.
   Active or passive wiretaps and traffic analysis, (e.g., correlation,
   timing or measuring packet sizes), or subverting the cryptographic
   keys used to secure protocols can also be used as part of pervasive
   monitoring.  PM is distinguished by being indiscriminate and very
   large scale, rather than by introducing new types of technical
   compromise.  See [RFC7258] for a discussion about PM.

   In the DHCPv6 context, PM approach can be used to collect any
   identifiers discussed in Section 3.  DHCPv4 and DHCPv6 are especially
   susceptible as the initial message sent (SOLICIT in case of DHCPv6)
   is one of the very first packets sent when visiting a network.
   Furthermore, in certain cases this packet can be logged even on
   networks that do not support IPv6 (some implementations initiate
   DHCPv6 even without receiving RA with M or O bits set).  This may be
   an easily overlooked attack vector when IPv6-capable device connects
   to an IPv4 only network, gains only IPv4 connectivity, but still
   leaks its stable identifiers over DHCPv6.

   Using PM approach, attacks discussed in Sections 5.1, 5.2, 5.3, 5.4,
   5.5, 5.7, 5.8 and possibly 5.9 apply.

Once we sort out this last comment, I can upload -05 and it should be
ready to go.

Thanks,
Tomek


From nobody Wed Feb 24 07:08:12 2016
Return-Path: 
X-Original-To: dhcwg@ietf.org
Delivered-To: dhcwg@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 96EBC1B2C53; Wed, 24 Feb 2016 07:08:11 -0800 (PST)
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: The IESG 
To: "IETF-Announce" 
X-Test-IDTracker: no
X-IETF-IDTracker: 6.14.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20160224150811.6194.22564.idtracker@ietfa.amsl.com>
Date: Wed, 24 Feb 2016 07:08:11 -0800
Archived-At: 
Cc: volz@cisco.com, dhc-chairs@ietf.org, The IESG , dhcwg@ietf.org, rfc-editor@rfc-editor.org, draft-ietf-dhc-dhcpv6-privacy@ietf.org
Subject: [dhcwg] Document Action: 'Privacy considerations for DHCPv6' to Informational RFC (draft-ietf-dhc-dhcpv6-privacy-04.txt)
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.15
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 24 Feb 2016 15:08:11 -0000

The IESG has approved the following document:
- 'Privacy considerations for DHCPv6'
  (draft-ietf-dhc-dhcpv6-privacy-04.txt) as Informational RFC

This document is the product of the Dynamic Host Configuration Working
Group.

The IESG contact persons are Brian Haberman and Terry Manderson.

A URL of this Internet Draft is:
https://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6-privacy/




Technical Summary: 

This document describes the privacy issues associated with the use of
DHCPv6 (RFC 3315).

Working Group Summary: 

This document analyzes the privacy issues associated with the use of
DHCPv6.

Document Quality: 

This document has had thorough reviews by many interested and
knowledgeable folks (beyond those mentioned in the acknowledgements
section). There were no significant points of difficulty or
controversy with the contents of the document.

Personnel: 

Bernie Volz is the document shepherd. Brian Haberman is the responsible AD. 


From nobody Wed Feb 24 07:09:18 2016
Return-Path: 
X-Original-To: dhcwg@ietf.org
Delivered-To: dhcwg@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 352CC1B2A54; Wed, 24 Feb 2016 07:09:14 -0800 (PST)
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: The IESG 
To: "IETF-Announce" 
X-Test-IDTracker: no
X-IETF-IDTracker: 6.14.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20160224150914.2166.87620.idtracker@ietfa.amsl.com>
Date: Wed, 24 Feb 2016 07:09:14 -0800
Archived-At: 
Cc: volz@cisco.com, dhc-chairs@ietf.org, The IESG , draft-ietf-dhc-anonymity-profile@ietf.org, dhcwg@ietf.org, rfc-editor@rfc-editor.org
Subject: [dhcwg] Protocol Action: 'Anonymity profile for DHCP clients' to Proposed Standard (draft-ietf-dhc-anonymity-profile-08.txt)
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.15
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 24 Feb 2016 15:09:14 -0000

The IESG has approved the following document:
- 'Anonymity profile for DHCP clients'
  (draft-ietf-dhc-anonymity-profile-08.txt) as Proposed Standard

This document is the product of the Dynamic Host Configuration Working
Group.

The IESG contact persons are Brian Haberman and Terry Manderson.

A URL of this Internet Draft is:
https://datatracker.ietf.org/doc/draft-ietf-dhc-anonymity-profile/




Technical Summary: 

This document specifies an anonymity profile for DHCP clients to remain
as anonymous as possible on visited networks.


Working Group Summary: 

This document is an answer to the privacy considerations raised in
draft-ietf-dhc-dhcp-privacy and draft-ietf-dhc-dhcpv6-privacy with respect
to DHCPv4 and DHCPv6, respectively. The profile provides guidelines on the
composition of DHCP or DHCPv6 requests, designed to minimize disclosure of
identifying information.

Document Quality: 

This document has had thorough reviews by many interested and
knowledgeable folks (beyond those mentioned in the acknowledgements
section). There were no significant points of difficulty or
controversy with the contents of the document.

Microsoft did a prototype implementation and reported great results (see
https://www.ietf.org/proceedings/93/slides/slides-93-dhc-1.pdf).

Personnel: 

Bernie Volz is the document shepherd. Brian Haberman is the responsible AD.


From nobody Wed Feb 24 07:10:22 2016
Return-Path: 
X-Original-To: dhcwg@ietfa.amsl.com
Delivered-To: dhcwg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABCFD1B32B1; Wed, 24 Feb 2016 07:10:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.906
X-Spam-Level: 
X-Spam-Status: No, score=-1.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.006] 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 WOD9B6oMpJ8F; Wed, 24 Feb 2016 07:10:18 -0800 (PST)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 2C7F71B2DFB; Wed, 24 Feb 2016 07:10:18 -0800 (PST)
Received: from [10.0.1.10] (cpe-70-119-203-4.tx.res.rr.com [70.119.203.4]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id u1OFA9Zl095943 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 24 Feb 2016 09:10:09 -0600 (CST) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-70-119-203-4.tx.res.rr.com [70.119.203.4] claimed to be [10.0.1.10]
From: "Ben Campbell" 
To: "Tomek Mrugalski" 
Date: Wed, 24 Feb 2016 09:10:09 -0600
Message-ID: <69F11960-F355-4344-B2E3-069145F231ED@nostrum.com>
In-Reply-To: <56CDAD2F.9070505@gmail.com>
References: <20160217230718.32558.47975.idtracker@ietfa.amsl.com> <56CDAD2F.9070505@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; format=flowed
X-Mailer: MailMate (1.9.4r5226)
Archived-At: 
Cc: dhc-chairs@ietf.org, The IESG , dhcwg@ietf.org, draft-ietf-dhc-dhcpv6-privacy@ietf.org
Subject: Re: [dhcwg] Ben Campbell's Yes on draft-ietf-dhc-dhcpv6-privacy-04: (with COMMENT)
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 24 Feb 2016 15:10:20 -0000

This all looks good to me, thanks!

On 24 Feb 2016, at 7:16, Tomek Mrugalski wrote:

> Oops, seems nobody answered this comment yet.
>
> On 18.02.2016 00:07, Ben Campbell wrote:
>> Ben Campbell has entered the following ballot position for
>> draft-ietf-dhc-dhcpv6-privacy-04: Yes
>> ----------------------------------------------------------------------
>> COMMENT:
>> ----------------------------------------------------------------------
>>
>> -2:
>> If this is strictly an analysis with no proposed solution, why does 
>> it
>> need 2119 keywords? Actually, I only found one MAY, and that seemed 
>> more
>> a statement of fact than a new requirement.
> 2119 references removed, normative language removed (MAY is now lower 
> case).
>
>> -5.6:
>> This seems to talk about pervasive monitoring in a very general 
>> sense.
>> Can you say something about how that specifically relates to dhcpv6?
> Sure. Here's the proposed text for section 5.6. The first paragraph
> comes from RFC7258 (this addressed a comment made earlier that 
> suggested
> to borrow the text directly rather than try to describe PM with our 
> own
> words). The last two paragraphs are new. Are they sufficient?
>
> 5.6.  Pervasive monitoring
>
>    Pervasive Monitoring (PM) is widespread (and often covert)
>    surveillance through intrusive gathering of protocol artefacts,
>    including application content, or protocol metadata such as 
> headers.
>    Active or passive wiretaps and traffic analysis, (e.g., 
> correlation,
>    timing or measuring packet sizes), or subverting the cryptographic
>    keys used to secure protocols can also be used as part of pervasive
>    monitoring.  PM is distinguished by being indiscriminate and very
>    large scale, rather than by introducing new types of technical
>    compromise.  See [RFC7258] for a discussion about PM.
>
>    In the DHCPv6 context, PM approach can be used to collect any
>    identifiers discussed in Section 3.  DHCPv4 and DHCPv6 are 
> especially
>    susceptible as the initial message sent (SOLICIT in case of DHCPv6)
>    is one of the very first packets sent when visiting a network.
>    Furthermore, in certain cases this packet can be logged even on
>    networks that do not support IPv6 (some implementations initiate
>    DHCPv6 even without receiving RA with M or O bits set).  This may 
> be
>    an easily overlooked attack vector when IPv6-capable device 
> connects
>    to an IPv4 only network, gains only IPv4 connectivity, but still
>    leaks its stable identifiers over DHCPv6.
>
>    Using PM approach, attacks discussed in Sections 5.1, 5.2, 5.3, 
> 5.4,
>    5.5, 5.7, 5.8 and possibly 5.9 apply.
>
> Once we sort out this last comment, I can upload -05 and it should be
> ready to go.
>
> Thanks,
> Tomek


From nobody Wed Feb 24 07:41:22 2016
Return-Path: 
X-Original-To: dhcwg@ietf.org
Delivered-To: dhcwg@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 35B5E1B3692; Wed, 24 Feb 2016 07:41:21 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: 
X-Test-IDTracker: no
X-IETF-IDTracker: 6.14.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20160224154121.1119.66746.idtracker@ietfa.amsl.com>
Date: Wed, 24 Feb 2016 07:41:21 -0800
Archived-At: 
Cc: dhcwg@ietf.org
Subject: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-privacy-05.txt
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.15
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 24 Feb 2016 15:41:21 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Dynamic Host Configuration of the IETF.

        Title           : Privacy considerations for DHCPv6
        Authors         : Suresh Krishnan
                          Tomek Mrugalski
                          Sheng Jiang
	Filename        : draft-ietf-dhc-dhcpv6-privacy-05.txt
	Pages           : 18
	Date            : 2016-02-24

Abstract:
   DHCPv6 is a protocol that is used to provide addressing and
   configuration information to IPv6 hosts.  This document describes the
   privacy issues associated with the use of DHCPv6 by the Internet
   users.  It is intended to be an analysis of the present situation and
   does not propose any solutions.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6-privacy/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-privacy-05

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-dhc-dhcpv6-privacy-05


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From nobody Wed Feb 24 07:45:34 2016
Return-Path: 
X-Original-To: dhcwg@ietfa.amsl.com
Delivered-To: dhcwg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 026371B375A for ; Wed, 24 Feb 2016 07:45:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] 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 bivfgRr2Xblm for ; Wed, 24 Feb 2016 07:45:29 -0800 (PST)
Received: from mail-lb0-x229.google.com (mail-lb0-x229.google.com [IPv6:2a00:1450:4010:c04::229]) (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 1D08A1B3738 for ; Wed, 24 Feb 2016 07:45:29 -0800 (PST)
Received: by mail-lb0-x229.google.com with SMTP id x4so12753646lbm.0 for ; Wed, 24 Feb 2016 07:45:28 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-type:content-transfer-encoding; bh=tBjxK8SgrhS9kPmYO37G6LpY+yhNlyozM53mHPY34UY=; b=VXb3AwA00EqUTlIk6szKbwEqs5sagKYemtBO3KdRl5DIzKIQw+MI/k9eIfCTJwtQiV cKec+W2CrZ/4mDP2tICNNFs96CXVedh/1rZeUsIcPUeuCWwbT9A7qyyrQ0Wh5WlmVA/y ugayc7m+b/A9gsXEqWhoIH6kzyIMY2GzmZz0SCbYk6kCn/eP3lvk/nFn+FbizeI+O7FR 4WHIAJCYzux5fkkJGqNGjtEPTJOudPqt8g1LNXZlfa1pKNtSB9WFALi6w6zQua+Li4tp lSAN1eFv7PBeuCZsQmfWehOlzS9Wk6eGhI1fPXJjPH7OX//E8+pWoSC7E7rnNROaBhrl O3fw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=tBjxK8SgrhS9kPmYO37G6LpY+yhNlyozM53mHPY34UY=; b=YKo7KZ+gFrgbpajJ3FHDexdczRGpkyK/ve/LAgTdv3MMcH0tarj71eisYabh6Z97cT HzlrbmjbdA59l525h+YYatkJ5+eZo5BI2T0ecnCkKu8Jr2z38eEaTNoEUmgKCzdNRPtW +dgTC5Tv8kg8BFsKGVLYN8YkPXvah9dYF+H/NZPL29liawkcfltPmE941QvR2W56zozY XD9OCUI6HhopCtfvZPCUEv8798GQqvcCD/oefW5IIuBYOaAyZAmyfsv9MM93/O3+v31p TOdurp4fyv8acholl42CNUPcUjMvUj9io+wXhs/D+dePlO+0oedb1YD5xKT0tK4WqIKA HphQ==
X-Gm-Message-State: AG10YORmgfOb+mxIObsra3GwCisQfEMa75EEEIdRd19XEw4wHwJCeRj5+xYmQALMkRjv3A==
X-Received: by 10.112.91.38 with SMTP id cb6mr162194lbb.35.1456328727315; Wed, 24 Feb 2016 07:45:27 -0800 (PST)
Received: from [10.0.0.100] (109107011157.gdansk.vectranet.pl. [109.107.11.157]) by smtp.googlemail.com with ESMTPSA id y184sm469050lfd.16.2016.02.24.07.45.26 for  (version=TLSv1/SSLv3 cipher=OTHER); Wed, 24 Feb 2016 07:45:26 -0800 (PST)
To: dhcwg@ietf.org
References: <20160224154121.1119.66746.idtracker@ietfa.amsl.com>
From: Tomek Mrugalski 
Message-ID: <56CDD015.1060501@gmail.com>
Date: Wed, 24 Feb 2016 16:45:25 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1
MIME-Version: 1.0
In-Reply-To: <20160224154121.1119.66746.idtracker@ietfa.amsl.com>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-privacy-05.txt
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 24 Feb 2016 15:45:31 -0000

This update addresses the last two comments from IESG:

- removed 2119 normative language

- add an extra paragraph about pervasive monitoring. It elaborates a
bit about how PM can glean information from DHCPv6.

The document is now approved by IESG and should appear in RFC-Ed queue
shortly.

Tomek

On 24.02.2016 16:41, internet-drafts@ietf.org wrote:
> 
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the Dynamic Host Configuration of the IETF.
> 
>         Title           : Privacy considerations for DHCPv6
>         Authors         : Suresh Krishnan
>                           Tomek Mrugalski
>                           Sheng Jiang
> 	Filename        : draft-ietf-dhc-dhcpv6-privacy-05.txt
> 	Pages           : 18
> 	Date            : 2016-02-24
> 
> Abstract:
>    DHCPv6 is a protocol that is used to provide addressing and
>    configuration information to IPv6 hosts.  This document describes the
>    privacy issues associated with the use of DHCPv6 by the Internet
>    users.  It is intended to be an analysis of the present situation and
>    does not propose any solutions.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6-privacy/
> 
> There's also a htmlized version available at:
> https://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-privacy-05
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-dhc-dhcpv6-privacy-05
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> _______________________________________________
> dhcwg mailing list
> dhcwg@ietf.org
> https://www.ietf.org/mailman/listinfo/dhcwg
> 


From nobody Wed Feb 24 09:25:16 2016
Return-Path: 
X-Original-To: dhcwg@ietfa.amsl.com
Delivered-To: dhcwg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02BC11B39BE; Wed, 24 Feb 2016 09:25:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.506
X-Spam-Level: 
X-Spam-Status: No, score=-14.506 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 Uihad7an3Urs; Wed, 24 Feb 2016 09:25:09 -0800 (PST)
Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5DFD01B39C7; Wed, 24 Feb 2016 09:25:08 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12449; q=dns/txt; s=iport; t=1456334708; x=1457544308; h=from:to:cc:subject:date:message-id:mime-version; bh=RquXYlpSFEbKBMbVE8hf3DmVpjoJk0wCPZJ8K6GUHPo=; b=CugbzbmRKij3hTesX0L7KoWISHCFHVKC9G4YfeK6vrCofmG+fjZZUiRW 7nl+qDO0N6RxIdnmIKFfik4bB/2eKT+72HIOO30xBgZ16SSDLXOukn+z6 Y03FB5kZrPtntzNNtdqYDr2GKnpeYl7YsqjnQexPFwy8O5zBFGzLf2Yu0 4=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BeBwB95s1W/4YNJK1EGoJuTFJtAQW6R?= =?us-ascii?q?isBDYFmI4VrgUc4FAEBAQEBAQFkHAuERAQtTBIBOAw8JgEEDg2IFw4stDuJYAE?= =?us-ascii?q?BAQEBAQEBAQEBAQEBAQEBAQEBARWKTIN8Jz8hg2wFlwcBhVeIAIIwjEuOSAEPD?= =?us-ascii?q?wEBQoIDGRSBNGoBhmJ9AQEB?=
X-IronPort-AV: E=Sophos;i="5.22,494,1449532800";  d="scan'208,217";a="240246803"
Received: from alln-core-12.cisco.com ([173.36.13.134]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 24 Feb 2016 17:25:07 +0000
Received: from XCH-RCD-001.cisco.com (xch-rcd-001.cisco.com [173.37.102.11]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id u1OHP721021386 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 24 Feb 2016 17:25:07 GMT
Received: from xch-aln-003.cisco.com (173.36.7.13) by XCH-RCD-001.cisco.com (173.37.102.11) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 24 Feb 2016 11:25:06 -0600
Received: from xch-aln-003.cisco.com ([173.36.7.13]) by XCH-ALN-003.cisco.com ([173.36.7.13]) with mapi id 15.00.1104.009; Wed, 24 Feb 2016 11:25:06 -0600
From: "Bernie Volz (volz)" 
To: "dhcwg@ietf.org" 
Thread-Topic: Reminder - Monthly draft-ietf-dhc-rfc3315bis co-author (3/2/2016 - 0800-0900 (EST - USA))
Thread-Index: AdFvKABPUB5Y5TFpTIioP7/W5kp1sw==
Date: Wed, 24 Feb 2016 17:25:06 +0000
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.131.77.57]
Content-Type: multipart/alternative; boundary="_000_c2beb42b49d34812a7d0d87dcc971920XCHALN003ciscocom_"
MIME-Version: 1.0
Archived-At: 
Cc: "'dhcpv6bis@ietf.org'" 
Subject: [dhcwg] Reminder - Monthly draft-ietf-dhc-rfc3315bis co-author (3/2/2016 - 0800-0900 (EST - USA))
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 24 Feb 2016 17:25:14 -0000

--_000_c2beb42b49d34812a7d0d87dcc971920XCHALN003ciscocom_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi:

This is to notify the DHC WG that there will be a draft-ietf-dhc-rfc3315bis=
 co-author meeting at 0800 to 0900 EST (USA) on Wed Mar 2, 2016. Those inte=
rested in participating may join the discussion. We will use https://jitsi.=
tools.ietf.org/dhcpv6 (with a WebEx as backup in case of issues - see below=
).

Here's the proposed agenda.


1.       Review assigned tickets.

2.       Review other open tickets.

3.       draft-ietf-dhc-rfc3315bis-04 publication (target 3/14 - deadline i=
s 3/31 for IETF-95).

4.       Determine whether to meet at IETF-95 (date/time will be determined=
 later once IETF-95 agenda is out).

Note: We will not hold the monthly call on Wed 4/6.


The tickets for this work can be viewed at http://trac.tools.ietf.org/group=
/dhcpv6bis/report.



While we intend to use jitsi (see above), a WebEx has been scheduled in cas=
e of issues with jitsi:



JOIN WEBEX MEETING

https://cisco.webex.com/ciscosales/j.php?MTID=3Dm22f09f2a39b354becf5825d8b9=
d6af37

Meeting number:   206 329 100

Meeting password: dhc



Global call-in numbers:

https://cisco.webex.com/ciscosales/globalcallin.php?serviceType=3DMC&ED=3D3=
21678407&tollFree=3D1


-          Bernie


--_000_c2beb42b49d34812a7d0d87dcc971920XCHALN003ciscocom_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Hi:

 =



This is to notify the DH=
C WG that there will be a draft-ietf-dhc-rfc3315bis co-author meeting at 08=
00 to 0900 EST (USA) on Wed Mar 2, 2016. Those interested in participating =
may join the discussion. We will use
https://jitsi.tools.ietf.org/dhcpv6 (with a WebEx as backup in =
case of issues – see below).


 =



Here’s the propose=
d agenda.


 =



1.&nbs=
p;     
Review assigned =
tickets.


2.&nbs=
p;     
Review other ope=
n tickets.


3.&nbs=
p;     
draft-ietf-dhc-r=
fc3315bis-04 publication (target 3/14 – deadline is 3/31 for IETF-95)=
.


4.&nbs=
p;     
Determine whethe=
r to meet at IETF-95 (date/time will be determined later once IETF-95 agend=
a is out).


Note: We will not=
 hold the monthly call on Wed 4/6.


 =



The tickets for this =
work can be viewed at
http://trac.tools.ietf.org/group/dhcpv6bis/report.


 


While we intend to us=
e jitsi (see above), a WebEx has been scheduled in case of issues with jits=
i:


 


JOIN WEBEX MEETING


https://cisco.webex.com/ciscosales/j.php?MTID=3Dm=
22f09f2a39b354becf5825d8b9d6af37


Meeting number: =
  206 329 100


Meeting password: dhc=



 


Global call-in number=
s:


https://cisco.webex.com/ci=
scosales/globalcallin.php?serviceType=3DMC&ED=3D321678407&tollFree=
=3D1


 =



- =
;        
Bernie


 






--_000_c2beb42b49d34812a7d0d87dcc971920XCHALN003ciscocom_--


From nobody Wed Feb 24 09:56:25 2016
Return-Path: 
X-Original-To: dhcwg@ietfa.amsl.com
Delivered-To: dhcwg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BA231A004A; Wed, 24 Feb 2016 09:56:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.577
X-Spam-Level: *
X-Spam-Status: No, score=1.577 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, FRT_BIGGERMEM1=2.555, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=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 xZZ0bG4gD2o5; Wed, 24 Feb 2016 09:56:21 -0800 (PST)
Received: from mail-io0-x232.google.com (mail-io0-x232.google.com [IPv6:2607:f8b0:4001:c06::232]) (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 8784A1A6FFB; Wed, 24 Feb 2016 09:56:21 -0800 (PST)
Received: by mail-io0-x232.google.com with SMTP id g203so55165390iof.2; Wed, 24 Feb 2016 09:56:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=x2HRWgOXcf6OfJwQw+wQhS53rBo1N1FaPSvv0UpQta0=; b=zQBQI0opYpjkVPA/DGNeWlXEczGllhrN83udFJ1H3Lnbw21uzZkfcJI20xsX3xqSlE aB6bLlX/WNz2PMyp4UDuC2IKL8r+N+WZqcsNKKRlc3w+bM47KwxH8qqA+b66rn3mGJvS yMuC4Tccs7kwhBmMIrAkrLf+nvXyuyFLlDhEcaLXhGyVrcQKuQknDGuFjq8WgoiETwuD GZYSkvP0gpOczgZyP3mKSUE9Abh72PnIy6oDz4Kx7z7w2rVw2Arjn6FxYIPUl5Wf52ec OT1LOYgJzUNeQrKXMi+lorzLLm8vrDQk883JwvU0xwbBwEQtR2nMmbUlotf+uHSFFWoG ciTA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=x2HRWgOXcf6OfJwQw+wQhS53rBo1N1FaPSvv0UpQta0=; b=meIX5NJbbW4vqIJIMvOcadQLb4Dm+rvuEG+qKtQ8ko8UnzW2aplcdKdfJpbETubCB8 tQe3MqYt8xnOH7MwOEGnG1F/4ti48Px01NA5iJ6DwSVuww0MNG3euJKI4+Ko4IXshSs4 nkX5GCwqz7hMiaNRWLdqhOjwjX//Iqd8O4WFot4uMIOsxlo4P3H84KbwBK/f1AUlAtsn iAZCVfEiBqgtjGfXSIKbFAoo6zeXcHmIXS+6X+kcf+ZbKw0Y6GpoxiUGS6OmEKgH6i/p BMDVBI+ZOgJ1w/woenCVaDhvXHF02oAUjXDS0Me83q9W8WaazUBTuRp+2OCw+bl5fudR tSyw==
X-Gm-Message-State: AG10YOSke4DmEg7mYLbQma9TxNfz+bk7zQAjIIp60ktBsLYbAo+ywFWbubFR+OAaxaZANRe/nTeYjmi0pJjw/g==
MIME-Version: 1.0
X-Received: by 10.107.137.142 with SMTP id t14mr43528803ioi.172.1456336580577;  Wed, 24 Feb 2016 09:56:20 -0800 (PST)
Sender: jinmei.tatuya@gmail.com
Received: by 10.107.169.35 with HTTP; Wed, 24 Feb 2016 09:56:20 -0800 (PST)
In-Reply-To: 
References:      
Date: Wed, 24 Feb 2016 09:56:20 -0800
X-Google-Sender-Auth: FJvc7ysJmYfDyfaTRM3TfDAG9uI
Message-ID: 
From: =?UTF-8?B?56We5piO6YGU5ZOJ?= 
To: Lishan Li 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Cc: "dhcwg@ietf.org" , draft-ietf-dhc-sedhcpv6@ietf.org
Subject: Re: [dhcwg] comments on draft-ietf-dhc-sedhcpv6-10.txt
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 24 Feb 2016 17:56:23 -0000

(I've removed draft-ietf-dhc-sedhcpv6@ietf.org)

At Tue, 23 Feb 2016 10:45:40 +0800,
Lishan Li  wrote:

> > I'm still not sure if my point was made clear...so let me be more
> > specific: in the following message exchanges:
> >
> > 1. Information-request from client to server(s)
> > 2. Reply to the Information-request from server(s) to client
> > 3. Encryption-Query from client to server
> > 4. Encryption-Response from server to client
> >
> > did you mean the Reply message of exchange #2?
> >
> > If so, do you at least agree that it makes almost no sense to include
> > the explicit separate signature in messages 3 and 4?
> >
> > [LS]: Yes, I mean the Reply message of exchange #2. The reply message
> contains the signature option and timestamp option for message integrity
> check. In the #3 and #4 messages, the DHCPv6 messages are encrypted, so t=
he
> signature and timestamp option are not contained.
> What do you think of it?

Okay.  So focusing on the Reply message (#2): my point was:

- in effect, its only content is the certificate (or public key).
- the recipient is already expected to validate this only content
  directly (by comparing it with locally pre-configured info, by using
  a PKI, etc), so we do not necessarily need to provide additional
  integrity protection for it by signing the message.
- on the other hand, if we eliminate the signing and the signature
  option from this, we'll completely eliminate this option from the
  protocol.  This will help make the protocol simpler and reduce
  development costs.

If you still disagree, perhaps it helps if you can show a specific
attack vector because of the lack of the signature.

> > Right, but this argument also holds even if we have TOFU...
> >
> > > So, I think that
> > > the certificate option is enough for authentication.
> > > Looking forward to your further guidance.
> >
> > ...so these don't explain why we should now remove the public key
> > option.  One obvious, though possibly relatively minor, drawback of
> > only having a certificate is that it will make the message size even
> > bigger when we actually only need the public key.
> >
> > I'm not necessarily opposed to removing the public key option if we
> > cover all such discussions and reach consensus, but I don't think I've
> > seen it yet.
> >
> > [LS]: In consideration of the support of TOFU and the add of all such
> discussions and consensus, the better way for us is to add the public key
> option as the before secure DHCPv6 version.
> Am I correct?

No, I just didn't see why the public key option was removed (the
explanation regarding TOFU didn't make sense to me).  As I already
said, I'm not necessarily opposed to removing it if there's a
convincing reason that can outweigh its cons.

> > > > >- Section 6

> > Introducing a new error code is related but a minor point.  My
> > question was about what the client should do if it sees that code (or
> > whatever signal that indicates this kind of failure).
> >
> [LS]: As you said before, the DecryptionFail failure is equivalent to
> SignatureFail. So if the client sees that code, the client MAY resend the
> message following normal retransmission routines defined in [RFC3315].
> Am I correct?

Not sure if you are correct:-), but, yes, that answers my question.
Whether this behavior makes most sense is a different question, on
which I don't yet have a particular idea.  Maybe I should first see a
revised draft in full text.

> > p.s. there's another bigger open issue I separated from the rest of
> > the discussions:
> > https://mailarchive.ietf.org/arch/msg/dhcwg/-tZBpeMs-EiVyMm0MLBpj3dFYNI

Reminder: this is still open.

> > [LS]: Another open isssue is that:
> If the server receives the Information-request message but it does not
> support this work, what should the server do?
> In my opinion, if the server don't support this work, it has two choices:
> 1. drop the received Information-request message;
> In this way, the client will not receive any message which illustrate the
> server don't support secure DHCPv6. If there is no authenticated DHCPv6
> server, the client may resend the Information-request message;
> 2. send the Reply message with the corresponding error status code to the
> client=EF=BC=9B
> This way will introduce the downgrade attack, a third party may send the
> Reply message with the corresponding error status code. And then the DHCP=
v6
> configuration process may be unsecured.
> I prefer the first one solution. Which one would you prefer? Looking
> forward to your guidance.

I'd simply expect the usual behavior: the server will return a Reply
(obviously) without the requested information (which, in this case,
the certificate or public key option).  I don't think we can eliminate
the possibility of downgrade attack by an on-path attacker, however we
specify the behavior in this case.

--
jinmei


From nobody Wed Feb 24 10:20:44 2016
Return-Path: 
X-Original-To: dhcwg@ietfa.amsl.com
Delivered-To: dhcwg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6153D1B3B53; Wed, 24 Feb 2016 10:20:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -11.652
X-Spam-Level: 
X-Spam-Status: No, score=-11.652 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FRT_BIGGERMEM1=2.555, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 4uNHW5rtO9MI; Wed, 24 Feb 2016 10:20:37 -0800 (PST)
Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E925F1B3B49; Wed, 24 Feb 2016 10:20:36 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9640; q=dns/txt; s=iport; t=1456338037; x=1457547637; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=oLorh92WSTAn0czi7VnWtbQXnf3C5hOZlI9liF1EoDc=; b=DmsggWm0VLMW1IWSpAUwNf3/KePUTGP7nCx8oo4fR2OjdNTC8ZCkQ4Jv v2OjrY/suEDx39mG6VqQQcL/dk7CVr9BImdtzs+gKyvDtGwav1AzzmAcC pOd50MImZjdh4RQcVbaFEZNQU1x7IbYSb6griXRyi7wgCIrFuOcxef2ms 4=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AMAgCp881W/5FdJa1egzpSbQarNY8/A?= =?us-ascii?q?Q2BZhcKhW0CHIEqOBQBAQEBAQEBZCeEQQEBAQMBAQEBIBE6CwwEAgEIEQQBAQM?= =?us-ascii?q?CIwMCAgIfBgsUAQgIAgQBDQUIE4dvAwoIDq8PihUNhEMBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQERBHuJUYI6gUoZLoJqgToFh1OHCIgsAYVXhhSBbIFljRaFcoETh0M?= =?us-ascii?q?BHgEBQoIDGYFIaoYoJRZ9AQEB?=
X-IronPort-AV: E=Sophos;i="5.22,494,1449532800"; d="scan'208";a="241948843"
Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 24 Feb 2016 18:20:36 +0000
Received: from XCH-RCD-004.cisco.com (xch-rcd-004.cisco.com [173.37.102.14]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id u1OIKZfU023826 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 24 Feb 2016 18:20:35 GMT
Received: from xch-aln-003.cisco.com (173.36.7.13) by XCH-RCD-004.cisco.com (173.37.102.14) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 24 Feb 2016 12:20:34 -0600
Received: from xch-aln-003.cisco.com ([173.36.7.13]) by XCH-ALN-003.cisco.com ([173.36.7.13]) with mapi id 15.00.1104.009; Wed, 24 Feb 2016 12:20:34 -0600
From: "Bernie Volz (volz)" 
To: =?utf-8?B?56We5piO6YGU5ZOJ?= , Lishan Li 
Thread-Topic: [dhcwg] comments on draft-ietf-dhc-sedhcpv6-10.txt
Thread-Index: AQHRSaCZXqKi2gG2DkeNiN4pYfommZ7/32AAgAI5DACABHlDgIAM1sYAgCYxbwCAApDEAP//nUBg
Date: Wed, 24 Feb 2016 18:20:34 +0000
Message-ID: <15449b1ae05a40a38afde57d4a0975a6@XCH-ALN-003.cisco.com>
References:       
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.131.77.57]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: 
Cc: "dhcwg@ietf.org" , "draft-ietf-dhc-sedhcpv6@ietf.org" 
Subject: Re: [dhcwg] comments on draft-ietf-dhc-sedhcpv6-10.txt
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 24 Feb 2016 18:20:43 -0000

UmVnYXJkaW5nIHRoZSBsYXN0IHBvaW50LCBKaW5tZWkgd3JvdGU6DQoNCiJJJ2Qgc2ltcGx5IGV4
cGVjdCB0aGUgdXN1YWwgYmVoYXZpb3I6IHRoZSBzZXJ2ZXIgd2lsbCByZXR1cm4gYSBSZXBseQ0K
KG9idmlvdXNseSkgd2l0aG91dCB0aGUgcmVxdWVzdGVkIGluZm9ybWF0aW9uICh3aGljaCwgaW4g
dGhpcyBjYXNlLCB0aGUgY2VydGlmaWNhdGUgb3IgcHVibGljIGtleSBvcHRpb24pLiAgSSBkb24n
dCB0aGluayB3ZSBjYW4gZWxpbWluYXRlIHRoZSBwb3NzaWJpbGl0eSBvZiBkb3duZ3JhZGUgYXR0
YWNrIGJ5IGFuIG9uLXBhdGggYXR0YWNrZXIsIGhvd2V2ZXIgd2Ugc3BlY2lmeSB0aGUgYmVoYXZp
b3IgaW4gdGhpcyBjYXNlLiINCg0KWWVzLCBhbiB1bmNoYW5nZWQgc2VydmVyIHdvdWxkIHJlc3Bv
bmQgdG8gdGhlIEluZm9ybWF0aW9uLVJlcXVlc3Qgd2l0aCBsaWtlbHkgYSBtaW5pbWFsIFJlcGx5
IChqdXN0IHNlcnZlci1kdWlkKS4gSXQgaXMgYWxzbyBwb3NzaWJsZSB0aGF0IHRoZXJlIGFyZSBz
ZXJ2ZXJzIHRoYXQgZG9uJ3QgUmVwbHkgaW4gdGhpcyBjYXNlIChzaW5jZSBwcm92aWRpbmcgbm90
aGluZyBtaWdodCBiZSBhcmd1ZWQgYXMgZmFpcmx5IHVzZWxlc3MpLg0KDQpZb3UgbWlnaHQgd2Fu
dCB0byB1cGRhdGUgdGhlIHNlY3Rpb24gNi4gIERIQ1B2NiBDbGllbnQgQmVoYXZpb3IgdGV4dCBi
ZWxvdzoNCg0KICAgSWYgdGhlcmUgYXJlIG5vIGF1dGhlbnRpY2F0ZWQgREhDUHY2IHNlcnZlcnMg
b3INCiAgIGV4aXN0aW5nIHNlcnZlcnMgZmFpbGVkIGF1dGhlbnRpY2F0aW9uLCB0aGUgY2xpZW50
IGJlaGF2aW9yIGlzIHBvbGljeQ0KICAgc3BlY2lmaWMuICBEZXBlbmRpbmcgb24gaXRzIHBvbGlj
eSwgaXQgY2FuIGNob29zZSB0byBjb25uZWN0IHVzaW5nDQogICBwbGFpbiwgdW5lbmNyeXB0ZWQg
REhDUHY2LCByZXBlYXQgdGhlIHNlcnZlciBkaXNjb3ZlcnkgcHJvY2VzcyBhZnRlcg0KICAgY2Vy
dGFpbiBkZWxheSBvciBhdHRlbXB0IHRvIGNvbm5lY3QgdG8gYSBkaWZmZXJlbnQgbmV0d29yay4g
IFRoZQ0KICAgY2xpZW50IE1VU1QgTk9UIGNvbmR1Y3QgdGhlIHNlcnZlciBkaXNjb3ZlcnkgcHJv
Y2VzcyBpbW1lZGlhdGVseSB0bw0KICAgYXZvaWQgdGhlIHBhY2tldCBzdG9ybS4NCg0KVG8gaW5k
aWNhdGUgdGhhdCBhIGNsaWVudCBzaG91bGQgcmV0cnkgYSBudW1iZXIgb2YgdGltZXMgYmVmb3Jl
IHRha2luZyBzb21lIGFsdGVybmF0aXZlIGFjdGlvbiAoZGVwZW5kaW5nIG9uIHBvbGljeSkgLSB0
aGF0IHdvdWxkIG1ha2UgaXQgbW9yZSBkaWZmaWN1bHQgZm9yIGEgcm9ndWUgc2VydmVyIHRvIGJl
YXQgb3V0IGEgYnVzeSAicmVhbCIgc2VydmVyLg0KDQpCVFc6IEEgc2ltcGxlIHdheSB0byBhdm9p
ZCB0aGUgcGFja2V0IHN0b3JtIGlzIHRvIGp1c3Qgbm90IGNhbmNlbCB0aGUgcmV0cmFuc21pc3Np
b24gdGltZXIgdW5sZXNzIGEgImdvb2QiIFJlcGx5IGlzIHJlY2VpdmVkOyBhbmQganVzdCBsZXQg
dGhlIHJldHJhbnNtaXNzaW9uIHRpbWVyICh3aXRoIGJhY2sgb2ZmIGFzIHBlciBSRkMgMzMxNSBz
ZWN0aW9uIDE4LjEuNS4pIGhhbmRsZSBpdC4NCg0KLSBCZXJuaWUNCg0KLS0tLS1PcmlnaW5hbCBN
ZXNzYWdlLS0tLS0NCkZyb206IGRoY3dnIFttYWlsdG86ZGhjd2ctYm91bmNlc0BpZXRmLm9yZ10g
T24gQmVoYWxmIE9mID8/Pz8NClNlbnQ6IFdlZG5lc2RheSwgRmVicnVhcnkgMjQsIDIwMTYgMTI6
NTYgUE0NClRvOiBMaXNoYW4gTGkgPGxpbGlzaGFuNDhAZ21haWwuY29tPg0KQ2M6IGRoY3dnQGll
dGYub3JnOyBkcmFmdC1pZXRmLWRoYy1zZWRoY3B2NkBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtk
aGN3Z10gY29tbWVudHMgb24gZHJhZnQtaWV0Zi1kaGMtc2VkaGNwdjYtMTAudHh0DQoNCihJJ3Zl
IHJlbW92ZWQgZHJhZnQtaWV0Zi1kaGMtc2VkaGNwdjZAaWV0Zi5vcmcpDQoNCkF0IFR1ZSwgMjMg
RmViIDIwMTYgMTA6NDU6NDAgKzA4MDAsDQpMaXNoYW4gTGkgPGxpbGlzaGFuNDhAZ21haWwuY29t
PiB3cm90ZToNCg0KPiA+IEknbSBzdGlsbCBub3Qgc3VyZSBpZiBteSBwb2ludCB3YXMgbWFkZSBj
bGVhci4uLnNvIGxldCBtZSBiZSBtb3JlDQo+ID4gc3BlY2lmaWM6IGluIHRoZSBmb2xsb3dpbmcg
bWVzc2FnZSBleGNoYW5nZXM6DQo+ID4NCj4gPiAxLiBJbmZvcm1hdGlvbi1yZXF1ZXN0IGZyb20g
Y2xpZW50IHRvIHNlcnZlcihzKSAyLiBSZXBseSB0byB0aGUgDQo+ID4gSW5mb3JtYXRpb24tcmVx
dWVzdCBmcm9tIHNlcnZlcihzKSB0byBjbGllbnQgMy4gRW5jcnlwdGlvbi1RdWVyeSANCj4gPiBm
cm9tIGNsaWVudCB0byBzZXJ2ZXIgNC4gRW5jcnlwdGlvbi1SZXNwb25zZSBmcm9tIHNlcnZlciB0
byBjbGllbnQNCj4gPg0KPiA+IGRpZCB5b3UgbWVhbiB0aGUgUmVwbHkgbWVzc2FnZSBvZiBleGNo
YW5nZSAjMj8NCj4gPg0KPiA+IElmIHNvLCBkbyB5b3UgYXQgbGVhc3QgYWdyZWUgdGhhdCBpdCBt
YWtlcyBhbG1vc3Qgbm8gc2Vuc2UgdG8gDQo+ID4gaW5jbHVkZSB0aGUgZXhwbGljaXQgc2VwYXJh
dGUgc2lnbmF0dXJlIGluIG1lc3NhZ2VzIDMgYW5kIDQ/DQo+ID4NCj4gPiBbTFNdOiBZZXMsIEkg
bWVhbiB0aGUgUmVwbHkgbWVzc2FnZSBvZiBleGNoYW5nZSAjMi4gVGhlIHJlcGx5IA0KPiA+IG1l
c3NhZ2UNCj4gY29udGFpbnMgdGhlIHNpZ25hdHVyZSBvcHRpb24gYW5kIHRpbWVzdGFtcCBvcHRp
b24gZm9yIG1lc3NhZ2UgDQo+IGludGVncml0eSBjaGVjay4gSW4gdGhlICMzIGFuZCAjNCBtZXNz
YWdlcywgdGhlIERIQ1B2NiBtZXNzYWdlcyBhcmUgDQo+IGVuY3J5cHRlZCwgc28gdGhlIHNpZ25h
dHVyZSBhbmQgdGltZXN0YW1wIG9wdGlvbiBhcmUgbm90IGNvbnRhaW5lZC4NCj4gV2hhdCBkbyB5
b3UgdGhpbmsgb2YgaXQ/DQoNCk9rYXkuICBTbyBmb2N1c2luZyBvbiB0aGUgUmVwbHkgbWVzc2Fn
ZSAoIzIpOiBteSBwb2ludCB3YXM6DQoNCi0gaW4gZWZmZWN0LCBpdHMgb25seSBjb250ZW50IGlz
IHRoZSBjZXJ0aWZpY2F0ZSAob3IgcHVibGljIGtleSkuDQotIHRoZSByZWNpcGllbnQgaXMgYWxy
ZWFkeSBleHBlY3RlZCB0byB2YWxpZGF0ZSB0aGlzIG9ubHkgY29udGVudA0KICBkaXJlY3RseSAo
YnkgY29tcGFyaW5nIGl0IHdpdGggbG9jYWxseSBwcmUtY29uZmlndXJlZCBpbmZvLCBieSB1c2lu
Zw0KICBhIFBLSSwgZXRjKSwgc28gd2UgZG8gbm90IG5lY2Vzc2FyaWx5IG5lZWQgdG8gcHJvdmlk
ZSBhZGRpdGlvbmFsDQogIGludGVncml0eSBwcm90ZWN0aW9uIGZvciBpdCBieSBzaWduaW5nIHRo
ZSBtZXNzYWdlLg0KLSBvbiB0aGUgb3RoZXIgaGFuZCwgaWYgd2UgZWxpbWluYXRlIHRoZSBzaWdu
aW5nIGFuZCB0aGUgc2lnbmF0dXJlDQogIG9wdGlvbiBmcm9tIHRoaXMsIHdlJ2xsIGNvbXBsZXRl
bHkgZWxpbWluYXRlIHRoaXMgb3B0aW9uIGZyb20gdGhlDQogIHByb3RvY29sLiAgVGhpcyB3aWxs
IGhlbHAgbWFrZSB0aGUgcHJvdG9jb2wgc2ltcGxlciBhbmQgcmVkdWNlDQogIGRldmVsb3BtZW50
IGNvc3RzLg0KDQpJZiB5b3Ugc3RpbGwgZGlzYWdyZWUsIHBlcmhhcHMgaXQgaGVscHMgaWYgeW91
IGNhbiBzaG93IGEgc3BlY2lmaWMgYXR0YWNrIHZlY3RvciBiZWNhdXNlIG9mIHRoZSBsYWNrIG9m
IHRoZSBzaWduYXR1cmUuDQoNCj4gPiBSaWdodCwgYnV0IHRoaXMgYXJndW1lbnQgYWxzbyBob2xk
cyBldmVuIGlmIHdlIGhhdmUgVE9GVS4uLg0KPiA+DQo+ID4gPiBTbywgSSB0aGluayB0aGF0DQo+
ID4gPiB0aGUgY2VydGlmaWNhdGUgb3B0aW9uIGlzIGVub3VnaCBmb3IgYXV0aGVudGljYXRpb24u
DQo+ID4gPiBMb29raW5nIGZvcndhcmQgdG8geW91ciBmdXJ0aGVyIGd1aWRhbmNlLg0KPiA+DQo+
ID4gLi4uc28gdGhlc2UgZG9uJ3QgZXhwbGFpbiB3aHkgd2Ugc2hvdWxkIG5vdyByZW1vdmUgdGhl
IHB1YmxpYyBrZXkgDQo+ID4gb3B0aW9uLiAgT25lIG9idmlvdXMsIHRob3VnaCBwb3NzaWJseSBy
ZWxhdGl2ZWx5IG1pbm9yLCBkcmF3YmFjayBvZiANCj4gPiBvbmx5IGhhdmluZyBhIGNlcnRpZmlj
YXRlIGlzIHRoYXQgaXQgd2lsbCBtYWtlIHRoZSBtZXNzYWdlIHNpemUgZXZlbiANCj4gPiBiaWdn
ZXIgd2hlbiB3ZSBhY3R1YWxseSBvbmx5IG5lZWQgdGhlIHB1YmxpYyBrZXkuDQo+ID4NCj4gPiBJ
J20gbm90IG5lY2Vzc2FyaWx5IG9wcG9zZWQgdG8gcmVtb3ZpbmcgdGhlIHB1YmxpYyBrZXkgb3B0
aW9uIGlmIHdlIA0KPiA+IGNvdmVyIGFsbCBzdWNoIGRpc2N1c3Npb25zIGFuZCByZWFjaCBjb25z
ZW5zdXMsIGJ1dCBJIGRvbid0IHRoaW5rIA0KPiA+IEkndmUgc2VlbiBpdCB5ZXQuDQo+ID4NCj4g
PiBbTFNdOiBJbiBjb25zaWRlcmF0aW9uIG9mIHRoZSBzdXBwb3J0IG9mIFRPRlUgYW5kIHRoZSBh
ZGQgb2YgYWxsIA0KPiA+IHN1Y2gNCj4gZGlzY3Vzc2lvbnMgYW5kIGNvbnNlbnN1cywgdGhlIGJl
dHRlciB3YXkgZm9yIHVzIGlzIHRvIGFkZCB0aGUgcHVibGljIA0KPiBrZXkgb3B0aW9uIGFzIHRo
ZSBiZWZvcmUgc2VjdXJlIERIQ1B2NiB2ZXJzaW9uLg0KPiBBbSBJIGNvcnJlY3Q/DQoNCk5vLCBJ
IGp1c3QgZGlkbid0IHNlZSB3aHkgdGhlIHB1YmxpYyBrZXkgb3B0aW9uIHdhcyByZW1vdmVkICh0
aGUgZXhwbGFuYXRpb24gcmVnYXJkaW5nIFRPRlUgZGlkbid0IG1ha2Ugc2Vuc2UgdG8gbWUpLiAg
QXMgSSBhbHJlYWR5IHNhaWQsIEknbSBub3QgbmVjZXNzYXJpbHkgb3Bwb3NlZCB0byByZW1vdmlu
ZyBpdCBpZiB0aGVyZSdzIGEgY29udmluY2luZyByZWFzb24gdGhhdCBjYW4gb3V0d2VpZ2ggaXRz
IGNvbnMuDQoNCj4gPiA+ID4gPi0gU2VjdGlvbiA2DQoNCj4gPiBJbnRyb2R1Y2luZyBhIG5ldyBl
cnJvciBjb2RlIGlzIHJlbGF0ZWQgYnV0IGEgbWlub3IgcG9pbnQuICBNeSANCj4gPiBxdWVzdGlv
biB3YXMgYWJvdXQgd2hhdCB0aGUgY2xpZW50IHNob3VsZCBkbyBpZiBpdCBzZWVzIHRoYXQgY29k
ZSANCj4gPiAob3Igd2hhdGV2ZXIgc2lnbmFsIHRoYXQgaW5kaWNhdGVzIHRoaXMga2luZCBvZiBm
YWlsdXJlKS4NCj4gPg0KPiBbTFNdOiBBcyB5b3Ugc2FpZCBiZWZvcmUsIHRoZSBEZWNyeXB0aW9u
RmFpbCBmYWlsdXJlIGlzIGVxdWl2YWxlbnQgdG8gDQo+IFNpZ25hdHVyZUZhaWwuIFNvIGlmIHRo
ZSBjbGllbnQgc2VlcyB0aGF0IGNvZGUsIHRoZSBjbGllbnQgTUFZIHJlc2VuZCANCj4gdGhlIG1l
c3NhZ2UgZm9sbG93aW5nIG5vcm1hbCByZXRyYW5zbWlzc2lvbiByb3V0aW5lcyBkZWZpbmVkIGlu
IFtSRkMzMzE1XS4NCj4gQW0gSSBjb3JyZWN0Pw0KDQpOb3Qgc3VyZSBpZiB5b3UgYXJlIGNvcnJl
Y3Q6LSksIGJ1dCwgeWVzLCB0aGF0IGFuc3dlcnMgbXkgcXVlc3Rpb24uDQpXaGV0aGVyIHRoaXMg
YmVoYXZpb3IgbWFrZXMgbW9zdCBzZW5zZSBpcyBhIGRpZmZlcmVudCBxdWVzdGlvbiwgb24gd2hp
Y2ggSSBkb24ndCB5ZXQgaGF2ZSBhIHBhcnRpY3VsYXIgaWRlYS4gIE1heWJlIEkgc2hvdWxkIGZp
cnN0IHNlZSBhIHJldmlzZWQgZHJhZnQgaW4gZnVsbCB0ZXh0Lg0KDQo+ID4gcC5zLiB0aGVyZSdz
IGFub3RoZXIgYmlnZ2VyIG9wZW4gaXNzdWUgSSBzZXBhcmF0ZWQgZnJvbSB0aGUgcmVzdCBvZiAN
Cj4gPiB0aGUgZGlzY3Vzc2lvbnM6DQo+ID4gaHR0cHM6Ly9tYWlsYXJjaGl2ZS5pZXRmLm9yZy9h
cmNoL21zZy9kaGN3Zy8tdFpCcGVNcy1FaVZ5TW0wTUxCcGozZEYNCj4gPiBZTkkNCg0KUmVtaW5k
ZXI6IHRoaXMgaXMgc3RpbGwgb3Blbi4NCg0KPiA+IFtMU106IEFub3RoZXIgb3BlbiBpc3NzdWUg
aXMgdGhhdDoNCj4gSWYgdGhlIHNlcnZlciByZWNlaXZlcyB0aGUgSW5mb3JtYXRpb24tcmVxdWVz
dCBtZXNzYWdlIGJ1dCBpdCBkb2VzIG5vdCANCj4gc3VwcG9ydCB0aGlzIHdvcmssIHdoYXQgc2hv
dWxkIHRoZSBzZXJ2ZXIgZG8/DQo+IEluIG15IG9waW5pb24sIGlmIHRoZSBzZXJ2ZXIgZG9uJ3Qg
c3VwcG9ydCB0aGlzIHdvcmssIGl0IGhhcyB0d28gY2hvaWNlczoNCj4gMS4gZHJvcCB0aGUgcmVj
ZWl2ZWQgSW5mb3JtYXRpb24tcmVxdWVzdCBtZXNzYWdlOyBJbiB0aGlzIHdheSwgdGhlIA0KPiBj
bGllbnQgd2lsbCBub3QgcmVjZWl2ZSBhbnkgbWVzc2FnZSB3aGljaCBpbGx1c3RyYXRlIHRoZSBz
ZXJ2ZXIgZG9uJ3QgDQo+IHN1cHBvcnQgc2VjdXJlIERIQ1B2Ni4gSWYgdGhlcmUgaXMgbm8gYXV0
aGVudGljYXRlZCBESENQdjYgc2VydmVyLCB0aGUgDQo+IGNsaWVudCBtYXkgcmVzZW5kIHRoZSBJ
bmZvcm1hdGlvbi1yZXF1ZXN0IG1lc3NhZ2U7IDIuIHNlbmQgdGhlIFJlcGx5IA0KPiBtZXNzYWdl
IHdpdGggdGhlIGNvcnJlc3BvbmRpbmcgZXJyb3Igc3RhdHVzIGNvZGUgdG8gdGhlDQo+IGNsaWVu
dO+8mw0KPiBUaGlzIHdheSB3aWxsIGludHJvZHVjZSB0aGUgZG93bmdyYWRlIGF0dGFjaywgYSB0
aGlyZCBwYXJ0eSBtYXkgc2VuZCANCj4gdGhlIFJlcGx5IG1lc3NhZ2Ugd2l0aCB0aGUgY29ycmVz
cG9uZGluZyBlcnJvciBzdGF0dXMgY29kZS4gQW5kIHRoZW4gDQo+IHRoZSBESENQdjYgY29uZmln
dXJhdGlvbiBwcm9jZXNzIG1heSBiZSB1bnNlY3VyZWQuDQo+IEkgcHJlZmVyIHRoZSBmaXJzdCBv
bmUgc29sdXRpb24uIFdoaWNoIG9uZSB3b3VsZCB5b3UgcHJlZmVyPyBMb29raW5nIA0KPiBmb3J3
YXJkIHRvIHlvdXIgZ3VpZGFuY2UuDQoNCkknZCBzaW1wbHkgZXhwZWN0IHRoZSB1c3VhbCBiZWhh
dmlvcjogdGhlIHNlcnZlciB3aWxsIHJldHVybiBhIFJlcGx5DQoob2J2aW91c2x5KSB3aXRob3V0
IHRoZSByZXF1ZXN0ZWQgaW5mb3JtYXRpb24gKHdoaWNoLCBpbiB0aGlzIGNhc2UsIHRoZSBjZXJ0
aWZpY2F0ZSBvciBwdWJsaWMga2V5IG9wdGlvbikuICBJIGRvbid0IHRoaW5rIHdlIGNhbiBlbGlt
aW5hdGUgdGhlIHBvc3NpYmlsaXR5IG9mIGRvd25ncmFkZSBhdHRhY2sgYnkgYW4gb24tcGF0aCBh
dHRhY2tlciwgaG93ZXZlciB3ZSBzcGVjaWZ5IHRoZSBiZWhhdmlvciBpbiB0aGlzIGNhc2UuDQoN
Ci0tDQpqaW5tZWkNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX18NCmRoY3dnIG1haWxpbmcgbGlzdA0KZGhjd2dAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3Lmll
dGYub3JnL21haWxtYW4vbGlzdGluZm8vZGhjd2cNCg==


From nobody Wed Feb 24 10:44:13 2016
Return-Path: 
X-Original-To: dhcwg@ietf.org
Delivered-To: dhcwg@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 565191B3CB1; Wed, 24 Feb 2016 10:44:12 -0800 (PST)
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: The IESG 
To: "IETF-Announce" 
X-Test-IDTracker: no
X-IETF-IDTracker: 6.14.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20160224184412.1696.60520.idtracker@ietfa.amsl.com>
Date: Wed, 24 Feb 2016 10:44:12 -0800
Archived-At: 
Cc: volz@cisco.com, dhc-chairs@ietf.org, The IESG , dhcwg@ietf.org, rfc-editor@rfc-editor.org, draft-ietf-dhc-dhcpv6-privacy@ietf.org
Subject: [dhcwg] UPDATED Document Action: 'Privacy considerations for DHCPv6' to Informational RFC (draft-ietf-dhc-dhcpv6-privacy-05.txt)
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.15
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 24 Feb 2016 18:44:12 -0000

The IESG has approved the following document:
- 'Privacy considerations for DHCPv6'
  (draft-ietf-dhc-dhcpv6-privacy-05.txt) as Informational RFC

This document is the product of the Dynamic Host Configuration Working
Group.

The IESG contact persons are Brian Haberman and Terry Manderson.

A URL of this Internet Draft is:
https://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6-privacy/




Technical Summary: 

This document describes the privacy issues associated with the use of
DHCPv6 (RFC 3315).

Working Group Summary: 

This document analyzes the privacy issues associated with the use of
DHCPv6.

Document Quality: 

This document has had thorough reviews by many interested and
knowledgeable folks (beyond those mentioned in the acknowledgements
section). There were no significant points of difficulty or
controversy with the contents of the document.

Personnel: 

Bernie Volz is the document shepherd. Brian Haberman is the responsible AD. 


From nobody Thu Feb 25 04:45:23 2016
Return-Path: 
X-Original-To: dhcwg@ietfa.amsl.com
Delivered-To: dhcwg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5B7D1A90A0; Thu, 25 Feb 2016 04:45:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.106
X-Spam-Level: *
X-Spam-Status: No, score=1.106 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, FRT_BIGGERMEM1=2.555, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=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 qpUwZ8Ki-XNR; Thu, 25 Feb 2016 04:45:19 -0800 (PST)
Received: from mail-lb0-x22d.google.com (mail-lb0-x22d.google.com [IPv6:2a00:1450:4010:c04::22d]) (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 30BC81A9061; Thu, 25 Feb 2016 04:45:18 -0800 (PST)
Received: by mail-lb0-x22d.google.com with SMTP id x1so28142377lbj.3; Thu, 25 Feb 2016 04:45:18 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ALnChSeyOWhy5J7Mr4rQItGPcl88/7x1BBlZM403Kd0=; b=B7C0vEhJalB/O8L09byzCi13aQdWgkfMXEgd7q9ll+ocbfvHcLthXptv+p1nEU/oPl yuEsYFjMMkvzcqBk+SP+Uct+qTegcUD24r6rYk8Rj1fGb/RnLd/JeQRtbpSiT3DHhaLY F2qyaQoLkiscO4E30nRu1QAMpJmTR/5mt4BJBlYbhb3CrnoGP4EmUqBeqJK755CVUihj go/7gL8cignhjMqz3GDd5IjrKYhCJ8kFThfarqmeSfWYGsOdvBxR9BptveReWA/9h5Qj jiw4DthSNFstX1ZJni2NrEY6hdpGKA9A3mGKKVbTVTtTIj//qdK2+4D43E1s2qAlcBvQ D2jA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=ALnChSeyOWhy5J7Mr4rQItGPcl88/7x1BBlZM403Kd0=; b=dvkePpFIqLeZ8vXQF7+7MQW0m/Q49s7c8ZxBQ+HhnPiD+ffYBABj+IQ1YiqQwGUrfx RhiPEo5khuKEKEG7Nexa7xO/moplpu5ULqSx4AZwp3VpXF0kidc+HImr659/3JELMoYk O86VdWj+2N3qCB0iB2OjkzydMYbM8RLBVFsO7fMf0A0DBRy/X2usXHSuyaawyJOrvc24 6DhTNKlVMYbzs9wDewAutB9fkGdv8osyLVWhTTwc0l+A0lvoIgWhy36JsZRzvJwXMqBo wm6nUQZeaO2XpIKPEPnguT6AQ9Ib/oUebOs3MwKkUWphfMQzvjVsbrrrckuXAq0VY8ft 0IhA==
X-Gm-Message-State: AG10YOROF/KvVCTLcEtJ4HU7KfxBMK6nk6+gb0eVxMeDKIaFr6KFeifD32J/cdUE0h+LJna+5+keCYamagWq9w==
MIME-Version: 1.0
X-Received: by 10.112.12.98 with SMTP id x2mr16621877lbb.76.1456404316382; Thu, 25 Feb 2016 04:45:16 -0800 (PST)
Received: by 10.114.79.194 with HTTP; Thu, 25 Feb 2016 04:45:16 -0800 (PST)
In-Reply-To: 
References:       
Date: Thu, 25 Feb 2016 20:45:16 +0800
Message-ID: 
From: Lishan Li 
To: =?UTF-8?B?56We5piO6YGU5ZOJ?= 
Content-Type: multipart/alternative; boundary=001a11c39ea8ed6ef7052c978d02
Archived-At: 
Cc: "dhcwg@ietf.org" , draft-ietf-dhc-sedhcpv6@ietf.org
Subject: Re: [dhcwg] comments on draft-ietf-dhc-sedhcpv6-10.txt
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 25 Feb 2016 12:45:21 -0000

--001a11c39ea8ed6ef7052c978d02
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

2016-02-25 1:56 GMT+08:00 =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89 :

> (I've removed draft-ietf-dhc-sedhcpv6@ietf.org)
>
> At Tue, 23 Feb 2016 10:45:40 +0800,
> Lishan Li  wrote:
>
> > > I'm still not sure if my point was made clear...so let me be more
> > > specific: in the following message exchanges:
> > >
> > > 1. Information-request from client to server(s)
> > > 2. Reply to the Information-request from server(s) to client
> > > 3. Encryption-Query from client to server
> > > 4. Encryption-Response from server to client
> > >
> > > did you mean the Reply message of exchange #2?
> > >
> > > If so, do you at least agree that it makes almost no sense to include
> > > the explicit separate signature in messages 3 and 4?
> > >
> > > [LS]: Yes, I mean the Reply message of exchange #2. The reply message
> > contains the signature option and timestamp option for message integrit=
y
> > check. In the #3 and #4 messages, the DHCPv6 messages are encrypted, so
> the
> > signature and timestamp option are not contained.
> > What do you think of it?
>
> Okay.  So focusing on the Reply message (#2): my point was:
>
> - in effect, its only content is the certificate (or public key).
> - the recipient is already expected to validate this only content
>   directly (by comparing it with locally pre-configured info, by using
>   a PKI, etc), so we do not necessarily need to provide additional
>   integrity protection for it by signing the message.
> - on the other hand, if we eliminate the signing and the signature
>   option from this, we'll completely eliminate this option from the
>   protocol.  This will help make the protocol simpler and reduce
>   development costs.
>
> If you still disagree, perhaps it helps if you can show a specific
> attack vector because of the lack of the signature.
>
> [LS]: Agree. But if we don't need the signature option, then the timestam=
p
option makes no sense, which is used to defend against anti-replay
attack before.

> > Right, but this argument also holds even if we have TOFU...
> > >
> > > > So, I think that
> > > > the certificate option is enough for authentication.
> > > > Looking forward to your further guidance.
> > >
> > > ...so these don't explain why we should now remove the public key
> > > option.  One obvious, though possibly relatively minor, drawback of
> > > only having a certificate is that it will make the message size even
> > > bigger when we actually only need the public key.
> > >
> > > I'm not necessarily opposed to removing the public key option if we
> > > cover all such discussions and reach consensus, but I don't think I'v=
e
> > > seen it yet.
> > >
> > > [LS]: In consideration of the support of TOFU and the add of all such
> > discussions and consensus, the better way for us is to add the public k=
ey
> > option as the before secure DHCPv6 version.
> > Am I correct?
>
> No, I just didn't see why the public key option was removed (the
> explanation regarding TOFU didn't make sense to me).  As I already
> said, I'm not necessarily opposed to removing it if there's a
> convincing reason that can outweigh its cons.
>
> [LS]: The self-signed certificate is the argument of the remove of the
public
key option. And we also need to supply some text to illustrate that it can
outweigh its cons. For the drawback of the method, the size of the DHCPv6
message is increased when we actually only need the public key, not the
certificate. However, the size of the X.509 certificate is not very large,
such as 1KB, which will not cause IPv6 fragment and other problem.


> > > > > >- Section 6
>
> > > Introducing a new error code is related but a minor point.  My
> > > question was about what the client should do if it sees that code (or
> > > whatever signal that indicates this kind of failure).
> > >
> > [LS]: As you said before, the DecryptionFail failure is equivalent to
> > SignatureFail. So if the client sees that code, the client MAY resend t=
he
> > message following normal retransmission routines defined in [RFC3315].
> > Am I correct?
>
> Not sure if you are correct:-), but, yes, that answers my question.
> Whether this behavior makes most sense is a different question, on
> which I don't yet have a particular idea.  Maybe I should first see a
> revised draft in full text.
>
> > > p.s. there's another bigger open issue I separated from the rest of
> > > the discussions:
> > >
> https://mailarchive.ietf.org/arch/msg/dhcwg/-tZBpeMs-EiVyMm0MLBpj3dFYNI
>
> Reminder: this is still open.
>
> [LS]: Will participate in the discussion.


> > > [LS]: Another open isssue is that:
> > If the server receives the Information-request message but it does not
> > support this work, what should the server do?
> > In my opinion, if the server don't support this work, it has two choice=
s:
> > 1. drop the received Information-request message;
> > In this way, the client will not receive any message which illustrate t=
he
> > server don't support secure DHCPv6. If there is no authenticated DHCPv6
> > server, the client may resend the Information-request message;
> > 2. send the Reply message with the corresponding error status code to t=
he
> > client=EF=BC=9B
> > This way will introduce the downgrade attack, a third party may send th=
e
> > Reply message with the corresponding error status code. And then the
> DHCPv6
> > configuration process may be unsecured.
> > I prefer the first one solution. Which one would you prefer? Looking
> > forward to your guidance.
>
> I'd simply expect the usual behavior: the server will return a Reply
> (obviously) without the requested information (which, in this case,
> the certificate or public key option).  I don't think we can eliminate
> the possibility of downgrade attack by an on-path attacker, however we
> specify the behavior in this case.
>
> [LS]: Thanks a lot for your guidance. I think that Bernie's reply has
solved this problem.


Best Regards,
Lishan

--001a11c39ea8ed6ef7052c978d02
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


2016=
-02-25 1:56 GMT+08:00 =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89 <jinmei@wide.ad=
.jp>:
(I've removed draft-ietf-dhc-sedhcpv=
6@ietf.org)



At Tue, 23 Feb 2016 10:45:40 +0800,

Lishan Li <lilishan48@gmail.com> wrote:



> > I'm still not sure if my point was made clear...so let me be =
more

> > specific: in the following message exchanges:

> >

> > 1. Information-request from client to server(s)

> > 2. Reply to the Information-request from server(s) to client

> > 3. Encryption-Query from client to server

> > 4. Encryption-Response from server to client

> >

> > did you mean the Reply message of exchange #2?

> >

> > If so, do you at least agree that it makes almost no sense to inc=
lude

> > the explicit separate signature in messages 3 and 4?

> >

> > [LS]: Yes, I mean the Reply message of exchange #2. The reply mes=
sage

> contains the signature option and timestamp option for message integri=
ty

> check. In the #3 and #4 messages, the DHCPv6 messages are encrypted, s=
o the

> signature and timestamp option are not contained.

> What do you think of it?



Okay.=C2=A0 So focusing on the Reply message (#2): my point was:



- in effect, its only content is the certificate (or public key).

- the recipient is already expected to validate this only content

=C2=A0 directly (by comparing it with locally pre-configured info, by using=


=C2=A0 a PKI, etc), so we do not necessarily need to provide additional

=C2=A0 integrity protection for it by signing the message.

- on the other hand, if we eliminate the signing and the signature

=C2=A0 option from this, we'll completely eliminate this option from th=
e

=C2=A0 protocol.=C2=A0 This will help make the protocol simpler and reduce<=
br>
=C2=A0 development costs.



If you still disagree, perhaps it helps if you can show a specific

attack vector because of the lack of the signature.


[LS]: Agree. But if we don't need th=
e signature option, then the timestamp
option makes no sense, whi=
ch is used to defend against anti-replay=C2=A0
attack before.=C2=
=A0


> > Right, but this argument also holds even if we have TOFU...

> >

> > > So, I think that

> > > the certificate option is enough for authentication.

> > > Looking forward to your further guidance.

> >

> > ...so these don't explain why we should now remove the public=
 key

> > option.=C2=A0 One obvious, though possibly relatively minor, draw=
back of

> > only having a certificate is that it will make the message size e=
ven

> > bigger when we actually only need the public key.

> >

> > I'm not necessarily opposed to removing the public key option=
 if we

> > cover all such discussions and reach consensus, but I don't t=
hink I've

> > seen it yet.

> >

> > [LS]: In consideration of the support of TOFU and the add of all =
such

> discussions and consensus, the better way for us is to add the public =
key

> option as the before secure DHCPv6 version.

> Am I correct?



No, I just didn't see why the public key option was removed (the=


explanation regarding TOFU didn't make sense to me).=C2=A0 As I already=


said, I'm not necessarily opposed to removing it if there's a

convincing reason that can outweigh its cons.


[LS]: The self-signed certificate is the argumen=
t of the remove of the public=C2=A0
key option. And we also need =
to supply some text to illustrate that it can=C2=A0
outweigh its =
cons. For the drawback of the method, the size of the DHCPv6=C2=A0
message is increased when we actually only need the public key, not the=
=C2=A0
certificate. However, the size of the X.509 certificate is=
 not very large,
such as 1KB, which will not cause IPv6 fragment =
and other problem.
=C2=A0

> > > > >- Section 6



> > Introducing a new error code is related but a minor point.=C2=A0 =
My

> > question was about what the client should do if it sees that code=
 (or

> > whatever signal that indicates this kind of failure).

> >

> [LS]: As you said before, the DecryptionFail failure is equivalent to<=
br>
> SignatureFail. So if the client sees that code, the client MAY resend =
the

> message following normal retransmission routines defined in [RFC3315].=


> Am I correct?



Not sure if you are correct:-), but, yes, that answers my question.<=
br>
Whether this behavior makes most sense is a different question, on

which I don't yet have a particular idea.=C2=A0 Maybe I should first se=
e a

revised draft in full text.



> > p.s. there's another bigger open issue I separated from the r=
est of

> > the discussions:

> > https://mailarchive=
.ietf.org/arch/msg/dhcwg/-tZBpeMs-EiVyMm0MLBpj3dFYNI



Reminder: this is still open.


[LS]: Will participate in the discussion=
.
=C2=A0

> > [LS]: Another open isssue is that:

> If the server receives the Information-request message but it does not=


> support this work, what should the server do?

> In my opinion, if the server don't support this work, it has two c=
hoices:

> 1. drop the received Information-request message;

> In this way, the client will not receive any message which illustrate =
the

> server don't support secure DHCPv6. If there is no authenticated D=
HCPv6

> server, the client may resend the Information-request message;

> 2. send the Reply message with the corresponding error status code to =
the

> client=EF=BC=9B

> This way will introduce the downgrade attack, a third party may send t=
he

> Reply message with the corresponding error status code. And then the D=
HCPv6

> configuration process may be unsecured.

> I prefer the first one solution. Which one would you prefer? Looking
> forward to your guidance.



I'd simply expect the usual behavior: the server will return a R=
eply

(obviously) without the requested information (which, in this case,

the certificate or public key option).=C2=A0 I don't think we can elimi=
nate

the possibility of downgrade attack by an on-path attacker, however we

specify the behavior in this case.

[LS]: Thanks a =
lot for your guidance. I think that Bernie's reply has solved this prob=
lem.=C2=A0=C2=A0


Best Regards,
Lishan



--001a11c39ea8ed6ef7052c978d02--


From nobody Thu Feb 25 09:53:33 2016
Return-Path: 
X-Original-To: dhcwg@ietfa.amsl.com
Delivered-To: dhcwg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A4A81B2F0E; Thu, 25 Feb 2016 09:53:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.978
X-Spam-Level: 
X-Spam-Status: No, score=-0.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=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 do3RSE2mugaQ; Thu, 25 Feb 2016 09:53:30 -0800 (PST)
Received: from mail-ig0-x233.google.com (mail-ig0-x233.google.com [IPv6:2607:f8b0:4001:c05::233]) (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 0D3401B2EFF; Thu, 25 Feb 2016 09:53:30 -0800 (PST)
Received: by mail-ig0-x233.google.com with SMTP id hb3so18338468igb.0; Thu, 25 Feb 2016 09:53:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=PEbmYWNVhqCBhD4XIO1Mvqoai2hFoqGFdGjcw7qp/TI=; b=vPyEVrrSRCvZomZ4zlkylflBFSqf7csSOZJ+wSLygTCiVnpA5aX88Dieh+tQ9ee9A1 346tFieQBAApddIXT++SliO1NgRIX9uveifXamSS5SGr6+kBmCij/X7Aqxon5/40ItYM ICzr+FJKTRfxejyaJleJTxc+DDTG07H6SjrPgzeFSz+HiZVqBTTkxOCMqPq/YoSqDW+q piVV2Ph19n5F8SQHcFopk1Mnnuu3YObT7pn1Ak9sebQc6Zn9U0nq8x/vbaCJGyrg9Fp9 hE9nu8AnqqA5O6HS4/1cPiWd1AGG5aOGuf0KJlKizeVwEYa8/klu+7cozv1NsRDFI+De eosw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=PEbmYWNVhqCBhD4XIO1Mvqoai2hFoqGFdGjcw7qp/TI=; b=ZAWZf583xzfT96k/q4LVMSaxjxOOb98Dh9w+36s8cOTghY9/EYwjA2AiqR1EyqP+0e d08JJh520wK0nOv7FUJG4OdbWD2VwboMmZi2XqDCgXB4IneBfvqv1OTUXzAxTPD+ouME JK5W+k1wmcskMKGHQe6xKWUZvVET2FNOmunEbrPZjn6zKFpfqaXWeNsWpcpbdzOti9Nj miVGt9aFU0tX9jVROUnwz3ZpEsGi1iss+ECoa5ZGrKaCkZsI5EcTZSWzBX0oZtdQf/8Z mTBVUlUwSh2Dmz32NOCHCYqZkhsPzQ7RsfL/nRmoiC9E3aKpID7YkTpm8Aeb2GLHKRIm FQ2g==
X-Gm-Message-State: AG10YORptUCHedCzT+l+tioVcceUyRBRmwHZoUtUcKn1kkwaLzYWwuT8haGgEW9ZEVDZqDQYJgZp855Gp6ZBXg==
MIME-Version: 1.0
X-Received: by 10.50.150.106 with SMTP id uh10mr3267834igb.41.1456422809470; Thu, 25 Feb 2016 09:53:29 -0800 (PST)
Sender: jinmei.tatuya@gmail.com
Received: by 10.107.169.35 with HTTP; Thu, 25 Feb 2016 09:53:29 -0800 (PST)
In-Reply-To: 
References:        
Date: Thu, 25 Feb 2016 09:53:29 -0800
X-Google-Sender-Auth: fw7WbAReCJTE-Mf9vYCk9tocKWo
Message-ID: 
From: =?UTF-8?B?56We5piO6YGU5ZOJ?= 
To: Lishan Li 
Content-Type: text/plain; charset=UTF-8
Archived-At: 
Cc: "dhcwg@ietf.org" , draft-ietf-dhc-sedhcpv6@ietf.org
Subject: Re: [dhcwg] comments on draft-ietf-dhc-sedhcpv6-10.txt
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 25 Feb 2016 17:53:31 -0000

At Thu, 25 Feb 2016 20:45:16 +0800,
Lishan Li  wrote:

> > Okay.  So focusing on the Reply message (#2): my point was:
> >
> > - in effect, its only content is the certificate (or public key).
> > - the recipient is already expected to validate this only content
> >   directly (by comparing it with locally pre-configured info, by using
> >   a PKI, etc), so we do not necessarily need to provide additional
> >   integrity protection for it by signing the message.
> > - on the other hand, if we eliminate the signing and the signature
> >   option from this, we'll completely eliminate this option from the
> >   protocol.  This will help make the protocol simpler and reduce
> >   development costs.
> >
> > If you still disagree, perhaps it helps if you can show a specific
> > attack vector because of the lack of the signature.
> >
> > [LS]: Agree. But if we don't need the signature option, then the timestamp
> option makes no sense, which is used to defend against anti-replay
> attack before.

For #2, correct.  We'll still need the timestamp option, though, for
the anti-reply protection of encrypted messages. (We might be able to
make it simpler such as a trivial sequence number, exploiting the fact
that the message is encrypted.  In that sense, it may not have to be a
"time stamp").

> > > Right, but this argument also holds even if we have TOFU...
[...]
> > > > [LS]: In consideration of the support of TOFU and the add of all such
> > > discussions and consensus, the better way for us is to add the public key
> > > option as the before secure DHCPv6 version.
> > > Am I correct?
> >
> > No, I just didn't see why the public key option was removed (the
> > explanation regarding TOFU didn't make sense to me).  As I already
> > said, I'm not necessarily opposed to removing it if there's a
> > convincing reason that can outweigh its cons.
> >
> > [LS]: The self-signed certificate is the argument of the remove of the
> public
> key option. And we also need to supply some text to illustrate that it can
> outweigh its cons. For the drawback of the method, the size of the DHCPv6
> message is increased when we actually only need the public key, not the
> certificate. However, the size of the X.509 certificate is not very large,
> such as 1KB, which will not cause IPv6 fragment and other problem.

Repeating my previous point just to make it sure that we are on the
same page: the argument that a self-signed certificate should make a
public key option redundant isn't new in our recent changes.  So I'd
wonder why we are now bothering it.  If this is a completely new
attempt of cleanup, I suggest making it very clear (i.e., it has
nothing to do with mandated encryption etc) and discussing it
accordingly.

--
JINMEI, Tatuya


From nobody Thu Feb 25 11:46:01 2016
Return-Path: 
X-Original-To: dhcwg@ietfa.amsl.com
Delivered-To: dhcwg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBAC61B334E for ; Thu, 25 Feb 2016 11:46:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.978
X-Spam-Level: 
X-Spam-Status: No, score=-0.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=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 zOY6sZ0OUczn for ; Thu, 25 Feb 2016 11:45:59 -0800 (PST)
Received: from mail-io0-x231.google.com (mail-io0-x231.google.com [IPv6:2607:f8b0:4001:c06::231]) (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 93AA71B3338 for ; Thu, 25 Feb 2016 11:45:59 -0800 (PST)
Received: by mail-io0-x231.google.com with SMTP id g203so99698354iof.2 for ; Thu, 25 Feb 2016 11:45:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:sender:date:message-id:subject:from:to; bh=YlzP0/fzdAzdtxAEW4vJVpWt4TBPgHLqmx2dtkcuOwI=; b=CXvBrz+LyzwuVY+noBkEzkw3PIyprQY/dzqDgEF9SUE2cUffneEbCm9ZiSMVT+FzMn p510QLzEihVis9i2AQNbp6f5c8WvxVy+cO9lv0TTKzolnkCJu2VZ1y/Ww4kPMl3i1BAS uwF7I7oeNnaZarI27stgl6GKQJNWLzuPXk23Of5gXaVZ3JpA9U5/eWDO53r3UNk1hYS1 96lABeRRWZlsx2tiTHThWnczd16ie6RlESgEWPGlQguckAiF9hukVREmKL0JM6tGthew AwbncAulvk+9kFPXAUq9h+ztb7PLLI+3IlzJ1F8of4U5yJqw+Fm+XpYpiwT2C7BAqD2s AgBg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:date:message-id:subject:from :to; bh=YlzP0/fzdAzdtxAEW4vJVpWt4TBPgHLqmx2dtkcuOwI=; b=OM4qI766e6GcI5qdblYA2MYNCRF0jgbH5cZ31ZopzWyd0BTMx2cOtBMkfsXRYcYGLN fk423fVn0LCCJVM1bZ2/FCxK7EtQnDVym/qYRobr02IowCz7ubR9jyEBflYdZkXdWLP8 V36tyhEKflRAzzs+zOo/Q9XcMisIK2n4iSD1x8NqGBThaz9jcR+hKmcEu2M4rxFG2xAF 9XBw4G2U8dRG0ODTgEg27OJho1tgCNxq8mIOn2XulVwQ15aG9gTA4LxfmTbqQdpks0Bb NafXpd1q+2anhEjJrW1tdmnOX9vPr9T6rFrO8wjqxjvElXEOBlW7yPJT3AngQh36tEau OuYA==
X-Gm-Message-State: AG10YOSUQClcdbrj7fCuqK2N5SABA1hQu4qYdhe9wwZHOYSFX75CHy4zOg2KFYQZLsyZ13g8vwGgZLd9dXFZXw==
MIME-Version: 1.0
X-Received: by 10.107.184.135 with SMTP id i129mr5394125iof.4.1456429558990; Thu, 25 Feb 2016 11:45:58 -0800 (PST)
Sender: jinmei.tatuya@gmail.com
Received: by 10.107.169.35 with HTTP; Thu, 25 Feb 2016 11:45:58 -0800 (PST)
Date: Thu, 25 Feb 2016 11:45:58 -0800
X-Google-Sender-Auth: r6F9WLCcA2L8SXbeoFv-yMxpMCA
Message-ID: 
From: =?UTF-8?B?56We5piO6YGU5ZOJ?= 
To: "dhcwg@ietf.org" 
Content-Type: text/plain; charset=UTF-8
Archived-At: 
Subject: [dhcwg] proposed text of sedhcpv6 applicability
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 25 Feb 2016 19:46:01 -0000

This is my proposed text for the "applicability" discussion of
draft-ietf-dhc-sedhcpv6-10 (Section 5.5) I promised before.  It is
intended to replace the entire text with the proposed text.

--
JINMEI, Tatuya

5.5.  Applicability

   In principle Secure DHCPv6 is applicable in any environment where
   physical security on the link is not assured and attacks on DHCPv6
   are a concern.  In practice, however, it will rely on some
   operational assumptions mainly regarding public key distribution
   and management, until more lessons are learned and more experiences
   are achieved.

   One feasible environment in an early deployment stage would be
   enterprise networks.  In such networks the security policy tends to
   be strict and it will be easier to manage client hosts.  One
   trivial deployment scenario is therefore to manually pre-configure
   client hosts with the server public key and manually register
   clients' public keys for the server.  It may also be possible to
   deploy an internal PKI to make this less reliant on manual
   operations, although it is currently subject to future study
   specifically how to integrate such a PKI into the DHCPv6 service
   for the network.

   Note that this deployment scenario based on manual operation is not
   different very much from the existing, shared-secret based
   authentication mechanisms defined in [RFC3315] in terms of
   operational costs.  However, Secure DHCPv6 is still securer than
   the shared-secret mechanism in that even if clients' keys stored
   for the server are stolen that does not mean an immediate threat as
   these are public keys.  In addition, if some kind of PKI is used
   with Secure DHCPv6, even if the initial installation of the
   certificates is done manually, it will help reduce operational
   costs of revocation in case a private key (especially that of the
   server) is compromised.

   It is believed that Secure DHCPv6 could be more widely applicable
   with integration of generic PKI so that it will be more easily
   deployed.  But such a deployment requires more general issues with
   PKI deployment be addressed, and it is currently unknown whether we
   can find practical deployment scenarios.  It is subject to future
   study and experiments, and out of scope of this document.


From nobody Thu Feb 25 23:30:19 2016
Return-Path: 
X-Original-To: dhcwg@ietfa.amsl.com
Delivered-To: dhcwg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DFA91ACDF0; Thu, 25 Feb 2016 23:30:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.449
X-Spam-Level: 
X-Spam-Status: No, score=-1.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=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 bZkBSv_VSQO3; Thu, 25 Feb 2016 23:30:08 -0800 (PST)
Received: from mail-lb0-x232.google.com (mail-lb0-x232.google.com [IPv6:2a00:1450:4010:c04::232]) (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 CF14B1ACDEC; Thu, 25 Feb 2016 23:30:07 -0800 (PST)
Received: by mail-lb0-x232.google.com with SMTP id x1so41948993lbj.3; Thu, 25 Feb 2016 23:30:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=c0cLeZYHV7sRkS97k0fFM3hFciy1maOCN8ZWlWkBxmc=; b=EaG2h9/A42KpHm+EFYXAFaWQzWo65pXIMUu1Yu+dZ6uUlX4eIChOD+zNEyEb/Bxmbs e91b6lqUbtP/ACG+pDnzgatJ31jx/KsjoTQnPYLHzyUDYRCA52V+3HxegM6lvrd3Mm5y fWc7+V0o8Vidnyl6ih8stwKvg5O8XYbJs1mxvsEoNTe2E7xu0HH0bBTmL4vIz35bS8lg 3vYawdqTrJZ5HRaQErxBrMmR3/Zs8vmhyZpzRGFJ/yD3HokS5oPvZAzWrNhqffCs20NN fzBGcdaGTKpdzax/U1yF0akingN1ML/DLzKWY3Xf5OlR5FMsnwtPZbYVbgdg3ajoktgu pkLg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=c0cLeZYHV7sRkS97k0fFM3hFciy1maOCN8ZWlWkBxmc=; b=cEf4kQEukEylGM7PjJ3xfkPCSaXjOVzUQraJtqc5fNzamEGuNaS1lk0MfsHEdVw35y fSImrXdUQjuH917U/IqVsdtJpWDvqlgmsVXK7g/P8yXLg5Bjv9AnVMxTCc/BuPqXHb6Q TjUlwG5tBbHdwEIghLG08C68SQekhEd2ITbcGe4He3XnrV1Zb+PzRf5Kc6+3vJlyC3Kt 0ayYs+NvBwJ6c9zKfDl7e/cgwAlWcg3eLcUAOUrTKRNVWxrPX5ejfHYhT4Jw8quZ9K8A yuvR7WHthZUwxpWXm3UxGLm+xFNCVeWboyX3SG/D2gEbdSXvZKs0C1Ldp/TwvRqZ2ovb 4ExA==
X-Gm-Message-State: AD7BkJKWT7F+nBaCzMkNf3ebVpFt7a/0Ue/OqbL03XgmcRkfYq8C4aH+hdBGB6BCfOuJ1+OBE38DCrB6HIlUZw==
MIME-Version: 1.0
X-Received: by 10.112.12.98 with SMTP id x2mr36245lbb.76.1456471805904; Thu, 25 Feb 2016 23:30:05 -0800 (PST)
Received: by 10.114.79.194 with HTTP; Thu, 25 Feb 2016 23:30:05 -0800 (PST)
In-Reply-To: 
References:         
Date: Fri, 26 Feb 2016 15:30:05 +0800
Message-ID: 
From: Lishan Li 
To: =?UTF-8?B?56We5piO6YGU5ZOJ?= 
Content-Type: multipart/alternative; boundary=001a11c39ea89dd1f8052ca74419
Archived-At: 
Cc: "dhcwg@ietf.org" , draft-ietf-dhc-sedhcpv6@ietf.org
Subject: Re: [dhcwg] comments on draft-ietf-dhc-sedhcpv6-10.txt
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 26 Feb 2016 07:30:10 -0000

--001a11c39ea89dd1f8052ca74419
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

2016-02-26 1:53 GMT+08:00 =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89 :

> At Thu, 25 Feb 2016 20:45:16 +0800,
> Lishan Li  wrote:
>
> > > Okay.  So focusing on the Reply message (#2): my point was:
> > >
> > > - in effect, its only content is the certificate (or public key).
> > > - the recipient is already expected to validate this only content
> > >   directly (by comparing it with locally pre-configured info, by usin=
g
> > >   a PKI, etc), so we do not necessarily need to provide additional
> > >   integrity protection for it by signing the message.
> > > - on the other hand, if we eliminate the signing and the signature
> > >   option from this, we'll completely eliminate this option from the
> > >   protocol.  This will help make the protocol simpler and reduce
> > >   development costs.
> > >
> > > If you still disagree, perhaps it helps if you can show a specific
> > > attack vector because of the lack of the signature.
> > >
> > > [LS]: Agree. But if we don't need the signature option, then the
> timestamp
> > option makes no sense, which is used to defend against anti-replay
> > attack before.
>
> For #2, correct.  We'll still need the timestamp option, though, for
> the anti-reply protection of encrypted messages. (We might be able to
> make it simpler such as a trivial sequence number, exploiting the fact
> that the message is encrypted.  In that sense, it may not have to be a
> "time stamp").
>
> [LS]: Agree. For the Reply message (#2), it does not contain the timestam=
p
option
because of the cleartext transmission. For the subsequent encrypted
message, the
timestamp option is used for message integrity check.
In general, in order to defend against the anti-replay attack, the
timestamp option
is used. As you said, the trivial sequence number can make it more simpler.
But if
the trivial sequence number is use, we need to define the format of the
trivial
sequence number. If the timestamp option is used, we can use the format
defined in
Section 5.3.1 of RFC3971.

> > > Right, but this argument also holds even if we have TOFU...
> [...]
> > > > > [LS]: In consideration of the support of TOFU and the add of all
> such
> > > > discussions and consensus, the better way for us is to add the
> public key
> > > > option as the before secure DHCPv6 version.
> > > > Am I correct?
> > >
> > > No, I just didn't see why the public key option was removed (the
> > > explanation regarding TOFU didn't make sense to me).  As I already
> > > said, I'm not necessarily opposed to removing it if there's a
> > > convincing reason that can outweigh its cons.
> > >
> > > [LS]: The self-signed certificate is the argument of the remove of th=
e
> > public
> > key option. And we also need to supply some text to illustrate that it
> can
> > outweigh its cons. For the drawback of the method, the size of the DHCP=
v6
> > message is increased when we actually only need the public key, not the
> > certificate. However, the size of the X.509 certificate is not very
> large,
> > such as 1KB, which will not cause IPv6 fragment and other problem.
>
> Repeating my previous point just to make it sure that we are on the
> same page: the argument that a self-signed certificate should make a
> public key option redundant isn't new in our recent changes.  So I'd
> wonder why we are now bothering it.  If this is a completely new
> attempt of cleanup, I suggest making it very clear (i.e., it has
> nothing to do with mandated encryption etc) and discussing it
> accordingly.
>
> [LS]: The self-signed certificate make the DHCPv6 option redundant, which
is not a new problem caused by our defined mechanism. So we don't need to
bother it. Could you please check whether my understanding is correct?

Best Regards,
Lishan

--001a11c39ea89dd1f8052ca74419
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


2016=
-02-26 1:53 GMT+08:00 =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89 <jinmei@wide.ad=
.jp>:
At Thu, 25 Feb 2016 20:45:16 +0800,=


Lishan Li <lili=
shan48@gmail.com> wrote:



> > Okay.=C2=A0 So focusing on the Reply message (#2): my point was:<=
br>
> >

> > - in effect, its only content is the certificate (or public key).=


> > - the recipient is already expected to validate this only content=


> >=C2=A0 =C2=A0directly (by comparing it with locally pre-configured=
 info, by using

> >=C2=A0 =C2=A0a PKI, etc), so we do not necessarily need to provide=
 additional

> >=C2=A0 =C2=A0integrity protection for it by signing the message.
> > - on the other hand, if we eliminate the signing and the signatur=
e

> >=C2=A0 =C2=A0option from this, we'll completely eliminate this=
 option from the

> >=C2=A0 =C2=A0protocol.=C2=A0 This will help make the protocol simp=
ler and reduce

> >=C2=A0 =C2=A0development costs.

> >

> > If you still disagree, perhaps it helps if you can show a specifi=
c

> > attack vector because of the lack of the signature.

> >

> > [LS]: Agree. But if we don't need the signature option, then =
the timestamp

> option makes no sense, which is used to defend against anti-replay

> attack before.



For #2, correct.=C2=A0 We'll still need the timestamp option, th=
ough, for

the anti-reply protection of encrypted messages. (We might be able to

make it simpler such as a trivial sequence number, exploiting the fact

that the message is encrypted.=C2=A0 In that sense, it may not have to be a=


"time stamp").


[LS]: Agree. For the Reply me=
ssage (#2), it does not contain the timestamp option=C2=A0
becaus=
e of the cleartext transmission. For the subsequent encrypted message, the=
=C2=A0
timestamp option is used for message integrity check.=C2=
=A0
In general, in order to defend against the anti-replay attack=
, the timestamp option=C2=A0
is used. As you said, the trivial se=
quence number can make it more simpler. But if
the trivial sequen=
ce number is use, we need to define the format of the trivial=C2=A0
sequence number. If the timestamp option is used, we can use the format =
defined in=C2=A0
Section 5.3.1 of RFC3971.=C2=A0


> > > Right, but this argument also holds even if we have TOFU...<=
br>
[...]

> > > > [LS]: In consideration of the support =
of TOFU and the add of all such

> > > discussions and consensus, the better way for us is to add t=
he public key

> > > option as the before secure DHCPv6 version.

> > > Am I correct?

> >

> > No, I just didn't see why the public key option was removed (=
the

> > explanation regarding TOFU didn't make sense to me).=C2=A0 As=
 I already

> > said, I'm not necessarily opposed to removing it if there'=
;s a

> > convincing reason that can outweigh its cons.

> >

> > [LS]: The self-signed certificate is the argument of the remove o=
f the

> public

> key option. And we also need to supply some text to illustrate that it=
 can

> outweigh its cons. For the drawback of the method, the size of the DHC=
Pv6

> message is increased when we actually only need the public key, not th=
e

> certificate. However, the size of the X.509 certificate is not very la=
rge,

> such as 1KB, which will not cause IPv6 fragment and other problem.



Repeating my previous point just to make it sure that we are on the<=
br>
same page: the argument that a self-signed certificate should make a

public key option redundant isn't new in our recent changes.=C2=A0 So I=
'd

wonder why we are now bothering it.=C2=A0 If this is a completely new

attempt of cleanup, I suggest making it very clear (i.e., it has

nothing to do with mandated encryption etc) and discussing it

accordingly.


[LS]: The self-signed certificate make the DHCPv6 opt=
ion redundant, which=C2=A0
is not a new problem caused by our def=
ined mechanism. So we don't need to=C2=A0
bother it. Could yo=
u please check whether my understanding is correct?=C2=A0

Best Regards,
Lishan



--001a11c39ea89dd1f8052ca74419--


From nobody Fri Feb 26 09:40:47 2016
Return-Path: 
X-Original-To: dhcwg@ietfa.amsl.com
Delivered-To: dhcwg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F4261B2BE4; Fri, 26 Feb 2016 09:40:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.978
X-Spam-Level: 
X-Spam-Status: No, score=-0.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=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 d6jVyXIlTO8O; Fri, 26 Feb 2016 09:40:42 -0800 (PST)
Received: from mail-io0-x230.google.com (mail-io0-x230.google.com [IPv6:2607:f8b0:4001:c06::230]) (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 498E21B2BE0; Fri, 26 Feb 2016 09:40:42 -0800 (PST)
Received: by mail-io0-x230.google.com with SMTP id l127so129093225iof.3; Fri, 26 Feb 2016 09:40:42 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=/0GifQYaTzqfBTmDqMkUCnAvRC6E3w4cpdQZjG2z3+0=; b=OkIYZ+CS2EvPimS14TXsXOksh8njXj3kQgYDBPRR2zMi5rharmLjBrGDwtMICwHwgl 9Be2XOgQ+RCBB5FMWVJRVVv54VQu0m0F9oHWBQKrGbDbxzds0r4t9YqkfSVkTsvMlECo wQdNr2FUK5LnfcrrPOvVCht5RHcmbtuMq2CX90Qaj/BCL/gHYWguIDuk57+TyyZ/DhbY EfrbPtfDaxLwmh4a5kuk5WXUYClyNcsYlJsKDywCVBGelYtmB9MChqb43ZLoXX8KF1MK DKFvAcrY90FSb54ZYulYVjfEMU9R69882gx6p2kWpZAjMjIi6WJhFuicEnpSuZKq6+Zc hREQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=/0GifQYaTzqfBTmDqMkUCnAvRC6E3w4cpdQZjG2z3+0=; b=ILFnMaGO3uCT2iTEURn9+DBq6CYX3GzMirp7HJRaIqZQ2RUQ1191K4aZk6pFaZRwDf kpf9oEbVylOPIA5TlpMk1IbaXMQWvZxEBUjN3liLpO2zEZyogQf/iJ2PVWPYtbl3VFHO N3Lkil90/Ks07OIvCKYvAIbaL3vqcrkrc1YwYpQSyi5GzLVUA9Lkmv+UQTuJ4pCnPSkB mwQbEr0DK4mZFyUwEV4cYca08lzQR/e0Otr5aRDFNns8WHH140EiEkq8hUESgFSQKltJ rQOzY9RSPYPvk8/9c+JHi7Z8RhJoGs4dkyBphWWVS5UFcKT5f+rIG3SRjVugWmwGR3+U BsQQ==
X-Gm-Message-State: AG10YOTnr2E+dTghrfjXonlq/0kFOFWDP6VjbRZjoeuRNFv5EGn6qCWBj9JhjHzDIGiOiBGthWhjRWtG5CBIbA==
MIME-Version: 1.0
X-Received: by 10.107.137.142 with SMTP id t14mr10462898ioi.172.1456508441664;  Fri, 26 Feb 2016 09:40:41 -0800 (PST)
Sender: jinmei.tatuya@gmail.com
Received: by 10.107.169.35 with HTTP; Fri, 26 Feb 2016 09:40:41 -0800 (PST)
In-Reply-To: 
References:          
Date: Fri, 26 Feb 2016 09:40:41 -0800
X-Google-Sender-Auth: XjnVI66S9Vc8EmmsH2o9keQsy_4
Message-ID: 
From: =?UTF-8?B?56We5piO6YGU5ZOJ?= 
To: Lishan Li 
Content-Type: text/plain; charset=UTF-8
Archived-At: 
Cc: "dhcwg@ietf.org" , draft-ietf-dhc-sedhcpv6@ietf.org
Subject: Re: [dhcwg] comments on draft-ietf-dhc-sedhcpv6-10.txt
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 26 Feb 2016 17:40:43 -0000

At Fri, 26 Feb 2016 15:30:05 +0800,
Lishan Li  wrote:

> > > > [LS]: The self-signed certificate is the argument of the remove of the
> > > public
> > > key option. And we also need to supply some text to illustrate that it
> > can
> > > outweigh its cons. For the drawback of the method, the size of the DHCPv6
> > > message is increased when we actually only need the public key, not the
> > > certificate. However, the size of the X.509 certificate is not very
> > large,
> > > such as 1KB, which will not cause IPv6 fragment and other problem.
> >
> > Repeating my previous point just to make it sure that we are on the
> > same page: the argument that a self-signed certificate should make a
> > public key option redundant isn't new in our recent changes.  So I'd
> > wonder why we are now bothering it.  If this is a completely new
> > attempt of cleanup, I suggest making it very clear (i.e., it has
> > nothing to do with mandated encryption etc) and discussing it
> > accordingly.
> >
> > [LS]: The self-signed certificate make the DHCPv6 option redundant, which
> is not a new problem caused by our defined mechanism. So we don't need to
> bother it. Could you please check whether my understanding is correct?

I didn't mean we "don't need to bother".  My major point is that this
change was confusing:

- We did a very substantial change since 08: merging encryption and
  mandating it (as well as removing TOFU)
- public key option was also removed as well without any explanation
  of why
- so I asked why, and your first response (it's because of the removal
  of TOFU) didn't make sense to me: the argument with self-signed
  certificate can apply with or without TOFU.

That's why we have this conversation.

Now, on clarifying these, I don't yet have a particular opinion on
whether to remove the public key option.  But my suggestion is: if you
want to make this change, raise this issue separately on this list
with your rationale, get consensus, and apply it to a subsequent
version of the draft.

--
JINMEI, Tatuya


From nobody Sat Feb 27 07:55:12 2016
Return-Path: 
X-Original-To: dhcwg@ietfa.amsl.com
Delivered-To: dhcwg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAAFA1A87F1 for ; Sat, 27 Feb 2016 07:55:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.749
X-Spam-Level: 
X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 6zABuOG8tKD3 for ; Sat, 27 Feb 2016 07:55:10 -0800 (PST)
Received: from mail-lb0-x232.google.com (mail-lb0-x232.google.com [IPv6:2a00:1450:4010:c04::232]) (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 7DD121A87ED for ; Sat, 27 Feb 2016 07:55:09 -0800 (PST)
Received: by mail-lb0-x232.google.com with SMTP id ep2so28626792lbb.0 for ; Sat, 27 Feb 2016 07:55:09 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:date:message-id:subject:from:to; bh=LSZyd/hn34c70+D7QeX1sqtaeMJWr6qyoY8y6Co5dIA=; b=VCuWpk2Y6O/Pn11RzFcZKjzE4PNwx7xEc9+rKgCCrTHWzAFISgvWLRP2BcBbZeSvcX vRhkjsjP8PFvP+ufQ5BpMFFul8TOL3QRRG3u57lf/B5wXi2xeMY3Ae8UDD3cnYyFjCTA V8W0/2BnHvIj8528dxj6ZznE+WA5+g/XELP4OFgR9G1B8Ey8d2sPS8pEH7+dIQUz3EFz SOCZSfiDCSzzzRIpB6kVHFw1mOjvsbkU+spYVZMPJYZ9WuehTCPyuLue5qYANJVGac++ yUq/ywVdsANnTz0zw4bIS4PMpkeXzRLBsMGuS+PxcNFfS8/PuCLrVXCHakA8V5NnMPSf augw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to; bh=LSZyd/hn34c70+D7QeX1sqtaeMJWr6qyoY8y6Co5dIA=; b=bnAuP58EwEaPw6gAvdTWI0QMf0fHCRlIzNptJdpRA/4gbLf+6XrEqvsnoOUkDdTmTX sAuoHgV+0mp/1ufVIxAH+8MldFoHf/XEi12tuHFozIbcLGwyTZDonFHdKWVFuxg4iZLP TDiJ0SjU4f1PD19GZ9egTRkr5FSIV98kjvfJc9fMqFchWNqGrTvUijmkhDgG+97M3uLw sYhjZsxfWoOjLs06G0Vv8wWb/wflNZTv3IjKLhvmmNIDiSz3pKcC+ZAX53ml2NG+DA5X hZawvk+tJRc5bRYIyOu1G/RebuNj8KSoy0XVBRaOcS171oLE1V5rPqaNXuQGkk8YVtWU EYJA==
X-Gm-Message-State: AD7BkJK8cW7luTRwicoSemXXAXRUx5BeZPXfOGrJLdHlScQFbxT9asTGS10YCeLvGn6qgVERfkAEatCbA5pASg==
MIME-Version: 1.0
X-Received: by 10.112.148.227 with SMTP id tv3mr1065740lbb.102.1456588507544;  Sat, 27 Feb 2016 07:55:07 -0800 (PST)
Received: by 10.114.79.194 with HTTP; Sat, 27 Feb 2016 07:55:07 -0800 (PST)
Date: Sat, 27 Feb 2016 23:55:07 +0800
Message-ID: 
From: Lishan Li 
To: dhcwg , JINMEI Tatuya 
Content-Type: multipart/alternative; boundary=047d7b3a83fa9385eb052cc270df
Archived-At: 
Subject: [dhcwg] Whether the public key option should be removed in sedhcpv6
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 27 Feb 2016 15:55:12 -0000

--047d7b3a83fa9385eb052cc270df
Content-Type: text/plain; charset=UTF-8

For secure DHCPv6 draft, compared with 08 version, the current version
removes
the public key option. Through the discussion with Jinmei, we want to get
some
comments from WG on whether the public key option should be removed or not.

The reason for the remove is that the self-signed certificate can replace
the public
key to achieve authentication. If the device is pre-configured with public
key not
certificate, it can generate the self-signed certificate for
authentication. For example,
if the DHCPv6 client is not pre-configured the CA-signed certificate, it
can generate
the self-signed certificate and send it to the DHCPv6 server for client
authentication.

For the self-signed certificate deployment, the self-signed certificate can
be generated
by a variety of tools easily. According to the pre-configured trusted
relationship between
the client and server, it is also easy to verify the self-signed
certificate.

For the drawback of the method, the size of the DHCPv6 message is increased
when
we actually only need the public key, not the certificate. However, the
size of the X.509
certificate is not very large, such as 1KB, which will not cause IPv6
fragment and other
problem.

Looking forward to your comments and guidance.


Best Regards,
Lishan

--047d7b3a83fa9385eb052cc270df
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


For secure DHCPv6 draft, compared with 08 version, th=
e current version removes=C2=A0
the public key option. Throug=
h the discussion with Jinmei, we want to get some=C2=A0
comments =
from WG on whether the public key option should be removed or not.=C2=A0

The reason for the remove is that the self-signed ce=
rtificate can replace the public=C2=A0
key to achieve authenticat=
ion. If the device is pre-configured with public key not=C2=A0
ce=
rtificate, it can generate the self-signed certificate for authentication. =
For example,=C2=A0
if the DHCPv6 client is not pre-configured the=
 CA-signed certificate, it can generate=C2=A0
the self-signed cer=
tificate and send it to the DHCPv6 server for client authentication.=C2=A0<=
/div>

For the self-signed certificate deployment, the se=
lf-signed certificate can be generated=C2=A0
by a variety of tool=
s easily. According to the pre-configured trusted relationship between=C2=
=A0
the client and server, it is also easy to verify the self-sig=
ned certificate.=C2=A0

For the drawback of the met=
hod, the size of the DHCPv6 message is increased when=C2=A0
we ac=
tually only need the public key, not the certificate. However, the size of =
the X.509
certificate is not very large, such as 1KB, which will =
not cause IPv6 fragment and other=C2=A0
problem.

Looking forward to your comments and guidance.=C2=A0

Best Regards,
Lishan =C2=A0


--047d7b3a83fa9385eb052cc270df--