Subject: Re: iSCSI login phasing

From: "Julian Satran" <[email-masked]>
Date: Sat, 28 Jul 2001 08:29:47 +0300

Robert,

The security purists will object (with good reason) to the names being
disclosed before security is established
when they are not needed for security.

Mandating always 2 phases is wastefull for those cases in which the
security negotiation is in fact bypassed.

Stating the phase explicitly solves both those problems.

Julo

"Robert D. Russell" <[email-masked]> on 27-07-2001 21:42:37

Please respond to "Robert D. Russell" <[email-masked]>

To:   Julian Satran/Haifa/IBM@IBMIL
cc:   [email-masked]
Subject:  Re: iSCSI login phasing

All:

Attached are 2 ASCII text files.  Once contains a state diagram
for the iSCSI Initiator login phase, the other a state diagram
for the iSCSI Target login phase.

The Initiator state machine has only 6 states with 10 allowed
transitions, and the Target state machine has only 5 states
with 7 allowed transitions.  Both diagrams have the form of
a single "spine" with minimal branching.  Error/failure
transitions are not shown, since they always result in
closing the connection during login (on the target side
a reject message may be sent first).

Both of these diagrams are based on draft 7 with simplifications
suggested by Julian, Rod Harrison, Steve Senum, Eddy Quicksall,
Stephen Bailey, Barry Reinhold, myself and others.

These include:

1. Every login is split into 2 distinct subphases (security and
   operational) with a required demarcation line between them.

1. Every login starts in the security subphase and must contain
   at least the keys: TargetName, InitiatorName, HeaderDigest,
   DataDigest, AuthMethod, and optionally SessionType=Normal.

2. No operational parameters can be negotiated before or during
   the security subphase (informational parameters, like
   TargetName, although listed in Appendix D, do not require
   negotiation and are not considered "operational" here).

3. The security subphase ends with a required 2- or 3-way handshake of
   Text and Text Response PDUs containing only the
   SecurityContextComplete=yes key and ending with a message from
   the target to the initiator.  The negotiated security functions
   become effective only at the successful conclusion of this handshake.

4. The operational subphase always begins immediately after the
   handshake had been completed.  No security parameters can be
   negotiated during or after the operational subphase.

5. The operational subphase ends with a Login Response with F=1 from
   the target to the initiator, at which time both target and
   initiator are in Full Feature Phase (the final state in both
   diagrams).

Comments please.

Bob Russell
InterOperability Lab
University of New Hampshire
[email-masked]
603-862-3774

On Fri, 27 Jul 2001, Julian Satran wrote:

> Dear colleagues,
>
> As some of you have complained about difficulty in implementing the login
> phase I thought it might be worthwhile to consider a slight departure
from
> the current description.
>
> The current text assumes that negotiations are forming one tree and the
> "login machine" has to parse the tree.
> A leaf node will completely define a state and some pathes may get you to
> error.
>
> I was driven to this design by the need to keep the parsing tree minimal
> (under the assumption that any split in subtrees
> will result is some parameters needing to appear in several subtrees).
>
> However - after the noisy (mostly UPPERCASE) debate - I came to realize
> that few if any have done the generalized mapping I started with, and
> implemented a parser,  and ad-hoc, man-glued, engines have to have
smaller
> trees for the next plugfest (although by then some bright undergraduate
> student may take onto himself to give us  an open-source yacc definition
of
> the login phase!).
>
> I looked at the 2 phases and the number of key=values that they share are
> probably limited today at initiator and target names (some
> organizations/configurations want them for authentication while some
others
> will object to them being revealed in the "open phase") and as such we
may
> want to slit the login in 2, completely bracketed, phases each of them
> optional but not both:
>
>
>    a security phase that if present must start with the login command and
>    is bracketed by the pairs SecurityPhase=start and ended by
>    SecurityPhase=end (on both initiator and target)
>    an operational-parameter-negotiation phase that must follow security
>    phase (if there is a security phase) and is bracketed by the pairs
>    OperationalPhase=start and OperationalPhase=end (on both initiator and
>    target)
>
>
> Some additional rules will apply:
>
>    No request/response will span phases
>    The phase closing handshake can start on both sides but if started at
>    target will be followed by an "full initiator target handshake" - i.e
a
>    new phase or the "curtain close" end always with the target having the
>    last word.
>    keys will be clearly segregated and only a few (like names) should be
>    allowed in both.
>
>
> Comments?
>
> Julo
>
>
>

---

From: "Robert D. Russell" <[email-masked]>
Date: Mon, 30 Jul 2001 15:40:45 -0400

> Stating the phase explicitly solves both those problems.

Julian:

1. Requiring the InitiatorName and TargetName keys on the login is
   independent of whether the phase is stated explicitly.

   a) If the phase is explicitly stated, we could still mandate that
      these keys always be required in the security phase.
      This makes your proposal identical to mine with respect to
      this issue.
   b) If the phase is not explicitly stated, we could drop the mandate
      that these keys always be required.  This makes my proposal identical
      to yours with respect to this issue.

   As you state, security purists would argue that these keys not be
   required before security is established.  Fine, but that does not
   argue either for or against your new proposal to explicitly state
   the phase.

2. Your new proposal to require a handshake at the end of both the
   security phase and the operational phase can also be considered
   wasteful, because now it will require two handshakes when
   both security and operational parameters are to be negotiated,
   whereas only one handshake is required in my approach.

   To compare the two approaches:

   a) No security, no operational:
        New proposal  - no handshakes (if this is legal, see below)
        Previous proposal - 1 handshake
   b) Security, no operational:
        New proposal - 1 handshake
        Previous proposal - 1 handshake
   c) No security, operational:
        New proposal - 1 handshake
        Previous proposal - 1 handshake
   d) Security, operational
        New proposal - 2 handshakes
        Previous proposal - 1 handshake

   So which is more wasteful -- your new proposal that requires 2 handshakes
   in case d, or my previous proposal that requires 1 handshake in case a?

   Note also that my previous proposal always required exactly 1 handshake,
   wherease your new proposal has a varying number, depending on the context.

3. I do not believe the new proposal solves either problem, nor do I believe
   it simplifies anything.  Attached is an ASCII text file containing the
   state diagram of the target for your new proposal as I interpret it,
   and I would welcome your comments/corrections to it, as I may not be
   interpreting it correctly.

   If my interpretation of your new proposal is correct, then your target
   requires 7 states and 14 transitions, instead of 5 states and 7
   transitions in my previous target state diagram.  Clearly the previous
   target is simpler by the measure of the number of states and/or the
   number of transitions.  I have not had time to produce a detailed
   diagram for the initiator, but your proposal does not seem to either
   add or delete states from my previous initiator state diagram.

   To make this new diagram easier to compare with my previous diagram
   for the target, I labeled the new states T6 and T7, and the new
   transitions Z8 through Z14.  If this new proposal is accepted,
   I would certainly relabel the states and transitions to be easier
   to follow.

   In his e-mail of 27-July Steve Senum asked 2 questions, which I repeat
   here:
        1.  Is the Initiator required to start with either a
            SecurityPhase=start or an OperationalPhase=start
            on the initial login command?

        2.  If the Initiator started with OperationalPhase=start,
            does the target have any way to force a SecurityPhase=start?

   In your reply of 28-July you did not answer either question directly,
   so I am assuming that the answer to both questions is No.
   Is this a correct assumption?

   If this is not true for question 1, (i.e., if the login must
   contain either SecurityPhase=start or OperationalPhase=start), then
   just eliminate the transition labeled Z9 in my new diagram.

   If this is not true for question 2, (i.e., if the target can
   force SecurityPhase=start), then there will be a need to add
   additional states and/or transitions to the new diagram.

   One final point about simplification -- your new proposal requires
   the addition of 4 new key-value pairs (SecurityPhase=start,
   SecurityPhase=end, OperationalPhase=start, OperationalPhase=end) and
   the elimination of 1 existing key-value pair (SecurityContextComplete=yes).
   My proposal keeps the SecurityContextComplete=yes key, and introduces no
   new keys.  (I believe the OpParmReset key would be eliminated in both
   proposals.)  Which is simpler and by what measure?  Clearly there is a
   direct cost to your proposal in terms of added states and transitions.

   Comments please.

Bob Russell
InterOperability Lab