Re: iSCSI: plugfest4 issues

[Paul Koning <ni1d@arrl.net>]

>>>>> "Robert" == Robert D Russell <rdr@io.iol.unh.edu> writes:

 Robert> Julian:

 Robert> Four issues came up today at the iSCSI plugfest:

 Robert> ...2. The last paragraph of section 2.2.3 says:

 Robert> "Before the Full Feature Phase is established, only Login
 Robert> Request and Login Response PDUs are allowed. Any other PDU,
 Robert> when received at ini- tiator or target, is a protocol error
 Robert> and MUST result in the connec- tion being terminated. ..."

 Robert> The question is the following: is this rule literally true
 Robert> for the target (i.e., can the target disconnect as soon as it
 Robert> receives a non-Login PDU from the initiator) or does the
 Robert> target have to first send a Login Response with Login reject
 Robert> PDU before disconnecting, as it does for all other errors
 Robert> detected by the target during Login Phase (according to
 Robert> section 4.3.1)?

 Robert> A related question is: does the target take the same action
 Robert> when the very first PDU it receives on a new TCP connection
 Robert> is not a Login Request PDU?

I like Luben's argument that a summary disconnect with no messages is
a good solution.  Apart from the security argument, I don't like
spending lots of effort coding up extra error paths that are only used
when the other side commits a gross protocol error.

 Robert> 3. Section 4.2 says:

 Robert> "All keys in Chapter 11, except for the X- extension format,
 Robert> MUST be supported by iSCSI initiators and targets and MUST
 Robert> NOT be answered with NotUnderstood."

 Robert> Two questions arose with this statement:

 Robert> 1. Shouldn't it say "All keys in Chapter 11 and Appendix A,
 Robert> ..." in order to include the Marker keys within the scope of
 Robert> this rule?

 Robert> 2. Does this literally mean that targets have to support
 Robert> initiator-only keys (and initiators support target-only
 Robert> keys)?  For example, suppose a target sends an InitiatorAlias
 Robert> key, which is supposed to be sent only by Initiators.  Does
 Robert> the target have to make an extra check to recognize that this
 Robert> is a "key in Chapter 11" that is used incorrectly, (so that
 Robert> it does not respond with NotUnderstood) or can it just treat
 Robert> it like it would any other key it cannot handle, for example,
 Robert> X-InitiatorAlias, and respond with NotUnderstood?

Similar reasoning as above: such an event is a protocol error.
"NotUnderstood" seems like a good response.  Disconnecting is also
fine in my view.

     paul