[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

(please see inline)

On Fri, 26 Apr 2019, Matt Harris wrote:

> 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?  

Good point. The same goes for RIPE NCC, LACNIC, AFRINIC and APNIC...

> 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.  

There are various sources of public routing data. But yes, sharing 
more routing views will increase the capacity to look at cases...

An uninvolved innocent third party should be able to show it was 
uninvolved (either by pointing out to public routing data, or by providing 
their own routing views if needed...)

In any case, if there is reasonable doubt, a case should always be 

> 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.  

Yes, this needs to be in place in every RIR to maximize efectiveness.

The idea of a "pool of worldwide experts" was to allow any RIR to use 
people from the same (larger) pool.

> 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.  

Your comment in pretty much inline with some comments opposing version 1.0 
in RIPE. Hopefully version 2.0 will be published next week. And it's a bit 
more "extensive" regarding details... :-)


> Take care,
> Matt