Re: Address privacy

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

On 27-Jan-20 20:43, Pascal Thubert (pthubert) wrote:
> Hello Tom
> 
> This looks similar to the idea of using Mobile IPv6 inside a domain: 

Yes, we proposed that as long ago as https://tools.ietf.org/html/rfc4864

   Brian

> Hosts in the domain get only ULAs buy default. 
> Hosts that need reach back from outside the domain obtain GUAs from common Home Agent that serves the domain.
> That GUA becomes their home address. The ULA is the CareOf.
> The MIP tunnel happens within the domain unbeknownst of the outside
> 
> This way:
> - you get a better aggregation factor for privacy, mixed amongst the other devices in the domain.
> - the network structure is hidden from the outside observer. It effectively appears as a flat /64.
> 
> Cheers,
> 
> Pascal
> 
>> -----Original Message-----
>> From: ipv6 <[e-mail]> On Behalf Of Tom Herbert
>> Sent: dimanche 26 janvier 2020 22:35
>> To: Brian E Carpenter <[e-mail]>
>> Cc: 6man <[e-mail]>
>> Subject: Re: Address privacy
>>
>> On Sun, Jan 26, 2020 at 12:53 PM Brian E Carpenter
>> <[e-mail]> wrote:
>>>
>>> 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"
>>>
>>
>> There's also the possibility of putting location information into a modifiable HBH
>> option (part of draft-herbert-fast-04). Something like:
>>
>> - End host sends packet with HBH option for location
>> - First hop in network writes its location into the HBH option. The location
>> information identifies the hop (e.g. base station in a mobile
>> network) and is only interpretable in the local network (encrypted for instance).
>> - Packet is routed to destination with HBH option in tact.
>> - At the destination, the HBH option is reflected on return packets for a flow.
>> End host doesn't do anything else than just reflect.
>> - At the ingress node to the network, the location information is decoded. Given
>> this, the ingress forwards the packet to the locator node by address translation
>> of encapsulation.
>> - At the locator node, i.e. first network hop upstream of destination node, the
>> encapsulation or translation is undone and packet is forwarded to the final
>> destination.
>>
>> I think this method was first proposed to ensure consistent routing to the same
>> backend in L4 load balancing. Obvious downsides are the we need EH to work in
>> the network and there are changes needed in the hosts.
>>
>> Tom
>>
>>>    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
>>>> --------------------------------------------------------------------
>>>>
>>>
>>> --------------------------------------------------------------------
>>> 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
>> --------------------------------------------------------------------