[OpenAFS-devel] rx/header extension

[Tom Keiser]

On Wed, Apr 15, 2009 at 10:32 AM, Matt Benjamin <matt@linuxbox.com> wrote:
> -----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. =A0We'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).
> =A0The hypothetical advantage of this would be to rely on existing rx
> security. =A0We 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. =A0The text below summarizes where we had
> gotten thinking out this approach, which seemed preferable. =A0However, w=
e
> had not resolved issues with assuring the integrity of the extension head=
er.
>
> I hope that's a good summary...


To some degree, I think we stopped moving forward with a draft because
of a lack of time.  However, as I recall, there were still a few
unresolved issues.  Immediately, I see two key issues which need to be
addressed:

1) providing a fool-proof mechanism to deal with peer version downgrades
2) a mechanism to address encryption/checksumming of header extension field=
s

Both of these issues are non-trivial, and demand further thought.

(1) is particularly nasty since the lowest layer of rx is effectively
a stateless mux.  For issuance of new calls, two different downgrade
detection ideas initially occurred to me:

a) perhaps we could pad the first several bytes of payload with an
illegal value for an rpc opcode (I can't remember off the top of my
head whether any part of the opcode namespace is reserved, so this may
not work).  If that would work, then we would fork based upon presence
of extension support bit assertion in the RXGEN_OPCODE return packet.
If the extent support bit was asserted, then clearly we hit an
unimplemented rpc.  Otherwise, we could retry without extensions.

b) since the Rx service id namespace is well defined, we could
allocate a special service id which is reserved for exended headers.
We would place the special service id in the rx header, and the actual
service id would be embedded as a required field in the extension
header.  Similarly to (a), we could fork based upon error return
codes.


If people would prefer that we take this discussion over to
afs3-standardization, please say so.

Regards,

-Tom


>
> 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. =A0There might be ways to omit the last-header field, too,=
 it
>>> seemed like. =A0I wonder whether there isn't an argument somewhere for
>>
>> Hi Matt,
>>
>> My intention was to create a reasonably extensible format. =A0I take it
>> your concern is minimizing the protocol overhead. =A0Given 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. =A0I 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. =A0Using this paradigm, we could deem
>> the extended channel id to be a well-known extension, and thus not
>> require the 8-bit length field. =A0If 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:
>>
>> =A0 =A01 bit =A0-- last extension flag
>> =A0 =A01 bit =A0-- when asserted, peer MUST understand this extension ty=
pe,
>> or an abort/call error must be sent*
>> =A0 =A06 bits -- extension type
>>
>> Then, I'd suggest reserving an extension type code (perhaps 0x3F?) for
>> variable-length "option" payloads.
>>
>> Option header:
>>
>> =A0 8 bits -- option type
>> =A0 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. =A0I propose instead that we do
> something like the following:
>
> 1 bit =A0-- last extension flag
> 1 bit =A0-- 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. =A0Of those, we should reserve several values:
>
> 0x3f -- non-critical, extended extension, for when we run out of
> =A0 =A0 =A0 non-critical extension numbers. =A0This would have a length, =
as
> =A0 =A0 =A0 for all non-critical extensions, followed by 8 or 16 bits of
> =A0 =A0 =A0 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
> =A0 =A0 =A0 extension numbers. =A0This would work like 0x3f, except the
> =A0 =A0 =A0 extension is critical. =A0Note that in this case, the implica=
tion
> =A0 =A0 =A0 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. =A0This 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 =A048104
>
> 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=3D
> =3D/IPj
> -----END PGP SIGNATURE-----
> _______________________________________________
> OpenAFS-devel mailing list
> OpenAFS-devel@openafs.org
> https://lists.openafs.org/mailman/listinfo/openafs-devel
>



--=20
Tom Keiser
tkeiser@gmail.com