RE: iSCSI gateways, proxies, etc.

[Joshua Tseng/Nishan Systems <joshua.tseng@NishanSystems.com>]

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.

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.

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.

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

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

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

I hope this helps.

Josh

-----Original Message-----
From: Black_David@emc.com [mailto:Black_David@emc.com]
Sent: Wednesday, October 11, 2000 11:18 AM
To: ips@ece.cmu.edu
Subject: iSCSI gateways, proxies, etc.


Folks,

We've been going around on the topic of these for
a while without much visible progress.  I'd like
to suggest a means to extricate ourselves from this
situation.

Jim Hafner correctly observed that there is a
fundamental difference between:
- A gateway that always exposes TCP/IP addresses for the
	iSCSI targets behind it, and
- A gateway that must be dynamically configured to
	obtain connectivity to the iSCSI targets behind it.
We don't need to do anything to support the first class
of gateway.  For the second class, there's another
crucial distinction in the second category, namely
between in-band and out-of-band configuration mechanisms.

>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: 

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

[B] An encrypting firewall does not provide connectivity
to hosts behind the firewall for general traffic outside
the firewall.  If an encrypted IPsec tunnel is set up in
accordance with the firewall's policies, then connectivity
to some of the hosts behind the firewall is provided for
traffic using the tunnel in accordance with the firewall's
policies.

Note that both the NAT and the firewall have to be configured
by some means, and that both of these mechanisms work without
any changes to the iSCSI protocol, as both the DNS lookup and
IPsec tunnel setup happen before the first iSCSI packet is sent.
The fact that we don't have to specify anything makes these
easier to deal with, and gives iSCSI compatibility with all sorts
of things we haven't thought of (yet).

Both the current URL mechanism and the discussion of the
CONNECT message are in-band configuration mechanisms.  In the
context of proxy configuration (Julian's concern about views
is a different, but related issue), this has been turning
into a tarpit on the list.  From what I can see, the issues
here are similar to the issues in naming for 3rd party
commands, something that is not in particularly good shape,
despite T10's best efforts. I find it hard to believe that
people want to repeat T10's experience with this from scratch
for iSCSI, but ... I see three possible paths forward
from which the WG needs to choose:

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

I'm inclined to dismiss (3) as being out-of-scope, because
if this really is analogous to 3rd party naming, then it needs
to be left to T10 and iSCSI should follow what T10 adopts, BUT
I'm willing to listen to counter-arguments.

(1) and (2) are complementary rather than exclusive, but the
protocol gets simpler if we don't have to do (2).  The 3rd party
naming recommendations to T10 are needed regardless.

Ok - comments are solicited, as I do intend to try to call
consensus on this set of issues to make progress.

Thanks,
--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
---------------------------------------------------