Re: [arch-d] Treating "private" address ranges specially

[Ted Hardie <[e-mail]>]

Following up Erik's message below.

On Wed, Mar 31, 2021 at 9:32 AM Erik Kline <[e-mail]> wrote:

> On Wed, Mar 31, 2021 at 12:15 AM Mark Nottingham <[e-mail]> wrote:
>
>>
>>
>> > On 31 Mar 2021, at 6:07 pm, Erik Kline <[e-mail]> wrote:
>> >
>> > On Tue, Mar 30, 2021 at 11:21 PM Martin Thomson <[e-mail]>
>> wrote:
>> > On Wed, Mar 31, 2021, at 17:17, Erik Kline wrote:
>> > > My mistake.  I think the key text I didn't property absord was "the
>> > > current url's host".
>> >
>> > :) Yes, though if you have name resolution that produces a ULA (which
>> might happen in mDNS), then you would be contacting a "private" address.
>> >
>> > I will say that this approach would seem to functionally treat all
>> private spaces as equivalent.  It's fairly easy to think of there being,
>> essentially, _one_ public sphere, but I think in practice there can be many
>> different private spaces.  I'm not sure how well that will play out [1],
>> but maybe it's no worse than today.
>> >
>> > [1] I'm imagining a client w/ a private address and VPNs to two
>> different organizations using two different private spaces.  Now a web page
>> from ORG1's private address space can cause the client to issue queries to
>> ORG2's privately addressed resources.
>>
>> Is that the case? My understanding is that this proposal only reduces
>> privilege when interacting with resources that are considered private, it
>> doesn't add new privileges .  But I could misunderstand.
>>
>
> <more speculation>
>
> If we discard the "local" space discussion, then a request is private iff.
> the "request’s current url's host maps to a private address, and request’s
> client's IP address space is public"... I think (per 2.2)?  If I'm reading
> this correctly, then I would think that section 3.1 #2, "[r]equests whose
> client's IP address space is private are allowed to fetch resources from
> private and public addresses as they do today" would mean a private
> resource fetched from a private address in the context of a current URL
> privately addressed host does not incur any extra Fetch algorithm
> modification (it's not a "private network request").
>

The document's description of the address space architecture is:

2.1. IP Address Space

Every IP address belongs to an IP address space, which can be one of three
different values:

   1.

   local: contains the local host only. In other words, addresses whose
   target differs for every device.
   2.

   private: contains addresses that have meaning only within the current
   network. In other words, addresses whose target differs based on network
   position.
   3.

   public: contains all other addresses. In other words, addresses whose
   target is the same for all devices globally on the IP network.

The contents of each IP address space
<https://wicg.github.io/private-network-access/#ip-address-space> are
determined in accordance with the IANA Special-Purpose Address Registries (
[IPV4-REGISTRY]
<https://wicg.github.io/private-network-access/#biblio-ipv4-registry> and
[IPV6-REGISTRY]
<https://wicg.github.io/private-network-access/#biblio-ipv6-registry>). To
determine the IP address space
<https://wicg.github.io/private-network-access/#ip-address-space> of a
given IP address (address), run the following steps:

   1.

   If address is an IPv4 address <https://url.spec.whatwg.org/#concept-ipv4>
   in the "Loopback" address block (127.0.0.1/8 at time of writing), then
   return local
   <https://wicg.github.io/private-network-access/#ip-address-space-local>.
   2.

   If address is an IPv6 address <https://url.spec.whatwg.org/#concept-ipv6>
   in the "Loopback Address" address block (::1/128 at time of writing),
   then return local
   <https://wicg.github.io/private-network-access/#ip-address-space-local>.
   3.

   If address is an IPv6 address in the "IPv4-mapped Address" address block
   (::ffff:0:0/96 at time of writing), return the IP address space
   <https://wicg.github.io/private-network-access/#ip-address-space> of its
   embedded IPv4 address.
   4.

   If address belongs to an address block for which the Globally Reachable
   bit is set to False in the relevant IANA registry, then return private
   <https://wicg.github.io/private-network-access/#ip-address-space-private>
   .
   5.

   Otherwise return public
   <https://wicg.github.io/private-network-access/#ip-address-space-public>.

Note: Link-local IP addresses such as 169.254.0.0/16 are considered private
<https://wicg.github.io/private-network-access/#ip-address-space-private>,
since such addresses can identify the same target for all devices on a
network link. A previous version of this specification considered them to
be local
<https://wicg.github.io/private-network-access/#ip-address-space-local>
instead.
What I think this proposal would actually like to do is to determine
whether a resource referenced by a specific web server would also be
reachable by that server.  If it is:  allow the reference; if it is not,
but it is for the client: ask the user.  First, I'm not a huge fan of "ask
the user" in decisions that rely on an understanding of opaque inner
workings of the net, and this runs that risk.  Having users understand
whether specific disjoint reachability domains are disjoint on purpose or
because of some accident of history does not strike me as a likely win.
Second, I don't understand the intended client behavior here if it accesses
web resources via a proxy, and I didn't find any mention of proxy behavior
in the text.  Text about this in the final document would be useful.

Lastly, "public" and "private" are very poor proxies for the actual
reachability information for a specific host.  A host can have multiple
interfaces, address families, and scopes and the mitigations IPv4/IPv6
interworking make that even more complicated.  In the WebRTC case, the
presence of destinations reachable via TURN which are in distinct
reachability domains is another complication. The current reality is that
the destination address does not encode the reachability domain in any
meaningful way *for the host*.  This is especially true in the
unfortunately large number of organizations who have repurposed unrouted
addresses as "extra" private address space (
https://teamarin.net/2015/11/23/to-squat-or-not-to-squat/ is old, but the
practice is far from dead).

If the final proposal doesn't actually tackle that complexity, we will
likely be left with a system that doesn't protect what it intends to
because it lumps all reachability domains into broad classes.  Add to that
a consent request that most users can't parse and wouldn't have the real
data to answer, and I think this is more burden than benefit.

regards,

Ted Hardie



> (But I admit that I'm not versed in Fetch algorithm steps 1 through N so
> I'm not readily understanding "modifications to behaviour between steps m<n
> and n<=N".  Also, it's past my bedtime. :-)
>
> I merely meant that two different private spaces appear to be treated the
> same.  I suspect in practice there's no practical way to distinguish one
> private space from another (short of explicit PVD information).  I still
> think this proposal is no worse than the status quo in this regard, though.
> _______________________________________________
> Architecture-discuss mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/architecture-discuss
>