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

[Donald Eastlake <[e-mail]>]

Hi Alissa,

Thanks for your quick reply.

I'm fine with all of your responses. I think the added explanation
your propose of Low Byte in Section 1 is good and eliminates the need
for any addition to Section 4.2 on that topic.

Thanks,
Donald
=============================
 Donald E. Eastlake 3rd   [phone] (cell)
 155 Beaver Street, Milford, MA 01757 USA
 [e-mail]


On Mon, Aug 3, 2015 at 4:04 PM, Alissa Cooper (alcoop) <[e-mail]> wrote:
> Hi Donald,
>
> Thank you for your review. Comments in-line.
>
> On Aug 1, 2015, at 8:47 AM, Donald Eastlake <[e-mail]> 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:
>
> OLD
> o  Manual configuration
>
>       *  IPv4 address
>
>       *  Service port
>
>       *  Wordy
>
>       *  Low-byte
>
> NEW
> o  Manual configuration
>
>       *  IPv4 address, in which the IID embeds the IPv4 address of the
> network interface (as in 2001:db8::192.0.2.1)
>
>       *  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.
>
> Thanks,
> Alissa
>
> 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   [phone] (cell)
>  155 Beaver Street, Milford, MA 01757 USA
>  [e-mail]