Re: [Gen-art] Gen-ART LC review: draft-ietf-dhc-dhcpv6-privacy-03
Tomek Mrugalski <tomasz.mrugalski@gmail.com> Mon, 15 February 2016 20:45 UTC
Return-Path: <tomasz.mrugalski@gmail.com>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@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 <rjsparks@nostrum.com>, General Area Review Team <gen-art@ietf.org>, "ietf@ietf.org" <ietf@ietf.org>, "dhcwg@ietf.org" <dhcwg@ietf.org>, draft-ietf-dhc-dhcpv6-privacy.all@ietf.org
References: <56B0DBA3.2050406@nostrum.com>
From: Tomek Mrugalski <tomasz.mrugalski@gmail.com>
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: <http://mailarchive.ietf.org/arch/msg/gen-art/x9uVjA2T9QzPHDlifhHhc1S6Hx0>
Subject: Re: [Gen-art] Gen-ART LC review: draft-ietf-dhc-dhcpv6-privacy-03
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/gen-art/>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=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
- [Gen-art] Gen-ART LC review: draft-ietf-dhc-dhcpv… Robert Sparks
- Re: [Gen-art] Gen-ART LC review: draft-ietf-dhc-d… Tomek Mrugalski
- Re: [Gen-art] Gen-ART LC review: draft-ietf-dhc-d… Robert Sparks
- Re: [Gen-art] Gen-ART LC review: draft-ietf-dhc-d… Bernie Volz (volz)
- Re: [Gen-art] Gen-ART LC review: draft-ietf-dhc-d… Robert Sparks
- Re: [Gen-art] Gen-ART LC review: draft-ietf-dhc-d… Fernando Gont
- Re: [Gen-art] Gen-ART LC review: draft-ietf-dhc-d… Tomek Mrugalski
- Re: [Gen-art] Gen-ART LC review: draft-ietf-dhc-d… Bernie Volz (volz)
- [Gen-art] Gen-Art review: draft-ietf-dhc-dhcpv6-p… Robert Sparks
- Re: [Gen-art] [dhcwg] Gen-Art review: draft-ietf-… Jari Arkko