[AFS3-std] Re: draft-wilkinson-afs3-rxgk-afs-01 comments

[Andrew Deason]

On Sun, 3 Jun 2012 19:44:44 -0500
Andrew Deason <adeason@sinenomine.net> wrote:

> This email contains the trivial and less trivial; nontrivial
> discussion on section 10 will follow in a separate email, because I
> think there's a lot to talk about wrt it.

Here are those comments.

paragraph 1:

The reference to XCB seems vague. This could either use a reference to
the XCB draft, or it could just say in general that future enhancements
will add file- related data over the callback channel.

paragraph 2:

"part of the RXAFS_ family" should read "part of the AFSINT protocol", I
think?

minor point: To be consistent with other RPC names, this should be
SetCallBackKey, not SetCallbackKey

2nd paragraph after SetCallbackKey:

Breaking all callbacks on a SetCallbackKey invocation seems
heavy-handed; is this necessary? Should instead this call just be a
barrier between the old and new key? That is, all callback promises
generated before issuing SCBK will be broken using the old key, and all
callback promises generated afterwards use the new key.

3rd paragraph after SetCallbackKey:

"Only RPCs issued over an rxgk protected connection should receive rxgk
protected callbacks"

This paragraph doesn't make any sense, since RPCs do not receive
callbacks; clients receive callbacks. What I believe this is trying to
say is that only callback promises generated by RPCs issued over an rxgk
protected connection should be broken via rxgk-protected callback
breaks. So, I would think this should be phrased more like, fileservers
MUST NOT issue rxgk-protected callbacks for breaking callbacks generated
by non-rxgk-protected RPCs.

However, this still does not seem like an adequate specification, since
a callback promise can be generated/shared by several different RPCs.
That is, if a client issues an rxgk-protected FetchData, then an rxnull
FetchData for a different chunk on the same file 5 seconds later, which
do we send?

What I was thinking is that fileservers need to track callback promises
generated from rxgk-protected RPCs separately from other callback
promises.  If a fileserver needs to send callback breaks over the
callback channel, it will send rxgk-protected calls until all
rxgk-protected callback promises have expired or been broken.

This allows the callback channel protected-ness to be downgraded
somewhat automatically, without allowing for downgrade attacks. The
current language does not really address downgrades, so, depending on
the interpretation, a client could break itself ~forever by just
upgrading to rxgk once (unless you have administrator intervention,
which for clients seems in general less practical). With the above
suggestion, a client can automatically downgrade after all of the
rxgk-protected callbacks have expired.


As a general note, at least some of the protocol specifications here
seem like they may belong in a document defining XCB (or whatever
specification for callback improvements). Or, some of the complexities
here may warrant an entire separate document explaining the interaction
between callbacks and XCB.

This section also seems a little unclear on when this mechanism should
be utilized; that is, we specify when the fileserver may use the
protected callback channel, and when it must not, but does not provide
recommendations for when the whole system should be used (do we always
use this for XCB and nothing else? or do we use it for all callbacks
whenever possible?). This should perhaps be specified by the document
defining a new callback protocol, but if so, the lack of it here should
be explicitly stated.

-- 
Andrew Deason
adeason@sinenomine.net