RE: iSCSI: Login Request error

["THALER,PAT (A-Roseville,ex1)" <pat_thaler@agilent.com>]

Luben,

The text you quoted from page 69 (which I agree has a consistency problem as you noted) is not relevant to negotiation of ImmediateData which is a binary key. That text is specifically for list negotiation. The relevant text for this negotiation is in 4.2.2 Simple-value negotiations.

Many people in responding to this string are equating responder to target but one needs to remember that the responder may be the target or the initiator. The reaction to an error condition varies depending on whether an initiator or a target has received the error.

The text you quote for Initiator Error is not the same as the text on page 173 of 12-90 which says in part "indicates that the initiator most likely caused the error. This MAY be due to a request for a resource for which the initiation does not have permission." It may also be due to other problems. For instance the last paragraph of 4.3 for the case where the target has detected an attempt to negotiate a parameter more than once: "If detected by the target this MUST result in a Login reject (initiator error)." This is not a resource error. With my picky filter engaged, the sentence also has a couple of problems. It refers to "Login reject". Page 74 lists "Login Reject" as a possible response to Login. Both make it sound like Login Reject is a defined response. However, I can't find any definition of "Login Reject" in the draft. 9.13 does not use the term in describing the Login response PDU. I believe that a login response PDU with any non-zero status class is a Login Reject but 9.13 should make that explici
t. Secondly, it isn't clear whether "(initiator error)" is the status or the status detail or both. I think both the status and the status detail for this error should be initiator error.

Initiator Error specifically says "(not a format error)" presumably because 6.4 Format Errors says that the response to a format error is to close all transport connections in the session immediately. It defines a format errors as "explicit violations of PDU layout rules." I don't think that an error in a key value fits this definition. It is not clear to me how one determines whether an error is a format error. And it seems like this reaction (especially during login when one may not even have completed authentication) allows a powerful denial of service attack. - Probably a subject for another string.

Also note that status detail Initiator Error 0200 Miscellaneous iSCSI initiator errors is not the same as status 2 Initiator Error. Presumably all status detail Initiator Errors imply that the status will be Initiator Error but the reverse is not true. It is confusing to have both a status detail and a status with the same name as the name is then only clear when one knows which field it is. A slight modification to the status detail name would be wise. Other Initiator Error would work.

Going back to 4.2.2: 
I beleive that "ImmediateData=Ye" is an inadmissible value. 

I think the text "An offer of a value not
admissible (e.g., not within the specified bounds) MAY be answered
with the constant "Reject" or the responder MAY select an admissible
value. The selection, by the responder, of a value not admissible
under the selection rules is considered a negotiation failure and is
handled accordingly. The selection rules are key-specific." is 
intended to apply to all simple value negotiation though from its position
in the paragraph it might appear to only apply to numeric range negotiation. This could be clarified by starting a new paragraph or by moving the sentence on numeric range negotiation to the end  of the paragraph. 

So if an orginator offers "ImmediateData=Ye"
the responder may reply with "ImmediateData=Reject"
or with "ImmediateData=Yes" or "ImmediateData=No" (since either is an admissible value).

What isn't explicitly stated is what happens after the responder responds with "ImmediateData=Reject". If the orignator tries sending an key value pair for ImmediateData again does it count as negotiating a parameter more than once or is it acceptable. An argument for continuing the negotiation by resending the key is that the responder knows that the negotiation hasn't completed? On the other hand, if the orignator offered a non-boolean value for a boolean key, then it is probably broken. Is there any point in continuing the negotiation? It might be an endless loop. I think it makes sense to terminate the login and that is consistant with what the originator is required to do if the responder sends an inadmissible value.

If we look at the alternate case where the responder chooses an admissible value rather than sending a Reject, it might also result in termination of the connection. The originator thinks it sent an admissible value. The value the responder chose might not be admissible under the selection rules. For instance, if the originator thought it had sent ImmediateData=No the responder received an inadmissible value and decided to reply ImmediateData=Yes, that would be an inadmissible response under the AND selection rule that applies to ImmediateData and the originator would terminate the login.

Therefore, receiving an inadmissible value for a key value pair should terminate the login. This simplifies negotiation. An attempt to do something else just complicates the login processing and has a large chance of ending up with login termination anyway. If it doesn't end up with login termination, then it may result in a loop of bad offers and rejections.

Regards, 
Pat


-----Original Message-----
From: Luben Tuikov [mailto:luben@splentec.com]
Sent: Tuesday, May 21, 2002 6:47 AM
To: Parthi
Cc: Bill Studenmund; Mike Donohoe; 'ips@ece.cmu.edu'; Julian Satran
Subject: Re: iSCSI: Login Request error


Parthi wrote:
> 
> > >  Responder should say  "Reject" in Text param negotiation.
> > >
> > >        ex.       Originator->  ImmediateData=Ye
> > >                     Responder ->  ImmediateData=Reject
> > >
> > >  The status value would be  020b  "Invalid during login".
> >
> > Would 020b be the correct error for that? I would have thought 0200
> > "Miscellaneous iSCSI initiator errors" would have been better; I thought
> > 020b was exclusively for an attempt to do something that should only be
> > done in FFP, before you've gotten to FFP.
> >
> > Take care,
> >
> > Bill
> 
> Hi :
> 
>   Draft says "Initiator Error(not a format error) -- This indicates request for a resource for
> which the initiator
> does not have permission. The request should not be tried again".

The status value should be 0 (Success). Note that
since we are talking about status codes, we imply
that the _Target_ replies.

That is, the Target should reply with (as already noted)
ImmediateData=Reject and status of 0. This would tell the
Initiator that login is proceeding ok, but ImmediateData
needs renegotiation/reconsideration.

Note that the Target may reply with other keys' responses,
along with the rejected ones.

Then the initiator will reconsider all rejected keys.

Note that a status code of anything but 0, implies
closing the connection.

Please see this message:
http://www.pdl.cmu.edu/mailinglists/ips/mail/msg09771.html

My reply is a bit messy, in that I should've been clearer,
that the originator of the key being rejected by the
responder, SHOULD, if available, offer another set of values,
or close the connection.

Currently, the draft says (pg 69, 12-90):

	If a responder does support, understand or is allowed
to use none of the offered options with a specific originator,
it MAY use the constant "Reject" or it MAY respond with an
admissible value. The selection of a value not offered is
considered a negotiation failure and is handled as a protocol
error.

Which is inconsistent with itself. (I.e. self-contradictory
to negotiation.)

Proof: By the first clause:
Assume that the responder cannot use any of the
offered options to a key (keyword ``none'' in the
first sentence). Then the responder 
   1) MAY Reject,
   2) MAY offer an admissible value.
Take 2) and proceed.

Then the originator receives an (admissible) value
which was NOT in what it offered and closes the
connection by the second clause.
Clearly, this is a negotiation failure.

If, on the other hand, we had chosen 1),
i.e. send Reject, the originator, may reconsider
it's options and send a different set of values,
and should one of them be acceptable to the
responder, we arrive at negotiation success.
QED.

This has already been communicated to Julian. Julian?

Nevertheless, a Reject response is required by
the responder to ``close the loop''.

If the originator doesn't close the connection
after that, the responder MAY choose to send
it's own values for the same (Rejected) key.
I.e. the responder to the Reject will now become
the originator of the Reject-ed variable.

-- 
Luben