[AFS3-std] Re: Last Call: afs3-rxgk-04, afs3-rxgk-afs-02

[Andrew Deason]

On Fri, 26 Apr 2013 13:03:35 -0400 (EDT)
Benjamin Kaduk <kaduk@MIT.EDU> wrote:

> >>       const RXGK_MAXMIC = 16384;
> >
> > By contrast, this seems large. The MIC is going to be the length of
> > the chosen encryption type's checksum, plus a small amount of header
> > material. For aes-256, that's a mere 28 octets (16 of CFX token, 12
> > of checksum). So, I think we could get away with something smaller
> > here.
> 
> I note that you do not suggest a new value :) This is large, it is
> true.  On the other hand, the goal of putting a limit here is to avoid
> excessive resource allocation by the rx peer without getting in the
> way of normal operation ... on the scale of 2**31, it's not very large
> at all.  Would you want to drop down to, say, 1024, or even smaller?

I'd rather err on the side of this being ridiculously large; 16k
shouldn't cause any problems. (But 1k is fine, too.)

> > 8.5 The Response
> > ----------------
> >
> >>   const RXGK_MAXAUTHENTICATOR = 1500  /* better fit in a packet! */
> >
> > The normal maximum size of an RX payload is 1416 bytes, so an 
> > authenticator of 1500 definitely won't fit in a packet! rxkad ends up
> > taking liberties here, and just extends the maximum size of packet when 
> > the data it needs to transmit is too large, but that causes issues on 
> > networks that drop fragmented UDP. It would be good to avoid those
> > here...
> 
> So you want to change 1500 to 1416?  I don't mind -- as I said, these
> constants were just things I made up and they didn't get much
> discussion.

If you want to guarantee things work in the scenario Simon describes
above, the whole payload of the response packet needs to be about 1416
or less. Since we have two variable-length items in it, the only way to
ensure that is if they're both less than 700 or something.

I don't think it's necessary to set these sizes to enforce that the
generated packets are "small enough", but that seems like a good
guideline of how small they will be if an application wants to work
vaguely "everywhere". (Maybe an implementation can force a smaller size,
but doing that in the rxgk spec itself seems far too broad a stroke;
there are networks where the larger packets work fine.)

So, something around 1400 or 1500 seems fine to me. Just don't think 
that that means it'll always fit in a single unfragmented packet.

-- 
Andrew Deason
adeason@sinenomine.net