RE: iSCSI gateways, proxies, etc.

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

Joshua,

> David,
>
> <Snip...snip>
> >>From a protocol specification viewpoint, out-of-band
> >configuration mechanisms are both more flexible and
> >easier to deal with.  Flexibility comes from the
> >variety of possible mechanisms, for example:
>
> I do not understand what is meant by "out-of-band".  Is it some
> kind of manual configuration?  That would be a nightmare
> for network administrators.  Traversing firewalls is an
> issue that consumes SOOOO much of their effort.  Perhaps I
> can clarify this issue by giving an overview on the state of
> firewall technology, and show how it applies to iSCSI.

Obtaining the IP address is a very small part of the information required to
communicate to a phalanx of drives sitting behind an IP address.  I would
strongly recommend that an Authentication Server which provides all the
required information in its native binary form (with the exception of volume
names for mounting and selectors for filtering) be used rather than depend
on a problematic DNS server.  Not using standardized tools will ensure an
impossible workload for IT administrators as even hostnames must come from
somewhere not to mention user authorization, mounting information, device
verification, selective discovery, third-party copy managers, machine boot
devices and on and on.

> 1)  Stateful Inspection
> Generally pioneered by Checkpoint Software.  NAT is optional.
> Internal hosts are allowed to directly resolve DNS queries for
> the entire Internet.  Internal hosts are allowed to initiate TCP
> connections to external hosts, so only a single TCP connection
> is needed for outbound connections.  External hosts must address
> a proxy in order to communicate with an internal host, so at
> least two connections are needed--the first from initiator to
> proxy, the second from proxy to target.  The proxy must obtain
> the IP address of the internal destination somehow and typically
> uses the fully qualified domain name to resolve the internal IP
> address by consulting an internal DNS server.  If this information
> is not in the application protocol, then it may be included in a
> shim such as a SOCKS shim (see RFC 1928).  If iSCSI does not include
> DNS domain name in the transport, then iSCSI must be prepared to
> be "socksified" in order to traverse a firewall from the external
> to internal.  Perhaps this is what is meant by "out-of-band"
> configuration.

There are many options to this problem.  Why try to pick a solution?  Let
the IT administrators decide if they need GRE, VPN, or a simple border
router or even SOCK.  Out-of-band means not done by a function of the
transport connection.

> 2)  Application Proxy Firewall
> Gauntlet, Axent, and others.  Declining in popularity, but there
> are still some out there. Requires internal hosts to connect to
> the proxy firewall before connecting to external hosts.  Worst case,
> a minimum of two TCP connections are needed for both outbound and
> inbound connections, but more recently, these firewalls can operate
> in modes which are more similar to 1) above, allowing internal hosts
> to directly communicate with external hosts.  If the application
> does not include the fully qualified domain name in the transport,
> then it must either be "socksified", or undergo a manual two-step
> process of the user first manually logging in and authenticating
> with the proxy, and then use the application hosted on the proxy to
> complete the connection.

Only two solutions?  It sounds like a bandaid to an insecure system.  You
have not made a good case to include this tar pit that gets very sticky when
you insist that DNS MUST be used.

> <snip..snip>
> >[A] A NAT monitors DNS traffic to/from a DNS server in
> >private address space behind the NAT.  When a DNS reply
> >containing a translation is intercepted, the NAT sets up
> >an external IP address that maps to the internal IP address
> >in the DNS reply, and substitutes that external IP address
> >for the internal IP address before forwarding the reply
> >(in addition to the usual translation operations performed
> >on the header).  Credit/apologies to whomever (Joshua Tseng?)
> >originally described this example.
>
> I'm afraid I don't quite follow this.  NAT is Network
> Address Translation, and is not an entity on the network.
> Perhaps you're refering to the proxy.  Note that a fully
> qualified domain name may resolve to a different IP address
> outside the firewall than it would inside the firewall.
> Outside the firewall, it resolves to the proxy.  Inside the
> firewall, it resolves to the real destination IP address
> (or even another proxy's address), which must be kept hidden
> from the Public Internet.  The proxy sits on the boundary
> between private and public, and has access to both internal
> and external DNS servers and IP addresses.

You then have to wonder which DNS is being used to get where you are going
for the correct scope as well as what kind of IP is being returned.  As DNS
uses UDP, you may have extensive timeouts waiting for a lookup.  This lookup
could be stale or of the wrong scope or the wrong IP version.  The transport
agent may cache the name lookup longer that it should.  The target may be a
device without a name but now it MUST be named.

> >(1) Rely on out-of-band gateway/proxy configuration.
> >(2) Reference T10's 3rd party naming formats for target naming.
> >	This WG would still define an iSCSI 3rd party naming format
> >	and recommend it to T10, and could define ways of using
> >	T10 naming formats with Internet protocols (e.g., LDAP).
> >(3) Invent new ways of naming targets.
>
> Once again, I am unclear as to what is meant by (1)"out-of-band",
> but if it involves manual configuration of proxies, including
> entering which IP addresses translate to what, etc..., then
> iSCSI will become a true enemy of network administrators
> everywhere.  This is a real heartache and resource sink for
> already-overburdened network admins.

Cue the violins.  Should the IT administrators have a uniform and standard
tool for dealing with bootstrapping their internal systems as well as
sharing designated resources with external groups using this single tool in
a coherent fashion, the heartache was only gas.  Not a function of the
transport connection is out-of-band.  Using an authentication server to
deliver a SCSI class object or schema to a client is out-of-sight.

> Regarding (2), I would support use of World Wide Port Name (WWPN)
> for target naming, including 3rd party naming.

These WWN could be included within the schema delivered to verify the target
and LUN.

Doug

> I hope this helps.
>
> Josh