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

Re: PGP Keyserver Synchronization Protocol



After working over Baumer's paper a bit, I don't understand the fault 
handling bits of the protocol, in chapter 4.  (Wording quoted here are all 
from section 4.1, the overview):

	- "When a keyserver detects a gap in the sequence number, it sends a 
_request_ message to another keyserver, ..."  When is the gap checked 
for?  Upon receipt of an update, no doubt; what about upon receipt of "a 
_request_ message"?

	- "... the sequence number ..."  Is that the number of the last contiguous 
known event, the first missing, the last missing, or the first received 
noncontiguous?  In general, there may be missing gaps, not merely single 
events (indeed, this seems more likely to me).  ("The oldest  missing 
sequence number" seems like a good choice, with the implication that this 
one and all subsequent known events be transmitted.)

	- "Then the Nearest Neighbour sends the information..."  What if the NN is 
also missing the requested info?  Mention of deadlock elsewhere suggests 
the NN might in turn requery its NN at this point, but this is nowhere 
explicit.

	- During this period (while a _request_ is pending from the NN), what is 
the behavior of the server with respect to the request itself?  Does it 
retry its request periodically, and/or after a timeout?  Should the server 
crash in the interregnum, is it obligated to restore itself in some state 
that will accept (or re-request) this info?  Or does it wait until yet one 
more event arrives from the originator?  Does it continue to accept and 
apply new server-server updates from this originator?  From other originators?

	- During this period, does it continue to serve uploads and requests from 
users?  Does it attempt to apply the updates?  (Note that some events, from 
beyond the gap, from other servers, or from users, may not be possible to 
apply, without the missing data - a new user ID added but lost, for 
example, means a subsequent signature on that ID can not be applied - and 
may not come even from the same originating server, so the potential 
extends over all updates.)

	- How does the distributed database detect and communicate the case where 
a request to an NN is for some sequence number that in fact does not exist?

I'm particularly thinking of a potential global denial-of-service attack, 
by sending a nonsensically-high sequence number into the mbone.  All 
keyservers then query their NN, but none know the answer.  There is no 
algorithm apparent here to recover (not to say it couldn't exist, but I 
don't find it here).






Informix Software, Inc.        Jack Repenning
Config/Release Mgmt            jackr@informix.com
4100 Bohannon Drive            M/S: 4100/2
Menlo Park, CA 94025           FAX: 650/926-6571
VOICE: 650/926-1044               PAGE: 800/781-6182
PGP/RSA: D24B E2C2 9AFB 7C24 : 7E59 7885 525D 644E
PGP/DSS: 955C 44AD 8FCE 77D4 9494 \
           : 4AB2 51F1 3EED 3B82 E870