Movatterモバイル変換

Network Working Group                         22 April 1971Request for Comments:  129               E. E. Harslem-RandNIC 5845                                 J. F. Heafner-Rand                                         E.    Meyer-MIT                       A REQUEST FOR COMMENTS ON                         SOCKET NAME STRUCTUREINTRODUCTION     This RFC is in answer to a request (made at theFebruary NWG Meeting at the University of Illinois) thatwe comment on several suggested socket name structures.We apologize for the delay in getting out these commentsand we hope that you will respond more quickly with yourreactions.     Please direct your replies via the standard RFCmechanism.     Two structures are presented in this RFC as shownbelow.                        31                 1          +-------------------------------+-+     1.   |         Arbitrary             | | <-- gender          +-------------------------------+-+                        24             7   1          +------------------------+------+-+     2.   |        User ID         | tag  | | <-- gender          +------------------------+------+-+     Three variations are given for the way in whichsocket names are assigned, as examples of use of thefirst 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 schemesof 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 toestablish a connection through the Network at a particulartime.  User B is to be waiting for the connection attemptinitiated by User A.  The issues to be faced are those ofaddressing (how is User A to know to which socket to connect?),and of security (how are both users to be confident thatthey are talking each other, and not some interloper?).     A fourth scheme follows which addresses another conceptof Network use--that connections are made between processesand that processes not users should be identified viaSocket names.FREELY SELECTED RANDOM SOCKET IDENTIFIERS (Scheme 1)     Under this scheme a user is able to use any 32-bitsocket identifier he chooses.  Two restrictions apply:  theleast 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 withidentifier "a" an connect it to socket "b" at Host B.  Thereis the possibility that somebody other than User B hasactivated socket "b" at Host B so that User A will addressthe wrong  party.  However, the possibility that some otheruser has accidentally picked this particular identifier isreasonably small, since there are about a billion differentidentifiers.  When the connection request from A gets toUser B, he examines the identifier of the calling socket.If for some reasom it is not "a" or not from Host A, herejects the request, because it is likely to be from some                                                                [Page 2]

outside party.  If the calling socket is named, "a" andfrom Host A, User B can be reasonably sure that it is fromUser A.  It is very unlikely that some other party willaccidentally address socket "b" from a socket named "a".     The advantages of this scheme are:  simplicity andreasonable security in a non-malicious environment.  Thedisadvantages are that there are possibilities from annoy-ingly unavoidable conflicts with other users and that eachpair of users must conduct a prior confidential privatecommunication (as opposed to a broadcast announcement inmore secure schemes).HOST-SELECTED IDENTIFIERS PLUS DIRECTORY (Scheme 2)     This system uses the same socket identifier structureas presented above, except that the Host picks the identi-fier at the time the socket is assigned, and the user has nono prior knowledge or control of the assignment.  By itself,this system would be totally unusable, because there wouldbe no way for User A to address User B.  However, it allowscertain service functions (such as the Network logger) tohave specifically assigned sockets.     One of these is a Network Directory service.  Thisserves to relate a socket identifier at a particular hostto the name of the user operating it.  This might eitherbe a single distributed service, or there might be a separ-ate service at each host.     Under this scheme, each user, A and B, first activateshis socket (or somehow gets his host to assign and tellhim of a socket identifier).  Then he gets the Directorymodule at his host to associate his name with the identi-fier of the socket just activated.  Following this, User Ain some manner gets the Directory Service at Host B to tellhim the socket identifier assigned to User B.  Then User Adispatches a connection request for this socket.                                                                [Page 3]

When User B gets the request, he similarly calls on theDirectory service at Host A to find out the name of the userwho is operating the socket User B was called by.  If thename is that of User A, User B can safely accept the request.Otherwise, he rejects.     This scheme is rather cumbersome, but some directoryservices must exist for Host-selected socket identifiers towork.  On advantage of the Directory Service is thst itallows symbolic addressing.  A sizeable disadvantage in viewof its complexity is that it does not provide absolutesecurity.  (For exemple, after User A gets the identifierof the socket he is to address, User B could deactivate it,and somebody else could come along and get the same-namedsocket.)ADMINISTRATIVELY ASSIGNED USER IDENTIFIERS (Scheme 3)     This is the system that is put forth on page 5 ofProtocol Document 1(8/3/70).  Under it a user is permanentlyassigned a user identifier by his home host.  There is auser identifier subfield within the socket identifier, and auser is permitted by an NCP to operate only those socketsbearing 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 Btell each other their user identifiers (alternatively a userID could be read from a directory), and User B specifieswhich of his sockets ("b") that he will "listen" on.  Atconnection time, User A selects one of his sockets andrequests connection for it to socket "b" specified by User B.By protocol only User B can operate socket "b", so User Acan be certain of reaching the right party.     When User B receives the connection request, he examinesthe user identifier subfield of the calling socket identifier.If it is the user identifier of User A, User B accepts theconnection request, confident that it is actually User A atthe other end.  Otherwise B rejects the request.                                                                [Page 4]

The advantages of this scheme are that if both hostsinvolved in a connection enforce the user ID assignment,the misconnection aspect of security is solved and therecan be no socket naming conflict between users.  Also,arrangements can be made openly and publicly between manypotential communicators.  A disadvantage to this scheme isthat some systems may be incapable of insuring user IDintegrity.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 bemulti-access subsystems that are really agents for localconsoles (and TELNETs).  Consoles will generally communicatethrough some such software agent rather than directly toan 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 today.  If such a program is to allow multiple concurrentconnections (for many or a single user) then it must havea range of variable identifiers as well.  It makes senseto group these sockets in a contiguous range.  The variableidentifiers are transient and are dynamically associatedwith 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) isdoing the communicating with an NCP and thus needs to beidentified for message traffic routing from an NCP.  Inthe past it has been said that users can be mobile, i.e.,log on from different sites, and thus it is the user thatneeds identification.  In many typical on-line systems theuser first requests a service and then identifies himselfto the service for purposes of accounting, etc.  User IDscan be transmitted after requesting a service and can thusbe elevated above the meaning of socket names.     A program might typically associate the terminals, forwhich 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 thefollowing format for socket names.  The first 24 bits areadministratively 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 accomodatesthe above example as well as other exploratory socket namestructures 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]