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

[Erik Kline <[e-mail]>]

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.