Subject: Questions about adding additional connections to a session

From: Bill Studenmund <[email-masked]>
Date: Fri, 15 Nov 2002 16:55:44 -0800 (PST)

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

---

From: "Mallikarjun C." <[email-masked]>
Date: Fri, 15 Nov 2002 19:09:33 -0800

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

---

From: "Julian Satran" <[email-masked]>
Date: Sat, 16 Nov 2002 06:47:37 +0200

Bill,

You want to work both without a security envelope and to resist an active 
attack...
If you keep letting in in your hypothetical attacker time after time then 
you certainly  have a pretty weak security.
This type of attacks are not uncommon on servers with a limited number of 
threads and the can be stopped by blocking the intruder through some other 
means (IP address filtering etc.). 
And regardless of when you declare a connection in session and count it in 
the limit - this type of attack will consume some resources if it reaches 
your system.

Julo

Bill Studenmund <[email-masked]>
Sent by: [email-masked]
16/11/02 02:55
 
        To:     <[email-masked]>
        cc: 
        Subject:        Questions about adding additional connections to a 
session

Thoughts?

Take care,

Bill

---

From: Bill Studenmund <[email-masked]>
Date: Sat, 16 Nov 2002 20:14:56 -0800 (PST)

> You want to work both without a security envelope and to resist an active

Agreed.

> means (IP address filtering etc.).

Just to run with the idea, say the attacker is a hostile process on the
initiator? :-)

> the limit - this type of attack will consume some resources if it reaches

Agreed.

Take care,

Bill

---

From: Bill Studenmund <[email-masked]>
Date: Sat, 16 Nov 2002 22:50:10 -0800 (PST)

> Hope that answers your question.

Yep, it does.

Thanks!

Take care,

Bill