Subject: Suggested discussion topic: Persistent reservation for the SECURITY PROTOCOL well known LUN Date: Tue, 25 Apr 2006 22:52:23 +0300 From: "Avraham Shimor" <Avraham.Shimor@m-systems.com> To: "T10 Reflector" <t10@t10.org> X-Message-Number: 6842 Formatted message: HTML-formatted message 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@m-systems.com <mailto:avraham.shimor@m-systems.com> www.m-systems.com <http://www.m-systems.com/>; ________________________________ >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 ?