[22581] in North American Network Operators' Group
Re: source filtering
daemon@ATHENA.MIT.EDU (Alex Bligh)
Tue Jan 12 14:14:06 1999
From: Alex Bligh <amb@gxn.net>
To: Jared Mauch <jared@puck.nether.net>
Cc: Alex Bligh <amb@gxn.net>, nanog@merit.edu
In-reply-to: Your message of "Tue, 12 Jan 1999 13:06:47 EST."
<19990112130647.A16946@puck.nether.net>
Date: Tue, 12 Jan 1999 18:25:47 +0000
Jared,
jared@puck.nether.net said:
> This does not mean you can't filter on your fastether, ether, fddi,
> etc.. that goes to customer aggregation boxes,
(i.e. on the core router on ingress core). Yes, but (it would seem
in practice) not if your network access LAN is multihomed and non-trivial
in topology.
Also causes problems if you use FR or ATM as access concentrators
directly into the core (oh if only you could stick this command on
a multipoint cloud and CEF worked properly).
My point was if one shipped CPE routers out, the responsible ISP
can ship them with "no ip directed broadcast" PLUS "ip verify unicast
reverse-path" on the CPE LAN interface, and ensure customers are
neither third-party reflectors nor perpetrators. Then use CEF to
rate-limit ICMP at the borders (which nearly works but not quite) and
you've mitigated the customers-as-victims problem too.
Is UDP smurf much in evidence? (send a UDP packet to the broadcast address
on the echo server port and you'll either get ICMP port unreachables
back or UDP echos). The reason I ask is that edge ICMP rate
limiting won't help UDP.
--
Alex Bligh
GX Networks (formerly Xara Networks)
