- cross-posted to:
- programming@programming.dev
- cross-posted to:
- programming@programming.dev
Read the doc, what are your thoughts?
You must log in or # to comment.
I don’t think we need to dump TCP/IP, at least not for the Layer 4 TOR-like approach the article is suggesting.
There are lots of reasons to block an IP (or range) that have nothing to do with censorship. I audit my logs regularly to find IPs or IP ranges that are doing nothing but hacking attempts and block them in the firewall. I also have automated tools taking care of that in many cases (yay, Fail2Ban). I’m not censoring anyone in doing so, merely protecting my assets.
At the application-level, sure, I’m on board with what the article is suggesting. Many tools already exist for that and run on top of IP just fine. In those cases, they’re no more or less susceptible to ISP/jurisdictional blocking than the solution proposed in the article, so no need to throw the baby out with the bath water.
Long story short, I do not ever want to run services, exposed to the world, where I cannot defend them from bad actors by denying them access at the network level.
what if someone is using Tor to hack your services? Then you will be blocking Tor exit IP,therebty also censoring Tor users.
Overlay networks like Tor has another problem too, you will have to trust the network nodes, and someone can just run a lot of nodes to control a big portion of the network, or can just deny acces to the network.
what if someone is using Tor to hack your services? Then you will be blocking Tor exit IP,therebty also censoring Tor users.
I’m fine with that, and that’s not censorship as far as I’m concerned. :shrug:
Overlay networks like Tor has another problem too, you will have to trust the network nodes, and someone can just run a lot of nodes to control a big portion of the network, or can just deny acces to the network.
I was referring more to I2P “eep” sites and TOR hidden services (and similar). Basically an overlay internet that operates separately. I’m not saying TOR / I2P /etc aren’t without their problems, but they’ve got a huge head start in addressing them versus something brand new.
But the big issue in replacing TCP/IP, the core protocol of the internet, is that IPv6 was introduced in 1995, has been supported by routers/OS’s not long after, was ratified as a standard in 2017, and is still not deployed as widely as it should be. Replacing IP entirely is just not going to happen since it will require replacing or at least firmware updating millions/billions of routing devices to support a new protocol. Anything that supplants TCP/IP is likely to be an evolution rather than a re-imagination.
Minor: The doc sometimes uses ‘it’s’ where ‘its’ is more appropriate.
Ditching TCP/IP and defining a whole new protocol stack would require your ISP to have routers that know how to route this new protocol without IP addresses. Also, every router between the source and destination would have to support the protocol also. That seems like a huge hurdle. We can’t even get mainstream ISPs to support IPv6 in the last 25 years.
Unless the author intends to layer this on top of IP, which defeats the defined goal.
If you did this, you would be running your own “Internet” with only your own routers connecting to each other.
