SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


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

    RE: iSCSI: reusing ISID for recovery



    Steph,
    
    This is a long thread, almost as long as the thread "iSCSI: response to
    second login (with same ISID)" we had a few months ago. One aspect from the
    other thread that may not have been mentioned is the fact that you could
    have a situation where a rogue software on the initiator running in user
    mode which simply issues ISID=existing, TSID=0 to the target. (This may be
    what was meant by "wild closing of connections" in this thread.) Choosing
    option A) would destroy an otherwise well protected ISID managed in the
    kernel space. This could also occur when you accidentally start another
    application that does not coordinate its ISID selection.
    
    The earlier thread was leaning towards "Reject the second login attempt with
    In-Use error code" but the issue of targets cleaning up inactive and failed
    sessions still lingers on.
    
    Some observations:
    
    1. There is no way to protect against rogue software at the intiator; even
    the best IPSec policies and key management can not prevent such software
    from disturbing other well-behaved components. So trying to design
    mechanisms to prevent this at the target would be fruitless.
    
    2. There is some value in protecting an accidental use of an existing ISID
    by a second client (ISID=<existing>, TSID=0). This can be done with a Reject
    of the login attempt, even without verification of login credentials - (less
    of a DOS attack). You also do not need to analyze connection states in this
    case.
    
    3. From the perspective of the Target, case 2) above is no different from an
    initiator rebooting and accidentally choosing an existing ISID with TSID=0.
    To distinguish 2) from 3), we can make use of the Clear bit (or the C-bit)
    and avoid many unnecessary trips at reboot time, trying to probe for an
    unused ISID. The usage is that if C-bit is present, any previous sessions
    are also closed by the target. I think this was Option B) in the original
    email.
    
    4. If initiators always set the C-bit, then they can't benefit from the
    duplicate session identification capability of 2). It is a bad initiator in
    that it doesn't respect the presence of other sessions at the initiator
    system, but the protocol can't bloat handling these cases of bad initiators.
    
    5. If an initiator only implements mandatory session recovery, it can help a
    target recover faster by explicitly logging out the previous session and use
    same or different ISID with TSID=0 and an C-bit to really ensure that it can
    recover on a new session. This is a fast operation because we are not
    waiting for lengthy round trips or timeouts, and the presence of the C-bit
    makes the intent clear to the target that it must wipe off the existing
    session. The perceived delay noted in Option C) does not arise.
    
    6. If a target determines that all connections in a session are dead (TCP
    keepalives can help here), and there is no activity on a session, it can
    simply close the session and release the ISID and the TSID and recover
    target side resources. This is not driven be explicit protocol action from
    initiator, but simply target timer based, and is designed for initiators
    that disappear without cleanup of sessions and don't reappear (no reboot for
    a long time).
    
    With this limited understanding, my preference would be Option B). One could
    argue that B) offers protection only against an accidental use of the same
    ISID, but if (as was pointed out earlier and in the other thread by Nick),
    there are multiple ways in which iSCSI applications are packaged, so that
    there is no shared visibility into ISID space, the protection offered by B)
    can be useful.
    
    Venkat Rangan
    Rhapsody Networks Inc.
    http://www.rhapsodynetworks.com
    
    
    -----Original Message-----
    From: Stephen Bailey [mailto:steph@cs.uchicago.edu]
    Sent: Wednesday, August 29, 2001 1:53 PM
    To: Santosh Rao
    Cc: ips@ece.cmu.edu
    Subject: Re: iSCSI: reusing ISID for recovery 
    
    
    > The same was earlier proposed by myself in a previous thread on this
    > issue a few months ago.
    
    You're not the only one.  I'm also in favor of (A).  I have also
    carefully laid out the chain that Marjorie's following on at least one
    (and probably several) past occasions.  It seems sound to me.  An
    initiator that has lost its mind (this might be an OS reboot, or
    `simply' a fat adapter crash & restart) is going to want to stomp out
    any existing sessions in its name.  It's not going to want to pick up
    old context unless it's aware that there IS old context, in which case
    it hasn't completely lost its mind.
    
    I've been keeping my mouth shut in hopes that it would actually pass,
    but I guess I don't have to articulate a position so much as just hold
    it to ensure it gets killed.  Given my track record, I'm now for sale
    to the highest bidder.
    
    Steph
    


Home

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