RE: iSCSI CONNECT message

["Merhar, Milan" <mmerhar@pirus.com>]

RLOGIN and FTP are pretty old protocols - I believe 
that FTP in particular predates TCP. As such, they 
may not be the best examples to follow for how to 
write protocols that are intended to pass through
a NAT.

Basically, a protocol that embeds IP addresses or 
specific TCP port numbers within itself (e.g. - to let the 
other end know how to set up another connection,) will 
require application proxy support. This is because 
those values may have significance only in a local 
domain - in other words, only on one side or the other
of the NAT box.  When the messages go through the NAT,
it has to dig into the protocol, and fix up those values
to be valid in the other domain.   

FTP is particularly messy, in that it represents an 
IP address as an ASCII string, which may change length 
when modified, creating a cascade of other corrections
needing to be applied to the message's structure. 

Without intending to pour fuel on the "DNS/URL" fire, it 
_is_ true that embedding not a literal address, but a symbolic 
value that can be converted to an address (like an DNS name,) 
can be said to eliminate the need for application proxy support.  
It does so, however, by requiring the DNS to map a name into different
values (either a public IP address, or an address in private 
space) depending on where the requestor is standing.

And yes, Doug, one could instead look that name up in an 
appropriate directory, rather than using DNS.

- milan



> -----Original Message-----
> From: David Robinson [mailto:David.Robinson@EBay.Sun.COM]
> Sent: Monday, October 09, 2000 9:26 PM
> To: ips@ece.cmu.edu
> Subject: Re: iSCSI CONNECT message
> 
> 
> Joshua Tseng/Nishan Systems wrote:
> > If I am "not correctly representing the world", it is purely
> > unintentional. But my references indicate that at least rlogin and
> > ftp embed the destination hostname in the messaging between
> > client and server (see TCP/IP Illustrated by R. Stevens, pg 396-397
> > and pg 428).  In rlogin, there are three strings sent after the
> > first byte--login name of the client, login name of server, and
> > terminal type and speed.  In ftp, the hostnames are passed in the
> > control connection.
> 
> I don't have Steven's book handy, but I have the BSD source code.
> For rlogin/rsh/rcmd what is sent is the stderr port number,
> local user name, remote user name, and the command string. Used
> primarily as a bad inband authentication protocol. There are
> no hostnames used. For FTP it is just a direct connection to port 21
> then ASCII commands are sent, no hostnames are required (see RFC959).
> Same for telnet, except it has some parameter negotiation available.
> I would like to be proven wrong, but I have written clients, servers,
> and packet sniffers for all of these in the past.
> 
> > Additionally, my real-world experience with application proxy
> > firewalls indicate that this MUST be so, or the proxy firewall
> > should not be working!  Am I missing something here?  Otherwise,
> > how is it working???  I do not understand what you mean by "out
> > of band entities".
> 
> What I mean is that the base Internet protocols were written long
> before anyone dreamed up the idea of a proxy and they are simple.  As
> a result the smarts is put in the proxy and not in rewriting the
> base protocol. By out of band entities I mean some technique that
> is not part of the standard protocol that enables proxies.
> 
> 	-David
>