NetBSD Problem Report #4785

Received: (qmail 13273 invoked from network); 6 Jan 1998 04:38:47 -0000
Message-Id: <199801060438.UAA04390@capsicum.wsrcc.com>
Date: Mon, 5 Jan 1998 20:38:04 -0800 (PST)
From: Wolfgang Rupprecht <wolfgang@wsrcc.com>
Reply-To: wolfgang@wsrcc.com
To: gnats-bugs@gnats.netbsd.org
Subject: net.inet.ip.directed-broadcast=0
X-Send-Pr-Version: 3.95

>Number:         4785
>Category:       kern
>Synopsis:       directed bcasts sysctl doesn't turn off icmp replies to bcast addr
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    kern-bug-people
>State:          closed
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Mon Jan 05 20:50:01 +0000 1998
>Closed-Date:    Sun Feb 25 17:43:50 +0000 2018
>Last-Modified:  Sun Feb 25 17:43:50 +0000 2018
>Originator:     Wolfgang Rupprecht
>Release:        NetBSD-current Jan 5, 1998
>Organization:
W S Rupprecht Computer Consulting, Fremont CA
>Environment:

System: NetBSD capsicum.wsrcc.com 1.3 NetBSD 1.3 (WSRCC) #0: Mon Jan 5 13:44:47 PST 1998 root@capsicum.wsrcc.com:/v/src/netbsd/src/sys/arch/i386/compile/WSRCC i386


>Description:

Following the recomendations in the CERT advisory has no effect on
pings to the broadcast address:

    Under NetBSD you can disable directed broadcast with this command,
    as root:

	# sysctl -w net.inet.ip.directed-broadcast=0


>How-To-Repeat:

	(possibly related: compile in and turn on ipfilt packet filtering)

	$ sysctl -w net.inet.ip.directed-broadcast=0
	$ ping 140.174.88.0
	PING ether.wsrcc.com (140.174.88.0): 56 data bytes
	64 bytes from 140.174.88.14: icmp_seq=0 ttl=255 time=0.924 ms
	64 bytes from 140.174.88.1: icmp_seq=0 DUP! ttl=255 time=1.754 ms
	64 bytes from 140.174.88.14: icmp_seq=1 ttl=255 time=1.650 ms
	$ ping 140.174.88.127
	PING broadcast.wsrcc.com (140.174.88.127): 56 data bytes
	64 bytes from 140.174.88.1: icmp_seq=0 ttl=255 time=0.686 ms
	64 bytes from 140.174.88.14: icmp_seq=0 DUP! ttl=255 time=1.890 ms
	64 bytes from 140.174.88.1: icmp_seq=1 ttl=255 time=1.016 ms
	64 bytes from 140.174.88.14: icmp_seq=1 DUP! ttl=255 time=3.375 ms

Both of the above machines are netbsd 1.3 boxes.  Neither
directed-broadcast=0, or directed-broadcast=1, nor pinging the
x.x.x.255 address has any effect.  Bcast pings are always honored.

>Fix:
	?
>Release-Note:
>Audit-Trail:

From: "Perry E. Metzger" <perry@piermont.com>
To: wolfgang@wsrcc.com
Cc: gnats-bugs@gnats.netbsd.org
Subject: Re: kern/4785: net.inet.ip.directed-broadcast=0 
Date: Tue, 06 Jan 1998 00:10:44 -0500

 Wolfgang Rupprecht writes:
 > >Synopsis:       directed bcasts sysctl doesn't turn off icmp replies to bcast addr

 But it *does* stop a NetBSD router from being used to forward directed
 subnet broadcasts, which is the point of setting that to zero.

 Perry

From: Jason Thorpe <thorpej@nas.nasa.gov>
To: gnats-bugs@netbsd.org
Cc: netbsd-bugs@netbsd.org
Subject: Re: kern/4785: directed bcasts sysctl doens't turn off icmp replies to bcast addr
Date: Tue, 06 Jan 1998 01:41:30 -0800

 Wolfgang Rupprecht notes that net.inet.ip.directed-broadcast=0 doesn't
 disable replies to icmp-to-broadcast.

 In short, it's not supposed to.

 That sysctl enables/disables the forwarding of IP-directed broadcasts.
 In other words, if your NetBSD machine is a router, and directed-broadcast
 is 0, IP-directed broadcasts will not be forwarded.

 The "smurf" CERT advisory actually says this, but not in a very clear
 way...

 NetBSD does not currently have a way to disable replies to icmp-to-broadcast.
 Such a thing could be implemented, but enabling it would break things
 such as router discovery.

 Jason R. Thorpe                                       thorpej@nas.nasa.gov
 NASA Ames Research Center                            Home: +1 408 866 1912
 NAS: M/S 258-6                                       Work: +1 650 604 0935
 Moffett Field, CA 94035                             Pager: +1 415 428 6939

From: Wolfgang Rupprecht <wolfgang@wsrcc.com>
To: perry@piermont.com
Cc: gnats-bugs@gnats.netbsd.org
Subject: Re: kern/4785: net.inet.ip.directed-broadcast=0 
Date: Tue, 6 Jan 1998 07:59:32 -0800 (PST)

 Perry E. Metzger writes:
 > Wolfgang Rupprecht writes:
 > > >Synopsis:       directed bcasts sysctl doesn't turn off icmp replies to bcast addr
 > 
 > But it *does* stop a NetBSD router from being used to forward directed
 > subnet broadcasts, which is the point of setting that to zero.

 Ok. I guess I misunderstood which aspect of directed-broadcasts this
 sysctl turned off.  It would still be nice to turn off smurf pings
 (directed broadcast pings) without incurring a per-packet overhead for
 non ICMP echo reply packets.

 Cable modems essentially put ~4096 total strangers on the same
 ethernet segment.  Any ethernet neighbor could request a smurf ping
 directed at any victim on the internet.  Right now my only choice is
 to filter bcast icmp echo requests via ipfilt.  This incurs a cpu-cost
 on every packet, not just icmp packets.

 -wolfgang

From: "Erik E. Fair" <fair@clock.org>
To: Jason Thorpe <thorpej@nas.nasa.gov>
Cc: gnats-bugs@netbsd.org, netbsd-bugs@netbsd.org
Subject: Re: kern/4785: directed bcasts sysctl doens't turn off icmp
 replies to bcast addr
Date: Tue, 6 Jan 1998 23:45:04 -0800

 RFC 1122 (host requirements, part 1), section 3.2.2, page 38:

 	An ICMP error message MUST NOT be sent as the result of
          receiving:

          *    an ICMP error message, or

          *    a datagram destined to an IP broadcast or IP multicast
               address, or

          *    a datagram sent as a link-layer broadcast, or

          *    a non-initial fragment, or

          *    a datagram whose source address does not define a single
               host -- e.g., a zero address, a loopback address, a
               broadcast address, a multicast address, or a Class E
               address.

          NOTE: THESE RESTRICTIONS TAKE PRECEDENCE OVER ANY REQUIREMENT
          ELSEWHERE IN THIS DOCUMENT FOR SENDING ICMP ERROR MESSAGES.

 Alas, ICMP Echo Reply is not included in the list of "ICMP error messages".
 However, later on in section 3.2.2.6:

 	3.2.2.6  Echo Request/Reply: RFC-792

             Every host MUST implement an ICMP Echo server function that
             receives Echo Requests and sends corresponding Echo Replies.
             A host SHOULD also implement an application-layer interface
             for sending an Echo Request and receiving an Echo Reply, for
             diagnostic purposes.

             An ICMP Echo Request destined to an IP broadcast or IP
             multicast address MAY be silently discarded.

             DISCUSSION:
                  This neutral provision results from a passionate debate
                  between those who feel that ICMP Echo to a broadcast
                  address provides a valuable diagnostic capability and
                  those who feel that misuse of this feature can too
                  easily create packet storms.

 I suggest that we make the NetBSD default be to silently discard ICMP ECHO
 messages that are broadcasts.

 	chapter & verse,

 	Erik <fair@clock.org>



From: Manuel Bouyer <bouyer@antioche.lip6.fr>
To: "Erik E. Fair" <fair@clock.org>
Cc: Jason Thorpe <thorpej@nas.nasa.gov>, gnats-bugs@NetBSD.ORG,
        netbsd-bugs@NetBSD.ORG
Subject: Re: kern/4785: directed bcasts sysctl doens't turn off icmp replies to bcast addr
Date: Wed, 7 Jan 1998 10:03:31 +0100

 On Jan 6, Erik E. Fair wrote
 > I suggest that we make the NetBSD default be to silently discard ICMP ECHO
 > messages that are broadcasts.
 > 

 I strongly dissagree. I use several time a week broadcast ping for diagnostic
 purpose (very usefull on a switched LAN, to detect which switch is down).
 This can be made tunable, but I really belive the default should
 be to honnor such messages. If it's off by default, noone will notice
 that util a problem occurs and then it's too late to easily turn it on.
 However, I agree that a router should not forward broadcast packets by default
 (but this should also be made tunable, I do have some examples where this
 is usefull).

 --
 Manuel Bouyer, LIP6, Universite Paris VI.           Manuel.Bouyer@lip6.fr
 --

From: "Perry E. Metzger" <perry@piermont.com>
To: "Erik E. Fair" <fair@clock.org>
Cc: Jason Thorpe <thorpej@nas.nasa.gov>, gnats-bugs@NetBSD.ORG,
        netbsd-bugs@NetBSD.ORG
Subject: Re: kern/4785: directed bcasts sysctl doens't turn off icmp replies to bcast addr 
Date: Wed, 07 Jan 1998 15:56:55 -0500

 "Erik E. Fair" writes:
 > I suggest that we make the NetBSD default be to silently discard ICMP ECHO
 > messages that are broadcasts.

 I actually dislike that -- it makes my life harder. It is also very
 easy to turn directed subnet broadcast forwarding off on all your
 routers -- trivial in fact.

 If anything, we should make not forwarding directed subnet broadcasts
 our default for our routing code...

From: Jason Thorpe <thorpej@nas.nasa.gov>
To: perry@piermont.com
Cc: "Erik E. Fair" <fair@clock.org>, gnats-bugs@netbsd.org,
        netbsd-bugs@netbsd.org
Subject: Re: kern/4785: directed bcasts sysctl doens't turn off icmp replies to bcast addr 
Date: Wed, 07 Jan 1998 12:57:27 -0800

 On Wed, 07 Jan 1998 15:56:55 -0500 
  "Perry E. Metzger" <perry@piermont.com> wrote:

  > If anything, we should make not forwarding directed subnet broadcasts
  > our default for our routing code...

 Um, doesn't net.inet.ip.directed-broadcase default to 0?

 Jason R. Thorpe                                       thorpej@nas.nasa.gov
 NASA Ames Research Center                            Home: +1 408 866 1912
 NAS: M/S 258-6                                       Work: +1 650 604 0935
 Moffett Field, CA 94035                             Pager: +1 415 428 6939
State-Changed-From-To: open->suspended 
State-Changed-By: thorpej 
State-Changed-When: Mon Jan 12 14:36:55 PST 1998 
State-Changed-Why:  
Described behavior not really a bug, but we'll keep the PR around as 
a reminder to think about ICMP and broadcast later. 
State-Changed-From-To: suspended->closed
State-Changed-By: maxv@NetBSD.org
State-Changed-When: Sun, 25 Feb 2018 17:43:50 +0000
State-Changed-Why:
Close this PR. There is no issue in the first place, broadcast pings
are not controlled by directed-broadcast.


>Unformatted:

NetBSD Home
NetBSD PR Database Search

(Contact us) $NetBSD: query-full-pr,v 1.39 2013/11/01 18:47:49 spz Exp $
$NetBSD: gnats_config.sh,v 1.9 2014/08/02 14:16:04 spz Exp $
Copyright © 1994-2007 The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.