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:
   1. Resource discovery - if the remote public key is not known
   2. Path discovery - if the remote public key is known
2. 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
   • Type = resource discovery
   • Optional: Origin resource = initiator resource
   • Destination resource = resource to locate
   • Route = [ initiator session ID ]
   • Keys = [ initiator public key ]
2. On reception, a node checks whether it serves the requested resource
   1. If so:
      1. It creates a session for the initiator public key (if it does not already exist)
      2. It adds the traced route to the list of routes for that session
      3. It sends a Reverse path confirmation via the traced route:
         • Type = route confirmation
         • Origin resource = located resource
         • Key = located public key
         • Route = [ local session ID ]
   2. If not:
      1. It checks whether it's key is listed in the Keys field, if so, the packet is discarded
      2. If the Route field has reached 255 entries, the packet is discarded
      3. It adds the local peer ID of the sending peer to the Route, and it's local key to Keys
      4. It broadcasts the packet to all of it's peers (except the sending peer)
      5. 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