Subject: RE: iSCSI login phasing

From: Julian_Satran/Haifa/IBM%IBMIL <[email-masked]>
Date: Fri, 27 Jul 2001 18:55:17 +0300

Deva,

If there is no security phase the keywords SEcurityPhase start/end don't
have to be used.

Julo

"Dev - Platys" <[email-masked]> on 27-07-2001 18:30:14

Please respond to "Dev - Platys" <[email-masked]>

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

Julian,

So this proposal allows the operational parameters to be issued during
login
request itself if it there is no authentication ?

i.e.

I ->FR Login -> Operational Parameters = Start key1=x, key2 =x, Operational
Parameters = End
T ->FR Login -> Operation Parameters = Start key=x, key2=x, key3=x

In the above case, since no authentication is involved thre is no security
phase start end.

Also the keywords SecurityPhase=Start and SecurityPhase=end mandatory so to
be used even during non authentication phases.

Thanks

Deva

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
Julian Satran
Sent: Thursday, July 26, 2001 11:14 PM
To: [email-masked]
Subject: iSCSI login phasing

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: "Julian Satran" <[email-masked]>
Date: Sat, 28 Jul 2001 06:27:45 +0300

If the initiator is willing to do security but would rather not offer
anything it will start with a
SecurityPhase - without any offering.

If it starts with OperationalPhase it indicate it is not willing/capable of
doing security.
The target can only accept or reject.

Julo

Steve Senum <[email-masked]> on 27-07-2001 19:19:19

Please respond to Steve Senum <[email-masked]>

To:   ietf-ips <[email-masked]>
cc:
Subject:  Re: iSCSI login phasing

Julian,

Questions on your proposal.

1. Is the Initiator then 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?

Steve Senum

---

From: Michael Schoberg <[email-masked]>
Date: Mon, 30 Jul 2001 12:13:09 -0500

The 13 x 13 login state chart and the state diagrams may confuse some people
out there (including me).  Because of all the transactions that need to take
place, I don't think you'll ever make it trivial, but there may be a few
things that can be done to simplify it:

1. How about adding a flags field into the login command that describes
negotiations that are expected from the alternate.   Something like:

LOGIN FLAGS (example only)
-----------
CID Recovery Requested           	(FALSE = New CID Requested)
Custom configuration pending     	(FALSE = Current configuration
accepted)
Security Method Required            (FALSE = Security method defined)
Security Login Required             (FALSE = Authentication complete)
Target Not Yet Identified           (FALSE = Target identified)
Initiator Not Yet Identified        (FALSE = Initiator identified)
In Login					(FALSE = Full feature mode
accepted)

The login from I->T describes the options it requires from the target.  The
initiator may want to recover a previous session, set custom configuration
options, authenticate the target, etc.  Messages T->I may state requirements
for the initiator:  authentication, identification, etc.

Login messages can be exchanged until all requirements have been met.  When
both initiator and target have satisfied their login requirements, a
login/login response is issued with a completed status.  By setting
requirement bits in the requests/responses, the sequence of login events can
be orchestrated.

2. Do we really want to use TEXT= based messages for sending and receiving
configuration and authentication requests?  One of the things I'm concerned
about is the use of English (or English acronym) to provide the parse keys
for the transactions.  Can we use something a little more international?

The spec already describes mode pages for iSCSI.  Mode pages are easily
translated to other languages and avoids parsing problems (LoWeR CaSe
translation, decimal/hexadecimal translation, etc.)  Perhaps extending mode
pages into variable and login negotiations would be useful.  However, rather
than creating a bunch of different mode pages, we can limit it to just a
few:

Parameter negotiation page

+--------+--------+--------+--------+
| PageID |    Variable page length  |
+-----------------------------------+
| Variable Identification           |
+-----------------------------------+
| Number of array elements          |
+-----------------------------------+
| Value(s)                          |
.                                   .
.                                   .
+-----------------------------------+

Page lengths are word aligned.  Null pad bytes are used to extend lengths to
even words.

Variable Identification

1=MarkerType
2=TargetName
3=MaxConnections
4=TargetAddress
5=...

Security page

+--------+--------+--------+--------+
| Sec-Pg |    Security page length  |
+-----------------------------------+
| Value                             |
.                                   .
.                                   .
+-----------------------------------+

PageID
0=Respond with the current value of this variable.
1=Respond with array of known/possible values for this variable.
2=Set and respond with the default value for this variable.
3=Request this variable take on this new value.  Respond with actual value.
4=Request the alternate select from a value listed.  The response will be as
a '3'=set request.
5=Security question phase page
6=Security answer phase page
..

Variables or requests not understood are responded with a zero element page
with a zero value length.

Multiple pages can be attached to the login request/response messages as
needed.  The Login Request & Login Response messages are used at all times
throughout the login negotiation process.