Re: Is it time to abandon bogon prefix filters?

[Mark Andrews <marka () isc org>]

In article <ABD7F391-84FE-4DC2-997F-04E0D6DE327E () multicasttech com> you write:
> On Aug 25, 2008, at 10:22 AM, Jared Mauch wrote:
>
> > On Thu, Aug 21, 2008 at 08:03:19PM -0400, Sean Donelan wrote:
> >
> >      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

While some people with some protocols have solutions to detect when
the communication path has been compromised.  Not all people with
all protocols have a solution to this problem.

There is no panecea to this problem, however *everyone* should do
their best to reduce the problem.

Any operator not implemting BCP 38 is potentially aiding and abetting
some criminal.

BCP 38 is over 10 years old.  There is no excuse for not having
equipment in place to handle the processing needs of BCP 38.

Mark

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