Is it time to abandon bogon prefix filters?

Jared Mauch jared at puck.nether.net
Mon Aug 25 09:22:28 CDT 2008


On Thu, Aug 21, 2008 at 08:03:19PM -0400, Sean Donelan wrote:
> On Tue, 19 Aug 2008, Kevin Loch wrote:
>>> 	While you're at it, you also placed the reachable-via rx on
>>> all your customer interfaces.  If you're paranoid, start with the 'any'
>>> rpf and then move to the strict rpf.  The strict rpf also helps with
>>> routing loops.
>>
>> Be careful not to enable strict rpf on multihomed customers.  This includes
>> any bgp customer unless you know for sure they are single homed to you 
>> and that will not
>> change.
>
> Isn't it time to change the assumption that sending arbitrary source IP  
> addresses without checking is Ok?
>
> Unless the customer has specifically told their ISP about all the IP  
> addresses they intend to use as source IP addresses, shouldn't the 
> default be to drop those packets.
>
> If those multi-homed customers have not told their upstream ISPs about  
> additional source IP addresses (hopefully also registered/authorized for  
> use by the same customer) why can they still send packets with those  
> source addresses?  Instead shouldn't you say "Be careful if you are a  
> using source IP addresses without informing your upstream."
>
> In practice, how many multi-homed customers send packets with unannounced 
> source IP addresses?  And for those customers which do, why is the ISP  
> unable to implement any of the alternative source IP checking options,  
> such as using a ACL with uRPF or on the interface?

	I certainly believe that this is the trap people fall into.

	I can't manage it, nor do I want to spend the effort telling
my provider, peer, etc.. that I stole their customer from them, so
I'm better off making the global network less secure.

	With all the concern about DNS cache integrity, network abuse, etc..
networks that are not taking afirmative action to implement better policies,
systems are going to continue to lower their overall value.

	If you think I'm wrong, I do suggest you sit back and ignore your
network and customers further.  When they are unable to trust your network
to deliver the correct response to a dns query, they will ask for credits
and will leave.  If I were any sort of a bank, I would insist that my provider
take actions to prevent my customers from being redirected to a phishing
site.  The interesting thing is the effort put into dns patching, dnssec, etc..
could all be helped by the networks doing u-rpf.  Not 100% mitigated against, but
the difference would be huge.

	this is no longer a ddos issue of people spoofing packets.  That's 
gone, it's easier to take over a million desktops with malware than one
on a fe/ge.  But the ability to use those machines to brute-force or reconfigure
the resolver settings to someplace bad, that risk is truly tangible and
possibly severely disruptive to the industry.  If I can't trust that I am
reaching my bank, email, etc.. what impact will that have?

	If you've not factored these things into your business process,
hardware acquisition, I think you will end up with a bad situation.

	- Jared

-- 
Jared Mauch  | pgp key available via finger from jared at puck.nether.net
clue++;      | http://puck.nether.net/~jared/  My statements are only mine.




More information about the NANOG mailing list