Re: iSCSI: CONNECT message (was Naming/Discovery/URLs)

[meth@il.ibm.com]

Jim,
With the additions listed here, your CONNECT command has almost become the
iSCSI Login command.

- Kalman



"Jim Hafner/Almaden/IBM" <hafner@almaden.ibm.com> on 05/10/2000 02:19:32

Please respond to "Jim Hafner/Almaden/IBM" <hafner@almaden.ibm.com>

To:   csapuntz@cisco.com
cc:   ips@ece.cmu.edu (bcc: Kalman Meth/Haifa/IBM)
Subject:  Re: iSCSI: CONNECT message (was Naming/Discovery/URLs)





Costa,

I hadn't really thought too much about it (before I sent that note).

In the meantime, I had a couple of half-baked ideas.
1) extend the content of the CONNECT message:
    CONNECT: TargetID FOR: InitiatorID
This allows some identifier (yet to be defined) that can perhaps passthru
to the target or get munged along they way as well, which might be used by
any intermediary or endpoint to deny the connection up front (i.e., before
the iSCSI login gets rejected).

2) Add as a field within the TargetID or an additional field in the CONNECT
message some security context (which is valid for that initiator and that
gateway).

3) Assume that this message goes with an underlying security context.
E.g., these could be running within an SSL socket or an IPsec connection
which is invisible to the iSCSI CONNECT protocol but defines a security
context for that initiator to talk (at all) with that gateway.

One can argue that iSCSI security is an issue for initiator and target
context.  Hop security is an issue for each hop in the connection.

Does that provide food-for-thought?

Jim Hafner


csapuntz@cisco.com@csapuntz-u1.cisco.com on 10-04-2000 04:04:33 PM

Sent by:  csapuntz@csapuntz-u1.cisco.com


To:   Jim Hafner/Almaden/IBM@IBMUS
cc:   ips@ece.cmu.edu, csapuntz@cisco.com
Subject:  Re: iSCSI: CONNECT message (was Naming/Discovery/URLs)




Jim,

I like your CONNECT message proposal quite a bit. Making the CONNECT
message the first message of the TCP connection will simplify the
gateway's implementation.

However, I worry about gateways that would like to authenticate the
initiator prior to allowing the connection to proceed. Do you have any
thoughts on how to make that work well?

-Costa