BGP 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 Under discussion Download TXT PDF XML DOCX
See other versions 1.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: 1

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 1

Interpretación de la propuesta por el staff de LACNIC
----------------------------------------------------

Aplicación
-----------
Esta propuesta aplicaría en el caso de un reporte sobre un secuestro de rutas a nivel operacional.

Modificación del texto actual
-----------------------------
Para la incorporación del texto de esta propuesta, se crearía una nueva sección en el Manual de Políticas previa a los apéndices.

Comentarios del staff
----------------------
1. LACNIC entiende que esta propuesta implicaría tomar acciones ante el no cumplimiento de esta política sobre los miembros de LACNIC. Sin embargo, no se podrían tomar acciones con las organizaciones que no son miembros de LACNIC.

2. LACNIC destaca que es muy difícil adjudicar intencionalidad de un anuncio no autorizado, por lo cual estos temas se gestionan con mucho cuidado.

3. Actualmente, para resolver este tipo de situaciones LACNIC cuenta con el WARP (Warning Advice and Report Point) que funciona como un Centro de Respuesta a Incidentes de Seguridad (CSIRT) (https://warp.lacnic.net/). El WARP ya recibe reportes de este tipo de incidentes y busca actuar ante estas situaciones basado en estándares de buenas prácticas utilizadas en centros de respuesta para la gestión de estos casos.
Además, hace algunos años que LACNIC brinda apoyo (incluyendo capacitación) a varias organizaciones para que creen sus CSIRTs y así mejorar la gestión de incidentes en la región, en especial para este tipo de casos.

4. Compartimos algunas cifras sobre la cantidad de reportes por anuncios de prefijos no autorizados recibidos por el WARP:
Durante el 2019 (hasta marzo): se recibieron 3 reportes y el 100% de los casos fueron resueltos.
Durante el 2018: se recibieron 6 reportes y el 100% de los casos fueron resueltos.
Durante el 2017: se recibieron 12 reportes. 11 fueron resueltos y uno sólo no respondió, pero se dejó de anunciar.

5. Impacto legal
En este tipo de incidentes no existen pruebas absolutas para determinar un secuestro de rutas, sino solamente indicios. Por otra parte, antes de proceder a iniciar un proceso de revocación de recursos, se debe contar con prueba fehaciente de que ello ha ocurrido. Por lo cual, puede traer aparejado consecuencias muy graves para LACNIC, en caso de que en algún caso se actué en base a indicios en lugar de certezas.

6. Esto podría no solo ser un impacto en el ámbito legal, sino que también a nivel operacional. No es posible probar la intencionalidad de un anuncio no autorizado de rutas. Los involucrados podrían sostener siempre que lo hicieron por error.

7. Podrían haber casos de falsos positivos, que al revocar recursos implicaría una mayor responsabilidad jurídica y financiera para el grupo de expertos y para LACNIC.

Recomendaciones
------------------

1. Se reconoce que el secuestro de rutas debe ser indicado como un incidente de seguridad. Sin embargo, la política entra en detalles del procedimiento que debería ser manejado por un Centro de Respuesta a Incidentes de Seguridad. Se informa que actualmente LACNIC implementa acciones para gestionar este tipo de incidentes a través del WARP, basado en las buenas prácticas establecidas por Centros de Incidentes de Seguridad.

2. Se recomienda ser cuidadosos en cuanto a los aspectos que se definen como responsabilidad de un RIR como parte de su administración de los recursos numéricos y no del ruteo. Es importante tener claro donde se establecen las fronteras.

3. En la sección 4.0 Líneas de acción:
3.1. Un aspecto importante a destacar es que los Centros de Respuesta tienen como principio básico la reserva de la información en forma confidencial para la correcta gestión del incidente.

3.2. LACNIC ya cuenta con un formulario web para reportar incidentes de seguridad (https://warp.lacnic.net/reportar-incidente) y un contacto de correo (info-warp@lacnic.net). Específicamente, en el formulario web hay un caso específico para reportar “anouthorized prefix advertisig”. De acuerdo con las buenas prácticas no se le denomina “secuestro de rutas” hasta no contar con pruebas de que se trata de una acción maliciosa.

3.3. Se sugiere cambiar la redacción que indica “LACNIC no puede supervisar la aparición de secuestros BGP”, debido a que en un futuro, LACNIC podría desarrollar algún servicio proactivo de detección de prefijos mal anunciados.

3.4. Los datos que se solicitan en un formulario son de resorte del equipo de respuesta del incidente y se basan en estándares de buenas prácticas utilizadas en centros de respuesta para la gestión de estos casos.

3.5. Se recomienda cambiar la redacción de "El secuestro de BGP es un comportamiento inaceptable (...) " y de "Los secuestros de BGP ocurren (...)".
Parece que el secuestro es a la sesión BGP. Se sugiere: "El secuestro de recursos de Internet (...) . BGP sería la vía para el secuestro. Pero lo que secuestra no es BGP, sino los recursos.

4. En la sección 5.0 Grupo de expertos
4.1. LACNIC cuenta con un Centro de Gestión de Incidentes de Seguridad (WARP). El BGP hijacking está definido dentro de la taxonomía de incidentes de seguridad que gestiona WARP. Además como centro coordinador puede determinar si es necesario escalar el mismo a otros CSIRTs, que también cuentan con un procedimiento y un protocolo de intercambio de información a nivel mundial.

4.2. Ya existe una red de confianza de centros de respuesta que trabajan de una forma establecida a nivel internacional.

4.3. No queda claro como LACNIC podría evaluar la experiencia de los expertos mundiales en el tema.

5. En la sección 6.0
“4.Si el evento parece intencionado, redactarán un informe con sus conclusiones, o con la confirmación o no de las mismas, de tratarse de la fase de apelación.” Al indicar “parece” podría no ser lo suficientemente sólido como para que los expertos generen un reporte por secuestro de rutas.
6 no permite a LACNIC tomar alguna acción en caso de que lo considere pertinente.

6. En la sección 8.0 Posibles objeciones
6.1. Cuando se indica que “(...) el secuestrador, quien dispondrá de un máximo de cuatro semanas para objetar (...)” contradice uno de los principios básicos de la gestión de incidentes “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. Al indicar que “el informe se hará público” podría ser tomado como una acusación y podría abrir una posible demanda.

7. En la sección 9.0 Apelaciones
7.1. Los tiempos propuestos no concuerdan con la gravedad de este tipo de incidentes, ya que el impacto de la demora puede significar un gran impacto en la estabilidad y la seguridad de Internet. Ejemplo: imaginemos el caso de YouTube and Pakistan Telecom con estos tiempos propuestos.
7.2. Al indicar “expertos alternativos”, no queda claro quienes formarían este otro grupo de expertos. Adicionalmente, en la sección 5.2 indica “El mismo número de expertos debe participar en cada caso y fase”, por lo cual no queda claro si se habla del mismo grupo u otro grupo de expertos “alternativos”.

Fuentes oficiales de referencias
-------------------------------

Situación en otros RIRs

RIPE NCC
Hay una propuesta similar en discusión:
https://www.ripe.net/participate/policies/proposals/2019-03

Privacy Policy