Resource Hijacking is a Policy Violation

Original Language Español Date Published 29/03/2019 Last Modified 29/04/2019
Last Call for Comments Period Does not apply Date Ratified Does not apply Implementation Date Does not apply
Status Under discussion Download TXT PDF XML DOCX
See other versions 1.0 2.0 (compare)

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

Proposal Data

Policy Type: LACNIC
Id: LAC-2019-5
Last version: 2
Presented at: LACNIC 31 Presentations:

Summary

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

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.

Text

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

The 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

Timetable

Immediate implementation

References

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.

Public Comments by LACNIC Staff

LACNIC STAFF´S IMPACT ANALYSIS - Proposal LAC-2019-5 - versión 1

LACNIC Staff’s Interpretation of the Proposal
---------------------------------------------
Applicability
------------
This proposal would apply when a case of route hijacking at operational level is reported.

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. This 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/). The WARP already receives reports on this type of incidents and acts based on the 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. Some figures on the number unauthorized prefix announcement events reported to LACNIC WARP:
○ January-March 2019: 3 reports were received and 100% of these cases were solved.
○ 2018: 6 reports were received and 100% of these cases were solved.
○ 2017: 12 reports were received. 11 were solved and only 1 failed to reply (the announcement was withdrawn).

5. Legal Implications
In this type of incident, there is no proof that a route has been hijacked but merely indications. On the other hand, before initiating a resource revocation process, reliable proof a hijack has actually occurred is required. This means that acting based on indications — not proof — might have serious consequences for LACNIC.

6. Such consequences might be not only 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 error.

7. False positives might occur which, if resources were revoked, would involve even greater legal and financial responsibility for the set of experts 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 its WARP, always based on best practices established by Security Incident Response Teams.

2. We recommend being careful when defining 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. 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.

3.2. 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. The online form includes a specific item to report “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. We suggest modifying the text that specifies that “LACNIC is not able to monitor the occurrence of BGP hijacks” as, in the future LACNIC, might possibly develop a proactive service for detecting incorrectly announced prefixes.

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

3.5. We recommend changing the terms used in “BGP hijacking is not acceptable behavior (...)” and “BGP hijacks happen (...),” as they make it seem as if the BGP sessions are the ones actually hijacked. Instead, we suggest: “Internet resource hijacking (...). BGP would be the vector; however, what is hijacked is not the BGP but the resources.

4. In Section 5.0 Expert’s Pool:
4.1. LACNIC has a Security Incident Management Team (WARP). BGP hijacking is included among the security incidents managed by the WARP. Likewise, as a coordination center, the WARP can determine whether it is necessary to scale each incident to other CSIRTs, which 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 6.0 Procedure:
“4. If the event seems deliberate, they will write a report with their conclusions, or with the confirmation or not of the same, if it is the appeal phase.” The use of the term “seems” might not be sound enough for experts to generate a route hijacking report.
6. does not allow LACNIC to take any action even if it believes it is pertinent.

6. In Section 8.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 is finalized and published” might be interpreted as an accusation and originate a lawsuit.

7. In section 9.0 Appeals:
7.1. The proposed time frame does not match the severity of this type of incidents, as the impact of a delay can greatly affect Internet stability and security. For example, imagine the case of YouTube and Telecom Pakistan using the proposed time frame.
7.2. By specifying “an alternative set of experts” it is not clear who would be part of this other group of experts. In addition, Section 5.2 states “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 other RIRs

● RIPE NCC
A similar proposal is under discussion:
https://www.ripe.net/participate/policies/proposals/2019-03

Privacy Policy