RE: iSCSI: URL scheme

["John Hufferd/San Jose/IBM" <hufferd@us.ibm.com>]

Douglas Otis,
Thanks for responding.

First let me say that LDAP is wonderful and useful in many ways.  Now
perhaps we can get that behind us.

What I was hoping for was a step by step  process so that everyone could
conclude what was a problem and what was not.

I was trying to keep things directed and pointed to the details of using
what currently exists today in IP networks so that we can remove any
misunderstandings.  So I think much of what you stated will be useful.

We have been spending a lot of time trying to name LUs and mixing it with a
lot of other things.  If we can orderly step through this stuff, then we
can appropriately ask what is missing and what we can or should do about
it.

Again, thank you very much for your response. Any one else?

(By the way I updated the thread Name to reflect the iSCSI part of the
Workgroup.)


.
.
.
John L. Hufferd


"Douglas Otis" <dotis@sanlight.net> on 10/03/2000 05:54:14 PM

To:   John Hufferd/San Jose/IBM@IBMUS, <ips@ece.cmu.edu>
cc:
Subject:  RE: SCSI URL scheme



John,

> Milan, (and others),
> Since at lest some of you are agreeing on part of this, perhaps we could
> use someone to step through their thoughts about the
> Proxy/Gateway/NAT with
> only the Storage Controller as a Target.  That is, for a little while,
> could we talk about what it take to just get to the IP capable Storage
> Controller that contains the LUNs we have been authorized to use (without
> giving the LUNs a name at this time, just assume we will talk to the
iSCSI
> Target Driver on the Storage Controller).

There is absolutely no mystery.  You ISP or IT manager will ensure the IP
address is routable via routing tables in the routers.  You nor I have
control over these tables.  Think of it as magic.  You could even allow a
DNS server to relate a name to this IP address.  You may even wish to
establish a well known port to this controller to provide an LDAP server as
example which then assigns a port connection.  Or this could be a different
machine that also tells you the IP and port of another machine.

> If the Storage Controller is known (by some method to its DNS server)
what
> more is needed for a host outside the  Proxy/Gateway/NAT to do to get
> through to the Target Storage Controller?  Assume NO changes to current
> Proxy/Gateway/NAT code.

Nothing is needed!

> Please assume that the Host has been given a Name that is resolvable, by
> its DNS, so when that Initiator  queries the DNS to get the IP address of
> the Storage Controller, it gets appropriately resolved.  Now I understand
> that it may only bring the Login request up to the  Proxy/Gateway/NAT,
but
> based on the discussion we have been having here, it might be useful to
> step the process through from the Host to the target Storage Controller
> including what is really needed to pass through the Proxy/Gateway/NAT and
> arrive at the Target Storage Controller.
>
> Would someone like to try describing that?

There will be an assignment within the gateway that translates a
non-routable IP and port to an IP and port that is routable and exposed to
the internet in most cases.  This translation runs both directions in a
completely transparent manner and only effects the source address of the
client.  The client should never assume knowledge of its IP address as it
appears beyond the gateway.  After 4 minutes of not being used, the
translation is taken down.  The destination IP provided gateway MUST be
routable.  The client and not the gateway makes the DNS lookup.  Only
within
the SCSI machine, would there be additional addresses needed.  I insist the
best means of indicating these addresses is via LDAP assigned during
authentication.

Doug

> .
> .
> John L. Hufferd
>
>
> "Merhar, Milan" <mmerhar@pirus.com>@ece.cmu.edu on 10/03/2000 01:40:03 PM
>
> Sent by:  owner-ips@ece.cmu.edu
>
>
> To:   ips@ece.cmu.edu
> cc:
> Subject:  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
>
>
>