|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] RE: ISCSI: CmdSN in non-leading loginFrom Julian's re-write, it seems that login requests would just carry the current CmdSN. For a non-leading login, it would follow that the CmdSN can increase if there are other non-immediate commands in progress in the session. The leading login's CmdSN would not increase because it would be impossible to have any commands in progress. For the leading login, there is a special case where the CmdSN is used as the first ExpCmdSN. That way, nothing gets "stuck" and I see very clean implementation. Eddy -----Original Message----- From: Bill Studenmund [mailto:wrstuden@wasabisystems.com] Sent: Monday, May 13, 2002 1:57 PM To: Julian Satran Cc: John Hufferd; ips@ece.cmu.edu; Mark S. Edwards; 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
Home Last updated: Mon May 13 18:18:34 2002 10106 messages in chronological order |