Subject: Re: Comments on draft-ietf-6man-stable-privacy-addresses-07

From: Fernando Gont <[email-masked]>
Date: Thu, 06 Jun 2013 03:19:43 +0200

On 06/06/2013 12:24 AM, Alissa Cooper wrote:
> I'll try to re-state one of my questions more simply, based on the
> -09:
> 
> How is the attack explained in C.4 mitigated by the mechanism
> specified in draft-ietf-6man-stable-privacy-addresses-09?

It doesn't. For instance, Section B.1 explicitly says so (and this type
of attack is not meant to be solved by stable-privacy-addresses).

In some scenarios, it can be mitigated with RFC 4941. Hoawever, as noted
in Section C.4, even ith RFC4941 there are scenarios n which yu cannot
do much about it.

>>> Which correlation attack vectors do random-per-network addresses 
>>> mitigate that temporary addresses do not?
>> 
>> See appendix B of drat-ietf-6man-stable-privacy-addresses.
> 
> I see the above-quoted text has been updated to the following:
> 
> In scenarios in which "temporary addresses" are employed,
> implementation of the mechanism described in this document (in
> replacement of stable addresses based on e.g.  IEEE identifiers)
> would mitigate address- scanning attacks and also mitigate the
> remaining vectors for correlating host activities based on the node's
> IPv6 addresses.
> 
> What "the remaining vectors for correlating host activities based on
> the node's IPv6 addresses" actually means is "the remaining vectors
> for correlating host activities across networks based on the node's
> stable IPv6 address," correct?

Yes. If you think it'd be better to phrase it that way, I can update the
text accordingly.

Thanks!

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

---

From: Alissa Cooper <[email-masked]>
Date: Wed, 5 Jun 2013 18:24:00 -0400

I'll try to re-state one of my questions more simply, based on the -09:

How is the attack explained in C.4 mitigated by the mechanism specified in draft-ietf-6man-stable-privacy-addresses-09?

One more comment below:

On May 31, 2013, at 8:23 PM, Fernando Gont <[email-masked]> wrote:
>> Another point for clarification:
>> 
>> On the other hand, in scenarios in which "temporary addresses" are
>> employed together with stable addresses such as those based on IEEE 
>> identifiers, implementation of the mechanism described in this 
>> document would mitigate address-scanning attacks and also mitigate 
>> some vectors for correlating host activities that are not mitigated 
>> by the use of temporary addresses.
>> 

In scenarios in which "temporary addresses" are employed, implementation
   of the mechanism described in this document (in replacement of stable
   addresses based on e.g.  IEEE identifiers) would mitigate address-
   scanning attacks and also mitigate the remaining vectors for
   correlating host activities based on the node's IPv6 addresses.

What "the remaining vectors for correlating host activities based on the node's IPv6 addresses" actually means is "the remaining vectors for
   correlating host activities across networks based on the node's stable IPv6 address," correct?

Thanks,
Alissa

---

From: Alissa Cooper <[email-masked]>
Date: Thu, 6 Jun 2013 09:40:27 -0400

Hi Fernando,

On Jun 5, 2013, at 9:19 PM, Fernando Gont <[email-masked]> wrote:

> It doesn't.

Good, that confirms what I thought.

> For instance, Section B.1 explicitly says so (and this type

Maybe it's just an organizational thing that makes me feel like this isn't clear -- in B.1 it says "However, as noted earlier in this document, in scenarios in which there is a reduced number of nodes …" but really that scenario is not discussed until later in the document (C.4). Then appendix C says that "It aims to clarify the motivation of employing the method specified in this document," but ends with the attack described in C.4, which is not mitigated by the mechanism specified in the document. I realize how this organization came about but it seems like it would make a little more sense to have each of the distinct threat models clearly described in one place in the body of the document, followed by a discussion of which threats the mechanism mitigates and which it does not.

> Yes. If you think it'd be better to phrase it that way, I can update the

Please do.

Thanks,
Alissa

---

From: Fernando Gont <[email-masked]>
Date: Thu, 06 Jun 2013 22:02:41 +0200

On 06/06/2013 03:40 PM, Alissa Cooper wrote:
>> For instance, Section B.1 explicitly says so (and this type of
>> attack is not meant to be solved by stable-privacy-addresses).
>> 
>> In some scenarios, it can be mitigated with RFC 4941. Hoawever, as
>> noted in Section C.4, even ith RFC4941 there are scenarios n which
>> yu cannot do much about it.
>> 
> 
> Maybe it's just an organizational thing that makes me feel like this
> isn't clear -- in B.1 it says "However, as noted earlier in this
> document, in scenarios in which there is a reduced number of nodes …"
> but really that scenario is not discussed until later in the document
> (C.4). 

The corresponding paragraph was moved to the appendix in version -09 --
it was part of the Intro in previous versions. I will update the
document accordingly.

> Then appendix C says that "It aims to clarify the motivation
> of employing the method specified in this document," but ends with
> the attack described in C.4, which is not mitigated by the mechanism
> specified in the document. 

As with the above, this is a product of the text that I moved to the
Appendix

> I realize how this organization came about
> but it seems like it would make a little more sense to have each of
> the distinct threat models clearly described in one place in the body
> of the document, followed by a discussion of which threats the
> mechanism mitigates and which it does not.

I'd personally prefer this not to be in the body of the document. For
the most part, because I think that we might benefit of a separate
document that does an analysis of all IID generation techniques, rather
than only this one (I had planned to wok on such a document even before
this whole discussion came up). To some extent, including such whole
discussion here looks a bit side-tracking.

But I'd love to hear what you and others think about it.

Thanks!

Best regards,

---

From: t.petch <[email-masked]>
Date: Fri, 7 Jun 2013 09:12:32 +0100

----- Original Message -----
From: "Fernando Gont" <[email-masked]>
To: "Alissa Cooper" <[email-masked]>
Cc: <[email-masked]>; "Brian Haberman"
<[email-masked]>; <[email-masked]>; "Dave Thaler"
<[email-masked]>; "Ray Hunter" <[email-masked]>; "Fernando
Gont" <[email-masked]>; "tom.petch" <[email-masked]>;
"Christian Huitema" <[email-masked]>; "He Xuan" <[email-masked]>
Sent: Thursday, June 06, 2013 9:02 PM
>> attack is not meant to be solved by stable-privacy-addresses).
<snip>

<tp>
Yes!  but I'd rather see this published sooner rather than later.

I have always found this a complicated I-D to read, and each successive
versions seems harder, as more and more gets added.  Yes, what is added
is related and is about the problems of IPv6, but that is a bottomless
pit:-) I would rather you has stopped a version or two ago, leaving some
of the compare and contrast, and the unsolved problems, at least in
detail, for another day.  (But the Introduction is better in this
version).

When I look back at the comments on this in the recent past, I do wonder
if perhaps there is an element of unconscious hindering, of asking for
more not because it will make the document noticeably better but rather
as a way of saying something like um, I am not too sure about this going
forward.

Leaving the psychology aside, I would like this to progress as is.  I
believe that there will more comments that will need changes in the
later stages of review, perhaps a GenArt or security directorate, or the
dreaded IETF Last Call.

Tom Petch

Thanks!

Best regards,

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: SM <[email-masked]>
Date: Fri, 07 Jun 2013 02:51:55 -0700

Hi Fernando,
>discussion here looks a bit side-tracking.

My preference would be to have the threat model in one place followed 
by the discussion of which threats are addressed or not 
addressed.  If the level of detail is a distraction I would move some 
of that text to an Appendix.  Another alternative is to discuss about 
the threats under Security Considerations.

As a reader I would look for the reason to implement what's in 
draft-ietf-6man-stable-privacy-addresses-09 and how it is done.  I am 
ok with what you prefer in terms of document organization.

Regards,
-sm