SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


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

    RE: SCSI URL scheme [WAS: Re: iSCSI: 2.2.6. Naming & mapping]



    I'd like to chime in with my agreement, worded a bit differently:
    
    1) I believe large systems (spanning the Internet) will at some point 
       need some form of proxy/gateway/NAT because:
        - addresses in one realm won't be legal in another realm
        - the owner of a realm does not want any of its internals revealed
        - those internals are changeable, and the owner wants to isolate 
           outsiders from the impact of those changes.
    
    
    2) Authentication, privacy (a.k.a. encryption), etc are indeed a separate
       issue from end-point naming.
    
    2a) Information obtained by observing and parsing an embedded identifier 
       should have no impact on overall security - We aren't relying on 
       "security by obscurity," after all.
    
    2b) ditto, whether those identifiers are human-readable or not.
    
    
    3) Let's assume that the available tools and techniques of DNS, URLs,
       etc are there to be leveraged, and let's see where it takes us.
       I'd rather spend our time delivering a robust application, 
       rather than inventing optimized replacements for common 
       Internet tools. 
         
    - Milan Merhar
    
    
    
    -----Original Message-----
    From: Joshua Tseng [mailto:jtseng@NishanSystems.com]
    Sent: Tuesday, October 03, 2000 2:43 PM
    To: Douglas Otis; ips@ece.cmu.edu
    Subject: RE: SCSI URL scheme [WAS: Re: iSCSI: 2.2.6. Naming & mapping]
    
    
    Doug,
    
    I'm not sure we understand each other anymore.  I will just carefully
    restate my points, and leave it at that.
    
    1)  URL's (domain name & path) are needed in the iSCSI transport to
    support proxy services.  Because of the prevalence of NAT, proxies
    are necessary.
    
    2)  Authentication is a separate issue and has nothing to do with
    identifying the final destination device/LUN/WWN of the iSCSI traffic.
    A separate key distribution server may improve scalability of the
    authentication mechanism, but this has nothing to do with addressing
    and routing of iSCSI traffic.
    
    3)  A LANE-type architecture for addressing and routing of iSCSI
    traffic is a bad idea due to scalability and management issues.  
    The iSCSI transport must have imbedded routing information in the
    form of a URL, to allow proxies and destination nodes to route
    iSCSI traffic to its final device/LUN/WWN destination.
    
    Best regards,
    Josh Tseng
    
    -----Original Message-----
    From: Douglas Otis [mailto:dotis@sanlight.net]
    Sent: Tuesday, October 03, 2000 11:13 AM
    To: Joshua Tseng; ips@ece.cmu.edu
    Subject: RE: SCSI URL scheme [WAS: Re: iSCSI: 2.2.6. Naming & mapping]
    
    
    Joshua,
    <snip>
    
    > What you describe might be possible (although I still think it's a bad
    > idea) if the entire Internet, including all public and private networks,
    > were in a single consolidated address space.  But the fact is we are
    > running out of address space, and there is something called NAT defined
    > in RFC1918.  Who knows, with IPv6, this may change, or it might not.  But
    > it is a reality today.  To operate in an environment with NAT, you need
    > proxies.  There's no way around it.  A client in a public network using
    > registered IP address space should NEVER see a 10.0/8 address.  It should
    > NEVER talk to a 10.0/8 address, and it shouldn't even have a 10.0/8
    > address entry in its routing table.  It must first talk to a dual-homed
    > proxy with at least one leg using registered IP address space, in order
    > to communicate with a host with a 10.0/8 address.  In this environment
    > and with these restrictions, I don't understand how you can remove the
    > involvement of the proxy in the process of what you call "authentication".
    >
    > BTW, it's not just http--e-mail and many other applications today make
    > extensive use of proxy relays as well.
    >
    > Josh
    
    Yes, and most enterprise environments include a NAT.  Even homes with DSL
    include NAT.  A few may even use a proxy.  That does not mean private
    addresses of the target can not be shared at the time of authentication.  I
    would have expected such an exchange.  As most of these things work, such
    permission is in the form of a lease.  I would also expect as the map is
    declared, mapping screens are established based on the permission discovered
    at the time of authentication.  Before and not during use.  Using a binary
    address does not mean PUBLIC addresses.  It may not even be IP.  It could be
    SCSI address or perhaps an encoded address.  You do not want SCSI to look
    like an HTTP server.  Especially if you wish this application to scale, you
    do not want to be doing in-band name lookup and authentication.
    
    Pleases, this is not a web server, it is a portal to SCSI devices.  A client
    does not need to use a name to get a proxy to listen, try just typing the IP
    of a web site.  The proxy will forgo the lookup.  Name lookup is simply a
    convenience for humans.  You would not want to depend on a round-robin
    selection of IPs from DNS should there be more than one such IP.  How would
    you select the alternative IP, the next in the list?  All these parameters
    can be concisely defined in the authentication exchange.  I can not see why
    someone would wish to place a name on their SCSI portal but they could.  The
    only name that needs to exist is the authentication server.  I would not
    expect an address beyond the SCSI portal to be PUBLIC IPs.  I would not
    expect them to be IP.  LDAP is good at doing symbolic lookup.  Let it do the
    work at the time of authentication.  Don't invent a SCSI browser.
    
    Doug
    


Home

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