|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] RE: iSCSI: reusing ISID for recoverySteph, 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 |