search

DavidSchinazi / draft-cms-masque-connect-ip

Other
2 stars 1 forks source link

Requesting or requiring NAT #11

Closed martinthomson closed 3 years ago

martinthomson commented 3 years ago

I know that it is not common for this to be requested. In fact, some services deliberately try to provide public addresses because NAT can make certain uses harder, particular bidirectional flows.

The idea is that a shared NAT is a privacy feature, especially if it is shared by many. If the proxy can provide an address that follows a route via a router that performs NAPT from a shared address pool, then flows originating from this tunnel could be made more or less indistinguishable from flows from other users. That means better privacy with respect to services on the other side of the NAT.

The only potential addition would be a flag on address assignments and requests indicating whether NAT is in use or preferred (respectively). It might not need any actual protocol: you might make this a property of different MASQUE endpoints instead: this one provides NAT, this one doesn't, and this one has no guarantees either way.

DavidSchinazi commented 3 years ago

I'm not sure this needs to be negotiated in the protocol. As far as I know, IPsec, OpenVPN, WireGuard, et al. don't offer this negotiation. I'm inclined to treat this as a matter of local policy.

achernya commented 3 years ago

Given that we're leaning towards using URIs in the discussion on #13, I would suggest that if a service operator wanted to provide such capability they could implement it with different URI endpoints. This allows this to be up to the service operator to specify as a matter of local policy and does not require any further protocol capabilities.

martinthomson commented 3 years ago

As I was writing this up, I realized that this sort of "optimization" is likely a very good use of the URI. No need for protocol specification. Feel free to close this along with #13.

DavidSchinazi commented 3 years ago

Sounds good, will do. Thanks.