[OpenAFS-devel] rx/header extension
Matt Benjamin
matt@linuxbox.com
Wed, 15 Apr 2009 10:32:14 -0400
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Good AM folks,
After speaking briefly with Jeff Altman about the fate of the connection
clones patch (which tries internalize a process for exceeding the hard
limit of 4 calls per rx connection, by creating "clone" connections that
share the security context of the original), it emerged that he and
probably Derrick now are thinking this may have been a dead end.
I'd asked whether we might use some type of capability negotiation to
assist on the clones ticket at an earlier stage, and at that time
started some discussion going with Tom Keiser (who had some ideas
already) and Jhutz, who contributed ideas.
So I'm forwarding what we had arrived at (incomplete) along, to
hopefully spark some discussion. We're all aware that eventually, this
would need to lead to a draft by one or more authors to
afs3-standardization, but I don't think we're ready yet.
There were two original paths we examined.
I had thought initially that negotiation could possibly happen above the
existing rx implementation, perhaps using an implicit RPC (or sequence).
The hypothetical advantage of this would be to rely on existing rx
security. We agreed that it would be possible to force renegotiation
across a restart.
Meanwhile Tom had thought of an extension to the rx header, flagged by
one of the unused rx flag bits. The text below summarizes where we had
gotten thinking out this approach, which seemed preferable. However, we
had not resolved issues with assuring the integrity of the extension header.
I hope that's a good summary...
Matt
- --On Friday, January 09, 2009 04:43:08 PM -0500 Tom Keiser
<tkeiser@gmail.com> wrote:
> On Wed, Jan 7, 2009 at 9:42 PM, Matt Benjamin <matt@linuxbox.com> wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA256
>>
>> Hi Tom and Jeff,
>>
>> Jeff, you raised good points against negotiation of headers.
>> Re-reading, I wonder if Tom your header sequence suggestion wasn't
>> closer to the mark.
>>
>> As my intention to introduce negotiation was aimed at header extension
>> to get cid16, I find myself left with no real arguments in its favor.
>> Maybe you guys now have?
>>
>> I wondered whether we needed the extension type field, as it claims a
>> lot of bits. There might be ways to omit the last-header field, too, it
>> seemed like. I wonder whether there isn't an argument somewhere for
>
> Hi Matt,
>
> My intention was to create a reasonably extensible format. I take it
> your concern is minimizing the protocol overhead. Given that we MUST
> allocate a bit in the existing header to notify the peer of the
> extension's presence, and free bits in the existing header are scarce
> (16, 64 and 128 appear to be free), I want the bit to represent as
> general a concept as possible. I suppose we could take the IPV6
> extension versus options approach -- in v6 extensions are well-known
> with fixed length and format, whereas options are variable length and
> encapsulated within an extension. Using this paradigm, we could deem
> the extended channel id to be a well-known extension, and thus not
> require the 8-bit length field. If we were to go this direction, I'd
> propose the following:
>
>
> /** packet header flag which is asserted when extension header(s) are
> present */
> # define RX_HDR_EXTENSION 64
>
> Extension header:
>
> 1 bit -- last extension flag
> 1 bit -- when asserted, peer MUST understand this extension type,
> or an abort/call error must be sent*
> 6 bits -- extension type
>
> Then, I'd suggest reserving an extension type code (perhaps 0x3F?) for
> variable-length "option" payloads.
>
> Option header:
>
> 8 bits -- option type
> 8 bits -- option length
>
> * if the extension code type is an option extent, I'd propose that the
> "peer must understand this type" flag should apply to the option type
> code, not the extension type code
Having non-critical extensions is kind of pointless when an
implementation which does not understand the extension will not know
enough to be able to skip past it. I propose instead that we do
something like the following:
1 bit -- last extension flag
1 bit -- critical extension flag
6 bits -- extension number
8 bits -- extension length, only for non-critical extensions
In this way, we have 6 bits (64 values) for critical extensions, whose
length is expected to be known by recipients which understand them, and
6 bits (64 values) for non-critical extensions, whose length is encoded
in the packet. Of those, we should reserve several values:
0x3f -- non-critical, extended extension, for when we run out of
non-critical extension numbers. This would have a length, as
for all non-critical extensions, followed by 8 or 16 bits of
extended extension ID.
0x40 -- critical, NOOP; this is a padding byte with no data
0x5f -- critical, extended extension, for when we run out of critical
extension numbers. This would work like 0x3f, except the
extension is critical. Note that in this case, the implication
is that the particular extended extension in use is critical.
For critical extensions, this has the same space requirements and allows
for the same number of extensions; however, it saves one byte per option
for non-critical extensions at the expense of reducing the number of
options from 256 to 64.
If you're really concerned about length, we can allocate a second flag
bit in the existing header to indicate the presence of an 8-bit
extension mask field, with each bit indicating the presence of a
particular (critical) extension; for clarity these extensions could be
numbered 0x80..0x87. This gives an additional savings of one byte per
option when multiple of these special options are used the same packet,
and no loss when less than 2 are used.
- -- Jeff
- --
Matt Benjamin
The Linux Box
206 South Fifth Ave. Suite 150
Ann Arbor, MI 48104
http://linuxbox.com
tel. 734-761-4689
fax. 734-769-8938
cel. 734-216-5309
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFJ5e/uJiSUUSaRdSURCP/BAJwLcOYd7iAP5SMWiDlRLFh1zkrjZgCdFazo
dTYNq/FSxClXo95/MHPcZfw=
=/IPj
-----END PGP SIGNATURE-----