Internet 2

a really decentralized free network

Similar projects worth following
The internet has become as fundamental as electricity, books, phones, cars. The idea was to have a robust, fault tolerant network by decentralizing the management and allowing arbitrary routing.
But that's not what it is anymore.
You have centralized providers, your data packets are intercept and analysed, by goverments, but companies down to a point where you become liable if someone uses your wifi, when some company claims some media was transferred over your IP.
It has essentially become a 1 to 1 network architecture, where the user has no way to control the rights he has in any way. The image on your phone that you share with the person in the same cafe might be inspected for legality, priority. it might be backed up on severs you don't know about, you might be classified for race, age, sexuality, religion and this knowledge might be exploited for marketing or to limit your career.

there are 2 issues why the internet is exploited.

Issue 1 is that while in theory you could combine networks dynamically, they are static mostly and routing follows static hierarchies. The message you send to your neighbor might hop through the central internet node of your country.

Issue 2 is that your connection and data is transparent. It's like if you had told your postman the message and the name of your friend that should receive it. Now postman to postman it's told until the postman of your friend tells it eventually to your friend.

In reality, your provider might just check the protocol you're using and if you've paid extra for it, route it a fast path or if that protocol causes a lot of network load, delay the transportation. Your government might parse it for keywords, protocols etc. Arriving at your neighbor's PC, it might be the trojan horse for something, it might be censored, alternated etc.

To secure something fundamental as your personal freedom, which you don't own anymore on the internet, you need to secure ownership of the content and transportation up to the recipient.

On high level that means those two issues need to be resolved.

1. Just you should know and own the route of your packets.

2. Just you should know the content and address of the recipient.

  • routing?

    Michael03/16/2015 at 09:29 0 comments

    Been thinking a lot about routing the past days. Actually not the routing, but knowing all the hops. I'm open for any suggestion or discussion.

    1. Broadcasting ping

    This has some neat possibilities. First of all, nodes could cache results. If you ping a depth of 2, it means for all receivers they don't need to ping any further, you'd get a list of their direct peers. This ping also registers you at all neighbours. With the result of the ping of depth of 2 you also cover a subnet fast, e.g. in a cafe you'd realize every client sees the same, just the up-link (aka free wifi ap) would show you a list with a unique link. Albeit imagin a block and every apartment has a node, you'd be able to progressively ping your way until e.g. you could play a lan party with your friend on the other side of the block without every the need to go through the net of any big provider.

    2. Registration echo

    Every peer would forward it to all, unless it already knows about you, then the registration echo was already received previously and forwarded. This would look like a wave through the net. Provider could use an uplink architecture that just forwards those registration echos up the chain. Some root nodes would act like DNS nowadays, but without any legal or other issues, there would be no country or organization that maintains this, you'd just register with any public key you want.... this time by using your private key to sign the current time/date. if anyone would try to spoof you, they'd need to sign the packet with a newer date and therefore they'd need to know your private key. "DNS Spoofing" would not be possible.

    3. resolve ping

    That would be like an DNS query, or rather a google query... or rather like a search with a data sharing network. But you could use previous knowledge to improve the search, e.g. send queries to the hops of the last time you've communicated to the address of your target. The person has maybe not moved at all (e.g. his home network knows him), so if you'd ping his router, it very likely knows your target. But even if the person moved, it is very likely in the same city, pinging higher nodes might track this person down and ultimately, in the worst case, one of the root hops of internet2 got his registration echo (from 2.)

    Your device would manage a DB with connections and when you buy it, it would have a clone from your device vendor with the basic upper level nodes just so you don't start at 0. But this could be very custom, some military organization might have even black lists of nodes your device should avoid.

    Companies on the other side could whitelist nodes that can communicate within the network, there would be no subnet masks. It could be a totally isolated network or shared across all companies within the same building. you would share the bandwidth, but again no security issues, as every packet would always be encrypted.

  • a few Solutions

    Michael03/12/2015 at 08:10 2 comments

    A few solutions.

    1) As mentioned in comments already, the base of the network is cryptography. Every recipient is identified by a public key. Assuming no two keys the same, just one person is identified uniquely. This also prevents man-in-the-middle attacks. Addressing a public key means you know the public key. If you address a man-in-the-middle, how would he know to whom you want to write?

    That's the advantage to have cryptography a key component of the network architecture instead of just layering it on top. Another advantage is that there is no centralized organization governing the addresses. If we use variable length RSA, then you could extend the space to whatever bit-count you want. As nobody on the route needs to decode your RSA address, just the end points, you could very well go with 16384bit if you need to.

    2) Routing is done by the client. It's easy to intercept your messages if they're managed by unknown hops. it's also a high load for the hops to identify the route for every packet. It's also extremely energy inefficient as this is done again and again. It might look like impractical at first, but crypto currencies let you download Gigs of transactions, which is basically a routing tree for money transfers, you could imagin it very alike for Internet 2.

    It would work like a gift that is recursively wrapped. let's say we have nodes A,B,C...Z to your target Z and every node has a public key: a,b.c....z to transfer your message, you'd reversely wrap your text and attach the key to the target. (Assume that * is the encoding operator and + is the attach operator)


    now you send your packet to the first node 'A'. it decodes your message with its private key a'. it reads the attachment, which is 'b' the public key aka address of the next node. 'B' also decodes the new packet with its private key b', reads the attached address etc. until it arrives at 'Z'.

    You see, nobody can decode the whole route, nobody knows the real target as the package could even be send around the world back to the origin. Nobody can manipulate the final message without knowing the private key of the recipient. And the limit in size automatically limits the age a packet can reach. once it is 0 in size, there is nothing to route.

    There is just one real validity check at the end. if a node decodes an attachment that points to itself, it's was the target. If there is a transaction error, the decoded packet will have an address of the next hop that is totally nonsense, thus unknown to the current node.

    3) It needs to be a totally unified ad hoc network. This guarantees that nobody owns it, there is no real hierarchy that could be exploited and there is no weak link in the chain. The security of the data would rely on the RSA security and the security of the device of both ends, even if you'd transfer the message on a postcard, it would be safe.

    Sitting next to a person, sending data, you wouldn't need to send it to a cloud, across countries and security gates, it would be a direct connection and even then totally encrypted. It could be done via blue tooth, wifi direct, fire wire, could even save data on a memory stick and pass the stick to the recipient who'd decode the packets.

View all 2 project logs

Enjoy this project?



Michael wrote 03/10/2015 at 22:59 point

I agree, and I don't aim for rocket science here. But the Issue arises because there is no end-to-end encryption in the lowest level. Every protocol has to add some kind of encryption. ftp->ftps and sftp, http->https, smtp? pop3? and what about those millions of apps in the stores? 

The problem is not only whether they add some encryption, but who has access to decryption? what algorithms are used? is it safe?

well, I guess my point is. why is there anything without encryption? I understand that it was an exhaustive task back then for 8bit cpus to run some 1024bit RSA. But nowadays it should be fundamental to your network. Every packet that leaves the software layers of your OS to the actually network devices should be already encrypted.

along that way, every node in the route to your target should just get the encrypted address of the next node. nothing more is needed to forward your packet. (not knowledge needed who send it, nor how many nodes are ahead of it.)

that's why I would suggest that instead of using IP addresses, you rather use the public encryption key as target. If the routing is made by the clients and not the nodes, then there should not be a problem with exploding routing tables, as all a Node needs to know is the private key of its own address to encrypt the address of the next node.

maybe my view is too simple and that's why I don't see a problem (yet).

  Are you sure? yes | no

PointyOintment wrote 03/10/2015 at 22:29 point

"Issue 2 is that your connection and data is transparent. It's like if you had told your postman the message and the name of your friend that should receive it. Now postman to postman it's told until the postman of your friend tells it eventually to your friend."

That's easily solved with end-to-end encryption.

  Are you sure? yes | no

Similar Projects

Does this project spark your interest?

Become a member to follow this project and never miss any updates