New Draft of Transfer Control

[Steve Alexander <[e-mail]>]

Here's an updated version of the Transfer Control document that I received
today.

-- Steve

Network Working Group                                          S. Denton
Internet-Draft                                       Coal Services Corp.
                                                               June 1993


                     TELNET Transfer Control Option


Status of this Memo

   This memo defines an Experimental Protocol for the Internet
   community.  Discussion and suggestions for improvement are requested.
   Please refer to the current edition of the "IAB Official Protocol
   Standards" for the standardization state and status of this protocol.
   Distribution of this memo is unlimited.

Motivation

   There has come into being on the Internet a number of loosely coupled
   hypertext multi-user databases (aka MUDs).  These may be
   characterized by the existence of a network-unique cursor object (aka
   player) which may be passed from host to host when the user is
   following what appears to be an otherwise normal database link.

   Although the security requirements of these systems are no greater
   than those of anonymous FTP, each system keeps track of the user's
   location within the database so that each new session starts where
   the previous session ended.  For this reason, an arbitrary user
   identifier is generated the first time a connection is made, and a
   simple password protocol is used to avoid accidentally using another
   user's cursor.  Users normally connect to these databases using a
   client program that emulates a simple Network Virtual Terminal.

   Currently, the hand-off of a cursor from one host to another is
   accomplished by a procedure the details of which vary from system to
   system.  For the purposes of this dissusion, the procedure used by
   the UnterMUD system will be described.  The current host establishes
   a connection to the proposed host using a previously agreed upon port
   number; the current host transfers the contents of the cursor object
   to the proposed host via this connection; when and if the transfer
   has been successfully completed, the current host marks the cursor
   object as "not-in-use" and sends a message to the user requesting a
   transfer to the proposed host.  The message has the fixed format
   "#### Please reconnect to MyMUD@123.45.67.89 (MUDHOST.YOYODYNE.COM)
   port 12345 ####".  The user is then expected to manually break the
   Telnet connection and establish a new connection to the specified
   port. Many of the more specialized client programs recognize this



S. Denton                Expires December 1993                  [Page 1]

Internet-Draft       TELNET Transfer Control Option            June 1993


   message and attempt to perform the transfer transparently.

   The author conjectures that a formalized version of this protocol
   would not only be convenient for the users of these databases, but
   could be useful in its own right.  Several services utilize the
   Telnet protcol for communications to a client.  Using this protcol, a
   Telnet connection to a service could be dynamically switched to
   another host for purposes of load sharing or to facilitate a simpler
   data path for information retrieval.  E.g., after connecting to an
   FTP server, a client may issue a CWD to a directory that is remotely
   mounted via NFS from another host that also provides FTP services.
   In this case, the client could be advised that an alternative
   connection is preferred.  Also, the method currently in use is
   subject to "spoof"-ing.  A message that resembles the transfer
   request may accidentally be placed into a MUD (in help text, for
   instance) where the client NVT will mistake the message for a genuine
   transfer request.  Utilization of a Telnet option subnegotiation
   would make a transfer request unambiguous.

1.  Command names and codes

   XFER_CTRL       to be assigned

       Commands
       IS              0
       SEND            1
       INFO            2
       NAME            3

       Roles
       CLIENT          0
       SERVER          1


2.  Command meanings

   IAC WILL XFER_CTRL

   The sender of this command REQUESTS permission to, or confirms that
   it will, suggest transfer to/from another server.

   IAC WONT XFER_CTRL

   The sender of this command REFUSES to suggest transfer to/from
   another server.

   IAC DO XFER_CTRL

   The sender of this command REQUESTS that the receiver, or grants the
   receiver permission to, suggest transfers between servers.



S. Denton                Expires December 1993                  [Page 2]

Internet-Draft       TELNET Transfer Control Option            June 1993


   IAC DONT XFER_CTRL

   The sender of this command DEMANDS that the receiver not suggest
   transfers between servers.

   IAC SB XFER_CTRL NAME <alternate port> IAC SE

   The sender specifies a remote host to which the connection must be
   transferred immediately.  The sender has already sent all necessary
   state information to the remote host via a private channel, and the
   remote host is waiting for the connection to be made.  The sender can
   break the connection immediately.

   The parameter specifies the address of the suggested host.  It is
   formatted as "<ip-address> [' ' <tcp-port> [' ' commentary]]".  The
   <ip-address> is the Internet address expressed as four decimal
   numbers separated by periods; optionally a DNS-style host name could
   be specified.  Space characters are NOT allowed to appear within the
   name.  If the TCP port number will be the default telnet service port
   (23), nothing more needs to be said.  Otherwise a space character
   will be issued, followed by the port number expressed as a 1-5 digit
   decimal number.  Finally, another space character may be issued
   followed by human-readable text proposing an alternate description of
   the channel, for instance "gopher server at Yoyodyne.com".  Space
   characters are allowed within the commentary.  An application
   compliant with this proposal is allowed to silently ignore the
   commentary.  All information will be encoded using NVT ASCII.

   IAC SB XFER_CTRL IS <role> IAC SE

   The sender demands to play the specified role in all subsequent
   Telnet negotiations of all kinds.

   IAC SB XFER_CTRL SEND IAC SE

   The sender requests that the receiver specify which role it wishes to
   play in all subsequent negotiations.

   IAC SB XFER_CTRL INFO <role> IAC SE

   The sender confirms that it is to play the specified role in all
   subsequent negotiations.

3.  Defaults

   WONT XFER_CTRL

   DONT XFER_CTRL

   i.e., this protocol will not be used.



S. Denton                Expires December 1993                  [Page 3]

Internet-Draft       TELNET Transfer Control Option            June 1993


4.  Description and Implementation Notes

   WILL and DO are used only at the beginning of the connection to
   obtain and grant permission for future negotiations.  Either side is
   free to begin negotiations.  The protocol is symmetric:  a person
   could use this option to move a Telent session from a workstation to
   a personal digital assistant.  Only the sender of DO XFER_CTRL may
   send SB XFER_CTRL NAME <alternate port>; if both sides might wish to
   do this, they should both send DO XFER_CTRL.

   Note that it is common to use the word "server" to refer to the side
   of the connection that did the passive TCP open (TCP LISTEN state),
   and the word "client" to refer to the side of the connection that did
   the active open.  In a hand-off from one client to another, the
   proposed recipient must have already performed a passive TCP open and
   be expecting the connection from the server.  At this point the
   notions of server and client can become confused, for example, in the
   context of the Telnet Authentication Option.  Also, it is easy to
   imagine that the recipient would also be willing to accept a
   connection from another Telnet client that wishes a "talk"
   connection.  This is the rationale for the IS/SEND/INFO sub-protocol.
   Once both sides have agreed to use XFER_CTRL negotiations, they
   should confirm which role they wish to play for the remainder of the
   session.  Generally, the side which performed an active open "knows"
   what role it should play, and should confirm this role by
   transmitting the IS sub-negotiation.  The side which performed the
   passive open may have expectations regarding its role, in which case
   it should send the INFO sub-negotiation, or it may not care, in which
   case it should transmit the SEND sub-negotiation.  In the latter
   case, once an IS sub-negotiation is received, the "passive" side
   should be acknowledge receipt by sending the INFO sub-negotiation.

   The IS/SEND/INFO sub-protocol may be used regardless of whether a
   side of the connection is in only the DO XFER_CTRL state, only the
   WILL XFER_CTRL state, or both.  (The author has given much thought to
   a separate DO/WILL/DONT/WONT SERVE option protocol, but ultimatly
   rejected the idea because of the tight coupling with the XFER_CTRL
   negotiation and irrelevance to all other Telnet negotiations.)
   Because of the possible effect that the semantics of these
   subnegotiations can have on subsequent Telnet option negotiations,
   XFER_CTRL negotiations should be performed as early as possible in
   the session.

   Neither end of a connection should ever assume that any Telnet state
   carries over from a previous connection terminated by XFER_CTRL NAME.
   In particular, authentication and/or encryption should be
   renegotiated with as much paranoia (or as little?) as was exhibited
   in the original session.  There does seem to be a need for an
   "anonymous" authentication method that can establish that multiple
   connections are from the same source, even though one cannot verify



S. Denton                Expires December 1993                  [Page 4]

Internet-Draft       TELNET Transfer Control Option            June 1993


   the identity of that source.

5.  Examples

   In the following examples, all quoted strings are NVT ASCII.

   1.  Server demands transfer to an alternate server.
       Client                           Server
       [ The client connects to the service at castor.gemini.org.  ]
                                        IAC WILL XFER_CTRL
       IAC DO XFER_CTRL
       [ Time passes.  Server decides to require transferring the
         connection to an alternate server.  ]
                                        IAC SB XFER_CTRL DO
                                        "123.45.67.89 6565
                                        [e-mail]" IAC
                                        SE
       [ The server is requiring the user to reconnect to an alternate
         host.  A comment is included to futher identify the new port.
         The server will break the connection at this point.  The client
         should immediately connect to port 6565 at pollux.gemini.org.
         ]
   2.  Client connects to an alternate server supporting dynamic control
   transfer and reconnection.
       Client                           Server
       [ Client connects to server at pollux.gemini.org.  ]
                                        IAC WILL XFER_CTRL
       IAC DO XFER_CTRL
       [ Client and server are connected.  ]
   3.  Transfer of server connection from one client to another.
       Host 1                           Host A
       [ Server (Host A) has connected to client (Host 1).  Both sides
         have authenticated themselves to their mutual satisfaction.  ]
       IAC WILL XFER_CTRL
                                        IAC DO XFER_CTRL
       [ Time passes.  Host 1 decides to transfer the connection to an
         alternate host.  Host 2 performs a passive TCP open on port
         1234.  ]
       IAC SB XFER_CTRL DO "44.55.66.77
       1234" IAC SE
       [ Host 1 breaks connection.  Host A performs an active TCP open
         to the suggested host and port.  ]

       Host 2                           Host A
       IAC WILL XFER_CTRL
                                        IAC DO XFER_CTRL
       [ Both hosts have now agreed to the XFER_CTRL protocol.  ]
       IAC SB XFER_CTRL SEND IAC SE
                                        IAC SB XFER_CTRL IS SERVER IAC
                                        SE



S. Denton                Expires December 1993                  [Page 5]

Internet-Draft       TELNET Transfer Control Option            June 1993


       IAC SB XFER_CTRL INFO CLIENT IAC
       SE
       [ From this point on for the purposes of this or any other Telnet
         option, Host A will be treated as though it had originally
         performed a passive TCP open (Host A is the Server) and Host 2
         will be treated as though it had originally performed an active
         TCP open (Host 2 is the Client).  ]
       IAC WILL AUTHENTICATION IAC SE
                                        IAC DO AUTHENTICATION IAC SE
       [ Both hosts agree to use the Telnet authentication option.  Even
         though RFC 1416 specifies that only the side of the session
         that performed an active open may send WILL AUTHENTICATION, the
         successful negotiation of XFER_CTRL WILL LOGON has reversed
         logical direction of the connection.  (Note: An ANONYMOUS
         authentication type has NOT been defined as of the writing of
         this RFC.  Its use here is as an example only.)  ]
                                        IAC SB AUTHENTICATION SEND
                                        ANONYMOUS CLIENT|ONE_WAY IAC SE
       IAC SB AUTHENTICATION NAME
       "[e-mail]" IAC SE
       IAC SB AUTHENTICATION IS
       ANONYMOUS CLIENT|ONE_WAY AUTH
       ... IAC SE
                                        IAC SB AUTHENTICATION REPLY
                                        ANONYMOUS CLIENT|ONE_WAY ACCEPT
                                        IAC SE

Future directions

   The original concept featured a command to handle non-mandatory
   transfers.  This idea ran aground during the initial implementation
   because of various uncertainties in the semantics of the command.

   It might be useful if the stable end of the connection could be used
   as the repository of connection state information during the transfer
   from the old host to the new.

Acknowledgements

   Thanks to the inventor of Cyberportals, which inspired me to invent a
   standardized protocol to accomplish the same result.

References

   [1] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1340,
   USC/Information Sciences Institute, July 1992.

   [2] Borman, D., "Telnet Authentication Option", RFC 1416, Cray
   Research, Inc., February 1993.




S. Denton                Expires December 1993                  [Page 6]

Internet-Draft       TELNET Transfer Control Option            June 1993


   [4] Alagappan, K., "Telnet Authentication: SPX", RFC 1412, Digital
   Equipment Corporation, January 1985.

   [3] Borman, D., "Telnet Authentication: Kerberos", RFC 1411, Cray
   Research, Inc., January 1993.

   [5] Borman, D., "Telnet Environment Option", RFC 1408, Cray Research,
   Inc., February 1993.

   [6] Reynolds, J., and J. Postel, "File Transfer Protocol", RFC 959,
   USC/Information Sciences Institute, October 1985.

Security Considerations

   Security issues are discussed in section 4.

Author's Address

   Sam Denton
   Coal Services Corp.
   301 North Memorial Drive
   St. Louis, MO  63102

   Phone:  [phone]
   Fax:    [phone]
   Email:  sunarch.central.sun.com!peabody!sam.denton

   This document is an Internet Draft.  Internet Drafts are working
   documents of the Internet Engineering Task Force (IETF), its Areas,
   and its Working Groups. Note that other groups may also distribute
   working documents as Internet Drafts.

   Internet Drafts are draft documents valid for a maximum of six
   months. Internet Drafts may be updated, replaced, or obsoleted by
   other documents at any time.  It is not appropriate to use Internet
   Drafts as reference material or to cite them other than as a "working
   draft" or "work in progress."

   Please check the 1id-abstracts.txt listing contained in the
   internet-drafts Shadow Directories on nic.ddn.mil, nnsc.nsf.net,
   nic.nordu.net, ftp.nisc.sri.com, or munnari.oz.au to learn the
   current status of any Internet Draft.











S. Denton                Expires December 1993                  [Page 7]