Date: Tue, 10 Mar 1998 16:23:43 -0500 (EST) From: Jt <hometeam@techpower.net> To: Alex Nash <nash@Mcs.Net> Cc: Mike D Tancsa <mdtancsa@sentex.net>, mike@sentex.net, stable@FreeBSD.ORG Subject: Re: ipfw unreach statement help Message-ID: <Pine.BSF.3.96.980310162212.3858A-100000@techpower.net> In-Reply-To: <Pine.BSF.3.95.980310120539.406C-100000@Jupiter.Mcs.Net>
next in thread | previous in thread | raw e-mail | index | archive | help
I noticed ipfw man pages :
Discard packets that match this rule, and try to
send an ICMP unreachable notice with code code,
what is preventing this from happening?
hometeam@techpower.net
--We cannot all be masters, nor all masters
Cannot be truly follow'd--
-----BEGIN PGP MESSAGE-----
Version: 2.6.2
owEBqwBU/4kAlQMFADRCxNWhsddKSTR+6QEBelED/jzeC3btZfqSdIfrNoCgwUJJ
iNQ33UQoMyJ2ygkfl72xP5J79yml/F4P73GnNaDVbaMOmOG2NNAi5ElE73wRh54U
17kH+n5XnYeqekV8T2TG2Q6ex3UotXPyZ1vvrCrSxapOz6a4hh0GQeA55rcwLy2W
ROHwxfvaVsrX5iVOkRoerBFiC21lc3NhZ2UudHh0AAAAAA==
=jCvF
-----END PGP MESSAGE-----
On Tue, 10 Mar 1998, Alex Nash wrote:
> 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
>
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.96.980310162212.3858A-100000>