Re: iSCSI: Status'es (clause 2.11.6)

[Mark Bakke <mbakke@cisco.com>]

I have not seen any responses other than from Julian and
Jim on the status codes, so I assume that we can go ahead
and make these modifications.

I had proposed five 030x status codes before; Julian was
concerned that these were getting to be too fine-grained,
and I think he's right.  I plan to change the 030x status
codes to:

0300 - Target Error - Target hardware or software error

0301 - Unavailable - The target is not operational

We can keep 0302 the way it is, and delete the 0303, 0304,
and 0305 I had added below.

--
Mark


Mark Bakke wrote:
> 
> Jim and I talked on the phone about this, and here's pretty
> much what we came up with for status code changes.
> 
> After thinking about the Proxy Required message, I agree that
> we no longer need it.  Since all iSCSI targets have unique
> names, which are not tied to addresses as in HTTP, the client
> does not need to be aware of a proxy for it to work.
> 
> Also, since the main definition of the 030X codes is "my bad"
> from the target's point of view, and 020X is "your bad", this
> means that login requests causing an 030X should be re-tryable
> by the initiator at some point in the future, and that 020X
> requests won't get anywhere if they keep trying.  This caused
> us to want to move a few status codes around.
> 
> So here are some proposed changes to the iSCSI status codes
> that should clean things up:
> 
> In the status class definitions, add the following sentence
> to "2 - Initiator error":
> 
>   The request should not be tried again as-is.
> 
> And change "3 - Target Error" to:
> 
>   indicates that the target sees no errors in the initiator's
>   login request, but is currently incapable of fulfilling the
>   requesst.  The client may re-try the same login request at
>   a later time.
> 
> Remove code 0103 "Proxy Required".
> 
> Rename 0201 "Security Negotiation Failed" to "Authentication Failure".
> 
>   Change its description to:
> 
>   The initiator could not be successfully authenticated by the target.
> 
> Rename 0202 "Forbidden Target" to "Authorization Failure".
> 
>   Change its description to:
> 
>   The initiator was authenticated, but is not authorized to access
>   the target.
> 
> Remove 0205 "Target Conflict".
> 
>   This one had specified that the target would not accept another
>   connection, but since this may be a temporary and re-tryable
>   condition, it should really belong in the 0300s.
> 
> Move 0302 "Unsupported Version" to 0205, since this is not a login
> request that the client has any hope of re-trying, so it belongs
> in the 0200s.
> 
> Add new 030X codes to be somewhat more precise as to the reason
> the target might be unavailable.
> 
> 0300 - Target Error - Miscellaneous target error
> 
> 0301 - Service Unavailable - The current target is not operational.
> 
> 0302 - Out of Resources - The target currently has insufficient
> connection or session resources.
> 
> 0303 - Not Ready - The target is not yet ready to accept connections.
> 
> 0304 - Software Failure - The target has experienced a software
> failure.
> 
> 0305 - Hardware Failure - The target has experienced a hardware
> failure.
> 
> Note that none of the 030X status codes should require different
> treatment; they are mainly broken out to allow the client to
> complain more precisely to its user or administrator.
> 
> --
> Mark
> 
> Jim Hafner wrote:
> >
> > Mark,
> >
> > Comments in line.  But for closure on some things and to tagged the still
> > open issues, I'll summarize my comments.
> >
> > There are three independent issues (and a few minor ones I'll skip):
> > 1) Proxy Required - I think this is just a placeholder and need not be
> > there -- save it for generation 2 (still open).
> > 2) Security Negotiation Failed and Forbidden Target - thanks for the
> > clarification, I think I like the name changes (closed)
> > 3) Target Conflict - what about "n->n+1" -- we have no status code for
> > that.  I suggest alternate names for this and that it cover not just the
> > 1->2 problem but the n->n+1 (still open).
> >
> > All other issues are agreed.
> >
> > Jim Hafner
> >
> > Mark Bakke <mbakke@cisco.com>@ece.cmu.edu on 07-25-2001 08:53:23 AM
> >
> > Sent by:  owner-ips@ece.cmu.edu
> >
> > To:   Jim Hafner/Almaden/IBM@IBMUS
> > cc:   ips@ece.cmu.edu
> > Subject:  Re: iSCSI: Status'es (clause 2.11.6)
> >
> > Jim-
> >
> > Comments are below.
> >
> > --
> > Mark
> >
> > Jim Hafner wrote:
> > >
> > > Folks,
> > >
> > > I have some questions, recommendations and editorial comments about the
> > > status codes for iSCSI in clause 2.11.6.
> > >
> > > Proxy Required is defined as the response when "the initiator must use an
> > > ISCSI proxy for this target".  But that isn't defined anywhere in the
> > > document, so I recommend deleting this status code.
> >
> > We should define this, then.  If a target is accessible only through
> > an iSCSI proxy, perhaps for security purposes, an initiator attempting
> > to log in to it directly should get an error.  If the target is aware
> > of the proxy, it can return the proxy's address in this type of redirect
> > response.  This is similar to what was done in HTTP/1.1.
> > <JLH>
> > If the target is aware of this (undefined) thing, then a simple redirect
> > would suffice and we don't need the status code.  If the target is not
> > aware, then how can it know to return this status code?   Does it just know
> > that there should be one but doesn't know the address?  How can it know
> > whether to accept the login from any old initiator vs the initiator that
> > lives in the proxy?  It will be configured (I assume) to allow login by the
> > proxy and reject all other logins.  It doesn't really help the initiator to
> > get back "can't login in here, use a proxy but it's up to you (the
> > initiator) to find the right address".
> >
> > Until we define this, I strongly suggest we take it out the status code --
> > it adds no value to the protocol.  We can't have placeholders for things
> > that are undefined (except perhaps reserved values or keywords).   You
> > clearly have an idea in your mind of what an iSCSI Proxy is, but I searched
> > for "proxy" in the document and the ONLY occurrances are in this clause.
> >
> > My suggestion then is (a) take it out for now (and reserve the code value)
> > and (b) table the whole definition/description/model, etc for an iSCSI
> > proxy is to "iSCSI-the sequel".   I expect that this will be a complex
> > issue (as I've hinted at above), and I don't want it to delay this draft.
> > </JLH>
> >
> > Although this status code likely won't be used right away, it does
> > have utility long-term when we start building larger storage networks
> > with this stuff.  I still don't believe that all iSCSI devices will
> > provide all of their own security code; other devices may have to
> > provide this on their behalf, which was why we had added iSCSI proxy
> > capabilities in the first place.
> > <JLH>
> > This is yet to be proven and in the meantime, we don't need the
> > placeholder.
> > </JLH>
> >
> > > What's the functional difference between the following: "Security
> > > negotiation failed" and "Forbidden Target"?  In both cases, the initiator
> > > doesn't get to use what it thinks is there.  I would think that
> > "Forbidden
> > > Target" might be a security leak as it admits the fact that the target is
> > > there, whereas if the initiator only got back failed security, that
> > > admission wouldn't be made.
> >
> > Security Negotiation Failed means that the initiator could not
> > be successfully authenticated.
> >
> > Forbidden Target means that the initiator was authenticated, but
> > is not authorized to access the target.
> >
> > These are two different reasons for an initiator not to be able
> > to get to a target, and would more useful to someone configuring
> > an initiator than simply returning "not found".
> >
> > Keep in mind that when returning Forbidden Target, the initiator
> > has been authenticated, so it's likely to be somewhere within
> > the realm of things that the target trusts.  If the target wants
> > to be more tight-lipped about this one, it could certainly return
> > "Not Found" instead.  This adds a bit more security at the expense
> > of making it easier to troubleshoot a mis-configured initiator.
> >
> > The names for these two status codes are perhaps a bit clumsy; perhaps
> > renaming them will help.  How about:
> >
> > Authentication Failure instead of Security Negotiation Failed
> >
> > and
> >
> > Authorization Failure instead of Forbidden Target?
> >
> > <JLH>
> > Thanks for the explanation.  I can live with this; the alternative wording
> > might be more clear.
> > </JLH>
> >
> > > "Target Conflict" and "Service Unavailable" both look more like
> > > "insufficient resources".  In particular, "Target Conflict" should not be
> > > limited to a response in the 1->2 or more initiators case but in the
> > n->n+1
> > > initiators case.  That is, if the target has resources for 'n' logins, it
> > > can reject another login with "insufficient resources", whether n=1 or
> > > n=10.   So, I'd suggest that "insufficient resources" is a better
> > catch-all
> > > for both of these cases.
> >
> > We had this discussion on the list a long time ago.  Target Conflict
> > is the initiator's problem; it should not be asking to connect to
> > a target that someone else is using (assuming it supports only one
> > initiator at a time).  Service Unavailable is the target's problem;
> > it is used when the target is not working at all.
> >
> > <JLH>
> > Apologies if I didn't follow or absorb all of that previous thread.
> >
> > I can see the subtle difference between Target Conflict and Service
> > Unavailable.  But what do we do if the target supports "n" logins (only)
> > and an "n+1" guy tries to login?  We have no status code for that.  I also
> > don't see how the name "Target Conflict" carries the meaning you want.  I
> > would suggest "Insufficient Login Resources" or "Target In Use" and use
> > this for anytime the target can't support an additional login (either from
> > 1 to 2 or from n to n+1).
> > </JLH>
> >
> > > We need to clarify the "Session already open" to include language that
> > says
> > > "with this initiator to this target portal group".
> >
> > Agree.
> >
> > > The sentence immediately after the table says that "accept" means the
> > > initiator may proceed to issue SCSI commands.  This is only true in a
> > > Normal session type and is not true for the Discovery session type.  This
> > > should be clarified.
> >
> > Agree here, too.
> >
> > > Jim Hafner
> >
> > --
> > Mark A. Bakke
> > Cisco Systems
> > mbakke@cisco.com
> > 763.398.1054
> 
> --
> Mark A. Bakke
> Cisco Systems
> mbakke@cisco.com
> 763.398.1054

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