[c-nsp] DNS amplification

Jimmy Hess mysidia at gmail.com
Mon Mar 18 06:23:57 UTC 2013


On 3/17/13, Damian Menscher <damian at google.com> wrote:

> Once you know an ISP hasn't implemented BCP38, what'st the next step?
>  De-peering just reduces your own visibility into the problem.  What if

In general, a hard problem,  not directly solvable in any obvious way.
It's similar to the question of what's the next step, after you
identified a probable connectivity issue.   Detection does not always
grant you a way of preventing something.

Ultimately,  to improve matters with regards to BCP38, I believe you
have to secure cooperation; cooperation can sometimes be achieved
through persuasion (discussing/requesting/bargaining/begging),  or
coercing  (bribing, threatening, seeking intervention from sponsors,
regulators, other networks, or other authorities, public shaming).

The recommended next-step would be the ones with the least harmful
ramifications for all involved  and the network  that do have a chance
of being effective,  and more aggressive options reserved as possible
backup plans.


In some cases, extreme methods such as inserting offending network's
AS into the middle of the AS path of outgoing announcements, possibly,
so the spoofed source's upstream network omits reachability to the
prefix under attack....

or maintaining peering, but blackholing traffic from that peer, to the
local prefix under attack

> it's a transit provider, who can be legitimately expected to route for 0/0?

Restricted peering can reduce the impact of the problem; in other
words: maintain the peering, but strictly controlling the packets per
second and octets per second volumes; traffic going over the peer link
is sacrificed during attack,  to protect the target.
This may still be mutually beneficial for the peers.


If the peer is such a transit provider, the problem is indeed hard,
possibly not  able to be mitigated.


> Damian
-- 
-JH




More information about the NANOG mailing list