LACNIC Staff's Interpretation of the Proposal
---------------------------------------------
Applicability
------------
This proposal would apply when a case of route hijacking is reported at operational level.
Modifications to the current text
---------------------------------
A new section would be created in the Policy Manual before the appendixes to incorporate the text of this proposal.
LACNIC Staff Comments
-----------------------
1. LACNIC understands that this proposal would mean acting on LACNIC members should they fail to comply with this policy. However, no action would be possible in the case of organizations that are not LACNIC members.
2. LACNIC stresses that it is very difficult to establish the intentionality of an unauthorized announcement, which is why they are managed with great care.
3. These type of situations are currently solved through the LACNIC WARP (Warning Advice and Report Point), which operates as a Computer Security Incident Response Team (CSIRT) (https://warp.lacnic.net/). LACNIC WARP already receives reports on this type of incidents and acts based on best practice standards used by other incident response teams.
In addition, for a few years now, LACNIC has been offering support (including training) to different organizations so that they can create their own CSIRTs and thus improve regional security incident management capabilities, particularly in this type of cases.
4. ome figures on the number unauthorized prefix announcement events reported to LACNIC WARP:
January-March 2019: Three reports were received, 100% of these cases were solved.
2018: Six reports were received, 100% of these cases were solved.
2017: Twelve reports were received, eleven of these were solved and only one failed to reply. This announcement was withdrawn.
Legal Implications
5. In this type of incident, there is no proof that a route has been hijacked. Instead, there are merely indications. On the other hand, before initiating a resource revocation process, reliable evidence that a hijack has actually occurred is required. Thus, actions taken based on indications and not on evidence might have serious consequences for LACNIC.
6. Such consequences might not only be legal but also operational. It is impossible to prove the intentionality of an unauthorized route announcement. Those involved could always claim that it was not a deliberate action but an unintended error.
7. False positives might occur which, if resources were revoked, would involve even greater legal and financial responsibility both for the set of experts involved and for LACNIC.
Recommendations
1. LACNIC agrees that route hijacking must be recognized as a security incident. However, the policy goes into details of the procedure that a Security Incident Response Team should follow. LACNIC currently implements actions for managing this type of incidents through LACNIC WARP, always based on best practices established by Security Incident Response Teams.
2. We recommend being careful to define the responsibilities of an RIR in terms of number resource management, not routing. It is important to be clear on where the boundaries are established.
3. In Section 4.0 Lines of Action:
3.1. LACNIC already offers an online form that can be used to report security incidents (https://warp.lacnic.net/reportar-incidente), as well as an email address (info-warp@lacnic.net) that can be used for the same purpose.
3.2. The online form includes a specific item for reporting “unauthorized prefix advertising.” In line with current best practices, an incident is not labeled as “route hijacking” until evidence is available to support the fact that it is a malicious action.
3.3.The information requested in the form is to be used by the incident response team and is based on best practice standards adopted by incident response centers for handling such cases.
4. In Section 6.0 Pool of Experts:
4.1. LACNIC has a Security Incident Management Team (WARP). BGP hijacking is included among the security incidents managed by LACNIC WARP. Likewise, as a coordination center, LACNIC WARP can determine whether it is necessary to scale each incident to other CSIRTs which, in turn, also use a global information exchange protocol and procedure.
4.2. A trusted global network of incident response centers already exists, and its members are working in a well-established manner.
4.3. It is not clear how LACNIC would assess the experience of global experts on the topic.
5. In section 7.0.
5.1. It is important to stress that one of the basic principles of an Incident Response Team is maintaining the confidentiality of the information for proper incident management.
5.2. Item 10. does not allow LACNIC to take any action, even if the organization believes it would be pertinent.
6. In Section 10.0 Possible Objections
6.1. The text “(...) This party will then have a maximum of four weeks to object to (...)” contradicts one of the basic principles of incident management: “The speed with which an organization can recognize, analyze, and respond to an incident will limit the damage and lower the cost of recovery.” Cert.org
6.2. Specifying that “the report will be finalized and published” might be interpreted as an accusation and result in a lawsuit.
7. In section 11.0 Appeals:
7.1. The proposed time frame is not in line with the severity of this type of incidents, as the impact of a delay can greatly affect Internet stability and security. For example, imagine if the proposed time frame had been used in the case of YouTube and Telecom Pakistan.
7.2. The proposal specifies “an alternative set of experts,” yet it is not clear who would be part of this additional group of experts. In addition, Section 5.2 states that “The same number of experts must participate in each case and phase,” so it is not clear whether this is the same group or another set of “alternative” experts.”
Official Sources
-----------------
Situation in the other RIRs
--------------------------
RIPE NCC
A similar proposal is under discussion:
https://www.ripe.net/participate/policies/proposals/2019-03
This proposal aims to clarify that BGP hijacking is not accepted as normal practice within LACNIC service region, primarily because it negates the core purpose of running a RIR.
The proposal is not concerned with simple operational mistakes – it is intended to address deliberate BGP hijacking events.
Rationale (Describe the problem you intend to solve)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 LACNIC. 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 RIR.
• This community needs to explicitly express that BGP hijacking violates LACNIC policies.
• If nothing changes in this field, the reputation of the LACNIC service region will continue to be affected from a cybersecurity perspective due to BGP hijacking events.
b. Arguments Opposing the Proposal
• Neither the LACNIC community or LACNIC 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, LACNIC 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.
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 LACNIC 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 (addresses or Autonomous System Numbers). This is considered to be a violation of LACNIC 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 LACNIC service region.
The announcement of unallocated address space or autonomous system numbers 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
LACNIC 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 LACNIC 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).
LACNIC will provide a public web-based form (or equivalent alternatives) to submit these reports, which will be made publicly available, so third parties can add information relevant to the case avoiding duplicated reports. The tool will have a section in case there is sensitive information that must not be published.
As soon as the involved parties are identified, they will be notified so they can provide relevant information and mitigate the hijack, avoiding further damages and possibly false claims.
The experts will only consider those cases which persist or have been reported six months since they ceased at the latest. In any case, LACNIC may send to the parties a notification with the reported information, which in any case will be filed as part of the history of the cases.
LACNIC will select 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.
The direct upstreams of the suspected hijacker, which facilitate the hijack through their networks, may receive a warning the first time. Nevertheless, in subsequent occasions the experts may consider them an involved party if intentional cases are repeated.
The experts’ investigation will be able to value the relationships between LIRs/end users of the same business groups.
Accidental cases or those that can’t be clearly classified as intentional will receive a warning, which may be considered if repeated.
Any cases in which the alleged hijacker can demonstrate that their infrastructure was improperly manipulated by third parties (for example, compromised routers) can not be considered intentional.
As a preventive measure, the resources of the investigated parties can not be transferred or modified until the case is ratified or dismissed.
5.0 Expert’s Pool
The selection procedure of the expert’s pool should be open and managed by LACNIC, possibly in collaboration with other RIRs.
1. A call will be made, every two years, to the global community including the requirements of experience and knowledge. Additional calls will be made if it is needed to expand the group of experts.
2. The same number of experts must participate in each case and phase (initial and appeal if any), to avoid discrimination between cases. It should be defined when implementing the process.
3. 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.
4. The expert’s must sign a document that confirms their impartiality and, therefore, that have no direct or indirect relationship with the involved parties, before accepting each case.
5. The cases in progress must be completed by the experts initially assigned, even if they are replaced in the biannual selection process. Only in case of justified cause and communicated to the community, one expert may be replaced by another.
6.0 Procedure
The procedure must incorporate, at least, the following steps:
1. LACNIC will verify that the report contains sufficient information before assigning it to the group of experts.
2. The assigned experts will verify the reported information regarding historical BGP data.
3. The experts will exclude those cases that are clearly accidental, although they must indicate this in their report, so that LACNIC transmits it to the suspected hijacker to avoid its repetition.
4. If the event seems deliberated, they will write a report with their conclusions, or with the confirmation or not of the same, if it is the appeal phase.
5. LACNIC staff can’t be part of the expert’s group, however they can provide assistance.
6. Neither LACNIC nor the claimant(s) can appeal the decision of the experts.
7.0 Retroactivity
Only hijacking events that occur after this policy has been implemented are eligible to be considered.
8.0 Possible Objections
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 contained in the report. Any objections are then assessed and ruled as admissible/non-admissible by the experts, during a maximum two-weeks review period. Following this, the report is finalized and published.
9.0 Appeals
Following the publication of the final expert’s 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 will review this for a maximum of four weeks. The results of this review are final and cannot be further appealed.
10.0 Ratification
Once the report has been published, any policy violation will be ratified by LACNIC Board. Otherwise, the complaint/report will be archived. The ratification will be delayed in case of an appeal, until the second expert’s group has published their review.
11.0 Transition Period
As soon as the policy implementation is completed, a transition period of 6 months will be established, so that organizations that announce not assigned address space or autonomous systems numbers, due to operational errors or other non-malicious reasons, receive only a warning.
New textProposed 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 LACNIC 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 (addresses or Autonomous System Numbers). This is considered to be a violation of LACNIC 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 LACNIC service region.
The announcement of unallocated address space or autonomous system numbers 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
LACNIC 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 LACNIC 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).
LACNIC will provide a public web-based form (or equivalent alternatives) to submit these reports, which will be made publicly available, so third parties can add information relevant to the case avoiding duplicated reports. The tool will have a section in case there is sensitive information that must not be published.
As soon as the involved parties are identified, they will be notified so they can provide relevant information and mitigate the hijack, avoiding further damages and possibly false claims.
The experts will only consider those cases which persist or have been reported six months since they ceased at the latest. In any case, LACNIC may send to the parties a notification with the reported information, which in any case will be filed as part of the history of the cases.
LACNIC will select 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.
The direct upstreams of the suspected hijacker, which facilitate the hijack through their networks, may receive a warning the first time. Nevertheless, in subsequent occasions the experts may consider them an involved party if intentional cases are repeated.
The experts’ investigation will be able to value the relationships between LIRs/end users of the same business groups.
Accidental cases or those that can’t be clearly classified as intentional will receive a warning, which may be considered if repeated.
Any cases in which the alleged hijacker can demonstrate that their infrastructure was improperly manipulated by third parties (for example, compromised routers) can not be considered intentional.
As a preventive measure, the resources of the investigated parties can not be transferred or modified until the case is ratified or dismissed.
5.0 Expert’s Pool
The selection procedure of the expert’s pool should be open and managed by LACNIC, possibly in collaboration with other RIRs.
1. A call will be made, every two years, to the global community including the requirements of experience and knowledge. Additional calls will be made if it is needed to expand the group of experts.
2. The same number of experts must participate in each case and phase (initial and appeal if any), to avoid discrimination between cases. It should be defined when implementing the process.
3. 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.
4. The expert’s must sign a document that confirms their impartiality and, therefore, that have no direct or indirect relationship with the involved parties, before accepting each case.
5. The cases in progress must be completed by the experts initially assigned, even if they are replaced in the biannual selection process. Only in case of justified cause and communicated to the community, one expert may be replaced by another.
6.0 Procedure
The procedure must incorporate, at least, the following steps:
1. LACNIC will verify that the report contains sufficient information before assigning it to the group of experts.
2. The assigned experts will verify the reported information regarding historical BGP data.
3. The experts will exclude those cases that are clearly accidental, although they must indicate this in their report, so that LACNIC transmits it to the suspected hijacker to avoid its repetition.
4. If the event seems deliberated, they will write a report with their conclusions, or with the confirmation or not of the same, if it is the appeal phase.
5. LACNIC staff can’t be part of the expert’s group, however they can provide assistance.
6. Neither LACNIC nor the claimant(s) can appeal the decision of the experts.
7.0 Retroactivity
Only hijacking events that occur after this policy has been implemented are eligible to be considered.
8.0 Possible Objections
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 contained in the report. Any objections are then assessed and ruled as admissible/non-admissible by the experts, during a maximum two-weeks review period. Following this, the report is finalized and published.
9.0 Appeals
Following the publication of the final expert’s 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 will review this for a maximum of four weeks. The results of this review are final and cannot be further appealed.
10.0 Ratification
Once the report has been published, any policy violation will be ratified by LACNIC Board. Otherwise, the complaint/report will be archived. The ratification will be delayed in case of an appeal, until the second expert’s group has published their review.
11.0 Transition Period
As soon as the policy implementation is completed, a transition period of 6 months will be established, so that organizations that announce not assigned address space or autonomous systems numbers, due to operational errors or other non-malicious reasons, receive only a warning.
Additional informationIt is considered that this proposal should constitute a new section of the policy manual, possibly before the appendices, but its exact position and form of numbering, given that they are editorial aspects, are left to the discretion of the LACNIC staff.
TimetableImmediate
ReferencesThe same proposal has already been submitted to RIPE:
• https://www.ripe.net/participate/policies/proposals/2019-03
We are already working in order to submit equivalent proposals to the other RIRs.
Presented at:-
This proposal aims to clarify that resource hijacking is a policy violation and therefore not accepted as normal practice within the LACNIC service region. In addition, these actions negate the core purpose of running a Regional Internet Registry.
The proposal is not concerned with simple operational mistakes – it is intended to address deliberate resource hijacking events.
Rationale (Describe the problem you intend to solve)A “hijack" is defined as announcing resources to another network, leasing them or selling them without the consent of the legitimate resource holder. Hijacks are not acceptable behavior, so there must be consequences for hijacking for those who have a service agreement with LACNIC. This proposal aims to clarify that an intentional hijack is indeed a policy violation.
Hijacks can have different visibility characteristics: they can be on a global scale (propagated to all networks) or restricted (only one or some networks). They not only impact the holders of the affected resources but also the networks (and end users) that receive illegitimate/hijacked routes and their consequences.
Initiatives and technologies such as MANRS and RPKI already exist but, unfortunately, they are not enough for a significant reduction of hijacks. While we strongly recommend using MANRS and RPKI, this policy is still necessary to address the lack of community rules on hijacking. Through this document, the LACNIC community clarifies that BGP hijacking is not an acceptable practice.
LACNIC is not merely a “virtual land registry”, as it also plays a role in the distribution of resources and, in fact, it is a membership-based organization with bylaws to support an even broader user community. Any persistent and/or repetitive hijack can be understood to be a way to affect the credibility of LACNIC as a registry; therefore, policies are needed as a form of self-regulation.
a. Arguments Supporting the Proposal
• BGP hijacking completely negates the purpose of a Regional Internet Registry.
• There is a gap in LACNIC's policies that allows supporting hijacking operations with a set of legitimate resources.
• The legitimate holders’ exclusive right to use their resources must be properly defended by the registry itself.
• Having an anti-hijacking policy in effect in the LACNIC region might prevent some actors from engaging in such practices.
• If nothing changes in this field, the reputation of the LACNIC service region will continue to be affected from a cybersecurity perspective due to resource hijacking events
b. Arguments Opposing the Proposal
• Neither the LACNIC community or LACNIC itself are the “Routing Police”.
o Counterargument: Nobody will try to dictate to anyone how their routing policy should be at any given moment. However, LACNIC needs to be able to choose not to enter into (or maintain) a contractual relationship with people/organizations that are performing resource 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 resource 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 hijacking events have taken place, and whether they were intentional.
• A simple BGP operation error might be considered a policy violation.
o Counterargument: First, this process is only initiated based on a report. Second, the experts’ analysis will determine whether BGP hijacking is a common action by the LACNIC member about whom the report was issued, or whether they have simply committed an operational error. There is massive data on the BGP protocol, and if the experts do not find enough relevant evidence, the report will be discarded.
• This proposal places LACNIC in difficult legal territory.
o Counterargument: LACNIC merely follows the rules (policies) created and approved by the community. Nevertheless, if a suspected hijacker were to file a lawsuit against LACNIC, legal insurance might be an option (even if it involves a cost).
• A single case of wrongful accusation that turns out to be innocent is worse than a hundred arrested resource hijackers.
o Counterargument: While this is true in practically every legal jurisdiction, it does not prevent the existence of rules or regulations. The proposal is simply trying to put an end to a clear gap in the rules of the region.
• Recognizing more policy violations will not improve global routing security. Instead, RPKI, MANRS or other tools should be used.
o Counterargument: The degree of implementation of RPKI or MANRS is still very low, and this policy is one more tool among many possibilities. The need for this policy and its performance should be reviewed in a few years (just as every other policy) once RPKI, MANRS and other tools achieve different levels of implementation.
No such text exists.
New text1.0 Introduction
Hijacks happen on an almost daily basis. Resource hijacks occur mainly, though not exclusively, through the use of eBGP. In the rest of this document, “hijacking” should be interpreted as the announcement of any type of resource (IPv4, IPv6, ASN) using BGP, without the consent of the legitimate holder of such resource, including those that have not been allocated/assigned.
The proposal does not attempt to address the problems caused by operational errors or occasional hijacks. Instead, it sees to create a mechanism for victims to report persistent and deliberate hijacking events. By making these cases more public and identifiable, each autonomous system will have additional information when making interconnection decisions.
2.0 Resource Hijacking Is a Policy Violation
A hijack is generally understood to be the announcement of routes by BGP to third parties without the consent of the legitimate resource holder. This is considered to be a violation of LACNIC policy.
A resource hijack or the announcement of unallocated or unassigned addresses or ASNs to a third party is a policy violation. The victims of the hijack include not only the legitimate holder of the hijacked resources, but also those who receive the announcements of the hijacked prefixes. In the context of a lease or sale, victims include both the legitimate holder and the party paying for the use of the resource.
To initiate an investigation, only reports in which the suspected hijacker is related to LACNIC policies will be accepted.
3.0 Scope: Accidental vs. Deliberate
Available routing datasets allow distinguishing between accidental and deliberate hijacks by observing parameters such as duration, recurrence, possible goals, and the size of hijacked blocks. Other parameters may also be considered in the future.
Accidental events are usually due to situations where a potentially hijacked prefix or ASN is very similar to other resources.
4.0 Lines of Action
LACNIC does not currently 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 LACNIC must include a minimum set of details, such as “Networks Affected”, “ASN of the Suspected Hijacker”, “What was the impact of this hijack?”, “Hijacked Prefixes/ASNs” and “Timespan”. This list is not final and other details may also be required.
LACNIC will provide a web-based form (or equivalent alternatives) to facilitate the submission of such reports. Only the information on hijacked routes/ASNs will be public to avoid the submission of duplicate reports.
The parties involved will be notified as soon as they are identified so that they can provide relevant information and mitigate the hijack, avoiding additional damages and possibly mistaken complaints.
LACNIC will define a pool of worldwide experts who can assess whether reported hijacks constitute policy violations. Experts from this pool will provide a judgment on each reported case no later than six weeks from the moment the report was received. If the report is not completed within this six-week period, the case will be dismissed.
Upstream or first hop transit providers of the suspected hijacker who allow such hijacks through their networks must receive a notification regarding the existence of the report. This report must not be considered a formal warning (a reply is not mandatory), but a request to verify whether they can provide more information or identify anything unusual.
As part of their research, experts may assess the relationships between ISPs of the same business groups, which may then be considered by LACNIC in case of having to proceed to apply any penalties. This prevents the suspected hijacker from continuing with the hijacking activities using the network of a spoofed customer. The experts’ research may also identify relationships between an ISP and end users that are part of the same business groups.
Cases in which the suspected hijacker can prove that their infrastructure was tampered with by a third party (for example, compromised routers) will not be considered deliberate.
As a preventive measure, holdership of the resources of the investigated parties may not be transferred or modified until the case is ratified or archived.
5.0 Expert: Definition
An expert is an external party to LACNIC, desirably with at least five years of experience in eBGP and experienced in managing peering and transit configurations. Experts must be familiar with the common types of interconnection agreements between entities both within and outside the LACNIC service region.
6.0 Pool of Experts
The procedure for the selection of the pool of worldwide experts must be open and managed by LACNIC, possibly in collaboration with other RIRs.
1. A call for candidates will be issued to the global community every two years including the experience and knowledge requirements; additional calls for candidate will be issued if it is necessary to expand the pool of experts.
2. The same number of experts must participate in each phase (initial and appeal, if applicable).
3. A minimum of three experts will be involved in each case and phase. If a larger number of experts is needed, this number must always be odd, and the community must be informed of the reasons for the change.
4. The pool of experts for each case and phase will be randomly selected, ensuring a balanced distribution of the cases among the experts.
5. The pool of selected experts will be kept confidential to avoid bribery attempts and/or retaliations against them.
6. Before accepting each case, the experts must sign a document confirming their impartiality and that they have no direct or indirect relationship with any of the parties involved.
7. The experts must sign a confidentiality agreement with LACNIC linking them to the information provided by the defendant (for example, information provided during the appeal).
8. Ongoing cases must be completed by the experts that were initially assigned, even if they are replaced during the selection process. An expert may only be replaced by another in case of justified cause and notifying the community about the replacement.
9. The experts will be replaced if they stop replying to their colleagues assigned to the same case or to LACNIC, or if they do not meet the deadlines established for three different cases.
7.0 Procedure
The procedure must include at least the following elements:
1. Before assigning a report to the group of experts, LACNIC will check that it contains sufficient information. Otherwise, the report will be dismissed.
2. If a report is accepted, the suspected hijacker will be notified and will be able to provide any information they consider relevant for the accusations to be dismissed.
3. The assigned experts will check the reported data against historical BGP data and verify the evidence provided by the suspected hijackers.
4. The group of experts assigned to each case will publish a joint report with their conclusions.
5. The experts will dismiss any case that is clearly accidental, but they will still have to specify this in their report so that LACNIC can transmit this information to the suspected hijacker to avoid its repetition.
6. Determining intentionality requires agreement among the majority of the experts assigned to the case.
7. The experts may not add any accused parties to a case.
8. The suspected hijacker may appeal the report. If this occurs, a different group of experts must review the case. Again, if the majority of the experts fail to reach an agreement, the case will be dismissed.
9. LACNIC staff (or the staff or the other RIRs) may not be part of the group of experts, although they may offer them administrative support. This does not include contacting those who originated the report to request further information or providing confidential information about its members.
10. The experts’ decision may not be appealed neither by LACNIC nor by the claimant.
8.0 Retroactivity
Only hijacking events that occur after this policy has been implemented are eligible to be considered.
9.0 Report and Evidence of Eligibility
A report may only be submitted by the networks directly affected by a hijacking event.
A report may only be submitted if:
• The victim is the legitimate holder of the hijacked resources.
• The victim has received by BGP a hijacked prefix or routes with an AS-PATH that includes a hijacked ASN.
A report will not be accepted if the person submitting the report was not affected by the reported hijacking event.
Any evidence that is more than six months prior to the moment when a report is submitted may not be considered or included in the experts’ reports.
10.0 Possible Objections
Once a report has been assessed by the experts, it will be sent to the suspected hijacker, who will then have four weeks to object to any conclusions contained in the report. The experts will then have two weeks to analyze any objections and rule on their admissibility. Following this, the report will be finalized and published.
11.0 Appeals
Following the publication of the final expert report, the suspected hijacker will have two weeks in which they can file an appeal. If an appeal is filed, an alternative group of experts will review the appeal within a maximum of four weeks. To uphold the initial decision of “deliberate hijacking”, during the appeals phase all the experts must maintain the majority. The results of this review are final and may not be further appealed.
12.0 Ratification
Once the report has been published, after a two-week public consultation period, the policy violation must be ratified by all the experts involved in the case. If not unanimously ratified, it will be dismissed. In case of an appeal, the ratification will be delayed until the second group of experts has concluded their review. The experts may refuse to ratify a report based on undisclosed information sources or information provided through the public consultation.
13.0 Transition Period
A transition period of six months is specified, which will begin when the implementation of the policy is announced. Thus, organizations that either due to operational errors or other non-malicious reasons are announcing address space or autonomous system numbers they have not been assigned may only be issued a warning.
Any bogons that exist at the time of the implementation of the policy should be treated as “exclusions”, and the cases where they are referenced should be dismissed before a case is assigned to the experts.
14.0 Continuous Violations by the Same Party
The procedures established for policy violations may only be applied in cases where a resource holder has regularly and repeatedly hijacked network resources they have not been assigned or authorized to use.
Additional informationThe authors believe that this proposal should become a new section of the Policy Manual, possibly located before the appendixes. However, given their editorial nature, the exact position and numbering will be left up to the LACNIC staff.
Other types of resource hijacks exist. In general, if they are intentional, their (isolated or combined) objectives may include:
• Hiding the true origin of traffic in order to perform illegal activities.
• Temporarily using address space without paying the associated registration costs (i.e., membership fees).
• Impersonating third-party networks and services.
• Listening in on third-party network traffic (i.e., man in the middle attacks).
• Interrupting IP communications between two or more third-party networks.
Examples of Expert Information Sources
The following list is not intended to be exhaustive but merely to serve as a reference:
• stat.ripe.net and stat.ripe.net APIs
• bgpmon.net and bgpstream.com
• irrexplorer.nlnog.net
• routeviews
• caida openBMP
• www.team-cymru.com/bogon-reference.html
• cidr report
o www.potaroo.net/cgi-bin/as-report?as=<asn>
o www.potaroo.net/cgi-bin/per-prefix?prefix=<prefix>
• bgp.he.net
• ixpdb.euro-ix.net/en/ixpdb/asns/
• atlas.ripe.net
• traceroute.org
Immediate implementation
ReferencesThe same proposal has been presented in the RIPE region:
• https://www.ripe.net/participate/policies/proposals/2019-03
Other RIRs are working on similar proposals, and equivalent proposals will be presented in each one.
Presented at:LACNIC 31 (06/05/2019)