summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc129.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc129.txt')
-rw-r--r--doc/rfc/rfc129.txt324
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]
+