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

[Joshua Tseng <jtseng@NishanSystems.com>]

Doug,

<snip..snip>
>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.

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