Re: Address privacy

[Ole Troan <[e-mail]>]

The obvious answer is to put the source address in the encrypted payload. It does not have to be in the core header. 
There’s a paper on it somewhere, although I am not sure if that’s where the idea originated. 

Cheers 
Ole

> On 26 Jan 2020, at 21:16, Tom Herbert <[e-mail]> wrote:
> 
> On Sun, Jan 26, 2020 at 11:59 AM Joel M. Halpern <[e-mail]> wrote:
>> 
>> Tom, your description is somewhat misleading.
>> 
>> On the one hand, LISP replies on per-flow state only in the mapping
>> entity.  Not at arbitrary places in the network.
>> 
>> Secondly, if hosts work in terms of identifiers, and the network works
>> in temrs of locators, someone has to map them.  You can cache (including
>> caching the whole thing), you can ask the host to hold the cache itself.
>>  There are other tradeoffs you can make, moving things around.  But you
>> can't just magically make the problem disappear.
> 
> Joel,
> 
> It comes down to how many addresses need to be mapped. It's intuitive
> that a higher frequency of address rotation yields more privacy. But
> higher frequency of address rotation means more active addresses in
> the network. This degenerates to the greatest frequency of change
> which would be to give each flow it's own unique address, and this is
> also the one case of temporary addresses where we can quantify the
> privacy characteristics.
> 
> However, giving each flow its own address quickly becomes a scaling
> and management problem-- we're talking several billions of active
> addresses in some provider networks. Hence, I believe we need mapping
> functions that are more N:1 than 1:1 (the latter doesn't scale).
> Similar, the ability of the network to delegate and map bundles of
> uncorrelated addresses to devices would be useful.
> 
> Tom
> 
>> 
>> Yours,
>> Joel
>> 
>>> On 1/26/2020 2:51 PM, Tom Herbert wrote:
>>> On Sun, Jan 26, 2020 at 9:42 AM Michael Richardson
>>> <[e-mail]> wrote:
>>>> 
>>>> 
>>>> Tom Herbert <[e-mail]> wrote:
>>>>>> Except that instead of doing it at layer 4, you do it with IPsec, and extrude
>>>>>> that /128 to your machine.  This is already a thing :-)
>>>>>> 
>>>>>>> Another solution I’ve considered is to have a giant anonymity mesh,
>>>>>>> with every ISP’s user participating, and forward flows through this
>>>>>>> mesh, treating each customer as an anonymity server.   I think this is
>>>>>> 
>>>>>> This is also a thing called Tor.
>>>>>> 
>>>>> Michael,
>>>> 
>>>>> Doesn't that require that the users must explicitly configure when
>>>>> they want privacy? I think a general solution should be transparent to
>>>> 
>>>> Yes, I agree, it requires explicit configuration.
>>>> I agree that this is not a good thing.
>>>> 
>>>>> the user and "just works" to ensure their privacy. That in fact is one
>>>>> of the arguments for NAT. If there is a significantly large enough
>>>>> pool of users behind a NAT device, then the obfuscation is transparent
>>>>> to the use and seems to be pretty good privacy (good enough that law
>>>>> enforcement is concerned about NAT). I suppose a similar effect could
>>>>> be achieved with a transparent proxy.
>>>> 
>>>> Yes, and I think that more and more LEA will grow ever concerned about this
>>>> situation, and it *is* pushing IPv6 adoption.  So, how can we find a happy medium?
>>>> 
>>>>> You might want to take a look at draft-herbert-ipv6-prefix-address-privacy-00.
>>>> 
>>>> An interesting read. I'm not sure where it goes.
>>>> 
>>>> I would like Locator/Identifier separation.
>>>> I wanted SHIM6. LISP would work, I think.
>>>> Then privacy needs don't need to screw up efficient routing at the edge.
>>>> 
>>> Hi Michael,
>>> 
>>> The problem of LISP is that it potentially includes a cache in the
>>> operator network that can be driven by downstream untrusted users--
>>> hence there is possibility of DOS attack on the cache (this is the
>>> primary reason why LISP hasn't been accepted into Linux).
>>> 
>>> What we really want is Identifier/Locator routing that neither
>>> requires per flow state to be maintained in the network nor relies on
>>> caches to get reasonable performance.
>>> draft-herbert-ipv6-prefix-address-privacy suggests crypto functions to
>>> map identifiers to locators at the edge.
>>> 
>>> Tom
>>> 
>>> 
>>>> 
>>>> --
>>>> Michael Richardson <[e-mail]>, Sandelman Software Works
>>>>  -= IPv6 IoT consulting =-
>>>> 
>>>> 
>>>> 
>>>> --------------------------------------------------------------------
>>>> IETF IPv6 working group mailing list
>>>> [e-mail]
>>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>>>> --------------------------------------------------------------------
>>> 
>>> --------------------------------------------------------------------
>>> IETF IPv6 working group mailing list
>>> [e-mail]
>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>>> --------------------------------------------------------------------
>>> 
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------