[ipv6hackers] Dynamic prefixes & privacy (was: IPv6 prefix changing)

Mon Mar 19 17:49:26 CET 2012

On Mar 19, 2012, at 12:47 AM, Alex List wrote:

> Hello Owen,
> 
> first of all, thank you for your participation in this discussion, I
> really appreciate it.
> 
>> ULA prefixes can't talk to the global internet.
> 
> I know, that's the reason why I've mentioned NPTv6 [1]
> 

But even with NPTv6, you're translating to a (quasi)-fixed locator
in order to get the end result you desire (internet access). That
translated locator is trackable, so, you've eliminated the benefit
you are seeking from the NPT unless you can somehow randomize
the locator.

Problem is, randomizing the locator is sort of like trying to give someone
directions to your house when your street changes names and is renumbered
frequently. It just doesn't tend to work out well, which is why people
don't have rapidly changing phone numbers or rapidly changing
street addresses.

Think of going to a website as being akin to ordering a product from
Amazon. At some point, in order to be able to receive what you requested,
you have to share a certain amount of personal information (address
and payment information, for example) to facilitate the transaction.

So it is with being able to get a response from a web site, receive email,
etc. In order for the internet to deliver what you want, you have to
tell the internet who/where you are to at least some extent.

>> Perhaps you should become familiar with the basics of how routing
>> actually works before pursuing this further...
> 
> Your advice surprised me, but I know it's difficult to estimate how
> much a newcomer understand. Well, I myself have difficulties in
> figuring out whether I really understand specific topics, thus I'm
> very thankful when people tell me when I don't. I made the analogy of
> calling my boss in order to illustrate what I want to achieve in terms
> of information hiding. I was not thinking about the underlying
> switching technology. In fact, in circuit switching I would not have
> needed to use the metaphor of calling my colleague, as it's also
> possible to disable the caller id [2]. I have no doubt that such level
> of information hiding is much harder to achieve in packet switching
> networks, especially when we consider the myriad of tracking
> techniques available at the application layer. That is the reason why
> I have named this thread "Dynamic prefixes and privacy". You may of
> course argue that it does not make sense to focus at the network
> layer, but that would be another discussion.
> 

I do, in fact argue that trying to achieve privacy at the network level
is every bit as absurd on the internet as it would be in any other
analogous form of human interaction.

As to disabling caller id[2] that's actually a myth (sort of). While you
can disable caller id well enough to mask your identity to the casual
observer, it doesn't have that effect when you call any of the following:

	1.	An 800 number.
	2.	Any 911 dispatch center (whether you called 911, 311, or
			any of a myriad of other numbers that end up there).
	3.	Any PSAP (Public Service Access Point)
	4.	Any entity that receives their phone calls on a digital trunk
	5.	Any entity other than a cell phone which may be billed per minute
		for your call.
	6.	Several other categories of destination that I'm not able
		to recall off the top of my head at the moment.

> 
>> IPv6 privacy extensions prevent one from using someone's MAC
>> address to track their mobility across different network segments.
>> They do nothing to anonymize your prefix.
> 
> Yes, that's clear to me [3].
> 
>> Dynamic prefixes aren't exactly deterministic, but, they are what I would
>> call long-lived. In most cases to be useful in the routing system, they
>> need to be sufficiently long-lived that they can't really offer much in
>> the way of anonymitiy.
> 
> Interesting point. In your opinion, in the case of DSL residential
> customers, what would be the minimum prefix lease time in order to be
> useful for the routing system?
> 

Well, every time you change prefixes, you disrupt the user's flows. If that
happens more than once a week, you tend to get customer complaints
about it. You're also likely (though not necessarily) going to create
route flaps which may lead to BGP penalties and increased convergence
which can cause up to 15-30 minutes of disruption.

Bottom line, most providers strive to minimize these disruptions because
most customers don't like them. I don't know of too many people who
care enough about hiding from the marketing spooks to make them
worth the performance/stability penalty that they carry. I know that I
have had the same IP lease from Comcast, for example, in IPv4 for
almost 2 years at this point.

>> As to your question of "if CGNs are here to stay", well, hopefully they
>> are very much not here to stay. CGNs are a really bad hack.  A worse
>> hack even than existing IPv4 NAT. They severely limit the utility of
>> the internet and the applications and innovations that can be
>> accomplished while they are in place. Hopefully they will be very
>> temporary in nature and will only apply to IPv4.
> 
> Actually that was not a question, but rather a premise for the
> subsequent statement. If I need a CGN in my infrastructure, and for
> whatever reason a customer wants me to do NPTv6 on his behalf, I'd
> like to understand whether it would make sense to use the CGN for
> that.
> 

Probably not. CGNs are targeted at IPv4 and for their hopefully limited
life span will probably need all the IPv4 performance they can muster.
Every provider will likely want to spend as little as possible on CGNs,
so will want to max out their IPv4 capabilities.

Further, I don't see how NPTv6 helps here. You still have to rotate the
external identifier and disrupt the users' sessions, so, I don't see any
benefit from NPT in the scenario.

> 
>> One of the biggest benefits of IPv6 is eliminating NAT. Adding it back
>> in is so antithetical to goodness I can only stare at your last sentence
>> in dismay and shake my head in disgust.
> 
> Sorry, I didn't expect that my last sentence would raise such
> feelings. I'll try to be more careful with the language when dealing
> with controversial topics next time.
> 
Meh... it isn't the language. It's the concept.

NAT brings nothing but breakage to the IPv6 party.

Owen

> Regards, Alex
> 
> Refs:
> [1] "NPTv6: The Simplest Case", http://tools.ietf.org/html/rfc6296#section-2.1
> [2] http://en.wikipedia.org/wiki/Caller_ID#Disabling
> [3] "Privacy Extensions for Stateless Address Autoconfiguration in
> IPv6", http://tools.ietf.org/html/rfc4941
> 
> Am 16. März 2012 12:20 schrieb Owen DeLong <owend at he.net>:
>> 
>> On Mar 16, 2012, at 1:06 AM, Alex List wrote:
>> 
>>> Hi,
>>> 
>>>> Not exactly, but yes. IPv6 privacy extensions alone would be sufficient to
>>>> make IP based tracking a lot harder and too inaccurate for the marketing
>>>> company.
>>> 
>>> Due to the /64 bits left I don't agree, but from the discussion so far
>>> I understand that:
>>> 
>>> - there is indeed no point in using dynamic prefixes for privacy if
>>> they were deterministic
>>> - random prefix assignments scary many people
>>> 
>>> But wait, aren't ULA prefixes random? If CGNs were here to stay[1],
>>> why couldn't they provide a "network layer privacy" [2] service? If
>>> they claim to be so good at NATPT44, NPTv6 should be a piece of cake.
>>> 
>> 
>> ULA prefixes can't talk to the global internet. If you don't want to talk to
>> the global internet and have packets routed back to you, you can be as
>> anonymous as you want. If you want the rest of the world to be able to
>> answer when you send them a packet, then there has to be a way for
>> them to get the answers back to you. Kind of reduces the probability
>> of useful anonymity short of using an anonymizing proxy or some other
>> such construct.
>> 
>> Perhaps you should become familiar with the basics of how routing
>> actually works before pursuing this further.
>> 
>> I wouldn't say that random prefix assignments scare people so much
>> as those of us who understand how the internet actually works realize
>> that they aren't really technically viable. (see my reference to having
>> your phone number randomized).
>> 
>> The difference is that in the phone network, since it is circuit switched,
>> the routing is all handled as part of the call setup and there is no need
>> for the remote destination to know the source address because the
>> destination does not participate at all in the routing decision.
>> 
>> With a packet switched network where each packet of information is
>> individually routed on a hop-by-hop basis, the story is a bit different.
>> The remote destination has to be able to place the originators source
>> address into reply packet headers in order for them to reach the
>> originator.
>> 
>> IPv6 privacy extensions prevent one from using someone's MAC
>> address to track their mobility across different network segments.
>> They do nothing to anonymize your prefix.
>> 
>> Dynamic prefixes aren't exactly deterministic, but, they are what I would
>> call long-lived. In most cases to be useful in the routing system, they
>> need to be sufficiently long-lived that they can't really offer much in
>> the way of anonymitiy.
>> 
>> As to your question of "if CGNs are here to stay", well, hopefully they
>> are very much not here to stay. CGNs are a really bad hack.  A worse
>> hack even than existing IPv4 NAT. They severely limit the utility of
>> the internet and the applications and innovations that can be
>> accomplished while they are in place. Hopefully they will be very
>> temporary in nature and will only apply to IPv4.
>> 
>> One of the biggest benefits of IPv6 is eliminating NAT. Adding it back
>> in is so antithetical to goodness I can only stare at your last sentence
>> in dismay and shake my head in disgust.
>> 
>> Owen
>> 
>> _______________________________________________
>> Ipv6hackers mailing list
>> Ipv6hackers at lists.si6networks.com
>> http://lists.si6networks.com/listinfo/ipv6hackers
> _______________________________________________
> Ipv6hackers mailing list
> Ipv6hackers at lists.si6networks.com
> http://lists.si6networks.com/listinfo/ipv6hackers