Subject: [Ips] old mail revisited - when should the ExpCmdSN and MaxCmdSN become valid during a session

From: Julian Satran <[email-masked]>
Date: Sun, 27 Nov 2005 18:19:18 +0200

The attached exchange was recently brought to my attention.
It refers to the values ExpCmdSN and MaxCmdSN. The RFC3720 text does not 
support the assertion that ExpCmdSN and MaxCmdSN should have their 
"correct" values only after the connection joins the session (there is no 
exception mentioned for the login phase for those commands). Although 
there is some value in their arguments Login non-final responses are not 
stated as differing from the final or any other immediate sequence. There 
are no real  "security" implications on revealing the 2 numbers (they can 
be seen by a spoofer later) and it will hurt implementations that have a 
simple "bad packet filter" to flushes out all the bad packets and is 
usable for every response. I am sorry for not having seen this exchange 
earlier.

Julo

-------------------------------------------------------------------------------
Re: [Ips] iSCSI: When does a connection become part of a session?

To: [email-masked]
Subject: Re: [Ips] iSCSI: When does a connection become part of a session?
From: "Mallikarjun C." <[email-masked]>
Date: Tue, 06 Jan 2004 18:06:35 -0800
Cc: [email-masked], [email-masked]
In-reply-to: <
[email-masked]>
List-help: <mailto:[email-masked]?subject=help>
List-id: IP Storage <ips.ietf.org>
List-post: <mailto:[email-masked]>
List-subscribe: <https://www1.ietf.org/mailman/listinfo/ips>,<
mailto:[email-masked]?subject=subscribe>
List-unsubscribe: <https://www1.ietf.org/mailman/listinfo/ips>,<
mailto:[email-masked]?subject=unsubscribe>
References: <
[email-masked]>
Sender: [email-masked]
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) 
Gecko/20030624 Netscape/7.1 (ax)

Let me attempt to answer Joe's questions and clarify
a couple of Pat's points.

On Joe's #1, I agree with Pat's comments - there is no
need to return valid values of sequence numbers before
the final successful login reponse.

On Joe's #2, Joe said:
  "My inclination is to only consider the connection to be part of the
   connection when it has successfully completed the entire login
   sequence, and thus do connection reinstatement just prior to sending
   the last login response."

This is indeed the intent.  Connection reinstatement
should be performed only when the target is ready to
signal the final approval for the login attempt on the
connection in question.  A target cannot perform the
reinstatement for an old CID instance unless it arrived
at a new FFP connection with the same CID (clearly, I
think, stated in 5.3.4), i.e. unless login process is
successfully complete for the new instance.

On Joe's #3, the general approach should be to allow
new login attempts to proceed as long as the total
number of connections is < MaxConnections.  At the
time the target moves a connection to FFP, it should
consider any earlier instance of the same CID to have
been reinstated and drop the old instance (10.12.7).
I thus would not recommend the approach you're leaning
towards.  Note however that the 10.12.7 text assumes
that the initiator is well-behaved - if the initiator
is in fact launching multiple login requests at the
same time for the same CID, then it's violating the MUST
requirement in 10.12.7 - "The initiator connection
state MUST be CLEANUP_WAIT (section 7.1.3) when the
initiator attempts a connection reinstatement."

On Pat's points -

> "Successful connection/session reinstatement" might be
> read to mean that the login for the new session successfully
> completed rather than just a login request was received.

Yes, as clarified above.

>However note that a failed connection
> reinstatement causes T15 which moves the session from LOGGED_IN to
> CLEANUP_WAIT so a failed attempt would still disrupt an active
> connection.

True, that was intended.  However, there are two state
machines here (CSM-C and CSM-I, borrowing 7.2 terminology),
and note that Pat's clarification applies to CSM-C (i.e.
the state machine representing the old instance).  The CSM-I,
the new state machine the login is happening on, OTOH,
takes the T7 transition from IN_LOGIN to FREE.

A "failed connection reinstatement", however, should have
been defined in the spec (as Pat says).  For a connection
reinstatement effort to be considered "failed" and thus
cause a state change to CSM-C on the target end, the effort
should have progressed (and failed) beyond the SecurityNegotiation
stage.  Ditto for session reinstatement.

Hope that helps.
--
Mallikarjun

Mallikarjun Chadalapaka
Networked Storage Architecture
Network Storage Solutions
Hewlett-Packard MS 5668
Roseville CA 95747
cbm [at] rose.hp.com

[email-masked] wrote:

Joe,
You raise interesting questions. For the first two items, I think I agree 
that your inclinations are sensible though not necessarily supported in 
the iSCSI draft. On the third one, I'm not sure.
On 1 - treatment of MaxCmdSN and ExpCmdSN during login, it would make 
sense to withhold valid values for these fields at least until the 
security phase of Login has completed and there doesn't seem to be any 
reason to provide them before the last login. However, I don't find 
anything in the spec that supports doing this. Under the description of 
status class for Login Response, it says

The numbering fields (StatSN, ExpCmdSN, MaxCmdSN) are only valid if 
Status-Class is 0.

which implies that the fields are valid when Status-Class is 0 including 
during the security phase.

On 2 - at what point in a connection reinstatement login does the old 
connection get closed, 5.3.4

The Login request performs the logout function of the old connection if an 
explicit logout was not performed earlier.

which appears to indicate that it is the reception of the initial Login 
Request PDU that causes the logout. As you suggest, actually operating 
this way would leave one vulnerable to denial of service type attacks. It 
makes more sense to wait until at least security phase has completed to do 
the logout. It may make sense to wait to do close the old connection until 
ready to send the final login response as you suggest because this login 
may not succeed. However for resource constrained implementations the 
reinstated connection may need resources allocated to the existing 
connection.

The state machine description might be hoped to provide more detail, but 
they don't seem to be entirely consistant. The definition in 7.1.2 for T8, 
(T13 and T18 have similar text)

-target: An internal event of sending a Logout response (success) on 
another connection for a "close the session" Logout request was received, 
or an internal event of a successful connection/session reinstatement is 
received, thus prompting the target to close this connection cleanly.

"Successful connection/session reinstatement" might be read to mean that 
the login for the new session successfully completed rather than just a 
login request was received. However note that a failed connection 
reinstatement causes T15 which moves the session from LOGGED_IN to 
CLEANUP_WAIT so a failed attempt would still disrupt an active connection. 
There doesn't seem to be any definition provided for successful and failed 
connection reinstatement. In the description of connection cleanup state 
transitions (7.2.2, M4) successful implicit logout appears to be defined 
as having reached the state LOGGED_IN on the new connection.

On 3, I think connection reinstatement only applies to a connection that 
has completed login. The state transitions for the target connection state 
machine only allow for implicit logout in the LOGGED_IN state and in the 
states that follow it. The transition from IN_LOGIN to FREE, T4, doesn't 
make any mention of implicit logout or connection reinstatement. Time out 
or the transport going away are the things that get you from IN_LOGIN to 
FREE. One might get a second login attempt if there was a problem on the 
initial connection such as the network going down but it is probably okay 
to not accept it until the original attempt has disappeared due to time 
out or closure of the transport connection. Lack of resources would be a 
reasonable response. If one does have the resources, I'm not sure it is a 
necessary response.

Regards,

Pat

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of Pittman, 
Joseph
Sent: Tuesday, January 06, 2004 1:02 PM
To: [email-masked]
Subject: [Ips] iSCSI: When does a connection become part of a session?

I'm working on adding support for multi-connection sessions to an
iSCSI target implementation, and I have some questions about when
a new connection is considered to be part of a session.
Consider this set of login request/response exchanges. Assume
that there already exists a session with ISID=1/TSIH=2 on the
target, so the initiator is trying to add a connection to an
existing session. The session is operating at ErrorRecoveryLevel=2,
and there already exists a connection with CID=3 within that
session, so connection reinstatement is required.
Initiator sends Target responds
------------------------- --------------------------
Exchange 0 LOGIN_REQ LOGIN_RESP
ISID=1, TSIH=2, CID=3 ISID=1, TSIH=2,
CID=3
CSG=0, T=0 CSG=0, T=0
AuthMethod=CHAP AuthMethod=CHAP
** Connection now in SecurityNegotiation phase
Exchange 1 LOGIN_REQ LOGIN_RESP
ISID=1, TSIH=2, CID=3 ISID=1, TSIH=2,
CID=3
CSG=0, T=0 CSG=0, T=0
CHAP_A=5 CHAP_A=5
CHAP_I=x
CHAP_C=x
Exchange 2 LOGIN_REQ LOGIN_RESP
ISID=1, TSIH=2, CID=3 ISID=1, TSIH=2,
CID=3
CSG=0, T=1, NSG=1 CSG=0, T=1, NSG=1
CHAP_R=x
CHAP_N=x
** Connection now in LoginOperationalNegotiation phase

Exchange 3 LOGIN_REQ
ISID=1, TSIH=2, CID=3 ISID=1, TSIH=2,
CID=3
CSG=1, T=1, NSG=3 CSG=1, T=1, NSG=3
MaxRecvDSegLen=xxx MaxRecvDSegLen=xxx
** Connection now in FullFeaturePhase phase
** Connection has been added to the session ISID=1/TSIH=2
** Previous connection ISID=1/TSIH=2/CID=3 has been logged out for
recovery
Given this example, here are a few questions:
1) When is the target supposed to consider the connection as part of
the session, for the purposes of the response ExpCmdSN and MaxCmdSN
fields?
In general, the ExpCmdSN and MaxCmdSN fields contain information
about the current command window for a session. But when does the
target consider the connection to be part the session:
- Before security negotiation is complete? If true, then this
tells a spoofing initiator (who will eventually fail
authentication)
about the presence of a connection by the initiator being spoofed
- After security negotiation is complete?
- Only in the last login response/transition to FFP?
My inclination is to only consider the connection to be part of the
connection when it has successfully completed the entire login
sequence, and thus to return the joined session's ExpCmdSN and
MaxCmdSN only in the last login response.

2) When is the target supposed to perform the connection reinstatement
algorithm, including the implicit logout for recovery of the
existing ISID=1/TSIH=2/CID=3 connection?
- Before security negotiation is complete? Surely not, because
this allows a denial of service attack.
- After security negotiation is complete?
- Just before sending the last login response/transition to FFP?
My inclination is to only consider the connection to be part of the
connection when it has successfully completed the entire login
sequence, and thus do connection reinstatement just prior to sending
the last login response.
3) Here's a more esoteric question: if the login sequence for one
connection ISID=1/TSIH=2/CID=3 is still in LoginOpNegotiation stage,
and the initiator starts another connection with the same
ISID/TSIH/CID, what is the target supposed to do? Does 'connection
reinstatement' apply also to a connection which is not yet in FFP?
My inclination is for the target to consider the second login
request as spurious, and to return NotEnoughResources (since I
am unwilling to dedicate two 'new connection' slots to the same
ISID/TSIH/CID combination).

I cannot find any text in the iSCSI spec that unambiguously addresses
these issues. Am I missing anything? If not, would any of the
authors care to give guidance?
Thanks in advance for any help.
--
Joe Pittman
[email-masked] <mailto:[email-masked]>

_______________________________________________
Ips mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ips

Follow-Ups: 
Re: [Ips] iSCSI: When does a connection become part of a session? 
From: "Eddy Quicksall" <[email-masked]>
Re: [Ips] iSCSI: When does a connection become part of a session? 
From: [email-masked]
References: 
RE: [Ips] iSCSI: When does a connection become part of a session? 
From: [email-masked]
Prev by Date: RE: [Ips] iSCSI: When does a connection become part of a 
session? 
Next by Date: [Ips] IPS Security draft change to SLP text 
Previous by thread: RE: [Ips] iSCSI: When does a connection become part of 
a session? 
Next by thread: Re: [Ips] iSCSI: When does a connection become part of a 
session? 
Index(es): 
Date
Thread

_______________________________________________
Ips mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ips

---

From: "Mallikarjun C." <[email-masked]>
Date: Tue, 29 Nov 2005 17:56:57 -0800 (PST)

MaxCmdSN is a dynamic variable anyway, so it can be
increased to reflect the true target capabilities once
in the FFP.  But I agree that both ExpCmdSN and
MaxCmdSN should be always "correct" in that the
standard semantics apply.  I now see how my previous
reply could have been read.

If someone believes that RFC3720 is ambiguous in this
area, please point out the section & text and we can
clarify the referenced in the implementer's guide.

Mallikarjun

> List-help:
> <mailto:[email-masked]?subject=help>
> List-subscribe:
> <https://www1.ietf.org/mailman/listinfo/ips>,<
> List-unsubscribe:
> <https://www1.ietf.org/mailman/listinfo/ips>,<
> stage.  Ditto for session reinstatement.
=== message truncated ===>
_______________________________________________
> https://www1.ietf.org/mailman/listinfo/ips

		
__________________________________ 
Yahoo! Mail - PC Magazine Editors' Choice 2005 
http://mail.yahoo.com