[arin-ppml] [EXT] Re: Open Petition for ARIN-prop-266: BGP Hijacking is an ARIN Policy Violation

Carlos Friaças cfriacas at fccn.pt
Fri May 3 17:10:00 EDT 2019


On Fri, 3 May 2019, Keith W. Hare wrote:

> Andrew,
> So far, I have seen lots of discussion of the issue but I have not seen a single concise coherent complete definition of the BGP hijacking problem that includes:
> ·         What technical mechanisms are used to create a BGP hijack

Cautiously choosing an address block with low probability that anyone will 
complain -- mostly used when the main idea is to flush toxic content to 
other networks.

If a specific org/network is targeted, then the above doesn't apply -- the 
main motive is disrupt or intercept communications to/from that 

> ·         How BGP hijacking is initiated

When an hijacker sees the window of opportunity.

> ·         Why BGP hijacking is possible

Because anyone can announce any prefix, sourcing it from any ASN.

> ·         The frequency of BGP hijacking instances

I was in a RIR training today (in my region). There was a slide that 
stated a number: 14.000, during 2017.

I don't personally believe all of them have been individually 
investigated and confirmed.

> ·         How long BGP hijacking instances last

It can vary a lot depending on the goals.
stat.ripe.net can be useful if anyone wants to look back at some cases. 
Please note that some or most cases were invisible to this platform.

> ·         The locations of BGP hijacking instances

Globally, accross the five RIR service regions. If someone has any data 
that can share...
Already in this thread i was pointed into a Google Sheet, but i think it 
didn't have a RIR column (i could be wrong).

> ·         How information about BGP hijacking instances can be gathered

This is one of the most interesting issues!
Today i also heard something about the volume of networks peering with 
stat.ripe.net: around 600.
Well, with more than 60.000 ASNs, this means less than 1% of ASNs are 
providing visibility into that specific system. That's probably something 
that could be improved!  

> Without a really clear definition of the problem, it is hard to evaluate the effectiveness of the proposed process.

Look, the proposed process is something that surely can be improved. The 
original text had a series of checks & balances, which we quickly 
understood as insufficient when some people started raising some concerns, 
and describing scenarios. I don't feel comfortable at all if someone is 
falsely/wrongly accused of having persistently and intentionally made an 
hijack. If there is any doubt, as i see it, a report should be dismissed.

> So far, it is not at all clear to me how the process described in 
> proposal 266 will have any effect on the problem, but that may be 
> because I do not fully understand the problem.

Trying to sum it up: RPKI is great, MANRS is great, BGPSEC will be great, 
but deployment is rather low and takes time. Something is needed at policy 
level, to make some people understand that using other people's 
numbering resources is not an acceptable business model.


ps: thanks for the questions, it was almost a template :-)

> Keith
> From: ARIN-PPML [mailto:arin-ppml-bounces at arin.net] On Behalf Of Andrew Bagrin
> Sent: Friday, May 3, 2019 10:05 AM
> To: Marilson Mapa <marilson.mapa at gmail.com>
> Cc: arin-ppml at arin.net
> Subject: Re: [arin-ppml] [EXT] Re: Open Petition for ARIN-prop-266: BGP Hijacking is an ARIN Policy Violation
> I'm curious why do people not want to let ARIN try to start getting involved to help resolve the issue of hijacking?
> Are you doing hijacking and don't want interference?
> Are you running a competitive service that you charge for?
> Does anyone believe there is a valid reason to hijack and advertise IP space that you do not own? (when the owner of that space does not want you to advertise it)
> Why would anyone be against ARIN having a process to help resolve these issues?  Sure we can question how effective it will be, but anything will be more effective than nothing, and by actually doing, failing and learning, ARIN will
> only improve and refine the process. We will all learn from this.

More information about the ARIN-PPML mailing list