[14043] in Athena Bugs
Weird IP TOSs on 18.181
daemon@ATHENA.MIT.EDU (John Hawkinson)
Sun Dec 10 01:24:47 1995
Date: Sun, 10 Dec 1995 01:24:12 -0500
To: rtfm-maintainers@MIT.EDU, anxiety-maintainers@MIT.EDU,
sipb-irc-maintainers@MIT.EDU, network@MIT.EDU, bugs@MIT.EDU
Cc: hartmans@MIT.EDU, elliot@MIT.EDU, webmaster@MIT.EDU
From: John Hawkinson <jhawk@MIT.EDU>
This evening I collected some statistics on IP type of service in use
on SIPB-ETHER. Most of this is irrelevent fact, but some is amusing :-)
There's a network misconfig, a solaris bug, and other anomalies.
I ran NNStat for 55 minutes and it found the following summary information:
OBJECT: TOS Class= freq-all [Created: 19:11:10 12-09-95]
ReadTime: 20:06:06 12-09-95, ClearTime: 19:11:10 12-09-95 (@-3296sec)
Total Count= 3570000 (+0 orphans)
#bins = 7
[x00]= 3568470 (100.0%) @-0sec 99.957142857142857142
[x08]= 617 ( <.1%) @-114sec 00.017282913165266106
[x10]= 433 ( <.1%) @-114sec 00.012128851540616246
[xc0]= 330 ( <.1%) @-8sec 00.009243697478991596
[x3c]= 89 ( <.1%) @-480sec 00.002492997198879551
[x01]= 53 ( <.1%) @-2216sec 00.001484593837535014
[xff]= 8 ( <.1%) @-676sec 00.000224089635854341
Here are descriptions of the TOS byte (which rightly includes
Precedence and TOS), glommed from RFC791 and RFC1349:
0x01: Must-be-zero = 1 (ILLEGAL)
0x08: TOS: maximize throughput
0x10: TOS: minimize delay
0x3c: Precedence: Priority,
TOS: mimimize delay, maxmize throughput & reliability
(ILLEGAL)
0xc0: Precedence: Internetwork Control
0xc6: Precedence: Internetwork Control,
TOS: mazimize reliability, minimize monetary cost (ILLEGAL)
0x80: Precedence: Flash Override (?)
0xff: Precedence: network control,
TOS: mimimize delay & monetary cost, maxmize throughput & reliability
Must-be-zero = 1
(ILLEGAL)
To investigate, I ran tcpdump (ip[0] != 0) from about 20:30 to 00:13.
There were two sorts legitimate uses of TOS:
* Both 0x08 and 0x10 were used by ftp clients connecting bloom-picayune. We
should consider providing a TOS-capable ftpd since currently TOS is
only get used on the client->server communications, which consists of
the control connection (most data) and the data connections (only
ACKs). Perhaps this is not possible under Ultrix? The 4.4lite ftpd has
support for this, at the least.
* OSPF Hello messages from W20-RTR with Internetwork Control. Unfortunately,
this reflects a misconfiguration of MITnet routers. By sending OSPF
Hellos on ethernet interfaces (meaning that the interfaces were not
marked as "passive" in the router configuration), any OSPF neighbors
on a particular subnet would be discovered. This would allow the
so-called "dealing IP" where any workstation could inject /32s into
MITnet's IGP [see Hacker, Alyssa P. "IP Address Shortage Spurs Black
Market". Voo Doo Magazine, Late Fall '95, pp. 22-23].
There were a number of cases of inappropriate usage:
* ftp and www connections that use 0x3c. Presumably the developers of these
applications are attempting to unfairly take advantage of TOS where it
is implemented in the network. Note that 205.217.132/24 belongs to
WESTERN KY ONLINE SERVICES, per whois. I've only listed the first
packet from each source. It's worth noting that all of these seemed to
be dialup IP connections, and are thus presumably PC or Mac
stacks. None of the source addresses pinged when I tried. For those
service providers whose customers consistently use this software,
perhaps someone should consider contacting them and asking them to
consider fixing this, particularly if the service provider is
distributing the software being used.
20:34:10.162241 205.217.132.35.1762 > ANXIETY-CLOSET.MIT.EDU.8001: S 3193350880:3193350880(0) win 2920 <mss 536> [tos 0x3c] (ttl 50, id 3036)
20:54:11.521321 ewing03.voicenet.com.2017 > ANXIETY-CLOSET.MIT.EDU.8001: S 3198122976:3198122976(0) win 2920 <mss 536> [tos 0x3c] (ttl 44, id 1735)
21:30:13.051582 ip27.baltimore.md.interramp.com.2033 > BLOOM-PICAYUNE.MIT.EDU.ftp: S 3200312304:3200312304(0) win 2920 <mss 536> [tos 0x3c] (ttl 47, id 1682)
interramp
21:44:01.765070 cnk036.conknet.com.1633 > ANXIETY-CLOSET.MIT.EDU.8001: S 3201509984:3201509984(0) win 2920 <mss 536> [tos 0x3c] (ttl 52, id 1040)
21:55:45.405737 ip168.new-york2.ny.interramp.com.1042 > ANXIETY-CLOSET.MIT.EDU.8001: S 3201864720:3201864720(0) win 2920 <mss 536> [tos 0x3c] (ttl 47, id 4702)
00:04:38.701537 cnk042.conknet.com.1121 > ANXIETY-CLOSET.MIT.EDU.8001: S 3210148960:3210148960(0) win 2920 <mss 536> [tos 0x3c] (ttl 52, id 6212)
* ICMP fragments tagged with TOS byte 0x1. These are interesting in that 0x1
has never been a valid type of service, so one suspects the OS is just
broken. In this case it seems that closet sent 1992-byte (fragmented
to mtu) and 7944-byte (also fragmented) ICMP echo replies to this BU
machine, which did not use bizarre TOS on ICMP echo requests. I sent
closet 8000-byte pings ("ping -s wwww 7992") and it used TOS 0x1 on
its return packets. Could someone (bugs) confirm if this is a known
Solaris bug and if not, submit it to Sun?
21:49:46.249404 ANXIETY-CLOSET.MIT.EDU > ROYCROFT.BU.EDU: icmp: echo reply (frag 272:1480@0+) [tos 0x1] (ttl 255)
21:49:46.251890 ANXIETY-CLOSET.MIT.EDU > ROYCROFT.BU.EDU: (frag 272:512@1480) [tos 0x1] (ttl 255)
21:49:46.254558 ANXIETY-CLOSET.MIT.EDU > ROYCROFT.BU.EDU: icmp: echo reply (frag 274:1480@0+) [tos 0x1] (ttl 255)
21:49:46.255042 ANXIETY-CLOSET.MIT.EDU > ROYCROFT.BU.EDU: (frag 274:512@1480) [tos 0x1] (ttl 255)
21:49:46.267190 ANXIETY-CLOSET.MIT.EDU > ROYCROFT.BU.EDU: icmp: echo reply (frag 279:1480@0+) [tos 0x1] (ttl 255)
21:49:46.267685 ANXIETY-CLOSET.MIT.EDU > ROYCROFT.BU.EDU: (frag 279:512@1480) [tos 0x1] (ttl 255)
21:49:46.269043 ANXIETY-CLOSET.MIT.EDU > ROYCROFT.BU.EDU: icmp: echo reply (frag 280:1480@0+) [tos 0x1] (ttl 255)
21:49:46.269498 ANXIETY-CLOSET.MIT.EDU > ROYCROFT.BU.EDU: (frag 280:512@1480) [tos 0x1] (ttl 255)
21:50:16.634695 ANXIETY-CLOSET.MIT.EDU > ROYCROFT.BU.EDU: icmp: echo reply (frag 3799:1480@0+) [tos 0x1] (ttl 255)
21:50:16.636004 ANXIETY-CLOSET.MIT.EDU > ROYCROFT.BU.EDU: (frag 3799:1480@1480+) [tos 0x1] (ttl 255)
21:50:16.637244 ANXIETY-CLOSET.MIT.EDU > ROYCROFT.BU.EDU: (frag 3799:1480@2960+) [tos 0x1] (ttl 255)
21:50:16.638534 ANXIETY-CLOSET.MIT.EDU > ROYCROFT.BU.EDU: (frag 3799:1480@4440+) [tos 0x1] (ttl 255)
21:50:16.639790 ANXIETY-CLOSET.MIT.EDU > ROYCROFT.BU.EDU: (frag 3799:1480@5920+) [tos 0x1] (ttl 255)
21:50:16.640269 ANXIETY-CLOSET.MIT.EDU > ROYCROFT.BU.EDU: (frag 3799:544@7400) [tos 0x1] (ttl 255)
* I don't really know what "Flash Override" is. I suspect that some IRC weenie
managed to confuse IP Precedence "flash" with IRC "flash", which are
two very different things, the former presumably specified by the DOD,
the latter hopefully not. Perhaps logs of the IRC server provide
interesting information at this time. Unknown.
23:02:16.537420 199.234.116.105.1697 > BLOOM-PICAYUNE.MIT.EDU.6667: SRP 1886546294:1886546324(30) win 24932 urg 10099 [tos 0x80] (ttl 46, id 469)
23:02:17.064735 truncated-tcp 4 [tos 0x80] (ttl 46, id 470)
* Lastly, we seem to have another broken dialup IP client. A TOS of all ones
is just plain broken. A tos of 0xc6 is illegal, and even prior to
RFC1349 does not seem awfully logical.
00:10:58.377632 port21.crso.com.1115 > ANXIETY-CLOSET.MIT.EDU.8001: S 3796828160:3796828160(0) win 8192 <mss 1400> [tos 0xff] (ttl 241, id 2113)
00:10:58.449670 port21.crso.com.1116 > ANXIETY-CLOSET.MIT.EDU.8001: S 3813605376:3813605376(0) win 8192 <mss 1400> [tos 0xff] (ttl 241, id 2114)
00:13:37.771594 port21.crso.com.1133 > ANXIETY-CLOSET.MIT.EDU.8008: S 962265088:962265088(0) win 8192 <mss 1400> [tos 0xc6] (ttl 241, id 2558)
That's it. I hope someone found this interesting. Please restrict replies to
the appropriate place. tcpdump for popular architectures may be found in
/afs/sipb/project/tcpdump.
--jhawk
