ietf-openpgp
[Top] [All Lists]

Re: PGP Keyserver Synchronization Protocol

1999-06-30 11:04:50
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(_at_)informix(_dot_)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