Re: Re- TCP broadcast storm

[Bob Braden <[e-mail]>]

  *> From [e-mail] Thu Oct 28 05:06:04 1993
  *> Date: 27 Oct 1993 17:45:00 U
  *> From: "MGauthier" <[e-mail]>
  *> Subject: Re- TCP broadcast storm
  *> To: [e-mail]
  *> Cc: "Robert Braden" <[e-mail]>
  *> Content-Length: 7357
  *> X-Lines: 156
  *> 
  *> Subject:     Re: TCP broadcast storm
  *> [To R. Braden:  there is a question (or observation) at the end of this
  *>  message asking why RFC 1122 doesn't explicitly say that TCP should
  *>  always ignore and never generate broadcast/multicast packets, instead
  *>  of just mentioning SYN packets.]

Marc,

The reasoning was this: the IP addresses of the endpoints of a TCP
connection are bound when a connection is opened.  A multicast address
appearing in a data or ACK segment must be ignored by the normal TCP
demux machinery, unless that address occurred in a SYN segment when the
connection was opened.  Hence, it is only necessary to make a special
test for multicast address at open time.

  *> 
  *> |From: "Ray Abbitt" <[e-mail]>
  *> |SUBJECT: Kind of interesting problem.
  *> |
  *> |>From: Glenn Davis <[e-mail]>
  *> |>Subject: TCP broadcast storm
  *> |>I am troubleshooting a particularly devilish network problem.  About two
  *> |>days ago I started seeing very high TCP broadcast traffic on our internal
  *> |>TCP/IP network.  After taking a network sniffer to the problem I discovered
  *> |>packets like:
  *> |>
  *> |>13-OCT-1993 02:59:09.76 02-60-8C-A5-4F-BD FF-FF-FF-FF-FF-FF  08-00 len=  46
  *> |>IP: vers=4 hdrlen= 5 lngwrds, svc:Routine
  *> |>    total len=   40  ID=%X967E frag ofs=    0
  *> |>    TTL= 30 prot=  6 TCP (Transmission Control), cksum=%X3B1E
  *> |>    src=255.255.255.255  dest=255.255.255.255
  *> |>TCP:port:src=31876 dest=132 seq#=523398 ack#=523398
  *> |>    window=0 len=5 Lwrds,ACK,RST cksum=39AD urgentptr=0
  *> |>FFFFFFFF 3B1E061E 0000967E 28000045 E..(~......;....  0000
  *> |>86FC0700 86FC0700 8400847C FFFFFFFF ....|.....|...|.  0010
  *> |>    4646 45434620 0000AD39 00001450 P...9Z.. FCEFF    0020
  *> |>
  *> |>Approximately 35 network stations (PC's running Netmanage TCP/IP) were
  *> |>sending out these packets as fast as their network adapters would allow!
  *> |>
  *> |>What seemed to happen is: each station would see a packet like the one
  *> |>above, and send out a RST (reset) response (ie this packet not for me).

Your analysis later is correct.  The Host Requirements RFC 1122 says
(4.2.3.10) that "A TCP implementation MUST silently discard an incoming
SYN segment that is addressed to a broadcast or multicast address".
Here "silently" means don't send a RST!

  *> |>This would repeat itself ad-nauseum, dragging the network down with all
  *> |>the broadcast traffic!
  *> |>[...]
  *> |>The only thing that stopped the beast was to shut down the entire network!
  *> |
  *> |I ran this by one of the other guys at work and got this reply:
  *> |
  *> |FROM:  FRANK H. COLETTI([e-mail])
  *> |Subject: Kind of interesting problem.
  *> |Ray: This is a known bug in TCP traffic and was probably started by some-
  *> |one who intentionally wanted this to happen. As far as I understand it
  *> |you can start it by custom making an ARP packet, or some other such packet,
  *> |and instead of putting your MAC address in the source field, you put the
  *> |broadcast address. This causes other machines that get the packet via the
  *> |broadcast to respond and automatically put in the original packet's
  *> |source address-in this case, the broadcast address again. This causes
  *> |a "Broadcast Storm" and what you saw is exactly what happens. It brings
  *> |the network to its knees. In one of the classes I attended they said
  *> |that some college guy did it on the Internet a couple of years ago and
  *> |promptly brought the Internet down.
  *> |[...]

No way.  A broadcast storm like this could have clogged the local
Ethernet, but not the Internet as a whole.  Perhaps he was referring to
the infamous Morris Worm, which was a far more subtle attack (and did
bring down a signficant part of the Internet).

  *> 
  *> I don't think this is a "known bug in TCP traffic", but rather a bug
  *> in that particular TCP implementation (unless you mean that particular
  *> bug is known to be present in a number of TCP implementations).
  *> A TCP should NEVER reply to a RST packet.

Right.  I suppose 1122 could say this more explicitly, since 793 was
not direct about it.  But anyone who has ever implemented a protocol
would realize that sending a RST for a RST is a bad idea!!

                                                 Although it's a bit spread
  *> out, this is rather clear from RFC 793 ("SEGMENT ARRIVES", pages 65-76),
  *> and from this explicit paragraph on page 36:
  *>     1.  If the connection does not exist (CLOSED) then a reset is sent
  *>     in response to any incoming segment except another reset.  In
  *>                                         ^^^^^^^^^^^^^^^^^^^^
  *>     particular, SYNs addressed to a non-existent connection are rejected
  *>     by this means.
  *> 
  *> Generally speaking, a proper TCP/IP implementation should NOT be prone
  *> to broadcast storms.  There are many discussions in the RFCs on steps
  *> that must be taken to avoid such possibilities.  If you find software
  *> that generates broadcast storms, then most likely the software itself
  *> is the culprit.  I know of no way for IP or TCP to be subject to broadcast
  *> storms, **when properly implemented according the the latest RFCs**.

Well, we hope so.  The Host Requirements group spent a lot of energy
trying to make things robust against broadcast storms -- but of course
we might have overlooked something.

  *> (Please correct me if you know full details of a valid counterexample.)
  *> I don't claim that most implementations are fully conformant :-)
  *> 
  *> The above TCP/IP implementation has a second bug, the removal of which
  *> would avoid this broadcast storm.  Simply said, IP packets with broadcast
  *> or multicast source addresses MUST be discarded.
  *> 
  *> RFC 1122 says (for TCP and UDP):
  *> 
  *>          4.2.3.10  Remote Address Validation
  *> 
  *>             A TCP implementation MUST reject as an error a local OPEN
  *>             call for an invalid remote IP address (e.g., a broadcast or
  *>             multicast address).
  *> 
  *>             An incoming SYN with an invalid source address must be
  *>             ignored either by TCP or by the IP layer (see Section
  *>             3.2.1.3).
  *> 
  *>             A TCP implementation MUST silently discard an incoming SYN
  *>             segment that is addressed to a broadcast or multicast
  *>             address.
  *> 
  *>          4.1.3.6  Invalid Addresses
  *> 
  *>             A UDP datagram received with an invalid IP source address
  *>             (e.g., a broadcast or multicast address) must be discarded
  *>             by UDP or by the IP layer (see Section 3.2.1.3).
  *> 
  *>             When a host sends a UDP datagram, the source address MUST be
  *>             (one of) the IP address(es) of the host.
  *> 
  *> It is clear from the above that broadcast and multicast addresses are
  *> not allowed as source addresses in IP datagrams, and that such datagrams
  *> should be discarded.  This is also stated explicitly in section 3.2.1.3
  *> of RFC 1122, on IP addressing:
  *> 
  *>          3.2.1.3  Addressing: RFC-791 Section 3.2
  *>             [...]
  *>             When a host sends any datagram, the IP source address MUST
  *>             be one of its own IP addresses (but not a broadcast or
  *>             multicast address).
  *> 
  *> [I believe there is an exception to the above for IP-level IP address
  *>  discovery protocols such as BOOTP, in which case 0.0.0.0 is used as
  *>  a source address by the BOOTP client. -MEG]
  *> 
  *>             A host MUST silently discard an incoming datagram that is
  *>             not destined for the host.  ...
  *>             [...]
  *>             A host MUST silently discard an incoming datagram containing
  *>             an IP source address that is invalid by the rules of this
  *>             section.  This validation could be done in either the IP
  *>             layer or by each protocol in the transport layer.
  *>             [...]
  *> 
  *> 
  *> I propose that the stated TCP/IP implementation has yet a third bug,
  *> removal of which would also prevent a broadcast storm.  It is simply that
  *> TCP should never respond to broadcast or multicast packets.  TCP is not a
  *> broadcast/multicast protocol, and should never generate (or respond to)
  *> such traffic.  (I'm ignoring the ARP mechanisms, which operate at the
  *> network level; ARP has / should have its own mechanisms to avoid
  *> broadcast storms.)  However, I couldn't find any explicit statement of
  *> this more general that what is found in section 4.2.3.10 of RFC 1122
  *> (see above quote).  Why isn't this clearly pointed out in RFCs?
  *> Looks like an omission...
  *> 
  *> 
  *> So the solution to Glenn's problem (other than shutting down the net for
  *> a short term fix) would be to contact the suppliers/writers of the
  *> TCP/IP software and tell them how buggy their software is.  You could
  *> quote the above.

Right!

Bob Braden

  *> 
  *> 73,
  *> 
  *> -Marc     VE2SOR
  *> --
  *> Marc E. Gauthier     Software Eng. Lab, IIT, National Research Council Canada
  *> [e-mail]  Building M-50, Ottawa ON, Canada  K1A 0R6
  *> [phone]   fax: [phone]   home: [phone]  (Hull QC)
  *> NCFreeNet: [e-mail]     Disclaim: I speak for myself only
  *> 
  *> 
  *>