TCP/TIME service
17-Jul-86 14:15:43-UT


The level of TCP/TIME requests directed to our DCnet fuzzballs has escalated
to the point of serious intrusion in other services. Our DCN1.ARPA fuzzball,
for example, is also our ARPAnet gateway DCN-GATEWAY and well-known as a good
source of accurate time. The problem is that the poor horse has only two
TCP servers, ordinarily used only for casual snooping and maintenance. A
TCP/TIME transaction takes anywhere from eight to 20 seconds, depending on
the path and degree of flake involved. At the present volume of requests,
it is not unusual for both servers to be occupied, while other requestors
are flailing SYNs and congesting the buffer pool.

As the longtime browsers of this know, I have invited clockwatchers to use
UDP/TIME and NTP/TIME protocols but highly discouraged use of the TCP/TIME
protocol. Not only are the former much more accurate, but the latter is very
disruptive to our normal operations. Note that Unix daemons for UDP-based
time services are readily available. (Eeep - make that UDP/NTP, not NTP/TIME
in the above!)

Some clockwatchers are using TCP/TIME on DCnet fuzzballs other than DCN1.ARPA.
Again, be advised the other critters set their watches from DCN1.ARPA anyway,
so there is nothing to be gained except escaping detection in the logs.

At the end of the month I will review the situation. If the onslaught persists,
I may have to disable the TCP/TIME service, perhaps (following a recent suggestion)
including a random offset of amplitude maybe two days.


This archive was generated by hypermail 2.0b3 on Thu Mar 09 2000 - 14:36:34 GMT