Resource Hijacking is a RIPE Policy Violation

Summary of Proposal

This proposal aims to clarify that BGP hijacking is not accepted as normal practice within the RIPE NCC 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 behaviour. 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/organisations that have a service agreement (either directly or indirectly) with the RIPE NCC. This proposal aims to clarify that an intentional hijack is indeed a policy violation.

Policy 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 RIPE 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 RIPE 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 RIPE NCC 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

The RIPE NCC 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 the RIPE NCC 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 RIPE NCC will provide a web-based form to facilitate these reports.

The RIPE NCC 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 finalised and published.

7.0 Appeals

Following the publication of the final expert report, the suspected hijacker has two weeks in which they can file an appeal. If an appeal is filed, an alternative expert 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 the RIPE NCC Executive Board. 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.

Rationale

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 RIPE policies.
• If nothing changes in this field, the reputation of the RIPE NCC service region will continue to be affected from a cybersecurity perspective due to BGP hijacking events. 

b. Arguments Opposing the Proposal

• Neither the RIPE community or the RIPE NCC 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, the RIPE NCC 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.

c. Alignment with other RIRs:

It remains to be investigated if any of the other four RIRs consider BGP hijacking to be a policy violation.