On 04/29/2013 07:04 PM, Doug Barton wrote:
>>> 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?

If what you're trying to accomplish doesn't *require* you to make it
trivial for cooperating nodes to correlate your activities, I'm not sure
why you should.



> 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.

Where in the attack scenarios are we assuming that the attacker is on
the same network?


> 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.

If you're implying a network-based firewall, you cannot rely on that. If
you're implying a host-based firewall, it's not unusual for firewalls to
respond to incoming packets (think TCP RSTs, ICMP unreach, etc.).

(And, from that pov he.. you shouldn't bother to do RFC4941, because you
should be using tor if you care about privacy...)


> A.1.3
> Printers? Seriously? This is a threat the IETF needs to mitigate against?

Doug, that's just a simple example. Call that file server, or anything
else. The point is: why should you disclose more information than the
one you really need to disclose to achieve your desired goal?



> 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.

Not sure what you mean. So far, when it comes to slaac, you have two
schemes implemented:

1) traditional slaac addresses embedding IEEE identifiers
2) Windows' approach of replacing the traditional slaac addresses with a
time-invariant version of RFC4941.

"1)" is vulnerable to address scanning attacks. "2)" mitigates them, but
still results in IIDs that are constant across networks, which lead to
the issues discussed in Appendix A.1 (and its subsections) of
draft-ietf-6man-stable-privacy-addresses.



>>> 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.

This scheme is NOT an alternative to RFC4941. For instance, if you're
doing RFC4941, you still benefit from implementing this (it will remove
the "constant across networks" IIDs, and will also mitigate
address-scanning attacks that leverage address patterns).


>> 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.

Let me ask a different set of questions:
* What's the reason for which you want patterns on your IPv6 addresses?
* Why wouldn't you want to make IPv6 address scanning attacks unfeasible?
* Why would you want IIDs that are constant across networks?
* When you say "complexity", are you referring to "implementation
complexity"? -- does computing a hash each time you do slaac mean
"complexity" to you?

Thanks,
-- 
Fernando Gont
SI6 Networks
e-mail: fg...@si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492




--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

Reply via email to