RE: iSCSI CONNECT message

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

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>