Re: iSCSI: Status'es (clause 2.11.6)

[Mark Bakke <mbakke@cisco.com>]

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