Subject: kern/10134: ipfilter with careless ICMP rules will send ICMP in response to ICMP
To: None <email@example.com>
From: Jonathan Stone <jonathan@DSG.Stanford.EDU>
Date: 05/16/2000 16:21:20
>Synopsis: ipfilter with careless ICMP rules will send ICMP in response to ICMP
>Arrival-Date: Tue May 16 16:22:00 PDT 2000
>Release: netbsd 1.4Y, 1.4P, 1.4L, 1.4N.
System: NetBSD Cup.DSG.Stanford.EDU 1.4.1 NetBSD 1.4.1 (GENERIC) #0: Tue Nov 9 12:18:04 PST 1999 jonathan@Cup.DSG.Stanford.EDU:/src/NetBSD/src/sys-1.4-release/src/sys/arch/i386/compile/GENERIC i386
Actually verified between i386 systems running netbsd 1.4Y, 1.4P, 1.4L, 1.4N.
(someone may have installed a newer version of IPfilter on the older
systems behind my back).
Set up simple rules which block most incoming traffic,
including ICMP, returning
an ICMP "administratively denied" message.
(this is perfectly safe to do if you __know__ that your local
interface has the same MTU as an upstream router which
will handle, e.g., IP MTU discovery for you).
Do this on two machines, A and B.
Attempt to send a UDP packet from A to B.
B's filter rules say the UDP packet should be dropped
and an ICMP message sent. B duly sends an ICMP
A's rules say nothing special about silently discarding
ICMP, so A responds to the "administratively denied" ICMP
by sending back an "administratively denied" ICMP to B.
This is in clear violation of Host Requirements RFC,
(rfc 1122 section 3.2.2)
At this point, an ICMP loop has been established,
and will last until one or other machine is rebooted,
or IPfilter is disabled.
I have a lot of sympathy with just saying "dont do that".
But I think the most-correct (vis-a-vis rfc1222) action
is to modify IPfilter's "block return-icmp" to check if the
blocked packet is an ICMP, and if it is, to silently
drop the ICMP packet.