Dumpnet drafts, and societal models

Attached at the end of this post will be some drafts of the Dumpnet protocol and specification. There’s some good ideas in them, and a kernel of truth in the idea presented there of Ant Routing. However, these drafts are crap for a number of reasons, both technical and societal.

A perfect society wouldn’t need the DUMPNET. A perfect society would have distinct similarities to a surveillance society: Cameras, records, logs would be everywhere. The difference would be that while a surveillance society would keep those records to those in power, a perfect society would keep them open to anyone.

Granted, this probably wouldn’t work for any number of reasons, but it’s a nice hope. A society where security procedures and anonymity are unnecessary is simply a dream, because there will always be a fringe who attempt to work outside the system.

Where is the DUMPNET necessary, then? Really, it’s current design is for a dystopian society. It allows perfect anonymity. Nobody can prove which packets you sent, or just routed, without careful examination of your computer. The design is paranoid. More along the lines of a cyberpunk world. Not practical in any way.

Not everyone shares my idea of a perfect world. I know some people who would love to live in said dystopia cyberpunk world. Even in our world, they live and value privacy as if they were living in that world. It’s not a bad attitude to take, all things considered. It serves them suprisingly well, if not the best socailly.

Most of those friends are people who I would consider “Hacker” friends. It’s not coincidental. Technological people tend to have higher concerns for issue like privacy. Perhaps because we better understand exactly how much data is being collected, and how it’s used.

I like the idea of the darknet. I like both the idea of freedom and the community that surrounds it. I like the idea of creating a service that can be used to make the world better. I like the access, the intrigue, and mystery that surrounds it.

I’m re-writing the spec. It was written as both a layer 3 and 4 protocol, but really, what’s important is the layer 3.

DUMPTRUNK Server Routing Protocol.

Programs that operate over the DUMPNET supply the DUMPTRUNK node with a Public key on which to listen. They are then allowed to send packets to the DUMPNET, as permitted by server policy, and all incoming messages with a DEST matching their key are routed to them.

To send a packet, the DUMPNET programs simply send a basic encapsulation of the packet to the DUMPTRUNK node along their connection to it. This should be essentially a full packet, with ID at 0. It should already include DEST, TTL, SRC, ID, and DATA, and data should be pre-encrypted. DEST should not be hashed.

The DUMPTRUNK node hashes DEST, lowers TTL according to policy, hashes SRC with it’s own private key if non-zero, sets ID

A packet, be it ANT or DATA, is received via a connection. The DEST hash is checked against the public keys registered with this DUMPTRUNK routing node. If it does not match, the ID is checked with the “Recent ID” table. If that returns a match, the packet is dropped. Zero should always be on the “Recent ID” table.

If there is no match on the “Recent ID” table, SRC is hashed with the DUMPTRUNK node’s private key and TTL is modified, appropriately. The new SRC is added to the public key table, along with the interface upon which it was received. (Unix Model note: If designed properly, there needs be no differentiation between a registered program and a linked node within the routing table. It’s just an opened filehandle.) It is then forwarded to each other node that is connected.

If the DEST matches one of them, it is determined whether it is an ANT or DATA packet, by the value of ID. The SRC and DATA are then passed on to the program that “owns” the public key.

DUMPNET Ant Packet specification:

An ant packet is used to set up a connection. It consists of the following information

DEST: A hash of a public key specifying destination.

TTL: A number, counting down the number of hops left to go for a given packet before it should be destroyed. TTL is one of the more flexible parts of DUMPNET. It should be randomized at the sender’s end, and at each node. There must be a general downward trend, but a 50% chance of reducing by one hop, a 40% chance of reducing by two, and a 10% chance of increasing by one helps mask the network architecture. Each DUMPNET routing node software MAY handle this differently.

SRC: An identifier, essentially a repeated crypt of a public key used in linking packets.

??? ID: An identifier, unchanged from node to node, to reduce traffic by preventing broadcast collision.

DATA: A further message, encrypted, with the same public key as used to generate DEST.

Dumpnet Packet Specification:

DEST: the SRC of the ant that was received to create the connection.

TTL: As above

SRC: Zero. There’s no need for a backtrace in this occurance.

??? ID: An identifier, unchanged from node to node, to reduce traffic by preventing broadcast collision. Note that, since the DEST should be a direct path, this should be 0. Perhaps this should be omitted for packets with a SRC of zero?

Leave a Reply