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



[Bug 279550] tun interface get stuck and cannot be destroyed

2024-06-12 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279550

--- Comment #2 from Ivan  ---
Sorry for the sub reply, but I'm not getting any emails from bugzilla for some
reason.

It happened once, after some time the stuck interface self-destructed. It has
not reproduced again so far.

--- Comment #3 from Ivan  ---
Sorry for the sub reply, but I'm not getting any emails from bugzilla for some
reason.

It happened once, after some time the stuck interface self-destructed. It has
not reproduced again so far.

-- 
You are receiving this mail because:
You are the assignee for the bug.


[Bug 279550] tun interface get stuck and cannot be destroyed

2024-06-12 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279550

--- Comment #2 from Ivan  ---
Sorry for the sub reply, but I'm not getting any emails from bugzilla for some
reason.

It happened once, after some time the stuck interface self-destructed. It has
not reproduced again so far.

-- 
You are receiving this mail because:
You are the assignee for the bug.