2.0 Resource Hijacking is a Policy Violation
3.0 Scope: Accidental vs. Deliberate
9.0 Report and Evidence Eligibility
10.0 Sources of Information for Experts: Examples
16.0 Holders of Legacy or Provider Independent Resources
17.0 Continued violations regarding Hijacking of Resources from the same party
BGP hijacks happen on an almost daily basis. Hijacks have different visibility characteristics. They can be on a global scale (propagated to all networks) or restricted (only one or some networks). Their impacts can also vary, and it is not only resource holders who are affected, but also networks (and end users) who receive illegitimate/hijacked routes and suffer the indirect consequences of this.
There are already initiatives and technologies such as MANRS and RPKI, which unfortunately are not enough to significantly reduce hijacks. While MANRS and RPKI are strongly encouraged, policy should address the lack of community rules about hijacking.
Through this document, the RIPE community clarifies that hijacking is not an acceptable practice.
The RIPE NCC is not a mere “virtual land registry,” due to the fact it also has a role in the distribution of resources and is a membership-based organisation with a charter to support a larger community of users. Any persistent hijack can be understood as undermining the RIPE NCC’s credibility as a registry, thus policy is needed as a form of industry self-regulation.
This policy does not try to address problems caused by operational errors or occasional hijacks, but instead tries to create a way for victims to report persistent intentional hijacks. By making more of these cases public and searchable, each Autonomous System will have additional information to inform its decisions about interconnection.
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.
A hijack of numbering resources or the announcement of unallocated or unassigned IP addressing space or Autonomous System Numbers to third parties are also considered a policy violation.
Only reports in which the suspected hijacker is subject to RIPE policies can be investigated.
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.
Accidental events usually emerge from situations where a hijacked prefix or ASN is very similar to other resources held by the source of the hijack.
The RIPE NCC is not able to monitor the occurrence of resource hijacks or assess whether they are policy violations. It must therefore rely on external parties, both to report hijacks and to 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”, “Why am I reporting this Hijack? (Holder or Receiving Party)”, “Hijacked Prefixes/ASNs” and “Timespan”. This is not a definitive list and other details may also be required.
The RIPE NCC will provide a web-based form (or equivalent alternatives) to submit reports. Information regarding the hijacked routes/ASNs reported will be made publicly available to limit the risk of duplicate reports being submitted.
The involved parties will be notified as soon as they are identified. This will allow them to provide any relevant information and mitigate the hijack, avoiding further damages and possibly false claims.
The RIPE NCC will define a pool of worldwide experts who can assess whether reported hijacks constitute policy violations. Experts from this pool will provide a judgement regarding each reported case, no later than six weeks from the moment the report was received. If this judgement report is not completed within six weeks, the case will be dismissed.
Direct upstream or transit providers of a suspected hijacker that facilitate a hijack through their networks should be notified about the publication of a judgement report. This is not to be considered a formal warning and a response is not required. However, the notification will ask if they can provide further information or identify anything odd. Nevertheless, if intentional cases are identified over successive occasions, they could be seen by the experts as an involved party.
The expert investigation could suggest other related organisations (such as multiple LIRs from a single business group), which may be considered by the RIPE NCC in the event of a future closure process. This possibility aims to prevent hijackers from continuing their activities from a simulated customer's network. The expert investigation could also identify relationships between LIRs/End Users within the same business groups.
If an alleged hijacker can demonstrate that their infrastructure was improperly manipulated by third parties (for example, compromised routers), then the hijack cannot be considered intentional.
An expert is an external party to the RIPE NCC, ideally with at least five years’ experience with (external) BGP from dealing with configurations related to peering and transit providers. Experts should be familiar with the common forms of interconnection agreements, both within and outside of the RIPE NCC service region.
The selection procedure for the pool of experts should be open and managed by the RIPE NCC, possibly in collaboration with other RIRs:
The procedure must incorporate at least the following elements:
Only hijacking events that occur after this policy has been implemented may be considered.
Only networks directly affected by a hijack may file a report.
A report can only be filed:
A report is not admissible if the person reporting it was not affected in any way by the hijack.
Evidence older than six months, counted from the time a report is submitted, cannot be considered or included in any expert report.
The following is only a reference, not an exhaustive list:
Cases involving Internet Exchange Points or transit providers with significant customer bases accused of hijacking should require a broader set of experts.
All non-private information disclosed by accused parties when objecting to a specific report should be included in the expert report (at least in an appendix).
Company registries (www.ebr.org and similar) can be useful in determining if different companies can be associated with the same actor.
Special care must be given to situations where a hijacked prefix is very similar to a prefix legitimately held by an accused party. In these cases, checking to see if the legitimate prefix was announced within the same time frame may shed some light on the case. However, if it was announced in parallel, it must not be proof of an intentional hijack.
BGP leaks are outside the scope of this policy. Any case strictly related to BGP leaks should be dismissed.
A report containing an expert judgement on the case will be sent to the suspected hijacker. This party will then have a maximum of four weeks to object to any conclusions included in the report. Any objections are then assessed and ruled as admissible/non-admissible by the experts, during a maximum two-week review period. Following this, the report is finalised and published.
Following publication of the final expert report, the suspected hijacker has a maximum of two weeks in which they can file an appeal. If an appeal is filed, an alternative set of experts (a minimum of three) will review the report for a maximum of four weeks. In order to maintain a ruling of “intentional hijack”, all experts involved in the review need to agree that this has occurred. The results of this review are final and cannot be further appealed.
Once the report has been published, any policy violation will need to be ratified by all experts involved in the case, following a two-week public consultation on the report. If ratification is not declared unanimously, the report will be archived. Ratification will be delayed in case of an appeal, until the second set of experts has published its review. Experts can refuse to ratify a report based on undisclosed information sources or input from the public consultation.
As soon as the policy implementation is completed, a transition period of six months will be established. This will allow organisations that announce unassigned address space or Autonomous System Numbers (due to operational errors or other non-malicious reasons) to receive only a warning.
Existing “Bogons” at the time of policy implementation should be treated as exclusions and cases where they are referenced should be dismissed before awarding a case to experts.
If an accused party is a Legacy Resource Holder (either with a direct or indirect relation to the RIPE NCC), the registration of their legacy resources will not be affected, as RIPE policies are not applicable to these resources. However, if a policy violation is ratified, what is described in section 17.0 will apply, in which case other RIPE NCC services such as reverse DNS or Resource Certification (RPKI) could be denied to the accused party.
Holders of Provider Independent resources that are sponsored by an LIR that is found have committed a deliberate hijack will not have their resources de-registered and will be able to find a new sponsoring LIR (provided they were not involved). In the same way, a sponsoring LIR is not responsible if its customer is found to have committed a hijack.
In instances where a resource holder has regularly and repeatedly hijacked network resources, not allocated or authorised for their use, procedures defined in “Closure of Members, Deregistration of Internet Resources and Legacy Internet Resources” (currently RIPE-716) may apply. This policy does not endorse the initiation of an LIR closure procedure on the basis of a single policy violation.