[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Multicast Keyserver Synchronization

Marcel Waldvogel wrote:

> 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
> http://www.tik.ee.ethz.ch/tik/education/sadas/SASS1998-33/thesis.ps.gz
> 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
> Status:
> 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
> manual intervention.
> Solution:
> 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:
> * Sender:
> - 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.
> * Receivers:
> - 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.
> -Marcel

where does a server get its worldwide unique sequence number? don't we
need a central authority here? If so, I believe that this is incongruous
to the soul of PGP.