disabling ip directed broadcast and proxy arp on campus routers
Chris van den Berg
Disabling of ip directed broadcast on campus routers
On Tuesday 24th of March, CNS will disable ip directed broadcast on campus
backbone routers, inr-100 and and inr-101. This is the first step in
disabling directed broadcast on all campus routers. Directed broadcast is
a method by which a packet is sent to an entire physical network of hosts.
The purpose of disabling directed broadcast is to prevent Berkeley's being
used as a mounting point for a "smurf" attack. Smurf attacks have been
used to flood a network with traffic (usually via ICMP echo requests, i.e.
"ping", sent to a network broadcast address). For more information on
smurf attacks, please see:
http://www.cert.org/pub/advisories/CA-98.01.smurf.html
or
ftp://ftp.cert.org/pub/cert_advisories/CA-98.01.smurf
Please note that these measures are intended to prevent the Berkeley campus
network from being used as a mounting point for smurf attacks. However, due
to the nature of smurf attacks, there is currently no effective means of
protecting campus hosts which may be the targets of externally initiated
smurf attacks.
CNS will attempt to stay alert to any problems that may be caused by the
disabling of ip directed broadcast. Very few IP applications require directed
broadcasts.
The affected subnets once directed ip broadcast is no longer enabled on
inr-100 and inr-101 are listed at the bottom of this message.
Disabling of proxy arp on campus routers
CNS will also be disabling proxy ARP on these routers, with the intention
to eventually disable proxy ARP on all campus routers. Disabling proxy ARP
should not affect properly functioning systems, however machines which are
misconfigured may see interruption in network connectivity until properly
configured. Proper configuration may include checking the Default Gateway,
Subnet Mask, and Broadcast Address.
Proxy ARP (Address Resolution Protocol) is the technique by which a machine
(in this case a router), answers ARP requests intended for another by supplying
its own physical address. By acting as a surrogate, this machine forwards
packets in lieu of the real intended gateway.
Although allowing proxy ARP lets some misconfigured hosts function, it also
tends to mask underlying network problems, and can make troubleshooting and
resolution more difficult than without proxy ARP.
List of affected subnets:
128.32.105
128.32.111
128.32.12
128.32.123
128.32.125
128.32.126
128.32.135
128.32.136
128.32.14
128.32.140
128.32.141
128.32.142
128.32.143
128.32.146
128.32.148
128.32.149
128.32.152
128.32.155
128.32.158
128.32.165
128.32.167
128.32.17
128.32.183
128.32.184
128.32.185
128.32.186
128.32.193
128.32.195
128.32.196
128.32.20
128.32.203
128.32.206
128.32.210
128.32.211
128.32.212
128.32.213
128.32.218
128.32.221
128.32.223
128.32.229
128.32.230
128.32.235
128.32.235
128.32.242
128.32.245
128.32.248
128.32.25
128.32.252
128.32.4
128.32.58
128.32.59
128.32.64
128.32.65
128.32.66
128.32.67
128.32.68
128.32.69
128.32.70
128.32.71
128.32.72
128.32.73
128.32.74
128.32.75
128.32.81
128.32.82
128.32.83
128.32.84
128.32.91
128.32.92
128.32.94
128.32.97
136.152.64
169.229.1
169.229.2
169.229.230
169.229.37
169.229.38
169.229.38
208.1.66
Chris van den Berg
Programmer/Analyst
Communication and Network Services
(510)643-9837 chri...@ack.berkeley.edu
Key fingerprint = 8B 52 10 58 96 40 E8 9A EA 4B E9 27 F2 29 1A A8
Sobald wir an die Moral glauben, verurteilen wir das Dasein.
-Friedrich Nietzsche
Michael Sinatra
Regarding proxy arp:
I occasionally see machines that incorrectly have their mask set to a class
B net (255.255.0.0). When they get on the network, they try to send arp
requests for, say, ns1, even though ns1 is not on the subnet. The router
sends an arp reply with the router interface's ethernet address. I assume
this is the proxy arp you are talking about. If so, there may be more
misconfigured machines out there than we think...(not that you shouldn't go
ahead and do it :)
Chris van den Berg
Michael,
That's certainly a consideration, and is part of the reason the message
was sent to ucb.sysadmin and not just u.n.a (in the hopes that campus
admin.'s will know about the changes). Another possibility we're
anticipating is hosts which are configured with the wrong default
gateway. E.g., a host on the 128.32.57.128/25 net has a default gateway
which points at 128.32.57.1 instead of 128.32.57.129 (since before OSPF
and Variable Length Subnet Masks .1 was almost always the default
gateway for any network and someone configuring a machine may have
forgotten they're on a /25 net). Without proxy ARP, it may appear that
this machine has suddenly "lost" off-subnet network connectivity,
since the router no longer performs proxy ARP, and won't "pretend" it's
the place to send things to.
The real issue is that proxy ARP hides misconfigurations, which can be
a useful crutch, but those misconfigurations can crop up under certain
circumstances (e.g. network topology changes) and make it seem like some
change has "caused" problems, when if fact the problem lays in machines
that are misconfigured.
At any rate, we're anticipating trouble tickets related to disabling
proxy arp from machines that aren't set up right.
Thanks,
Chris
--
Partha S. Banerjee
In article <3512C832...@ack.berkeley.edu>,
Chris van den Berg <chri...@ack.berkeley.edu> wrote:
>Michael,
>
>At any rate, we're anticipating trouble tickets related to disabling
>proxy arp from machines that aren't set up right.
>
people are using? or is there no real contact database for the machines?
it is pretty simple to convert the ping program into one that
sends icmp maskreqests and listens for the right icmp reply.
i'll see if i can dig up by source code. can only find a solaris bin
of by getnm program.
i guess this is one of those cases where no one really has the time
to do something like that.
looking around the net at lbl, it is amazing how long some people mange to
function quite happily with some odd netmasks [fffcfc00?].
a few months back we saw some traffic coming into LBL from a .mil site
that on further examination contained "willing to manage" ... eventually
vern and i figured out some microsoft thing started these massive broadcasts
that was finally replied to by an XDMP in .mil land somewhere.
--psb
p.s. the 128.32.43 has everything correct that replied to icmp maskreq
correct.
--
/*\*/*\*/*\*/*\*/*\*/*\*/*\*/*\*/*\*/*\*/*\*/*\*/*\*/*\*/*\*/*\*/*\*/*\*/*\*/*\
|* Partha S. Banerjee Sic volo, Sic jubeo; *|
|* <p...@ieee.EECS.Berkeley.EDU> Stat pro ratione voluntas *|
\*/*\*/*\*/*\*/*\*/*\*/*\*/*\*/*\*/*\*/*\*/*\*/*\*/*\*/*\*/*\*/*\*/*\*/*\*/*\*/
ken lindahl
In article <6eute4$shk$1...@agate.berkeley.edu>,
Partha S. Banerjee <p...@ucsee.EECS.Berkeley.EDU> wrote:
>can you just scan the subnets or a dump of the zone for what subnet mask
>people are using? or is there no real contact database for the machines?
there is no real contact database for campus machines. in many cases,
we are able to find someone who knows someone who may know the sysadmin
(who may or may not be able to fix the problem without assistance), but
the overhead is staggering.
>it is pretty simple to convert the ping program into one that
>sends icmp maskreqests and listens for the right icmp reply.
thanks. it's an interesting suggestion and certainly worthy of discussion
on the CNS side.
>i guess this is one of those cases where no one really has the time
>to do something like that.
that's certainly a major consideration.
>looking around the net at lbl, it is amazing how long some people mange to
>function quite happily with some odd netmasks [fffcfc00?].
proxy arp on the router hides a multitude of very ugly sins. but i must
admit, i don't know if it would help in the specific example you listed.
>p.s. the 128.32.43 has everything correct that replied to icmp maskreq
>correct.
thanks, that's encouraging. 'course, that's a CS net and we expect fewer
misconfigured hosts in CS than elsewhere on campus.
ken