NWG/RFC 49      Conversations with Steve Crocker (UCLA)                          Edwin W. Meyer, Jr.                            MIT Project MAC                             April 25, 1970   (Both my personal opinions and those that I believe represent a   consensus of the Network Working Group at Project MAC are presented   here.  The pronouns "I" and "we" are used to distinguish between   these.)On April 21 and 23 Thomas P. Skinner and I had telephone conversationswith Steve Crocker at UCLA relating to the network protocol,specifically regarding our proposal in NWG/RFC 46.  The following itemswere discussed.  (I hope that Steve will pardon me if I happen tomisparaphrase him.)1) Steve stated that he felt that a need for dynamic reconnection wouldlater be recognized by the network participants.  However, because of alack of consensus, it will not be included in the initialimplementation.  (We at Project MAC favor this approach of not includingit initially.)2) Steve supported the implementation of the INT network commanddescribed in NWG/RFC 46.This command allows a process that has agreed to accept interrupts overa socket connection to be reliably interrupted by the process at theother end.  The interrupt causes a process to abey its current executionand execute a procedure that it has specified as the INT handler.  (TheNCP does not specify the INT handler.  That is the function of higherlevel protocols.)The INT command is designed specifically for use by a third level UserControl and Communication (UCC) protocol to implement a "quit" signal.Under such a protocol, both the requestor and the created process agreethat an INT related to a specific socket connection and transmitted overthe NCP control link to the created process is the standard "quit"signal.  The created process provides an INT handler that implementsthis "quit" function.  (This does not preclude a differentinterpretation of INT by other third level protocols.)Although many systems implement the "quit" as a control character in theTeletype input stream, systems such as CTSS, Multics, and othersimplement it as a 200 ms spacing on the line.  We at MAC think that the                                                                [Page 1]NWG/RFC 49      Conversations with Steve Crocker (UCLA)first method is an undesirable implementation within the network (whilethe second is impossible).  I put forth several reasons why (and I thinkSteve agreed).(a) The link over which the quit character is to be transmitted may beblocked.(b) While the interrupt is most effectively implemented within the NCP,it is undesirable for the NCP to place any particular structure on thedata being transmitted.  (See discussion below.)  This would be requiredif the NCP were to scan a data stream for a control character.(c) Scanning the input stream greatly reduces NCP efficiency in asubsystem where speed is critical to effective operation.Steve pointed out that the implementation of INT as a "quit" should notnecessarily preclude a HOST's interpretation of a control character inthe input stream from also acting as a "quit".3) Steve is opposed both to including the instance tag in the socketidentifier and reserving a null field in the identifier for futuredefinition.  He cited several reasons:(a) Multiple processes of a single user should be indistinguishable to aforeign process.  (I agree with this in certain cases when processes areco-ordinated in joint action.  But what about the case where twoprocesses of the same user both want to independently use the network?)(b) A process wishing to connect to one of a foreign user's processesdoes not know the instance tag of the particular process that he wants,and he can't easily find out.(c) If an instance tag should later prove desirable it could be addedwith some difficulty.  (I claim that something as fundamental as thelength of a socket identifier will prove very resistant to change.)Tom stated that perhaps the low order three bits of the user code couldbe reserved for later interpretation as an instance tag.  He doesn'tthink that a separate field is of great importance.Steve's arguments seem to have merit.  Perhaps Tom's suggestion is theway to go.  I am currently undecided on this matter.4) We all (Steve and MAC) seem to agree that at the NCP level thereshould be no special structure imposed on the data transmitted.  To anNCP all data to be transmitted are bit strings of arbitrary length.  One                                                                [Page 2]NWG/RFC 49      Conversations with Steve Crocker (UCLA)happy result is that the difficult question of character sets does nothave to be resolved at this protocol level.  To include a character setspecification at the NCP level would delay agreement on the protocol andmake this character set more resistant to change.  (If there is to be astandard character set, we prefer ASCII.  After all, it is the preferedstandard of our sponsoring organization.)We also agree with Steve that there should be no optional echoing ofmessages at the NCP protocol level.  (This is also the position of theSDC people in RFC 44.)5) Shoshani, Long, and Landsberg also state (RFC 33) that they prefer toalign messages to end on a word boundary as opposed to double padding.Steve agrees with us in not liking double padding.6) In our proposal (RFC 46) we suggest that RFCs be queued only for opensockets, that RFCs to inactive or connected sockets are to beautomatically rejected via the CLS command.  Steve proposes that RFCs tothese sockets be briefly queued.  If the socket remains in anunacceptable state for a specific interval after the RFC comes in, it isrejected.  This scheme allows certain types of network commandinteraction involving critical races to be implementable.  Such a schemeof limited queueing does not seem unreasonable to me.7) Steve, Tom, and I discussed strategies for a User Control andCommunication (UCC) Protocol.  Steve said that he disliked our UCCstrategy (RFC 46) because it requires maintaining two full-duplexconnections to the requestor process and switching between them.Steve put forth an alternate proposal: a process wishing to create auser process at a foreign HOST issues RFCs to sockets 0 and 1 belongingto the user whose process he wishes to create.  If these sockets areinactive, the NCP automatically directs these requests to the foreignHOST's logger process.  The logger accepts connection and performs thelogin ritual.  If successful, the logger creates a user process and letsgo of the usurped sockets so that the created process may use them tocommunicate with the requestor process.  (I note that this does not usereconnection at a network level, since the logger uses sockets belongingto the ultimate user.  However, it does involve internal reconnection.)Tom and I objected to this because it introduces UCC protocol into theNCP level.  (The NCP must direct all RFCs to inactive sockets 0 and 1 toa logger process.)  I made a quick suggestion that perhaps our twoproposals could be combined such that the requestor issues a"signalling" RFC to a "signal" socket of the UCC process.  The UCC                                                                [Page 3]NWG/RFC 49      Conversations with Steve Crocker (UCLA)rejects the RFC but remembers who is calling.  It then tries to connecttwo sockets of the process to be created to the requestor's sockets, andconducts the login ritual through these.  Steve liked this and suggestedthat I write it up.Following the conversation, I thought of several disadvantages to thisUCC strategy:(a) If the control sockets at a created process are limited to 0 and 1,there is the possibility that a rightful user may not be able tocommunicate with a foreign UCC because the UCC already is using thosesockets to communicate with an imposter.  The logger will discover thisand turn off the imposter, but this is an aggravating security breach.A malicious process could issue simultaneous multiple requests to tie upthe sockets and prevent access to a rightful user.  A better solution isto allow any socket pair of the potential user process to act as thecontrol path.  This permits the UCC to conduct simultaneousinterrogations of competing requestors.(b) A disadvantage of both Crocker's and the combined UCC is that theuser to be logged in is specified by supplying a socket belonging to aparticular user.  The logger must now make the additional check that theuser it is logging in actually belongs to the socket pair it is talkingover.  This seems the reverse of the prefered process: to identify auser and then determine the user code for his socket identifiers.(c) The user may not know the socket user code of the user he wishes tolog in at the foreign HOST.  (After all, there is no basic reason whythe requestor and created processes should have the same user code solong as the requestor satisfies the foreign logger.)(d) In the combined strategy, there is no way for the requestor tospecify which socket user code it wants.  The only assumption that theUCC can make is that the requestor process wishes to log in a processhaving the same socket user code as itself.  (This may not seem veryimportant, but I envision a scheme in which a local process exists toallow consoles attached to the local HOST to login at a foreign HOSTwithout being logged in locally.)(e) The idea of allowing a process to masquerade within the network asanother process (even with the best of intentions) by using its socketuser code introduces a potentially dangerous security breach.  I thinkthat it should be a basic protocol law that NO PROCESS WHATSOEVER mayrequest or accept connections or transmit or receive data over a sockethaving a user code not its own.  This does not apply to an NCP processwhich has responsibility for such transmission, nor does it prevent apriviliged process from closing or rejecting connections between aforeign process and another local process.                                                                [Page 4]NWG/RFC 49      Conversations with Steve Crocker (UCLA)I still think that the UCC proposal we advanced in RFC 46 is a goodworkable scheme.  It does not require socket reconnection (eitherexpressly throughout the network or implicitly within an NCP), nor doany of the objections raised above apply.  The only particulardisadvantage I see is that it requires the requestor process to maintainand switch between two full-duplex connections.  I don't see this as aserious hindrance.  I would like the comments of the networkparticipants on this point in particular.Fortunately the UCC is a third level protocol.  The second level NCP canbe specified before we reach final agreement on a UCC, provided that theNCP allows implementation of a workable UCC.Steve expressed the thought that there need not be an initial standardUCC, that there might be several UCCs.  We at MAC disagree.  If we areall to talk to each other, and not between limited subsets of HOSTswithin the network, there must be an initial standard UCC whichEVERYBODY implements.  (Steve is of course correct that there can beother experimental UCCs also implemented.)It is theoretically possible for each HOST to provide multiple sets ofsoftware to allow a requestor process to communicate with the loggers atHOSTs implementing different UCCs.  I don't think that it will work thisway in practice.  Each HOST will implement the UCC protocol that is mostagreeable to it, and will provide one set of software so that arequestor process can communicate only with those HOSTs which implementsimilar UCCs.I don't think that there is much enthusiasm at Project MAC forimplementing a non-standard UCC just so we can talk to ourselves.  Wewant to implement a single UCC supported at all installations, so thatwe can log in to all HOSTs using this protocol, and that users at allforeign HOSTs can log in to us.       [ This RFC was put into machine readable form for entry ]       [ into the online RFC archives by Altair Petrofsky 7/97 ]                                                                [Page 5]