[arin-ppml] prop266 - re-framing the discussion

Thu May 2 14:01:41 EDT 2019

Thanks, David.  I’d rather focus on what we CAN do or MIGHT be able to do, instead of focusing on the negative side of things.

So the carrot hasn’t worked, over the last 20yrs.  That’s fairly clear.  (Nor has it utterly failed, but its degree of success is noticeably less than perfect.)

Maybe it’s time to get out a (relatively gentle) stick:  No new IP address space for you, until you demonstrate that you have A) correctly/successfully added both IRR and RPKI ROAs for your existing allocations/assignments; and B) implemented BGP filtering, if not up to full MANRS, at least done *something* to prevent bogons, hijacks, etc.  (This could be as simple as “I maintain my prefix-lists by hand and apply them to every connection except my upstream(s)”.)

I don’t know how to solve the multiple chicken-and-egg problems embedded in what I just wrote, but something along those lines would be consistent with the … huh, can’t find it now, I thought there was some language in ARIN’s mandate or policy or something that included “fostering” the development of the Internet?

If the solution to the problem is to get Tier-1 & Tier-2 backbones to implement filtering, we can drag them along with us.  It’s not an overnight fix, but all the little pushes in the right direction add up.  It’s hard to bootstrap your way past a chicken-and-egg problem, and I believe it requires deployment of sticks, not carrots.

The obvious stick to use would be to put conditions-of-use on any and all number resources back in, but we just took out the RDNS provisions, I’m not sure there’s any appetite for adding anything new…?

Also – in this hypothetical world where everyone publishes IRR or RPKI data, ARIN gains a very effective stick: immediate masking of your ROA data.  Would require a well-thought-out enforcement policy, that would be horrible if deployed accidentally, but it would be a lot more effective than the, er, nearly-nothing ARIN has today.  I don’t love ARIN, in many ways, but it would seem to be self-consistent for an org that is being asked to police certain aspects of organizational behaviour, to enact policies giving itself the tools to do said policing.  OTOH, there’s a very good reason “Judge, Jury and Executioner” is an English idiom with negative connotations.

-Adam

Adam Thompson
Consultant, Infrastructure Services
[merlin-email-logo]
100 - 135 Innovation Drive
Winnipeg, MB, R3T 6A8
(204) 977-6824 or 1-800-430-6404 (MB only)
athompson at merlin.mb.ca<mailto:athompson at merlin.mb.ca>
www.merlin.mb.ca<http://www.merlin.mb.ca/>

From: David Farmer <farmer at umn.edu>
Sent: Thursday, May 2, 2019 12:28 PM
To: Scott Leibrand <scottleibrand at gmail.com>
Cc: Adam Thompson <athompson at merlin.mb.ca>; arin-ppml at arin.net
Subject: Re: [arin-ppml] prop266 - re-framing the discussion

Adam,

Thank you, for trying to reframe the discussion, I think this is a useful direction to try to move the discussion forward.

More below;

On Thu, May 2, 2019 at 10:16 AM Scott Leibrand <scottleibrand at gmail.com<mailto:scottleibrand at gmail.com>> wrote:
Do we have any evidence that 1) a significant fraction of BGP hijacking (announcement in BGP of address space registered by an RIR to another organization that has not authorized them to use it) is being performed by organizations that have other address space directly registered to them by an RIR?

Or 2) is nearly all hijacking being performed by entities that have no relationship with the RIR?

If 1) is true, then ARIN could theoretically revoke an organization’s registrations if they used address space that was not registered to them. We can of course debate whether we want RIRs to serve as adjudicators of what space RIR members are allowed to announce, but there would at least be something RIRs could do (kick non-cooperators out of the club of RIR registrants) to enforce their decisions if they decided to make them.

But if 1) is false and 2) is true, then it’s not clear what ARIN could do about a case of BGP hijacking by someone who doesn’t have any ARIN resources registered to them. Can you think of anything we’d actually want ARIN to do in that case?

Unfortunately, I believe 1) is false and 2) is true. I'm open to evidence of the contrary, but without such evidence, I'm very skeptical of any proposal for the RIRs, especially ARIN, to be able to do anything meaningful about the situation. Without an enforceable contract with the wrongdoers, I don't see what ARIN or the other RIRs can do about the situation.

ARIN’s only authority is to over their registry of who “has” which addresses, so the only thing I can imagine they could do would be to threaten to revoke unrelated registrations from a transit provider who willfully or negligently accepted the BGP announcement of space from an entity it wasn’t registered to. But if tier 1 transit providers aren’t willing to filter, let alone depeer, each other over hijacking today, it seems unlikely they’d be willing to stop accepting formerly legitimate prefixes from a peer or customer network just because ARIN is trying to take that space away to punish the network for accepting an unrelated hijacked announcement.

One fundamental problem with any proposal for ARIN or the other RIRs to do anything about these situations, who determines who is responsible for the hijacking event, and to what standard of evidence must the finding be made. The preponderance of the evidence or beyond a reasonable doubt? Further, I think everyone agrees that Intent matters in these situations, accidents, and misunderstandings happen and will continue to happen. Deregistering resources because of an accident or a misunderstanding seems an unjust punishment and an overaction that will not likely withstand legal scrutiny by the inevitable lawsuit.

The fundamental difference between ARIN, and the other RIRs, and an actual government is that governments have sovereign immunity or state immunity. This is the idea a government cannot be sued without the permission of the government itself and they are not subject to the courts of other countries. Without such immunity, the actions of ARIN and the other RIRs are subject to review by at least the courts of the countries they exist in, if not also by the courts of the country where an aggrieved party lives. Further, if one of the RIRs were to be found to have acted unjustly in one of these situations, the legal repercussions are likely to threaten their very existence.

Having the RIRs decide these situations seems like it risks the existence of the RIRs, the courts or law enforcement resolving these situations and making lawful orders to the RIRs seems like the only resolution of these situations that doesn't risk the existence of the RIRs.

Thanks.

Scott

On May 2, 2019, at 7:18 AM, Adam Thompson <athompson at merlin.mb.ca<mailto:athompson at merlin.mb.ca>> wrote:
Instead of focusing on whether the current proposal is or isn’t in scope, I suggest we re-cast the discussion as follows:

  1.  So far, we have unanimous community agreement that BGP hijacking is bad.
  2.  So far, we have broad agreement that “something ought to be done” about BGP hijacking, although detailed opinions vary significantly.
  3.  So what (else) can ARIN do about it?  (Caveat: the answer “nothing” is unacceptable to a significant proportion of PPML participants.)

My suggested direction to the AC and/or the board would therefore be:  Find something ARIN can do to help combat the problem (more effectively).  If this requires expanding the scope of ARIN’s operations or policies, bring that back to the membership (possibly via PPML?) with the accompanying financial & legal analysis, as usual.

Now the question becomes: what is the most appropriate mechanism, within ARIN’s existing policies, to bring a request like that to the AC and/or Board?  It seems clear to me that the petition already underway here is not meeting, and will not meet, the needs of the community very well.

-Adam

Adam Thompson
Consultant, Infrastructure Services
<image001.png>
100 - 135 Innovation Drive
Winnipeg, MB, R3T 6A8
(204) 977-6824 or 1-800-430-6404 (MB only)
athompson at merlin.<mailto:athompson at merlin.mb.ca>
--
===============================================
David Farmer               Email:farmer at umn.edu<mailto:Email%3Afarmer at umn.edu>
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SE        Phone: 612-626-0815
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===============================================
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20190502/484ce45c/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 2381 bytes
Desc: image001.png
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20190502/484ce45c/attachment.png>