|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: iSCSI Plugfest at UNH
Most of those have already been taken care of - so here are some quick
comments only.
And thanks all for the excellent work.
Julo
"Robert D. Russell" <rdr@mars.iol.unh.edu> on 19-07-2001 01:46:46
Please respond to "Robert D. Russell" <rdr@mars.iol.unh.edu>
To: ips@ece.cmu.edu
cc:
Subject: iSCSI Plugfest at UNH
From: Bob Russell rdr@iol.unh.edu
Bill Lynn bill_lynn@corp.adaptec.com
Kalman Meth meth@il.ibm.com
Barry Reinhold barry.reinhold@trebia.com
Points that arose during the UNH Plugfest (July 16-20, 2001)
where the Standard is unclear.
(not in any particular order)
--------------------------------------------------------------------------------
1. Exactly what should happen if operational parameters are sent by the
initiator during the security phase of login?
In section 4.2 the standard says:
"-The iSCSI parameter negotiation (non-security parameters)
SHOULD start only after security is established. This should be
performed using text commands."
and:
"When establishing the security context, any
operational parameters sent before establishing a secure
context MAY be ignored by both the target and the initiator."
There is a problem with the meaning of "ignore" -- should the target:
1. not respond to these operational keys at all, or
2. respond with key=reject, or
3. respond with a valid value and then just not use these values.
In this case, how does the initiator know whether or not the
target
is ignoring these parameters or not?
A final note: The standard seems to allow the initiator to
send operational parameters when establishing the security context,
get back a valid value from the target, and then ignore the entire
negotiation anyway. Is this legal? In this case, how does
the target know that the initiator is ignoring these parameters?
+++ It is standard practice (and legal) in most protocols to reset the
operational parameters to previous values
at the end of the security phase negotiation if the channel is becoming a
secure channel
WE have two options:
a) assume that this happens at every SecurityContextComplete
b) say explicitly that it happened - e.g., the target or initiator decide
that the channel is now more secure than before
and say explicitly something like OpParmReset=yes
I will assume that is b that most of you want and I will say so in 7 unless
I hear otherwise TODAY:
here is the text:
01 OpParmReset
Use: IO
Who can send: Initiator and Target
OpParmReset=<yes|no>
OpParmReset enables an Initiator or Target to request the operational
parameters to be reset to the values they had before login. Either the
initiator or target may choose to do so but only after and only if a
SecurityContextComplete handshake is completed on the connection. The
resetting should involve only parameters that where set during login on
the connection in which the OpParmReset is issued. Please note that
since either initiator or target may request this behavior there is no
need to reply.
and 4.3 reads:
1.1 Operational Parameter Negotiation During the Login Phase
Operational parameter negotiation during the login MAY be done:
- starting with the Login command if the initiator does not offer
any security/ integrity option
- starting immediately after the security/integrity negotiation if
the initiator and target perform such a negotiation
- starting immediately after the Login response with Final bit 0 if
the initiator does offer security/integrity options but the target
chose none.
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.
++++
++++
--------------------------------------------------------------------------------
2. In section 2.8.3 the standard says "Many key=value pairs can be
included
in the Text block by separating them with null (0x00) delimiters."
This implies that the last (or only) key=value pair is NOT terminated
by
a null delimiter. However, all C programs naturally treat key=value
pairs
as C strings which are always terminated by a null (0x00) delimiter.
Therefore, to avoid a source of errors and to simplify implementations,
please change the standard to require all key=value pairs MUST be
TERMINATED by null (0x00) delimiters.
NOTE: if this change is NOT made, then the standard needs to address
the
issue of what to do when a receiver receives a set of key=value pairs
that is terminated by a final NULL. Should this be treated as a format
error, or does that final NULL separate the last key from an empty key
which the receiver should just ignore?
The group consensus was unanimous that all key=value pairs MUST be
TERMINATED by null (0x00) delimiters.
+++ the change is made +++
--------------------------------------------------------------------------------
3. Many key parameters can take only "yes" or "no" as valid values.
However,
section 1.2.4 "Text Mode Negotiation" discusses only "list" negotiation
and "numerical" negotiation -- there is no discussion of "binary" or
"boolean" negotiation. However, the examples never show the use of a
list to negotiate any of these parameters. There are then two
interpretations of how to negotiate these parameters:
(a) Use the existing "list" negotiation mechanism for parameters that
can take only "yes" or "no" as valid values.
(1) If an initiator has a key named xxx for which it would prefer a
"yes" setting, but can also operate correctly with a "no"
setting,
then the initiator must offer "xxx=yes,no" to the target and
then
the target must respond with "xxx=yes" if it wants to use the
feature, "xxx=no" if it does not use the feature, "xxx=reject"
if it does not support the feature, or "xxx=NotUnderstood" if
it
does not understand the key name xxx.
(2) If an initiator has a key named xxx for which it can only
utilize
a "yes" setting, it offers the target "xxx=yes". The target
must respond with "xxx=yes" if it can also use this feature,
"xxx=reject" if it either cannot use or does not support this
feature, or "xxx=NotUnderstood" if it does not understand the
key name xxx. The reply "xxx=no" is explicitly disallowed.
This is a very simple way to do this negotiation, and does not
require
any new mechanism in either the standard or an implementation that
already does list negotiation. However, the standard should
explicitly show an example similar to one of those just shown to
make
it clear that this is the way to do it.
(b) Invent a new "binary" or "boolean" negotiation. This would require
new wording in the standard and probably new code in addition to
the "list" and "numeric" negotiation implementation code.
In particular, with this method there is no obvious way for the
initiator to indicate to the target that it can use either "yes" or
"no" but would prefer "no", for example, because sending the
string "xxx=no" could be interpreted either as "only no" or
"no prefered but yes is also ok". This gets complicated by
the default key values. If the required default is "yes", then
offering "no" would appear to mean "no is prefered bu yes is also
ok".
If the required default is "no", then offering "no" would not
appear
to be necessary, (but is currently not explicitly prohibited and
may be useful for implementations that simply send all keys) and
would appear to mean "only no".
The group consensus seemed to be that solution (a) is by far the
simplest
and therefore is prefered.
++++
As an engineer I though always that booleans are numbers (even if expressed
as yes and no).
As such I assumed they are included in 1.2.4 under the numeric umbrela.
I've added some wording about this to make unambiguous even for those that
assumed yes and no to be only
the English cahracter strings yes and no and negotiated as a list
The negotiated values are determined by a function that is specific to each
key (as with the rest of the numerics)
usually AND or OR (the text for the keys is hopefully specific enough).
I think also that boolean algebra is not a good subject for consensus. The
rules have
stated a long time ago.
++++
--------------------------------------------------------------------------------
4. It is not clear from the standard whether or not the value in the
CmdSN field of an initial login command for a session (i.e., TSID=0) is
"consumed" by its appearance in the login command or not. For example,
suppose an intiator sends a login command with TSID=0 and CmdSN=123
and then waits for a response from the target. Should the Login
Response
from the target contain ExpCmdSN=123 or ExpCmdSN=124? Similarly,
should
the next command sent by the initiator after this login contain
CmdSN=123
or CmdSN=124?
The consensus seemed to be that ExpCmdSN=124 in the Login Response and
CmdS124 in the next command, but the standard needs to make it
explicit,
perhaps with an example such as the one just given.
This is being dealt with in a mailing list thread.
+++ it is worded clear and an example is included +++
--------------------------------------------------------------------------------
5. Analagous with point 4, it is not clear how InitStatSN is handled
by the login phase. If a login response contains a value of 123
in its InitStatSN field, is the value of the next response from the
same target 123 or 124? For consistency with the handling of CmdSN
it would appear that 124 is correct. However, this situation may
be different because the field is called "InitStatSN", not "StatSN"
as it is in other responses.
At the plugfest the consensus was to use the value 124 for now,
but that 123 MIGHT be better long term.
A second issue is the fact that there can be two login responses
in response to a login (the "login partial response" and the
"login final response"), each of which carries an InitStatSN field.
It is not clear if the value of the InitStatSN field in a login
final response needs to be part of the sequence established by
the InitStatSN field in a preceding login partial response, or whether
the login final response can restart the sequence to an arbitrary value
supplied in its InitStatSN field. The standard should make this
explicit.
At the plugfest the consensus was that the final response CAN
restart the sequence.
This is being dealt with in a mailing list thread.
+++ changed to statsn and made numbering uniform from login +++
--------------------------------------------------------------------------------
6. During text mode negotiation, if a format error occurs, what is the
proper
response? Section 6.1 "Format Errors" does not handle all cases.
(a) During login, suppose the initiator offers a list and the target
responds with a value that is not in the list (and is not "reject"
or "Not Understood"). Is the initiator required to close the
connection or can it just internally recover from the error
(perhaps reporting the error through the "appropriate service
response") and continue with the login?
+++ the initiator is free as it sees fit - the initiator is the master of
this phase
It can drop or goon as it sees fit. I would suggest drop the connection but
why
should we specify this behavior+++
(b) During full-feature phase, suppose the initiator sends a text
command that offers a list and the target responds with a value
that
is not in the list (and is not "reject" or "NotUnderstood").
Section 7.3 deals only with the situation when there is an
outstanding task related to the PDU, but in this case there is
no outstanding task. Therefore, is the proper response to just
report the error through an appropriate service response
and then ignore it?
+++ Txt commands have an associated task (ITT) and are covered by 7.3 +++
--------------------------------------------------------------------------------
8. The last example in Appendix A "iSCSI Security and Integrity"
illustrates a special case that should be elimiated.
The last sentence of this example says:
"Note that no SecurityContextComplete=yes is required since no
security mechanism was chosen."
But it would be simpler if the exchange of
"SecurityContextComplete=yes"
keys were required in this case.
The reason they should be required is the following:
Appendix B. starts by saying that "the parameters (keys)
negotiated for security are:
- Digests (HeaderDigest, DataDigest)
- Authentication method (AuthMethod)"
Thus as soon as the Initiator offers either the HeaderDigest or
the DataDigest key, the security negotiation phase has been entered.
Section 4.2 "Security and Integrity Negotiation" clearly indicates
that the security sub-phase ends only when both sides have
correctly executed the "SecurityContextComplete=yes" handshake.
There is NO qualification in section 4.2 about the outcome of
the negotiation -- i.e., one would reasonably conclude that
selecting no digests and no authorization still requires the handshake,
because the final selections were acheived through negotiation, and the
handshake marks the end of the security negotiation subphase.
The phrase in the standard that makes this example "legal" is in
section 4.3, which says:
"Operational parameter negotiation during the login MAY be done:
. . .
- starting immediately after the Login response with Final bit
0 if the initiator does offer security/integrity options but
the target chose none."
This clause overrides the rules of section 4.2 with a special case.
Why bother with this special case? It complicates the logic in
implementations, requires extra wording in the standard, and appears
to offer no benefit. If it stays, there should be some indication
in section 4.2 about it, or better yet, combine these sections so
all this information is together in one place. As it is now, this is
an error trap for implementors of both targets and initiators.
+++ I will add to 4.2:
The SecurityContextComplete handshake MUST be performed if any of
negotiating parties has offered a security/integrity item (even if it
is not selected).
and fix the example to:
In the next example, the initiator does offer security/integrity
parameters on the Login PDU, but the target does not choose any (i.e.,
chooses the "none" values):
I-> Login InitiatorName=iqn.com.os.hostid.77
TargetName=iqn.com.acme.diskarray.sn.88 HeaderDigest=crc-32C,none
DataDigest=crc-32C,none AuthMethod:KRB5,SRP,none
T-> Login-PR, HeaderDigest=none, DataDigest=none, AuthMethod=none
I-> Text SecurityContextComplete=yes
T-> Text SecurityContextComplete=yes
I-> Text ... iSCSI parameters
T-> Text ... iSCSI parameters
And at the end:
I-> Text optional iSCSI parameters F bit set to 1
T-> Login "login accept" TargetName=iqn.com.acme.diskarray.sn.88
Note that SecurityContextComplete=yes is required although no security
mechanism was chosen.
++++
--------------------------------------------------------------------------------
9. the SCSI Command (section 2.3) contains R and W bits and an
"Expected Data Transfer Length". The standard says in section 2.3.1:
"b6 (R) set to 1 when input data is expected
b5 (W) set to 1 when output data is expected"
and in section 2.3.5:
"the Expected Data Transfer Length field states the number of bytes
of data involved in this SCSI operation."
It then goes on to describe 2 cases:
- W=1 with R=0,
- W=0 with R=1.
The problem is that some SCSI commands involve no data transfer
(Test Unit Ready is an example). So in this case, the
Expected Data Transfer Length field is set to 0.
How should the R and W bits be set?
- Should they both be set to 0?
- are they "don't care" bits so that their value can be anything?
(In the Test Unit Ready example, some implementations will set
the R bit because the SCSI implementation interfacing with the
iSCSI code uses a single bit to differentiate between read and
write commands, and considers this a read command).
The standard should make this explicit.
+++ there is already some wording for it +++
--------------------------------------------------------------------------------
10.Another problem related to setting the F bit on SCSI commands.
Section 2.3 says:
"b7 (F) set to 1 when no unsolicited SCSI Data-Out PDUs follow
this PDU. For a write, if Expected Data Transfer Length is
larger than the Length the target may solicit additional data
through R2T."
This does not explicitly say what happens on a read or on a
command other than a write (point 9 above) or on a write with
an expected data transfer length of 0. These commands do
not allow unsolicited SCSI Data-Out PDUs to follow them, so one
could infer that the F bit should be set to 1. However, the present
wording can also be interpreted that because unsolicited SCSI
Data-Out PDUs are not allowed to follow these commands, this
explanation does not apply to them.
The standard should explicitly state what happens in the case of
these commands, rather than leave it up to an implication.
+++ as above +++
--------------------------------------------------------------------------------
11.In section 1.2.3 iSCSI Login there is the paragraph:
"The login PDU includes a session ID that is composed of an initiator
part ISID and a target part TSID. For a new session, the TSID is
null. As part of the response, the target generates a TSID.
>> Session specific parameters can be specified only for the first login
of a
>> session (TSID null) (e.g., the maximum number of connections that can
>> be used for this session). Connection specific parameters, if any,
>> can be specified for any login. Thus, a session is operational once
it has at least one connection."
The wording of the 2 sentences indicated by ">>" needs to be changed
to explicitly indicate login phase, since as now worded in could
be literally interpreted to mean login command only. Proposed
rewording for those sentences:
"Session specific parameters can be specified only during the login
phase
begun by a login command containing a null TSID (e.g., the maximum
number of connections that can be used for this session). Connection
specific parameters, if any, can be specified during the login phase
begun by any login command.
+++ OK (that is from the plugfest or personal?)+++
--------------------------------------------------------------------------------
12.If unsolicited data is negotiated, it appears that it still does not
have to be used. In practice this can lead to performance
inefficiencies.
Consider the following:
- Unsolicited data has been negotiated to YES but immediate data
is NO (although a problem still exists even if this is YES).
- The initiator sends a SCSI command with F=0, W=1 and a large
Expected Transfer Length field (greater than FirstBurstSize).
- When the target receives this command, it knows that unsolicited
data follows (because F=0), but does NOT know how much (there
is a maximum determined by the negotiated FirstBurstSize, but
there
is no requirement that the initiator actually send this much).
Therefore, the target cannot at this time send out an R2T to get
the "rest" of the data -- it must wait to receive data PDUs
until it gets the F=1 set on one of these data PDUs, and then
compute the amount of data to ask for in the R2T. This may
introduce needless delay.
To avoid this situation, the standard should either:
- require that when unsolicited data is to be sent, that the
amount be min(Expected Transfer Length, FirstBurstSize),
- alternatively, provide a field in the SCSI command that
allows the initiator to indicate how much unsolicited data
follows.
+++ Should we really? A good driver will do what it can to optimize its use
of resources while getting maximum performance. IMHO a warning to
implementers will be enough and I will try to put it in.++++
--------------------------------------------------------------------------------
13.Some keys are dependent on other keys. For example, the keys that
determine the actual marker intervals (RFMarkInt, SFMarkInt) have
meaning only if markers are in fact being used, as determined by
the FMarker key. Typically an initiator will offer these
three keys in the same message. If the target responds with
FMarker=no, does it need to respond to the RFMarkInt and SFMarkInt
keys, or can it just omit those from the response, since whatever
values they contain will be meaningless anyway?
+++ A rule might be required for the general case and I will try to specify
one. However this specific example has no real dependencies to worry about.
You may end up with some useless values or you may drop them if you are not
supporting FMarker +++
--------------------------------------------------------------------------------
14.The login phase involves many combinations and permutations that
need to be clarified through a state diagram incorporated into
the standard. One example is the situation that arises when an
initiator sends a login command with F=1 and operational parameters
but no security parameters (because the initiator does not want to
utilize any security). The target, however, wishes to use security.
There appear to be several valid responses the target can give:
(a) It can reply with a login final response, F=1, Reject Code of
201 (Authentication failed) and then disconnect.
(b) It can reply with a login partial response, F=0, status code
1 (if the login included the ITN) or 2 (if login did not include
ITN) and offer its own security parameters.
The consensus seems to be that login in its current form is too
complex and needs to be simplified considerably.
One possibility would be to standardize one or a small number of
simple,
"fast-path" logins that involve no (or very limited) negotiation and
that together would cover the majority of situations.
+++ A state diagram is a powerful representation for a small state space
it is of no value in space that is large. You are in fact talking about
a very limited state diagram and we will look at a way of specifying it.
+++
--------------------------------------------------------------------------------
15.The issue of case sensitivity in names arose, and is being dealt with
by a mailing list thread. There also seems to be cases where the
Naming and Discovery document is in conflict with the iSCSI Standard.
+++ fixed +++
--------------------------------------------------------------------------------
16.The issue of using a target name of "iscsi" for both discovery sessions
and "simple" devices arose, and is being dealt with by a mailing list
thread and new text in draft 6-98, which was not available at the time
of the plugfest.
--------------------------------------------------------------------------------
17.Can the option "none" be offered as the first element in a key list
if that is in fact the prefered option? The present wording in
section 1.2.4 says nothing about where in the list it can be offered,
so by implication it can be anywhere. However, the standard should be
explicit on this point, since all examples (and apparently some
earlier drafts required) indicate "none" as the last option offered.
+++ 1.2.4 reads:
During login and thereafter some session or connection parameters are
negotiated through an exchange of textual information.
In "list" negotiation, the offering party sends a list of values for a
key in its order of preference.
What do we have add. I assume that if we add more text the amount of
overlooked text will only increase +++
--------------------------------------------------------------------------------
18.The login process is incredibly difficult to understand from the
current standard. There are three major obstacles:
(1) The information is spread out in at least 5 major sections of
the document (section 1.2.3, section 2.3 and 2.4, section 4,
Appendix A, and Appendix D.)
(2) There is no state diagram to bring all this information together.
(3) It is too complex in its current form.
--------------------------------------------------------------------------------
19.In Appendix A the Standard defines the crc-32C generator polynomial
to be used by iSCSI but gives no example of its use. On the mailing
list
several people worked out an example with actual data and gave the
actual
result of the algorithm. Also on the mailing list several people
contributed code to perform this computation. This information (the
detailed worked out example and the code) should be made part of the
standard in order to eliminate any sources of confusion and to allow
implementors to check their own implementations against a reference.
+++ added an example ++
--------------------------------------------------------------------------------
20.This is just an observation -- the iSCSI response sent by a target
contains a Data Segment Length field and requires the SCSI response
to carry sense and response data in the PDU itself. Any I/O data
produced by the SCSI command itself should be carried in a separate
Data-In command, not in the iSCSI response. This should be made
explicit in the standard, especially because in earlier drafts it
was apparently possible to do this. The group at the plugfest
unanimously agrees that SCSI I/O data not be allowed in the iSCSI
response, but would just like it to be stated explicitly in the
standard.
+++ even in the current draft it is possible The last data PDU carries
status
BUT ONLY IF STATUS IS GOOD. Moreover 1.2 reads
For performance reasons, iSCSI allows a "phase-collapse". A command and
its associated data may be shipped together from initiator to target and
data and responses may be shipped together from targets.
+++
--------------------------------------------------------------------------------
Home Last updated: Tue Sep 04 01:04:16 2001 6315 messages in chronological order |