Re: iSCSI CONNECT message

[julian_satran@il.ibm.com]

Jim,

I am not sure how to formulate this to avoid too much flake on list.

IMHO anything that precedes the iSCSI login is outside the scope
of this transport specification proper. The login establishes the context.
If there is a way for the two endpoints to build a TCP connection then we
can start
an iSCSI session.

In practical terms the topology I labeled a is a concatenation of TCP links
connected
through gateways. It will "process" all TCP packets (change addresses,
sequence numbers etc.).
The amount of packet manipulation such a scheme does imply is higher that
in case b
and it has to maintan a lot of state (error recovery is local on each
element of the chain).
As such its performance is low and it is used only in cases in which there
is no better
solution (ALG use such a scheme).
To add some more pain - it also violates our basic assumption that TCP is
an end-to-end
protocol and has implications that go far beyond the connection phase.


Due to the same reasons most tunneling schemes intervene only in the
"connection"
building phase and then let the packets flow through with recovery done
end-to-end.
Obviously level-4 routing/switching still makes some decisions based on
level-4 data
(the flow) but leaves recovery end-to-end (they might make queueing or pass
drop decisions
for QoS or security and even change addresses).
This is the scheme I called b - and this is a scheme widely used by
firewalls, gateways and
proxys.

For b I see nothing missing in the current login information. Login is
sequence made to establish connections
and a security context.

The sequence looks like:

login - request
text -req
text -resp
.
.
.
text-req
text-resp
login - response

Up to now we though that text-req/resp
will be used to establish a security context followed
by a sequence that will establish the working parameters for the session.

It was mentioned that we should consider a mechanism similar to HTTP
redirection - but I saw very little incentive for this.

Unlike HTTP establishing an iSCSI session is a rare event. With a session
alive there is no way you can change end-point addresses. And if the
session
is not alive then you have probably enough time to propagate the
information
to all interested administrative domains (and I assume that there fewer
of those than domains hold an http URL).

Is CONNECT a function we want to add? What for? Where in this sequence?

Julo




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

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

To:   ips@ece.cmu.edu
cc:    (bcc: Julian Satran/Haifa/IBM)
Subject:  Re: iSCSI CONNECT message




Folks,

Let's see if I can handle a bunch of these questions at once.  I'll admit
upfront that I'm not the most knowledgeable about how the IP network works,
how DNS works, how tunnelling works, etc.  As a consequence, I may be using
terms well-known in the network community in the wrong way.  Please correct
me if I am.

Definition: I'm using the term gateway here to mean any device (proxy,
etc.) with the following properites:
1) it sits between an initiator and a target (an implementation of a proxy
or any other sort of firewall)
2) it obscures the ipname/address of the target on its back-side from the
initiator on the front-side.
3) it is NOT an iSCSI target device; it is a device that enables connecting
two iSCSI devices
(in effect, a gateway is a device that must provide some sort of
tunnelling).  Or is "intermediary" a better term here?

Tunneling:  As Costa said, the only standardized tunnelling mechanism
defined (AFAIK) is in specific protocols like the HTTP GET URL protocol.
As I mentioned in my note, I'm suggesting that perhaps an analogous
function is required here.

Use of DNS: there may be security concerns here (about DNS itself).  But
this also assumes that every iSCSI target has a "public" ipname (or perhaps
ipname:port combo).This may or may not be the case (correct?) if the
controller lives deep in the bowels of some private network.

If the controller has a public IPname, then the normal mechanisms for
connecting to it should work (even through gateways as described by
Joshua).  In my proposal, the CONNECT message effectively gets delivered
directly to the target in the first step.

Is this the same as the login?  To me, the login is an initiator to target
operation, to validate the iSCSI to iSCSI layer connection end-to-end (once
the pipe is open for them to talk to each other).  iSCSI security may be
completely independent of the link security (e.g., that the gateway might
want to impose).  The iSCSI login security involves a context that is only
relevant to the two end points as iSCSI entities, not as TCP/IP entities
(i.e., at a different layer).  The link security is potentially independent
from the iSCSI security context and is a function of the two ends of an
intermediary link (as TCP or IP entities).  The CONNECT message then is the
instruction to the intermediary to request it's tunnelling services.
This gets to one of David's concerns about tunnel autoconfig.  My third
option (my favorite) for security in the CONNECT was effectivly leveraging
whatever tunneling autoconfig policies are in place between the two
endpoints of a hop (in the picture below, G1 and G2 may have their own
policies, which I assume they impose on each other, independent, perhaps,
of the type of traffic).

Julo's Topology(a):  I---G1---G2---G3---T

This is exactly the topology that Daniel and I discussed and the CONNECT
message was supposed to enable.  If this is "of little interest", then I
don't see the point of the CONNECT, either.  It may be that a gateway is
just a passthru or a proxy or any other mechanism that the gateway utilizes
in order to provide the services (QoS, security, etc.) that motivated the
placement of that gateway in that spot in the first place!

David also mentioned an issue about QoS and such.  If I'm a gateway doing
all this obsuring, then perhaps I'd like to have policies for QoS as well.
Whether they are blind to the type of traffic (iSCSI or http or ...), is a
different issue.

In short, I think I can summarize the issues:
A) if an initiator can ALWAYS open a connection to a target through normal
TCP/IP mechanisms, then there is no need for my proposal. (I didn't think
this was necessarily possible).  Additionally, this assumption implies that
target naming is pure and simply an ipname:port and nothing more (that is,
I don't need URLs or any other complicated naming scheme).
B) if NOT, then my proposal defines a means whereby that initiatial
connection can get established, in order that the rest of the iSCSI process
can begin. I think you need a two-part naming mechanism in this case.  If
one was enough, then option A holds.

Did I miss anybody's questions?  Am I completely off base here?  Can
somebody say whether (A) holds?  Does (A) hold with the requisite security
requirements (or is that a separate issue)?

Jim Hafner