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



    Joshua Tseng,
    I think that was a good note.
    To summarize in my own words:
       We need more then the normal TCP/IP addressing with a DNS.  It meets
       many needs but not all (ESP. Private Networks)
       We need an additional method to pass through Private Network Gateways
    
    It seems the Current Draft gives us a way to address item 2 above, via the
    Login Text Field "Target:".
    I have had other opinions that we do not need a separate "Connect" command,
    that the current Login (with Text Field "Target:") is sufficient.
    
    
    .
    .
    .
    John L. Hufferd
    Senior Technical Staff Member (STSM)
    IBM/SSG San Jose Ca
    (408) 256-0403, Tie: 276-0403
    Internet address: hufferd@us.ibm.com
    
    
    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:46 2001
6315 messages in chronological order