Access Control points of debate - IPsec?

[hafner at almaden.ibm.com]

* From the T10 Reflector (t10 at t10.org), posted by:
* hafner at almaden.ibm.com
*


David,

Two partial responses:
1) Access Controls are really not a "secure" storage feature (in
particular, there is no encryption).  It is mainly a protocol for enabling
fairly static partitioning of resources on a large fabric with some
control over who owns the partitioning management functions.

(This discussion will go way off beyond the subject of the original
posting but it is an interesting topic)

2) There are fundamental differences between the nature of
an IP network and a SCSI interconnect (at least as I see it).
In particular, I think the layers are different.  I view TCP
over IP over ethernet as the analogue of SCSI over FCP
over FCPH.  So, your question is probably: can one leverage
IPsec in FCP? The answer is probably yes, though I haven't
really looked into it.  Of course this raises the question of
using TCP style security protocols on SCSI.  I think this is
also possible (and in some ways is contained in some of
the OSD proposal for object storage devices).
IMHO, the fundamental nature of SCSI imposes some
interesting challenges in this regard.  Namely, in TCP it's
very simple and natural to do "dialogs" with data exchanges
in both directions and state maintained during the dialog.
In SCSI this is almost impossible.  Also, in TCP (generally),
all devices are essentially equivalent.  E.g., every device
is both an initiator (requestor of service) and a target (receiver
of service request).  That is, they can each initiate a dialog
with another device.  In SCSI, the model is more restrictive.
Typically, an initiator is a host and a target is a storage
device.  Only recently have target's started to take on
a dual role as an initiator.  It's still a ways away (unless
I'm mistaken) before initiators also take on target roles.


Jim Hafner


David Ford <dford at orca.com> on 11-23-99 04:37:21 PM

To:   Jim Hafner/Almaden/IBM at IBMUS
cc:
Subject:  Re: Access Control points of debate



Hi Jim.

A comment from left field, probably on the warning track:

Have you looked at leveraging, either whole or in part, IPsec? Since it
will be pervasive, can one adapt the IPsec model to storage, or do you need
to invent another protocol for security with storage?

-- Dave

At 02:06 PM 11/23/99 -0800, you wrote:
 >
>* From the T10 Reflector (t10 at t10.org), posted by:
>* hafner at almaden.ibm.com
>*
>
>
>Greetings,
>First, thanks for Robert Elliot and Compaq for hosting the T10
>Access Controls teleconference and putting up the minutes.
>
>A couple of issues were raised in the teleconference and in
>other e-mail discussions.  Rather than me making some
>decisions, writing them into the next revision and finding
>that they don't meet the need,  I thought I'd throw out some
>strawman proposals here to see what discussion/resolution
>we can generate.
>
>1) Two related things came up in the teleconference: request
>for a simple "RESET" service action (to clear the ACL, set Manage
>ACL Key to zero, etc.), and a mechanism to override the
>Manage ACL Key (reset in the absense of the current key).
>I'd like to suggest the following to address both.  We add a RESET
>ACCESS CONTROLS service action which includes a VS bit field.
>If the VS bit field is set to zero, then the parameter list contains
>the current Manage ACL Key which must be checked.  If the
>VS bit is set to one, then any validation of the command
>happens in a VS-specific manner.  Example VS implementations
>might include:
>      a) no parameter list, no checking, simple reset
>      b) parameter list contains serial number or some public value
>      c) parameter list contains some other value requiring either
>           physical access to the device (akin to the HW password of
>           earlier drafts) or vendor servicing/maintanence software.
>      d) other...
>What this does is provide a simple API to reset with Key
>checking (VS=0) and a standardized template for implementation
>dependent reset (VS=1).
>
>2) One major change from rev1 to rev2 involved moving "access
>controls management/enforcement server" functions from LUN0
>to each logical unit independently (as that seemed to fit the SAM-2
>model much better).  This implies that there will be a Manage ACL Key
>per logical unit.  It also means that ENROLLMENT is on a per logical
>unit basis (and this implies that an initiator can use a different
AccessID
>per logical unit -- it's not how I'd implement it, but the standard can't
>require it).  This change forces more resource requirements on the
>target (and I'm getting requests to go back to the original model).
>I personally perfer this "shared" model but I don't see how the SAM-2
>model can easily adapt to this (I like to be wrong on this point).
>Alternatives to rev2:
>    a) allow shared behavior if the device reports the presence of an
>embedded controller in inquiry.
>    b) allow (somehow) implicit enrollment at other logical units if
>there is an explicit enrollment at another (shared enrollment).  This
>has some interesting consequences, however.
>    c) find some language which requires that an initiator use the same
>AccessID on all logical units of a given target (is there such language?)
>    d) change the SAM-2 model to allow for an "access control server"
>which spans logical units (IMHO, this is too much to bite off,...)
>
>Other big issues to resolve are:
>a) element level access controls (are they needed, if so, does the current
>draft provide the right functionality)
>b) proxy model (is it clear, and provide the right functionality)
>
>Comments, suggestions, questions, etc. are welcome.
>
>Jim Hafner
>
>
>*
>* For T10 Reflector information, send a message with
>* 'info t10' (no quotes) in the message body to majordomo at t10.org
<

     -----------------------------------------------------------------
     Dave Ford                                            Orca Systems
     dford at orca.com                                       77 Union St.
     617-926-1399                                 Watertown, MA. 02172




*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org