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

["Douglas Otis" <dotis@sanlight.net>]

Joshua,

<snip>
> Thanks, but as a former network engineer, I am fully aware of how NAT
> works.  I was not talking about the NAT mechanism per se, but proxies.
> The client cannot "poke through the NAT" because the destination IP
> address is in a different address domain.  It's the proxy, not
> the original
> client that must do the DNS lookup for the final IP address destination.
> Conversely, the target will not see the original initiator, but the proxy.
> And guess how the proxy obtains the information to do a DNS
> lookup?  Hint:
> It's a critical piece of info in http which is not "binary
> information", but
> rather is a name in human-readable form...
>
> >Placing the authentication server within the SCSI transport does not
> improve
> >the ability to scale.  If anything, the authentication will occupy
> resources
> >needed for the retrieval of data.  Let a server specifically designed to
> >provide secure connections and access to the client and server
> perform that
> >function.  It makes no sense to conclude it becomes difficult to delegate
> >this function to a server already up and running.
>
> I don't understand why you equate placing the domain name & path in iSCSI
> PDU's to "putting the authentication server within the SCSI transport."
> We will need an authentication LDAP server regardless of whether domain &
> path go into the iSCSI PDU.  Once again, putting the ASCII-based name in
> iSCSI allows receiving nodes, INCLUDING intermediary proxies, to be able
> to identify the final destination of the iSCSI traffic.  That's all.  And
> as long as DNS is out there and in everyday use, why not use it?  I agree
> it's not perfect, but it works fine and scales.  I do believe we need
> something in addition to DNS for topology/resource discovery, but that can
> be handled separately using a different mechanism.

If you envision use of a proxy sitting in a private name space rather than
using direct access and wish to embed names as a routing feature, then after
authenticating between the proxy and the client, you will be filtering the
PDUs to extract the embedded "name" to then do a lookup of that name to then
do an authentication of the client against that named target.  If an
authentication process has already "embedded" the correct location in a
binary form from negotiations at the client together with an opaque id,
there would not be any lookup required nor any mid-stream authentication.
Why place this in the path of getting the job done?  Why not get it out of
the way directly and let the two ends do the work?  Doing it your way, you
would need to authenticate between the proxy and the client and then again
between the proxy and the target after doing a name lookup.  I would assume
this proxy is passing all the traffic to all the devices, so why add the
burden?  Why is a web browser proxy concept better? Why not authenticate
using a secure and public means and then allow each end to confirm a
connection based on information delivered during authentication.  Once the
client has discovered the authentication server, all of the heavy lifting is
out of the way. There is no good reason to embed names within the SCSI
transport if your goal is security and performance.  Rather than keeping the
process simple, you have made the matter far more complex and far less
likely to scale.

Doug

> Authentication is a totally different problem.  It involves distributing
> a shared secret between nodes and using it to create a message digest
> appended to the end of the iSCSI PDU which can be verified by
> each endpoint.
> It should be used only when necessary and required by the operational
> environment.  Maybe I'm misunderstanding your proposal, but it
> seems you're
> advocating total reliance on the authentication server, not only for
> authentication, but for IP endpoint discovery?
>
> Josh
<snip>