RE: Task Management Commands

[julian_satran@il.ibm.com]

Robert,

That was the easy way out (and I said so in the past too).
Provided with enough access control you can limit the target reset to
authorized initiators and then only for the group of LUs they are
authorized to.
Removing it completely removes the ability to do the operation atomically.

Julo

"Elliott, Robert" <Robert.Elliott@compaq.com> on 09/03/2001 08:15:12

Please respond to "Elliott, Robert" <Robert.Elliott@compaq.com>

To:   John Hufferd/San Jose/IBM@IBMUS, Julian Satran/Haifa/IBM@IBMIL
cc:   George Penokie <gpenokie@tivoli.com>, "'ENDL_TX@computer.org'"
      <ENDL_TX@computer.org>, Jim Hafner/Almaden/IBM@IBMUS
Subject:  RE: Task Management Commands




Today, T10 approved 01-015r2.  For devices compliant with SAM-2 revision
16,
Logical Unit Reset is now mandatory and Target Reset is not.  Protocols are
allowed to mandate Target Reset, make it optional, or not support it at
all.

In response, the SCSI RDMA protocol working group (defining SCSI over
InfiniBand) voted to remove Target Reset support from that protocol.  See
T10 document 01-108r0 for the (short) proposal.

I recommend you do the same and remove both Target Warm Reset and Target
Cold Reset task management functions from iSCSI.

Other IP protocols don't offer similar resets - a web browser doesn't have
a
way to reset an http server, a NFS client cannot reset an NFS server, a
telnet user cannot interfere with other telnet users.  iSCSI shouldn't be
any different.

John's email mentioned 4 task management functions, which included Logical
Unit Reset, and Clear Task Set.  The Access Controls feature (by Jim
Hafner;
going into SPC-3 revision 1) can be used to prevent initiators from logging
in and issuing Logical Unit Reset and Clear Task Set.  It is not a
cryptographically secure protocol, but will prevent accidents from software
that doesn't know it is not supposed to access a logical unit.  Many
environments using iSCSI will want true authentication to be integrated
with
Access Controls.  The general support for iSCSI authentication might cover
this, or an Access Control-specific secure authentication might be needed.
I think Access Controls was architected with that possibility in mind.

---
Robert.Elliott@compaq.com
Compaq Server Storage

> -----Original Message-----
> From: Ralph Weber [mailto:ralphoweber@compuserve.com]
> Sent: Tuesday, March 06, 2001 9:28 PM
> To: John Hufferd
> Cc: Elliott, Robert; George Penokie; Julian Satran
> Subject: Re: Task Management Commands
>
>
> John, Julian,
>
> Please review
>
>  ftp://ftp.t10.org/t10/document.01/01-015r1.pdf
>
> If there are difficulties with the proposal, please contact
> the author,
> Rob Elliott whose e-mail address appears as a CC to this message.
>
> (Rob, thanks for taking on this task.)
>
> Best Wishes to All
>
> Ralph...
>
> John Hufferd wrote:
>
> >
> >
> > Ralph, George,
> > The SCSI Task Management Commands, can impact other
> initiators, and in some
> > cases shuts down the other initiators, and the Target.  I
> think that, since
> > this protocol can be issued from anyplace (now with iSCSI)
> in the Internet,
> > there is a Risk that some Users Systems might send a Target
> Cold Reset, for
> > example, either on purpose, or by accident.  This seems to
> be to be a very
> > large hole.  Basicly it is a SCSI issue, even if it is the
> iSCSI  protocol
> > that brings the possibility of this to the "great
> unwashed".   When we
> > build our Very Large Systems this seems to be a problem.
> >
> > Julian Satran, thought this was a T10 issue, and that you
> folks could help
> > push it through there.
> >
> > .
> > .
> > .
> > John L. Hufferd
> > Senior Technical Staff Member (STSM)
> > IBM/SSG San Jose Ca
> > (408) 256-0403, Tie: 276-0403,  eFax: (408) 904-4688
> > Internet address: hufferd@us.ibm.com
> >
> > Julian Satran@IBMIL
> > 03/02/2001 09:27 PM
> >
> > To:   John Hufferd/San Jose/IBM@IBMUS@IBMDE
> > cc:
> > From: Julian Satran/Haifa/IBM@Haifa/IBM@IBMIL
> > Subject:  Re: Task Management Commands  (Document link:
> John Hufferd)
> >
> > As you might recall we discussed it several times and even
> attempted to
> > play with
> > separate channels.  Every solution we could think of
> affected badly the
> > good guys.
> > I think that the best place to handle it is authorization
> (T10).   They
> > have already limited the damage
> > to resetting in fact only things that come from the
> initiator that issued
> > the reset.
> >
> > We have introduced the cold reset (drop all connections).  We could
> > specifically (or vendor specific)
> > restrict that command to trusted entities with strict
> authentication.
> >
> > I think that we could (should?) standardize an error code
> that will tell
> > the initiator
> > "not authorized" but even this can be viewed as T10 turf.
> >
> > It would be a good idea to forward this exchange to George
> Penokie and/or
> > Ralph Weber.
> > They have been helpful.
> >
> > Regards,
> > Julo
> >
> > John Hufferd@IBMUS
> > 02/03/2001 02:22
> >
> > To:   Julian Satran/Haifa/IBM@IBMIL@IBMDE
> > cc:
> > From: John Hufferd/San Jose/IBM@IBMUS
> > Subject:  Task Management Commands
> >
> > Julian,
> > I got to thinking about the Task Management Commands, and
> every thing
> > dealing with functions 4-7, impacts other initiators, and
> in some cases
> > shuts down the other initiators, and the Target.  I think
> that, since this
> > protocol can be issued from anyplace in the Internet, there
> is a Risk that
> > some Users Systems might send a Target Cold Reset, for
> example, either on
> > purpose, or by accident.  This seems to be to be a very
> large hole. I know
> > it is a SCSI issue, but it is our protocol that brings the
> possibility of
> > this to the "great unwashed".   When we build our Very
> Large Systems this
> > seems to be a problem.  What do you think we should do
> about this, both
> > from the Standards side and from the Product side?
> >
> > .
> > .
> > .
> > John L. Hufferd
> > Senior Technical Staff Member (STSM)
> > IBM/SSG San Jose Ca
> > (408) 256-0403, Tie: 276-0403,  eFax: (408) 904-4688
> > Internet address: hufferd@us.ibm.com
>