Extended CDBs

Sivan Tal SIVANT at il.ibm.com
Wed May 2 04:46:32 PDT 2007


* From the T10 Reflector (t10 at t10.org), posted by:
* Sivan Tal <SIVANT at il.ibm.com>
*
Ralph,
Here are my comments on this version. I'd like to mention that this
proposal satisfies the needs for CbCS extensions for now. The comments
relate to the general use of standardized extensions and the ways in which
multiple extensions may be handled and may interact with one another.
"XCDB descriptor" - I suggest renaming the term to "extension descriptor",
as it describes a particular extension.
You do not allow "More than one XCDB descriptor contains the same extension
type;"	I don't see a good reason not to allow it. I think such restriction
can be made specific to an extension where appropriate, rather than limit
the extension model.
I don't see the reason for this standard to require ordering restrictions
of XCDB descriptors. One can specify restrictions that are specific to
descriptors. But in general there could be extensions that have no ordering
restrictions. Also, this scheme is problematic for long term maintenance:
Suppose you have two extensions, with orders M and N (where M<N). This
means that in the future, only N-M-1 order-sensitive extensions can be
added in between.
I can see, however, that an extension will require to be first or last and
you want to be "explicit" about it, and you may want to add two bits for
specifying these restrictions instead of the total order. (I guess I am not
strongly against the ordering specification after all...)
There is no delimiter that would help an implementation to avoid going
out-of-bounds when parsing the XCDB. In your annex (X.2) you rely on
encountering an unrecognized EXTENSION TYPE. But if you're reading past the
last extension, you're reading garbage that could incidentally match a
defined type. Then you're in trouble...  The previous version had a "next
encapsulation type" field that was used to denote that there is no next
encapsulation. We need something equivalent here. It could be a single bit.
Alternatively (and may be an even better solution), add a SIZE field to the
XCDB. This would be consistent with the other type of variable length CDB
(operation code 7Fh)
The lack of an EXTENSION SIZE field in the XCDB descriptor prevents an
implementation from being forward compatible with future extension types
(referring to annex X.2 again). As in my comments on the previous version,
I again suggest that a LENGTH field is added to the XCDB descriptor, i.e.
specify the extension size in the extension itself in addition to the
standard. The motivation is forward compatibility of implementations of the
X.2 algorithm.
Two little comments on the History clause:
1. In IPsec, ESP stands for Encapsulating Security Payload (not Protocol).
2. Seems like we ended up with something more similar to Authentication
Header (AH).
See you in Bellevue.
- Sivan.
	     Ralph Weber						   
	     <roweber at IEEE.org						   
	     >								To 
	     Sent by:		       "'t10 at t10.org'" <t10 at t10.org>	   
	     owner-t10 at t10.org						cc 
								   Subject 
	     02/05/2007 05:09	       Extended CDBs			   
* From the T10 Reflector (t10 at t10.org), posted by:
* Ralph Weber <roweber at ieee.org>
*
I have uploaded the latest revision of the CDB encapsulation
(now extension) proposal.
http://www.t10.org/ftp/t10/document.07/07-029r2.pdf
Based on the discussions in Houston, the proposal is a near-
total rewrite (starting with a new title), see:
http://www.t10.org/ftp/t10/document.07/07-182r1.htm
See you in Bellevue,
.Ralph
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org



More information about the T10 mailing list