Re: [IPv6] [v6ops] Smaller prefixes (/64-/96?) for draft-collink-v6ops-ent64pd

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

Hello Brian

Indeed we need to write that threat model down before we give any recommendation on how to delegate prefixes.

In that process we note that there’s the same number of addresses in a /64 regardless of the sizes that are distributed, as individual/128 or else. The threat depends thus on what additional information the attacker can get, from and inside compromised device or from the outside (e.g., a darkweb db).

In a case 2 attack, since there are still as many addresses to scan in the /64, one interesting difference is whether the attack is blocked by the router or not. The router offers more protection when it distributes many long prefixes (meaning small in size like a /112).
And as Mark pointed out in that case we want the host to own multiple prefixes in the case of small-size / long-plen prefixes, and to rotate them. Which in my book reads as we want something like a prefix stateful autoconfiguration.

Regards,

Pascal

Le 31 mars 2023 à 00:22, Brian E Carpenter <[e-mail]> a écrit :
Hi Pascal,

On 31-Mar-23 05:21, Pascal Thubert (pthubert) wrote:
Hello Mark
The trouble we're going to have with this discussion is we don't have a privacy threat model for context. We don't know which types of attackers we're trying to have a host be private from, what information they have or can acquire etc.
Fully agreed that we need a threat model and all your words around that. IMHO the threat model should consider how bad it is to reach the host for an address that does not exist, vs. dropping the packet at the router.

Also, there are two very different types of threat model here, which might lead to different answers:

(#1) The remote tracking threat model (section 1.2 of RFC 8981)
(#2) The address scanning threat model (explored in RFC 7707)

My comment about /80 vs /96 was directed at #2. But the threat also depends on where the scanning code runs. If a host can be tricked into running a scanning script locally, for example, there are probably new vulnerabilities.

  Brian

Not if the network doesn't rotate prefixes.
The idea is not for the host to assume that the network rotates prefixes. To your point that the host protects itself, the idea is for the host to rotate a number of small prefixes the way it rotates addresses today. See that as address groups as opposed to addresses. This gives more addresses for the internal apps. And uses roughly the same resources on the router, at least when only stateful protocols are used (SFAAC and DHCP but no SLAAC which has its own costs and threats like DoS).
You can even autoconf prefixes like you autoconf addresses. The idea is that the host has a stateful IGP-independent UNI with the router to inject the prefix, so the can router redistributes that in its stateful IGP. See https://datatracker.ietf.org/doc/draft-thubert-6lo-prefix-registration/ <https://datatracker.ietf.org/doc/draft-thubert-6lo-prefix-registration/> .
I realise you deal with low bandwidth wireless scenarios, I wonder if bandwidth issues caused by 128 bits addresses is really a sign that IPv6 is fundamentally "too big" for your scenarios?
I appreciate your concern; As it goes, the problem is with the big irons, not IoT.
- Silicon forwarders pull a limited amount of heading bytes and make their decision on that . For that reason, everything that is for the destination should be at the end of the header chain (in a destination option) so as to allow more room for things that the router is interested in, IP header and HbH for a start. The expectation behind this is that everything in the IP header is crucial to reach the destination.
- In IoT we compress the headers with 6LoWPAN HC, 6LoRH and SCHC. So the size is not really a worry. We usually do not care for privacy that much, and derive IPv6 IIDs from MAC the old way. This way we can totally elide the IPv6 address that matches the MAC address.
All the best
Pascal
*From:* Mark Smith <[e-mail]>
*Sent:* jeudi 30 mars 2023 8:57
*To:* Pascal Thubert (pthubert) <[e-mail]>
*Cc:* David Farmer <farmer=[e-mail]>; Lorenzo Colitti <lorenzo=[e-mail]>; 6man WG <[e-mail]>; V6 Ops List <[e-mail]>; Vasilenko Eduard <vasilenko.eduard=[e-mail]>
*Subject:* Re: [IPv6] [v6ops] Smaller prefixes (/64-/96?) for draft-collink-v6ops-ent64pd
Hi Pascal,
(Repeating some points others have already made, started this email much earlier today)
On Thu, 30 Mar 2023, 02:31 Pascal Thubert (pthubert), <[e-mail] <mailto:[e-mail]>> wrote:
     *
     * A /64 per host gives the host a lot more capability to take care and ownership of its own address privacy as compared to trusting the network to do so when given a smaller prefix such as a /96 or longer.
 *
   Sorry Mark, I do not buy that at all. It’s quite the opposite.
Not if the network doesn't rotate prefixes.
   Once it is known (by the attacker) that the /64 is taken from a network that hands /64s out, then the correlation will be 100% based on the first 64 bits. 0 privacy when rotating addresses.
How does the attacker determine that a network is sharing a 64 bit IID space between a set of hosts or giving a 64 bit IID space to individual hosts?
   Ask yourself, if it is useful for attackers, long would that take knowledge to be available in the dark web? Today you can easily get the location of an address on the web, and it’s usually quite good.
The trouble we're going to have with this discussion is we don't have a privacy threat model for context. We don't know which types of attackers we're trying to have a host be private from, what information they have or can acquire etc.
Without that threat model, types of attackers, the information they have and can acquire, I think we need to aim for a privacy minimum or baseline in these IDs. I think that means giving as much responsibility and resources to the hosts for their own privacy by default, so they don't have to rely on the network to provide some or any of it.
Which is a worse host privacy situation?
- A host that has been given an unchanging /64, giving it 64 bits of possible IID randomness for how ever it wants to use those bits to attain privacy (per packet spread spectrum addressing for a connection? Tony Hain mentioned that idea at APNIC 38 when I met up with him there) and doesn't have to assume the network will rotate /64 prefixes, or
- A host that has been given a /96, a /104 or a /112, and then must assume the network will rotate prefixes, can't be sure of it, and has to risk its privacy to somehow measure if the network is providing rotating prefixes or not?
Privacy like security is relative, not absolute.
   With /64 per host, you effectively end up with what some people wanted to build 25 years ago: an IPv4 with 8 bytes addresses (at least for what is used in forwarding), DHCP only, 0 privacy. The remaining 64 bits become wasted expensive space in the IP header that could better fit in a destination option but that all the silicon forwarders along the path have to load and deal with. Lose-lose.
I don't think the lower 64 bits are wasted, they are providing addressing privacy that is in the hosts' control and other conveniences such as a simple default subnet size. Waste only occurs when there is no useful value gained from the resource.
The bandwidth consequences of 128 bit size of IPv6 addresses wasn't a concern back in May of 1994 when IPv6 addresses were changed from 64 bits to 128 bits. Since my Internet link has gone from 33 600 bps to 100 000 000 bps in that nearly 30 years, as have many other networks, the bandwidth overhead can only be less of a concern since then.
https://www.sobco.com/ipng/archive/sipp/message.31.may.94 <https://www.sobco.com/ipng/archive/sipp/message.31.may.94>
I realise you deal with low bandwidth wireless scenarios, I wonder if bandwidth issues caused by 128 bits addresses is really a sign that IPv6 is fundamentally "too big" for your scenarios?
Regards,
Mark.
   It would be a lot better to get a number of random size (/96 and longer)  and rotate them, using very few addresses in each, maybe for applications that are not afraid to be correlated. Prefix Autoconfiguration is doable too, long as you have a “DAD” process that 1) works and 2) considers overlaps.
   All the best;
   Pascal
   *From:* ipv6 <[e-mail] <mailto:[e-mail]>> *On Behalf Of *Mark Smith
   *Sent:* mercredi 29 mars 2023 16:53
   *To:* David Farmer <farmer=[e-mail] <mailto:[e-mail]>>
   *Cc:* Lorenzo Colitti <lorenzo=[e-mail] <mailto:[e-mail]>>; 6man WG <[e-mail] <mailto:[e-mail]>>; V6 Ops List <[e-mail] <mailto:[e-mail]>>; Vasilenko Eduard <vasilenko.eduard=[e-mail] <mailto:[e-mail]>>
   *Subject:* Re: [IPv6] [v6ops] Smaller prefixes (/64-/96?) for draft-collink-v6ops-ent64pd
   On Thu, 30 Mar 2023, 00:46 David Farmer, <farmer=[e-mail] <mailto:[e-mail]>> wrote:
       On Wed, Mar 29, 2023 at 05:06 Lorenzo Colitti <lorenzo=[e-mail] <mailto:[e-mail]>> wrote:
           On Tue, Mar 28, 2023 at 1:36 AM Vasilenko Eduard <vasilenko.eduard=[e-mail] <mailto:[e-mail]>> wrote:
               > Please keep in mind that the host running a DHCP-PD client (one the code development might be needed for) is not necessarily  the only host using the delegated prefix.
               > In the case of virtual OSes or expanding the network behind the host the prefix is used for SLAAC by other systems so we shall ensure all of them would work.
               DHCP-PD could not happen automatically, it is possible to support the configuration
               when the link would have 1) many /96 hosts and 2) /64 router
           I think you are confusing the host itself with other hosts behind it that it wants to extend the network to. If the host wants to extend the network, SLAAC is the only thing that is guaranteed to work for any IPv6 implementation, because it's required by the IPv6 specifications.
           Nothing today can do SLAAC on a /96 so if the host got a /96 from the network it would not be able to do anything with it other than create IP addresses for itself.
       Lorenzo,
       If the host (in this case, more accurately, the node, since it is extending the network to other hosts) wants to extend the network to other hosts, and the network the node is attaching to wants to allow that, then yes, SLAAC and a /64 prefix hint with DHCP-PD seems the most appropriate way to accomplish that.
       However, you have said your objection to DHCP-IA_NA is the host needs the network’s permission for additional addresses. But with DHCP-PD with a /96, the network is given the host 4B address to do with as it sees fit, and short of extending the network to other hosts (again, technically, that’s a node), that seems like enough addresses for an individual host to do anything it could ever want to do. With 4B addresses, every process on a host could have its own address and still have a few billion leftovers.
       Furthermore, the host doesn’t need to use SLAAC or ND to utilize any of those 4B addresses. It’s an internal matter within the host. SLAAC and ND are needed to coordinate address usage with other hosts, and in the case of an individual host, that’s unnecessary.
       Now when you start talking about virtualization and multiple virtual hosts within a single physical host, then SLAAC and ND are probably the best way for those virtual hosts to coordinate address usage with each other, and then a /64 again seems most appropriate.
       While I still think recommending a /64 per host is appropriate to allow the most flexibility and to allow extension of the network to other hosts, physical or virtual. Nevertheless, longer prefixes should also be allowed as well. If we are really only attaching an individual host, then a /96, a /104, or maybe even a /112 seems more than sufficient for the addressing needs of any individual host. Furthermore, this would allow more bits for the network to randomize part of the prefix to restore some privacy to the host that is lost by assigning a whole prefix to an individual host.
   What if the network hands out /112s but  doesn't periodically change the prefix?
   What can a host do if the network doesn't provide the level of privacy the host wants?
   How can a host determine what privacy levels the network will provide without the host having to risk its privacy to find out?
   For example, say a host wants its prefix changed daily, yet the network changes it weekly. What does the host do after 24 hours?
   Its only choice is to disconnect and then never connect again because it doesn't know if it is going to get the same or a different prefix. If it was given the same prefix if it connects again its privacy requirement has been breached.
   What if different hosts want to implement different privacy measures? They will all be bound and limited to what the network provides, rather than having the choice themselves.
   The less a host has to rely on the network for its privacy, the better off the host is. This is the essence of the end-to-end argument - if you want something done properly, you need to do it yourself.
   A /64 per host gives the host a lot more capability to take care and ownership of its own address privacy as compared to trusting the network to do so when given a smaller prefix such as a /96 or longer.
       With a /64 per host, the randomized IID will be much less effective from a privacy perspective, where shifting randomized bits to the prefix could restore some privacy, at least Internet-facing.
       Thanks
       --------------------------------------------------------------------
       IETF IPv6 working group mailing list
       [e-mail] <mailto:[e-mail]>
       Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 <https://www.ietf.org/mailman/listinfo/ipv6>
       --------------------------------------------------------------------
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[e-mail]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------