Re: ISCSI: CmdSN in non-leading login

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

I do not see the issue, it works as is, it does not effect the first non
immediate command unless it completes as a authorized connection. Again, I
do not see the issue, in fact it works as is.

.
.
.
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


"Mark S. Edwards" <marke@muttsnuts.com>@ece.cmu.edu on 05/10/2002 09:47:53
AM

Sent by:    owner-ips@ece.cmu.edu


To:    Bill Studenmund <wrstuden@wasabisystems.com>
cc:    <ips@ece.cmu.edu>
Subject:    Re: ISCSI: CmdSN in non-leading login



At 09:13 AM 5/10/2002 -0700, Bill Studenmund wrote:
>On Fri, 10 May 2002, Mark S. Edwards wrote:
>
> > 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 ?
>
>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.

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.


> > 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.
>
>I thought login counted as a command, so it got its own command number, in
>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.