Summary of Proposal

This proposal aims to clarify that resource 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 hijacking events.

BGP hijacking events.BGP hijacking is not acceptable behaviour. A "BGP hijack" is defined as by announcing a prefix to another network without the resource holder's consent. BGP hijacking is not considered acceptable behaviour and there holder’s consent.There must be  consequences for resource hijacking for those 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.

Resource hijacking (while not limited to the below) is commonly observed to have several objectives:

• Diverting law enforcement from the real origin of packets tied with illegal activities;
• Temporarily making use of address space without any maintenance cost associated (i.e. RIR membership);
• Impersonating third party networks and services;
• Eavesdropping on the traffic of third-party networks (i.e. man-in-the-middle attacks);
• Disrupting IP communications between two or more third party networks.

Policy Text

Contents

1.0  Introduction Link: #1-0-introduction

2.0 Resource Hijacking is a Policy Violation Link: #2-0-resource-hijacking-is-a-policy-violation

3.0 Scope: Accidental vs. Deliberate Link: #3-0-scope--accidental-vs--deliberate

4.0 Lines of Action Link: #4-0-lines-of-action

5.0 Expert: Definition Link: #5-0-expert--definition

6.0 Pool of Experts Link: #6-0-pool-of-experts

7.0 Procedure Link: #7-0-procedure

8.0 Retroactivity Link: #8-0-retroactivity

9.0 Report and Evidence Eligibility Link: #9-0-report-and-evidence-eligibility

10.0 Sources of Information for Experts: Examples Link: #10-0-sources-of-information-for-experts--examples

11.0 Guidelines for Experts Link: #11-0-guidelines-for-experts

12.0 Possible Objections Link: #12-0-possible-objections

13.0 Appeals Link: #13-0-appeals

14.0 Ratification Link: #14-0-ratification

15.0 Transition Period Link: #15-0-transition-period

16.0 Holders of Legacy or Provider Independent Resources Link: #16-0-holders-of-legacy-or-provider-independent-resources

17.0 Continued violations regarding Hijacking of Resources from the same party Link: #17-0-continued-violations-regarding-hijacking-of-resources-from-the-same-party

Policy Text

1.0 Introduction

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 BGP 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.

2.0 Resource 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.

A hijack of numbering resources or the announcement of unallocated or unassigned IP addressing space or Autonomous System Numbers to third parties are

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.

Only reports in which the suspected hijacker is subject to RIPE policies can be investigated.

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.

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.

4.0 Lines of Action

The RIPE NCC is not able to monitor the occurrence of resource BGP 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 “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 (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 BGP hijacks constitute policy violations. Experts from this pool will provide a judgement regarding each reported case, no later than six four 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.

5.0 Expert: Definition

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.

6.0 Pool of Experts

The selection procedure for the pool of experts should be open and managed by the RIPE NCC, possibly in collaboration with other RIRs:

1. Every two years, a call for applications to the expert panel will be made to the global community, noting the experience and knowledge required. Additional calls will be made the pool needs to be expanded.
2. To join the pool of experts, a candidate will need a statement support from three different networks (ASes) from three different economies within the RIPE NCC service region, which are within different LIR sponsorships.
3. The authors of this proposal and active RIPE WG Chairs are not eligible to become experts. If an expert is selected as RIPE WG Chair, they will need to step down from expert duties, after completing their participation in any ongoing cases.
4. To avoid discrimination between cases, the same number of experts must participate in each case, for both the initial phase and the appeal phase (if applicable). This number is intentionally undefined and should be decided when the process is implemented.
5. The minimum number of experts per case and phase will be three. If a larger number is necessary, it must be odd, and the community will be informed of the reasons for the change.
6. The experts for each case/phase will be chosen at random, to ensure a balanced sharing of cases.
7. The identity of the experts chosen for a particular case will be kept confidential to avoid bribery attempts or reprisal actions against them.
8. Before accepting a case, experts must sign a document that confirms their impartiality and states that they have no direct or indirect relationship with the involved parties.
9. Experts must sign a non-disclosure agreement with the RIPE NCC that covers any information provided by an accused party as part of their appeal.
10. Cases must be completed by the experts that were initially assigned to them, even if they are replaced in a selection process while a case is ongoing. If there is a justified cause, one expert (only) may be replaced by another; this must be communicated to the RIPE community.
11. Experts will be replaced if they are unresponsive to either their fellow experts on a case or the RIPE NCC. Experts will also be replaced if they fail to comply with the defined time frames in three separate cases.
12. A person can only serve as an expert for four consecutive years (two terms). They must then stand down for at least two years before they are eligible to apply for selection again.
13. RIPE NCC will need to provide legal insurance for all experts, exclusively covering investigations/cases where they were involved.
14. The assignment of cases to experts will follow a programmed process (a draw from a minimum number of experts currently handling no cases, or a minimum of cases).
15. New cases cannot be investigated until the pool of available experts is at least twice the minimum number that can be assigned to a single case.

7.0 Procedure

The procedure must incorporate at least the following elements:

1. The RIPE NCC will verify that a report contains sufficient information before assigning it to a group of experts. If this is not the case, the report will be dismissed.
2. If a report is accepted, the suspected hijacker will be notified and given an opportunity to respond, providing evidence as they see fit.
3. Experts assigned to a case will verify the reported information regarding historical BGP data and will review any evidence provided by the suspected hijacker.
4. The group of experts assigned to a case will publish a joint report with their conclusions.
5. The experts will dismiss any cases that are clearly accidental, though they must indicate this in their report. The RIPE NCC can share this report with the responsible party to avoid future reoccurrences.
6. For an event to be identified as an intentional hijack, there must be unanimity between all experts on the case.
7. Experts cannot add accused parties to a case.
8. A suspected hijacker must be given the opportunity to appeal a report. In this case, a different group of experts will review the case. Again, there must be unanimity between all experts or the case will be dismissed.
9. RIPE NCC staff (or staff from other RIRs) cannot be part of an expert group, though they may provide administrative assistance. This does not include contacting the people which originally filed a report to request more information or providing any non-public RIPE NCC membership information.
10. Neither the RIPE NCC nor the claimant(s) can appeal expert decisions.

Only hijacking events that occur after this policy has been implemented

may be considered.

9.0 Report and Evidence Eligibility

Only networks directly affected by a hijack may file a report.

A report can only be filed:

• If the victim is the legitimate holder of a hijacked IP address prefix or Autonomous System;
• If the victim has received a hijacked IP address prefix through BGP or a route with an AS-PATH that includes a hijacked Autonomous System.

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.

10.0 Sources of Information for Experts: Examples

The following is only a reference, not an exhaustive list:

• ripe.net and stat.ripe.net APIs
• net and bgpstream.com
• nlnog.net
• routeviews
• caida openBMP
• team-cymru.com/bogon-reference.html
• cidr report
  • potaroo.net/cgi-bin/as-report?as=<asn>
  • potaroo.net/cgi-bin/per-prefix?prefix=<prefix>
• he.net
• euro-ix.net/en/ixpdb/asns/
• ripe.net
• org

11.0 Guidelines for Experts

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 contained 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.

13.0 Appeals

7.0 Appeals

14.0 8.0 Ratification

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 the RIPE NCC Executive Board. Otherwise, the complaint/report will be archived. Ratification The 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.

15.0 Transition Period

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.

16.0 Holders of Legacy or Provider Independent Resources

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.

17.0 Continued violations regarding Hijacking of Resources from the same party

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 Link: /publications/docs/ripe-716/ ” (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.

Rationale

a. Arguments Supporting the Proposal

• Resource hijacking completely invalidates BGP hijacking completely negates the purpose of a Regional Internet Registry; (Regional Internet) Registry.
• This community needs to explicitly express that resource BGP hijacking violates RIPE policies; 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:
  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 resource BGP hijacks. There are already enough sources of historic and almost real-time routing data which function as a worldwide observatory. From these sources, sources it is possible to accurately evaluate who is performing resource hijacks 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 resource BGP hijacking events have taken place, and whether were intentional.

• A policy violation can be determined following a simple mistake done during BGP operation.
  
  Mitigation/counter-argument: Firstly, initiating a process relies on a report. Then the expert analysis will determine if BGP hijacking is a common action from the RIPE NCC member that the report was issued about, or if they only happen to have made an operational error. Data about the BGP protocol is massive, and if the experts do not find enough related evidence, then the report will be dismissed.

• This proposal places the RIPE NCC in a difficult legal territory.
  
  Mitigation/counter-argument: The RIPE NCC follows the rules/policies issued by the community. However, if a suspected hijacker issues a lawsuit against the RIPE NCC, legal insurance can be a possibility (even if there is an associated cost).

• A single innocent party wrongly accused is worse than one hundred resource hijackers stopped.
  
  Mitigation/counter-argument: While this is valid within almost all law jurisdictions, it does not prevent the existence of rules or laws. The proposal is simply trying to end a clear gap in the RIPE NCC’s region ruleset.

• Acknowledging more policy violations, will not improve global routing security. Tools such as RPKI, MANRS or other should still be used instead.
  
  Mitigation/counter-argument: The degree of RPKI or MANRS deployment is still very low, and this policy is needed to address this lack of deployment. The need for this policy should be reviewed in a few years when different stages of deployment are reached by RPKI, MANRS and other tools.

c. Alignment with other RIRs

Similar policy proposals are under discussion in LACNIC Link: https://politicas.lacnic.net/politicas/detail/id/LAC-2019-5?language=en and AFRINIC Link: https://www.afrinic.net/policy/proposals/provisions-for-resource-hijacking . 

RIRs:

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

Note: In order to provide additional information related to the proposal, details of an impact analysis carried out by the RIPE NCC are documented below. The projections presented in this analysis are based on existing data and should be viewed only as an indication of the possible impact that the policy might have if the proposal is accepted and implemented.

A. RIPE NCC's Understanding of the Proposal

A.1. General

It is the RIPE NCC’s understanding that this policy change will expand the scope of the RIPE NCC service portfolio with the introduction of a reporting, evaluation and arbitration process for the purpose of validating claims concerning “BGP Hijacks”.
The proposal uses the terms “Resource Hijacking” or “BGP Hijack” or “BGP Hijacking” or “hijacking” interchangeably. We will only use the term “hijacking” for the purpose of this document.

The following section A.2 contains analyses of the overall impact that this policy change might have to the RIR system. This will be followed in section A.3 by an analysis of the proposed steps of this new process.
The following sections will provide the regular analysis of the impact on the Registry and addressing system (section B), on RIPE NCC’s operations (section C), on legal activities (section D) and implementation details (section E)

A.2 Impact on the RIR system

In section 1.0 the proposal states:

“The RIPE NCC […] is a membership-based organisation with a charter to support a larger community of users”.

We would like to clarify that the objective of the RIPE NCC is defined in Article 3 of the RIPE NCC Articles of Association, according to which:

“The objective of the Association is to perform activities for the benefit of the Members, primarily activities that the Members need to organize as a group. This object can be sub-divided into the following activities:

• Registration Activities related to the role of the Association as Regional Internet Registry;
• Co-ordination Activities, including the support of the stable operation of the Internet;
• Administration Activities, including all regular reports and administrative support as well as all other general administrative tasks which cannot be attributed to a specific activity;

• New Activities, including all activities which are necessary to react to the rapidly changing world of the Internet; and to do all that is connected therewith or may be conducive thereto, all this in the widest sense of the word. Making profit is not an object of the Association.”

Based on this, the proposed policy would in general be within the scope of the RIPE NCC’s activities. However, several organisational and legal implications are to be considered, which will be outlined in this impact analysis.

If this policy change is accepted, it seems to add a routing regulator role to the RIPE NCC in addition to the established role as registry. Although the policy assigns this role to the RIPE community (via a pool of experts), for many observers from other stakeholder groups and even within the RIPE community and the association’s membership, the distinction between the two bodies and their respective roles with regards to creating policy and the implementation of such, including possible retributive actions, might be not clear.

Should this policy be accepted it will have a significant impact in the position of the RIPE NCC as steward of the Internet, in particular to the current established position that the RIPE NCC has no direct influence over Internet traffic flow. As part of its current services, the RIPE NCC publishes a number of data sources such as Internet Routing Registry (IRR) and the Resource Public Key Infrastructure (RPKI) that can assist network operators to make routing decisions. For this information, the RIPE NCC only acts as publisher. Although input is authenticated and validated against registry data, it is ultimately the responsibility of the data provider and not the publisher to ensure the information is correct.

Acceptance of this proposal will extend the role of the RIPE NCC from publisher to the executor of decisions taken by external experts. This new role will contain some adjudicate aspects, especially given that the proposed policy leaves it in the hands of the RIPE NCC to define any retributive actions.

It must also be understood that any consequences of this policy change, like the deregistration and revoking of resources, will only have a limited and delayed impact on routing security. This is different to a service like RPKI, which provides immediate protection against BGP hijacking. This proposed process could result in a penalty for the hijacker only after a report has been sent and evaluated (which could take several weeks).

It is the RIPE NCC’s understanding that this proposed policy aims to increase the self-regulation of the Internet registry system. A potential failure in this attempt to self-regulate could lead to external challenges to the self-regulating Internet registry system in general (e.g. if the pool of experts has problems to producing timely, consistent and justifiable reports).

A.3. The Process

The following sections explain the RIPE NCC’s understanding of the process based on the current version the policy proposal.

A.3.1. Reporting

Only persons directly affected by a suspected hijack can report to the RIPE NCC that another party has announced resources registered to or used by the reporter without their consent. The report has to contain information about the affected networks and resources, the Autonomous System Number (ASN) used for the suspected hijack and the timespan of the event. The relation of the reporting person to the impacted resources must also be provided. The RIPE NCC would act as an administrator, ensuring that the report is complete, abides to RIPE Policies and is sent by a legitimate person.

Reports can only be processed when the suspected hijacker is bound by RIPE Policies, specifically when the ASN used for the suspected hijack was assigned by the RIPE NCC.
If the report meets all these criteria, the RIPE NCC would notify the involved parties (affected resource holder and the suspected hijacker) and provide an opportunity to respond. Further, the RIPE NCC would also need to publish the information about the impacted routes/ASN before the reported event is evaluated and include information pertaining to the report’s validity (or lack thereof) to prevent the reporting of non-existent hijacks. It is not clear in the policy for what period the reports will be published.

The proposed policy provides no guidance on the period that the RIPE NCC has to analyse the report, nor does it specify the period that the involved parties have to respond. We anticipate difficulties in confirming the relationship between the reporting person and the affected resources, especially if these resources are registered via another RIR. Further, the proposal provides no guidance on the consequences that a potential reply from the suspected hijacker could have.

It is the RIPE NCC’s understanding that we would develop and adjust a reasonable timeframe for report analysis and the associated window for the involved parties to respond as we become more experienced with the process. The RIPE NCC is expected to forward valid and complete reports together with potential responses from the parties involved to an assigned group of people comprised from a pool of experts. The RIPE NCC would be responsible for administering this pool of experts. The RIPE NCC would not be responsible for evaluating the content of the reports. 

A.3.2. Pool of Experts

According to the proposed policy, the experts and the process for their selection would be defined by the RIPE NCC. There is no guidance about the specific body within the RIPE NCC, so it could be either the Executive Board, or the General Meeting, the RIPE NCC management or a newly created body.

The criteria for the experts are the following:

• They do not work for the RIPE NCC
• They are not active RIPE Working Group Chairs or the authors of this proposal
• They have at least five years of experience with external BGP
• They are familiar with common interconnect agreements between entities both inside and outside of the RIPE NCC service region.
• They have “Support from three different networks (ASNs) from three different economies, within the RIPE NCC service region, which are within different LIR sponsorships”.

It is the RIPE NCC’s understanding that the last requirement suggests support from three different ASN holders that are established in three different countries. These different ASN holders must be sponsored by different members that act as “sponsoring LIR”. It is the RIPE NCC’s understanding that this also includes ASN holders that have a direct membership with the RIPE NCC (and therefore don’t need a sponsoring LIR).

These criteria will limit the number of eligible candidates. People wanting to apply for the voluntarily role of an expert would have to provide an application with sufficient documentation to prove their eligibility. The RIPE NCC can’t forecast if it would receive a sufficient number of applications for the selection process.

The proposed policy explains that experts should be replaced if:

• They are unresponsive to the other experts that are evaluating the same case or to the RIPE NCC.
• They fail to comply with maximum defined periods in three different cases.

It is the RIPE NCC’s understanding that this refers to removal of the unresponsive experts from the expert’s pool and not to the replacement of an unresponsive expert with another expert in a particular case.

A.3.3. Report Evaluation

Before the evaluation can start, the selected experts must sign documents that confirm their lack of conflict of interest and a non-disclosure agreement regarding a report before they accept it. Accordingly, the RIPE NCC must prepare such (template) agreements for this purpose and ask the involved experts to sign them before they undertake a report. Only when the agreements are signed by all involved experts can the evaluation of the report begin.

Except for the lack of conflict of interest mentioned above, the policy doesn’t provide detailed guidance on which criteria the RIPE NCC would adhere to in order to select the expert per reported case. The RIPE NCC would assign experts based on their availability and the time period since the last evaluations by that expert.

It is the RIPE NCCs understanding that from this moment, the selected experts would evaluate whether a report concerns an intentional hijacking within six weeks.

If the evaluation is not completed within six weeks, the report will be dismissed. This may lead to a situation where not all reports are treated in the same way and that the experts discriminate or unfairly prioritise some reports. Also, it is not clear whether the dismissed report would remain publicly available and with what status.

The proposed policy defines that the minimum number of experts per report is three. The same number applies in case of an appeal. If a larger number is necessary, this should be an exception and the community would be informed of the reasons for the change.
The policy provides limited clarification on which cases would require more experts. It is also unclear when and how the community would be informed and who would inform the community (the experts or the RIPE NCC?).

The policy describes a couple of situations where the community needs to be involved. The RIPE NCC would need to set up a separate public mailing list for this purpose.

The proposed policy defines the confidentiality of the selected experts. Any communication/information exchange between the experts and those involved in a report (accused parties, involved upstream provider) should take place in an anonymously. The RIPE NCC would have to provide administrative support to facilitate this communication. Also, the selection of experts would be confidential so the addition or replacements of experts in a case should not reveal to the community the names of the experts.

The proposed policy provides several guidelines for the evaluation of a hijack report. The experts have to decide whether or not the reported activity was a deliberate hijack.
Besides measurable criteria such as duration, recurrence, size of block, similarity of hijacked block and legitimate block, the policy also mentions subjective criteria, such as intention/possible goals. We foresee that clear evidence of a deliberate hijack would only be clear in a limited number of events and the experts would often have to base their decision on predictions and assumptions.

If this evaluation is based on assumption instead of on facts, the evaluators may be vulnerable to claims of reputation damages. The RIPE NCC would therefore need to arrange for liability insurance for experts against claims from parties that have been damaged due to their evaluation.

According to the proposal, the experts are “unable to add accused parties to a case”. It is the RIPE NCCs understanding that the experts cannot expand their investigation to other suspected hijackers other than the ones stated in the report. 

The proposal requires that upstream providers of the suspected hijacker would be notified about the existence of the report. The notification would include a request to provide further information or to verify if they “identify anything odd”. A response is not mandatory. If the same upstream provider is involved in successive occasions, then they experts may consider them to be involved parties.

Additional clarification is needed on how this requirement could be fulfilled without conflicting with the previous requirement to not add accused parties to the case. Also, it is not clear what the consequences for such upstream providers would be.

Beside the criteria for experts to be familiar with common interconnect agreements between entities, the proposed policy also stipulates that the experts “identify relationships between LIRs/end users of the same business groups”.

The proposed policy provides no guidance about the criteria the experts would adhere to in order to identify such relationships (officially belonging in the same group with the same brand, having the same director or board, etc).

In any case, these criteria require the experts to have legal expertise and, in particular, expertise in contract law, corporate law and international private law. The experts must rely on facts and not assumptions to identify that such relationships exist or be vulnerable to claims for reputation damages.

The proposed policy also states that during the experts’ investigation, they may suggest that “other related organisations (such as multiple LIRs from a single business group)” be considered by the RIPE NCC in case of a future closure process. However, the RIPE NCC is not the one to assess whether hijacks are policy violations. Also, we could like to note that the term “multiple LIRs” refers to the same organisation and not to other related organisations.

A.3.4. Processing Decision

Once the experts have finished their evaluation, the report is sent to the suspected hijacker and they have four weeks to object to the report’s conclusions. The experts assigned to the case have a maximum of two weeks to review these objections.

The report would be published if no objection is received within four weeks or following an assessment of the objections.

The proposed policy provides no guidelines about what happens if the experts fail to finish their assessment within two weeks after an objection is received.

Only the suspected hijacker can file an appeal once the report is published. The appeal would be evaluated by a different group of experts and confirm the first report unanimously, or the case will be dismissed.

It is the RIPE NCC’s understanding that the second group of experts would need to confirm the outcome unanimously. If they disagree on the merits but they agree with the outcome, this is considered as a confirmation of the report.

The proposal states that once the evaluation is published, any policy violation would need to be ratified by all of the experts involved in the case following a two-week public consultation on the report.

The value of this ratification is not fully clear. Since the proposal establishes that hijacking is a policy violation, and the experts evaluate that a particular case is indeed intentional hijacking, the experts might divert from their original decision only in cases of input from the public consultation or new undisclosed information.

Once a policy violation is constituted and ratified, existing RIPE Policies and related RIPE NCC procedures would have to be applied. The RIPE Policy “IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region”, which defines that an LIR can be closed if it consistently violates the RIPE community's policies, as well the RIPE Document “Contractual Requirements for Provider Independent Resource Holders in the RIPE NCC Service Region”, which defines that independent resources are subject to RIPE Policies, are applicable here.

The proposal defines that repeatedly hijacking resource by the member justifies termination of the SSA. We understand that the RIPE NCC would only consider hijackings of resources that have been reported and evaluated as intentional hijackings and that this decision has been ratified.

The procedural document “Closure of Members, Deregistration of Internet Resources and Legacy Internet Resources” should be updated accordingly.

The policy doesn’t provide enough guidance for the RIPE NCC about the number of repeated violations that would activate the closure procedure, nor if the period between repeated policy violations would have any influence. Consequently, it would be up to the RIPE NCC to decide if the threshold to activate the closure procedure has been reached on a case-by-case basis. Such individual decisions could be a challenge for the impartiality of the RIPE NCC. It also gives the RIPE NCC a more active role regarding the consequences of a policy violation, exceeding the intended role as solely administrator of the process.

B. Impact of Policy on Registry and Addressing System

No impact is expected by this proposed policy on the registry and addressing system.

C.1  Impact of Policy on RIPE NCC Operations/Services

A significant increase of workload is expected if this policy change is implemented.

Firstly, to process received reports. It is difficult to estimate the actual number of reports that could be received. As an indication, the external page bgpstream.com listed around 400 events as “Possible Hijack” that involved ASNs assigned by the RIPE NCC for the last six months. This would result in up to two possible valid reports per day. The number of reports would likely be lower than this but there will be a considerable amount of time needed for every received report to be analysed to see if it meets all criteria, to identify and inform the involved parties, to publish information about the impacted routes/ASN and to forward all relevant information to the selected experts for evaluation.

Secondly, to maintain the pool of experts, to monitor the evaluation by the experts, to provide administrative assistance and to inform the community.

The pool of experts must be big enough to handle a realistic amount of possible reports in parallel. While the policy defines that new reports cannot be investigated until the pool of available experts is at least twice the minimum number that can be assigned to a single case, such situations should be avoided.

Additional work is expected if the de-registered blocks would remain announced and the termination of the membership would require further actions against the announcing party.

We anticipate extra efforts for outreach and training activities, as this policy change can lead to misunderstandings and misconceptions by different parties. As mentioned in section A.2, the new service and the perceived change of RIPE NCC’s authority and scope towards the Internet routing domain must be explained to all relevant stakeholders of the Internet governance ecosystem, such as RIPE NCC members, the RIPE community, governments, competent authorities and the general public. These extra activities would need to clarify the details and limitations of the process, the underlying Policy Development Process (PDP), the roles of the RIPE community, the pool of experts and the RIPE NCC and the differences between them.

We also anticipate a significant financial impact. The more reports we receive, the more experts would be needed and this would require additional staff members to fulfill the multiple administrative tasks required from the RIPE NCC. Also, the liability insurance for the experts would be a significant cost factor.

C.2 RIPE NCC Board’s input

The proposal fundamentally shifts the RIPE NCC's activities while exposing the association to unacceptable liability risks. The Executive Board has a fiduciary duty to the RIPE NCC; it is therefore unlikely that it could allow the proposal to be implemented if it is accepted by the community in its current form.

D. Legal Impact of Policy

As mentioned in previous sections, multiple legal documents must be updated or newly drafted in order to implement the RIPE NCC’s policy-based process.

E. Implementation

With the information currently available, it is expected that the implementation of the proposal would take several months to prepare. Implementation work would involve software development, the creation of report forms, publishing mechanisms and mailing lists to facilitate the policy changes in internal RIPE NCC systems. Legal documents must be created or updated, often requiring at least the approval by the RIPE NCC Executive Board. Then an application and selection process for external experts must be created and initiated until a sufficient number of qualified experts is available. Multiple internal and external processes and documentation would also need to be updated or newly created.