|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: iSCSI CONNECT messageFolks, 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
Home Last updated: Tue Sep 04 01:06:49 2001 6315 messages in chronological order |