nanog mailing list archives

Re: [c-nsp] DNS amplification


From: Jimmy Hess <mysidia () gmail com>
Date: Mon, 18 Mar 2013 01:23:57 -0500

On 3/17/13, Damian Menscher <damian () 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


Current thread: