Newsgroups: comp.protocols.tcp-ip
Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!think.com!sdd.hp.com!elroy.jpl.nasa.gov!decwrl!pa.dec.com!mogul
From: mogul@pa.dec.com (Jeffrey Mogul)
Subject: Re: well-behaved firewalls
Message-ID: <1991Jun25.003609.22406@pa.dec.com>
Sender: news@pa.dec.com (News)
Organization: DEC Western Research
References: <BOB.91Jun17182958@volitans.MorningStar.Com>
Date: Tue, 25 Jun 91 00:36:09 GMT
Lines: 27

In article <BOB.91Jun17182958@volitans.MorningStar.Com> bob@MorningStar.Com (Bob Sutterfield) writes:
>When a gateway is configured as a firewall, what is the polite thing
>to do about those packets that aren't passed?  The packet itself
>should be dropped on the floor, but should the originating system be
>told anything about it?

The system I implemented (see my paper in Proc. 1989 Summer USENIX
Conf.) currently sends "Host Unreachable" packets, but only in
those cases specified in the filtering rules.  E.g., the manager
of the gateway can say:

	from any to any tcp port telnet reject notify;
	from any to any tcp port finger reject;

This means that telnet users will get notification via ICMP, and finger users
will see their connections time out.  (This is a contrived example; in
real life, we tend to send notifications except in cases where nobody
is likely to be listening and the traffic rate could be high.)

In my implementation, the choice of ICMP type+code is wired into the kernel.
Given that I allow fine-grained choice of when to send an ICMP, it might
also be reasonable to add fine-grained choice of which ICMP code to send.
However, we've been running this way for more than 2 years without any
problems. [This code is now shipping with Ultrix (release 4.2) so if I
made the wrong choice, I guess I'll hear about it.]

-Jeff