identification (public key)
signature
packet type | signed content body
... |
The point of this common header is to establish minimum authenticity for every packet.
The packet type is included in the signature body to both protect it from being modified, and to prevent the body from being re-used with a different packet type.
If either the identification or signature are modified, the packet will no longer have a valid authenticity. And since the remainder of the packet is the body of the packet matching the signature, any modifications made to the packet will invalidate the authenticity.
identification
signature
packet type (ip chain link)
previous signature
IP addresses
Whenever the list of IP addresses on a host changes, it should send out an IP-chain link packet to all associated hosts. As a practical boundary on the frequency of IP address changes, these packets should be sent out no more frequently than once a second.
The signature of the previous IP-chain link packet is included in the IP-chain link packet body. This establishes a strict ordering to the packets to protect against replay attacks. Note, however, that use of this mechanism may require re-transmission of earlier IP-chain link packets.
identification
signature
packet type (ping sequence)
ip-chain link packet signature
sequence number
Transmitted once a second to all associated hosts. These packets are used to confirm reachability on an ongoing basis. Failure to receive these packets from a host should trigger rediscovery attempts.
The sequence number on ping sequence packets associated with a given IP-chain link packet will be strictly increasing.
A real, practical network consists of several hosts. Some of those hosts will be yours, while other hosts may belong to a friend or other entity. The reason for having several hosts is to decrease the likelihood of a network split, wherein part of the network has completely lost contact with another part of the network.
However, the larger the network, the more risk each host in the network inherits from the other hosts. Not every host will always be completely trustworthy, and given that there is no practical means to know which hosts cannot presently be trusted, the only real solution is to provide minimal trust to all hosts in the network.
For the sake of coherence, let's consider the smallest scale network that still provides insight into the large-scale problem. This network consists of three hosts that we will call Alice, Bob, and Charlie.
A---B
\ /
C
If any single host changes location in the network, they simply need to re-broadcast their location to the last known location of the other hosts in the network to maintain connectivity. However, if Alice and Bob both change location at roughly the same time, then they will find themselves in a situation where neither is aware of the current location of the other.
a b <-- old locations
/ \
B---C---A
Alice and Bob must, somehow, relay their current location through Charlie. The simple solution would be to trust anything that Charlie reports. However, this would be compromising Alice and Bob's independent security.
There are two well studied solutions to this problem. We will call those solutions "the Rumor-mill" and "the Messenger".
Alice and Bob ask Charlie about each other, and Bob is expected to reply with its last known location of each. Once Alice and Bob have heard where each other is expected to be, they then proceed to attempt verification of each other's present locations.
This verification most likely requires some form of challenge-response mechanism.
Alice and Bob ask Charlie about each other, and Bob is expected to reply with messages forwarded from each. Those messages contain signatures from Alice and Bob that validate their authenticity, thus guaranteeing that Charlie has not tampered with the messages.
These messages most likely require some form of strict ordering to prevent abuse of previously transmitted messages.
Modern routers are only guaranteed to support TCP and UDP. Of those two, UDP is the simplest for performing NAT poking. UDP also entrusts queueing and rate limiting to the application, whereas TCP is dependent on operating system implementation. Since UDP behavior relies less on operating system implementation, it is also far easier to implement logging of operational details that are likely to be of use for troubleshooting and development of network software.