Re: [secdir] SECDIR review of draft-ietf-6man-ipv6-address-generation-privacy-07

"Alissa Cooper (alcoop)" <> Mon, 03 August 2015 20:04 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 39B081ACDBB; Mon, 3 Aug 2015 13:04:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -13.11
X-Spam-Status: No, score=-13.11 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id J8AyowRzmgc3; Mon, 3 Aug 2015 13:04:16 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 9D64E1ACDBC; Mon, 3 Aug 2015 13:04:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=12324; q=dns/txt; s=iport; t=1438632256; x=1439841856; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=dJ3rjzqndwRJSfXekQjweMQlRMfqmdCLCjZrQj2XlpA=; b=hBMF2yDaZqoYYzIZAsz7WUfKo//RxQ2XCRwNJLhuMFVj4Q2eTfYVBtws pKGGlmFI72gOPda9ejKUCSzahuJVZEF8t3bhnSL4Q/wW9TzT0niwvMuYY d3eWi2QM02V/wewhr+Ff6zDdXIjBNgbP0qCMUnTgCkV2JCMdT5mystLnp o=;
X-Files: signature.asc : 496
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.15,603,1432598400"; d="asc'?scan'208,217";a="174889211"
Received: from ([]) by with ESMTP; 03 Aug 2015 20:04:15 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id t73K4FRr003017 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 3 Aug 2015 20:04:15 GMT
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1076.9; Mon, 3 Aug 2015 15:04:14 -0500
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1076.9 via Frontend Transport; Mon, 3 Aug 2015 15:04:14 -0500
Received: from ([]) by ([]) with mapi id 14.03.0248.002; Mon, 3 Aug 2015 15:04:13 -0500
From: "Alissa Cooper (alcoop)" <>
To: Donald Eastlake <>, Dave Thaler <>
Thread-Topic: SECDIR review of draft-ietf-6man-ipv6-address-generation-privacy-07
Thread-Index: AQHQzHFmVXu3AOdd70CpPLjNULgCkZ37ChIA
Date: Mon, 3 Aug 2015 20:04:13 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
x-originating-ip: []
Content-Type: multipart/signed; boundary="Apple-Mail=_7B0DFED7-E5C7-4EDC-8426-E5FD3993F483"; protocol="application/pgp-signature"; micalg=pgp-sha512
MIME-Version: 1.0
Archived-At: <>
X-Mailman-Approved-At: Mon, 03 Aug 2015 13:07:13 -0700
Cc: "" <>, IESG <>, "" <>
Subject: Re: [secdir] SECDIR review of draft-ietf-6man-ipv6-address-generation-privacy-07
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 03 Aug 2015 20:04:19 -0000

Hi Donald,

Thank you for your review. Comments in-line.

On Aug 1, 2015, at 8:47 AM, Donald Eastlake <> wrote:

> I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG.  Document editors and WG chairs should treat these comments just like any other last call comments.
> This draft is ready with nits. It provides a survey of the privacy and security considerations of a variety of IPv6 address generation mechanisms. As far as I can tell, it does a thorough job and is a useful document. I have the following minor comments:
> Section 1: Although references and lengthier names are given for all the other categories of configuration method, the "Manual configuration" method section is notable for the brevity of its entries and lack of any references whatsoever. I don't have the faintest idea what "Wordy" is and a couple of the others convey to me only a vague idea of what is being listed.

Understood. Here is my suggestion, drawing text from draft-ietf-opsec-ipv6-host-scanning:

o  Manual configuration

      *  IPv4 address

      *  Service port

      *  Wordy

      *  Low-byte

o  Manual configuration

      *  IPv4 address, in which the IID embeds the IPv4 address of the network interface (as in 2001:db8::

      *  Service port, in which the IID embeds the TCP/UDP service port of the main service running on that node (as in 2001:db8::80 or 2001:db8::25)

      *  Wordy, in which a word is encoded (as in 2001:db8::dead:beef)

      *  Low-byte, in which most of the bytes of the IID are set to 0 (except for the least significant byte)

> Section 2: What does "DHT" stand for? Given that it occurs exactly once in this document, perhaps it should be spelled out.

Distributed hash table. Will make the change.

> Section 3.3: It might also be useful to mention that the group-addressed bit in the upper 24-bits of a 48 bit MAC will be zero and the global/local bit will probably be zero also. It would be good to add a reference to RFC 7042.

Makes sense, will do.

> Section 4, Table 1: Given that there seems to be plenty of space, I would recommend spelling out "CGA" in the Mechanism column.

Will do.

> Also, I see no reason for the "(s)" on the end of "Mechanism" in the column header.

I think this was for a category like static manual, that could encompass multiple mechanisms in a single row of the table.

> Section 4.2: "low byte", which occurs here as well as in Section 1, could use a couple of sentences of explanation.

If the explanation above is provided in Section 1, does that suffice?

> Section 4.3: The first sentence reads very oddly. Suggest replacing "it" with "such a mechanism”.

Will do.

> Section 5.2: Maybe it is just me but it sounds quite odd to come across a "This document recommends" exactly once here almost at the end of this Informational document. It is certainly a reasonable recommendation but there are a number of previous points in the document where some mechanisms seems so much better, from the privacy and security point of view, than others that a recommendation would be equally justified. So I suggest changing "This document recommends that compliance testing suites be ..." to "Such compliance testing suites should be ...". (I realize that means about the same thing but somehow it bothers me a lot less.)

That change works for me.


> Alternatively, state in the introduction that recommendations are provided and review the document and add appropriate recommendation language in favor of superior mechanisms.
> Thanks,
> Donald
> =============================
>  Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
>  155 Beaver Street, Milford, MA 01757 USA