[Docs] [txt|pdf] [Tracker]
Updated by: 147
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]
Html markup produced by rfcmarkup 1.129b, available from
https://tools.ietf.org/tools/rfcmarkup/
