Resource Hijacking is a Policy Violation

Original Language Español Date Published 29/03/2019 Last Modified 18/03/2019
Last Call for Comments Period Does not apply Date Ratified Does not apply Implementation Date Does not apply
Status Abandoned 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
Presentations:

Summary

This proposal aims to clarify that BGP hijacking is not accepted as normal practice within LACNIC service region, primarily because it negates the core purpose of running a RIR.

The proposal is not concerned with simple operational mistakes – it is intended to address deliberate BGP hijacking events.

Rationale

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.

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

2.0 BGP Hijacking is a Policy Violation

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

The location of the resource holder or hijacker in such cases is irrelevant. A hijack constitutes a policy violation even if both parties are located outside of the LACNIC service region.
The announcement of unallocated address space or autonomous system numbers to third parties is also considered a policy violation and is evaluated according to the same parameters.

3.0 Scope: Accidental vs. Deliberate
A distinction can be made between accidental or deliberate hijacks from available routing datasets, looking at parameters such as duration, recurrence, possible goals, and the size of hijacked blocks. Other parameters may also be considered in the future.

4.0 Lines of Action
LACNIC is not able to monitor the occurrence of BGP hijacks or assess whether they are policy violations. It must therefore rely on external parties, both to report hijacks and determine whether they are deliberate.
Reports sent to LACNIC need to include a minimum set of details, such as: “Networks Affected”, “Offender ASN”, “Hijacked Prefixes” and “Timespan” (this is not a definitive list and other details may also be required).
LACNIC will provide a public web-based form (or equivalent alternatives) to submit these reports, which will be made publicly available, so third parties can add information relevant to the case avoiding duplicated reports. The tool will have a section in case there is sensitive information that must not be published.
As soon as the involved parties are identified, they will be notified so they can provide relevant information and mitigate the hijack, avoiding further damages and possibly false claims.
The experts will only consider those cases which persist or have been reported six months since they ceased at the latest. In any case, LACNIC may send to the parties a notification with the reported information, which in any case will be filed as part of the history of the cases.
LACNIC will select a pool of worldwide experts who can assess whether reported BGP hijacks constitute policy violations. Experts from this pool will provide a judgement regarding each reported case, no later than four weeks from the moment the report was received.
The direct upstreams of the suspected hijacker, which facilitate the hijack through their networks, may receive a warning the first time. Nevertheless, in subsequent occasions the experts may consider them an involved party if intentional cases are repeated.
The experts’ investigation will be able to value the relationships between LIRs/end users of the same business groups.
Accidental cases or those that can’t be clearly classified as intentional will receive a warning, which may be considered if repeated.
Any cases in which the alleged hijacker can demonstrate that their infrastructure was improperly manipulated by third parties (for example, compromised routers) can not be considered intentional.
As a preventive measure, the resources of the investigated parties can not be transferred or modified until the case is ratified or dismissed.

5.0 Expert’s Pool

The selection procedure of the expert’s pool should be open and managed by LACNIC, possibly in collaboration with other RIRs.
1. A call will be made, every two years, to the global community including the requirements of experience and knowledge. Additional calls will be made if it is needed to expand the group of experts.
2. The same number of experts must participate in each case and phase (initial and appeal if any), to avoid discrimination between cases. It should be defined when implementing the process.
3. The minimum number of experts per case and phase will be three. If a larger number is necessary, it must be odd, and the community will be informed of the reasons for the change.
4. The expert’s must sign a document that confirms their impartiality and, therefore, that have no direct or indirect relationship with the involved parties, before accepting each case.
5. The cases in progress must be completed by the experts initially assigned, even if they are replaced in the biannual selection process. Only in case of justified cause and communicated to the community, one expert may be replaced by another.

6.0 Procedure

The procedure must incorporate, at least, the following steps:
1. LACNIC will verify that the report contains sufficient information before assigning it to the group of experts.
2. The assigned experts will verify the reported information regarding historical BGP data.
3. The experts will exclude those cases that are clearly accidental, although they must indicate this in their report, so that LACNIC transmits it to the suspected hijacker to avoid its repetition.
4. If the event seems deliberated, they will write a report with their conclusions, or with the confirmation or not of the same, if it is the appeal phase.
5. LACNIC staff can’t be part of the expert’s group, however they can provide assistance.
6. Neither LACNIC nor the claimant(s) can appeal the decision of the experts.
7.0 Retroactivity
Only hijacking events that occur after this policy has been implemented are eligible to be considered.

8.0 Possible Objections
A report containing an expert judgement on the case will be sent to the suspected hijacker. This party will then have a maximum of four weeks to object to any conclusions contained in the report. Any objections are then assessed and ruled as admissible/non-admissible by the experts, during a maximum two-weeks review period. Following this, the report is finalized and published.

9.0 Appeals
Following the publication of the final expert’s report, the suspected hijacker has a maximum of two weeks in which they can file an appeal. If an appeal is filed, an alternative set of experts will review this for a maximum of four weeks. The results of this review are final and cannot be further appealed.

10.0 Ratification
Once the report has been published, any policy violation will be ratified by LACNIC Board. Otherwise, the complaint/report will be archived. The ratification will be delayed in case of an appeal, until the second expert’s group has published their review.

11.0 Transition Period

As soon as the policy implementation is completed, a transition period of 6 months will be established, so that organizations that announce not assigned address space or autonomous systems numbers, due to operational errors or other non-malicious reasons, receive only a warning.

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

Timetable

Immediate

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.

Public Comments by LACNIC Staff

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

LACNIC Staff's Interpretation of the Proposal
---------------------------------------------

Applicability
------------
This proposal would apply when a case of route hijacking is reported at operational level.

Modifications to the current text
---------------------------------
A new section would be created in the Policy Manual before the appendixes to incorporate the text of this proposal.

LACNIC Staff Comments
-----------------------

1. LACNIC understands that this proposal would mean acting on LACNIC members should they fail to comply with this policy. However, no action would be possible in the case of organizations that are not LACNIC members.

2. LACNIC stresses that it is very difficult to establish the intentionality of an unauthorized announcement, which is why they are managed with great care.

3. These type of situations are currently solved through the LACNIC WARP (Warning Advice and Report Point), which operates as a Computer Security Incident Response Team (CSIRT) (https://warp.lacnic.net/). LACNIC WARP already receives reports on this type of incidents and acts based on best practice standards used by other incident response teams.
In addition, for a few years now, LACNIC has been offering support (including training) to different organizations so that they can create their own CSIRTs and thus improve regional security incident management capabilities, particularly in this type of cases.

4. ome figures on the number unauthorized prefix announcement events reported to LACNIC WARP:
January-March 2019: Three reports were received, 100% of these cases were solved.
2018: Six reports were received, 100% of these cases were solved.
2017: Twelve reports were received, eleven of these were solved and only one failed to reply. This announcement was withdrawn.

Legal Implications
5. In this type of incident, there is no proof that a route has been hijacked. Instead, there are merely indications. On the other hand, before initiating a resource revocation process, reliable evidence that a hijack has actually occurred is required. Thus, actions taken based on indications and not on evidence might have serious consequences for LACNIC.

6. Such consequences might not only be legal but also operational. It is impossible to prove the intentionality of an unauthorized route announcement. Those involved could always claim that it was not a deliberate action but an unintended error.

7. False positives might occur which, if resources were revoked, would involve even greater legal and financial responsibility both for the set of experts involved and for LACNIC.

Recommendations

1. LACNIC agrees that route hijacking must be recognized as a security incident. However, the policy goes into details of the procedure that a Security Incident Response Team should follow. LACNIC currently implements actions for managing this type of incidents through LACNIC WARP, always based on best practices established by Security Incident Response Teams.

2. We recommend being careful to define the responsibilities of an RIR in terms of number resource management, not routing. It is important to be clear on where the boundaries are established.

3. In Section 4.0 Lines of Action:

3.1. LACNIC already offers an online form that can be used to report security incidents (https://warp.lacnic.net/reportar-incidente), as well as an email address (info-warp@lacnic.net) that can be used for the same purpose.
3.2. The online form includes a specific item for reporting “unauthorized prefix advertising.” In line with current best practices, an incident is not labeled as “route hijacking” until evidence is available to support the fact that it is a malicious action.

3.3.The information requested in the form is to be used by the incident response team and is based on best practice standards adopted by incident response centers for handling such cases.

4. In Section 6.0 Pool of Experts:
4.1. LACNIC has a Security Incident Management Team (WARP). BGP hijacking is included among the security incidents managed by LACNIC WARP. Likewise, as a coordination center, LACNIC WARP can determine whether it is necessary to scale each incident to other CSIRTs which, in turn, also use a global information exchange protocol and procedure.

4.2. A trusted global network of incident response centers already exists, and its members are working in a well-established manner.

4.3. It is not clear how LACNIC would assess the experience of global experts on the topic.

5. In section 7.0.
5.1. It is important to stress that one of the basic principles of an Incident Response Team is maintaining the confidentiality of the information for proper incident management.
5.2. Item 10. does not allow LACNIC to take any action, even if the organization believes it would be pertinent.

6. In Section 10.0 Possible Objections
6.1. The text “(...) This party will then have a maximum of four weeks to object to (...)” contradicts one of the basic principles of incident management: “The speed with which an organization can recognize, analyze, and respond to an incident will limit the damage and lower the cost of recovery.” Cert.org
6.2. Specifying that “the report will be finalized and published” might be interpreted as an accusation and result in a lawsuit.

7. In section 11.0 Appeals:
7.1. The proposed time frame is not in line with the severity of this type of incidents, as the impact of a delay can greatly affect Internet stability and security. For example, imagine if the proposed time frame had been used in the case of YouTube and Telecom Pakistan.
7.2. The proposal specifies “an alternative set of experts,” yet it is not clear who would be part of this additional group of experts. In addition, Section 5.2 states that “The same number of experts must participate in each case and phase,” so it is not clear whether this is the same group or another set of “alternative” experts.”

Official Sources
-----------------

Situation in the other RIRs
--------------------------
RIPE NCC
A similar proposal is under discussion:
https://www.ripe.net/participate/policies/proposals/2019-03

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