doc: Add RFC documents

1 files changed, 324 insertions, 0 deletions

diff --git a/doc/rfc/rfc129.txt b/doc/rfc/rfc129.txt
new file mode 100644
index 0000000..c4790d4
--- /dev/null
+++ b/doc/rfc/rfc129.txt
@@ -0,0 +1,324 @@
+
+
+
+
+
+
+Network Working Group                         22 April 1971
+Request for Comments:  129               E. E. Harslem-Rand
+NIC 5845                                 J. F. Heafner-Rand
+                                         E.    Meyer-MIT
+
+                       A REQUEST FOR COMMENTS ON
+                         SOCKET NAME STRUCTURE
+
+INTRODUCTION
+
+     This RFC is in answer to a request (made at the
+February NWG Meeting at the University of Illinois) that
+we comment on several suggested socket name structures.
+We apologize for the delay in getting out these comments
+and we hope that you will respond more quickly with your
+reactions.
+     Please direct your replies via the standard RFC
+mechanism.
+     Two structures are presented in this RFC as shown
+below.
+
+                        31                 1
+          +-------------------------------+-+
+     1.   |         Arbitrary             | | <-- gender
+          +-------------------------------+-+
+
+                        24             7   1
+          +------------------------+------+-+
+     2.   |        User ID         | tag  | | <-- gender
+          +------------------------+------+-+
+
+     Three variations are given for the way in which
+socket names are assigned, as examples of use of the
+first structure.
+     1.   Users pick the arbitrary number arbitrarily
+          and associate it with a process.
+     2.   A logger chooses the arbitrary number dynamically
+          and associates it with a process via a directory.
+     3.   The arbitrary number is assigned outside of a
+          logger but may be issued by a logger to the
+          remote party.
+
+
+
+
+
+
+
+
+
+
+                                                                [Page 1]
+
+The second format shown above associates sockets specifi-
+cally with users as opposed to processes.
+     The following discussion covers three different schemes
+of socket identifier assignment using a simple example.
+User A at Host A has agreed (by letter, telephone, etc.)
+with User B at Host B for their respective processes to
+establish a connection through the Network at a particular
+time.  User B is to be waiting for the connection attempt
+initiated by User A.  The issues to be faced are those of
+addressing (how is User A to know to which socket to connect?),
+and of security (how are both users to be confident that
+they are talking each other, and not some interloper?).
+     A fourth scheme follows which addresses another concept
+of Network use--that connections are made between processes
+and that processes not users should be identified via
+Socket names.
+
+FREELY SELECTED RANDOM SOCKET IDENTIFIERS (Scheme 1)
+
+     Under this scheme a user is able to use any 32-bit
+socket identifier he chooses.  Two restrictions apply:  the
+least significant bit denotes the socket's gender (0-read,
+1-write), and no more than one socket bearing a given iden-
+tifier can be active at a host at a time.
+     The two users select suitably random identifiers ("a"
+and "b").  User A will attempt to activate his socket with
+identifier "a" an connect it to socket "b" at Host B.  There
+is the possibility that somebody other than User B has
+activated socket "b" at Host B so that User A will address
+the wrong  party.  However, the possibility that some other
+user has accidentally picked this particular identifier is
+reasonably small, since there are about a billion different
+identifiers.  When the connection request from A gets to
+User B, he examines the identifier of the calling socket.
+If for some reasom it is not "a" or not from Host A, he
+rejects the request, because it is likely to be from some
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+                                                                [Page 2]
+
+outside party.  If the calling socket is named, "a" and
+from Host A, User B can be reasonably sure that it is from
+User A.  It is very unlikely that some other party will
+accidentally address socket "b" from a socket named "a".
+     The advantages of this scheme are:  simplicity and
+reasonable security in a non-malicious environment.  The
+disadvantages are that there are possibilities from annoy-
+ingly unavoidable conflicts with other users and that each
+pair of users must conduct a prior confidential private
+communication (as opposed to a broadcast announcement in
+more secure schemes).
+
+HOST-SELECTED IDENTIFIERS PLUS DIRECTORY (Scheme 2)
+
+     This system uses the same socket identifier structure
+as presented above, except that the Host picks the identi-
+fier at the time the socket is assigned, and the user has no
+no prior knowledge or control of the assignment.  By itself,
+this system would be totally unusable, because there would
+be no way for User A to address User B.  However, it allows
+certain service functions (such as the Network logger) to
+have specifically assigned sockets.
+     One of these is a Network Directory service.  This
+serves to relate a socket identifier at a particular host
+to the name of the user operating it.  This might either
+be a single distributed service, or there might be a separ-
+ate service at each host.
+     Under this scheme, each user, A and B, first activates
+his socket (or somehow gets his host to assign and tell
+him of a socket identifier).  Then he gets the Directory
+module at his host to associate his name with the identi-
+fier of the socket just activated.  Following this, User A
+in some manner gets the Directory Service at Host B to tell
+him the socket identifier assigned to User B.  Then User A
+dispatches a connection request for this socket.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+                                                                [Page 3]
+
+When User B gets the request, he similarly calls on the
+Directory service at Host A to find out the name of the user
+who is operating the socket User B was called by.  If the
+name is that of User A, User B can safely accept the request.
+Otherwise, he rejects.
+     This scheme is rather cumbersome, but some directory
+services must exist for Host-selected socket identifiers to
+work.  On advantage of the Directory Service is thst it
+allows symbolic addressing.  A sizeable disadvantage in view
+of its complexity is that it does not provide absolute
+security.  (For exemple, after User A gets the identifier
+of the socket he is to address, User B could deactivate it,
+and somebody else could come along and get the same-named
+socket.)
+
+ADMINISTRATIVELY ASSIGNED USER IDENTIFIERS (Scheme 3)
+
+     This is the system that is put forth on page 5 of
+Protocol Document 1(8/3/70).  Under it a user is permanently
+assigned a user identifier by his home host.  There is a
+user identifier subfield within the socket identifier, and a
+user is permitted by an NCP to operate only those sockets
+bearing his uder identifier.  This gives the user a selec-
+tion of 256 sockets operable by him.
+     In arranging for the connection the two Users A and B
+tell each other their user identifiers (alternatively a user
+ID could be read from a directory), and User B specifies
+which of his sockets ("b") that he will "listen" on.  At
+connection time, User A selects one of his sockets and
+requests connection for it to socket "b" specified by User B.
+By protocol only User B can operate socket "b", so User A
+can be certain of reaching the right party.
+     When User B receives the connection request, he examines
+the user identifier subfield of the calling socket identifier.
+If it is the user identifier of User A, User B accepts the
+connection request, confident that it is actually User A at
+the other end.  Otherwise B rejects the request.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+                                                                [Page 4]
+
+The advantages of this scheme are that if both hosts
+involved in a connection enforce the user ID assignment,
+the misconnection aspect of security is solved and there
+can be no socket naming conflict between users.  Also,
+arrangements can be made openly and publicly between many
+potential communicators.  A disadvantage to this scheme is
+that some systems may be incapable of insuring user ID
+integrity.
+
+A VIEW OF SOCKET NAME MEANING (Scheme 4)
+
+     Another view of Network use is that programs will con-
+nect to programs, via NCPs.  Some of these programs may be
+multi-access subsystems that are really agents for local
+consoles (and TELNETs).  Consoles will generally communicate
+through some such software agent rather than directly to
+an NCP.
+     Programs, then, must have a fixed, unique identifier,
+known to its remote users and perhaps to its local logger.
+The identifier is constant; it does not change from day to
+day.  If such a program is to allow multiple concurrent
+connections (for many or a single user) then it must have
+a range of variable identifiers as well.  It makes sense
+to group these sockets in a contiguous range.  The variable
+identifiers are transient and are dynamically associated
+with Network logical connections.
+
+      +---------------------   ---------------------+
+      |                                           |
+      | Fixed, unique       /  /  Variable          |
+      | Identifier         /  /  Identifier         |
+      |                                           |
+      +---------------------   ---------------------+
+
+      _________  _________/   _________  _________/
+                /                       /
+       Identifies the           Identifies a particular
+       program uniquely         connection of the program
+
+
+
+
+
+
+
+
+
+
+
+
+
+                                                                [Page 5]
+
+The above premise is that the program (or agent) is
+doing the communicating with an NCP and thus needs to be
+identified for message traffic routing from an NCP.  In
+the past it has been said that users can be mobile, i.e.,
+log on from different sites, and thus it is the user that
+needs identification.  In many typical on-line systems the
+user first requests a service and then identifies himself
+to the service for purposes of accounting, etc.  User IDs
+can be transmitted after requesting a service and can thus
+be elevated above the meaning of socket names.
+     A program might typically associate the terminals, for
+which it is an agent, with the variable part of the identi-
+fier, i.e., the particular connection(s).  For example,
+the Network Services Program (NSP) at Rand now uses the
+following format for socket names.  The first 24 bits are
+administratively assigned and would be known to a logger.
+The multiplex code is normally chosen randomly.  Predefined,
+fixed multiplex codes are possible also.
+
+                24                   7     1
+       +------------------------+---------+-+
+       | Program Number         |Multiplex| | <-- Gender
+       |                        |  Code   | |
+       +------------------------+---------+-+
+
+     The Socket name structure #1 (page 1) thus accomodates
+the above example as well as other exploratory socket name
+structures and various "standards" superimposed on the arbi-
+trary field.
+
+
+       [ This RFC was put into machine readable form for entry ]
+         [ into the online RFC archives by Simone Demmel 4/97 ]
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+                                                                [Page 6]
+