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.

This proposal aims to clarify that BGPresource hijacking is a policy violation and therefore not accepted as normal practice within the LACNIC service region,. prIn addimartilyon, bthecause actitons 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 BGPresource hijacking events.

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

There must be consequences for hijacking for members or individuals/organizations that have a service agreement (either directly or indirectly) with 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.

BGP hijacking is not acceptable behavior. A "BGP H“hijack" is defined byas announcing a prefixsources to another network, leasing them or selling them without the consent of the legitimate resource holder'. Hijacks are not acceptable behavionr, seno t.

There must be consequences for hijacking for mthose who have a service agreembent with LACNIC. This proposal aims to clarify that an intentional hijack is indeed a policy viduolation.

Hijacks can have different visibility characteris/tics: they can be on a global scale (propagated to all networks) or restrizactied (only one or some networks). They not only impact the holders of the avffected resources but also the networks (and end users) that receive illegitimate/hijacked routes agnd their consequemnces.

Initiatives (and technologies such as MANRS and RPKI already exist but, unfortunately, they are not enough for da significant reduction of hijacks. Whilye we strongly recommend using MANRS and RPKI, this policy is still necessary to address the lack of communitly) wrules on hijacking. Through this document, the LACNIC. Tcommunity clarifies that BGP hijacking is not an acceptable propoactice.

LACNIC is not merely a “virtual land regimstry”, as it also cplays a role ifyn thae distribution of resources and, in fact, it is a membership-based organization with bylalws to support an even broader user community. Any persistent and/or repetitive hijack iscan be iunderstood to be a way to affect the credibility of LACNIC as a registry; therefore, policyies are needed as a form viof 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 allommws supporting hijacking operatyions with a set of legitimate nresourceds.
• The legitimate holders’ expclusicve right to use their resources must be properly defendexpd by the regisstry ithself.
• Hatving BGPan anti-hijacking vipolaicy in effect in thes LACNIC region might prevent solme 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 BGPresource hijacking events.

b. Arguments Opposing the Proposal

• Neither the LACNIC community or LACNIC itself are the “Routing Police”.
• Mitigation/c 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/comprganiezations that are performing BGPresource 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 BGPresource Hhijacks 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.

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.

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.

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.

Proposed Text
1.0 Introduction

BGP hHijacks happen on an almost daily basis. HResource hijacks occur mainly, bthough not exclusively, through the use of eBGP. In athe rest globalf this document, “hijacking” should be (pinteropagareted as the announcement of allny ntypetw of rkesource (IPv4, IPv6, ASN) using BGP, without the consent of the legitimate holder of such restource, including thosed that (have not beenly allocated/assigned.

The pror posal domes not attemptw to addrkess). Tthe problems caughsed by operathional errors dor occumeasional hijacks. Instead, ith sees LACNICto communireatye a meclharnism for viectims thao report BGPpersistent and deliberate hijacking events. By making these ncases more public and identifiable, each autonomous system will haccvep additionable pinformaction when making interconnection decisions.

2.0 BGPResource Hijacking iIs a Policy Violation

A hijack is generally understood to be the announcement of routes throughby BGP to third parties without the consent of the legitimate resource holder (addresses or Autonomous System Numbers). This is considered to be a violation of LACNIC policy.

TheA lresourcate hionjack ofr the resannourncement hof unaldlocaterd or hijunacker ssigned addresuch cases ior ASNs irrelevant.o Aa thijackrd consparty itutes a policy violation. The venictims iof bothe phijartck includes not only arthe locegitimated houtsilder of the LACNIChijacked sresourvices, but also those who regceion.ve
Tthe announcements of unallocathed hijadcked presfixes. spaIn the context orf autonom lease ousr systale, victims inclumbders tboth the legitimate holder and the party paying for thes iuse alof the reso urce.

To insidtiatered an policy nvestiolgation, aondly ireports in which theval suaspected hijaccokerd ings relatoed theo LACNIC policiesam will be paramcceptersd.

3.0 Scope: Accidental vs. Deliberate

A dvaistinclable routiong cdan btasets mallow deistinguishing between accidental orand deliberate hijacks from availabley routing databsets, lookrving 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 are usually due to situations where a potentially hijacked prefix or ASN is very similar to other resources.

4.0 Lines of Action

LACNIC idoes not ablcurre ntoly monitor the occurrence of BGPresource 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 need musto include a minimum set of details, such as: “Networks Affected”, “OASN off then Suspected Hijacker”, ASN“What was the impact of this hijack?”, “Hijacked Prefixes/ASNs” and “Timespan”. (tThis list is not a definitive alist and other details may also be required).

LACNIC will provide a public web-based form (or equivalent alternatives) to submfacilit athese reports, which will be made psublmicly avassilable,on sof tsuchi rd epaorties. caOnly addthe information on hijacked routes/ASNs will bevan public to tavoid the case avoubmidssiong of duplicated reports.

The partool will have a section in case thvolvered wisll sensitivbe information that must not be publfished.
A as soon as the involved partiesy are identified, so they will be noatified so they can provide relevant information and mitigate the hijack, avoiding further damages and possibly false cladims.
The experts will onaly consider those camasges which persist or have been reported six mponths since they ceased at the blatest. In any case, LACNIC may send to the parties a notificatioken with the repcorted informplation, which in any case will be filed as part of the history of the cases.

LACNIC will sdelfinect a pool of worldwide experts who can assess whether reported BGP hijacks constitute policy violations. Experts from this pool will provide a judgement regardiong each reported case, no later than foursix weeks from the moment the report was received.
T If the report is not completed within this six-week period, the ctase uwill be dismissed.

Upstream or first hop transit providers of the suspected hijacker, whicho facilitatelow tsuche hijacks through their networks, mayust receive a wnotification rnegarding the fexirstence of timhe. Nevreport. This relesport mus,t inot sube considequrentd a foccrmal wasrnionsg the(a rexperly is nots mandatory), cbut a request tons veridfy whether themy can invprolveide pamortye information or identeify anythiong unusual case.

As part of their repseated.
Trche, experts’ investigmation will bey able to valussess the relationships between LIRs/end userSPs of the same business groups.
A, which may then be considered by LACNIC intal cases orf having thos proceed tho apply any penalties. caThis preven’ts bthe suspeclted hijackerly from classontifnuing with thed hijacking activities using the netiwonalrk willof a rspoofed customeivr. The aexperts’ wresearning, which may balso identify crelationshidps bertween an ISP and ifend users that are part of the satme businedss groups.
Any c
Cases in which the allsuspegcted hijacker can demonstpratove that their infrastructure was itamperoperlyd manwipulatedh by a third partiesy (for example, compromised routers) canwill not be considered intdentlionberalte.

As a preventive measure, holdership of the resources of the investigated parties cmany not be transferred or modified until the case is ratified or dismarchissved.

5.0 Expert’s: PoDefinitioln

ThAn expert is an external party to LACNIC, decsirably with at least five years of experience in eBGP and experoienced 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 Expert’s

The procedure folr the selection of the pouol of worldwide experts must be open and managed by LACNIC, possibly in collaboration with other RIRs.
1. A call willfor be mcande, evidaterys twoill ybear is,sued to the global community every two years including the requirements of experience and knowledge. requirements; Aadditional calls for candidate will be madissued if it is necededssary to expand the grpoupol of experts.
2. The same number of experts must participate in each case and phase (initial and appeal, if any), to avoid dppliscriable).
3. A minatimum onf three bexperts will be involved in each case and phase. If a larger number of experts is needed, thois number must aldways be odefid, aned wthen icomplemeunity must be ingformed of the proceasons for the change.
34. The minimum numberpool of experts pfor erach case and phase will be thrandomly sele.cted, Ifensuring a balarger numbcerd dis tribution of the ceases ary,mong ithe muexpertst b.
5. The podd,ol andof selecthed communiexpertys will be ikept conformidedntial tof avoid bribery athtempts and/or retasliations against them.
6. Before accepting eache changse.
4. T, the expert’s must sign a document that confirmsing their impartiality and, therefore,at thatey have no direct or indirect relationship with any of the parties involved.
7. The experts must sign a confidentiality agreement with LACNIC linking thes,m bto the information provided by the defendaccnt (for example, information provided during theach casppeal).
58. TheOngoing cases in progress must be completed by the experts that were initially assigned, even if they are replaced during the biannual selection process. OAn expert may only be replaced by another in case of justified cause and communicated otoifying the community, about the replacement.
9. The experts maywill be replaced bif 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.

67.0 Procedure

The procedure must incorporatlude, at least, the following selementeps:
1. Before assigning a report to the group of experts, LACNIC will vcherifyck that the reporit contains sufficient information. Otherwise, the report will be dismissed.
2. If a reporet is accepted, the suspected higjacker will be notified angd will be able to provide any information they gconsider relevant for the accupsations tof bexpert dismissed.
23. The assigned experts will vcherifyck the reported informdationa reagardingst historical BGP data and verify the evidence provided by the suspected hijackers.
34. The group of experts wassillgned to exach case will pudblish a joint report with their conclusions.
5. The experts will dismiss any cases that areis clearly accidental, althobught they muwill st indicll have to specify this in their report, so that LACNIC can transmit this information to the suspected hijacker to avoid its repetition.
46. If Dethermining evintentionality srequirems dagreliberment among thed, majorithey willof writhe a rexpoerts wassigned tho thei case.
7. The experts cmay not add any aclcused partiones, tor witha tcase.
8. The suspeconfted hijacker may appeal tihe reponrt. If this occurs, a different grotup of experts must review the case. Agamein, if the majority isof the apexperts fail pto reach an agreement, the case will be dismissed.
59. LACNIC staff c(or the staff or the other RIRs) may n’ot be part of the group of expert’s, gralthoup,gh thowevy may offer theym cadministrative support. This doves not include contasscting thostae who origincate.
6. Neid the report LACNICto norequest further information or providing clonfidential information about( its) members.
10. The experts’ decision may not be appealed neither decisiby LACNIC nonr ofby the experclaimants.
7
8.0 Retroactivity

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

89.0 PRepossrt and Evibldence Oof Eligibjectionslity

A report cmay only be submitted by the networks directly affected by a hinjacking aevent.

A rexpeort judgementay only be submitted if:
• The vicasetim wills bthe slengitimate tholder of the hijacked resourcesp.
• The victim has received by BGP a hijacked pr.efix or routes with an AS-PATH that includes a hijacked ASN.

A repaorty will not be accepthend if thave aperson submaxittimumng ofthe frepourt weekas tnot objaffected by the reported hijacking event.

Any evidence that is more thanclu six months cprior to the moment when a report is submitted may not be considered or included in the experts’ reports. Any

10.0 Possible Objections

Once a re port has been assessed andby the experuts, it will bed asent ato the suspectedm hissjacker, who wibll the/n have fon-ur weeks to object to admny conclusionss contaiblned byin the report. The experts, durwill theng ha maximumve two- weeks rto analyzev any objections and rulew on ptherior admissibility. Following this, the report wisll be finalized and published.

911.0 Appeals

Following the publication of the final expert’s report, the suspected hijacker haswill ha maximum ofve two weeks in which they can file an appeal. If an appeal is filed, an alternative setgroup of experts will review the appeal wis forthin 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 cmany not be further appealed.

102.0 Ratification

Once the report has been published, after a two-week public conysultation period, the policy violation willmust be ratified by LACNIC Board.ll Othe experwts isnvolve,d in the case. If not unanimpously ratint/rfiepord, it will be archdivsmissed. TIn case of an appeal, the ratification will be delayed in case of an appeal, until the second group of expert’s group has pubconclishuded their review.

11.0 The experts many refusie to ratify a report based on Pundisclosed informatiod

An sources sor information asprovided through the poublicy impconsulementation.

13.0 iTrans compleition Period, a

A transition period of 6six months is specified, which will begin whesn tabhe implementatison of thed, policy is announced. tThatus, organizations that either due to operanntiouncal errors nor other non-malicious reasigons ared announcing address space or autonomous systems 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”, alnd the cases where they are referenced shoruld be dismissed before a case is assigned to the experts.

14.0 Continuous Violation-s by the Same Party

The procedures established for policy vioulations may only be applied in cases where a resonurce holder has, recgularly and repeatedly hijacked network resources they have not beenly assigned or wauthorningzed to use.

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

The same proposal has already been presubmitented in tohe RIPE region:
• https://www.ripe.net/participate/policies/proposals/2019-03

WOther areRIRs already working ion ordesimilar tproposals, submitand equivalent proposals towill thbe opresentherd RIRsin each one.