Subject: ISCSI: CmdSN in non-leading login

From: "Mark S. Edwards" <[email-masked]>
Date: Fri, 10 May 2002 10:51:56 +0100

I am looking for clarification with regard the value that an initiator 
should put in the CmdSN field of a login request for a non-leading connection.

There is a certain ambiguity about 9.12.8.  The text describes how in a 
leading connection, the target takes must accept and use a non-zero CmdSN, 
but it does not explain what should be present for a non-leading connection.

There are a couple of problems here for the target.  At what point is a 
non-leading connection considered to be part of the session ?  Is it the 
moment that the login request is received with a non-zero TSIH ?  Or is it 
only when the non-leading login succeeds and it enters full feature phase ?

So, should an initiator set the CmdSN in the first login request to zero 
and only synchronise with the session command stream after full feature 
phase is established ?  This is my preferred option.

What happens if the initiator tries using the current session command 
sequence number is that whilst the login negotiation occurs, other 
connections within the session can be issuing new commands, so by the time 
that the login is finished the CmdSN exchanged in the initial request is 
invalid anyway.

I would like to see something along the lines that for a non-leading 
connection, the CmdSN field MUST be zero and that the connection can not be 
considered part of the session until full feature phase is entered, at 
which point any commands issued on the connection are now synchronised with 
the session command sequence number as observed by all other existing 
connections on the session.

regards,

Mark.

---

From: Bill Studenmund <[email-masked]>
Date: Fri, 10 May 2002 09:13:40 -0700 (PDT)

> only when the non-leading login succeeds and it enters full feature phase ?

I think the target shouldn't let anything from a new connection influence
things until after at least the security phase has been passed. Otherwise
we have a security hole. After operational negotiation would probably be
best.

> connections on the session.

I thought login counted as a command, so it got its own command number, in
the stream of all other commands. ??

Take care,

Bill

---

From: "Mark S. Edwards" <[email-masked]>
Date: Fri, 10 May 2002 17:47:53 +0100

>we have a security hole. After operational negotiation would probably be

Good, as far as I can see, a new connection should not be allowed to 
influence any session context until the connection reached full-feature 
phase.  But this is a problem if we have to follow the CmdSN rules of 
9.12.8.   See next comment.

>the stream of all other commands. ??

For a leading connection the CmdSN, whether zero or non-zero, is regarded 
as a primer with which to set the initial session command sequence number, 
all the login requests exchanged in the negotiation, no matter how many 
carry the same CmdSN as does the first non-immediate command.  In other 
words, the first pdu in a leading connection does influence session state.

So if we agree that a non-leading connection can not influence session 
state until full-feature phase, then we have to also state that the rule in 
9.12.8 about the first non-immediate command carrying the same CmdSN as the 
initial login request can not work for a non-leading connection.  In this 
case, the first non-immediate command must be set from the next logical 
value in the session context.  I would like the spec to have this added and 
to explicitly say that the CmdSN in a login request for a non-leading 
connection is ignored by the target.  I'd really prefer that the actual 
value be zero, but that's not necessary from a protocol perspective if the 
target ignores the field.

Mark.