[47526] in North American Network Operators' Group
Re: unicast RPF for peers viable?
daemon@ATHENA.MIT.EDU (Stephen Griffin)
Sun May 5 20:19:43 2002
Message-Id: <200205060018.UAA19280@elektra.ultra.net>
In-Reply-To: <20020505115827.B38784-100000@sequoia.muada.com> from Iljitsch van Beijnum at "May 5, 2002 12:10:36 pm"
To: iljitsch@muada.com (Iljitsch van Beijnum)
Date: Sun, 5 May 2002 20:18:57 -0400 (EDT)
From: Stephen Griffin <stephen.griffin@rcn.com>
Cc: nanog@merit.edu
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Errors-To: owner-nanog-outgoing@merit.edu
In the referenced message, Iljitsch van Beijnum said:
> So what is the collective wisdom on the NANOG list? Is uRPF on peering
> interfaces a viable option and if it breaks esoteric customer
> configurations, too bad; or is it something that should be discouraged
> because it breaks legitimate customer needs?
I believe that every little bit helps. If some amount of collateral
damage for odd configs is too much for you, you can still do
the below. This should only break the most egregiously broken
setups (sources in space which is entirely unreachable.)
The most permissive configuration:
loose-check RPF (allow if any path available)
combined with:
interface acls (in and outbound)
deny src or dst in rfc1918
deny src or dst in class e
!supposedly, some mcast apps set both src and dst to group
!so permit
permit src _and_ dst in class d
!nothing else should have source in class d
deny src in class d
the interface acls aren't needed assuming you have no active routes
for RFC1918, class d, or class e. IMHO, they are still a good idea
anyways, esp. on _outbound_ to reduce crap sent to others.
As with all things, every little bit helps. Filter what you can, contribute
to the overall improvement of the net. Become a White Hat respected by all,
or do nothing and become a Black Hat reviled by millions of small children.
