On 6 Apr 2012, at 18:37, Andrew Deason wrote: > 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 current recommendation seems to be that for ciphers with a block size of 128 or more, you want to rekey for every 2^(BlockSize/4) bytes of data that are exchanged. With AES, this gives us a theoretical limit of 256 Terabytes of data per connection. Practically, there are other limits that we are likely to hit on a per-call basis first. RX packet sequence numbers are limited to an unsigned 32 byte integer, and we don't support these rolling round. Assuming a 1428 byte payload, this limits us to approximately 5 Terabytes of data per call. > 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. This sounds like a great plan. I'll amend the current draft to incorporate this, and send it round for (hopefully) one last spin. > 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... In terms of what's happening at the moment, there is a working rxgk implementation which is being used by a couple of cells. Its inclusion in OpenAFS is blocked on us reaching consensus in this group on the protocol description. I'm keen on doing so as soon as possible, but as I already have to respin to incorporate Thomas Kula's comment, it seems like a good point to pick this up as well. Cheers, Simon. _______________________________________________ AFS3-standardization mailing list [email protected] http://lists.openafs.org/mailman/listinfo/afs3-standardization
