Project Logs

Collapse

• routing?

  Michael • 03/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

  Michael • 03/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)

  ((...((((message+z)*z+z)*y+y)*x+x)...)*b+b)*a

  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, usb...you 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