Non-Text Versions
PunkNet
(Unformatted Text Version)
ANNOUNCEMENT: Wed Mar 24, 2004
New version of this document coming soon!
There is movement on PunkNet development at last!
--- Old paper (primarily just to help make sure of Prior Usage) ---
Date: Friday, 26 July 2002
Version: Draft 0.14
Status: White Paper
Author: The Jon
PunkNet Defined
A Design for an Anonymous Ad-hoc Transport-layer based Connection-oriented network
Contents
Abstract
Overview
Entities and Nomenclature
Nomenclature
Substrate
Neighbour
JBOX (and Carriers)
Channels
PPOP
PA
OverPunk
Link-Layer Substrate Models
Radio Model
IP Model
Anatomy of a PunkNet Message
Neighbours
JBOXes, Tags and Carriers
Channels and PPOPs
Divided-Content and Upper Layers
OverPunk
Appendix A : Ineffectiveness of Malicious attacks on Hop-counts
Appendix B : IP Model - UDP Direct
PunkNet - Abstract
PunkNet is an attempt at an anonymous-traceless, ad-hoc network.
This means that it is impossible to tell the physical location of a client or a server, or of any nodes on the path between them, and that a node can enter or leave the network at any time or at any point.
It is now widely accepted that networks of this kind will become increasingly important to society.
PunkNet is a dynamic model, that rebuilds itself very frequently, and in which no paths are permanent. The problem of then having standing publishable "addresses" is then very different to the same problem for "normal" networks.
PunkNet can cope with a high degree of network outage and node movement, and is therefore almost a "battlefield" communications technology, as it has to be to survive in the real world.
PunkNet is not necessarily fast! The primary goal of this design is to achieve totaly anonymity whilst allowing publishing, not necessarily go for maximum speed. As a result, this design is more of a batch/http type model, not a fast real-time model. The design here is as highly evolved as the current author can get it thus far, but efficiency is certainly something to keep a strong focus on in further research.
PunkNet makes some use of Public Key Encryption, PKE, and it is assumed that the reader is familiar with this technology. PunkNet does not rely on PKE to do everything it needs to do - many people pin all their hopes of anonymity solely on PKE - but PKE is very important to some of the setup processes of PunkNet.
The model described in this document may seem complicated at first, leading one to wonder why it has to be so. However, the complexity here is more in describing what is going on, rather than in the way that the mechanism actually works.
Furthermore, remember at all times that this model is attempting to solve two problems simultaneously:
(1) create an ad-hoc network which can tolerate a high degree of node outage
(2) allow that ad-hoc network to operate whilst keeping the physical locations of all nodes hidden from all other nodes and all outside observers.
Its a challenge to say the least because:
Ad-hoc networks have their own unique set of design problems.
Anonymous networks have their own unique set of design problems.
In some aspects ad-hoc networks and anonymous networks help each other to function, and in others they are independant of or even interefere with each other.
The goal, therefore, is to design a network where the two paradigms come together in harmony.
The rough outline of how PunkNet addresses this general dichotomy, may be described metaphorically as:
Create You. You are an owner entity in a House
Build a rigid Tube from You to somebody else's House.
Feed a flexible Hose down that Tube. When it reaches the end it will connect onto some sort of "spigot".
When the flexible Hose has connected to the House at the other end of that rigid Tube, speak down the Hose and ask the owner of the House to connect the Hose to another House.
The owner of the House will (all things being proper) build a new rigid Tube from itself to the new House.
When the new rigid Tube has connected to the new House, the first House will feed the flexible Hose (that is coming from You) through the new Tube to the new House.
To do this indefinitely:
When the Hose has connected to the House at the other end of that Tube, speak down the Hose and ask the owner of the House to connect the Hose to another House, and so the flexible Hose can travel far afield ...
Now:
To make a House into an address for your Hose, you speak down the Hose to the House at the other end and ask its owner to do so.
To connect to an address (a specific Hose end in a specific House) that you have heard of (somehow), you push your own Hose to that House and ask the House owner to connect the end of your Hose to the end of the Hose that is addressed there. After that, you and the owner of the other Hose effectively have one big flexible Hose connecting the two of you together.
Why a metaphor of rigid Tubes and flexible Hoses ?
Because -
You can only see down a rigid Tube to the first junction. As soon as the next Tube diverges away from that junction you have a corner you cannot see around.
We assume that the only thing that you can push down that Tube is a flexible Hose, and that the junctions automatically know how to connect up Hoses properly.
A flexible Hose can be pushed around a junction corner and on up a different rigid Tube (you are still relying on the junction to do things properly).
Once the Hose is connected, to whatever target, you can for instance blow water (/air etc) up the Hose.
The junctions will not care about what is being carried via the Hose, they only care that the Hose connectors are set up properly.
The water (/air etc) will eventually reach the end of the Hose, at a target House, and appear there - But! Even though you know how you instructed the "system" to get that Hose to that target House:
You don't know physically where that target House actually is.
You can't see down more than the first rigid Tube to try and guess where the flexible Hose is going, and the junction won't tell you.
The water in the flexible Hose is purely a matter between You and the target House at the end of the flexible Hose, and is no business of either the junctions or the rigid Tubes (and this can be enforced, see later).
PunkNet - Overview
The set of problems that PunkNet is attempting to address may be listed roughly as:
Keeping an at least useful bandwidth and latency
Detecting blockages to transmission and automatically routing around them
Connecting across the network to physically remote nodes, in reasonable time
Joining onto the network in reasonable time, given that a new node is allowed no prior knowledge of the internal structure of the network
Creating a point of presence and announcing it, so that others may connect to it
And we assume that all of these take anonymity for granted - at no time do any of the above actions contribute significantly to exposing the physical whereabouts of any of the participants.
The design components that, in this model, address these problems may be grouped, in fact layered, bottom up, as:
At the lowest level, PunkNet has a physical link-layer Substrate.
On top of the physical link-layer Substrate sits the Neighbour system, which allows nodes to enter the network, find some other nodes to talk to, and is the first layer of defence against transmission blockages.
The Neighbour system is PunkNet's approach to establishing an orderly interface between nodes "floating in a sea" of other nodes.
On top of the Neighbour system sits the Junction Box - JBOX for short - system, which allows messages to travel some distance through the network - that is, the messages can travel several Neighbour hops.
The JBOX system is different in nature to the Neighbour and Substrate systems which is why it deserves mention on its own. Whereas the Substrate and Neighbour systems allow nodes to reach out and discover other nodes directly, the JBOX system actively builds new information into the network and nodes rely on it to tell them things about remote nodes. It is - sort of - a push versus pull system.
The JBOX system layer implements and uses what is called the Carrier transmission system, and implements and uses what is called the Channel transmission system on top of the Carrier transmission system. These elements come together to form communication conduits that have "elbows", or "corners", around which physical information about the network cannot be seen.
The JBOX system is PunkNet's primary way of firewalling connections between nodes so that they can talk to but not expose each other.
On top of the JBOX system, which forms the major backbone set of structures in PunkNet, sits the PPOP system which provides a means to create semi-permanent Points Of Presence that other nodes may use the JBOX system to connect to. This system layer uses what is called the Channel transmission system, which sits on top of the Carrier system maintained by the the JBOX system layer.
The Channel/PPOP system is PunkNet's way of doing useful business, especially across long network distances.
The reason that there are two distinct transmission systems, the Carrier system and the Channel transmission system which sits on top of it, is that the Carriers form "straight-line pipes" between JBOX's, whereas the Channels form "flexible hoses" that get around using the Carrier "pipes".
The details are roughly as follows:
The Carrier system is the actual node-by-node, hop-by-hop, tag-by-tag, physical connection to a JBOX - eg. for a JBOX to talk to another JBOX.
Thats as far as it goes, it is purely for establishing a peer-to-peer relationship between the two nodes, across however many Neighbour node hops separate the two of them.
A Carrier is a duplex pipe between a node and a JBOX, carried across various Neighbors that may exist between this JBOX and the other JBOX.
A Carrier cannot be relayed.
The Channel system is a higher-level communication system used by a node to talk to a remote node (which happens to always be a JBOX, but ignore that for now), and it sits on top of the physical connections provided by the Carrier system. A given Channel may pass through several JBOXes on its way to the the target, and is carried by the Carriers that exist between those various JBOXes.
A Channel is a duplex pipe between a node and another node, carried across various Carriers that may exist between the JBOXes along the route.
A Channel can be relayed infinitely.
Neither of the two systems can be multiplexed, deliberately:
A Carrier cannot carry, or be carried upon, another Carrier
A Channel can be carried upon a Carrier, indeed it has to be, but :
A Channel cannot carry a Carrier
A Channel cannot carry, or be carried upon, another Channel. (There is an exception to this rule, but it is buried inside the PPOP implementation details of the PunkNet design, covered below)
Thus, the two transmission systems achieve different goals, with the Carrier system essentially acting as a physical Substrate for the more virtual Channel system.
PunkNet - Entities and Nomenclature
Nomenclature
Client
This is only a naming term and does not really have any existence in the PunkNet protocol.
A Client is a Node.
A Client is just the name given to a Node that initiates a connection to a Site (see below).
Site
This is only a naming term and does not really have any existence in the PunkNet protocol.
A Site is a Node.
A Site attaches information onto the network, to be accessed by Clients, and causes the appropriate information to be published, using the network, that will allow Clients to connect to the Site and retrieve data from it.
A Site is just the name given to a Node that takes on these responsibilities.
Key
A Cryptographic Key, eg. a Public Key, Private Key or a pre-agreed Secret Key.
Key { }
An encrypted item of data. Whatever is in the {} braces is encrypted using the Key.
Tag
A number that acts as a reminder or label for something.
Hop-count
A number which decrements as a message travels.
Hop-counts are used in the Substrate and JBOX layers, described below.
Note: A hop-count can be used quite safely in PunkNet.
See: Appendix A : Ineffectiveness of Malicious attacks on Hop-counts
PunkNet Entities
PunkNet has a handful of native entities to it, each with their own role.
PunkNet is layered but is not tree-hierarchical for good design reasons that not discussed here, but basically - a tree-hierarchy makes the business of establishing "corners" (refer to the metaphor of Tubes and Hoses at the start) too risky and inefficient - a limited hierarchical system is enough to establish "corners" but does not allow infinite nesting of targets or keys: this is a good thing.
The entities are:
Substrate
This is the Physical Link-Layer. This allows physical communication between Nodes.
The Substrate is theoretically important, since the anonymity of the network wants it as good as the Substrate can guarantee. If the Substrate has a structure that makes it impossible to use without full authentication, it will not add any security benefit to the layers above it, and the overall system security will become dependant on their protocols' inbuilt security mechanisms alone.
This layer ideally would be able to guarantee:
No reliable way to prove at this level whether a particular Node was actually the originator of a message or just a messenger that relayed it
Messages at this level will not propagate forever and will "fade out" before they travel too far
The next entities described sit on top of the Substrate, and are more or less listed in their upward order through the PunkNet layers:
Neighbour
A given assumption is that a given Node can at any given time only see a portion of the PunkNet node population. (In fact in the Radio Substrate-model, it can only ever see a tiny portion of the physically available nodes, and thus adds a security benefit that is passed on to the upper layers).
Any Nodes that a Node can see and communicate with are called its Neighbours.
A Node ideally cannot tell where a Neighbour physically is.
Neighbours form the short(est)-range system that the JBOX system sits upon.
JBOX (and Carriers)
JBOX is short for Junction Box.
These are nodes that are presumed to be several Neighbor-by-Neighbor Hops away from a given Node. There is no way to actually prove how many Hops a JBOX is away from you, but by the same token the JBOX cannot prove how many Hops you are away from it, because of the way the protocols work, and even one Hop means that both of you could be in wildly different physical locations.
JBOXes actively broadcast paths out into the network, such that any Nodes that receive the broadcast can, if they wish, connect back along the path to the JBOX.
This is how PunkNet breaks the problem of "if you don't know anybody, how do you address them ?".
In PunkNet, the addressing system pushes instead of pulls.
A JBOX is also just a Node, and hears other JBOX path broadcasts just like any other Node.
the JBOXes Thus ihteroacen themselves to form a loose higher-level mesh of Neighbour-like Nodes.
Any Node can become a JBOX by performing and honouring the necessary broadcast.
A Node cannot tell where a JBOX physically is.
The path from a given Node to a JBOX is referred to as a Tag Chain, and a duplex communication pipe that uses one or more Tag Chains is referred to as a Carrier.
There is a mechanism by which Carriers can optimise themselves.
JBOXes, and the Carriers to and from them, form the medium-range system that the Channel system sits upon.
JBOXes and Carriers form the primary first-line-of-defense anonymity mechanism in PunkNet.
Channel
These are like TCP-pipes and form reliable (though not necessarily causal) duplex connection pipes that can travel transparently via any number of JBOXes. via those JBOXes' Carriers.
Channels form the main currency of PunkNet.
There is no point discussing them in detail here as they require an understanding of the Neighbour and JBOX protocols first.
Channels form the long-range system that allows universal communication in PunkNet, and also are the means by which the PPOP system is set up and used.
PPOP
This is short for PunkNet Point Of Presence. These are like little (but very secure) firewalls.
A Site Node connects to a remote JBOX and asks it to establish a PPOP. A secure Channel then exists from the PPOP on the JBOX back to the Site Node.
A Client Node can then connect a Channel - via several JBOXes if it wishes - to the "other side" of the PPOP on the JBOX, and get a pipe connection all the way to the Site Node.
Neither end Node can tell physically where any of the intervening JBOXes are, where the PPOP is, or where the other end Node is.
PPOPs together with the identity of the JBOX - ie. JBOX:PPOP - form the closest thing we have to a first "address" component, and can be published using OverPunk (see sections on OverPunk).
PPOPs are like the sockets in a plugboard, with the JBOX being the panel.
A Punknet address may actually consist of several different JBOX:PPOP pairs in a list, and may be published along with some other infromation for accessing the Site that hides behind the address.
The intention is that PPOPs come with different security caveats that control how they must be used by a client wishing to connect a Channel to them - for example, one PPOP could be clearly visible on the host JBOX, so that a search of the JBOX's PPOPs will show it up, but another PPOP could be private, so that the JBOX will not admit that it has it unless you connect to the PPOP explicitly, and then the PPOP could demand a password - or other restrictions - before it will allow your Channel to connect.
PPOPs are the "hook" system that allow a concept of Addresses to exist in PunkNet.
PA
This is short for PunkNet Address.
A PunkNet Address, a PA, is primarily a list of JBOXes (even just one will do), each with a PPOP number.
The reason why a PA can contain a list of JBOX:PPOP pairs is discussed in the sections concerning Divided Pipe.
However, we extend the concept of the PunkNet Address to also mean a record that unifies that information with other real-world information, such as the name of a Site.
The PA, PunkNet Address, system allows a concept of Address Publication, or "permanent" Addresses, to exist in PunkNet.
This is discussed more in the sections concerning OverPunk.
OverPunk
OverPunk is strictly speaking not a part of the PunkNet protocol.
The true PunkNet protocol is sometimes humorously referred to as "Punk", and, since the OverPunk components give overview information, choosing the name "OverPunk" was irresistible.
OverPunk lives on JBOXes that have choosen (at random) to become "OverPunk Nodes".
OverPunk provides several discrete types of things:
Overview data that is useful to outside clients of the system, and crucial for interfacing to other systems such as HTTP, but does not strictly form a part of the core Punk protocol.
Low-level overview data, eg. concerning JBOXes, that helps Clients form long-distance connections more quickly
OverPunk is something Punk can live without, but we'd rather it kept it.
It is beneficial to become an OverPunk node, because of the superior network connectivity you receive, however it does consume resources of cpu and bandwidth.
PunkNet - Link-Layer Substrate Models
Here are two different models for a Substrate for PunkNet to physically work across.
The Radio model concerns physical transmission via digital wireless.
The IP model concerns physical transmission via the internet using UDP.
There are two different IP UDP models:
Noise Network
Direct
See also Appendix B : IP Model - UDP Direct, for an explanation of how IP can be used safely under PunkNet even with full IP exposure.
Radio Model "Broadcast Boxes"
The re-transmitter nodes in this model are physical boxes that have a radio tranceiver.
They can transmit and receive broadcasts over a limited physical radius, they do not use Line Of Sight.
Sufficient Physical-Layer protocol must exist so that a box knows when it has fully received a transmitted message, ie. CRC's etc.
It is even feasible to have a duplex connection box-to-box at this level to ensure message reception, without compromising the security of the system.
How ?
Because the boxes broadcast, meaning that they never physically know where the box that they are communicating actually is, and, having completed the communication, the information used at this layer to guarantee data integrity can of course be changed and then becomes immediately useless again to a snooper.
Description
In the Radio model the simple trick is this:
If a box short-range broadcasts (eg. in a radius of 300 metres or less) a Public Key into the ether, only a handful of other boxes will hear it.
If those boxes then each encrypt their own Public Key using the one that the broadcaster just gave them, and then broadcast the resulting reply-message themselves, the only node that can decode the reply broadcasts will be the original box. (Naturally retry back-offs and/or other mechanisms are required to prevent collisions).
The original broadcasting box now knows a Public Key for each of its Neighbours, and can establish secure communication channels with each of them as individuals, even though the only means of physical transmission available to it remains to be broadcasting in a radius.
That's it! The rest is down to whatever is available in the real world!
IP Model UDP "Noise"-Network
Note: As you will probably notice, with a view to implementing PunkNet as soon as possible, at writing the author has devoted a lot more thought to this IP Model than to the Radio Model above.
The re-transmitter nodes in this model are internet hosts, each running a daemon that listens for UDP messages on a given interface and port number.
The daemon can transmit and receive UDP messages to others of these daemons that it discovers.
Because of the nature of UDP, a daemon cannot reliably tell where (what IP number and port) a received UDP message has come from, and assumes that the From address is bogus.
Note: on the real internet, routers are often configured to drop UDP messages that have "silly" From addresses. This means that the From address has to be "reasonable" - eg. the address of another host on the same ethernet run. However, this model does not suffer unduly if the From address is compromised, as tracing the hops back through the network is pretty much impossible anyway as you will see.
UDP is not reliable, although there are some excellent "Reliable UDP" models out there. PunkNet will cope with messages being lost and has a re-transmission scheme, but whatever protocol that sits on top of PunkNet should ideally have a re-transmission scheme of its own.
A further daemon is required to publish public lists of interfaces and ports.
Description
Call this protocol UDPunk just to give it a name.
Each node has an IP address and port number on which it accepts UDPunk messages.
UDPunk messages have a hop-count number that decrements with each hop. This does not compromise the safety of the system as it can be shown that a node falsifying the hop-count value has very little effect on the overall network.
See Appendix A : Ineffectiveness of Malicious attacks on Hop-counts
Each node openly publishes its address and port, on public servers - most likely on HTML servers. This is right and proper - the safety in this system is that there are so many nodes in operation that snooping all of them would be impossible, and inter-communication paths are so tangled that snooping would reveal next to no useful data anyway.
A node, upon waking:
(1) publishes its own address and port, and then
(2) goes to the public lists and randomly picks (but possibly only amongst the newest entries), say, eight other nodes. These are referred to for convenience as its "children".
The node creates "ping" messages for each of its children and then sends to them.
The UDP From address is faked and the receiving nodes will not rely on it anyway.
The just-woken node waits to see if any of those "ping" messages come back to it.
Why would they come back ?
Because:
The default action of any node, upon receiving a message, is to decrement the hop-count and forward the message to all of its children.
The message thus propagates forward, and there is a finite chance that it will just randomly fall into a path that takes it back to its originator node - that is, there is a finite chance that some other node will select this node from the public lists and make it a child.
If a "ping" message does come back to the node, the node makes note of this and of what child it sent out that "ping" message to, (and naturally does not forward the message).
This means that a loop then exists, from the node back to itself, out on the network.
If the hop-count in a message is already too low, a node will not forward the message any further. This sets a boundary of propagation and every node is programmed the same way.
The node also keeps a cache of the messages that it has forwarded in the recent past and if it sees a packet go past again, with a lower hop-count (meaning it is more travelled now), it will not forward the message any further.
If it has exactly the same hop-count, it will assume that it is a re-transmission attempt and forward it as usual, but it will only do this a certain number of times per time-period, eg. 3 per 30 seconds then it will wait 5 minutes before allowing this message to go through again. This prevents loops that just happen to have the same hop-length from surviving.
If it has a higher hop-count (meaning it has come from closer to the originator), the node treats the message as though it had the same hop-count, exactly as detailed above, but updates its internal record of the hop-count for this message.
Any messages that the node does not recognise from its cache, and that are not its own "ping" messages, the node will escalate to a higher-level protocol for actioning. If the higher-level protocol cannot do anything useful with the message, it will give the message back to the link-layer who will then cache and forward the message as usual.
If after several tries, a given "ping" message does not come back, the node drops the child that it was sending that message too and picks another one from the public lists to replace it.
The node keeps "pinging" itself in this way, adjusting its children, until it has a set of children that will return its messages to it. It continues to monitor this behaviour to make sure paths are still open.
All UDPunk messages have a hop-count, whether they are pings or data, and are identical in form even though they have individual content. Thus it is impossible for a snooper to tell ping messages from data messages.
Note that a node could use the data transmissions travelling via it as pings, after a while, instead of making up its own ping messages.
Every so often the node will drop a child anyway and go and find another one, to confuse potential snoopers.
The node pings any new children heavily, but after a period it drops its ping frequency for a given child back to a low noise-level.
If a node finds itself being deluged with messages it will shut down for a while, causing any nodes using it to route around it.
Other criteria for judging "fit" children are:
If ping messages come back from a given child - there will likely be more than one reply to a ping as the message scatters into the network - and some of them have too high a hop-count, the child is rejected: there are not enough hops between the node and at least one of the other nodes in the loop - eg. the child is sending straight back. Security is not guaranteed via that child.
If ping messages overall have too low a hop-count: this means that all the loops from this child are too long and therefore efficient transmission via this child will not work.
This Substrate model thus links the nodes together into short "loops", and it is up to a higher-level protocol to use this system to effect longer-range transmission.
Idea:
A node re-broadcasts received stuff to all its active children. It could have non-active children, which have been pinged but which do not get forwarded to yet, which it keeps ready to make into active children.
A node monitors how much traffic it is handling. If it is still within capacity, it can add more active children. If it is over capacity it can start dropping active children.
The principle: You want to keep re-broadcast scatter down to a minimum, but you still want the maximum connectivity. If a node isnt receiving much data, its probably because nobody has linked to it. In that case it should beget more children, because then it will end up with more loops back to itself - that is, it increases the likelihood of loops back to itself forming. If a node is receiving too much data, it should try and cut some of the loops back to itself, and the easiest way is to drop children.
IP Model UDP Direct
See Appendix B: IP Model - UDP Direct
Higher Layer to Substrate Layer Optimisation
A higher-level protocol, such as Punk, can interface to whichever model is at this Substrate level and optimise connections that suit its own purposes, rather like using ARP and RARP in IP.
Eg. in the IP Model, higher-level messages going out into the world are initially just broadcast to all the children, but through level-crossing this can be optimised down to just the children that connect to, say, in Punk's case a particular Neighbour.
This optimisation only works for the originator node of a higher-level message, of course. It allows that node to limit which initial vector/s its broadcasts go out along.
PunkNet - Anatomy of a PunkNet Message
PunkNet messages are divided into two Sections: imaginatively called Section 1 and Section 2.
Section 1 occurs in the message before Section 2, ie.they are stored in the message one after the other.
Section 1 is for Neighbour-to-Neighbour hop transactions, and for JBOX transactions.
Section 2 is the payload section, and relates to Channels and PPOPs.
This division into two sections is to prevent excessive encryption and de-encryption of the message as it travels along from node to node.
Here is an example of how a message is written down in this document:
Section 1:
Neighbour Key {
Sender's Neighbour ID
JBOX Announce Header
From: Tag
Hop-count
}
Section 2:
JBOX ID
JBOX Public Key
JBOX Signature/s (eg. of previous Public Keys it announced)
Message transactions in this document are written using indents, thus:
Transmitted Message
Reply Message
PunkNet - Neighbours
This describes the lowest-level (above the Substrate Physical Link-Layer) behaviour of PunkNet, Node to Node.
Neighbour-oriented protocol messages travel 1 hop only at the PunkNet layer (though they may possibly travel several hops in the Substrate layer of course). They travel to a Neighbour, and the Neighbour can reply, but they are not relayed further in any way.
All of the Neighbour-oriented instructions occur in Section 1 of the message, but the data (eg. keys etc) that is travelling in the payload along with the instruction is stored in Section 2.
Thus:
Section 1:
... where a Neighbour sees request and response instructions ...
Section 2:
... payload travelling with those instructions ...
Neighbour Hello
This is not encrypted. It conveys a signed Public Key to all Nodes who can hear it.
It will look something like:
Section 1:
Neighbour Hello header
Section 2:
Sender's Public Key
Sender's Signature
Neighbour Welcome
This is encrypted. It conveys a Public Key, a Secret Key, and some network-speedup info back in response to whichever Node just sent out a Neighbour Hello.
It will look something like:
Section 1:
Helloer's Public Key {
Neighbour Welcome header
}
Section 2:
Helloer's Public Key {
Welcomer's Public Key
Welcomer's Secret Key (quicker than Public Key cryptography)
Quick ID string list: [ list of consumable Section 1 headers, of arbitrary bit-length, for quick recognition ]
I know you as: Neighbour ID for Helloer
Know me as: Neighbour ID for Welcomer
Welcomer's Signature
}
Neighbour Confirm
This is just to convince your Neighbours that you are worth bothering about.
It is sent back in response to whichever Node just sent back a Neighbour Welcome.
It will look something like:
Section 1:
Quick ID (identifies Welcomer's Secret Key)
Welcomer's Secret Key {
Neighbour Confirm header
Neighbour ID (of original Hello'er)
}
Section 2:
(empty, or deliberately garbage)
At this point the Nodes have agreed on Neighbour IDs, which are "pet names", for each other.
The Neighbour IDs that a given node knows its Neighbours by mean nothing to anyone else except that node.
They only make sense in the context of direct communication with the node's Neighbour nodes.
The Nodes also have Quick ID's for each other - any message that has a Section 1 that begins with one of these strings is quickly recogniseable and the appropriate responses are quick to determine.
The default cascaded actions of a Node are to:
Look for an unencrypted Neighbour Hello in Section 1, failing that-
Look for a Quick ID leading Section 1, upon which try to apply the matching Secret Key to try and decode Section 1, failing that-
Begin applying all the Private Keys it knows that apply to itself, to try and decode Section 1, in which it only expects to find a Neighbour Keys Update message, failing that-
Drop the message
Neighbour Keys Update
This is how Neighbours keep up to date with their keys and help to foil snoopers, archivers and other attackers.
This will look something like:
Section 1:
Recipient's Public Key {
Neighbour Keys Update header
Neighbour ID
}
Section 2:
Recipient's Public Key {
Sender's (current) Public Key
Sender's (current) Secret Key (quicker than Public Key cryptography)
Quick ID string list: [ list of consumable Section 1 headers, of arbitrary bit-length, for quick recognition ]
Sender's (previous) Public Key
Sender's Signature (based on previous Public Key)
}
Neighbour Keys Acknowledged
This is the reply to the Neighbour Key Update, it is almost the same message:
Section 1:
Quick ID
Recipient's (current) Secret Key {
Neighbour Keys Acknowledged header
Neighbour ID
}
Section 2:
Recipient's (current) Secret Key {
Sender's (current) Public Key
Sender's (current) Secret Key (quicker than Public Key cryptography)
Quick ID string list: [ list of consumable Section 1 headers, of arbitrary bit-length, for quick recognition ]
Sender's (previous) Public Key
Sender's Signature (based on previous Public Key)
}
Neighbour Message ACK
This is a suggested way how one form of reliable transmission could be done in PunkNet, via a simple re-try mechanism at the Neighbour level.
This message is sent from a Neighbour that successfully receives a particular message type.
The only message types this applies to are JBOX Announce (JA) and Node-Node Data (NND), which are covered in the sections on Tags and Carriers.
It is sent back to the Neighbour who sent the original message.
It looks something like:
Section 1:
Quick ID
Neighbour's Secret Key {
Neighbour Message ACK header
Neighbour ID
SHA digest of Section 2 of original message
Neighbour SHA Signature (based on current Public Key) of the above 3 sub-sections)
}
Section 2:
(empty, or deliberate garbage)
Neighbour Gimme JBOXes
This is how a Node finds out about JBOXes (including OverPunk ones).
This will look something like:
Section 1:
Quick ID
Recipient's Secret Key {
Neighbour Gimme JBOXes header
Neighbour ID
}
Section 2:
Recipient's Secret Key {
Wildcard/OverPunk information
Sender's Signature (based on current Public Key) of relevant message sub-sections
}
Neighbour Listof JBOXes
This will look something like:
Section 1:
Quick ID
Recipient's Secret Key {
Neighbour Listof JBOXes header
Neighbour ID
}
Section 2:
Recipient's Secret Key {
List of JBOX ID's, Public Keys and any OverPunk information thereabout
Sender's Signature (based on current Public Key) of relevant message sub-sections
}
Neighbour Extend JBOX Request
Neighbour Extend JBOX Accept
This is how a new Node gains the ability to talk to a JBOX at all.
There is no point discussing this here as it requires an understanding of the JBOX Announce mechanism, discussed elsewhere.
Neighbour HeartLub
Neighbour HeartDup
This is how a Node checks that a given Neighbour is "still there".
(Note: the two distinct sounds of a human heartbeat are medically referred to in English as "Lub" and "Dup").
Section 1:
Quick ID
Neighbour's Secret Key {
Neighbour HeartLub/HeartDup header
Neighbour ID
Neighbour Signature (based on current Public Key) of the above 2 sub-sections)
}
Section 2:
(empty, or deliberate garbage)
Also there are some Neighbour-to-Substrate layer crossover messages:
In the Radio model:
Tranceiver Hunting Outbound
Tranceiver Hunting Return
This allows frequencies etc to be agreed on between radio model Neighbours.
In the UDP model:
IP Hunting Outbound
IP Hunting Return
This allows Neighbours to be associated with particular children in the IP model.
These message types are used to securely optimise communications between Neighbours.
(They can also potentially provide re-try clues to the Substrate layer).
We do not cover the use of these message types here.
The basic actions of a Node joining the network anew are:
Find out who your Neighbours are and agree on all Keys and IDs with them, then-
Find out a list of what JBOXes they know of and set things up with your Neighbours so that you are able to communicate with a given JBOX from that list
Further joining actions are:
Find out a list of JBOXes your Neighbours know of that are OverPunk servers
Actions that are constantly repeated after joining are:
Heartbeat your Neighbours to make sure they are still there
Agree on new keys with your Neighbours
Optimise Substrate-layer communication with your Neighbours
Later on, actions that actually perform communication functions are:
Handle JBOX Announce messages from your Neighbours
Handle Node-Node Data messages from your Neighbours
ACK any messages of the above types that you get from your Neighbours
Any other Node actions reach outside the scope of just Neighbour-Neighbour transactions and are discussed in other sections of this document.
Note: we don't bother writing the Quick ID / Secret Key in all message descriptions from now on, rather we just write "Neighbour Key", for clarity.
PunkNet - JBOXes, Tags and Carriers
This section describes how JBOXes get set up, how they get connected to by Nodes, and how they establish Carriers to act as pipes between them and their peers.
All of this involves the use of Tags.
1. A JBOX tells PunkNet about itself
You are a Node.
You decide to become a JBOX
You therefore need to send out a JBOX Announce message.
You send the JBOX Announce to each of your Neighbours, but you personalise it for each individual Neighbour.
You give each Neighbour a different From: Tag.
(A Tag is just a randomly chosen number, it is not cryptographic in nature.)
The message you send to a Neighbour looks something like:
Section 1:
Neighbour Key {
Sender's (in this case Your) Neighbour ID
JBOX Announce Header
From: Tag
Hop-count
}
Section 2: (not encrypted)
JBOX ID
JBOX Public Key
JBOX Signature/s (eg. of previous Public Keys it announced)
Receiver Actions (first time this JBOX Announce received):
These following actions ensure that the JBOX Announce propagates as a broadcast, propagates only outward, and propagates finitely.
You are a Node that has just received a JBOX Announce that you will discover you have never seen before.
Decrypt Section 1
Verify that Sender's Neighbour ID is known and authenticated
Interpret Header
Go to JBOX Announce handling mode
Record the details in Section 2 as the identity of this JBOX
Associate the From: Tag with the identity of this JBOX
Now,
We use tables with records thus:
Table 1 record -
Tag [tag]
Tag to translate it to [tag]
and the inverse of this but we just assume that
Table 2 record -
Tag [tag]
Neighbour associated with this Tag
You create an entry in Table 2 thus:
Tag [Tag you received in the From: field]
Neighbour associated with this Tag (in this case the Neighbour who sent it to you)
Decrement the Hop-count
If the Hop-count is now too low, stop here, otherwise continue
For each of the Neighbours you have not received the JBOX Announce from:
You invent a new Tag just for this Neighbour, and then you add entries
in the Tables thus:
Table 1
Tag [tag] (you invent this Tag, now)
Tag to translate it to [Tag you received in the From: field]
and the inverse of this but we just assume that
Table 2
Tag [Tag you just invented]
Neighbour associated with this Tag (in this case the Neighbour who you are about to send to)
Create a new Section 1, using:
Neighbour Key {
Sender's (in this case Your) Neighbour ID
JBOX Announce Header
The new invented Tag
The new Hop-count
}
Copy Section 2 as-is, unchanged:
Section 2: (not encrypted)
JBOX ID
JBOX Public Key
JBOX Signature/s (eg. of previous Public Keys it announced)
You now have a new JBOX Announce for this Neighbour, so send it!
(Note: you should possibly re-check just before you send it out, in case a Neighbour has sent you the JBOX Announce whilst you have been processing it from a different Neighbour, and not send to the new one, but this is not crucial as if you send by mistake the Neighbour will cope anyway, see next section).
Receiver Actions (n'th time this JBOX Announce received):
These actions ensure that the JBOX Announce can be re-broadcast by the originator, to re-inforce it, without problems resulting out on PunkNet, and ensure that all Nodes in the path of the JBOX Announce record all details of what they know of where it came from.
Decrypt Section 1
Verify that Sender is a known and authenticated Neighbour
Interpret Header
Go to JBOX Announce handling mode
Notice that the JBOX ID is one we already have recorded, look up its details.
If the Sender is the Neighbour who is associated with the From: Tag and JBOX ID field that this JBOX Announce has, then this is the same JBOX broadcasting the same way (the Public Key may have changed! This is how JBOX's can publish new keys for themselves). In this case, after verifying the signatures in the JBOX Announce, do the following:
Do exactly the same re-broadcast again (same Tags and Neighbours, same everything)
else, If the Sender is not the Neighbour who is associated with the From: Tag and JBOX ID field that this JBOX Announce has:
Record its details
Do not further broadcast
Note: this situation could drift - for example, if you initially get the JBOX Announce from one Neighbour, but after a while you find you have been getting lots of re-broadcasts from a different Neighbour, that new Neighbour could take over.
This should be a cache-managed arrangement.
2. A Node connects to a JBOX
You are a Node in the way of a JBOX Announce broadcast.
You have honoured the broadcast, and you know which Neighbours sent you which tags, and which Neighbours you sent which tags.
You decide you want to talk to the JBOX.
But note! You only have the tags for one direction, that is the direction the JBOX is in.
This is Ok - because this is the direction You want to send in to talk to the JBOX - but you also want the JBOX to be able to reply specifically and reliably to You.
We thus now move to the most common message type, the Node-Node Data, or NND, message.
Don't worry about what you actually say to the JBOX yet, we will cover that.
For now just think about how the first message gets from You to the JBOX and how replies get back again.
To the Neighbour that is associated with the JBOX you want to talk to, you send:
Section 1:
Neighbour Key {
Sender's (in this case Your) Neighbour ID
NND Header
To: Tag (in this case the Tag associated with the JBOX you want to talk to)
From: Tag (you invent this, individual for each Neighbour you send it to, and store the fact that it points to You)
}
Section 2:
JBOX Public Key {
Carrier ID
Data Header
Data
}
Receiver Actions:
Decrypt Section 1
Verify that Sender is a known and authenticated Neighbour
Interpret Header
Go to NND handling mode
Look at the Tags that came with the message:
If its a To:Tag , you look up the [tag] to translate it to, in Table 1, then you use that Tag to find out, from Table 2, which Neighbour to send it to.
You only send to one Neighbour.
If you have never seen the To:Tag before, you abort the transaction on the spot.
If its a From:Tag , and you have seen it before, you use this tag to find out, from Table 2, which Neighbour should have sent it to you, verify that this is so (on failure abort the transaction on the spot), and then you look up the [tag], in Table 1, to translate it to.
If you have seen the To:Tag, but you have never seen the From:Tag before, you add entries for the Tag found in the From: field, thus:
Tag [tag] (the From:Tag)
Tag to translate it to [tag] (you invent this Tag)
and the inverse of this but we just assume that
Tag [tag] (the From:Tag)
Neighbour associated with this Tag (in this case the Neighbour who sent it to you)
Then you just proceed as if you had always known the From:Tag in the first place.
(Note: this all implies that a JBOX could actually build a tag-chain back to the Client; this is actually fine and acceptable and generally a good thing!)
Select the Neighbour to send to using the translated To:Tag and Table 2, as described above.
Create a new Section 1, using the above information:
Section 1:
Neighbour Key {
Sender's (in this case Your) Neighbour ID
NND Header
To: translated Tag (obtained from Table 1)
From: translated Tag (entered in (or obtained from) Table 1)
}
Copy Section 2 as-is, unchanged:
Section 2:
JBOX Public Key {
Carrier ID
Data Header
Data
}
Then you send the message to the Neighbour you selected.
3. Carrier Establishment
Eventually the NND message will arrive at the Node that is the actual JBOX that sent out the original JBOX Announce.
The JBOX decrypts and processes Section 1 as already described.
The JBOX will receive an NND message with a To:Tag that contains a Tag that the Node knows is meant for the Node itself (the Node invented it when it originally first sent out the JBOX Announce to its Neighbours).
The JBOX stores the whole context of the NND message so that it cannot be lost. The NND message has just brought the end of the 'Tag-chain' in contact with this JBOX.
The JBOX knows by context that it should be able to decrypt the payload in Section 2 of the NND message, using the Private Key of its current Public Key (or of one of its most recent Public Keys).
The JBOX decrypts Section 2 (on failure, it aborts here).
Section 2:
JBOX Public Key {
Carrier ID
Data Header
Data
}
You are the JBOX.
You lookup the Carrier ID to see if you know it already.
If you do know the Carrier ID already, you update its details with the context of the NND message (ie. the Tag and Neighbour to send messages on this Carrier to).
If you don't know the Carrier ID, you add its details with the context of the NND message.
Thus: a Carrier ID is independant of the Tag-chain it arrives on, and the Tag-chain is free to change.
The Data Header and Data will, in the first message, provide:
A Public Key to talk back to the Client on
A Request for a Carrier Connect
Assuming that You accept the Carrier Connect (if not you just abort here) you formulate a reply and send it back out the way it came, along the tag-chain, with the same Carrier ID.
The Client will react in a similar manner and catch the reply.
(We ignore any Acknowledgement messages here for clarity).
4. Types of Carrier message
Carrier Connect
Carrier Accept
This message exchanges the Client and JBOXes' Public Keys.
Carrier HeartLub
Carrier HeartDup
There is no Carrier Disconnect, as failure to maintain the Heartbeat is enough to cause the Carrier to be forgotten, and a prolonged lack of traffic will cause the intermediate Nodes to forget the tag-chain.
Carrier Channel Connect
Carrier Channel Accept
Channels are the next level of communication above Carriers.
Carriers are used to create them, but then the Channels themselves do the deeper operations.
Once a Channel is Accepted, it talks directly to the JBOX and the JBOX expects it to say Channel-related things.
Carrier Channel Move
Carrier Channel Move Accept
Carriers are constantly being created to a given JBOX by the Client, as this is PunkNet and the Client does not expect any given data path to necessarily survive for any length of time.
Just as Carriers can be moved to different tag-chains, Channels can be moved between different Carriers.
Carrier Channel Delete
Carrier Channel Delete Accept
This is a courtesy to the JBOX. If the JBOX experiences a prolonged lack of traffic on the Channel it will forget it anyway.
After-Note:
It may be possible to get away with not encrypting the Section 1's of NND messages, since the Tags are only meaningful to the Neighbours who use them - thus a snooper gains very little by seeing them.
This possibly applies to the messages involved in the establishment of a Carrier, too, though at writing I feel that they at least should have encrypted Section 1's for peace of mind.
5. Intermediate Node Carrier AutoOptimisation
Nodes on a Tag-chain, between a Node and a JBOX, can notice heavy traffic on a particular Tag-chain and lookup the JBOX that the Tag-chain is associated with.
They can then, via their Neighbours, build their own Carrier to the JBOX, and then hand over an already existing Tag-chain's Carrier traffic to the new Carrier's Tag-chain.
They can do this hand-over whenever they find a faster Carrier to the JBOX.
The nodes on this Tag-chain cannot read the Section 2's of the messages from then on, but the Carrier ID inside NND messages takes care of everything, so that the JBOX just copes with the jump in Carrier on this Tag-chain.
The old Tag-chain just fades out.
PunkNet - Channels and PPOPs
The Client can be a JBOX itself, and in fact often will be.
Channels are created via Carriers.
Once a Channel has been created, it talks directly to the JBOX at the other end, ie. it is "plugged into" that JBOX.
This is conveyed via a Node-Node Data, or NND, message, something like the following:
Section 1:
Neighbour Key {
Sender's Neighbour ID
NND Header
To: Tag
From: Tag
}
Section 2:
JBOX Public Key {
Carrier ID
Channel Data Header + Channel ID
Data
}
The Channel Data Header, Channel ID and Data contain the information we want.
The Data will contain a Channel message
1. Types of Channel message
Channel Encryption Request
Channel Encryption Accept
This uses the JBOX's Public Key to transmit the Client's Public Key to the JBOX.
This mechanism can also be used to allow the Client and the end Node to establish Secret Keys, which are quicker to use than Public Keys.
After this exchange, all further communications will be encrypted; unless the Channel requests a Relay - on a successful Relay the encryption is dropped again. There are good reasons for this that will be explained.
This command can be used even if encryption is already in place, in which case it is used to update the keys used by each end.
This command can be used by a Client to set up encryption with a Site. However, the Site's Public Key should be verified using OverPunk.
All the following commands can be encrypted or non-encrypted, the JBOX knows by context what state the Channel is in:
The encryption applies to the data underneath the Channel ID, thus:
Section 2:
JBOX Key {
Carrier ID
Channel Data Header + Channel ID
Data: Site/Client's Key { - note this Data section is relayed unaltered by a JBOX or PPOP
Final Data - eg. Channel Relay command, etc.
}
}
The Keys are underlined to draw attention to the 2 levels of encryption here.
The JBOX Key gets used at every JBOX involved in relaying a Channel, whereas the Site/Client's Key only gets used at the Site and Client.
Note for below: PPOPs add one more layer of encryption to this scheme, with Keys used only at the PPOP and at the Site.
Channel HeartLub
Channel HeartDup
This just allows a Client or Site to check that a given Channel is still operating.
It can also be used on Control Channels from Sites that connect to the back of a PPOP, and will also work end-to-end from a Client Channel to its eventual Site Channel.
Channel Gimme JBOXes
Channel Listof JBOXes
This is how the Client asks the JBOX for a list of other JBOXes (any JBOXes that JBOX knows about from past JBOX Announce broadcasts).
The JBOX replies with a list of the most recent ones, and their Public Keys and Signatures.
(The 'Gimme' should be able to have both default and specific criteria, for example if the Client is only interested in whether the JBOX knows about one other particular JBOX then the Client won't want to receive a big list).
Note:
For any given JBOX, the Client should compare the query-answers from several JBOXes to make sure it sees the same Public Key listed everywhere, as a security measure.
Channel Relay JBOX Request
Channel Relay JBOX Accept
This is one of the most important operations in PunkNet.
You are the Client Node.
You have a Carrier to a JBOX, and you have set up one Channel over that Carrier, and that Channel is now 'plugged into' that JBOX.
You say to the JBOX that the Channel is currently 'plugged into', lets call it JBOX 1, that you want the JBOX to:
1. Relay the Channel to another JBOX (that this JBOX has told you it knows of using the Gimme JBOXes exchange of messages), lets call it JBOX 2, and
2. Make things such that the Channel is now 'plugged into' JBOX 2 instead of JBOX1, whilst being of course still physically relayed via JBOX 1
This requires that JBOX 1 have a Carrier in turn to JBOX 2, just as the Client has a Carrier to JBOX 1.
If JBOX 1 does not have a Carrier to JBOX 2, it builds one, there and then (or it can refuse if it is eg. overworked, and just abort your request).
JBOX 1 then builds a new Channel to JBOX 2, across the Carrier to JBOX 2 that it just re-used or created.
If the new Channel to JBOX 2 takes hold, JBOX 1 updates its records that anything from Channel X on Carrier 1 is now to be relayed straight to Channel Y on Carrier 2, and vice-versa.
This is accomplished by a Relay Table entry:
[Channel ID on one side] [Channel ID on the other side]
JBOX 1 then sends a Channel Relay JBOX Accept back to You, the Client.
If you have encryption running up to that point, on the Channel, the encryption is killed, so that you are talking plaintext again. Thus you are now talking plaintext, on this Channel, to JBOX2.
Yes, this means that JBOX 1 can read the data going past! - this is not a big problem, as will be explained below.
You can now send a Channel Encryption Request to JBOX 2 to set up encryption on this Channel, and from that moment on JBOX 1 will not have a clue what you are saying to JBOX 2.
You do this using a Public Key for JBOX 2, that you found out when you found out about JBOX 2. This information could have come from Neighbours, other JBOXes, or OverPunk.
Remember: as stated above, the Client should then compare the JBOX query answers from several sources to make sure it sees the same Public Key listed everywhere, as a security strategy. That way it knows it is talking on the correct Public Key to the remote JBOX.
Once you, the Client, and the remote JBOX, in this example JBOX 2, have exchanged Public Keys (ones that you are as sure as you can be that they are safe), you have secure communications between you that not even relaying JBOXes between the two of you can read.
Any further Relay requests to JBOX 2 (to ask it to relay again in turn) will be known only to You and to JBOX 2, and - since there is quite deliberately no mechanism for querying a JBOX on what Channels it is currently Relaying and where to - JBOX 1 will never know who JBOX 2 is now relaying this Channel on to in turn.
The Channel does not care about the Carriers that are supporting it, and will never know if two JBOXes on the route have to move it across to a different Channel on a different Carrier. Similarly the Carriers are never aware of if/when they get moved across to a different Tag-chain.
Why do we drop the encryption ?
Because if we didn't, You could nest encryption infinitely.
This sounds like an advantage but its not, all it would really do is vastly increase the CPU usage across the whole of PunkNet, because of all the encryption and decryption required.
There is also no need to encrypt excessively:
Carriers are encrypted from the Client to the JBOX and back. This makes it very difficult for anybody to analyse or even track data travelling between the two Nodes.
A Relayed Channel is exposed at the relaying JBOX, because the JBOX has to decrypt Section 2 and find out the Channel ID so that it knows what Channel ID to copy the contents across to. However this has very little effect on overall security because you can always ask the endpoint JBOX to start encryption, after which the intermediate JBOX's (even if they were reading the passing data which they wouldn't have time to unless they were massive ASIO/NSA plants!) cannot tell who the Channel is ultimately talking to. Again: If you have researched the remote JBOX's Public Key well enough you are safe in doing this.
The intermediate JBOXes on a Relayed Channel never know who the Client is.
Channel PPOP Build
Channel PPOP Up
This is where the Site (which is just what we call a Client that sets up a PPOP) asks the JBOX to build it a PPOP (Punknet Point Of Presence) and connect this Channel to the back of it. (The Site can attach conditions to the PPOP too, but that is out of scope here).
This operation automatically enables encryption, if it is not already turned on, so that nobody can see the PPOP data.
The PPOP has its own Key and the Site has its own Key.
Once established, the PPOP will expect PPOP information from this Channel, but will also respond to Heartbeat messages and encryption related messages.
In the reply, the PPOP specifies a Control Channel which is reserved for PPOP-only commands from the Site to the PPOP (eg. Destroy PPOP, Destroy Channel, etc).
Channel PPOP Connect Request
Channel PPOP Connect Accept
This is where an external Client Channel asks the JBOX to connect it to the PPOP, which ultimately puts it in contact with the Site. (A good idea may be that a PPOP may ask for eg. a password in order to connect).
Once established, this Channel from now on gets multi/de-plexed onto/from the back-Channel connecting the PPOP and its Site.
After this operation, encryption is killed just as for Channel Relay requests!
This is because, philosophically, it has just committed a Channel Relay request.
A few of the Channel commands still work to the Site behind a PPOP:
Begin Encryption
Hence, the Client can now ask the Site to begin (or update) Encryption, just as before.
However - the Client should use OverPunk to gain assurance that lots of OverPunk servers agree on a particular Public Key for this Site, otherwise the Client could be talking to a relaying interceptor somewhere behind the PPOP!
This is a fundamental problem with Public key cryptography - even though you can be sure you have a valid Public Key, because of a Signature, you still have to take steps to ensure that the Public Key you have is actually owned by who you think it is owned by.
Channel Data
This is plain data bound for a Site or for a Client.
See sections on Divided Pipe and Upper Layers for what the content of these messages may be.
2. PPOPs and Sites
A PPOP is the only thing in Punknet that can multiplex several Channels onto one Channel - the Channel that it communicates with its Site on.
It can only multiplex them to a depth of 1, nesting is deliberately not provided for.
The multiplexing is done explicitly inside Section 2:
Section 2:
JBOX Key {
Carrier ID
Channel Data Header
Channel ID - a Site knows by context if this is a PPOP Channel
- a PPOP knows by context this will contain PPOP data
Data: Site/PPOP's Key {
PPOP data header
PPOP Channel ID - a PPOP knows by context if this is the Control Channel
Data : Site/Client's Key { - just to illustrate the layers of encryption
Final Data
}
}
}
At the Site Node, the PPOP handling is done separately from the Channel system, such that the incoming PPOP Channel just appears as a normal Channel that can be replied to - having passed all the appropriate authentication checks inside the PPOP handling system.
Its context is carefully kept by the PPOP handling system in the Site Node along with the PPOP information, so that you know that, say, this Channel came in from a different PPOP to another Channel, which can be important for doing Divided Pipe etc.
At the Client, the Channel is now put into connected-to-Site mode, and the Client knows that any data it pumps up this Channel in the payload will appear at the Site, and that any replies the Site makes will appear as data coming from this Channel.
The Client can request the Site to begin encryption (and vice versa could be accomplished too), after which nobody between the Client and the Site, not even the PPOP, can read the data travelling back and forth.
This means that the final leg of the journey attracts 3 layers of encryption, but this is not a big problem:
Section 2:
JBOX Key {
Carrier ID
Channel Data Header
Channel ID
Data: Site's (or PPOP's) Key {
PPOP data header
PPOP Channel ID
Data : Site's (or Client's) Key {
Final Data
}
}
}
PunkNet - Divided Pipe and Upper Layers
So, in summary about PPOPs:
A PPOP that is established expects PPOP data to arrive on its back-channel, which it knows by context must be data from the Site, as well as Encryption and Heartbeat messages from the Site.
The PPOP looks at the PPOP Channel ID in a data message and figures out which external Channel to send the data on to.
Similarly if a PPOP gets data from an external Channel that is already connected to this PPOP, it knows by context that this data must be sent on to the Site.
The PPOP figures out which PPOP Channel ID it is using to represent this external Channel and uses that to send the data on to the Site.
The Site knows that any Channels that appear from this PPOP are Clients attempting to connect to it to read or write data.
The Client knows that any Channel that successfully connects to a PPOP is now talking directly to the Site.
The question now remains: What do they say to each other ?
1. Divided Pipe
I propose that the next layer up from Channels/PPOPs be a Divided-content handling layer.
In its default mode, this layer will do nothing - it will simply pass the data up to the next layer.
In its more activated modes, the Divided-content layer will do things such as insist that you must connect to this Site via several PPOPs on different JBOX's before you will be allowed to communicate further, and that furthermore you must split your content evenly across all those connections.
The Divided-content layer handles recognition of "sessions", authentication, and content-distribution.
Once it has completely assembled a message, it passes it up to the next layer.
2. Upper Layer
I propose the next layer up from Divided Pipe be the cross-over between PunkNet and real-world applications (phew, we got there! I hear you say).
The most obvious way for this to work is to have a universal Header with the format details in it, and then the rest of the data be in the native format required.
HTTP
Just concentrating on HTTP for example, the completely reassembled message at this layer could be:
Header (States this is a PunkHTTP message)
Session Number (since several TCP/HTTP requests may travel up the same PunkNet Channel)
Data (ie. a solid block of text or compressed text)
This can be processed easily and fed straight out via TCP to a web server, the results collected in the same session, and the context used to ferry the resulting TCP data reply all the way back across PunkNet to the Client.
The Client would have to have similar encoding/decoding facilities.
Simple Messaging
A simpler version of the above could accomplish simple messaging, with a simple dedicated client, bringing PunkNet into some kind of useability without the sophistication of existing apps:
Header (States this is a PunkMessaging message)
Session Number (since several TCP Chat connections may travel up the same PunkNet Channel, rather like running several irc sessions to the same irc channel at the same time - you rarely need to do this but there may be other reasons to do it, eg. transmission of files in the background).
Data (ie. a solid block of text or compressed text)
Distributed Anonymous File Serving
Napster style.
PunkNet - OverPunk
OverPunk is a higher-level protocol to make PunkNet's interface to the rest of the world easier.
1. Publication of PA's
When your Site establishes a PPOP at a JBOX, your Site software (PunkNet software) learns the PA (PunkNet Address) you have just created.
A PA consists of:
JBOX
JBOX Public Key
PPOP ID
Any extra Site info
This can include security information (as a courtesy to connecting Clients), and
also other information such as:
the type of data at this Site, eg. HTTP
a Symbolic Name (see section on Symbolic Names)
a Description/Keyword List
a URL or other init string appropriate for this type of data
etc
OverPunk nodes can be sent this data by your software, if you wish (generally you would or nobody could connect to you, but there are still ways you can use the PA without doing so).
Several different OverPunk nodes can be sent the same data.
OverPunk nodes automatically talk to each other and compare notes. If enough of them report the same data for a given PA, they will honour that PA and begin publicly listing it.
A PA can be hidden from OverPunk completely (in which case another means has to be found of giving it to somebody, eg. convert to some standard ASCII form and then PGPmail to another person whose Punknet software then reads it and loads it).
An OverPunk-capable JBOX can be asked to be a private OverPunk server (or partially private - ie. it is still a public OverPunk server but it will reserve a private space for your purposes), requiring passwords from those wishing to inquire of it.
This allows for the setting up of private mailing lists, chat channels etc etc.
Of course you have to trust the JBOX to not allow anybody else to see your OverPunk data.
2. Publication of JBOX's
JBOXes will every so often send a list of JBOXes that they themselves know of to OverPunk.
They also send their current Public Key and a Signature.
There needs to be a facility to inquire OverPunk for this information and thereby save some time tracking down a particular JBOX you (a Client) want.
OverPunk nodes automatically talk to each other and compare notes. If enough of them report the same data for a given JBOX, they will honour that JBOX and begin publicly listing it.
3. Symbolic Names
A PA can have a Symbolic Name attached to it.
This can be anything, but if it is in one of a few standard formats, eg. a.standard.domain.name, OverPunk nodes will store the PA in a sorted list that can be looked up quickly.
4. External World Publication
OverPunk servers can be interfaced to HTTP servers, so that the data in the PA's can be published on those HTTP servers.
This allows for the possibility of URL's that can be clicked on, though this then further depends on having a Resolver and a DNS setup that can fool the Browser into connecting to an already setup (and trustworthy!) Punk/HTTP interface proxy daemon.
The idea of having a .punk domain, wherein URLs - that contained sites that ended in .punk - would magically cause the browser to be redirected to a server that would interface it across PunkNet, to a hidden web-server, is particularly attractive!
Appendix A : Ineffectiveness of Malicious attacks on Hop-counts
A hop-count in a message is started (by its originator) at a maximum possible number that all nodes know, but is made up of a random fudge-factor number added to a base number, eg. rand(0-5) + 10.
Thus if you receive a message with a high hop-count - but not the maximum hop-count possible - you have no way of proving whether the message originated at whoever just sent it to you, or whether instead they were just the last point to relay it to you.
The lowest possible hop-count is known, but is decided at a given node by a random fudge-factor also, as in when you get a hop-count you roll a dice to determine what your lowest hop-count is. Say your lowest is always chosen from between 5 and 2, inclusive, and you get a message with a hop-count of 3, there is a chance (the number 2) that you will relay it onwards and there is a chance (the numbers 3, 4, 5) you will just stop relaying here.
If you do receive a message with the maximum possible hop-count, you roll a dice to determine whether you decrement it before relaying the message or just leave it as-is - with a small but finite probability, that all nodes know, that you will just leave it as-is:
Thus, if you receive a message with the maximum possible hop-count, you have no way of proving whether it is a true number or if it was just relayed as-is to you by the last relay point.
Together with the fudged lowest hop-count this then makes very little if any difference to the propagation of a message.
It can be shown that nodes that choose to fake the hop-count maliciously when they relay messages actually do very little damage to the network.
If they fail to change the hop-count, they have almost no effect on the network.
If they increase the hop-count, effectively causing the message to propagate further, they are only going to affect a linear quantity of other nodes, they are not going to cause a combinatorial explosion. Furthermore, all nodes have other means of stopping infinite loops anyway, built into their protocols.
If they decrease the hop-count, effectively cutting short the travel of the message, again they only affect a linear quantity of other nodes, but they also self-limit the damage in doing so - the incorrect information can by its very nature only travel a short penetration distance into the network.
Since the hop-counts are also a part of "ping" processes, the originator is not going to be able to ping nodes that have had the hop-count maliciously increased across them (unless the attacker is prepared to keep honouring the hop-count changes and therefore also to manage the resulting traffic!). It will effectively never know about them, and thus never generate any traffic on them. Before long those nodes will forget all about the message.
By the same token, nodes that have had the hop-count maliciously reduced across them will simply not carry the "ping" very far. The originator will not be able to find many nodes via that path. If the originator finds a way to get further afield by a different route then of course it will, and will stop using any path that it finds it can't communicate with many nodes over.
In fact, it could actually be a useful thing if nodes were to modify the hop-count!
If they are underworked they can extend the hop-count, and continue to do so, effectively becoming conduits for remote nodes.
If they are overworked they can reduce the hop-count, limiting the traffic through themselves to just that from local nodes.
Appendix B : IP Model - UDP Direct
It is possible to connect Neighbours together in PunkNet using UDP directly, without having any Substrate mechanics other that enough to keep the UDP layer as a separate link-layer.
The Substrate encryption and obfuscation can be merged seamlessly with that of PunkNet.
This does not compromise PunkNet unduly, except only on the first Neighbour hop. Beyond the first Neighbour, PunkNet itself hides all involvement of nodes.
Description
At this layer, all nodes regard themselves as members of the Substrate.
All nodes have an IP number, Port, and Public Key - and they can manifest under more than one Public Key.
Each node broadcasts the above details onto public servers, from where they can be found by any other node.
Any node looking up a node on the public servers can compare the details found at several public servers, to try and verify that the Public Key(s) it is seeing are regarded as the same universally.
In essence, a node can contact another node via encrypted UDP:
From: bogus UDP address
To: Target's UDP address
Target's Key (found on public server) {
Hi There!
My UDP address
My Public Key
(any bonus stuff such as quick-Keys)
My Signature
}
The Target node can respond, also via encrypted UDP:
From: bogus UDP address
To: Me's UDP address (given in Hi There! message)
Me's Key {
Hi Back!
SHA Digest of Me's original Hi There! message
(any bonus stuff such as quick-Keys)
Target's Signature
}
At that point a Snooper has only seen packets go back and forth between two nodes, the Snooper knows nothing of what they said to each other.
Now!
An upper layer, which we will assume is PunkNet, can drop messages down onto this Substrate.
This means that we can substitute, in place of the above exchange, a PunkNet Neighbour exchange instead, thus:
From: bogus UDP address
To: Target's UDP address
Target's Key (from public server) {
Neighbour Hello
My Neighbour Data including UDP address and My Public Key
(any bonus stuff such as quick-Keys)
My Signature
}
The Target node can respond, also via encrypted UDP:
From: bogus UDP address
To: Me's UDP address
Me's Key (from Neighbour Hello message) {
Neighbour Welcome
(any bonus stuff such as quick-Keys)
Target's Signature
}
"Me" will know who this message is from by context.
The layer-crossing code in the Substrate and Neighbour layers can then glue a given Neighbour not only to its stated (and proven) Public Key but also to its stated (and proven) UDP address.
This may sound like madness on first inspection, however - PunkNet still protects the nodes:
As a node, you only know your Neighbours by UDP address and vice-versa, you and they know nobody else in this way.
If you have to say something privately to a Neighbour you can still use its Public Key - ie. JBOX Announces, Neighbour Keys Updates, Neighbour JBOX Extend Requests, etc, can all be protected by a layer of public key encryption for what its worth.
JBOXes are still fully protected by the fact that their initial broadcasts have to hop Neighbour by Neighbour, and nobody can tell where they originated.
The further obfuscation of paths that PunkNet employs when it uses Channels rapidly hides the physical location (UDP address) of any node involved.
Once Neighbour exchanges have occurred, NND's can pass as usual, and could even pass unencrypted without badly compromising security, as they only expose Tags not targets.
This actually sounds like the easiest version of PunkNet to get working immediately, as it uses the Internet and IP directly.
The public servers that nodes put their details up on need to be designed.
{end of document}