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

[Alex List]

Hello Owen,

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

That's not a problem, my customers trust to me that I won't disclosure
their households. This is part of my service aggreement.

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

As Gert mentioned, you don't need to fully randomize that. It's enough
when people know how to find our building. We have a doorman who can
give visitors further directions.

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

They do, as people have mobiles, but the underlying system take cares
of handoffs.


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

Yes, I aggree, it's part of my service aggreement to do in that in
behalf of my customers.

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

Yes, I'm aware of the identication and location function of IP
addresses (and the current efforts for separating them for the
Inter-Domain Routing [7]). Because of my scope, I think it's perfectly
reasonable to randomize the prefix to a certain extent.

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

Well, I disagree, because there are forms of human interaction that
requires a representative, e.g. mediation [1].

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

It's enough to mask the identity of my customers to the casual
observer. For the services like VoIP I can use other prefixes. I know
there might be issues with multihoming[4], btw, there's going to be an
interesting talk [3] in the next IPv6-Kongress[2].

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

That's no problem for services like web browsing, and I can always
equate that in my SLAs. For other services I can use other prefixes.


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

I don't need BGP.

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

I don't know in other countries, but I think there's a market for that
in Germany[5]. Btw, I'm expecting here a very extensive media coverage
of the World IPv6 Launch Day[6].

Regards, Alex

Refs:
[1] http://en.wikipedia.org/wiki/Mediation
[2] Der IPv6-Kongress 2012, http://www.ipv6-kongress.de/
[3] Multihoming für Client-Netze,
http://www.ix-konferenz.de/showabstract.php?vid=1869
[4] IPv6 Multihoming without Network Address Translation,
http://tools.ietf.org/html/draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat-04
[5] OpenWRT würfelt IPv6-Präfixe,
http://www.heise.de/netze/artikel/OpenWRT-wuerfelt-IPv6-Praefixe-1445607.html
[6] World IPv6 Launch Day, http://www.worldipv6day.org/
[7] Locator/ID Separation Protocol (LISP),
https://datatracker.ietf.org/doc/draft-ietf-lisp/






Am 19. März 2012 17:49 schrieb Owen DeLong <owend at he.net>:
>
> 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
>
> _______________________________________________
> Ipv6hackers mailing list
> Ipv6hackers at lists.si6networks.com
> http://lists.si6networks.com/listinfo/ipv6hackers