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

David Farmer farmer at umn.edu
Thu May 2 13:27:35 EDT 2019


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>
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> 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. <athompson at merlin.mb.ca>
>
> --
===============================================
David Farmer               Email:farmer 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/a4893414/attachment.htm>


More information about the ARIN-PPML mailing list