[AFS3-std] rxgk key version number of value zero

Jeffrey Hutzelman jhutz@cmu.edu
Tue, 11 Dec 2012 16:41:53 -0500


On Tue, 2012-12-11 at 20:30 +0000, Simon Wilkinson wrote:
> On 11 Dec 2012, at 20:05, Michael Meffie wrote:
> 
> >   The Checksum field allows for an optional packet checksum.  A zero 
> >   checksum field value means that checksums are not being computed.  An
> >   Rx security protocol (identified by the security field, described
> >   below) may choose to use this field to transport some checksum of the
> >   packet that is computed and verified by it (for example, rxkad uses 
> >   this field for a cryptographic header checksum).  Rx itself makes no
> >   use of the checksum field.
> 
> Technically, this is a "spare" field that rxkad hijacked to use for
> checksums. I don't think there's any particular problem with rxgk
> assigning it a different meaning. One possible consideration is that
> the OpenAFS RX stack notes the presence of non-zero values here, and
> the rx_IsUsingPktCksum() function will return true if it has seen any
> in the life of the connection. However, the only caller of this
> function in the OpenAFS code is rxkad, and I don't think it makes much
> sense outside of rxkad itself.

In fact, it makes sense only in versions of rxkad newer than 1989 or so.
Versions of rxkad prior to that didn't use this field, and had no
equivalent to the checksum that is carried there today.  According to
RCS logs, the rx_{Get,Set}PacketCksum interfaces were introduced in 1991
by Ted Anderson; they were present by the time AFS 3.1 was released.

rxvab never used the spare/cksum; in fact, its CheckPacket always
succeeds.  R did have a checksum field in its headers, but it was never
actually used -- the field was always sent as -1 and discarded as the
packet was being decoded (R's headers were XDR'd on the wire).

-- Jeff