[AFS3-std] draft-wilkinson-afs3-rxgk-02 comment

[Andrew Deason]

So, I discussed the rxgk document with a few others a while ago... we
had some non-substantive or minor formatting/wording/clarification
comments but I think just one major substantive comment. While I've been
waiting for someone to send me the electronic notes from that discussion
in order to bring up the non-substantive comments, I realized I can
mention the substantive one in the meantime.

Anyway, there were some concerns about the small width of the rekeying
key version number field (16-bits; this is section 8.2 and thereabouts).
Since it seems likely that a single Rx conn or call can/will be used to
send large amounts of data and/or last for a very long time, what may
seem like reasonable rekeying lifetimes or bytelives in the future can
render such connections unusable (bytelife moreso). So, for certain
applications, the only way to ensure that the call will not prematurely
terminate due to kvno rollover is to never rekey, which seems to
somewhat defeat the purpose. 2^16 rekey ops just doesn't seem like that
many, but I'm not sure if that's the norm.

The field could just be expanded if the value is stored as part of the
security blob or something, but I was wondering about something simpler.
What if you define the kvno to logically be 32 bits (or 64), but on the
wire you just transmit the lower 16 bits of the actual kvno? It doesn't
seem possible for the endpoints to be confused about the actual kvno in
use, since we only accept kvnos between 1 greater and 1 less than what
we think the current kvno is; we cannot be thousands off.

I don't know how much of a concern this really is; the fact that
rekeying is there at all (and all of the other aspects of the security
class) already make this a vast improvement over the current situation.
And I know this isn't exactly in the normal timeframe of discussion, but
it's a (possible) problem regardless, and it doesn't seem like much is
happening anyway at the moment, so...

-- 
Andrew Deason
adeason@sinenomine.net