Subject: last call comments for draft-ietf-6man-stable-privacy-addresses-06

From: RJ Atkinson <[email-masked]>
Date: Mon, 22 Apr 2013 09:34:26 -0400

Earlier, Eliot Lear wrote:
% Put simply, you are over-specifying the RID 
% and derive no benefit from doing so.

There is benefit to implementers in having a specific
example that is known to meet the requirements of
this specification.  This benefit also accrues to users,
as implementers are more likely to correctly implement
when giving a specific example that they may reuse.

% Also, the following text in section 3 Page 7 is contorted:
%
%> This means that this document does not formally obsolete or
%> deprecate any of the existing algorithms to generate Interface IDs
%> (e.g. such as that specified in [RFC2464]).Â However, those IPv6
%> implementations that employ this specification must generate all
%> of their "stable" addresses as specified in this document.
%
% My suggestion is to simplify remove it as it is self-evident.

It would reduce consensus within the WG and the IETF as a whole
to remove that text -- as it clarifies that other mechanisms for
generating such IDs are not affected by this specification.

Text to this effect was specifically requested by various WG 
participants, precisely because it is not "self-evident" and 
instead was confusing.

% Finally, this algorithm requires that the resultant host 
% portion be 64 bits.  Is that necessary?

Yes, it is required, for technical reasons relating to multiple
IPv6-related standards-track RFCs.

I oppose Eliot's proposed edits on grounds that they would
reduce the clarity of the specification and also would
reduce IETF and WG consensus about this specification.

Yours,

Ran

---

From: Sam Hartman <[email-masked]>
Date: Mon, 22 Apr 2013 09:56:59 -0400

>>>>> "RJ" == RJ Atkinson <[email-masked]> writes:

    RJ> I oppose Eliot's proposed edits on grounds that they would
    RJ> reduce the clarity of the specification and also would reduce
    RJ> IETF and WG consensus about this specification.

Ran,  I just checked, and you don't seem to be a 6man chair. We
generally ask chairs, not involved participants to judge WG consensus
and ADs to judge IETF consensus.

So, I think  what you're saying boils down to you disagree with Eliot
because you believe his comments would reduce clarity. You believe
others within the WG and outside the WG are likely to agree with you.
That's all fine and is valuable to contribute.

However, I don't think it promotes open and honest technical discussion
when participants try to call consensus. 
Thanks for considering my input.

---

From: [email-masked] (Martin Rex)
Date: Mon, 22 Apr 2013 16:32:42 +0200 (CEST)

Sam Hartman wrote:
>
> RJ Atkinson <[email-masked]> writes:
> 
> 

This applies not only to individuals alleging "consensus", but in just
the same way to WG chairs, ADs and the IESG to allege "consensus" for
a change without performing a consensus call that properly lists
options and their tradeoffs.

The only exception is, that IETF leadership (WG chairs, AD, IESG)
could assert their leadership privilege to make a specific choice.
In this case, however, they should label it as such (a leadership
decision).  For resolving issues that individuals have with
leadership decisions, there is the appeals process.

-Martin

---

From: Michael StJohns <[email-masked]>
Date: Mon, 22 Apr 2013 12:03:26 -0400

>and ADs to judge IETF consensus.

Bovine dung.  Or more politely - nonsense.  Participants judge WG consensus all the time.  Occasionally WG chairs will "declare" consensus to more the process forward, but that's rarer than the normal group think.

>Thanks for considering my input.

And I don't think it promotes open and honest technical discussion when you attack "standing" of a participant who *has* participated in the formation of a document to take an action, ask a question, or make a comment, rather than addressing the substance of the comment(s) made by that participant.

It's unclear from what you wrote that you considered the substance of Ran's comment.  

>participants, precisely because it is not "self-evident" and 

What *I* heard was:  "Elliot, the section you want to remove was added specifically through working group discussion to gain consensus for the document".   Assuming that I understood that was what he meant, and that it represents the reality of the process, Ran drawing the conclusion that removing that text would tend to "reduce consensus" seems to be a reasonable one and targeted specifically at the edit.

Mike

---

From: Christian Huitema <[email-masked]>
Date: Tue, 23 Apr 2013 17:55:50 +0000

> > And I would
> > observe that the DAD problem cannot be solved ina  reliable way.
>
> Could you please elaborate?

(Moving to the ipv6 mailing list, as this is way too detailed for the main IETF list.)

The goal is to use the same address when repeatedly visiting the same network. However, since we are using random numbers, we do not have guarantees that these addresses will not collide. Suppose that two hosts, A and B, want to use the same "colliding" addresses. If A connects first, B will have to use a fallback address. If B connects first, it will be A's turn to use a fallback address. That means that, given collisions, we fundamentally cannot guarantee that "the same host will always have the same address on the same network."

Your draft attempts to make the fallback predictable, by incorporating a DAD counter in the seeds of your nominal algorithm. But that means redefining the solution a only a guarantee that "the visiting host will have one of the same 2 or 3 addresses on the visited network." I am not sure it is worth the additional complexity, by opposition to just saying, "in case of collision, pick a new number."

By the way, there are many issues relate to privacy and mobility, and I am not sure that we can address them. Suppose that, as an attacker, I want to know the correspondence between a visiting host, identified by a particular MAC address, and the IPv6 address that this host use when "at home." I can somehow get control of a hot spot that the target host will visit. Then I can instruct the hot spot to announce in RA the very same prefix as the target's home network. Voila, the host will start doing DAD with their home network IPv6 address...

-- Christian Huitema

---

From: Fernando Gont <[email-masked]>
Date: Tue, 23 Apr 2013 13:37:45 -0500

On 04/23/2013 12:55 PM, Christian Huitema wrote:
>>> And I would observe that the DAD problem cannot be solved ina
>>> reliable way.
>> 
> The goal is to use the same address when repeatedly visiting the same
> network. However, since we are using random numbers, we do not have
> guarantees that these addresses will not collide. Suppose that two
> hosts, A and B, want to use the same "colliding" addresses. If A
> connects first, B will have to use a fallback address. If B connects
> first, it will be A's turn to use a fallback address. That means
> that, given collisions, we fundamentally cannot guarantee that "the
> same host will always have the same address on the same network."

Agreed. But we have 64-bit Interface IDs. If you get collisions, and you
get the nodes connecting in different sequences... well... call that
"bad luck" ;-)

At the end of the day, you cannot guarantee that because the TCP
checksum is valid and e.g. the Ethernet CRC is valid, the data being
transferred does not contain across, either.

And you cannot guarantee that packet have a limited lifetime on a
network (after all, nothing is taking into account the time it takes for
the packet to be put in the network, and travel from one router to
another), and....

> Your draft attempts to make the fallback predictable, by
> incorporating a DAD counter in the seeds of your nominal algorithm.
> But that means redefining the solution a only a guarantee that "the
> visiting host will have one of the same 2 or 3 addresses on the

So you're implying that on a given network, there might be e.g. three
collisions. What would be the probability of that from happening?

> By the way, there are many issues relate to privacy and mobility, and
> I am not sure that we can address them. Suppose that, as an attacker,
> I want to know the correspondence between a visiting host, identified
> by a particular MAC address, and the IPv6 address that this host use
> when "at home." I can somehow get control of a hot spot that the
> target host will visit. Then I can instruct the hot spot to announce
> in RA the very same prefix as the target's home network. Voila, the
> host will start doing DAD with their home network IPv6 address...

That assumes that the nodes uses the same network interface to access
its home network and your compromised hotspot, and that, if Network IDs
are employed for F(), you know what's the Network ID in use at home.

At the point you get to this kind of attack ascenario, and *if* it is a
concern, you may need some additional mitigations (e.g., SEND or the like).

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

---

From: Fernando Gont <[email-masked]>
Date: Tue, 23 Apr 2013 14:02:48 -0500

> transferred does not contain across, either.

s/across/errors/