RE: Address privacy

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

Hello Tom

This looks similar to the idea of using Mobile IPv6 inside a domain: 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
> --------------------------------------------------------------------