iSCSI Re: Questions on iSCSI 07

["Julian Satran" <Julian_Satran@il.ibm.com>]

Comments in text - thanks - Julo

"Lee Xing" <lxing@Crossroads.com>@ece.cmu.edu on 15-08-2001 17:27:17

Please respond to "Lee Xing" <lxing@Crossroads.com>

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


To:   <ips@ece.cmu.edu>
cc:
Subject:  Questions on iSCSI 07



Hi All,

I have a few questions on iSCSI 07.  I would appreciate it if someone
could explain them.

Thank you.


Lee Xing
Sr. Software Engineer
Crossroads Systems, Inc.

----------------------------------------------
Q1:
Page 104: "Operational parameters MAY be negotiated outside (after) the
login phase."
Page 157: "Some session specific parameters MUST be carried only on the
leading connection and cannot be changed after the leading connection
login..."

If operational parameters are considered as session parameters, then
should we reword the sentence on page 104, such as "Some operational
parameters MAY be negotiated outside (after) the login phase."?


+++ will fix +++
----------------------------------------------
Q2:
Page 22: "Any PDU except login and text, which is sent on a TCP
connection before this connection gets into full feature phase, is a
protocol error."

Page 169: "To make use of SendTargets, an initiator must first be logged
in to one of two types of targets."

Since SendTargets is one of the keys for Text Cmds, and we can't issue
it before logging in, we probably should reword the sentence on page 22.

+++ will read:

Any PDU except login and text, which is sent on a TCP connection before
this connection gets into full feature phase, is a protocol error. Some
text command parameters also allowed only in full feature phase (e.g.,
SendTargets).

++++
----------------------------------------------
Q3: Page 169: "If it logs in to any other target, the session the
session can be either a discovery session or a normal operational
session".  Should we delete one "the session" from this sentence?
+++
??? can't find it
+++
----------------------------------------------
Q4: Why don't section 1.2.2.1 & 1.2.2.2 address where CmdSN & StatSN
should start from (0, 1, or whatever) explicitly like DataSN does?
Should we initialize the counters before start the process?
+++ third paragraph of 1.2.2.1 says now
Commands in transit from the initiator to the target layer are numbered by
iSCSI; the number is carried by the iSCSI PDU as CmdSN
(Command-Sequence-Number).  The numbering is session-wide and starts with a
value set by the initiator during the first login of a session (leading
login).

and 1.2.2.2 gstates:

   The first login response includes an initial value for status numbering.

 +++
----------------------------------------------
Q5: Page 102: "An operational parameter negotiation on a connection
SHOULD not start before the security/integrity negotiation if such a
negotiation exists.  Operational parameters negotiated inadvertently
before the security/integrity negotiation MAY be reset after the
security/integrity negotiation at the explicit request of the initiator
or target."

The question is under which circumstance do we need to negotiate
operational parameters before security/integrity negotiation?  If it's
unlikely to happen, why do we leave a potential security hole here?
+++ this will be clarified in an upcoming writeup
+++
----------------------------------------------
Q6:
Page 21: "... ... If an initiator and target are connected through more
than one session, both the initiator and target perceive the other as a
different entity on each session (a different I_T nexus in SAM-2
parlance)."

Page 69: "When a target is detecting an attempt to open a new session by
the same initiator (same InitiatorName and ISID) it MUST check if the
old session is active.  If it is not the old-session must be reset by
the target and the new session established. Otherwise the Login MUST be
terminated with a Login Response."

The sentence on page 21 tells us multi-sessions between an initiator and
a target are allowed; while the sentence on page 69 implies they are
not.  We probably need to clear it a bit.
+++ No it tells you that the target must check if the old connections are
still alive.  If they are this attempt is an error. If they are not the
target has not realized the old session has gone away (e.g. a client
reboot). I reformulate as:

   When a target is detecting an attempt to open a new session by the same
   SCSI initiator port (same InitiatorName and ISID) to the same target
   portal group it MUST check if the old session is still active.  If it is
   not active and the target has failed to realize that the old-session
   must be reset by the target and the new session established. Otherwise
   the Login MUST be terminated with a Login Response of "Session already
   open with this initiator".
   ++++

----------------------------------------------
Q7:
Page 69: "When a target is detecting an attempt to open a new session by
the same initiator (same InitiatorName and ISID) it MUST check if the
old session is active.  If it is not the old-session must be reset by
the target and the new session established. Otherwise the Login MUST be
terminated with a Login Response."

What does "reset" exactly mean here?

+++ clean its internal state - remove anything non-persistent data related
to the old session
+++
----------------------------------------------
Q8: This question is on multi-path.  Suppose two NICs are connected to
the same target, therefore we could have at least two target addresses
a1 & a2.  Suppose address a1 needs to be dedicated to a particular
initiator I1.  Is it OK if we let the target to hide a1 from (i.e. not
sending a1 with "SendTargets" cmd response to) all initiators except I1,
or do we need to modify 07 to do so?

The current Standard 07 on page 171 says "If a SendTargets response
reports an iSCSI address for a target, it SHOULD also report all other
addresses in its portal group in the same response."

+++ It is OK to hide the NIC. Portal groups are meant for groups of
physical ports that MAY share state+++
----------------------------------------------
Q9:  This is a performance-related question.

After the first (leading) connection logs into a normal operational
session, why can't the same initiator have an option to just "spawn"
more "full featured" connections with the same target without running
Login handshake processes (i.e. authenticate the parties, negotiate the
session's parameters, open security associations protocol and make
connections as belonging to a session) again.  It would be more
efficient if we could have this option.

It seems feasible because:

  - it's not necessary to authenticate both parties
    again after doing so on the first (leading)
    connection.
  - security is still possessed without running
    Login process on the following connections
    because the first (leading) connection has to
    run Login process, and no extra connections
    can be spawned without logging into the first
    one.
  - session parameters, generally, are the same
    for connections within a session.  If not, they
    can be re-negotiated later.
  - All connections within a session belong to
    the same I_T nexus.
  - Text Cmds can be used to "spawn" full-featured
    connections without adding too much stuff into
    iSCSI Standard or making it too complex.


+++  I don't understand exactly what you are suggesting here. Every TCP
connection raises the authentication issue (parties can't be sure that
simple things like IP addresses are not spoofed. More complicted things
(shared secrets) could be used and we looked at them in the past and did
not find that it is worth pursuing them. And different connections may have
different security requirements (a private line vs. a public line).
++++