Subject: RE: [Ips] iSCSI: When does a connection become part of a session?

From: [email-masked]
Date: Tue, 6 Jan 2004 16:50:32 -0700

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
 <mailto:[email-masked]> [email-masked]

---

From: "Mallikarjun C." <[email-masked]>
Date: Tue, 06 Jan 2004 18:06:35 -0800

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 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
> 
>     [email-masked] <mailto:[email-masked]>
>      

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

---

From: [email-masked]
Date: Wed, 7 Jan 2004 14:23:36 -0800 (PST)

> a couple of Pat's points.

And I'll comment on your comments. :-)

> the final successful login reponse.

Note: Joe was talking about MaxCmdSN and ExpCmdSN, and I agree there is
some question about them. However you mentioned "sequence numbers", which
can be taken to include StatSN too. As best I can tell, StatSN needs to be
present and respected at all times. Also, our target expects StatSN (and
ExpStatSN) to be handled correctly even in login. As StatSN is
connection-specific, I see no session nor security problems with this. :-)

I think perhaps we should split this question into two questions. 1) what
should the target put into MaxCmdSN and ExpCmdSN (and the initiator into
CmdSN), and 2) what should the target (or initiator) do with the CmdSN
(MaxCmdSN and ExpCmdSN) value(s) it gets.

I think (2) is the more important. I think both the initiator and target
should ignore CmdSN, MaxCmdSN, and ExpCmdSN on PDUs other than the last
one. For the initial login and for session reinstatement, I think the
CmdSN on the last Login Request (the one that triggers the transition to
FFP) should seed the target's idea of ExpCmdSN (and thus MaxCmdSN). Other
than that, I think it should be ignored. As login commands are immediate,
that makes sense.

As for (1), I think you're supposed to be shoving good values into the
response. Our target does. However with (2) in place, it wouldn't hurt if
the target just returned zero.

Does anyone see a security implication of the target leaking MaxCmdSN and
ExpCmdSN?

> successfully complete for the new instance.

Agreed.

Actually, we have two levels of session membership. One is "full" which a
connection gets when it goes to FFP. This is what everyone thinks of for
connections being in a session.

The other is a tentative membership, which we give new connections that
are members of an existing session. This isn't really covered in the spec.
We do this mainly so that we can limit the number of connections tied to a
session, and protect ourselves from DoS attacks. A connection in this
state can see what's happening in the session (it reports MaxCmdSN and
ExpCmdSN), but it can't impact the session. This is how we send back valid
MaxCmdSN and ExpCmdSN.

You can only have MaxConnections connections in FFP, and MaxConnections +
a fudge factor (currently 2) connections in FFP and in login.

> initiator attempts a connection reinstatement."

We take a third approach. If we don't already have MaxConnections + 2
connections in FFP and in login, we let a new login proceed. If we didn't
do something like this, then if you had a session with MaxConnections
connections, you could not do any ERL 2 recovery.

We let the second (connection reinstatement) login attempt proceed as
well.  When ever either of them reaches FFP, both the original connection
and the login that hasn't completed login get killed.

Yes, this is a violation in that the initiator appears to be violating
10.12.7. However if something went wrong with one reinstatement attempt,
we might get to this situation.

>  > completed rather than just a login request was received.

Agreed. It all happens at the end of login processing, just before the PDU
is sent indicating we're going to FFP.

> stage.  Ditto for session reinstatement.

Take care,

Bill

---

From: "Eddy Quicksall" <[email-masked]>
Date: Wed, 7 Jan 2004 17:50:45 -0500

Mallikarjun,

For case #1, that seems like a good idea but I don't think the spec says
this.

If an initiator is using MaxCmdSN and ExpCmdSN to update internal registers,
then suddenly forcing them to 0 may cause problems in current
implementations.

Eddy

---

From: "Robert D. Russell" <[email-masked]>
Date: Thu, 8 Jan 2004 14:27:05 -0500 (EST)

Mallikarjan:

I agree with Eddy and Bill -- the current standard requires that the
target fill in MaxCmdSN and ExpCmdSN with valid values on all
Login Response PDUs that it sends.  To do otherwise violates the
standard and is potentially not interoperable with an arbitrary
initiator.  However, applying the philosophy of "conservative in
what you send, liberal in what you receive", there is no apparent
reason for the initiator to check these values if it doesn't want to,
and not checking them will not violate the standard.

Bob Russell

---

From: "Mallikarjun C." <[email-masked]>
Date: Thu, 08 Jan 2004 16:33:00 -0800

>Also, our target expects StatSN (and

Agreed.

 > Does anyone see a security implication of the target leaking MaxCmdSN and

I think inadvertent revealing of current ExpCmdSN even before the
security negotiation stage allows an attacker to gain insights
into traffic volumes - he can periodically use this to get
snapshots of the ExpCmdSN value.

 > connections in FFP and in login, we let a new login proceed.

OK, this is one implementation approach.  I see this as a
superset of the required behavior I described.

 >If we didn't

Not necessarily.  I'd think if a TCP connection for CID=x is dead from
the initiator's perspective, the initiator can Logout CID=x on a
connection with CID=y, and do a task reassign for all tasks active
on CID=x.  If MaxConnections=1 and connection recovery is supported
and the target thinks the connection is still up though initiator
thinks it's dead, it would have to adopt an approach like yours.
My recollection is that the iSCSI spec in 3.2.1 says the following
for the same reason.

	"For error recovery purposes, targets and initiators
          that support a single active connection in a session
          SHOULD support two connections during recovery."

Mallikarjun

---

From: [email-masked]
Date: Thu, 8 Jan 2004 17:00:32 -0800 (PST)

> snapshots of the ExpCmdSN value.

I think I agree with you and Joseph (private EMail) that it would be
advantageous to not expost ExpCmdSN & MaxCmdSN. Unfortunately the spec
requires their inclusion at present. :-|

> superset of the required behavior I described.

Yes, it's a superset.

Oh, as for why it's + 2 as opposed to + 1 is a bit of over-conservativism
on my part. :-)

> the initiator's perspective, the initiator can Logout CID=x on a

I had in mind the case where you had MaxConnections connections and they
all died. Yes, it's extreme.

>           SHOULD support two connections during recovery."

Yep. That's why we came up with permitting a little more than
MaxConnections connections.

Take care,

Bill

---

From: "Mallikarjun C." <[email-masked]>
Date: Thu, 08 Jan 2004 17:08:32 -0800

Bob,

 >the current standard requires that the
 > Login Response PDUs that it sends.

I don't see "all", but as someone pointed out earlier,
the closest to this formulation is what I find in 10.13.5 -

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

I think a) there's a minor security exposure in revealing
ExpCmdSN (as I said in an earler email), b) initiator
has no reason to check/depend on ExpCmdSN from the
first Login.

I am not suggesting that we require changes in some
implementations - the spec isn't that explicit (no
MUST/SHOULD either way) to require changes.
-- 
Mallikarjun

Mallikarjun Chadalapaka

Robert D. Russell wrote:

>>>>                      CSG=0, T=1, NSG=1                 CSG=0, T=1,
>>
>>NSG=1
>>
>>>>                      CHAP_R=x
>>>>                      CHAP_N=x
>>>>
>>>>                      CSG=1, T=1, NSG=3                 CSG=1, T=1,
>>
>>NSG=3
>>
>>>>                      MaxRecvDSegLen=xxx
>>
>>MaxRecvDSegLen=xxx
>>
>>>>       the session, for the purposes of the response ExpCmdSN and
>>
>>MaxCmdSN
>>
>>>>       fields?
>>>>
>>>>       about the current command window for a session.  But when does
>>
>>the
>>
>>>>         about the presence of a connection by the initiator being
>>
>>spoofed
>>
>>>>       My inclination is to only consider the connection to be part of
>>
>>the
>>
>>>>    2) When is the target supposed to perform the connection
>>
>>reinstatement
>>
>>>>       My inclination is to only consider the connection to be part of
>>
>>the
>>
>>>>       sequence, and thus do connection reinstatement just prior to
>>
>>sending
>>
>>>>       the last login response.
>>>>
>>>>       connection ISID=1/TSIH=2/CID=3 is still in LoginOpNegotiation
>>
>>stage,
>>
>>>>       ISID/TSIH/CID, what is the target supposed to do?  Does
>>
>>'connection
>>
>>>>       reinstatement' apply also to a connection which is not yet in
>>
>>FFP?
>>
>>>>    I cannot find any text in the iSCSI spec that unambiguously
>>
>>addresses
>>

---

From: Paul Koning <[email-masked]>
Date: Fri, 9 Jan 2004 10:05:10 -0500

>>>>> "Mallikarjun" == Mallikarjun C <[email-masked]> writes:

 >> Also, our target expects StatSN (and ExpStatSN) to be handled
 >> correctly even in login. As StatSN is connection-specific, I see
 >> no session nor security problems with this. :-)

 Mallikarjun> Agreed.

 >> Does anyone see a security implication of the target leaking
 >> MaxCmdSN and ExpCmdSN?

 Mallikarjun> I think inadvertent revealing of current ExpCmdSN even
 Mallikarjun> before the security negotiation stage allows an attacker
 Mallikarjun> to gain insights into traffic volumes - he can
 Mallikarjun> periodically use this to get snapshots of the ExpCmdSN
 Mallikarjun> value.

Traffic analysis is probably more easily done by watching existing
connections than by active attack.  But I'd agree that this is
possible.

The other issue, I think, is that ExpCmdSN is one of the pieces of
state you need to succeed in connection hijacking.  For that reason,
it would be better not to reveal it until authentication is done.

As a design principle, it would make sense to say that the security
handshake portion of the login procedures contains NOTHING other than
the data required for the security machinery.

    paul

---

From: "Eddy Quicksall" <[email-masked]>
Date: Fri, 9 Jan 2004 12:21:47 -0500

It seems that everyone agrees that ExpCmdSN and MaxCmdSN should not be
reported during security stage. But the spec does not say that and does not
even imply that.

I think there needs to be an errata to the spec to specifically say this.

Eddy