I normally wouldn't forward something to such a big list, but this has
real implications (and was part of a nast DOS against dsl.ca last
week). The patch for FreeBSD (netbsd code is quoted) is trivial:
--- /sys/netinet/ip_input.c Thu Oct 17 08:29:53 2002
+++ ip_input.c Mon Nov 11 15:15:31 2002
@@ -1822,9 +1822,7 @@
break;
case ENOBUFS:
- type = ICMP_SOURCEQUENCH;
- code = 0;
- break;
+ return;
case EACCES: /* ipfw denied packet */
m_freem(mcopy);
I'm submitting a PR now.
For discussion: source quenches probably shouldn't be generated
anyways, but this patch also doesn't generate the source quench if
we're the target machine. It's probably good to go straight ahead
with this. IIRC, tcp_input.c also can generate a source quench
...
--- Begin Message ---
On Mon, Nov 11, 2002 at 02:11:42PM -0400, richard's all...
> Maybe a bit late...
> But.....
> ------snip-----
> #if 1
> /*
> * a router should not generate ICMP_SOURCEQUENCH as
> * required in RFC1812 Requirements for IP Version 4 Routers.
> * source quench could be a big problem under DoS attacks,
> * or if the underlying interface is rate-limited.
> */
4.3.3.3 Source Quench
A router SHOULD NOT originate ICMP Source Quench messages. As
specified in Section [4.3.2], a router that does originate Source
Quench messages MUST be able to limit the rate at which they are
generated.
DISCUSSION
Research seems to suggest that Source Quench consumes network
bandwidth but is an ineffective (and unfair) antidote to
congestion. See, for example, [INTERNET:9] and [INTERNET:10].
Section [5.3.6] discusses the current thinking on how routers
ought to deal with overload and network congestion.
A router MAY ignore any ICMP Source Quench messages it receives.
DISCUSSION
A router itself may receive a Source Quench as the result of
originating a packet sent to another router or host. Such
datagrams might be, e.g., an EGP update sent to another router, or
a telnet stream sent to a host. A mechanism has been proposed
([INTERNET:11], [INTERNET:12]) to make the IP layer respond
directly to Source Quench by controlling the rate at which packets
are sent, however, this proposal is currently experimental and not
currently recommended.
INTERNET:9.
A. Mankin, G. Hollingsworth, G. Reichlen, K. Thompson, R.
Wilder, and R. Zahavi, "Evaluation of Internet Performance -
FY89", Technical Report MTR-89W00216, MITRE Corporation,
February, 1990.
INTERNET:10.
G. Finn, A "Connectionless Congestion Control Algorithm",
Computer Communications Review, volume 19, number 5, Association
for Computing Machinery, October 1989.
/kc
> if (mcopy)
> m_freem(mcopy);
> return;
> #else
> type = ICMP_SOURCEQUENCH;
> code = 0;
> break;
> #endif
>
>
> - - - - - - - - - - - - -
> Jonathan Richards
> Tel:+1-416-876-5219
> Fax:+1-708-575-1680
> Email:[EMAIL PROTECTED]
--
Ken Chase, [EMAIL PROTECTED] * Velocet Communications Inc. * Toronto, CANADA
--- End Message ---
Dave.
