unicast RPF for peers viable?

Mon May 6 00:18:57 UTC 2002

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.