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
___________________________________
___________________________________
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@t10.org
[mailto:owner-t10@t10.org] On Behalf Of Kevin D Butt
Sent:
Friday, June 20, 2008 11:14 AM
To: Roger Cummings
Cc:
t10@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@us.ibm.com
http://www-03.ibm.com/servers/storage/
| "Roger Cummings"
<roger_cummings@symantec.com>
06/20/2008 08:04 AM
|
|
To
| Kevin D
Butt/Tucson/IBM@IBMUS
|
|
cc
| <t10@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@t10.org
[mailto:owner-t10@t10.org] On Behalf Of Kevin D Butt
Sent:
Thursday, June 19, 2008 3:32 PM
To: t10@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@us.ibm.com
http://www-03.ibm.com/servers/storage/