[dns-operations] responding to spoofed ANY queries

Vernon Schryver vjs at rhyolite.com
Sun Jan 13 01:55:04 UTC 2013


> From: David Conrad <drc at virtualized.org>

> > The tool is too tempting and potentially effective for too many government
> > projects ranging from national hostilities to operations by law
> > enforcement against criminals to expect governments to entirely
> > support BCP38 or even allow its complete deployment.  This is like
> > the prospects for governments and politicians limiting their own spam.
>
> A possibility but I've not yet reached that level of cynicism. I
> suspect that when there is a sufficient demonstration of the effectiveness
> of source address spoofing against government or infrastructure targets,
> laws will suddenly appear that require ISPs to take steps to ensure
> the traffic they source has appropriate source addresses, just as laws
> appeared to allow lawful intercept of traffic.

Wouldn't spoofing against government or infrastructure targets invoke
the Patriot Act and other terrorism laws?  Would an ISP that hasn't
deployed the recommend, available and official standard measures to
prevent such attacks be an accomplice in a violation of the CFAA?

The laws mandating support for wiretaps are in the opposite direction,
because they mandate support for network abouse.

Laws requiring that all routers support one or more of the BCP 38
mechanisms sound rather late and redundant and wouldn't do much to
make ISPs turn them on, especially given the occassional perfectly
legitimate situation where simple ingress filtering is wrong.

More relevant than CALEA are anti-spam laws and the current noise about
Iran being the source of recent reflection attacks.  (Never mind whether
that noise true this time or is merely more lies and FUD from the usual
suspects and beltway bandits.)  Everyone with experience in the spam
realm knows how impotent the anti-spam laws have been.  Even if someday
one nation after all these years of broken promises really does outlaw
unsolicited bulk email, there will still be plenty of others that
won't.  Why doesn't the same dire problem affect laws against all forms
of network abuse including IP header forgery?

Then there is the enforcement problem.  Would you have DHS inspectors
checking compliance?  Would they spot check cages in data centers,
consumer access routers, and so on and so forth?  That sounds like a
bigger job airport security.  Would the inspectors be as competent,
trustworthy, and educated as TSA inspectors?

A common response reaction at this point is something about the civil
courts.  Why haven't the targets of the recent reflection attacks sued
anyone?  All authority servers that are not negligent should by now
be doing something, whether RRL in BIND or NSP or operators standing
by with axes.  Reflecting recursive servers have no excuse besides
desires to make money cheaply.  I suspect some of the ISPs of the
sources of the forged requests have been identified, but I've not heard
of any court cases against ISPs.  Besides the lack of action from the
victims, there are the lessons of spam history.  You won't find any
signs of the civil legal victories of AOL and Earthlink in charts of
spam volume.  Unless Spamford Wallace goes down on "electronic mail
fraud, intentional damage to a protected computer, and criminal
contempt," will he ever really retire?
https://en.wikipedia.org/wiki/Sanford_Wallace


> > IP source address forging is like spam.
>
> Not really.  Spam doesn't affect anything except email.  Source
> address spoofing can affect _anything_ on the Internet.

Even if we agreed that spam affects nothing but email (we don't), we
should learn the lessons of the spam war both in general and in the
effectiveness of laws on such problems.  That there would be fewer
interests trying to water down a BCP 38 law into equivalents of CAN-SPAM
is irrelevant, because most spam is and has been illegal since CAN-SPAM
was signed.

In the real world, the phrase covering laws against "cybercrime"
is "security theater."


Vernon Schryver    vjs at rhyolite.com



More information about the dns-operations mailing list