Re: Address privacy

["Pascal Thubert (pthubert)" <[e-mail]>]

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?


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