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 [email protected] _______________________________________________ AFS3-standardization mailing list [email protected] http://lists.openafs.org/mailman/listinfo/afs3-standardization
