-----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 <[email protected]> wrote: > On Wed, Jan 7, 2009 at 9:42 PM, Matt Benjamin <[email protected]> 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----- _______________________________________________ OpenAFS-devel mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-devel
