Re: iSCSI MIB - comments on iscsiAccessList

[Mark Bakke <mbakke@cisco.com>]

Keith McCloghrie wrote:
> 
> 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

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

> 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 ?

Yes.  That is correct.

> >    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 ?

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.


> > 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.

OK.

> > ...
> >
> > 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.

"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.

> 
> 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.)

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.

> 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.

-- 
Mark A. Bakke
Cisco Systems
mbakke@cisco.com
763.398.1054