Peer2Cloud

Design decisions

 * 1) Route discovery on demand, instead of route announcements
 * 2) Explicit per packet, source specified route
 * 3) End to end NaCl encryption
 * 4) Loop detection based on NaCl public keys
 * 5) Supports many different types of addresses and protocols, including IPv4 and IPv6

Other features

 * Cheap source specified routing (just one byte per hop)
 * Optional load balancing over multiple routes (will also reduce the impact of a failing route)
 * Broken routes are not detected, and thus not used (the discovery has to travel the entire path in both directions)
 * Allows for meshes of any form to be built
 * No "broadcast" traffic resulting from route announcements
 * No more ghost routes
 * Actual network topology is mostly hidden from anybody in the network
 * Individual IP addresses are authenticated using NaCl public key cryptography

Limitations

 * Maximum of 255 hops
 * Need for broadcasts for route discovery
 * Discovery packets are rather large
 * Data broadcast packets tend to get rather large because of the key based loop detection

Protocol spec (alpha version)
P2P cloud protocol


 * After a Resource Discovery, the IP address and remote private key are cached
 * During renewals, the lookup targets the remote private key, the IP address is not queried again
 * If multiple private keys announce the same IP address, the IP address should be blocked, until administrator intervention has occured
 * Data packets may be encrypted end-to-end (recommended)
 * Resource and path discovery packets have a small encrypted data field to verify authenticy of the key
 * All packets may be encrypted between peers, but this is not required
 * Resource lookups include IPv4 addresses, IPv6 addresses, IPX addresses, and other resources for which recurring communications are useful
 * Actual data packets are routed as specified by the originator.

Routes are specified using local peer ID numbers, these consist of 1 octet per peer, and are meaningful only to a specific node
 * It's meaning is comparable to a port number on an ethernet switch
 * A local peer ID must be unique within the context of one node
 * A local peer ID should not be reused for another peer within a certain time interval
 * A local peer may have multiple local peer IDs to hide the network topology
 * A node may insert artificial peer IDs to hide the network topology, but this must be done sparingly!
 * A node may insert additional peer IDs, if it has more than 255 peers, it can simply use two octets as a 16 bit integer, and pretend to be 2 nodes
 * Route specifications for a certain path are usually different in both directions!
 * The source of a route lookup may add a one or two octet session identifier, that it associates with the remote public key

Packet type
 * 1) Resource discovery - origin resource, destination resource, trace, keys
 * 2) Route discovery - key, trace, keys
 * 3) Route confirmation - route, trace
 * 4) Route ping - route, trace, data
 * 5) Route pong - route, data
 * 6) Data - route, data
 * 7) Broadcast data - destination resource, keys

Packet contents
 * Flags / Type - Packet type code
 * Origin resource (type, value) - Resource that originated a resource discovery
 * Destination resource (type, value)- The resource to discover
 * Key - The key to discover, or the key that was discovered in a resource discovery
 * Route (length, values) - list of peer IDs (bytes), which specifies the intended route
 * Trace (length, values) - list of peer IDs (bytes), which specifies the traced route (in a trace/discovery request)
 * Keys (count, values) - list of unique keys to prevent loops (in broadcasts)
 * Data

Initializing communication with another node consists of a few steps:
 * 1) Path discovery, either:
 * 2) Resource discovery - if the remote public key is not known
 * 3) Path discovery - if the remote public key is known
 * 4) Reverse path confirmation
 * Both ends cache the discovered paths, and should regularly verify the known paths (PING).
 * Either end may at any time request a new path discovery, if it has insufficient routes, or simply to detect possibly faster/better paths.

Resource discovery
 * 1) The initiator broadcasts a 'Resource discovery' packet to all it's peers
 * 2) * Type = resource discovery
 * 3) * Optional: Origin resource = initiator resource
 * 4) * Destination resource = resource to locate
 * 5) * Route = [ initiator session ID ]
 * 6) * Keys = [ initiator public key ]
 * 7) On reception, a node checks whether it serves the requested resource
 * 8) If so:
 * 9) It creates a session for the initiator public key (if it does not already exist)
 * 10) It adds the traced route to the list of routes for that session
 * 11) It sends a Reverse path confirmation via the traced route:
 * 12) * Type = route confirmation
 * 13) * Origin resource = located resource
 * 14) * Key = located public key
 * 15) * Route = [ local session ID ]
 * 16) If not:
 * 17) It checks whether it's key is listed in the Keys field, if so, the packet is discarded
 * 18) If the Route field has reached 255 entries, the packet is discarded
 * 19) It adds the local peer ID of the sending peer to the Route, and it's local key to Keys
 * 20) It broadcasts the packet to all of it's peers (except the sending peer)
 * 21) Step 2 repeats

Path discovery
 * This is used when looking for a public key.
 * After a resource discovery, the located public key should be cached, and can be re-used in a path discovery.
 * The procedure is very similar to the Resource discovery

Alternative less promiscuous protocol
A sends to X: 	A sends discovery to peers B and C, hopcount=1 B sends discovery to C and D, hopcount = 2 C sends discovery to B and D, hopcount = 2 C ignores discovery from B (higher hopcount) B ignores discovery from C (higher hopcount) D sends discovery to X (hopcount=3) D ignores second discovery (time out) X answers D (hopcount=1, return=4) D answers B (hopcount=2, return=4), request from B arrived first with equal hopcount B answers A (hopcount=3, return=4), request from A arrived with lowest hopcount