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

[Erik Kline <[e-mail]>]

On Tue, Mar 30, 2021 at 10:59 PM Erik Kline <[e-mail]> wrote:

> On Tue, Mar 30, 2021 at 10:25 PM Martin Thomson <[e-mail]> wrote:
>
>> There is a proposal to add extra controls to the Web to prevent servers
>> on the "public" Internet from connecting to "private" resources without
>> consent:
>>
>> https://wicg.github.io/private-network-access/
>>
>> The short story here is that the Web has always included was in which
>> browsers aim to protect themselves from the repercussions of their actions
>> on networks that have insecure local services.  Basically, the browser asks
>> the service for permission before it makes requests.  However, in the
>> interest of compatibility, these protections have always had exceptions
>> where no such permission was requested.  This proposal simply eliminates
>> those exceptions for "private" addresses.
>>
>> The way that this works is fairly simple.  The IPv4 and IPv6
>> special-purpose address registries [1][2] have a "globally reachable"
>> flag.  If this flag is false, then a browser will always ask for permission
>> before using a service on one of those addresses.  The browser will look
>> for a new signal from the server (one that is unlikely to appear purely by
>> accident) before it continues to make requests.  There's another similar
>> protection when going from non-globally reachable addresses to loopback
>> addresses.
>>
>> (Note that this doesn't prevent cross-protocol attacks; it assumes that
>> the server is talking HTTP.  HTTP is not that great at cross-protocol
>> attacks, but there is a separate blocklist for ports that aims to manage
>> that.)
>>
>> The question then: is this is a reasonable approach for minimizing harm?
>> Is this sort of approach consistent with the vision for the addressing
>> architecture, or is this an abuse of these flags?  Are there guidelines
>> that we might follow in treating addresses based on their attributes?
>>
>> My read here is that this is in line with design intent, but I claim no
>> particular expertise with respect to the addressing architecture.  From my
>> perspective, closing consent loopholes is a good thing.
>>
>> Obviously, there is a school of thought that says if you stand up a
>> networked service, then you need to protect it properly.  This isn't about
>> ensuring that you use HTTPS or that you properly authorize access to
>> resources that should be protected.  This is about browsers taking steps to
>> avoid being complicit in attacks on services that aren't properly protected.
>>
>> I should also point out that there is no protection conferred if a
>> service is reachable via an address in a globally reachable space.  The
>> proposal doesn't really acknowledge this possibility, but it's implied.
>>
>> Cheers,
>> Martin
>>
>>
>> [1]
>> https://www.iana.org/assignments/iana-ipv4-special-registry/iana-ipv4-special-registry.xhtml
>> [2]
>> https://www.iana.org/assignments/iana-ipv6-special-registry/iana-ipv6-special-registry.xhtml
>>
>> _______________________________________________
>> Architecture-discuss mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/architecture-discuss
>
>
> I'm not clear how much this will really achieve in the presence of typical
> IPv6 addressing.  For example, though I haven't read this entirely nor in
> detail, the text in 2.2 is somewhat curious.  My reading of that, for one
> example scenario, is:
>
>     [1] suppose a URL's host resolves to an IPv6 ULA address
>     [2] likely the client has a ULA address as well as a few GUA addresses
>     [3] RFC 6724 source address selection selects the ULA source for the
> ULA destination
>     [4] ergo connection is not deemed private --> any web page can cause a
> client to connect to "private" IPv6 destinations
>
> Wouldn't the same be true of a client with only an RFC1918 address, i.e. a
> web page can cause connections to RFC1918 destinations?  I'm sure I'm
> misunderstanding something here.
>

My mistake.  I think the key text I didn't property absord was "the current
url's host".