GROSSMAN@SU-SIERRA.ARPA.UUCP (05/20/86)
DECnet solved this problem a long time ago. Here is what it does: In DECnet, the SYN message (called a CI in DECnet) can contain one of the following for both the destination and source ports: 1) A numeric service id (ala the FTP, TELNET, etc known ports). 2) A string service id (usually called a process name). 3) A PPN and a string service ID. This data is actually carried inside the CI message just as though it was user data. The point is that the desired service is specified by a string of bytes of (almost) arbitrary length and format in the normal data bucket within the message. By contrast, TCP describes the desired service by using some bytes from the port number of the packet, which is very small and inflexible compared to the aforementioned scheme. This means that the port numbers used in DECnet have no intrinsic meaning (other than to uniquely identify this logical link). Once DECnet has made a connection, there is no way to tell what type of service is being used over a logical link. With respect to secure services, DECnet implementations are supposed to only allow privileged people to offer services for service types 1-128. In addition, only privileged people are allowed to use a different PPN from their own in the source descriptor type. I don't beleive that any DECnet implementations currently impose any restrictions on the string service ID text. But it would be easy to add. Note that the format type is carried along in the CI message prefixed to the data that it is describing. Currently, only 3 format types are defined. It would be trivial to add more if they were deemed necessary. I think that adding this to TCP could be done fairly easily. One way to do it would be to create a new option: Kind Length Meaning ---- ------ ------- 3 -- Service ID If this option is present, then it communicates the name of the service that the user desires. The format of the service name is TBD... This option must only be sent in the initial connection request (i.e., in segments with the SYN control bit set). The only important thing about the Service ID is that it should be of arbitrary length, and allow for multiple (but well specified) formats by using a format type byte in the beginning of the data. Another way to put this into TCP would be to create a new control bit: SID: Service ID If this flag is on, then the data segment of the datagram contains a service name string. The format and restrictions on this would be the same as for the option described above. Now for the question of backwards compatibility. Lets say that old TCPs were allowed to just ignore this option/SID bit. Then senders would be able to ensure connections by making SYNs that used BOTH a known port AND the Service ID option/SID bit. The one bugaboo that this has is that TCPs that support the Service ID option/bit would have to be careful about avoiding "known ports" unless they really mean to use them for their intended purpose. A way around this would be to create another flag called the KP (Known Port (Kitchen Patrol :-)) flag. If this is set, you are using a known port, otherwise the port is just a random number. I would desperately urge people to come up with a better way than this flag. Just another point 'o view, Stu Grossman -------