From: [email-masked]
Date: Wed, 1 Oct 2003 08:47:50 -0400 (EDT)

([email-masked] [192.94.214.100])
	by lists.tislabs.com (8.9.1/8.9.1) with ESMTP id CAA27300
	Wed, 1 Oct 2003 02:48:42 -0400 (EDT)
nutshell.tislabs.com via csmap (V6.0)
	id srcAAA_daqZD; Wed, 1 Oct 03 02:55:55 -0400
To: [email-masked]
Subject: Re: 2401bis Issue # 84 -- DROP'd outbound packet
References: <[email-masked]>
From: Markus Stenberg <[email-masked]>
Date: 01 Oct 2003 09:53:24 +0300
In-Reply-To: Charles Lynn's message of "Tue, 30 Sep 2003 10:03:04 -0400 (EDT)"
Message-ID: <[email-masked]>
Lines: 29
User-Agent: Gnus/5.0807 (Gnus v5.8.7) XEmacs/21.1 (Cuyahoga Valley)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: [email-masked]
Precedence: bulk

Charles Lynn <[email-masked]> writes:
>  It would be nice it the user could be given some indication of the
>  problem so that they could initiate corrective action.

Yes, in an ideal world with clued users and no black hats.

>  Should we define additional ICMP codes to distinguish the cases?
>  I think we should.

I am somewhat nervous of adding variety of obscure ICMP messages, none of
which can be obviously protected, and are therefore spoofable. And to top
it off, most of the typical client end-user applications nowadays (say, web
browsers, email readers) don't give meaningful error messages for ANY ICMP
messages anyway.

_If_ this is really useful feature (I'm not very convinced myself, but at
least some people apparently are), I think it should be MAY at best. A
security infrastructure relying on insecure error messages sounds dangerous
for some reason - at least human-level DoS is easily achieved with such
infrastructure. (e.g. send forged ICMP messages, end user notes that oops,
can't do, and starts bothering IT people.. multiply this by X where X is
number of users, and you have lots of fun)

-Markus

-- 
"Why? Are they brain damaged?"
"No more so than anyone who works on computers for a living."
- Neal Stephenson/Frederick George, "Interface"