SSC-3: Discussion related to Letter Ballot SYM-019-a

Paul Suhler Paul.Suhler at Quantum.Com
Fri Jun 20 15:38:02 PDT 2008


Formatted message: <A HREF="r0806205_f.htm">HTML-formatted message</A>

I believe that there was another use case in which old tapes were copied
onto newer tapes to avoid wear becoming so bad that error rates would go
up too much.  Keyless copy was seen as a way of improving the security
of this.
Thanks,
Paul
___________________________________
Paul A. Suhler | Firmware Engineer | Quantum Corporation | Office:
949.856.7748 | paul.suhler at quantum.com  
___________________________________
Disregard the Quantum Corporation confidentiality notice below.  The
information contained in this transmission is not confidential.
Permission is hereby explicitly granted to disclose, copy, and further
distribute to any individual(s) or organization(s), without restriction.
________________________________
From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of Kevin D
Butt
Sent: Friday, June 20, 2008 11:14 AM
To: Roger Cummings
Cc: t10 at t10.org
Subject: RE: SSC-3: Discussion related to Letter Ballot SYM-019-a
Roger, 
The group forced me to create the KCSLU and KCDLU terms in order to
describe the feature.  In describing what one device is doing, I could
only talk about RAW because to read you need to be in RAW mode and for
the other when writing I could only talk about EXTERNAL because you need
to be in EXTERNAL to write.  So I had to narrow  the discussion
depending on whether I was talking about reading or writing. The keyless
copy section is intended to describe how to use the RAW and EXTERNAL
modes.	I personally don't care what terms are used.  Let me describe
the intent then we can understand what needs to be described.  Hopefully
this will help us describe it clearly. 
The intent is that a system can use the keyless copy capability to copy
data from one tape to another without requiring an encryption/decryption
key.  The use case would be a data recovery lab.  The lab are the
experts on getting the data off the tape but the user doesn't want to
expose the data.  Hence the need to copy the data without having the
decryption key.  I envision that if a device supports RAW it will also
support EXTERNAL.  I really don't see a use case where support for one
but not the other makes sense.	I would have no problem with stating
that if RAW is supported EXTERNAL shall be supported and vice-versa. 
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/ 
"Roger Cummings" <roger_cummings at symantec.com> 
06/20/2008 08:04 AM 
To
Kevin D Butt/Tucson/IBM at IBMUS 
cc
<t10 at t10.org> 
Subject
RE: SSC-3: Discussion related to Letter Ballot SYM-019-a
Kevin, 
I'm not sure that I can accept your simplification that this collapses
to which settings of "ENCRYPTION MODE" and "DECRYPTION MODE" fields are
supported. The issue I'm having relates to the second paragraph on page
55 (PDF page 74) of SSC-3 Rev 4a, which seems to imply that for some
encryption algorithms it's necessary for the KCSLU to support both
EXTERNAL & RAW modes, but for others RAW support is sufficient. Is the
converse of this true i.e. some LUs that support RAW mode will NOT be
able to act as KCSLUs? 
I do agree that this would be a useful simplification if we can resolve
the above point, which I freely admit may be a misunderstanding on my
point. And being able to read the capability of an LU wrt encryption
modes in advance would definitely be a useful thing for our apps. But if
we can make that simplification then I'd recommend that we delete the
terms KCSLU & KCDLU in their entirety as all they mean is "an LU that
supports RAW mode" and "an LU that supports EXTERNAL mode" respectively.
Regards, 
Roger 
P.S. And I haven't forgotten that I have an AI related to SYM-019-b, and
I hope to have something on that subject ready for Anchorage. 
________________________________
From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of Kevin D
Butt
Sent: Thursday, June 19, 2008 3:32 PM
To: t10 at t10.org
Subject: SSC-3: Discussion related to Letter Ballot SYM-019-a
SYM-019-a: 
The 4.2.21.5 Keyless copy section should identify How an application
client determines that a Logical Unit has the capability to act as a
KCSLU or a KCDLU 
There is no bit anywhere that indicates the support for acting as a
KCSLU or KCDLU.  In reality, it is if the LU supports the EXTERNAL
encryption mode or the RAW decryption mode.  So the request here should
be reworded to say how does an application client determine which
settings of "ENCRYPTION MODE" and "DECRYPTION MODE" fields are
supported. 
Looking at the section describing each of these fields, there is no text
describing a CC returned for RAW or EXTERNAL if they are not supported.
The standard is silent.  This is also the case for DISABLE.  Obviously
the standard does not explicitly indicate anywhere that these modes are
optional. 
What should we do? 
Option 1: Add text under the description of these fields stating that if
EXTERNAL or RAW mode is selected and it is not supported then CC.  This
would change the standard to explicitly state that these options are
optional. 
Option 2: Add text somewhere to mandate support for these modes.  I
suspect this option is not desired. 
I think that we must do either option 1 or option 2.  The standard needs
to be clear if these are optional or not. 
If we go done the path that these are explicitly stated as optional,
then this letter ballot comment leads to the question, "How do we report
support for different values in these two fields?"  This is not just a
question of Keyless copy but also of MIXED decryption mode.  There is an
implication that ENCRYPT and DECRYPT are supported as well as DISABLE.
I am not sure that is correct.	There could be a device that only
supportes one or the other or some combinations. 
Comments? 
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/ 
-----------------------------------------------------------
The information contained in this transmission may be 
confidential. Any disclosure, copying, or further 
distribution of confidential information is not permitted 
unless such privilege is explicitly granted in writing by 
Quantum Corporation. Furthermore, Quantum Corporation is not 
responsible for the proper and complete transmission of the 
substance of this communication or for any delay in its 
receipt.



More information about the T10 mailing list