I was checking out my router settings looking for something else when I came across this. The blocked services and there is a check box for “all p2p protocols”. Is this something the devs are working on punching through as well? Are we currently just working on “making it punch the NAT reliably?” This is the first time I’m seeing this option (though I knew it could be set up with firewall rules, I didn’t think it would be so point and click).
Thoughts?
Isn’t the SAFE API html? So such blocking at the router would stop anyone on a local network from using a browser, in which case they’ve got bigger problems than SAFE ants.
On the other hand if they really want to only allow some protocols other than html then the devs might consider something like the Tor plugin that pretends to be a particular app.
Maybe they mean “catch any protocols”. Catching all protocols would only be used for testing purposes.
As far as I know they want to connect on almost all protocols like TCP, UDP, uTP, and use random ports as well. So at IP-level Crust should connect to everything from smartphones to tablets to browsers and more. All without the need to use centralized servers to find out what your IP number is.
Well, it specifically says “all p2p protocols” which would lead me to believe it would try to catch bittorrent (which I believe would also catch uTP?) and was most likely designed for things like limewire and its ilk.
The SAFE API is only a local redirect to the launcher where it gets turned into an actual wire protocol (not the REST syntax we see).
Micro Transport Protocol or µTP (sometimes also uTP) is an open UDP-based variant of the BitTorrent peer-to-peer file sharing protocol intended to mitigate poor latency and other congestion control issues found in conventional BitTorrent over TCP, while providing reliable, ordered delivery.
But remember the Devs are building in encryption from bit nr. 1. So you might connect to a bootstrap-node and get an IP:port for another user at uTP-level without your ISP noticing. Don’t know if they can understand that you are using uTP that way. Same for your router. It might block “visable” connections using uTP but maybe not the encrypted ones as it might not see them.
Unfortunately we can’t just say “encryption solves the problem” with this.
I know that I’m pretty bad at explaining things (my wife will vouch) but I’m going to give this a shot as I feel its important to understand.
In a packet there is a header and a body. The header has to be read by everyone so they know where to send it next. This can’t be encrypted en-route. The body can.
±---------------------------------±------------------------------------------------------------+
|Header - destination | Body of the packed that people in the |
|return addr, sequence # | middle dont need to know anything about. |
|other stuff for directing it | Only needed by the destination |
We dont see any of this. However, even when you connect to google.com or another node on SAFE, every server between you and that server need to be able to direct that packet.
open up a cmd prompt and type “tracert google.com”
All of those computers need to be able to send that packet on to where its needs to go. They have to use that header to do that even if they don’t know whats in the message itself.
If my router (or work’s router) thinks its a p2p packet, it may drop it. There is no difference between a “visible” uTP packet and “encrypted” uTP packet, its still a uTP packet as far as I know.
It is entirely possible that I’m missing something here. I’m not an expert, just an enthusiast trying to learn, but this is how the wire protocols work to the very best of my knowledge.
I think you are right with your example and indeed your router and ISP’s can see it’s a uTP-packet. Even when they can’t see the encrypted data inside.
We don’t know what’s “Catch all P2P protocols” means. Is possible that block uTP or not, or block STUN or UPnP protocols, or block standard P2P ports.
However, crust will work on TCP too, with NAT trasversal, so I don’t see any problem to connect with the Network.
I fact, the Crust’s Devs is working in this new method for UDP and TCP multi-hole punching who work in almost all the routers.
All p2p is probably well known p2p ports. So we should be fine. In terms of encryption we will encrypt all payload traffic. Header must be left alone but utp header is not udp header so all of the utp header can be encrypted. The secure_serialisation crate provides authenticated encryption for this purpose.
All tcp and udp headers must not be encrypted but utp can be. Also random ports helps. In terms of IP info this is just between nodes in routing tables and clients → bootstrap / relay nodes. If you run a home vault then you relay through it, which means your ip is only seen in your hose, which will help a lot as well, although your vault’s ip will be known to it’s routing table members.
