SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


    [Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

    Re: iSCSI: Status'es (clause 2.11.6)



    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
    
    
    
    
    
    


Home

Last updated: Tue Sep 04 01:04:12 2001
6315 messages in chronological order