Re: Address privacy

[Brian E Carpenter <[e-mail]>]

On 27-Jan-20 09:20, Ole Troan wrote:
> 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.

Google "SNA: Sourceless Network Architecture" and "IPv6 source addresses considered harmful"

   Brian
 
> 
> 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
>> --------------------------------------------------------------------
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>