RE: iSCSI CONNECT message

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

Doug,

I am not defining a tunnel in the sense of IP tunneling.  I think
you are confused by Jim's discussion about explicit and implicit
"tunneling"--we are talking about something different here.  What
I am describing is no different from what exists today with http,
telnet, ftp, rlogin, e-mail, and many other applications.  Each of
these protocols has the hostname (DNS name) of the sending and
receiving hosts imbedded in the protocol, for use by proxies when
necessary.  DNS maps this name to an external proxy IP address if
you are talking to a public external DNS server, or to an internal
IP address if you are talking to an internal DNS server.  Similarly,
an internal client asking the local DNS server to resolve an external
DNS name may have the proxy server's IP address returned to it.

Now, the precise mechanism may vary depending on the administrator
and how they have set up their DNS infrastructure.  Some administrators
only NAT the source IP address for outbound packets and destination
IP address for inbound packets.  If this were the case, the local
DNS server has access to the entire Public Internet, and can map
DNS names to the real IP address.

Regarding the scalability of DNS, I think you will find most people
who have used DNS and depend on it, believe it scales quite well.
I don't know what else I can say.

Josh

-----Original Message-----
From: Douglas Otis [mailto:dotis@sanlight.net]
Sent: Monday, October 09, 2000 11:54 AM
To: Joshua Tseng; ips@ece.cmu.edu
Subject: RE: iSCSI CONNECT message


Joshua,

You are defining a tunnel.  The internal IP can not be directly accessed.
It makes little sense to advertise non-routable IPs from a public DNS.
Should the user be able to tunnel past the NAT or firewall, the internal DNS
servers (not exposed to the outside public) would then be visible.  You
would not need to do any more than to find the point of entry.  As there are
already tunneling protocols to allow access beyond these modes of
protection, opening new means of access beyond this protection and then
allow every device within this domain similar features would be a nightmare
to secure.  DNS would not be a good tool to scale a database as well.  You
would need a means of selecting a subset based on the user.  As tunnels are
common place in allowing access and need not be used as a feature of the
transport, keep the transport independent of any required tunnels and simply
assume if a tunnel is needed, it will be provided.

Doug


> John,
>
> What I'm trying to say is that DNS provides a means for
> individual administrators to make their networks visible and
> addressable to the Public Internet, even if they are using
> proxy gateways and NAT.  If the administrator's DNS servers are
> configured correctly, they will allow someone on the Public
> Internet to be able to resolve a DNS domain name to a proxy
> gateway.  The initiator will try to login to that proxy.  That
> proxy gateway can take the DNS name imbedded in the login
> message to resolve to the storage controller, or another
> proxy gateway managed by an internal DNS server in the
> adminstrator's network.  If there are several levels
> of nested networks and proxy gateways, then this process
> continues until the final storage controller is reached.
> DNS provides the infrastructure and mechanism to handle
> proxy gateways, provided that the administrator has properly
> configured his/her DNS servers.
>
> The process works this way today with http proxies, telnet
> proxies, ftp proxies, SMTP mail relays, etc...
>
> I agree the current login mechanism in the existing iSCSI
> draft is sufficient.
>
> Josh
<snip>

storage protocol positioning.ppt