SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


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

    iSCSI gateways, proxies, etc.



    Folks,
    
    We've been going around on the topic of these for
    a while without much visible progress.  I'd like
    to suggest a means to extricate ourselves from this
    situation.
    
    Jim Hafner correctly observed that there is a
    fundamental difference between:
    - A gateway that always exposes TCP/IP addresses for the
    	iSCSI targets behind it, and
    - A gateway that must be dynamically configured to
    	obtain connectivity to the iSCSI targets behind it.
    We don't need to do anything to support the first class
    of gateway.  For the second class, there's another
    crucial distinction in the second category, namely
    between in-band and out-of-band configuration mechanisms.
    
    From a protocol specification viewpoint, out-of-band
    configuration mechanisms are both more flexible and
    easier to deal with.  Flexibility comes from the
    variety of possible mechanisms, for example: 
    
    [A] A NAT monitors DNS traffic to/from a DNS server in
    private address space behind the NAT.  When a DNS reply
    containing a translation is intercepted, the NAT sets up
    an external IP address that maps to the internal IP address
    in the DNS reply, and substitutes that external IP address
    for the internal IP address before forwarding the reply
    (in addition to the usual translation operations performed
    on the header).  Credit/apologies to whomever (Joshua Tseng?)
    originally described this example.
    
    [B] An encrypting firewall does not provide connectivity
    to hosts behind the firewall for general traffic outside
    the firewall.  If an encrypted IPsec tunnel is set up in
    accordance with the firewall's policies, then connectivity
    to some of the hosts behind the firewall is provided for
    traffic using the tunnel in accordance with the firewall's
    policies.
    
    Note that both the NAT and the firewall have to be configured
    by some means, and that both of these mechanisms work without
    any changes to the iSCSI protocol, as both the DNS lookup and
    IPsec tunnel setup happen before the first iSCSI packet is sent.
    The fact that we don't have to specify anything makes these
    easier to deal with, and gives iSCSI compatibility with all sorts
    of things we haven't thought of (yet).
    
    Both the current URL mechanism and the discussion of the
    CONNECT message are in-band configuration mechanisms.  In the
    context of proxy configuration (Julian's concern about views
    is a different, but related issue), this has been turning
    into a tarpit on the list.  From what I can see, the issues
    here are similar to the issues in naming for 3rd party
    commands, something that is not in particularly good shape,
    despite T10's best efforts. I find it hard to believe that
    people want to repeat T10's experience with this from scratch
    for iSCSI, but ... I see three possible paths forward
    from which the WG needs to choose:
    
    (1) Rely on out-of-band gateway/proxy configuration.
    (2) Reference T10's 3rd party naming formats for target naming.
    	This WG would still define an iSCSI 3rd party naming format
    	and recommend it to T10, and could define ways of using
    	T10 naming formats with Internet protocols (e.g., LDAP).
    (3) Invent new ways of naming targets.
    
    I'm inclined to dismiss (3) as being out-of-scope, because
    if this really is analogous to 3rd party naming, then it needs
    to be left to T10 and iSCSI should follow what T10 adopts, BUT
    I'm willing to listen to counter-arguments.
    
    (1) and (2) are complementary rather than exclusive, but the
    protocol gets simpler if we don't have to do (2).  The 3rd party
    naming recommendations to T10 are needed regardless.
    
    Ok - comments are solicited, as I do intend to try to call
    consensus on this set of issues to make progress.
    
    Thanks,
    --David
    
    ---------------------------------------------------
    David L. Black, Senior Technologist
    EMC Corporation, 42 South St., Hopkinton, MA  01748
    +1 (508) 435-1000 x75140     FAX: +1 (508) 497-8500
    black_david@emc.com       Mobile: +1 (978) 394-7754
    ---------------------------------------------------
    
    


Home

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