[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Multicast Keyserver Synchronization
Last summer, Michael Baumer has been working out and implementing a
protocol for efficient key server synchronization (with input from
Nathalie Weiler, Patrick Feisthammel, and myself). The semester thesis
report can be found at
Unfortunately, lack of time have prevented us from developing this
further than a prototype implementation based on pks-0.9.3.
In the following, I'll present the main goals.
1. Reduce the load for basic keyserver synchronization
2. Insure synchronization with very little network traffic
3. Allow the operation of cache/partial keyservers
Currently, each keyserver has a list of neighbors (syncsites), which
it sends new keys and signatures ("incrementals") to by mail. This
results in flooding each message along the keyserver network. Each of
the hosts receives the message potentionally from each of its
syncsites. To achieve high reliability, the degree of the syncsite
graph has to be relatively high, resulting in many redundant mails for
a single incremental.
The flooding approach is not well-suited for the mail system, which
results in regular overloads at sites (too many processes), and lost
incrementals. Although, if a destination is down for some time, the
mail queue at its syncsites quickly grows without bound, requiring
Instead of using the "push" semantics using mail, our proposal is to
use a combined "push-pull" semantics using IP multicast (and
designated unicast tunnels for sites not connected to the MBone).
Whenever a keyserver learns of a new packet to any key from an
"old-style" source, the following steps are performed:
- it tags that packet with a world-wide unique sequence number,
consisting of its host ID to make everything unique, and the
next number of its private sequence number space
- it multicasts the tuple (host ID, sequence number, OpenPGP packet)
to the multicast group (together with an identification of the
enclosing UID and public key packet.
- add the packet together with its sequence number to their database
- make sure that the sequence number from this host is exactly one
higher than the previous number. If not, they ask for retransmission
of missing packets
On a regular basis, keyservers heartbeat the list of their known (host
ID, highest sequence number) pairs, to tell the others what their
belief of maximum sequence number is. This packet's size is
proportional to the number of sequence-number creating keyservers, and
not influenced by the number of "listening" keyservers or the number
of keys in the database. When any host thus learns of a higher
sequence number, it starts requesting the missing packets from either
a closeby host or the originator.
In our experiments, the network traffic generated was much less than
it is with the current e-mail-based synchronization. Also, the load
was lower. To insure against malicious sending of packets, it is
possible to get (possibly signed) *incremental* digests from the
originator. We also believe, that this is better than sending out
hashes of all keys.