SPC-4: Security Protocol In Supported Protocols

[Gerry.Houlder at seagate.com]

* From the T10 Reflector (t10 at t10.org), posted by:
* Gerry.Houlder at seagate.com
*
I did intentionally use an 8 byte header for the Protocol ID = 00h,
SP_Specific = 0000h case to allow for additional feature reporting to be
designed into the extra reserved bytes, as the committee sees useful
purpose. This is thought to be useful as a place for "Inquiry type" bits to
report security related features. This is expecially needed in cases where
the drive might be locked or have other security functions that disable
responses to many other commands. The other designed cases (one other
protocol ID = 0h case, the SSC-3 protocol cases) didn't envision much
future need for extra reserved bytes and went for 4 byte headers.
This is not the first case in which the parser has to be aware of one or
more CDB bytes in order to predict the correct size of headers in data
field. I can quickly name two other examples:
(a) Mode data has a 4 byte header for 6 byte CDB version, but an 8 byte
header with 10 byte CDB version.
(b) Data for Format command has 4 byte header if Longlist bit in CDB is
zero and has 8 byte header if Longlist bit is one.
I agree with Ralph's point about future protocols choosing their own header
size, so it is likely that other security protocols may make other choices.
You may have a point that, within protocol ID = 0h, some SP_Specific values
dictate different header sizes. It may be disireable to use the same header
size for all cases using the same protocol ID. If this is your point, I
would agree to make all protocol ID = 0h cases have an 8 byte header. I
would not suggest that the SSC-3 proposal (which will use its own protocol
ID) change to an 8 byte header, however.
Others may argue that, once you have to inspect one CDB byte to determine
the correct header size to expect, it is not that much harder to inspect 2
or 3 CDB bytes before you can get to the correct size. This difference is
negligible if you are parsing the data in firmware but may be significant
if you intend to parse the data in hardware. Are you thinking this function
will be parsed by hardware in the near future?
	     Kevin D Butt						   
	     <kdbutt at us.ibm.co						   
	     m> 							To 
	     Sent by:		       t10 at t10.org, roweber at IEEE.org	   
	     owner-t10 at t10.org						cc 
	     No Phone Info						   
	     Available						   Subject 
				       SPC-4: Security Protocol In	   
				       Supported Protocols		   
	     03/28/2006 05:30						   
	     PM 							   
Ralph, Gerry, and all,
In SPC-4 rev 4 in looking at the SECURITY PROTOCOL IN command, I have found
that there is an inconsistency between where the length field is placed in
both listed IN pages.
In Table 175 — Supported security protocols SECURITY PROTOCOL IN parameter
data, the length field is in bytes 6 & 7, but in Table 176 — Supported
security protocols SECURITY PROTOCOL IN parameter data the length field is
in bytes 2 & 3.  Likewise in the proposed Tape Data Encryption security
protocol the length is also in bytes 2 & 3.
Having the length field in different bytes makes it very difficult for
parsing.  In this case it requires that you know a priori what data is
coming back.  The parser must be CDB aware and also must know about the
specific security protocols in order to parse.	This seems like a very bad
design to me.  Can we modify the location of the length bytes in Table 175
— Supported security protocols SECURITY PROTOCOL IN parameter data, to be
in bytes 2 & 3 and not in bytes 6 & 7?
Thanks,
Kevin D. Butt
SCSI & Fibre Channel Architect, Tape Firmware
MS 6TYA, 9000 S. Rita Rd., Tucson, AZ 85744
Tel: 520-799-2869 / 520-799-5280
Fax: 520-799-2723 (T/L:321)
Email address: kdbutt at us.ibm.com
http://www-03.ibm.com/servers/storage/
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org