Subject: [Gen-art] Gen-ART LC Review of draft-ietf-6man-stable-privacy-addresses-06

From: Ben Campbell <[email-masked]>
Date: Thu, 25 Apr 2013 15:39:54 -0500

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at

<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Please resolve these comments along with any other Last Call comments
you may receive.

Document:  draft-ietf-6man-stable-privacy-addresses-06

Reviewer: Ben Campbell
Review Date: 2013-04-25
IETF LC End Date: 2013-04-16

Summary: This draft is almost ready for publication as a proposed standard. There are a few minor issues which should be considered first, described in the review.

Major issues:

None.

Minor issues:

-- section 3, third paragraph from end:

The paragraph suggests that changing the number of network interfaces should be rare. I think it's quite common in practice for the sorts of hosts likely to move between subnets regularly. For example, my Macbook Pro uses an external (Thunderbolt attached) ethernet interface which regularly gets disconnected and reconnected. Same might hold true for a USB attached wireless modem. And I have any number of VPNs which may be active or not at any given time.

-- section 3, 2nd paragraph from end:

You describe the affects of including Network_ID in some detail. It would be helpful to note the consequences of _not_ including it.

Nits/editorial comments:

-- section 1, 4th paragraph: "Therefore, it is vital..."

That seems a bit overstated. We're not talking about breaking the Internet here, are we?

-- 1, 6th paragraph: "Also, they result in increased complexity..."

What sort of complexity? Implementation complexity? It's a bit confusion because the previous sentences already talk about increased complexity of specific sorts. It would help to mention what sort of additional complexity is referred to here.

-- 1, paragraph 11: "This document does not update..."

How is adding an alternative algorithm _not_ an update?

--1, paragraph 12: "... may already address"

Is the "already addressing" part in question? Or is it a matter of addressing it in some circumstances, but not others? If the latter, it would help to elaborate.

-- 6, last paragraph: "... may mitigate..."

Not sure? Or only under some circumstances?

-- references:
 RFC1948 is obsoleted by 6528. Is there a reason to reference the obsolete version?

---

From: Fernando Gont <[email-masked]>
Date: Thu, 25 Apr 2013 17:32:17 -0500

Hi, Ben,

Thanks so much for your feedback! Please find my comments in-line...

On 04/25/2013 03:39 PM, Ben Campbell wrote:
> The paragraph suggests that changing the number of network interfaces
> should be rare. I think it's quite common in practice for the sorts
> of hosts likely to move between subnets regularly. For example, my
> Macbook Pro uses an external (Thunderbolt attached) ethernet
> interface which regularly gets disconnected and reconnected. Same
> might hold true for a USB attached wireless modem. And I have any
> number of VPNs which may be active or not at any given time.

I will tweak the text a bit -- as noted in other threads, I will replace
"Interface Index" with a generic "Interface_ID", and will comment on the
desired properties, and note that two possible options for it are the
Interface Index and the Interface name -- with the interface name
probably being more constant in the scenarios that you describe.

> You describe the affects of including Network_ID in some detail. It
> would be helpful to note the consequences of _not_ including it.

Well, should we really do it? -- after all, you MUST include it.

> That seems a bit overstated. We're not talking about breaking the

Well, that depends... there are scenarios in which privacy is really vital.

> What sort of complexity? Implementation complexity? It's a bit
> confusion because the previous sentences already talk about increased
> complexity of specific sorts. It would help to mention what sort of
> additional complexity is referred to here.

Yep, implementation complexity -- I will clarify this.

> How is adding an alternative algorithm _not_ an update?

Well, you still send an RS, receive an RA, and generate an IID.

Me, I'd probably update RFC 4862, so that we make sure that folks
implementing SLAAC take a look at this document, but....

> Is the "already addressing" part in question? Or is it a matter of
> addressing it in some circumstances, but not others? If the latter,
> it would help to elaborate.

Not sure what you mean. The idea is that, in many scenarios,
draft-ietf-stable-privacy-addresses may be good enough to address your
privacy concerns.

> Not sure? Or only under some circumstances?

The idea is that the only privacy implication that this doesn't mitigate
is correlation of node activities within the same network.
However, that really depends on the number of active nodes within the
same subnet. For example, if you have only one active node in the
subnet, then no matter whether its changes its addresses, its activities
can be easily correlated.

> -- references: RFC1948 is obsoleted by 6528. Is there a reason to
> reference the obsolete version?

Yes: RFC1948 is only referenced in the Acks section, where I note that
this document was inspired by Bellovin's work on RFC1948. While RFC6528
obsoletes RFC1948, the algorithm in that RFC is the same as that in RFC1948.

Thanks!

Best regards,
-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: Ben Campbell <[email-masked]>
Date: Thu, 25 Apr 2013 19:44:22 -0500

> probably being more constant in the scenarios that you describe.

Works for me.

> Well, should we really do it? -- after all, you MUST include it.

Hmm. Section 3 says Network_ID is optional.

> Well, that depends... there are scenarios in which privacy is really vital.

It's not a big deal, really, but it might be worth mentioning the context in which it's "vital". Or maybe tone it down to merely "important" :-)

[...]

> implementing SLAAC take a look at this document, but....

...?

(The reason you mention is one of the best reasons I can think of to call it an update--but if the working group consciously chose not to make it an update, I can live with it.)

> draft-ietf-stable-privacy-addresses may be good enough to address your

The way it's worded, it looks like you think it might address the concerns, but aren't sure. I doubt that's the intent. Simply saying "may address certain privacy concerns", or "in some circumstances, will address...". OTOH, elaborating on the specific concerns addressed would be even better. Do you mean to say it addresses the concerns already mentioned in this draft? If so, you could use language stronger than "may".

Your answer to my next comment is instructive for this as well.

> can be easily correlated.

Saying that would be helpful.

> obsoletes RFC1948, the algorithm in that RFC is the same as that in RFC1948.

So 6528 equally illustrates Steve Bellovin's  work, and is also more current, right? If someone decided to follow up to better understand your inspiration, which draft would you prefer them to read?

Thanks!

Ben.

---

From: Ben Campbell <[email-masked]>
Date: Thu, 25 Apr 2013 19:51:51 -0500

> So 6528 equally illustrates Steve Bellovin's  work, and is also more current, right? If someone decided to follow up to better understand your inspiration, which draft would you prefer them to read?

oops, s/draft/version.

---

From: Fernando Gont <[email-masked]>
Date: Thu, 25 Apr 2013 22:12:26 -0300

Hi, Ben,

On 04/25/2013 09:44 PM, Ben Campbell wrote:
>>> You describe the affects of including Network_ID in some detail. 
>>> It would be helpful to note the consequences of _not_ including 
>>> it.
>> 

Ooops, sorry -- you're right! I was thinking about the prefix, rather
than the Network_ID. I will address this in the next rev.

> (The reason you mention is one of the best reasons I can think of to 
> call it an update--but if the working group consciously chose not to 
> make it an update, I can live with it.)

I'm not sure whether this was "consciously chosen" -- I will check with
a few folks about their thoughts (for the most part, I wouldn't want to
trigger a controversy just because of this).

>>> Is the "already addressing" part in question? Or is it a matter 
>>> of addressing it in some circumstances, but not others? If the 
>>> latter, it would help to elaborate.
>> 
>> draft-ietf-stable-privacy-addresses may be good enough to address 
>> your privacy concerns.
> 
> The way it's worded, it looks like you think it might address the 
> concerns, but aren't sure. I doubt that's the intent. Simply saying 
> "may address certain privacy concerns", or "in some circumstances, 
> will address...". OTOH, elaborating on the specific concerns 
> addressed would be even better. Do you mean to say it addresses the 
> concerns already mentioned in this draft? If so, you could use 
> language stronger than "may".
> 

Ok, I will add some text about this.

>> Yes: RFC1948 is only referenced in the Acks section, where I note 
>> that this document was inspired by Bellovin's work on RFC1948. 
>> While RFC6528 obsoletes RFC1948, the algorithm in that RFC is the 
>> same as that in RFC1948.
> 
> So 6528 equally illustrates Steve Bellovin's  work, and is also more 
> current, right? 

Yes. But I'm a co-author of RFC 6528 -- so it'd be a bit arrogant (and
incorrect) to say that I was inspired by RFC 6528 :-) -- I was inspired
by Bellovin, rather than myself. :-)

Thanks!

Best regards,

---

From: Ben Campbell <[email-masked]>
Date: Thu, 25 Apr 2013 22:13:06 -0500

Hi, deleting sections that seem resolved:

On Apr 25, 2013, at 8:12 PM, Fernando Gont <[email-masked]> wrote:

[...]

> trigger a controversy just because of this).

Point taken.

[...]

> by Bellovin, rather than myself. :-)

Ah, I see your point :-)