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

[Simon Wilkinson]

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.