ARIN-prop-266: BGP Hijacking is an ARIN Policy Violation [Archived]

Date: 19 March 2019

Proposal Originator: Carlos Friaças, Jordi Palet Martinez

Problem Statement:

This proposal aims to clarify that BGP hijacking is not accepted as normal practice within ARIN service region, primarily because it negates the core purpose of running a (Regional Internet) Registry. The proposal is not concerned with simple operational mistakes – it is intended to address deliberate BGP hijacking events.

BGP hijacking is not acceptable behavior. A “BGP Hijack” is defined by announcing a prefix to another network without the resource holder’s consent.

There must be consequences for hijacking for members or individuals/organizations that have a service agreement (either directly or indirectly) with ARIN. This proposal aims to clarify that an intentional hijack is indeed a policy violation.

a. Arguments Supporting the Proposal

BGP hijacking completely negates the purpose of a (Regional Internet) Registry.

This community needs to explicitly express that BGP hijacking violates ARIN policies.

If nothing changes in this field, the reputation of the ARIN service region will continue to be affected from a cybersecurity perspective due to BGP hijacking events.

b. Arguments Opposing the Proposal

Neither the ARIN community or ARIN itself are the “Routing Police”.

Mitigation/counter-argument: Nobody will try to dictate to anyone how their routing policy should be at any given moment. However, ARIN needs to be able to choose not to enter into (or maintain) a contractual relationship with people/companies that are performing BGP hijacks. There are already enough sources of historic and almost real-time routing data which function as a worldwide observatory. From these sources it is possible to accurately evaluate who is performing BGP Hijacks and harming (or trying to harm) third party networks by doing so. The external experts are mere evaluators, who can use available sets of routing data to determine whether BGP hijacking events have taken place, and whether were intentional.

Policy Statement:

Proposed Text 1.0 Introduction

BGP hijacks happen on an almost daily basis. Hijacks can be on a global scale (propagated to all networks) or restricted (only one or some networks). Through this document, the ARIN community clarifies that BGP hijacking is not an acceptable practice.

2.0 BGP Hijacking is a Policy Violation

A hijack is understood to be the announcement of routes through BGP to third parties without the consent of the resource holder. This is considered to be a violation of ARIN policy.

The location of the resource holder or hijacker in such cases is irrelevant. A hijack constitutes a policy violation even if both parties are located outside of the ARIN service region.

The announcement of unallocated address space to third parties is also considered a policy violation and is evaluated according to the same parameters.

3.0 Scope: Accidental vs. Deliberate

A distinction can be made between accidental or deliberate hijacks from available routing datasets, looking at parameters such as duration, recurrence, possible goals, and the size of hijacked blocks. Other parameters may also be considered in the future.

4.0 Lines of Action

ARIN is not able to monitor the occurrence of BGP hijacks or assess whether they are policy violations. It must therefore rely on external parties, both to report hijacks and determine whether they are deliberate.

Reports sent to ARIN need to include a minimum set of details, such as: “Networks Affected”, “Offender ASN”, “Hijacked Prefixes” and “Timespan” (this is not a definitive list and other details may also be required). The ARIN will provide a web-based form to facilitate these reports. ARIN will define a pool of worldwide experts who can assess whether reported BGP hijacks constitute policy violations. Experts from this pool will provide a judgement regarding each reported case, no later than four weeks from the moment the report was received.

5.0 Retroactivity

Only hijacking events that occur after this policy has been implemented are eligible to be considered.

6.0 Possible Objections

A report containing an expert judgement on the case will be sent to the suspected hijacker. This party will then have four weeks to object to any conclusions contained in the report. Any objections are then assessed and ruled as admissible/non-admissible by the experts, during a two-week review period. Following this, the report is finalized and published.

7.0 Appeals

Following the publication of the final expert’s report, the suspected hijacker has two weeks in which they can file an appeal. If an appeal is filed, an alternative set of experts will review this for a maximum of four weeks. The results of this review are final and cannot be further appealed.

8.0 Ratification

Once the report has been published, any policy violation will be ratified by ARIN Board of Trustees. Otherwise, the complaint/report will be archived. The ratification will be delayed in case of an appeal, until the second expert has been published their review.

Timetable for Implementation: Immediate, to be confirmed by ARIN

Anything Else:

b. Situation in other regions: The policy has already been submitted to RIPE and LACNIC, and we are working in order to submit ASAP to APNIC and AfriNIC.

NOTES: To be completed, following the discussion among the LACNIC co-authors and RIPE initial WG discussion:

1. Selection process of experts. Open process managed by ARIN, but the community nominates and choose them. Similar to ASO-AC/others?. No staff can be part of it, but staff provide assistance to the experts.

2. 3 experts per case and appeal. Same number across all the cases. Renew every 2 years. If a bigger number is needed, it must be odd. They should sign before starting each case a document that states they are impartial and not directly/indirectly related to the parties.

3. The form, public, to avoid duplicate reports and allow to complete data from other parties, not just from the claim initiator.

4. ARIN will review the report to ensure that sufficient data is provided before assigning to a set of experts.

5. Experts will review the data vs historical data.

6. Experts will exclude cases clearly accidental, but ARIN will tell also to the originator, so they avoid repeating it.

7. If it looks deliberate, write a report, or in the appeal phase confirm or not the previous report.

8. Neither ARIN or the initiator of the claim can appeal the expert’s decision.

9. Cases started when a new selection proccess is started, must be completed by the previous set. Only in justified cases, which must be reported to the community, experts may be replaced.

10. Should also the “direct” peers be responsible and at least get a “warning” ?