Replacing TCP with something else isn't going to change anything to being tracked.
IP adresses aren't fixed (for most people), just disconnect your modem for a few hours and you'll probably get a new one.
You are being tracked by cookies, browser fingerprints, only being able to use a website after logging in, etc.
So this might solve some problems, it's not going to just give you privacy or make you untraceable.
Not so long ago a local news site was being DDOSed. The kid that did it thought he was so smart using a VPN. He bragged online how he could bring any website down (sending those messages from his VPN). Until he was dumb enough to keep his VPN open and open this news site in his browser, because he never logged out he was logged in automatically. So the website admin saw his (known) VPN IP and now knew his account. The account he used before from his actual IP.
IP adresses aren't fixed (for most people), just disconnect your modem for a few hours and you'll probably get a new one.
The issue is not that it's static, the issue is that it is getting assigned by an authority. In the solution the random ID is generated on device
You are being tracked by cookies, browser fingerprints, only being able to use a website after logging in, etc.
Although that is possible, my understanding is that the most significant information regarding one's location and identity, after an account, is the IP.
IPs change, maybe you're at home, maybe on mobile, maybe at the office, maybe at a friend's house. The aggregate fingerprint of the remaining parameters, is way better at uniquely identifying anyone, then linking any information that "anonymous unique identity" leaves behind to create a profile that over time becomes easier and easier to deanonymize.
The cookies and so on are the “account.” And the trackers are sophisticated enough that they can track you across multiple devices, meaning multiple IPs.
Does your imagined network protocol also not have MAC addresses? At some level a packet needs to know where it is going, or the receiver won’t get it.
It's an interesting premise, but 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.
I'm fine with that, and that's not censorship as far as I'm concerned
I believe that is a form of censorship, hlocking a whole exit node only because it's used for hacking... it's like blocking a country because most of the users from the country are haters
They want to make it impossible to block other machines by address? Including ones that are attacking you? That's a horrible idea.
Also, this sounds like it will require way too much intelligence in the network itself. The Internet works because the big trunk routers do very little processing per packet—just look at the destination address, decrement TTL, and send the packet to the next router. If trunk routers have to do a lot of per-packet processing or keep track of every single node on the network, they'll fall over very quickly.
Also, this sounds like it will require way too much intelligence in the network itself
Yes that can be a disadvantage
Internet v2
That name's already taken.
The device must be assigned a random ID by the physical layer [...]
Look into IPv6 ephemeral addresses.
Look into IPv6 ephemeral addresses
Sounds good! But does it provide encryption tho?
IPv6 supports IPsec, but I think this proposal would be closer to Tor/I2P over IPv6.
For example, a client using an IPv6 ephemeral address, accessing a Tor hidden site, hosted on another client using an IPv6 ephemeral address, will both encrypt, and anonymize both endpoints, with a very short window for any de-anonymization attempts.
I2P will also scramble the whole connection over multiple circuits.
EDIT: reading closer the proposal, I see you only consider connections to public targets, with intermediate nodes keeping a cache of the circuit, and using a shortest path algorithm. It would seem to me that a client on IPv6 ephemeral using a HTTPS (with ECH) connection over Tor, would be safer than in this proposal. Choosing random intermediate nodes is a feature to reduce the chance of a single actor controlling all nodes on the path and being able to log the whole circuit.
I2P takes that a couple steps farther, adding more intermediate nodes, splitting the send and receive parts over different circuits, and expiring circuits periodically.
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.
know how to route this new protocol without IP addresses
A ptoperly implemented solution will be able to route packets without IP, I believe
We can’t even get mainstream ISPs to support IPv6 in the last 25 years.
Yeah, I don't know if it will be taken seriously. But if then It'd be nice.
Minor: The doc sometimes uses 'it's' where 'its' is more appropriate.
Replacing TCP with something else isn't going to change anything to being tracked.
IP adresses aren't fixed (for most people), just disconnect your modem for a few hours and you'll probably get a new one.
You are being tracked by cookies, browser fingerprints, only being able to use a website after logging in, etc.
So this might solve some problems, it's not going to just give you privacy or make you untraceable.
Not so long ago a local news site was being DDOSed. The kid that did it thought he was so smart using a VPN. He bragged online how he could bring any website down (sending those messages from his VPN). Until he was dumb enough to keep his VPN open and open this news site in his browser, because he never logged out he was logged in automatically. So the website admin saw his (known) VPN IP and now knew his account. The account he used before from his actual IP.
The issue is not that it's static, the issue is that it is getting assigned by an authority. In the solution the random ID is generated on device
Although that is possible, my understanding is that the most significant information regarding one's location and identity, after an account, is the IP.
https://amiunique.org/fingerprint
Notice how the IP is not even on the list.
IPs change, maybe you're at home, maybe on mobile, maybe at the office, maybe at a friend's house. The aggregate fingerprint of the remaining parameters, is way better at uniquely identifying anyone, then linking any information that "anonymous unique identity" leaves behind to create a profile that over time becomes easier and easier to deanonymize.
The cookies and so on are the “account.” And the trackers are sophisticated enough that they can track you across multiple devices, meaning multiple IPs.
Does your imagined network protocol also not have MAC addresses? At some level a packet needs to know where it is going, or the receiver won’t get it.
It's an interesting premise, but 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.
I'm fine with that, and that's not censorship as far as I'm concerned. :shrug:
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.
I believe that is a form of censorship, hlocking a whole exit node only because it's used for hacking... it's like blocking a country because most of the users from the country are haters
They want to make it impossible to block other machines by address? Including ones that are attacking you? That's a horrible idea.
Also, this sounds like it will require way too much intelligence in the network itself. The Internet works because the big trunk routers do very little processing per packet—just look at the destination address, decrement TTL, and send the packet to the next router. If trunk routers have to do a lot of per-packet processing or keep track of every single node on the network, they'll fall over very quickly.
Yes that can be a disadvantage
That name's already taken.
Look into IPv6 ephemeral addresses.
Sounds good! But does it provide encryption tho?
IPv6 supports IPsec, but I think this proposal would be closer to Tor/I2P over IPv6.
For example, a client using an IPv6 ephemeral address, accessing a Tor hidden site, hosted on another client using an IPv6 ephemeral address, will both encrypt, and anonymize both endpoints, with a very short window for any de-anonymization attempts.
I2P will also scramble the whole connection over multiple circuits.
EDIT: reading closer the proposal, I see you only consider connections to public targets, with intermediate nodes keeping a cache of the circuit, and using a shortest path algorithm. It would seem to me that a client on IPv6 ephemeral using a HTTPS (with ECH) connection over Tor, would be safer than in this proposal. Choosing random intermediate nodes is a feature to reduce the chance of a single actor controlling all nodes on the path and being able to log the whole circuit.
I2P takes that a couple steps farther, adding more intermediate nodes, splitting the send and receive parts over different circuits, and expiring circuits periodically.
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.
A ptoperly implemented solution will be able to route packets without IP, I believe
Yeah, I don't know if it will be taken seriously. But if then It'd be nice.
Minor: The doc sometimes uses 'it's' where 'its' is more appropriate.