Hi,
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
org/network.
· 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.
Regards,
Carlos
ps: thanks for the questions, it was almost a template :-)
Keith
From: ARIN-PPML [mailto:[email protected]] On Behalf Of Andrew Bagrin
Sent: Friday, May 3, 2019 10:05 AM
To: Marilson Mapa <[email protected]>
Cc: [email protected]
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.
_______________________________________________
ARIN-PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List ([email protected]).
Unsubscribe or manage your mailing list subscription at:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contact [email protected] if you experience any issues.
