Re: [w3ctag/design-reviews] CORS-RFC1918 (#572)

As for the IETF comments, I see a few main points beyond what Martin summarized above. Here is my interpretation of these (indented for clarity, not because I am quoting anyone):

### 1. The specification is misleading, purporting to fix things that it cannot entirely address.

This is a fair point. The spec can and should do a better job of explaining the limitations of this approach. Filed https://github.com/WICG/private-network-access/issues/47.

### 2. IP address bits are insufficient to correctly understand network topology.
 
Entirely agreed. This is a practical, non-theoretically-satisfying approach that can meaningfully improve on the status quo (no protections whatsoever) with minimal breakage. This should be clarified, per https://github.com/WICG/private-network-access/issues/47.

#### 2.1. NATs confuse `private` and `public` IP addresses.

I don't fully understand the point being made here. Some private IP addresses are used for "globally-reachable" endpoints and NATed. I believe this entails that IP addresses behind the NAT will believe that they belong to the same private network, when they could e.g. belong to different ISP subscribers.

I can see two consequences:

- a) it exacerbates issue 2.2.
- b) if a website wants to connect to another IP address behind the same NAT, that might be incorrectly treated as a private network request, if the request uses the real (non-translated, private) IP address.

b) looks very unlikely to me. Either the website makes a request to a hostname that requires a DNS lookup, in which case the DNS would have to return the non-translated address (possible, but a bit weird), or it would have to target the non-translated address, in which case how could it know the address without itself being behind the NAT?

#### 2.2. Treating all `private` IP addresses as belonging to the same `private` address space is incorrect. Many private IPs reside on distinct networks and cannot reach each other.

Correct. This is still an improvement on the status quo, where even `public` IP addresses can talk to `private` IP addresses. This should be clarified per https://github.com/WICG/private-network-access/issues/47.

#### 2.3. Large networks (e.g. corporate) make use of globally-reachable addresses for their private networks. These are left unprotected. Ditto for IPv6 addresses behind firewalls.

I have been thinking that a mechanism for administrators to override the address space of certain subnets would be very useful. Filed https://github.com/WICG/private-network-access/issues/48 for this. This allows network administrators to opt into the protections afforded by this spec. It does not address the home IPv6 angle though.

#### 2.4. Some network operators make use of unrouted IP addresses for extra private IPs.

IIUC these should not be considered "globally-reachable", thus they should be considered `private`.

### 3. The SOHO pharming link is broken.

Filed https://github.com/WICG/private-network-access/issues/49 for this.

### 5. Having "browsers decide" (unilaterally) what is OK and not is misguided.

This seems to stem from a misunderstanding of the CORS part of the specification. The browser does ask the target endpoint whether or not to allow the connection.

Beyond that, it is true that browsers are making decisions regarding what they allow or do not allow. I do not see a qualitative distinction between this and say mixed content. User agents have a duty to protect their least-technically-savvy users.

### 6. What happens to old devices that cannot update?

This is touched upon [in the specification](https://wicg.github.io/private-network-access/#example-deny-by-default): the expected failure mode is that they do not reply to the `OPTIONS` request and thus are protected.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/572#issuecomment-819519940