RE: iSCSI - Login proposed change

["Julian Satran" <Julian_Satran@il.ibm.com>]

Thanks Bill,  Your point about leaking is well taken - I hope it will
resonate with those that favor as much debugging information as possible.

As for checking the target may do 1 in 2 things:

   really check with a nop
   just tell the initiator that a session is there and wait for him to come
   bake asking to blow it away (the X bit)

Julo

"Bill Strahm" <bill@Sanera.net> on 31-08-2001 00:09:32

Please respond to "Bill Strahm" <bill@Sanera.net>

To:   Julian Satran/Haifa/IBM@IBMIL
cc:   "Ips@Ece. Cmu. Edu" <ips@ece.cmu.edu>
Subject:  RE: iSCSI - Login proposed change



I'll make some comments on the text... I'll copy the current text from your
.txt file then a comment denoted by [bills][\bills]


Security associations established before the Login request are outside the
scope of this document although they may realize a related function (e.g.,
establish a IPsec tunnel).
[bill]
Establish IPsec SAs using IKE or other methods.  I do not see a need to
specify tunnel/transport modes etc.
[\bills]


When a target detects an attempt to open a new session by the same SCSI
initiator port (same InitiatorName and ISID) to the same target portal
group
it MUST check if the old session is still active.  If it is not active and
then the old-session must be reset by the target and a new session is
established. Otherwise, the Login MUST be terminated with a Login Response
of "Session already open with this initiator".
[bills]
How are we to determine that a TCP connection is active.  Do we send data
on
it and wait for a timeout (3 minutes ???) before we can continue.  If the
TCP connection is not active, and the TCP connection is shutdown, what do
you mean by reset by the target ?
[\bills]



Indicates the version supported (the highest version supported by the
target
and initiator). If the target does not support a version within the range
specified by the initiator, the target rejects the login and this field
indicates the lowest version supported by the target.
[bill]
I would rather see a failed login result in the socket closing, and not
leaking implementation details to the client.  Ok maybe I am a little
paranoid.
[\bills]


-----------------------------------------------------------------
Authentication| 0201 | 1   | The initiator could not be
Failure       |      |     | successfully authenticated.
-----------------------------------------------------------------
Authorization | 0202 | 1   | The initiator is not allowed access
Failure       |      |     | to the given target.
-----------------------------------------------------------------
[bills]
This is leaking interesting information.  Kind of like an operating system
telling you that it can't log you in (wrong password) vs. Unknown user...
This is information that doesn't need to be passed to the initiator that
can't authenticate.
[\bills]

If the Status Class is not 0, the initiator and target MUST close the TCP
connection.
[bills]
NO... The TARGET WILL close the connection.  Think about a DOS attack, I
just attempt a login, then leave my session open.  The TARGET MUST close
the
socket
[\bills]


Security MUST be completely negotiated within the Login Phase or provided
by
external means (e.g., IPSec).
[bills]
I thought we were providing security with IPsec...
[\bills]

Bill Strahm
Sanera Systems Inc.

-----Original Message-----
From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
Julian Satran
Sent: Thursday, August 30, 2001 9:35 AM
To: ips@ece.cmu.edu
Subject: iSCSI - Login proposed change


I am not sure that I sent the right set of proposed changes - here is a
complete one:

Julo

(See attached file: Login-changes.txt)