All,
I just want everyone to be aware that I have stopped the
publication process on this document and sent it back to the WG. There
was significant feedback that I felt needed to be dealt with and that
the resulting changes may alter the document significantly. The author
and the document shepherd will be setting up an issue tracker for this
document to ensure all issues raised are addressed within the document.
Given this, I want to make sure that everyone is aware that this
means that the WG has to reach consensus on the contents of the document
as if it were a new document. Please let me know if you have any
questions on this approach.
Regards,
Brian
On 4/29/13 6:04 PM, Doug Barton wrote:
On 04/29/2013 01:12 PM, Fernando Gont wrote:
On 04/29/2013 05:00 PM, Doug Barton wrote:
I only peripherally followed the early discussion about this topic (only
so many hours in the day). I confess that I never "got" the need for
this, but lots of people seemed enthusiastic about it, so I put it in
the category of things to figure out later. :)
Now that there is non-trivial pushback on the draft becoming an RFC I
have taken another look, and I still don't get it.
I don't see pushback, but rather feedback and request for improvements
-- which is a normal (and healthy) part of the publication process.
I'll leave it for the IESG to judge consensus of course, but I have seen
a non-zero number of people provide "feedback" as you term it anywhere
from "this is a bad idea," to "this probably won't work," to "It's not
clear why this is necessary at all." The fact that they are more polite
than I am may have allowed for that feedback to be misinterpreted however.
Let's assume that
there are 2 broad categories that cover a statistically significant
percentage of the possible use cases, home and business. I don't see any
scenario where the home user would be benefited from stable privacy
addresses beyond what 4941 already provides.
Please see the appendix in draft-ietf-stable-privacy-addresses. (and
keep in mind that Windows replaces the traditional slaac addresses just
to avoid address scanning attacks).
I did. I don't find any of your arguments compelling.
A.1.1
In the case of bittorrent at least I'm fairly certain that you have a
fundamental misunderstanding as to how p2p connections are set up. But
even if you don't, why would anyone who sets up a server-like function
on their system have an expectation of privacy?
A.1.2
Even if all your points from A.1.1 are valid, if the attacker is on the
same network they have other ways of tracking the targeted system. Sure,
knowing/guessing its address would make that easier, but if you're on
the same network with a determined attacker you've pretty much lost the
game already. If you're not on the same network the potential for
exploiting this knowledge is minimal given properly configured firewalls.
A.1.3
Printers? Seriously? This is a threat the IETF needs to mitigate against?
A.2
Nothing in this section is mitigated by your proposal, other than the
discarding of certain traditionally characteristic bits, which is
covered by another draft already.
Assuming my use case analysis is correct (and I would not be surprised
if it were not),
Not wanting to use temporary addresses (RC4941) does not imply that you
want to paste a super-cookie into your IPv6 addresses.
What is the intersection of the sets of people who do not want to use
4941, but do want the privacy it provides? I'm not seeing it. As pointed
out previously, in the case of tracking for web services your IP address
is superfluous anyway. Do you have any other types of services in mind,
and a description of why they can't use 4941?
Besides, as
discussed in the appendix of draft-ietf-stable-privacy-addresses, RFC
4941 and this document are, to some extent, orthogonal.
I'm not arguing against that. As I said, I understand the attraction of
using the real address on your enterprise network(s), and using 4941
outside. I just don't think your proposal accomplishes anything that
justifies the additional complexity, if it can even work as advertised.
Doug
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
