RFC 129

RFC 129: A Request for Comments on Socket Name Structure 🎀

okay bestie, let's start with the title block 💅 this is RFC 129 (also known as NIC 5845), from the Network Working Group, dated 22 April 1971. The authors are E. E. Harslem-Rand, J. F. Heafner-Rand, and E. Meyer-MIT 🫶 The header doesn't say what category or status it has, and it doesn't list anything it obsoletes or updates 🦋

INTRODUCTION 🌸

okay so this RFC is answering a request made at the February NWG Meeting at the University of Illinois 🏫 people asked for comments on several suggested socket name structures. the authors say sorry it took so long to get these out 🙈 and they really hope you'll reply faster than they did 💌 send your replies through the standard RFC mechanism!!

there are two structures presented here 👑

                        31                 1
          +-------------------------------+-+
     1.   |         Arbitrary             | | <-- gender
          +-------------------------------+-+

                        24             7   1
          +------------------------+------+-+
     2.   |        User ID         | tag  | | <-- gender
          +------------------------+------+-+

there are three variations on how socket names get assigned, all using the first structure as the example ✨

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 a logger may issue it to the remote party.

the second format is the one that associates sockets specifically with users instead of processes 🧚

the discussion below covers three different schemes of socket identifier assignment, using one simple example. User A at Host A has agreed (by letter, telephone, etc.) with User B at Host B that their processes will connect through the Network at a particular time 📞 User B is supposed to be waiting for the connection attempt User A starts. the issues are addressing (how does User A know which socket to connect to?) and security (how can both users be confident they're talking to each other, and not some interloper? 👀).

then there's a fourth scheme, for a different concept of Network use: connections are made between processes, so processes (not users) should be identified by socket names 🤖

FREELY SELECTED RANDOM SOCKET IDENTIFIERS (Scheme 1) 🎲

under this scheme, a user can pick any 32-bit socket identifier they want 💖 there are two restrictions though. first, the least significant bit tells you the socket's gender (0 means read, 1 means write). second, no more than one socket with a given identifier can be active at a host at a time.

so the two users each pick a suitably random identifier, "a" and "b" 🎀 User A activates his socket with identifier "a" and connects it to socket "b" at Host B. the scary part is that somebody other than User B might have already activated socket "b" at Host B, so User A ends up talking to the wrong person 😭 but honestly, the chance that some other user accidentally picked that exact identifier is pretty small, since there are about a billion different identifiers to choose from.

when A's connection request reaches User B, B checks the identifier of the calling socket. if it isn't "a", or it doesn't come from Host A, B rejects the request, because it's probably from some outside party 🚫 if the calling socket is named "a" and it's from Host A, then B can be reasonably sure it's from User A 🥰 it's very unlikely that some other party would accidentally address socket "b" from a socket named "a".

the good stuff about this scheme: it's simple, and it's reasonably secure in a non-malicious environment ✨ the not-so-good stuff: there's a possibility of annoyingly unavoidable conflicts with other users, and each pair of users has to have a prior confidential, private conversation to share the identifiers (instead of a broadcast announcement, like in the more secure schemes) 🙄

HOST-SELECTED IDENTIFIERS PLUS DIRECTORY (Scheme 2) 🗂️

this system uses the same socket identifier structure as above, except the Host picks the identifier when the socket is assigned, and the user has no prior knowledge of it and no control over it 😵‍💫 on its own this would be totally unusable, because User A would have no way to address User B! but it does let certain service functions (like the Network logger) have specifically assigned sockets, which is kinda iconic 👑

one of those is a Network Directory service 📒 it relates a socket identifier at a particular host to the name of the user operating it. it might be one single distributed service, or there might be a separate service at each host.

here's how it goes. each user, A and B, first activates his socket (or gets his host to assign one and tell him the identifier). then he gets the Directory module at his host to associate his name with the identifier of the socket he just activated. after that, User A somehow gets the Directory Service at Host B to tell him the socket identifier assigned to User B. then User A sends a connection request to that socket 📨

when User B gets the request, he does the same thing: he calls the Directory service at Host A to find out the name of the user operating the socket B was called from. if that name is User A's, B can safely accept the request. otherwise, he rejects it 🙅‍♀️

ngl this scheme is kind of cumbersome 💀 but some directory services have to exist for Host-selected socket identifiers to work at all. the big upside of the Directory Service is that it allows symbolic addressing 🦋 the sizeable downside, given how complicated it is, is that it does not provide absolute security. (for example, after User A gets the identifier of the socket he's supposed to address, User B could deactivate it, and then somebody else could come along and get a socket with the same name.)

ADMINISTRATIVELY ASSIGNED USER IDENTIFIERS (Scheme 3) 🪪

this is the system that's put forth on page 5 of Protocol Document 1 (8/3/70) 📜 under it, a user is permanently assigned a user identifier by their home host. there's a user identifier subfield inside the socket identifier, and an NCP only lets a user operate the sockets that carry their user identifier. that gives each user a selection of 256 sockets they can operate 🎀

to set up the connection, the two users A and B tell each other their user identifiers (or they could look them up in a directory), and User B says which of his sockets ("b") he'll "listen" on 👂 at connection time, User A picks one of his own sockets and requests a connection to socket "b" that B specified. by protocol, only User B can operate socket "b", so User A can be certain they're reaching the right party 🥹

when User B receives the connection request, he checks the user identifier subfield of the calling socket identifier. if it's User A's user identifier, B accepts the request, confident that it's really User A on the other end 🫶 otherwise, B rejects it.

the advantages of this scheme: if both hosts involved in a connection enforce the user ID assignment, the misconnection part of security is solved, and there can be no socket naming conflicts between users 🙌 arrangements can also be made openly and publicly between lots of potential communicators. the disadvantage is that some systems may be incapable of insuring user ID integrity 😬

A VIEW OF SOCKET NAME MEANING (Scheme 4) 🔮

another way to look at Network use is that programs connect to programs, via NCPs 🤖 some of these programs might be multi-access subsystems that act as agents for local consoles (and TELNETs). consoles usually talk through some software agent like that, rather than directly to an NCP.

so programs need a fixed, unique identifier, known to their remote users and maybe to their local logger 💜 that identifier is constant, so it doesn't change from day to day. if a program is going to allow multiple concurrent connections (for lots of users, or just one user), it also needs a range of variable identifiers 🌈 it makes sense to group those sockets in a contiguous range. the variable identifiers are transient, and they get dynamically associated with Network logical connections.

      +---------------------   ---------------------+
      |                                           |
      | Fixed, unique       /  /  Variable          |
      | Identifier         /  /  Identifier         |
      |                                           |
      +---------------------   ---------------------+

      _________  _________/   _________  _________/
                /                       /
       Identifies the           Identifies a particular
       program uniquely         connection of the program

the premise here is that the program (or agent) is the thing talking to an NCP, so it needs to be identified for message traffic routing from an NCP 🛣️ in the past, people said users can be mobile (logging on from different sites), so it's the user who needs identifying. but in lots of typical online systems, the user first requests a service and then identifies themselves to the service, for accounting and stuff 🧾 user IDs can be sent after a service is requested, so they can be elevated above the meaning of socket names 👑

a program might typically link the terminals it's an agent for to the variable part of the identifier (aka the particular connection or connections) 📺 for example, the Network Services Program (NSP) at Rand currently uses this 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, though predefined, fixed multiplex codes are possible too 🧩

                24                   7     1
       +------------------------+---------+-+
       | Program Number         |Multiplex| | <-- Gender
       |                        |  Code   | |
       +------------------------+---------+-+

so Socket name structure #1 (page 1) already fits the example above, along with other exploratory socket name structures and various "standards" layered on top of the arbitrary field 🎉✨

---

       [ This RFC was put into machine readable form for entry ]
         [ into the online RFC archives by Simone Demmel 4/97 ]