Re: Discarding inbound ICMP REDIRECT by default

2024-06-14 Thread Chris

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

2024-06-14 Thread Rodney W. Grimes
> 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

2024-06-14 Thread Ed Maste
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

2024-06-14 Thread Marek Zarychta

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

2024-06-14 Thread Rodney W. Grimes
> 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

2024-06-14 Thread Ed Maste
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

2024-06-14 Thread Ed Maste
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

2024-06-14 Thread Rodney W. Grimes
> > > > 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

2024-06-14 Thread Rodney W. Grimes
> 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

2024-06-14 Thread Ed Maste
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

2024-06-14 Thread Ed Maste
> > > 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

2024-06-14 Thread Chris

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



Re: Discarding inbound ICMP REDIRECT by default

2024-06-13 Thread Chris

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



Re: Discarding inbound ICMP REDIRECT by default

2024-06-13 Thread Chris

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



Re: Discarding inbound ICMP REDIRECT by default

2024-06-13 Thread Bakul Shah
On Jun 13, 2024, at 6:39 AM, 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.
>> 
>> ICMP REDIRECTs served a useful purpose in earlier networks, but on
>> 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.
>> 
>> If you have any questions or feedback please follow up here or in the review.
> 
> 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.

Back when we did a router startup, I carefully read significant portions
of rfc1122 + rfc1812 several times over. Rodney is 100% right here but
the larger issue is following relevant standards or RFCs. Anyone
contemplating such changes should become intimately familiar with these
two documents (+ any update RFCs). [Not to mention there should be tests
checking conformance]


Re: Discarding inbound ICMP REDIRECT by default

2024-06-13 Thread Chris

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



Re: Discarding inbound ICMP REDIRECT by default

2024-06-13 Thread Rodney W. Grimes
[ Charset UTF-8 unsupported, converting... ]
> On Thu, 13 Jun 2024 at 09:39, Rodney W. Grimes
>  wrote:
> >
> > 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.

-- 
Rod Grimes rgri...@freebsd.org



Re: Discarding inbound ICMP REDIRECT by default

2024-06-13 Thread Chris

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



Re: Discarding inbound ICMP REDIRECT by default

2024-06-13 Thread Chris

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



Re: Discarding inbound ICMP REDIRECT by default

2024-06-13 Thread Ed Maste
On Thu, 13 Jun 2024 at 09:39, Rodney W. Grimes
 wrote:
>
> 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.



Re: Discarding inbound ICMP REDIRECT by default

2024-06-13 Thread Rodney W. Grimes
> 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.
> 
> ICMP REDIRECTs served a useful purpose in earlier networks, but on
> 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.
> 
> If you have any questions or feedback please follow up here or in the review.

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.
 
-- 
Rod Grimes rgri...@freebsd.org



Re: Discarding inbound ICMP REDIRECT by default

2024-06-13 Thread Rodney W. Grimes
> 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!!!


-- 
Rod Grimes rgri...@freebsd.org



Re: Discarding inbound ICMP REDIRECT by default

2024-06-12 Thread Chris

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. :)

--Chris



Re: Discarding inbound ICMP REDIRECT by default

2024-06-12 Thread Chris

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



Re: Discarding inbound ICMP REDIRECT by default

2024-06-12 Thread Rodney W. Grimes
> 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.
> 
> 

-- 
Rod Grimes rgri...@freebsd.org



Re: Discarding inbound ICMP REDIRECT by default

2024-05-08 Thread Ed Maste
On Tue, 7 May 2024 at 14:35, Marek Zarychta
 wrote:
>
> But what about IPv6 ? We have "net.inet6.icmp6.rediraccept" knob which
> defaults to 1. Can ICMPv6 redirects be fixed along with the change
> proposed for the legacy IP protocol?

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.



Re: Discarding inbound ICMP REDIRECT by default

2024-05-07 Thread Marek Zarychta

W dniu 7.05.2024 o 20:12, Ed Maste pisze:

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.

ICMP REDIRECTs served a useful purpose in earlier networks, but on
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.

If you have any questions or feedback please follow up here or in the review.

Thank you for submitting your inquiry to the community. I spotted it on 
Phabricator yesterday. It looks to me like a long-awaited, positive change.


But what about IPv6 ? We have "net.inet6.icmp6.rediraccept" knob which 
defaults to 1. Can ICMPv6 redirects be fixed along with the change 
proposed for the legacy IP protocol?


--
Marek Zarychta




Discarding inbound ICMP REDIRECT by default

2024-05-07 Thread Ed Maste
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.

ICMP REDIRECTs served a useful purpose in earlier networks, but on
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.

If you have any questions or feedback please follow up here or in the review.