Stu Grossman (GROSSMAN@SU-SIERRA.ARPA)
Mon 19 May 86 17:32:32-PDT
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
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,
This archive was generated by hypermail 2.0b3 on Thu Mar 09 2000 - 14:36:33 GMT