SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


    [Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

    RE: iSCSI CONNECT message



    David,
    
    I am not proposing anything new or different to iSCSI, but am
    trying to support maintenance of the text-based URL that
    is already in the existing iSCSI draft.  Other protocols such
    as http, telnet, ftp, and others already have something similar.
    These protocols leverage DNS and use a text-based hostname to
    identify the destination, and I don't see why iSCSI should not.
    My messages have merely been posted to counter suggestions by
    some that it is not needed.
    
    Perhaps you are right in that the discussion has drifted
    from this original topic.
    
    But I would not underestimate the importance of proxies either.
    They are quite instrumental for providing security and redundant
    routing of data in many applications.
    
    Josh
    
    -----Original Message-----
    From: David Robinson [mailto:David.Robinson@EBay.Sun.COM]
    Sent: Monday, October 09, 2000 2:53 PM
    To: ips@ece.cmu.edu
    Subject: Re: iSCSI CONNECT message
    
    
    There has been a lot of discussion on adding support for poxies
    within the iSCSI protocol.  There have been a number of examples
    given, but I am questioning if this is an actual environment
    that we need to care about.
    
    If we look at most of the IETF protocols, they are designed to
    be a direct connection between two end nodes and they work
    well in the existing Internet structure.  What I fail to see is
    what is unique about the iSCSI environment that we need to
    add explicit support for proxies.
    
    The most common problem that is faced is how to traverse a
    firewall.  To handle this all we really need to do is to make
    the protocol well behaved with respect to using well known
    port numbers (NFSv2 with the portmapper requirement is a bad
    example, NFSv4 with a single well known port is a good example).
    As currently proposed, this should not be a problem with iSCSI.
    
    The second issue are NAT devices, as they are commonly deployed
    they map the source address on the way out and remap the destination
    on return. As currently defined, iSCSI does not initiate connections
    from the target for normal usage (I am ignoring 3rd party transfers
    as that is not what we are discussing now). We cannot have any
    security based on source address so that is not an issue. Therefore NAT 
    should not be an issue.
    
    The only case that is of any consequence is if you wish to go from the
    hostile side of a firewall into the private side.  In this case there
    are lots of security and management issues that each site will want
    to directly control.  An automated mechanism to drill into a firewall
    is not likely to be accepted by network adminstrators so I see no
    value of putting it into the protocol.  A more likely scenerio is
    that a specific address/port in the firewall will be mapped to
    a specific target inside the firewall and the mapping managed out
    of band.
    
    In a more general case, the iSCSI protocol from a connection perspective
    is relatively simple.  As such, to develop an out of band proxy or
    gateway should not be difficult and therefore I see no reason to
    add extra things into the protocol.
    
    So the core question is what is different about iSCSI that it needs
    protocol extensions that most other IETF protocols don't need?
    
    	-David
    
    Joshua Tseng/Nishan Systems wrote:
    > 
    > Jim,
    > 
    > I think we're getting our definitions straight, but I am still
    > not sure which model we're talking about (implicit or explicit).
    > If the iSCSI initiator identifies a target using an IP address,
    > placing that IP address after the target: text in the login message,
    > then a storage controller must exist at that IP address and there is
    > no proxy or tunneling operation.  On the other hand, if the iSCSI
    > initiator identifies a target using a DNS name, it could be talking
    > to a proxy OR the actual storage controller, and it does not need
    > to know is the case.  If you're saying it is "explicit tunneling"
    > when the DNS name has to be used and not the IP address, then okay,
    > this is explicit tunneling.
    > 
    > However, do note that if the iSCSI initiator identifies
    > a target with the DNS name, it should not care whether it is talking
    > to a proxy or the actual storage controller.  Unless I've overlooked
    > something, this should be completely transparent and non-material
    > to the iSCSI initiator, who shouldn't care either way.  If a proxy
    > resides at that IP address, he will understand the iSCSI login, set
    > up the appropriate TCP state tables, do its own DNS lookup, and
    > forward login the message on to the next proxy, or to the actual
    > storage controller.  But the original initiator shouldn't need
    > to be aware of this operation by the proxy.
    > 
    > I am neutral as to whether a CONNECT message should be included
    > in iSCSI for architecturual purity reasons, but I agree that
    > technically, the login message alone has enough information to
    > provide connectivity through proxies.  If we use a CONNECT: message,
    > then we don't need the DNS name in the login message.  I guess the
    > question is whether CONNECT and login should be done in the same
    > message.
    > 
    > Josh
    > 
    > -----Original Message-----
    > From: Jim Hafner/Almaden/IBM [mailto:hafner@almaden.ibm.com]
    > Sent: Monday, October 09, 2000 10:14 AM
    > To: ips@ece.cmu.edu
    > Subject: RE: iSCSI CONNECT message
    > 
    > Josh,
    > 
    > OK, I think we're getting to the crux of the matter (and getting our
    > definitions straight).
    > 
    > Implicit or transparent tunnelling:  NO *protocol specific* message is
    > needed to TCP-connect an iSCSI initiator to an iSCSI target.  (E.g., this
    > is the case, if an intermediary (proxy) aliases an ipaddress:port for a
    > target).
    > 
    > Explicit tunnelling: a protocol specific message, handled by the
    > intermediary, is required in order that a TCP connection be established
    > between an iSCSI initiator and iSCSI target (in those cases where the
    > implicit tunnelling is not sufficient).
    > 
    > I've heard both sides argued.  In my opinion, more people believe in the
    > second (Josh, Julo, ?).
    > 
    > Among those that believe the second is "where it's at", there is some
    > disagreement concerning what that message should be.  There are two
    > proposals:
    > (a) CONNECT message.
    > (b) iSCSI Login message with "Target:..." text field.
    > 
    > The iSCSI login message with "Target: ..." text is an "embedded" explicit
    > tunnel instruction AND much more (as it has context that is relevant only
    > to the iSCSI initiator and iSCSI target, not to the intermediary reading
    > the tunnel instruction).   In this case, the login message is carrying two
    > different kinds of information (one for the intermediary and one for the
    > iSCSI target at the end of the pipe).   I consider the iSCSI Login as
    > establishing context for the iSCSI initiator and the iSCSI target and NOT
    > for any intermediary.  [Maybe I'm wrong here!]
    > 
    > IMHO, the CONNECT message is nothing more or less than the explicit tunnel
    > instruction, and as such is the cleaner approach.   It is easy for an
    > intermediary to handle; it has no extraneous information; it's layered
    > bettered.
    > 
    > OK, now I'll try to shutup on this point.   If the WG thinks that iSCSI
    > login should provide this embedded tunnel instruction, so be it (but I
    > disagree!).
    > 
    > Jim Hafner
    > 
    > Joshua Tseng <jtseng@NishanSystems.com>@ece.cmu.edu on 10-09-2000 09:17:49
    > AM
    > 
    > Sent by:  owner-ips@ece.cmu.edu
    > 
    > To:   ips@ece.cmu.edu
    > cc:
    > Subject:  RE: iSCSI CONNECT message
    > 
    > Jim,
    > 
    > Whether we are talking about implicit or explicit tunneling depends
    > on your perspective.
    > 
    > >At the end of the note you say that my condition (A) "an initiator can
    > >ALWAYS open a connection to a target through normal TCP/IP mechanisms" is
    > >false. That is, we need explicit tunnelling.
    > 
    > I define TCP/IP mechanisms as IP address and port number (not DNS name).
    > Therefore, from the TCP/IP perspective, the target's IP address and port
    > number may not be visible to the initiator (although the DNS name is).
    > This is what you call explicit tunneling, if you are talking about TCP/IP
    > (address & port).
    > 
    > >Perhaps my choice of words is misleading.  By "open a connection", I did
    > >not mean "direct" connection but a connection (perhaps through multiple
    > >gateways/tunnels, etc.) that at least as far as the host "opensocket"
    call
    > >is concerned is transparent.
    > 
    > This is true.  From the perspective of the initiator host, the
    > tunneling is transparent.  The initiator host knows the target by
    > the DNS name, not the IP address & port.  The proxy is responsible
    > for the tunneling. operations.  I think this is what you mean by
    > implicit tunneling.
    > 
    > Josh
    > 
    > -----Original Message-----
    > From: Jim Hafner/Almaden/IBM [mailto:hafner@almaden.ibm.com]
    > Sent: Monday, October 09, 2000 8:33 AM
    > To: Joshua Tseng
    > Cc: ips@ece.cmu.edu
    > Subject: RE: iSCSI CONNECT message
    > 
    > Joshua,
    > 
    > I'm confused.
    > 
    > At the end of the note you say that my condition (A) "an initiator can
    > ALWAYS open a connection to a target through normal TCP/IP mechanisms" is
    > false. That is, we need explicit tunnelling.
    > 
    > Then in the beginning of the note you say that  DNS can get me deep into
    > the bowels of a private network.   To me that says that the world is
    > "transparent tunnelling".
    > Perhaps my choice of words is misleading.  By "open a connection", I did
    > not mean "direct" connection but a connection (perhaps through multiple
    > gateways/tunnels, etc.) that at least as far as the host "opensocket" call
    > is concerned is transparent.
    > 
    > Again, I'll state my case:
    > If we need explicit tunnelling (like "Target: ..." string in login), then
    I
    > contend the CONNECT message is better suited to that purpose.
    > If we don't need explicit tunnelling, then drop my CONNECT proposal (and
    > "Target"... string in login!).
    > 
    > Jim Hafner
    > 
    > Joshua Tseng <jtseng@NishanSystems.com>@ece.cmu.edu on 10-07-2000 09:52:47
    > AM
    > 
    > Sent by:  owner-ips@ece.cmu.edu
    > 
    > To:   ips@ece.cmu.edu
    > cc:
    > Subject:  RE: iSCSI CONNECT message
    > 
    > Hi Jim,
    > 
    > <snip..snip>
    > >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 is in the bowels of some private network, it should
    still
    > be addressable by DNS, as long as the root authority is talking to the
    > root ICANN servers.  Hence, the following DNS name:
    > 
    >      disk4.hpnetworkA3D.hpnetworkA3.hpnetworkA.hp.com
    > 
    > is resolvable on the public Internet as long as the DNS server for
    > "hp.com" is talking to the ICANN ".com" server, and the DNS server
    > for hpnetworkA.hp.com is talking to the server for hp.com, and....
    > 
    > Security concerns about DNS can be handled separately through independent
    > authentication and/or encryption mechanisms between iSCSI entities and/or
    > proxies.
    > 
    > <snip..snip>
    > >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).
    > 
    > Jim, I am in complete agreement here.  I would like to add that IPSec
    > provides
    > security between IP endpoints.  IPSec provides network level security,
    > while
    > TLS or iSCSI security can provide security for iSCSI entities, since
    > SSL, TLS, and iSCSI security only protects the TCP payload (or a subset of
    > the payload) and not the IP or TCP header, so it can be proxied without
    > changing the payload.  IPSec protects the IP header, so it can't be
    > proxied.
    > Rather, the proxy must authenticate and/or decrypt the IPSec before it can
    > forward the data to the next IP endpoint.
    > 
    >     network domain 1  |   network domain 2   |    network domain 3
    >                       |                      |
    > iSCSI initiator-----proxy1-----------------proxy2-----------iSCSI target
    >       |               |                      |                  |
    >       |<---IPSec----->|<-------IPSec-------->|<-----IPSec------>|
    >       |<---TCP 1----->|<-------TCP 2-------->|<-----TCP 3------>|
    >       |                                                         |
    >       |<-------------------iSCSI security or SSL/TLS----------->|
    >       |<-------------------iSCSI session----------------------->|
    >       |                                                         |
    >       |<--------------------SCSI session----------------------->|
    > 
    > I believe this security model is quite practical as well, since there
    > is no dependency between IPSec and iSCSI.  If the administrator wants
    > to protect the proxys, then IPSec can be added and the iSCSI layer and
    > your CONNECT mechanism will be completely ignorant of the presence or
    > nonpresence of IPSec (IPSec has its own key distribution mechanism).
    > IPSec can be managed separately and independently.
    > 
    > <snip..snip>
    > >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.
    > 
    > My experience with the Public Internet and corporate WANs says that A is
    > not true.  Sure, there will always be cases in a private network where the
    > administrator uses IP addresses only with no NAT, and is completely cut
    off
    > from the Public Internet (military/national defense concerns come to
    mind).
    > But if iSCSI is to be used through the Public Internet, then I believe
    > your B) might be the case.
    > 
    > Josh
    > 
    > -----Original Message-----
    > From: Jim Hafner/Almaden/IBM [mailto:hafner@almaden.ibm.com]
    > Sent: Thursday, October 05, 2000 9:33 AM
    > To: ips@ece.cmu.edu
    > 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
    


Home

Last updated: Tue Sep 04 01:06:44 2001
6315 messages in chronological order