[AFS3-std] rxgk: Rekeying

[Jeffrey Hutzelman]

--On Wednesday, October 14, 2009 05:50:17 PM -0400 Marcus Watts 
<mdw@umich.edu> wrote:

> So, for instance, if the client is in the middle of a bulk data write,
> and the server decides to return "VICETOKENDEAD", then on the client
> there is a problem.  The client has no way to know how much of the
> write was accepted by the server before the error was returned

Sure it does.  RPC's are atomic.  If the RPC failed, it failed, period. 
The server is responsible for ensuring that it has not committed any change 
(note that in practice, OpenAFS doesn't actually do this, which means it is 
already possible for things to break).

Note that any of the failure modes you describe can happen today with an 
expired token.

> 2/
> For key version numbers, wraparound should not be a real problem.
> You don't need to send the whole version number, you only need to send
> the least significant bits - enough to distinguish between "old" and
> "new".  Of course you still need to store the whole thing at both ends

That depends on whether key version numbers are just versions, or actual 
counters used to produce a derived key.  If the former, you don't need to 
store the whole thing anywhere; you'll only have a few relevant ones at a 
time, and it's well-understood how to handle operations on mod-n sequence 
number spaces.

> On the wire, one bit is probably sufficient

Nope.  If the current key is represented by value 0, does 1 mean the next 
key or the last one?  You need a few bits, depending on how many keys might 
be relevant.  Again, this sort of sequence number is fairly well 
understood; see TCP.

-- Jeff