Re: ISCSI: CmdSN in non-leading login

["John Hufferd" <hufferd@us.ibm.com>]

Sure, you can send a 1002 command, just deliver the 1001 non-immediate
command, then you have room for 1002, deliver it, and go to 1003 etc.
Other connections will operate just as they normally do, when another
connection is NOT in the process of being logged in.  I think Julian's new
wordage make this more clear.

.
.
.
John L. Hufferd
Senior Technical Staff Member (STSM)
IBM/SSG San Jose Ca
Main Office (408) 256-0403, Tie: 276-0403,  eFax: (408) 904-4688
Home Office (408) 997-6136, Cell: (408) 499-9702
Internet address: hufferd@us.ibm.com


Bill Studenmund <wrstuden@wasabisystems.com> on 05/13/2002 10:57:02 AM

To:    Julian Satran/Haifa/IBM@IBMIL
cc:    John Hufferd/San Jose/IBM@IBMUS, <ips@ece.cmu.edu>, "Mark S.
       Edwards" <marke@muttsnuts.com>, <owner-ips@ece.cmu.edu>
Subject:    Re: ISCSI: CmdSN in non-leading login



On Sun, 12 May 2002, Julian Satran wrote:

> John,
>
> My only point was that there is enough information in the section to
> describe correct behavior.

> And immediate commands do not create any blockage regardless of their
> CmdSN.

Don't they though? Say I have a queue depth of 2, and I start a secondary
login with a CmdSN of 1000. I can then send other immediate commands at
1000, and a non-immediate command at 1000. I can then also send a
non-immeidate command at 1001. But can I send a command at 1002 before the
login has finished? If we increase the queue depth, there will still be
some other command number that would overflow it.

Say the login takes a while. Won't the login pin the queue at 1002 until
it's done? Now let the login take a while, it requires talking to say a
low kerberos server or doing a DH computation. If we really pay attention
to CmdSN, then the slow login process can effectively take the device
off-line while it completes, since we can't enqueue new commands.

Worse yet, say the secondary connection is NOT from our initiator, but
from an imposter. All the rogue has to do is get the TSIH right & guess a
CmdSN, and stall at trying to add another connection. Say do leading
negotiation, but just never send any security negotiations. The queue will
eventually become pinned until the target times out. Nice little DOS
attack; all you have to do is get the TSIH right & guess a CmdSN. You
don't have to do any security negotiation.  :-)

I'd like to suggest that we just ignore CmdSN on non-leading sessions,
beyond the fact that a well-behaved initiator should pick a CmdSN in its
current command window. We certainly shouldn't pay attention to it before
security negotiations have completed. :-) Oh also no commands should be
sent over the new connection with a CmdSN lower than the one used in the
new connection.

Take care,

Bill