Request for comments on socket name structure
RFC 129

Document Type RFC - Unknown (April 1971; No errata)
Updated by RFC 147
Last updated 2013-03-02
Stream Legacy
Formats plain text pdf html bibtex
Stream Legacy state (None)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state RFC 129 (Unknown)
Telechat date
Responsible AD (None)
Send notices to (None)
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-
Show full document text