Suggested discussion topic: Persistent reservation for the SECURITY PROTOCOL well known LUN

Avraham Shimor Avraham.Shimor at m-systems.com
Tue Apr 25 12:52:23 PDT 2006


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

Hi colleagues,
In the current revision of SPC-4, in para. 8.5 it is stated that "The
SECURITY PROTOCOL well known logical unit shall only process the
commands listed in table 401."
Now, since table 401 does not list  the  PERSISTENT RESERVE IN/OUT
commands , it is evident that persistent reservation cannot be
exercised on the SECURITY PROTOCOL well known logical unit.  Of course,
this is different from the use of SECURITY PROTOCOL commands on regular
LUNs, where  persistent reservation can be applied (see table 31, part 3
of SPC-4).
My feeling is that the SECURITY PROTOCOL well known logical unit might
be very useful to exercise the SECURITY PROTOCOL commands to affect  the
complete device as a whole, versus affecting a single LUN by exercising
the SECURITY PROTOCOL commands on that specific LUN.  It seems to me,
that the use of persistent reservation, coupled with  SECURITY PROTOCOL
commands,  may be  very useful and important feature to avoid
conflicting/contradicting/ambgous settings   in a multi initiator
environment, not only in relation to a specific regular LUN, but also
for the SECURITY PROTOCOL well known LUN.  
I am interested to hear  the  opinion  of the general T10 membership on
this idea.
As a primer/starter, attached below a thread of preliminary discussion
on this topic between Gerry Houlder and myself.  If there is interest in
the subject, I might suggest to include it on the coming CAP meeting
agenda too.
Best regards,
Avraham
Avraham Shimor
Standardization Coordinator
M-Systems Israel
Phone:	 +972-9-764-5106 
Fax:	   +972-3-548-8666
Mobile:   +972-54-922-2392 
e-mail: avraham.shimor at m-systems.com
<mailto:avraham.shimor at m-systems.com> 
www.m-systems.com <http://www.m-systems.com/&gt;	 
________________________________
>From Gerry Houlder (Sat 4/22/2006 10:46 PM):
A discussion with the full T10 membership is welcome, including on the
T10 reflector.
I still believe that if a security protocol action is tightly associated
with the action of a particular LUN, then the commands should be
supported by that LUN instead of a well known LUN. If the function is a
general purpose authorization/ key distribution function (where the keys
are subsequently used to gain access to someting else) then a well known
LUN is appropriate. The only exception I can think of right now is a
RAID controller that might use a well known LUN as a proxy for the
entire string of drives that are virtualized behind it.
I believe that folks will design security protocols so that they
implicitly prevent interference for other initiators when a critical
security function is being performed. They protocols should be designed
to prevent interference from other applications in the same host, which
will look like the same initiator ID. In the enterprise environment, it
is normal for multiple users (which may have different security rights)
to access the same storage subsystem through the same access point
(i.e., initiator ID).
This is much better protection than reservations can offer, and may be
the only way to prevent two "properly authorized" users from treading on
each other.
In T10 we have always had the situation where two "non-cooperating"
initiators can frustrate each other's actions in setting mode pages,
resetting devices, etc. The real answer to this is that multi-initiator
systems must provide some communication method between users to
coordinate such things. The security commands are no worse off in this
regard, but can be better if more protection is designed into the
underlying security protocols to prevent the kind of interference you
are concerned about.
________________________________
From: Avraham Shimor (Sat 4/22/2006 12:21 AM):
I totally agree with your observations, but...
I was considering the SCSI reservation mechanism not in the context of
avoiding unauthorized access, but rather in the context of mutual
exclusion, i.e. to avoid a situation for example where two properly
authorized user are connected to a device, from two distinct initiator
ports, and where one of these users, exercising his authority causes a
change which might adversly affect other users simultaneously connected,
like locking the device, or changing the encryption key, etc. The
reservation method could be used to avoid these situations by providing
an application-independent, and security protocol independent, generic
mechanism to detect whether other initiators/users are currently
connected which are in a "critical section" of their device use, so that
"this" application cannot inflict a critical change; or vice versa,
"this" application can avoid/block others to access/use/read/write the
device while a significant change is effected.
I repeat: the importance and usefulness of the reservation mechanism
stems from its application and security protocol independence and
generality.
Does this make more sense to you now ? Should we open up this discussion
to the general membership of T10 ?
________________________________
From: Gerry Houlder ( Fri 4/21/2006 11:42 PM ):
I don't pretend to know all of the reasons why a well known LUN would be
used, but I have these opinions:
(1) A well known LUN is well suited to do authentication and key
generation functions, or other security related functions that might use
a central appliance to service requests for an entire domain or network.
For these functions, the "protection against unauthorized use" is
contained within the protocols of those functions (if they are properly
designed) and don't need to rely on reservations to keep out the
unauthorized users. I don't think it is suited for directly controlling
encryption function for another device or an entire group of devices,
however.
(2) There isn't any user data within that LUN (i.e., no read or write
commands) so there is no reason to protect any user data (the usual
reason for reservations).
(3) None of the other well known LUNs support reservations either. Some
folks think that univeral access to the LUN is a property of being "well
known". If it could be restricted, then it isn't well known any more.
(4) When an encryption engine is contained within a device (e.g., disk
or
tape) there may be reason to keep an unauthorized user from changing
settings (e.g., password or key) while the device is being accessed.
Reservation is used to prevent an unauthorized user from reading or
writing any data unless it is a member of the reservation group. The
Tape group devised a protocol that allows any user to change the key
without having to prove it is authorized to do so, so reservations are
needed to add similar protection for this case. Such tampering may not
allow the unauthorized user to access any data but could prevent an
authorized user from getting such data if it wasn't aware of the
tampering. Its not as good as requiring full authentication for such a
change, but the group felt they didn't need the extra security that the
authentication would provide. The trade-off is that they have a simpler
protocol. I think this illustrates why device level encryption should be
controlled within the same LUN as the encryption engine, not some other
LUN, unless you require full authentication before critical changes are
allowed.
________________________________
From: Avraham Shimor (Fri 4/21/2006 8:39 PM):
In the current revision of SPC-4, in para. 8.5 it is stated that "The
SECURITY PROTOCOL well known logical unit shall only process the
commands listed in table 401."
Now, since table 401 does not list PERSISTENT RESERVE IN/OUT, it is
evident that persistent reservation cannot be applied to the SECURITY
PROTOCOL well known logical unit. Of course, this is different from the
use of SECURITY PROTOCOL commands on regular LUNs, where persistent
reservation can be applied (see table 31, part 3 of SPC-4).
My feeling is that the SECURITY PROTOCOL well known logical unit might
be very useful to exercise the SECURITY PROTOCOL commands to affect the
complete device as a whole, versus affecting a single LUN by exercising
the SECURITY PROTOCOL commands on that specific LUN. It seems to me,
that the use of persistent reservation, coupled with SECURITY PROTOCOL
commands, is a very useful and important feature to avoid
conflicting/contradicting/ambgous setting in a multi initiator
environment, not only in relation to a specific regular LUN, but also
for the SECURITY PROTOCOL well known LUN.
I am interested to hear your opinion: what is the reason to exclude the
use PERSISTENT RESERVE IN/OUT from the SECURITY PROTOCOL well known LUN
?



More information about the T10 mailing list