RE: iSCSI gateways, proxies, etc.

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

David,

Thanks for the reference.  I would have never guess it otherwise.  I think
the point you have made is how very ugly these issues become with things
like doctoring DNS responses to hide botched IP configurations.  Should a
transport deal with this quagmire?  There is substantial overhead associated
with any redirection.  In the simple case, no redirection is required, be it
IP or hostname.  Once redirection is allowed, resources expended for
hostname lookup alone could create havoc.  With redirection, every segment
must be examined for both source and destination against a permissions table
constructed via remote or local authentication.  This table has now doubled
in size to increase latency and every node must ask for permissions.  Again,
in the simple case, these provisions are not required or are handled by
existing equipment.  It would be the poor approach to design for little used
cases as a burden to all cases.  The bottom line, SCSI transport is not
HTTP.

The expectations of this transport is to allow a server to expose a SAN by
means of SCSI encapsulation.  Until that changes, there is no need to
consider issues of third-party addressing as this is defined by the native
medium of the SAN.  The only open issue is how to allow construction of
commands, provide flow control to this underlying medium, and should there
be a requirement for server to server communication, the client must not be
allowed to autonomously make those associations.  These server to server
associations must be predefined by the IT administrators.  Every operation
must consider aspects of security.  By allowing redirection, this security
becomes difficult and expensive.

Doug

> > I do not understand what is meant by "out-of-band".  Is it some
> > kind of manual configuration?
>
> Out-of-band means that the configuration is not done as part of
> setting up the iSCSI connection.  It could be manual or automatic -
> both the DNS and firewall examples in my original message were
> examples of automatic out of band configuration.  I believe that there
> are implementations of the DNS example, and the IPsec community
> is in the midst of working on automating things that include the
> tunnel autoconfig required by the firewall example.  The firewall in the
> example I used could be a stateful inspection firewall; the intent
> was not to have the firewall itself be a visible iSCSI proxy.
>
> The NAT example is "Bidirectional NAT" or "Twice NAT" with dynamic
> setup of the address translations.  See Sections 4.2 and 4.3 of RFC 2663,
> and discussion in that RFC of using a DNS-Application Level Gateway.
> The example I described uses invocation of and information from the
> DNS-ALG to set up the translations as opposed to the RFC description
> that does not include the setup mechanism.
>
> --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
> ---------------------------------------------------
>