Subject: iSCSI: Status'es (clause 2.11.6)

From: "Jim Hafner" <[email-masked]>
Date: Tue, 24 Jul 2001 11:07:30 -0700

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.

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.

"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 need to clarify the "Session already open" to include language that says
"with this initiator to this target portal group".

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.

Jim Hafner

---

From: Mark Bakke <[email-masked]>
Date: Wed, 25 Jul 2001 10:53:23 -0500

Jim-

Comments are below.

--
Mark

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

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.

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

> n=10.   So, I'd suggest that "insufficient resources" is a better catch-all

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.

> "with this initiator to this target portal group".

Agree.

> Normal session type and is not true for the Discovery session type.  This

Agree here, too.

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