search

WICG / private-network-access

https://wicg.github.io/private-network-access/
Other
58 stars 22 forks source link

Define "private" and "local" in terms of properties of the relevant IANA registry #30

Closed sleevi closed 3 years ago

sleevi commented 3 years ago

This is a subset of issue #28 , and addresses the Carrier Grade NAT / Special Use address.

Presently, the spec states:

An IPv4 address is a private address if it matches the private address space defined in Section 3 of [RFC1918], a local address if it matches the "loopback" space (127.0.0.0/8) defined in section 3.2.1.3 of [RFC1122] or the "link-local" space (169.254.0.0/16) defined in [RFC3927], and a public address otherwise.

However, the "source of truth" for these reservations is the relevant IANA registry, which captures all of the relevant reservations (such as what @thejh raised with RFC6598)

With this approach, the following rules should give equivalent results, but support the full spectrum of reserved allocations

This isn't perfect, as there are still reserved address spaces that would be treated as public.

However, this also matches Chrome's current implementation, and would cover the situation raised in Issue #28 regarding VMs

letitz commented 3 years ago

That sounds like a great idea. I'll amend the spec.

letitz commented 3 years ago

I went through the IPv4 registry to see how the above proposal would play out concretely.

Here are the special-use registrations classified by address space:

I'll want to dig into a few of these a bit more to understand whether the classifications make sense, but on a surface level they look good :)

thejh commented 3 years ago

I think it's noteworthy that this will classify things like TEST-NET-1 as local; so if a private network uses these (in violation of the RFC?), that would allow the network to gain access to 127.0.0.1?

If addresses of the same type are allowed to interact freely, then local must be restricted to addresses that operating systems won't route onto the network (independent of what the router tells the local machine about the private network).

letitz commented 3 years ago

That's fair, and simple enough to fix. How about this alternate definition?

It hardcodes the IPv4 and IPv6 loopback addresses, but otherwise defers to the registry for private vs public distinctions?

thejh commented 3 years ago

I think that sounds reasonable.

letitz commented 3 years ago

It just happens to match the current implementation in Chromium too! :tada:

I'll see how it plays out with the IPv6 special-use registry.

letitz commented 3 years ago

Here's the classification of the IPv6 special-use registry assignments according to the rules laid out in comment https://github.com/WICG/cors-rfc1918/issues/30#issuecomment-728980926.

private:

The following assignments have a Globally Reachable value of N/A... Not sure what to do with those.

public:

We might want to make an exception for IPv4-mapped addresses, and instead consider the address space of the embedded IPv4 address?

letitz commented 3 years ago

A strict reading of https://github.com/WICG/cors-rfc1918/issues/30#issuecomment-728980926 yields that both TEREDO an 6to4 should be considered public, as their Globally Reachable bit is not explicitly False. I think this makes sense as a default stance, since it gives less privileges to such IP addresses.

I'll amend the algorithm to handle the IPv4-IPv6 mapped addresses: in that case, apply the algorithm to the encapsulated IPv4 address.

Will send a PR to fix the spec.

letitz commented 3 years ago

Fixed by #31.