3 ms·

> whether end users can get at least one public IP. That only gets harder as address space limits[1] squeeze more and more people onto Carrier Grade NAT and si

by pdkl95 7y ago

> whether end users can get at least one public IP. That only gets harder as address space limits[1] squeeze more and more people onto Carrier Grade NAT and similar workarounds. > NAT is actually a security feature. No, it's not. All supposed security features are actually from some other source, because NAT is only ever about changing addresses (or port) fields in the IP header. > it hides specific client host addresses from servers. NAT usually makes your local addresses very predictable. Is yours 192.168.[01].[1-4]? Often guessing isn't needed; the other IP fields that NAT does not touch can be used to differentiate[2] between hosts behind a NAT. > The last thing anybody should want is to leak even more information to the surveillance companies. That's why it's so important that we move to IPv6 asap. The theoretical problem of a few bits of identifiable entropy (differentiating between a few hosts on a private LAN) is trivial in comparison to the centralization that NAT has forced us into. NAT forces network software development into the client/increasingly-centralized-server model[3]. > The point is that a flat address space isn't the RPC-panacea A flat address space is the most important feature of the original internet, because it makes all hosts equal in the eyes of the protocol. You don't need an imprimatur[4] - an authority's permission to publish - to publish from your own IP. You don't need a centralized server's permission to develop new network software that uses new network protocols. Of course we don't want to leak information to a serer, especially those owned by surveillance companies. The way to do that is to write software that doesn't involve that server, which is only possible with a flat address space. Arguing otherwise is arguing we should keep using party lines[3]. [1] http://www.potaroo.net/tools/ipv4/index.html http://www.potaroo.net/tools/ipv4/index.html [2] (section 0x03-2) http://phrack.org/issues/63/3.html#article http://phrack.org/issues/63/3.html#article [3] https://news.ycombinator.com/item?id=20169372 https://news.ycombinator.com/item?id=20169372 [4] https://www.fourmilab.ch/documents/digital-imprimatur/ https://www.fourmilab.ch/documents/digital-imprimatur/

mindslight 7y ago
> That only gets harder as address space limits[1] squeeze more and more people onto Carrier Grade NAT and similar workarounds. Warning: we're awfully close to violent agreement here. I'm saying that the demand for more IPs is primarily for end users needing their first public IP, compared to end users needing public subnets for their devices. > NAT is only ever about changing addresses (or port) fields in the IP header Ya, the changing of which has the security benefit of a remote server not receiving it! I suspect you've become too used to responding to "I like NAT because it blocks connections to my network" to read what I've actually written. > NAT usually makes your local addresses very predictable. Is yours 192.168.[01].[1-4] Sure, for MACs (and guests) that are listed to receive 192.168 addresses because their treacherous software (eg Android, WebRTC, etc) is likely to turn around and leak it... That is the concern I am talking about here, not my local network being actively probed from outside. But most substantively I do not agree with the point in your [3], based on relative significance. I believe the overriding dynamic is that serverless software is much harder to fund. Implementing UPnP and NAT punching is trivial compared to developing, polishing, and marketing software for mass adoption. Meanwhile centralized surveillance is lucrative, attracting massive investment. And don't be confused by the brief popularity blip of end-user hosted websites using DNS, because DNS is a terrible user-facing namespace. It essentially mandates a high availability server standing ready to answer requests for every specific entity. There is no ability to retrieve the latest version of a given object from an untrusted peer.
- pdkl95 7y ago
  > Implementing UPnP and NAT punching is trivial It's possible if and only if you have control of the router. Good luck doing that when it's your ISP doing CGNAT. This is already impossible in some areas (e.g. parts of China) that are behind multiple (5+) layers of NAT. This isn't a theoretical concern; there are already many places on the IPv4 network that cannot get any kind of port forwarding (including UPnP). Also, NAT hole punching is not[5] "trivial". It only seems trivial if you only consider the easiest case. It also requires a centralized server to initiate. edit: re: the supposed privacy benefits of NAT - even if you have globally routable addresses, you can still proxy your HTTP requests through your router if you want to. You do not need NAT to have webservers see a single IP address from your LAN. > harder to fund 100% offtopic; I'm not talking about software funding. The point is that NAT has held back software development. There are entire categories of network software that haven't even been invented yet, because they require being able to receive calls (incoming TCP SYN packets). We don't know what is even possible, because true network software has receive4d very little development effort. > end-user hosted websites That is useful. I know several people that use local hosting for various useful activities. Bandwidth isn't that important if you're just sharing with friends. However, this is yet again an example of the client/server model. You seem to be proving my point that being stuck behind NAT can limit your thinking to the one model that works. For a simple example of non-client/server network software, how about chat software that makes direct connections without the need for a server? (discovery can still use a server; that doesn't mean the chat protocol itself has to be centralized). In ~1996 I did that with very early PGP-encrypted VOIP software that let you simply dial whomever you wanted by their IP address. Just like we dial people on the telephone network by their telephone number. Yes, there are more convenient methods, most of which require trusting a centralized source. To even have a chance at developing something better, we need the ability to develop software freely at the network endpoints, which is incompatible with NAT. > DNS I didn't say anything about DNS. As I said above, you seem to be assuming a very limited range of network software. Of course DNS has serious problems; it's not the only way we can discover IP addresses. I want a future where we are free to invent these new methods, instead of a highly-centralized future where the surveillance capitalists have the power to decide which network connections you are allowed to make. [5] https://bford.info/pub/net/p2pnat/ https://bford.info/pub/net/p2pnat/

by pdkl95 7y ago

mindslight 7y ago

> That only gets harder as address space limits[1] squeeze more and more people onto Carrier Grade NAT and similar workarounds. Warning: we're awfully close to violent agreement here. I'm saying that the demand for more IPs is primarily for end users needing their first public IP, compared to end users needing public subnets for their devices. > NAT is only ever about changing addresses (or port) fields in the IP header Ya, the changing of which has the security benefit of a remote server not receiving it! I suspect you've become too used to responding to "I like NAT because it blocks connections to my network" to read what I've actually written. > NAT usually makes your local addresses very predictable. Is yours 192.168.[01].[1-4] Sure, for MACs (and guests) that are listed to receive 192.168 addresses because their treacherous software (eg Android, WebRTC, etc) is likely to turn around and leak it... That is the concern I am talking about here, not my local network being actively probed from outside. But most substantively I do not agree with the point in your [3], based on relative significance. I believe the overriding dynamic is that serverless software is much harder to fund. Implementing UPnP and NAT punching is trivial compared to developing, polishing, and marketing software for mass adoption. Meanwhile centralized surveillance is lucrative, attracting massive investment. And don't be confused by the brief popularity blip of end-user hosted websites using DNS, because DNS is a terrible user-facing namespace. It essentially mandates a high availability server standing ready to answer requests for every specific entity. There is no ability to retrieve the latest version of a given object from an untrusted peer.

pdkl95 7y ago
> Implementing UPnP and NAT punching is trivial It's possible if and only if you have control of the router. Good luck doing that when it's your ISP doing CGNAT. This is already impossible in some areas (e.g. parts of China) that are behind multiple (5+) layers of NAT. This isn't a theoretical concern; there are already many places on the IPv4 network that cannot get any kind of port forwarding (including UPnP). Also, NAT hole punching is not[5] "trivial". It only seems trivial if you only consider the easiest case. It also requires a centralized server to initiate. edit: re: the supposed privacy benefits of NAT - even if you have globally routable addresses, you can still proxy your HTTP requests through your router if you want to. You do not need NAT to have webservers see a single IP address from your LAN. > harder to fund 100% offtopic; I'm not talking about software funding. The point is that NAT has held back software development. There are entire categories of network software that haven't even been invented yet, because they require being able to receive calls (incoming TCP SYN packets). We don't know what is even possible, because true network software has receive4d very little development effort. > end-user hosted websites That is useful. I know several people that use local hosting for various useful activities. Bandwidth isn't that important if you're just sharing with friends. However, this is yet again an example of the client/server model. You seem to be proving my point that being stuck behind NAT can limit your thinking to the one model that works. For a simple example of non-client/server network software, how about chat software that makes direct connections without the need for a server? (discovery can still use a server; that doesn't mean the chat protocol itself has to be centralized). In ~1996 I did that with very early PGP-encrypted VOIP software that let you simply dial whomever you wanted by their IP address. Just like we dial people on the telephone network by their telephone number. Yes, there are more convenient methods, most of which require trusting a centralized source. To even have a chance at developing something better, we need the ability to develop software freely at the network endpoints, which is incompatible with NAT. > DNS I didn't say anything about DNS. As I said above, you seem to be assuming a very limited range of network software. Of course DNS has serious problems; it's not the only way we can discover IP addresses. I want a future where we are free to invent these new methods, instead of a highly-centralized future where the surveillance capitalists have the power to decide which network connections you are allowed to make. [5] https://bford.info/pub/net/p2pnat/ https://bford.info/pub/net/p2pnat/