TELNET Transfer Control Option

["Robert G. Moskowitz" <[e-mail]>]

---------------------------------------------------------------------------

Source-Date: Thu, 03 Jun 1993 16:06:54 -0500
From:     Steve Alexander
          EMS: INTERNET / MCI ID: 376-5414
          MBX: [e-mail]
TO:     * Robert G. Moskowitz / MCI ID: 385-8921
TO:       telnet ietf
          EMS: INTERNET / MCI ID: 376-5414
          MBX: [e-mail]
Subject:  Telnet Transfer Control Option
Message-Id: 73930603220137/0003765414NA3EM
Source-Msg-Id: <[e-mail]>

------- =_aaaaaaaaaa0
Content-Type: text/plain; charset="us-ascii"

While cleaning out some old mail I realized that I never sent this out.
I received this a while back, with the request that the group review it.

Thanks,
-- Steve


------- =_aaaaaaaaaa0
Content-Type: text/plain; charset="us-ascii"
Content-Description: Transfer Control Draft







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


                     TELNET Transfer Control Option


Status of this Memo

   This memo defines an Experimental Protocol for the Internet communi-
   ty.  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 character-
   ized 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 iden-
   tifier 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 ac-
   complished 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 October 1993                  [Page 1]

Internet-Draft       TELNET Transfer Control Option           April 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 Tel-
   net 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 connec-
   tion is preferred.  Also, the method currently in use is subject to
   "spoof"-ing.  A message that resembles the transfer request may ac-
   cidentally be placed into a MUD (in help text, for instance) where
   the client NVT will mistake the message for a genuine transfer re-
   quest.  Utilization of a Telnet option subnegotiation would make a
   transfer request unambiguous.

1.  Command names and codes

   XFER_CTRL       to be assigned

       LOGON           0
       MUST_XFER       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 anoth-
   er server.

   IAC DO XFER_CTRL

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

   IAC DONT XFER_CTRL

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

   IAC SB XFER_CTRL ( WILL/WONT/DO/DONT <command> ) ... IAC SE



S. Denton                 Expires October 1993                  [Page 2]

Internet-Draft       TELNET Transfer Control Option           April 1993


   To allow for future expansion of the protocol, each command must be
   separately negotiated using the standard WILL/WONT/DO/DONT technique.
   Multiple commands may, but need not, be negotiated within a single
   subnegotiation.

   IAC SB XFER_CTRL MUST_XFER <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.  The
   sender can break the connection immediately.

   The parameter specifies the address of the suggested host.  If known,
   this should be the Internet address expressed as four decimal numbers
   separated by periods; optionally a DNS-style host name should be
   specified.  Space characters are NOT allowed to appear within the
   name.  If the TCP port number will be the same at the alternate host,
   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.  The information will be encoded using NVT ASCII.

   IAC SB XFER_CTRL LOGON <handshake> IAC SE

   The sender requests that the host utilize a private logon protocol to
   effect a transparent transfer of control.  This is sent by the client
   to a server at the beginning of a session.  The meaning of the
   handshake data is arbitrary and is not covered by this standard.  One
   use would be to exchange normal logon prompts and replies in an unam-
   biguous fashion.  The handshake is a string of NVT ASCII data.

3.  Defaults

   WONT XFER_CTRL

   DONT XFER_CTRL

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

   SB XFER_CTRL WONT/DONT LOGON

   Transparent reconnect using this protocol will not be allowed.

   SB XFER_CTRL WONT/DONT MUST_XFER

   Mandatory session tranfer using this protocol will not be allowed.

4.  Description and Implementation Notes

   WILL and DO are used only at the beginning of the connection to ob-
   tain and grant permission for future negotiations.  Either side is



S. Denton                 Expires October 1993                  [Page 3]

Internet-Draft       TELNET Transfer Control Option           April 1993


   free to begin negotiations.  Because of the possible effect the se-
   mantics of the LOGON subnegotiation can have on subsequent Telnet op-
   tion negotiations, XFER_CTRL negotiations should be performed as ear-
   ly as possible in the session.  The protocol is symmetric:  a person
   could use this option to move a connection from a workstation to a
   personal digital assistant.  Only the sender of WILL XFER_CTRL may
   send XFER_CTRL WILL MUST_XFER and subsequently only that sender may
   sent XFER_CTRL MUST_XFER <alternate port>; if both sides might wish
   to do this, they should both send WILL 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 pro-
   posed 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 become confused, especially in the context of
   the Telnet Authentication Option.  To clear this up, the following
   rule is suggested:  No more than one side of a connection may be in
   the XFER_CTRL DO LOGON state and no more than one side may be in the
   XFER_CTRL WILL LOGON state; once confirmed, the side in the XFER_CTRL
   DO LOGON state shall henceforth be treated as having performed a pas-
   sive TCP open, while the side in the XFER_CTRL WILL LOGON state shall
   henceforth be treated as having performed an active TCP open.  To en-
   force this rule, if a side sees XFER_CTRL WILL LOGON after having
   first sent XFER_CTRL WILL LOGON, it must send XFER_CTRL DONT LOGON;
   if a side sees XFER_CTRL DO LOGON after having first sent XFER_CTRL
   DO LOGON, it must send XFER_CTRL WONT LOGON.  (This is not expected
   to be a problem in practice; failure of this subnegotiation would be
   sufficient cause to terminate a session.)  Also, because either side
   of the new connection could be the former client, a side is allowed
   to send the XFER_CTRL WILL LOGON command when it is in either of the
   WILL XFER_CTRL or DO XFER_CTRL states.

   The sole reason for the existance of the logon handshake procedure to
   establish identity rather than using the Telnet authentication op-
   tions is that the existing options are too secure.  Even a nominally
   anonymous user may still have session state information that should
   survive a single connection, and any collection of hosts supporting
   transfer of control should utilize some method of confirming that an
   incoming connection is synonymous to a previous connection.  Some may
   argue that only MUDs require this capability, but many services could
   benefit from this added feature, and often provide a way to use it.
   For example, many, if not most, FTP connections on the Internet are
   anonymous.  In this case, common usage provides for the use of an In-
   ternet mailing address as a password to allow administrators to track
   usage.  This can provide a way to contact users if, for example,
   downloaded files are later discovered to contain a security hazard.

   RFC 959 gives a state diagram for automating a logon procedure using



S. Denton                 Expires October 1993                  [Page 4]

Internet-Draft       TELNET Transfer Control Option           April 1993


   the client-issued commands USER, PASS, and ACCT.  The second imple-
   mentation example in this document uses this same state diagram for
   automating reconnection.  Note that passwords are passed in clear
   text through the network.  If the connections go through untrusted
   networks, there is the possibility that passwords will be compromised
   by someone watching the packets as they go by.  RFC 1416, along with
   1411 and 1412 detail authentication options that should be used in
   preference to this procedure whenever such security is warrented.
   The final implementation example uses a non-approved but apparently
   legal variation of the Telnet authentication option to accomplish the
   same end.  Again, passwords are passed in clear text through the net-
   work.

   Finally, RFC 1408 details a Telnet environment option that could be
   used to transmit detailed state information during a transfer of con-
   trol.

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
                                        IAC SB XFER_CTRL WILL MUST_XFER
                                        IAC SE
       IAC SB XFER_CTRL DO MUST_XFER
       IAC SE
       [ Time passes.  Server decides to require transferring the
         connection to an alternate server.  ]
                                        IAC SB XFER_CTRL MUST_XFER
                                        "pollux.gemini.org 6565" IAC SE
       [ The server is requiring the user to reconnect to an alternate
         host.  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
       IAC SB XFER_CTRL WILL LOGON IAC
       SE
                                        IAC SB XFER_CTRL DO LOGON IAC SE
       IAC SB XFER_CTRL LOGON "USER
       123@MyMUD" IAC SE
                                        IAC SB XFER_CTRL LOGON "330



S. Denton                 Expires October 1993                  [Page 5]

Internet-Draft       TELNET Transfer Control Option           April 1993


                                        Enter password as 'PASS
                                        <password>'" IAC SE
       IAC SB XFER_CTRL LOGON "PASS
       potrzebie" IAC SE
                                        IAC SB XFER_CTRL LOGON "231
                                        Connected." IAC SE
       [ Client and server are connected.  ]
   3.  Transfer of server connection from one client to another.
       Host 1                           Host A
       [ Server (Host A) connects to client(Host 1).  ]
       IAC WILL XFER_CTRL
                                        IAC DO XFER_CTRL
       IAC SB XFER_CTRL WILL MUST_XFER
       IAC SE
                                        IAC SB XFER_CTRL DO MUST_XFER
                                        IAC SE
       [ 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 MUST_XFER
       "123.45.67.89 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 some form of the XFER_CTRL
         protocol.  ]
       IAC SB XFER_CTRL WILL LOGON IAC
       SE
                                        IAC SB XFER_CTRL DO LOGON 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: AUTH and ACCEPT
         are not defined for the NULL authentication type, but for this
         example they are assumed to have the same values as defined for
         Kerberos and SPX.) ]
                                        IAC SB AUTHENTICATION SEND NULL
                                        CLIENT|ONE_WAY IAC SE
       IAC SB AUTHENTICATION NAME



S. Denton                 Expires October 1993                  [Page 6]

Internet-Draft       TELNET Transfer Control Option           April 1993


       "anonymous" IAC SE
       IAC SB AUTHENTICATION IS NULL
       CLIENT|ONE_WAY AUTH
       "[e-mail]" IAC SE
                                        IAC SB AUTHENTICATION REPLY NULL
                                        CLIENT|ONE_WAY ACCEPT IAC SE

Future directions

   The original concept featured a MAY_XFER 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.

   [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



S. Denton                 Expires October 1993                  [Page 7]

Internet-Draft       TELNET Transfer Control Option           April 1993


   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 October 1993                  [Page 8]


------- =_aaaaaaaaaa0--