Date: Tue, 10 Mar 1998 12:36:03 -0600 (CST) From: Alex Nash <nash@Mcs.Net> To: Mike D Tancsa <mdtancsa@sentex.net> Cc: mike@sentex.net, stable@FreeBSD.ORG Subject: Re: ipfw unreach statement help Message-ID: <Pine.BSF.3.95.980310120539.406C-100000@Jupiter.Mcs.Net> In-Reply-To: <199803101757.MAA29599@granite.sentex.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 10 Mar 1998, Mike D Tancsa wrote: > > ipfw will not send an ICMP packet in response to an ICMP packet. Doing so > > might result in some nasty endless loops. One could argue that it would > > make sense to reply with ICMP_UNREACH when the incoming packet was not > > ICMP_UNREACH, but more thought would be required to ensure there weren't > > any endless loop scenarios possible from this (I can't think of any > > off-hand). > > Hi, > > Just curious, but could you give me an example of such ? Where > an ICMP packet of type 8 coming in would result in an endless loop ? Your example would not generate such a loop. However, let's consider a highly contrived example. Host A and B are on different networks, both run with the rule: unreach host icmp from any to xxx.xxx.xxx.xxx/yy in via xyz0 Where xxx.xxx.xxx.xxx/yy represent their respective network address/mask, and xyz0 represents their network connection to each other. Now, if A pings B, or B pings A, or even worse, some other host (C) fakes a ping packet from host A to host B, then the following happens: 1. host B receives ICMP packet (seemingly) from A 2. ipfw finds a rule which says "send a host unreachable message" 3. B sends back host unreachable to A 4. A receives host unreachable message, and finds a similar ICMP rule 5. A sends host unreachable back to B 6. loop to step 1 The proposal I made before, not to respond to an ICMP_UNREACH message with another ICMP_UNREACH message should solve this problem. > I was just looking for a better way > to let people on the outside that we prohibit pings comming it.. I get > sick answering all the mail asking if our network is down just because > we dont allow pings coming in indescriminately... It's interesting to note that none of the umpteen addresses of www.microsoft.com respond to pings either. I could have sworn that about a month or so ago they replied to pings with an ICMP unreachable message (communication prohibited by filter). Perhaps this was done to conserve bandwidth? Or perhaps their filter wasn't very smart and ended up in a loop as described above. Alex To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.95.980310120539.406C-100000>