Re: Address privacy

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

On 28-Jan-20 09:40, Pascal Thubert (pthubert) wrote:
> Yes, Brian,
> 
> and I must admit it’s encumbered by Cisco IPR but I doubt it’s the reason why it was not used that much. Any clue?

No idea. The IPR disclosure offers "reciprocal RAND" and that applies to so many protocols that I doubt if it had any specific effect here (even if the patent is applicable, which I have not checked). I think the idea probably got lost because of more pressing issues in v6 deployment.

Regards
    Brian
> 
> 
> Regards,
> 
> Pascal
> 
>> Le 27 janv. 2020 à 19:38, Brian E Carpenter <[e-mail]> a écrit :
>>
>> 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
>>>> --------------------------------------------------------------------
>>