Open Petition for ARIN-prop-266: BGP Hijacking is an ARIN Policy Violation (fwd)

Matt Harris matt at netfire.net
Fri Apr 26 18:22:35 UTC 2019


On Fri, Apr 26, 2019 at 12:49 PM William Herrin <bill at herrin.us> wrote:

> I personally support the petition. I think the out of scope reasoning is
> flawed. By enforcing minimum assignment sizes, ARIN has long acted as a
> gatekeeper to the routing system, controlling who can and can not
> participate. For better or worse, that puts the proposal in scope.
>
> I personally think it's for worse. I oppose the proposal itself. I'd just
> as soon ARIN not act as a gatekeeper to BGP and certain don't want to see
> it expand that role.
>

A couple of things spring to mind here now that I've given this a few more
minutes' thought.  I agree with your reasoning as to why it makes sense for
this to be considered in scope for ARIN.

As far as expanding roles goes... Over the past few decades, we've all
watched as the internet became less and less "wild wild west" and more and
more controlled (sometimes centrally, sometimes in a more or less
decentralized way) by various organizations and entities.   In various and
sundry ways, bad actors could get away with plenty of things in 1990 that
they cannot so easily today.  It may be the case that this problem will be
"solved" in some way by someone, but that "someone" may end up being a less
engaged community or a less democratic organization than ARIN is.
Ultimately, ARIN does a better job than some other internet governance
bodies of promoting stakeholder and community interaction and some degree
of democracy.  We have to consider the question: if some organization is
going to expand into this role, is it better that ARIN be the organization
to do so instead of one which may be ultimately less democratic and more
problematic?

One major problem with the proposal, having given it a couple of minutes
thought, that I can see as of now would be enforcement being dependent on
knowing whom the perpetrator is.  If I decide to announce to some other
networks some IP space owned by Carlos, but I prepend Bill's ASN to my
announcement, how does Carlos know that I'm the bad actor and not Bill?
Having good communication between network operators to determine where the
issue actually lies is critical.  Unfortunately, that doesn't always
happen.  When we talk about leveraging ARIN's authority or potentially
applying penalties of any sort to bad behavior, we have to be able to be
certain whom the bad actor is so that the penalties are not inappropriately
applied to an uninvolved or innocent third party.

Additionally, a question of scope does arise with regard to which resources
ARIN would be able to enforce any such policy with regard to.  Indeed, the
proposal as written currently calls for a "pool of worldwide experts"
despite being a proposal submitted to an RIR which is explicitly not
worldwide in scope.  For example, if a network with an ASN assigned by ARIN
is "hijacking" address space that is allocated by APNIC (or any other RIR)
to an entity outside of ARIN's region, would this be an issue for ARIN to
consider?  What if ARIN-registered address space is being "hijacked" by an
entity with a RIPE ASN and which is not located within ARIN territory?  I
suspect that for this proposal to have any meaningful enforcement
mechanisms, it would require inter-RIR cooperation on enforcement, and
that's a very large can of worms.  Not one that is impossible to overcome,
but likely one which will require several years of scrutiny, discussion,
and negotiation prior to any real world implementation.

Ultimately, I don't think I can support a proposal this vague, either.  For
something like this I think we need a lot more objective language and a lot
more specifics and details.  We must make policies easy to comply with, and
at all costs avoid vagueness which may allow for anything less than
completely fair and objective enforcement - regardless of how simple the
concept may seem to us on the outset.

Take care,
Matt
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20190426/3d39b2e1/attachment.html>


More information about the NANOG mailing list