Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!seismo!sundc!pitstop!sun!decwrl!ucbvax!PURDUE.EDU!narten
From: narten@PURDUE.EDU (Thomas Narten)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: Bogon sightings
Message-ID: <8710221942.AA03243@percival.cs.purdue.edu>
Date: Thu, 22-Oct-87 15:42:12 EST
Article-I.D.: percival.8710221942.AA03243
Posted: Thu Oct 22 15:42:12 1987
Date-Received: Sun, 25-Oct-87 15:02:21 EST
References: <8710202001.aa28899@Huey.UDEL.EDU>
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The ARPA Internet
Lines: 56

Couple of observations.

1) Default routes tend to suck up everything, both valid and invalid.
First, there are obvious things like permutations of various broadcast
addresses. In subnetted environments, they also suck up packets for
subnetted networks that "don't exist". For instance, Suppose that
gateway A-GATE is on the ARPANET and fronts as a gateway to a subnetted
network A-NET. A-GATE runs EGP and has full routing tables, and all
machines on A-NET have a default route pointing to A-GATE.

Now suppose someone starts sending packets to machine BOGUSHOST.
BOGUSHOST is on a nonexistent subnet. Normally, these packets get
forwarded to A-GATE via the default route. A-GATE doesn't have a
default route, so the packet is discarded.

Now, if j-random core gateway X advertises a default route, we get a
routing loop. Instead of dropping packets for BOGUSHOST, A-GATE
forwards them to X. X, knowing nothing about subnets, forwards the
packet back to A-GATE.

The problem is, gateway A and gateway X don't have a consistent view
of A-NET. X sees it as one  network, A doesn't view A-NET as a
single network.

In my experiences with subnetting, these homeless packets appear from
time to time, much like invalid broadcasts that should never appear
either. In fact, invalid broadcasts in particular get sucked up by
default routes.

>All this wouldn't have mattered much, since the squawker should advise
>all squawkees via ICMP Unmentionable messages to do otherwise.

2) ICMP Unmentionable messages have little effect on some UDP oriented
protocols in 4.3. Errors can only be returned to sockets that have a
foreign address bound into them via connect(). Typically, UDP based
query/response servers send response messages by including the
destination address as an argument to the write call. When ICMP
errors get returned to the server, the OS has no way of matching the
error message with the socket it goes to.

Named is my favorite scapegoat in this regard.

3) The distributed version of 4.3 does not pass ICMP Unreachable
errors back to the TCP layer. It does process src quench and redirects
though. Machine's relying heavily on default routes almost always have
connections time out (after several retransmissions), as apposed to
having the connection attempt abort quickly with a "host unreachable"
error.  The fix for this is less than a dozen lines of code, I have
not seen Berkeley send out a fix for it (though in fairness, I may
have missed it).

This is all rather disturbing considering the heavy dependence placed
on default routing, and the recognized need for network applications
to better respond to network feedback.

Thomas