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