Subject: iSCSI MIB - comments on iscsiAccessList

From: Keith McCloghrie <[email-masked]>
Date: Thu, 1 Nov 2001 09:16:18 -0800 (PST)

I have some questions/suggestions regarding iscsiAccessList
in draft-ietf-ips-iscsi-mib-03.txt.
 
> 6.9.  iscsiAccessList
> 
>    The iscsiAccessListAttributesTable contains an entry for each
>    initiator that is allowed to access the target under which it
>    appears.  If a target allows access to any initiator, an
>    AccessListAttributesEntry with the initiator's iSCSI name should be
>    used.

I think the last sentence is 

a) confusing (do you mean "any initiator" ?) and 
b) may not always be true - with a wildcard mechanism ("iscsi" in the next
   paragaph), an initiator's name does not have to be in the table, right ?

>    This table does not cover all possible access control schemes that a
>    vendor could implement.  If access to an initiator cannot be
>    determined just by its iSCSI name, an implementation may either
>    include a single entry per target with the initiator name "iscsi", or
>    may choose to place no entries in this table.
 
Does no entries in the table allow any initiator access, or does it
deny access to all initiators ?

> iscsiAccessListAttributesTable OBJECT-TYPE
>     SYNTAX        SEQUENCE OF IscsiAccessListAttributesEntry
>     MAX-ACCESS    not-accessible
>     STATUS        current
>     DESCRIPTION
>         "A list of iSCSI initiators which will be granted access
>         to iSCSI resources through targets within the iSCSI
>         instance."

Can you say explicitly:

- what does no entries in the table mean, and
- how does the wildcard entry (an entry with name="iscsi") work. 

> ...
> 
> iscsiALInitiatorName OBJECT-TYPE
>     SYNTAX        SnmpAdminString
>     MAX-ACCESS    read-only
>     STATUS        current
>     DESCRIPTION
>         "An octet string that defines an initiator identified
>      by the <InitiatorName> key of the Login Command which will
>      be granted access. If this string has the value of 'iscsi',
>      then any initiator may access this target."
> ::= { iscsiAccessListAttributesEntry 2 }
 
If you intend that an entry of "iscsi" means that "any initiator
name is allowed", then I think it's a little strange that a special
meaning applies to a name that an administrator might just happen to
use without realising it.

Here are three alternatives which I think are better:

1. have a column in the iscsiTargetAttributesTable which enables/disables
   the use of the access-list.  (Then, disabling has the same function as
   "icsci" entry.)

2. have the zero-length name allow access to any name; (this is a special
   case of #3 below.)

3. have an additional column, iscsiALInitiatorMatchType, which is an
   INTEGER { exact(1), prefix(2) } where 'exact' is the type you currently
   have, and 'prefix' says that longer initiator names will match
   if they can be truncated to the value of iscsiALInitiatorName.

Keith.

---

From: Mark Bakke <[email-masked]>
Date: Thu, 01 Nov 2001 12:05:02 -0600

> a) confusing (do you mean "any initiator" ?) and

No.  I meant "any particular initiator"; this was badly worded.

>    paragaph), an initiator's name does not have to be in the table, right ?

Yes.  That is correct.

> deny access to all initiators ?

I think that we need to decide that here.  It was originally intended
to mean that all initiators are allowed, but since we have a way to
say that by putting in "iscsi", I think that it should mean either that
all initiators are denied, or that the access list mechanism in the
MIB is not enough to determine whether or not an initiator will
be granted access.  I would tend toward the latter; if there are no
access list entries for a target, it means that there is not enough
information to tell who gets to access it from this MIB.  Implementations
that provide value-add access control can augment this MIB with their
own enterprise MIBs for access control.

I would like to re-word this to:

   ... The value "iscsi" in an access list entry means that any
   initiator may access this target.  If a target has no entries
   in the access list attributes table, it means that there is
   not enough information here to determine whether or not an
   initiator will be granted access.

> - how does the wildcard entry (an entry with name="iscsi") work.

OK.

> use without realising it.

"iscsi" is a reserved initiator name value, and must not be assigned
to an initiator or target by an adminstrator or manufacturer.  There
should be no problems with using it here.

>    the use of the access-list.  (Then, disabling has the same function as

This is probably the cleanest; an implementation that does not do
access lists would not have to implement the access list part of
the MIB at all.

-- 
Mark A. Bakke
Cisco Systems
[email-masked]
763.398.1054

---

From: Keith McCloghrie <[email-masked]>
Date: Thu, 1 Nov 2001 10:22:58 -0800 (PST)

> No.  I meant "any particular initiator"; this was badly worded.

How about also changing "with the initiator's iSCSI name" to
"with that initiator's iSCSI name".

OK.

OK.

Thanks,
Keith.

---

From: "Mark A. Carlson" <[email-masked]>
Date: Thu, 01 Nov 2001 11:54:58 -0700

...
>    initiator will be granted access.

But isn't the fact that the iSCSI name is used, as part of what access
control is based on, useful to applications? For example, if I use a
combination of iSCSI name and host userid to determine access, I would
still like to know that *some* access is available from this initiator
so that I can relate this logical relationship (maybe draw a graph).

How about a field that indicates "additional information required" rather
than leaving the whole entry blank? (empty really should mean no access,
rather than no standard access, and we need to differentiate these two).

Even if a vendor extends iscsiAccessList for their own access control, at 
least the standard properties could be supported so that applications
can see that access is allowed from somewhere.

Having iscsiALInitiatorName = iscsi, and "additional information" = true,
would indicate that the proprietary access control mechanism needs to be 
consulted to understand who has access, but at least there is some access
allowed.

-- mark