Return-Path: X-Sieve: cmu-sieve 2.0 Return-Path: Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id h0G95sr13107 for ips-outgoing; Thu, 16 Jan 2003 04:05:54 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [194.196.100.236]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id h0G95qW13103 for ; Thu, 16 Jan 2003 04:05:52 -0500 (EST) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-3.de.ibm.com (8.12.3/8.12.3) with ESMTP id h0G95c0G039202; Thu, 16 Jan 2003 10:05:41 +0100 Received: from d10ml001.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id h0G95aEs093154; Thu, 16 Jan 2003 10:05:37 +0100 In-Reply-To: To: "Robert D. Russell" Cc: "" Subject: Re: UNH Plugfest 5 MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0 September 26, 2002 From: "Julian Satran" Message-ID: Date: Thu, 16 Jan 2003 11:05:35 +0200 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 16/01/2003 11:05:36, Serialize complete at 16/01/2003 11:05:36 Content-Type: multipart/alternative; boundary="=_alternative 0031B81DC2256CB0_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 0031B81DC2256CB0_= Content-Type: text/plain; charset="US-ASCII" Bob, First on behalf of the entire team thanks for the great job. As for the two issues: "Robert D. Russell" wrote on 16/01/2003 01:28:21: > Julian: > > Two more questions arose at the plugfest today, 15-Jan-2003. > > 1. A question arose as to the proper target response during the following > CHAP authentication exchange. > > Assume that: > I->T: CHAP_A=5 > T->I: CHAP_A=5 CHAP_I= CHAP_C= > worked correctly. The Initiator now sends: > I->T: CHAP_N= CHAP_R= CHAP_I= CHAP_C= > Further assume that the values CHAP_N= and CHAP_R= are > correct, so that the initiator is successfully authenticated by the > target and the target will allow it access to the target's resources. > > The problem arises because the target does not want to be > authenticated by the initiator, for whatever reason -- perhaps it has > no CHAP_N value to return for this initiator, or it has no secret > to use in calculating a value to return for CHAP_R, or whatever. > If the initiator had not sent the CHAP_I and CHAP_C keys, both > sides would have been happy and the login would proceed. But the > initiator did send those keys and the target does not want to see > them. So, what should happen? > > There appear to be at least the following 4 possibilities. > > a. The target replies: CHAP_I=Reject CHAP_C=Reject > This does not appear to be correct because the target is > expected to reply to the pair of keys CHAP_I, CHAP_C with > different keys (i.e., CHAP_N and CHAP_R), not the same keys. > Furthermore, the target already sent CHAP_I and CHAP_C > earlier in the exchange, so this would be sending the same > key twice. Certainly the initiator is not expecting to > receive CHAP_I and CHAP_C again. > > b. The target replies: CHAP_N=Reject CHAP_R=Reject > This does not appear to be correct because these are not > replies to offers of CHAP_N and CHAP_R, but to offers of > different keys (i.e., CHAP_I and CHAP_C). However, they > could be considered "replies" of sorts to the initiator's > "offer" of CHAP_N and CHAP_R, but that is stretching things. > > c. The target replies with a login reject, but it is not > clear what status code to use in this login reject pdu: > 0x0200 is not accurate, because it is not an initiator > error. > 0x0201 is not accurate, because the initiator WAS > successfully authenticated. > 0x0202 is also not accurate because the initiator > IS allowed access to the given target. > 0x0300 is not accurate, because it is not a target > error. > A new access code could be invented "The target will not > authenticate itself". > > However, in this present situation, a login reject is probably > not what the target wants to send, because it is willing to > allow this initiator to proceed without target authentication, > and thus the target does not want to terminate the login exchange. > > d. The target replies with no keys, and if the initiator offered > a transition out of security negotiation phase (i.e. T=1 and > NSG=1 or NSG=3) then the target accepts the transition. If the > initiator does not like going on without having the target > authentication, it can always just close the connection upon > receiving this reply. If the initiator did not offer a > transition out of security negotiation phase, the target can > only reply with T=0 and NSG=0, and will continue doing this for > all subsequent login requests until either the initiator offers > a transition or drops the connection. > > Solution d appears to be the most flexible, because the decision to > ask for target authentication was made by the initiator, and solution > d leaves it up to the initiator to decide whether or not it will > proceed when the target refuses to provide this authentication. > > In any case, there appears to be a need for some clarification > in the standard to cover this situation. > > C is the behaviour we intended. As it does not look like another error response is warranted i will update the code explanation to read: The initiator could not be successfully authenticated, or target authentication is not supported. and make 11.1.4 read: If the initiator authentication fails, the target MUST answer with a Login reject with "Authentication Failure" status. Otherwise, if the initiator required target authentication, the target MUST either answer with a Login reject with "Authentication Failure" or reply with: CHAP_N= CHAP_R= Obviously a carefully designed initiator should be prepared to handle case d although this is not the cannonical target behavior. > 2. The question arose with regard to how an initiator maps a scsi > "bus reset" onto iscsi (this may be a legacy situation). Some vendor > initiators are simply doing a session logout, but other vendors claim > this is not sufficient, and that to correctly emulate a "bus reset" > the initiator needs to do a task management function TARGET WARM > RESET, or, since that is optional to implement, when it is not > implemented then the initiator needs to issue a task management > function LOGICAL UNIT RESET for all active LUNs in that session. > > Can/should there be a "note to implementers" on this in the standard, > so that a consistent result will be obtained in this situation? > Rob Elliot has already commented on that and I can add little to his comments. Resets where intended as "big hammer" commands - and I assume that this is what happened on the old parallel bus SCSI devices. I doubt this will be appropriate for a networked device. > Thank you for your consideration. > > > Bob Russell > InterOperability Lab > University of New Hampshire > rdr@iol.unh.edu > 603-862-3774 --=_alternative 0031B81DC2256CB0_= Content-Type: text/html; charset="US-ASCII"
Bob,

First on behalf of the entire team thanks for the great job.

As for the two issues:

"Robert D. Russell" <rdr@io.iol.unh.edu> wrote on 16/01/2003 01:28:21: > Julian: > > Two more questions arose at the plugfest today, 15-Jan-2003. > > 1. A question arose as to the proper target response during the following > CHAP authentication exchange. > > Assume that: > I->T: CHAP_A=5 > T->I: CHAP_A=5 CHAP_I=<i> CHAP_C=<c> > worked correctly. The Initiator now sends: > I->T: CHAP_N=<n> CHAP_R=<r> CHAP_I=<i> CHAP_C=<c> > Further assume that the values CHAP_N=<n> and CHAP_R=<r> are > correct, so that the initiator is successfully authenticated by the > target and the target will allow it access to the target's resources. > > The problem arises because the target does not want to be > authenticated by the initiator, for whatever reason -- perhaps it has > no CHAP_N value to return for this initiator, or it has no secret > to use in calculating a value to return for CHAP_R, or whatever. > If the initiator had not sent the CHAP_I and CHAP_C keys, both > sides would have been happy and the login would proceed. But the > initiator did send those keys and the target does not want to see > them. So, what should happen? > > There appear to be at least the following 4 possibilities. > > a. The target replies: CHAP_I=Reject CHAP_C=Reject > This does not appear to be correct because the target is > expected to reply to the pair of keys CHAP_I, CHAP_C with > different keys (i.e., CHAP_N and CHAP_R), not the same keys. > Furthermore, the target already sent CHAP_I and CHAP_C > earlier in the exchange, so this would be sending the same > key twice. Certainly the initiator is not expecting to > receive CHAP_I and CHAP_C again. > > b. The target replies: CHAP_N=Reject CHAP_R=Reject > This does not appear to be correct because these are not > replies to offers of CHAP_N and CHAP_R, but to offers of > different keys (i.e., CHAP_I and CHAP_C). However, they > could be considered "replies" of sorts to the initiator's > "offer" of CHAP_N and CHAP_R, but that is stretching things. > > c. The target replies with a login reject, but it is not > clear what status code to use in this login reject pdu: > 0x0200 is not accurate, because it is not an initiator > error. > 0x0201 is not accurate, because the initiator WAS > successfully authenticated. > 0x0202 is also not accurate because the initiator > IS allowed access to the given target. > 0x0300 is not accurate, because it is not a target > error. > A new access code could be invented "The target will not > authenticate itself". > > However, in this present situation, a login reject is probably > not what the target wants to send, because it is willing to > allow this initiator to proceed without target authentication, > and thus the target does not want to terminate the login exchange. > > d. The target replies with no keys, and if the initiator offered > a transition out of security negotiation phase (i.e. T=1 and > NSG=1 or NSG=3) then the target accepts the transition. If the > initiator does not like going on without having the target > authentication, it can always just close the connection upon > receiving this reply. If the initiator did not offer a > transition out of security negotiation phase, the target can > only reply with T=0 and NSG=0, and will continue doing this for > all subsequent login requests until either the initiator offers > a transition or drops the connection. > > Solution d appears to be the most flexible, because the decision to > ask for target authentication was made by the initiator, and solution > d leaves it up to the initiator to decide whether or not it will > proceed when the target refuses to provide this authentication. > > In any case, there appears to be a need for some clarification > in the standard to cover this situation. > >

C is the behaviour we intended. As it does not look like another error response is warranted i will update
the code explanation to read:

The initiator could not be successfully authenticated, or target
authentication is not supported.

and make 11.1.4 read:

If the initiator authentication fails, the target MUST answer with a
Login reject with "Authentication Failure" status. Otherwise, if the
initiator required target authentication, the target MUSTeither
answer with a Login reject with "Authentication Failure" or reply
with:

CHAP_N=<N> CHAP_R=<R>

Obviously a carefully designed initiator should be prepared to handle case d although this is not the cannonical target behavior.
> 2. The question arose with regard to how an initiator maps a scsi > "bus reset" onto iscsi (this may be a legacy situation). Some vendor > initiators are simply doing a session logout, but other vendors claim > this is not sufficient, and that to correctly emulate a "bus reset" > the initiator needs to do a task management function TARGET WARM > RESET, or, since that is optional to implement, when it is not > implemented then the initiator needs to issue a task management > function LOGICAL UNIT RESET for all active LUNs in that session. > > Can/should there be a "note to implementers" on this in the standard, > so that a consistent result will be obtained in this situation? >
Rob Elliot has already commented on that and I can add little to his comments. Resets where intended as "big hammer" commands - and I assume that this is what happened on the old parallel bus SCSI devices. I doubt this will be appropriate for a networked device.
> Thank you for your consideration. > > > Bob Russell > InterOperability Lab > University of New Hampshire > rdr@iol.unh.edu > 603-862-3774 --=_alternative 0031B81DC2256CB0_=--