Is it time to abandon bogon prefix filters?

Mon Aug 25 14:28:40 UTC 2008

On Aug 25, 2008, at 10:22 AM, Jared Mauch wrote:

> 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?

My Bank (Bank of America) put in something to mitigate against this  
about 2 years ago (IIRC), so they
were clearly anticipating something like this. Not only do you have to  
verify that you are you, you
also have to verify that the bank is the bank.

Regards
Marshall

>
>
> 	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.
>