|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: iSCSI: Login State Tables
Barry,
Thanks for sharing your thoughts with us.
Some of the things you mention are already in our text (like forbidding a
negotiation on an F=1 response) as we agreed.
We will give careful consideration to all the rest and I will get the
appendix to this list soon.
We are considering removing most of the parameters from the ALL category
and making them unchangeable by a
a MODE set (although the mode set will be accepted - for compatibility) -
as some of you (most vocally Santosh Rao) have requested.
Regards,
Julo
"Barry Reinhold" <bbrtrebia@mediaone.net> on 21-05-2001 20:00:27
Please respond to "Barry Reinhold" <bbrtrebia@mediaone.net>
To: Julian Satran/Haifa/IBM@IBMIL
cc: "ISCSI" <ips@ece.cmu.edu>
Subject: iSCSI: Login State Tables
Julian and interested parties:
The login mechanisms as documented in 06 concerns me, as there is a lot of
room for
"interpretation" of the current text. I have attempted to pull the 06
statements together
into a state table in order to avoid what I fear may be a bunch of
interoperability
headaches. The state table, however, also places some restrictions on the
process that
is not in the current text. In particular:
1. It forces all negotiations to go through an explicit security handshake.
If
security is not being used the handshake still takes place. This allows a
target to
demand security in a clean manner even if the initiator did not request it.
2. It explicitly places most parameters into an operation class and a
security class.
These parameters may only be exchanged during defined phases of the login
process.
(This is intended to remove ambiguity associated with the use of
operational
parameters
that were negotiated in the security phase). There is a set of parameters
that are
really not in either camp. These parameters can be used in both the
security
phase and
the operational phase. Once negotiated their values would remain
established
unless
explicitly renegotiated. [Note: Another choice here is to place all
operational parameters
into this category and apply the rule that all negotiated values MUST be
maintained by
both parties unless renegotiated.]
3. It does not allow a target to respond to a Text PDU that has a F=1
setting with new
key=value pairs in a login PDU with F=1.
4. It allows the initiator to continue negotiations if it was happy with a
context but
additional negotiations made it unhappy. This allows the protocol to
address
situations
in which there is a coupling between parameters.
This is intended to mostly be a clarification of what I think 06 is
attempting to
state, however, you may think differently. If there is basic agreement that
this is
what we are trying to do in 06 I would like to see something of this nature
added to
the draft.
Parameter classification:
Operational Parameters:
Maxconnections, FMarker, RFMarker, RFMarkInt, SFMarkInt, IFMarkInt,
InitialR2T,
BidiInitialR2T, ImmediateData, DataPDULength, FirstBurstSize,
LogoutLoginMinTime,
LogoutLoginMaxTime, EnableACA, MaxOutstandingR2T, DataOrder, BootSession,
Glen-Turner Vendor Specific Keys.
Not Classified - TargetName, InitiatorName, TargetAlias, InitiatorAlias,
TargetAddress, SendTargets
Security - DataDigest, HeaderDigest, AuthMethod
Identifiers used in login state table
SecDone - An indicator that takes on the value True (T) or False (F).
This indicator is when the local device is satisfied with
the current security context and is ready to move to the
operational parameter negotiation phase. When a PDU has
been received the value of SecDone is that established
after the contents of the received PDU have been evaluated.
OpDone - This is the logical equivalent of SecDone for the Operational
Phase.
Fsent - This variable is used to indicate that the last PDU sent by
this device had the F bit set to 1. [Note: The meaning of the
F bit is changed by this usage. It no longer means that this is
the last PDU to be sent by the initiator, in this context it
means
that this is the last text PDU I will send if the target
doesn't continue the negotiation.]
SCC - A short hand notation for the key "SecurityContextComplete"
Rcv_Text- A valid Text PDU was received
Rcv_Login-A login PDU was received
Xmit_Text-A Text PDU is transmitted
Perror - A protocol error was detected
Initiator Login State Transition Table:
+--------+-------------------------+--------+-------------------------+-----
--+
|C State | Event(s) and conditions |N State | Actions |
Notes |
+--------+-------------------------+--------+-------------------------+-----
--+
|START |(TCP connection Est- |SEC-END |xmit login(SCC=yes) | 1
|
| |ablished) & SecDone | | |
|
+--------+-------------------------+--------+-------------------------+-----
--+
|START |(TCP connection Est- |SEC-NEG |xmit login |
|
| |ablished & not(SecDone) | | |
|
+--------+-------------------------+--------+-------------------------+-----
--+
|SEC-NEG |Rcv_Text & SecDone=F |SEC-NEG |Xmit_Text |
|
+--------+-------------------------+--------+-------------------------+-----
--+
|SEC-NEG |Rcv_Text & SecDone=T |SEC-END |xmit_Text(SCC=yes) |
|
+--------+-------------------------+--------+-------------------------+-----
--+
|SEC-NEG |Perror |ABORT |TCP connection terminated| 2
|
+--------+-------------------------+--------+-------------------------+-----
--+
|SEC-END |Rcv_Text & SecDone=F |SEC-NEG |xmit_Text | 3
|
+--------+-------------------------+--------+-------------------------+-----
--+
|SEC-END |Rcv_Text & SecDone=T |SEC-NEG |xmit_Text |
|
+--------+-------------------------+--------+-------------------------+-----
--+
|SEC-END |Rcv_Text(SCC=yes) & |OPER-NEG|xmit_Text | 4
|
| |SecDone = T & OpDone = F | | |
|
+--------+-------------------------+--------+-------------------------+-----
--+
|SEC-END |Rcv_Text(SCC=yes) & |OPER-END|xmit_Text | 4
|
| |SecDone = T & OpDone = T | | |
|
+--------+-------------------------+--------+-------------------------+-----
--+
|SEC-END |Perror |ABORT |TCP connection terminated| 5
|
+--------+-------------------------+--------+-------------------------+-----
--+
|OPER-NEG|Rcv_Text & OpDone = F |OPER-NEG|xmit_Text |
|
+--------+-------------------------+--------+-------------------------+-----
--+
|OPER-NEG|Rcv_Text & OpDone = T |OPER-END|xmit_Text(F=1), Fsent=1 |
|
+--------+-------------------------+--------+-------------------------+-----
--+
|OPER-NEG|Perror |ABORT |TCP connection terminated| 6
|
+--------+-------------------------+--------+-------------------------+-----
--+
|OPER-END|Rcv_Text & OpDone = F |OPER-NEG|xmit_Text, Fsent=0 |
|
+--------+-------------------------+--------+-------------------------+-----
--+
|OPER-END|Rcv_Text & OpDone = T |OPER-END|xmit_Text(F=1), Fsent=1 |
|
+--------+-------------------------+--------+-------------------------+-----
--+
|OPER-END|Rcv_Login(F=1) & Fsent=1 |FULL | |
|
+--------+-------------------------+--------+-------------------------+-----
--+
|OPER-END|Perror |ABORT |TCP connection terminated| 7
|
+--------+-------------------------+--------+-------------------------+-----
--+
Notes:
All - The F bit is set to zero (F=0) unless otherwise indicated
in the login state table.
All - Operational parameter key=value lists SHALL NOT be allowed
before the security context has been completed.
All - The Key=value pair "SecurityContextComplete=yes" must always
be sent by itself
1 - No key=value pairs may be included in this PDU
except "SecurityContextComplete=yes"
2 - Identified protocol errors are: Rcv_Text has F=1, Rcv_Text
has operational parameters
3 - If the target sends a security parameter that causes the initiator
to no longer be satisfied with the current security context the
initiator
continues the security negotiations.
4 - This and subsequent PDUs sent on this connection SHALL be transmitted
using the negotiated security context.
5 - Identified protocol errors are Rcv_Text has F=1, Rcv_Text has
operational parameters
6 - Identified protocol errors are: Rcv_Text has F=1 and Fsent is not
set,
Rcv_Text contains a security key
7 - Identified protocol errors are: Rcv_Text has F=1, A login PDU is
received with new key=value parameters, A login PDU is received with
F=0.
Target Login State Transition Table:
+--------+-------------------------+--------+-------------------------+-----
--+
|C State | Event(s) and conditions |N State | Actions |
Notes |
+--------+-------------------------+--------+-------------------------+-----
--+
|WAIT |rcv_login(scc=yes) & |OPER |xmit_Text(scc=yes) | 1
|
| |SecDone = T | | |
|
+--------+-------------------------+--------+-------------------------+-----
--+
|WAIT |rcv_login & SecDone = T |SECURITY|xmit_Text(scc=yes) |
|
+--------+-------------------------+--------+-------------------------+-----
--+
|WAIT |rcv_login(scc=yes) & |SECURITY|xmit_Text |
|
| |SecDone = F | | |
|
+--------+-------------------------+--------+-------------------------+-----
--+
|WAIT |rcv_login & SecDone = T |SECURITY|xmit_Text |
|
+--------+-------------------------+--------+-------------------------+-----
--+
|WAIT |Perror |ABORT |xmit_Login(F=1) | 2
|
| | | |status_class != 0 |
|
+--------+-------------------------+--------+-------------------------+-----
--+
|SECURITY|rec_Text & SecDone = F |SECURITY| xmit_Text |
|
+--------+-------------------------+--------+-------------------------+-----
--+
|SECURITY|rec_Text & SecDone = T |SECURITY| xmit_Text(scc=yes) |
|
+--------+-------------------------+--------+-------------------------+-----
--+
|SECURITY|rec_text(Scc=yes) & |SECURITY| xmit_Text |
|
| | SecDone = F | | |
|
+--------+-------------------------+--------+-------------------------+-----
--+
|SECURITY|rec_text(Scc=yes) & |OPER | xmit_Text(SCC=yes) | 3
|
| | SecDone = T | | |
|
+--------+-------------------------+--------+-------------------------+-----
--+
|SECURITY|Perror |ABORT |xmit_Login(F=1) | 4
|
| | | |status_class != 0 |
|
+--------+-------------------------+--------+-------------------------+-----
--+
|OPER |rcv_Text & OpDone = F |OPER |xmit_Text |
|
+--------+-------------------------+--------+-------------------------+-----
--+
|OPER |rcv_Text & OpDone = T |OPER |xmit_Text |
|
+--------+-------------------------+--------+-------------------------+-----
--+
|OPER |rcv_Text(F=1) |OPER |xmit_Text |
|
| |OpDone = F | | |
|
+--------+-------------------------+--------+-------------------------+-----
--+
|OPER |rcv_Text(F=1) |Full |xmit_Login(F=1) | 5
|
| |OpDone = T | | |
|
+--------+-------------------------+--------+-------------------------+-----
--+
|OPER |Perror |ABORT |xmit_Login(F=1) | 6
|
| | | |status_class != 0 |
|
+--------+-------------------------+--------+-------------------------+-----
--+
1. The Target SHALL NOT send a login PDU back unless there is an error and
it
is ending the login process. The next PDU to be received will be using
the
negotiated security context (externally established or default)
2. Identified protocol errors: The F bit is set in the login PDU,
Operational
parameters are given as key=value lists in the PDU
3. The device SHALL use the negotiated security on the all subsequent PDUs
received for this connection.
4. Identified protocol errors: The F bit is set in the text PDU, a login
PDU
was received, operational parameters were received in the PDU.
5. The target SHALL NOT send any additional key=value lists in this PDU.
6. Identified protocol errors: Security parameters were received in the
PDU.
Barry Reinhold
Principal Architect
Trebia Networks
barry.reinhold@trebia.com
603-868-5144/603-659-0885/978-929-0830 x138
Home Last updated: Tue Sep 04 01:04:38 2001 6315 messages in chronological order |