Resource Hijacking is a Policy Violation

LAC-2019-5-v1 LAC-2019-5-v2 Vs
References:
New
Deleted
Modified
Authors

Name: Carlos Friacas
Email: cfriacas@fccn.pt
Organization: FCT | FCCN
Name: Jordi Palet Martinez
Email: jordi.palet@theipv6company.com
Organization: The IPv6 Company
Name: Fernando Frediani
Email: fhfrediani@gmail.com
Organization: -

Name: Carlos Friacas
Email: cfriacas@fccn.pt
Organization: FCT | FCCN
Name: Jordi Palet Martinez
Email: jordi.palet@theipv6company.com
Organization: The IPv6 Company
Name: Fernando Frediani
Email: fhfrediani@gmail.com
Organization: -

Summary

This proposal aims to clarify that BGP hijacking is not accepted as normal practice within LACNIC service region, primar
ily 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 even
ts.

This proposal aims to clarify that resource hijacking is a policy violation and therefore not accepted as normal practic
e within the LACNIC service region. In addition, these actions negate the core purpose of running a Regional Internet Re
gistry.
The proposal is not concerned with simple operational mistakes – it is intended to address deliberate resource hijacking
events.

Rationale

BGP hijacking is not acceptable behavior. A "BGP Hijack" is defined by announcing a prefix to another network without th
e 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 violati
on.
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 c
ybersecurity 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 m
oment. 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 da
ta 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.

A “hijack" is defined as announcing resources to another network, leasing them or selling them without the consent of th
e 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 v
iolation.
Hijacks can have different visibility characteristics: they can be on a global scale (propagated to all networks) or res
tricted (only one or some networks). They not only impact the holders of the affected resources but also the networks (a
nd 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 signific
ant reduction of hijacks. While we strongly recommend using MANRS and RPKI, this policy is still necessary to address th
e 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, i
t is a membership-based organization with bylaws to support an even broader user community. Any persistent and/or repeti
tive hijack can be understood to be a way to affect the credibility of LACNIC as a registry; therefore, policies are nee
ded 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 prac
tices.
• If nothing changes in this field, the reputation of the LACNIC service region will continue to be affected from a c
ybersecurity 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. Howev
er, LACNIC needs to be able to choose not to enter into (or maintain) a contractual relationship with people/organizatio
ns that are performing resource hijacks. There are already enough sources of historic and “almost” real-time routing dat
a 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 evaluat
ors, who can use available sets of routing data to determine whether resource hijacking events have taken place, and whe
ther 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 determ
ine 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 c
ost).
• A single case of wrongful accusation that turns out to be innocent is worse than a hundred arrested resource hijack
ers.
o Counterargument: While this is true in practically every legal jurisdiction, it does not prevent the existence of r
ules 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 sh
ould 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.

Text

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 accepta
ble 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 eve
n 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 parameter
s 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 theref
ore 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 pub
licly available, so third parties can add information relevant to the case avoiding duplicated reports. The tool will ha
ve 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 mitig
ate 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 lates
t. In any case, LACNIC may send to the parties a notification with the reported information, which in any case will be f
iled 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 warnin
g the first time. Nevertheless, in subsequent occasions the experts may consider them an involved party if intentional c
ases 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 considere
d if repeated.
Any cases in which the alleged hijacker can demonstrate that their infrastructure was improperly manipulated by third pa
rties (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 knowled
ge. 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 discrimin
ation 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, a
nd 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 biannu
al selection process. Only in case of justified cause and communicated to the community, one expert may be replaced by a
nother.
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 o
f 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 a
s admissible/non-admissible by the experts, during a maximum two-weeks review period. Following this, the report is fina
lized 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. T
he 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/repo
rt will be archived. The ratification will be delayed in case of an appeal, until the second expert’s group has publishe
d 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 organiza
tions that announce not assigned address space or autonomous systems numbers, due to operational errors or other non-mal
icious reasons, receive only a warning.

Current text:
No such text exists.
New text:
1.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 allo
cated/assigned.
The proposal does not attempt to address the problems caused by operational errors or occasional hijacks. Instead, it se
es to create a mechanism for victims to report persistent and deliberate hijacking events. By making these cases more pu
blic 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 leg
itimate 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 violat
ion. The victims of the hijack include not only the legitimate holder of the hijacked resources, but also those who rece
ive the announcements of the hijacked prefixes. In the context of a lease or sale, victims include both the legitimate h
older 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 accepte
d.
3.0 Scope: Accidental vs. Deliberate
Available routing datasets allow distinguishing between accidental and deliberate hijacks by observing parameters such a
s 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 reso
urces.
4.0 Lines of Action
LACNIC does not currently monitor the occurrence of resource hijacks or assess whether they are policy violations. It mu
st 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 Hijacke
r”, “What was the impact of this hijack?”, “Hijacked Prefixes/ASNs” and “Timespan”. This list is not final and other det
ails 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 m
itigate 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. Exp
erts 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 rec
eive 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 identif
y 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 exampl
e, 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 unti
l 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 ma
naging 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 collabo
ration with other RIRs.
1. A call for candidates will be issued to the global community every two years including the experience and knowledg
e 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 cas
es 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 d
irect 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 defe
ndant (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 abou
t 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. Othe
rwise, 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 re
port 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. A
gain, 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 the
m administrative support. This does not include contacting those who originated the report to request further informatio
n 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 includ
ed 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 an
d 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 ma
jority. 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 b
y all the experts involved in the case. If not unanimously ratified, it will be dismissed. In case of an appeal, the rat
ification 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. Thu
s, organizations that either due to operational errors or other non-malicious reasons are announcing address space or au
tonomous 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 w
here 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 Information

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

The authors believe that this proposal should become a new section of the Policy Manual, possibly located before the app
endixes. 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

References

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