On Wed, Oct 14, 2009 at 7:04 PM, Chaskiel Grundman <[email protected]> wrote: > >> By "application layer" - do you mean the application (ie, fileserver, >> ptserver) instead of the security mechanism? I can't speak for the >> rxgk side of things, but speaking from the rxk5 side of things this >> is something I was specifically seeking to avoid: application/mechanism >> specific glop. Or, in a world, "yuck". But, ignoring that problem... > > Well, more like the client application (cache manager, ubik). When the key > expires, all calls on that connection start to fail, you throw it away, and > call rx_NewConnection, which gets you a new cid, which means you get a new > TK. The fileserver has some code for this, but I think it never gets > triggered (i.e. it's leftover from the bcrypt days) > >> From the rx side of things, there is a problem: there may be handling >> multiple >> calls, they may be in different stages of completion, and there is no >> guarantee on how long any given call might last. On the server side, it's >> not possible to know what calls the client might have sent, are in-flight, >> but haven't been received on the server. This means there is no >> logical "good" place timing-wise for the server to return "VICETOKENDEAD". >> Waiting for idle moments on a connection on the server may not be possible >> for a sufficiently busy connection. Adding slop in will reduce problems, >> but not eliminate them. > > Once you decide the key is expired, all in progress rpcs start failing in > _CheckPacket, as if the token was expired (but with an error code that > causes an immediate retry) > >> idempotent. And, of course, if a bulk data write is larger than the >> "byte window" in rxgk, things get worse. > > I had hoped to avoid additional complexity, but that's a good reason to > either do rekeying, or make the byte life more advisory (i.e. the transport > doesn't enforce it at all, but the app enforces it at the begining of an rpc > if it wants to, as src/viced/host.c:GetClient() redundantly does for token > lifetimes).
I'm not sure advisory byte life is going to be satisfactory for all rxgk use cases. Consider the afs3 volume dump and forward RPCs, which treat the split interface as a long-lived bulk transport. We know that there are sites which routinely move several terabytes of data under a single split call, over periods of many hours. Given the extremely large amounts of data being transported, and the relatively long time periods over which a split call can exist, I think we would be remiss to ignore the rekeying problem. -Tom _______________________________________________ AFS3-standardization mailing list [email protected] http://michigan-openafs-lists.central.org/mailman/listinfo/afs3-standardization
