RE: iSCSI CONNECT message

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

Joshua,

If you look at http://www.ietf.org/rfc/rfc2784.txt this RFC describes the
Generic Routing Encapsulation protocol that can be used to tunnel past
firewalls and NATs.  iSCSI is not describing anything remotely similar to
HTTP, telnet, or FTP and perhaps with the exception of HTTP, these protocols
do not use DNS as part of their basic functioning.  HTTP certainly does not
require DNS, but as much of the embedded text strings within HTML documents
depend on symbolic domain names, DNS has become a part of HTTP. Symbolic
names have been troublesome in that one HTTP server does not translate in
the same manner as another. (Things like file: or scsi: would not help this
situation.)

At each point of tunneling within iSCSI, authentication must be made.  As
that would then include every point within iSCSI, authentication would be
part of every operation for every node.  As each node will be required to
translate symbolic information in the same manner, a name server would need
to be referenced to forwarded packets.  Symbolic parsing, name lookup,
authentication, and packet forwarding becomes a required operation
understood by each node.  This becomes a significant level of complexity
added to assist in an imagined problem.

In a real-world situation, a target address could be just a number
understood by targets through prior initialization.  If the target doing a
third-party operation is required to forward a packet, the network for this
server should understand how to transport that packet to its final location
based on this pre-defined number.  That forwarding should be fixed in place
and not altered by the client.  As such, there would be no reason to include
any IP or domain name for DNS lookup within the SCSI transport.  Once a
permission list of targets is checked at the SCSI portal, no other points
are required to check and re-check.  Once you allow dynamic routing tables,
the ability to authenticate and secure the system has become sizable and
likely beyond scaling.

Doug

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