[Bug 279653] Page fault in in6_selecthlim
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279653 --- Comment #3 from Zhenlei Huang --- (In reply to Andrey V. Elsukov from comment #2) Emm, I guess we have to disassemble the kernel file to figure out what happens behind, if this can not be repeated. -- You are receiving this mail because: You are the assignee for the bug.
Re: Discarding inbound ICMP REDIRECT by default
On 2024-06-14 05:50, Ed Maste wrote: On Wed, 12 Jun 2024 at 18:05, Chris wrote: As Rodeney already effectively explains; dropping packets makes routing, and discovery exceedingly difficult. Which is NOT what the average user wants, This is on end hosts only, not routers (which already drop ICMP REDIRECT). or expects. I use "set block-policy drop" in pf(4). But as already noted, this is for "filtering" purposes. Your suggestion also has the negative affect of hanging remote ports. Which can result in other negative results by peers. I don't follow -- how does a host not processing ICMP REDIRECT cause these effects? It appears I may have overstated my point here. Dropping redirects isn't (necessarily) out of line. I was thinking in terms of dropping (all) queries. Which is wrong in this context. Sorry. :) Thanks for taking the time to respond. --Chris
Re: Discarding inbound ICMP REDIRECT by default
> On Fri, 14 Jun 2024 at 11:13, Rodney W. Grimes > wrote: > > > > That section is about how the router responds to an ICMP redirect > > set to IT, not one that is going THROUGH it. > > Sorry I wasn't explicit, in all cases I'm talking about ICMP REDIRECTs > destined for the machine (as a host or as a router). This is > icmp_input dropping when either drop_redirect or ipforwarding is true. Ok, so long as we are not dropping ICMP REDIRECTS that are NOT destined for the router we are fine, which is the behavior I expected and observed on my network, though it is a bit older code. -- Rod Grimes rgri...@freebsd.org
Re: Discarding inbound ICMP REDIRECT by default
On Fri, 14 Jun 2024 at 11:13, Rodney W. Grimes wrote: > > That section is about how the router responds to an ICMP redirect > set to IT, not one that is going THROUGH it. Sorry I wasn't explicit, in all cases I'm talking about ICMP REDIRECTs destined for the machine (as a host or as a router). This is icmp_input dropping when either drop_redirect or ipforwarding is true.
Re: Discarding inbound ICMP REDIRECT by default
W dniu 8.05.2024 o 21:14, Ed Maste pisze: It may make sense to apply the same default change for IPv6, but I don't think we need to tie the two discussions / investigations together. IMHO it is important to link ICMP6 with ICMP in terms of ICMP redirection. I have the impression that we are neglecting the IPv6 field again and this is our common sin. -- Marek Zarychta
Re: Discarding inbound ICMP REDIRECT by default
> On Fri, 14 Jun 2024 at 09:52, Rodney W. Grimes > wrote: > > > > > > I would argue that having IP forwarding enabled (i.e. > > > net.inet.ip.forwarding for IPv4) is what establishes FreeBSD as a > > > router, and ICMP REDIRECT messages are already dropped in kernel in > > > that case. > > > > Yet another mistake by FreeBSD. These ICMP dropping or not dropping > > are SITE SPECIFIC POLICIES, and should never be hard coded to wrong > > knobs. > > This change dates to 2004: > > commit 87c3bd275523515dc67444b900a8f1d39ae257cd > Author: Andre Oppermann > Date: Tue Jan 6 23:20:07 2004 + > > According to RFC1812 we have to ignore ICMP redirects when we ^^ Incorrect interpretation of ietf keyword "MAY". > are acting as router (ipforwarding enabled). > > This doesn't fix the problem that host routes from ICMP redirects > are never removed from the kernel routing table but removes the > problem for machines doing packet forwarding. > > RFC1812 is not quite that explicit, but: > > | A router using a routing protocol (other than static routes) MUST NOT > | consider paths learned from ICMP Redirects when forwarding a packet. > | If a router is not using a routing protocol, a router MAY have a > | configuration that, if set, allows the router to consider routes > | learned through ICMP Redirects when forwarding packets. That section is about how the router responds to an ICMP redirect set to IT, not one that is going THROUGH it. 5.2.7.2 about generating redirects is also not relavant here, as we are discussing forwarding redirects. As far as I can find RFC1812 does NOT discuss the issue of forwarind ICMP REDIRECTs. -- Rod Grimes rgri...@freebsd.org
Re: Discarding inbound ICMP REDIRECT by default
On Fri, 14 Jun 2024 at 09:57, Rodney W. Grimes wrote: > > I am not sure that it would "hang" the port, but by ignoring the > rediect your going to place additional burden on the router that > is trying to redirect you as all packets would have to be forwarded > by that router. I suppose it could hang you if infact the router > sent the redirect but did not forward the packet for you expecting > that a retransmission with your updated routing table due to the > redirect would get the flow going. The router is required to forward the packet (RFC1812); if an ICMP REDIRECT is necessary it is sent as the final step in unicast forwarding.
Re: Discarding inbound ICMP REDIRECT by default
On Fri, 14 Jun 2024 at 09:52, Rodney W. Grimes wrote: > > > > I would argue that having IP forwarding enabled (i.e. > > net.inet.ip.forwarding for IPv4) is what establishes FreeBSD as a > > router, and ICMP REDIRECT messages are already dropped in kernel in > > that case. > > Yet another mistake by FreeBSD. These ICMP dropping or not dropping > are SITE SPECIFIC POLICIES, and should never be hard coded to wrong > knobs. This change dates to 2004: commit 87c3bd275523515dc67444b900a8f1d39ae257cd Author: Andre Oppermann Date: Tue Jan 6 23:20:07 2004 + According to RFC1812 we have to ignore ICMP redirects when we are acting as router (ipforwarding enabled). This doesn't fix the problem that host routes from ICMP redirects are never removed from the kernel routing table but removes the problem for machines doing packet forwarding. RFC1812 is not quite that explicit, but: | A router using a routing protocol (other than static routes) MUST NOT | consider paths learned from ICMP Redirects when forwarding a packet. | If a router is not using a routing protocol, a router MAY have a | configuration that, if set, allows the router to consider routes | learned through ICMP Redirects when forwarding packets.
Re: Discarding inbound ICMP REDIRECT by default
> > > > Discarding ICMP redirects on a internet host is non-conformant with > > > > STD-3 via rfc-1122. Processing of ICMP rediects is a MUST for hosts. > > > > > > In that case our default of "auto" is non-conformant if you have a > > > routing daemon. > > > > NO, because then your not subject to rfc-1122 as your now a router, > > not a host. > > I would argue that having IP forwarding enabled (i.e. > net.inet.ip.forwarding for IPv4) is what establishes FreeBSD as a > router, and ICMP REDIRECT messages are already dropped in kernel in > that case. Yet another mistake by FreeBSD. These ICMP dropping or not dropping are SITE SPECIFIC POLICIES, and should never be hard coded to wrong knobs. One can easily be using FreeBSD as a router inside an AS that has a need for ICMP REDIRECT to pass through that router unfiltered. But I would agree in general that the better detection mechanism for the "auto" keyword of /etc/rc.conf icmp_drop_redirects is probably the value of net.inet.ip.forwarding and net.inet6.ip6.forwarding, but iirc the is an ordering issue. Could use the *GATWEAY_ENABLE rc.conf variables though. -- Rod Grimes rgri...@freebsd.org
Re: Discarding inbound ICMP REDIRECT by default
> On Wed, 12 Jun 2024 at 18:05, Chris wrote: > > > > As Rodeney already effectively explains; dropping packets makes routing, > > and discovery exceedingly difficult. Which is NOT what the average user > > wants, > > This is on end hosts only, not routers (which already drop ICMP REDIRECT). Probably a mistake, see other email. > > or expects. I use "set block-policy drop" in pf(4). But as already noted, > > this is for "filtering" purposes. Your suggestion also has the negative > > affect > > of hanging remote ports. Which can result in other negative results by > > peers. > > I don't follow -- how does a host not processing ICMP REDIRECT cause > these effects? I am not sure that it would "hang" the port, but by ignoring the rediect your going to place additional burden on the router that is trying to redirect you as all packets would have to be forwarded by that router. I suppose it could hang you if infact the router sent the redirect but did not forward the packet for you expecting that a retransmission with your updated routing table due to the redirect would get the flow going. -- Rod Grimes rgri...@freebsd.org
Re: Discarding inbound ICMP REDIRECT by default
On Wed, 12 Jun 2024 at 18:05, Chris wrote: > > As Rodeney already effectively explains; dropping packets makes routing, > and discovery exceedingly difficult. Which is NOT what the average user > wants, This is on end hosts only, not routers (which already drop ICMP REDIRECT). > or expects. I use "set block-policy drop" in pf(4). But as already noted, > this is for "filtering" purposes. Your suggestion also has the negative > affect > of hanging remote ports. Which can result in other negative results by peers. I don't follow -- how does a host not processing ICMP REDIRECT cause these effects?
Re: Discarding inbound ICMP REDIRECT by default
> > > Discarding ICMP redirects on a internet host is non-conformant with > > > STD-3 via rfc-1122. Processing of ICMP rediects is a MUST for hosts. > > > > In that case our default of "auto" is non-conformant if you have a > > routing daemon. > > NO, because then your not subject to rfc-1122 as your now a router, > not a host. I would argue that having IP forwarding enabled (i.e. net.inet.ip.forwarding for IPv4) is what establishes FreeBSD as a router, and ICMP REDIRECT messages are already dropped in kernel in that case.
Re: Discarding inbound ICMP REDIRECT by default
On 2024-06-13 06:34, Rodney W. Grimes wrote: On 2024-06-12 15:05, Chris wrote: > On 2024-06-12 14:47, Rodney W. Grimes wrote: >>> I propose that we start dropping inbound ICMP REDIRECTs by default, by >>> setting the net.inet.icmp.drop_redirect sysctl to 1 by default (and >>> changing the associated rc.conf machinery). I've opened a Phabricator >>> review at https://reviews.freebsd.org/D45102. >> >> I propse that we NOT do this. If you need this to protect your end >> node your probably doing something really unsafe network wise. The >> place that ICMP REDIRECTS should be dropped, and is most places, is >> at access routers and firewalls. >> >> Any one that needs this change to protect there network has larger >> issues than an ICMP REDIECT causing some issues. >> >> ICMP redirectr are very usefull for not having to run routing >> protocols on all your end nodes and allowing your edge/access >> routers tell your internal hosts via redirects how to get to >> places more efficiently. >> >>> >>> ICMP REDIRECTs served a useful purpose in earlier networks, but on >> They still serve this very usefull purpose. >> >>> balance are more likely to represent a security issue today than to >>> provide a routing benefit. With the change in review it is of course >>> still possible to enable them if desired for a given installation. >>> This change would appear in FreeBSD 15.0 and would not be MFC'd. >>> >>> One question raised in the review is about switching the default to >>> YES but keeping the special handling for "auto" (dropping ICMP >>> REDIRECT if a routing daemon is in use, honouring them if not). I >>> don't think this is particularly valuable given that auto was >>> introduced to override the default NO when necessary; there's no need >>> for it with the default being YES. That functionality could be >>> maintained if there is a compelling use case, though. >> >> The policy that is there now is exactly how things should be configured >> for a host in a network protected by a proper router w/firewall. >> The existing "auto" does exactly the right thing. >> >>> >>> If you have any questions or feedback please follow up here or in the >>> review. > As Rodeney already effectively explains; dropping packets makes routing, > and discovery exceedingly difficult. Which is NOT what the average user > wants, > or expects. I use "set block-policy drop" in pf(4). But as already noted, > this is for "filtering" purposes. Your suggestion also has the negative > affect > of hanging remote ports. Which can result in other negative results by > peers. > > Please don't. :) >>> >>> > --Chris OK, now having actually read the (phab) review. I'm of the opposite opinion. Your review seems to make the right decision. :) You do get that the final effect of the change is that by default ALL freeBSD boxes well be dropping ICMP REDIRECTS, both routers and end nodes. I know first hand that this change WOULD break my network(s) in locations that have more than 1 router as all of the interior hosts simply depend on an ICMP redirect to get them using the optimal router after they wrongly use the default router for a packet. A quick check on Ubunty 22.04 and Debian 12 indicate these are stlll accepted by default on those systems. Again, this is gona be one of those "bite someone in the ass" and your actually not providing any real security to anyone by making this change. If this is such a security issue, how come FREEFALL.freebsd.org still has: net.inet.icmp.drop_redirect: 0 Because it does not need to do that, because it is properly protected by routers and firewalls that do the dropping for them. DOG food Dog FOOD DOG FOOD!!! Firstly, please accept my apology for incorrectly spelling your name. :/ Secondly, my "reversal" of opinion on the matter was based upon my assumption on what would be returned by "auto". Closer examination, and reviewing your reply here, I think you're right, as was my original response. Accepting the new changes, as you say; will bite me in the ass -- well, will make my job (and others) more challenging. While I can appreciate the intent to keep users from getting "spoofed" packets that lead them into trouble. I think this is more a matter of responsible (network) administration. Maybe a better solution could be sent from rc(8) if FreeBSD thinks you've made the wrong decision here? Because the proposed change(s) look to me to only make routing and discovery more problematic. Thanks for commenting, (and correcting me) Rodney. :) --Chris
