Re: iSCSI: Questions about adding additional connections to a session

["Mallikarjun C." <cbm@rose.hp.com>]

An iSCSI connection is considered to be part of a FFP iSCSI 
session (one in Q3) when the connection enters the LOGGED_IN 
state.

The target session state Q2 represents the fact that the first iSCSI
connection is going through the login dynamics.  The connection itself
is not formally considered to be "part of the" session, because the 
session itself is not quite operational state.  Note that the session is 
essentially in a special situation here, and that's what state Q2
represents.  I tend to think that one doesn't have a need to use general 
purpose algorithms here - no active connections yet, no active tasks yet.

Hope that answers your question.
--
Mallikarjun

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

----- Original Message ----- 
From: "Bill Studenmund" <wrstuden@wasabisystems.com>
To: <ips@ece.cmu.edu>
Sent: Friday, November 15, 2002 4:55 PM
Subject: Questions about adding additional connections to a session


> I was wondering when exactly an additional connection becomes part of a
> session? When it is IN_LOGIN, or LOGGED_IN?
> 
> This question is coming from the angle of seeing if an attacker could
> disrupt a session by trying to log in additional connections. I'm also
> assuming it's an attacker that does NOT have the security secrets; an
> attacker with the secrets will look legitemate.
> 
> If the connection is added at LOGGED_IN, then there is nothing malicious
> an attacker can do. However, that doesn't seem to be how the spec is
> writen, and it means special-casing additional-connection logins. 'cause
> we have state Q2, which corresponds to the first connection of the session
> being in IN_LOGIN. It also breaks the clenliness of connections always
> being in their session, and of using itt to always find a task, including
> login, in a session.
> 
> The flip side is that if the extra connection is added at IN_LOGIN, then
> an attacker can impact an operational session. Note: I understand well
> that since I'm talking about an attacker without valid security
> credentials, this impact is bounded; at some point the target will reject
> the login.
> 
> At the bare minimum, assuming we enforce a limit on the number of
> connections, the rogue connection will count. Thus there will be a window
> in which the real initiator can't add new connections. Since it's real
> easy to keep fake connections going, this could be a long-term attack.
> 
> The other thing I could see is that if the connection is part of the
> session, then, unless care is taken, its itt is visable to the session.
> Thus the real initiator can't start a task with that itt. While it's
> feasable to shield the itt, you have to take care to do it.
> 
> Thoughts?
> 
> Take care,
> 
> Bill
> 
> 
>