Registration and validation of "abuse-c" and "abuse-mailbox"

Original Language Español Date Published 05/03/2018 Last Modified 16/10/2018
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 3.0 (compare)

Authors

Name: Jordi Palet Martinez
Email: jordi.palet@consulintel.es
Organization: The IPv6 Company

Proposal Data

Policy Type: LACNIC
Id: LAC-2018-5
Last version: 3
Presentations:

Summary

La política actual (ASN) no es clara en cuanto a la obligación de registrar un contacto de abuse (abuse-c) ni al formato específico y si aplica a otros casos de registros en el whois.

Como consecuencia, puede haber receptores de recursos de LACNIC que no tienen dicho contacto registrado para sus recursos, o incluso hay casos de LIRs/ISPs, usuarios finales, u otros, que utilizan un buzón de correo inexistente o que no es procesado.

Ello origina en la práctica, que dicho contacto sea ineficaz para poder reportar abusos y en general problemas de seguridad y costes para las víctimas.

Esta propuesta pretende resolver el problema y garantizar la existencia de un contacto abuse-c correcto y el proceso para su uso.

Rationale

La comunidad de Internet se basa en la colaboración, pero en muchas ocasiones esto no es suficiente y hace falta que todos podamos ser capaces de contactar con aquellos LIRs u otros receptores de recursos de LACNIC que pueden tener un problema en la red y no conocerlo.

Esta propuesta crea una nueva sección en el manual de políticas, para permitir resolver este problema, por medio de una sencilla verificación periódica y establece las reglas básicas para la misma y evitar así costes innecesarios a terceras partes en su función de contactar con los responsables de resolver los abusos de una determinada red.

La propuesta garantiza que el coste de procesar los abusos recaiga sobre el LIR cuyo cliente está provocando el abuso (y del cual recibe compensación económica por el servicio), en lugar de recaer sobre la víctima, tal y como ocurriría si hubiera que acudir a la vía judicial, evitando por lo tanto el agravamiento económico (abogados, procuradores, etc.) y en tiempo, para ambas partes.

Para ello, el atribute abuse-c, que hasta ahora sólo estaba referenciado para el objeto “aut-num”, se hace obligatorio en los objetos “inetnum” (tanto para IPv4 como para IPv6), y cualesquiera puedan surgir en el futuro. Este atributo es un contacto de abuso, que contendrá como mínimo el atributo “abuse-mailbox”.

Text

Texto actual: No existe

Nuevo texto:

Nota (no debe ser incluida en el manual de políticas): La sección actual “12. Apéndices” pasa ser “A. Apéndices”, al final del manual de políticas, y se renumera en todo el manual de políticas, todas las referencias a ella. De este modo, nuevas secciones del manual, no requieren futuras renumeraciones, según el manual vaya “creciendo”. El texto de esta propuesta pasa por lo tanto a ser la sección 12.

12. Registro y Validación de “abuse-c” y “abuse-mailbox”

12.1. Descripción del “abuse-c” y “abuse-mailbox”
Todos los recursos distribuidos por LACNIC deben incluir, obligatoriamente, en la entrada de WHOIS correspondiente, el atributo de contacto “abuse-c” (contacto de abuso) como mínimo con un único email (abuse-mailbox) válido, monitorizado y adecuadamente atendido, que permita enviar reportes manuales o automáticos de comportamientos abusivos, seguridad, y similares.

El atributo “abuse-mailbox” debe estar disponible sin restricciones vía whois, APIs y futuras técnicas.

Teniendo en cuenta la naturaleza jerárquica de los objetos de direcciones IP, los objetos heredados de aquellos distribuidos directamente por LACNIC, pueden estar cubiertos por los objetos de nivel superior o tener su propio atributo “abuse-c”.

Siguiendo prácticas habituales, otros atributos “e-mail” pueden ser incluidos para otros propósitos.

12.2. Características del “abuse-mailbox”

Los emails enviados a ”abuse-mailbox” deben requerir intervención manual en algún momento, por parte del destinatario, y no pueden estar filtrados, ya que ello podría impedir, que en algunos casos, el envío de un reporte de abuso, por ejemplo por spam, al incluir el propio mensaje de spam o URLs o contenidos habitualmente clasificados como spam, evite su recepción.

El buzón “abuse-mailbox” podrá devolver inicialmente, una respuesta automática, por ejemplo, asignando un número de ticket, aplicando procedimientos de clasificación, pidiendo más información, etc. Sin embargo, no podrá requerir el uso de un formulario, ya que ello implicaría que cada empresa que necesite reportar abusos, generalmente de forma automatizada, se vea obligada a desarrollar una interfaz específica para cada caso de abuso, lo cual es inviable e ilógico, ya que haría recaer el coste del procesado de los abusos en el que envía la reclamación y por tanto es víctima del abuso, en lugar de ser costeada por aquel cuyo cliente (y de quién recibe ingresos), causa el abuso.

A título informativo, cabe mencionar que, lo razonable, es que quien reporta el abuso, lo haga desde el primer momento y en ese primer reporte, enviando los logs, o copia del spam (adjuntando ejemplo del email de spam o sus cabeceras completas) o similares, que demuestren el abuso. Igualmente, es razonable esperar que el email inicial de auto-respuesta indique que, si no se han enviado dichos registros, no será atendido, dando así la oportunidad a repetir el envío con las pruebas procedentes. Esto permite reportes automatizados, por ejemplo, mediante fail2ban, SpamCop u otros, con mínimo coste para ambas partes.

12.3. Objetivos de la validación del “abuse-c”/“abuse-mailbox”

El procedimiento, que habrá de ser desarrollado por LACNIC, deberá cumplir con estos objetivos:

1) Proceso simple que garantice su funcionalidad y permita a los “helpdesk” que atienden los reportes de abuso, verificar que las peticiones de validación efectivamente provienen de LACNIC y no de terceras fuentes (que pudieran implicar riesgos de seguridad), evitando, por ejemplo, una única URL “directa” para la validación.
2) Impedir un proceso exclusivamente automatizado.
3) Confirmar que quien valida asegura conocer el procedimiento, la política, que monitoriza regularmente el “abuse-mailbox”, se toman medidas y se responde al reporte de abuso.
4) Plazo de validación “inicial” no superior a 15 días.
5) Si no se valida correctamente, “escalado” con el receptor del recurso (LIR, usuario final, etc.) y un nuevo plazo, no superior a 15 días.

Los plazos de validación “inicial” y “escalado” podrán ser modificados por LACNIC, si lo considera oportuno, informando a la comunidad de los motivos. Por ejemplo, podrían acortarse una vez que hayan sido validados de forma inicial un alto porcentaje de los contactos, de forma que se incrementa la calidad de los contactos y se reduce el tiempo de respuesta a los casos de abuso.

(a título de ejemplo se propone un procedimiento detallado en “información adicional” de esta propuesta de política)

12.4. Validación del “abuse-c”/“abuse-mailbox”
LACNIC validará el cumplimiento de los puntos anteriores, tanto en el momento en que se crean o modifican los atributos “abuse-c” y/o “abuse-mailbox”, periódicamente, no menos de dos veces al año y en cualquier momento que LACNIC considere oportuno.

La frecuencia periódica de validación podría ser modificada por LACNIC, si lo considera oportuno, informando a la comunidad de los motivos. Por ejemplo, podría realizarse una única validación el primer año, para facilitar el tiempo de adaptación a la política, y posteriormente, de forma progresiva, incrementar el número de validaciones anuales, llegando a ser incluso trimestrales o mensuales, con el objetivo de incrementar la calidad de los contactos.

A criterio de LACNIC, de forma generalizada o en casos puntuales (por ejemplo para la confirmación en casos de escalado según el 12.5), LACNIC podrá utilizar dominios diferentes a lacnic.*, e incluso modificar el asunto y cuerpo del mensaje, para realizar dichas validaciones.

El incumplimiento por parte de cualquier organización, implicará inicialmente el bloqueo de “milacnic” para todos los recursos asociados con dicha organización, excepto para la actualización de los contactos abuse-c/abuse-mailbox, de tal forma que puedan ser re-validados para permitir el desbloqueo de “milacnic”.

LACNIC realizará un seguimiento más exhaustivo, y en el caso en que en la siguiente validación automática sigue confirmándose el incumplimiento, actuará de conformidad con las políticas y procedimientos pertinentes de LACNIC y especialmente “7.1. Recuperación de recursos”.

12.5. Mecanismo de escalado a LACNIC

Con el objetivo de evitar engaño (por ejemplo, “abuse-mailbox” que solo responden a emails de LACNIC, a determinado asunto o determinado cuerpo del mensaje), o el incumplimiento del resto de los aspectos de esta política (la incorrecta o no atención de los casos de abuso) y, por lo tanto, para garantizar la calidad de los servicios en la región con los recursos distribuidos por LACNIC, se dispondrá de un buzón (por ejemplo, “escalado-abusos@lacnic.net”), que permita escalar dichas situaciones, permitiendo así a LACNIC activare una re-validación, según el punto 12.4 anterior, e incluso la intermediación de LACNIC y en su caso, la aplicación de las políticas/procedimientos pertinentes y especialmente “7.1. Recuperación de recursos”.

Additional Information

Ejemplo de procedimiento de validación.
1) La validación se inicia de forma automatizada, por parte de LACNIC, con el envío de DOS emails consecutivos al “abuse-mailbox”.
2) Dichos emails tendrán exclusivamente formato texto (y por tanto ocultar URLs que correspondan a ataques como “phishing”, etc.).
3) El primero de los emails contendrá la URL donde debe realizarse la validación, que será “validacion.lacnic.net”, y podrá contener información respecto del procedimiento, extracto de esta política, etc.
4) El segundo de los emails contendrá un código alfanumérico único de validación.
5) El receptor que atiende el “abuse-mailbox”, deberá acceder a la URL y pegar en el formulario el código recibido en el segundo email.
6) Dicha URL, deberá estar diseñada de tal forma que impida un proceso automatizado (por ejemplo, “captcha”), y contendrá un texto que confirme que el receptor de la validación conoce el procedimiento, la política y que monitoriza de forma regular el “abuse-mailbox” y se toman medidas apropiadas para resolver los abusos reportados y responder a los mismos, con un “checkbox” que necesariamente deberá ser aceptado.
7) El código alfanumérico sólo será válido durante un máximo de 2 días laborables.
8) Si el código no es introducido en ese plazo, el sistema marcará el “abuse-c” como “provisionalmente inválido”, y alertará al staff de LACNIC para que se pueda iniciar el seguimiento personalizado con el receptor del recurso.
9) En caso de no obtener una respuesta, con la confirmación de la corrección de la situación, en un plazo adicional de 3 días laborables, el “abuse-c” será marcado de forma permanente como “inválido”.
10) Se repetirá de forma automática el proceso de validación (puntos 1 al 7 anteriores), y en este caso, el “abuse-c” será marcado como “válido” en caso satisfactorio, o en caso insatisfactorio, se trataría de un caso de incumplimiento de la política.

Timetable

90 días, de forma prudencial y a confirmar con LACNIC, para permitir tanto al staff el desarrollo de la herramienta, como a los LIRs actualizar sus contactos abuse-c.

References

En RIPE se está tramitando una propuesta similar, aunque aún está en debate y ha alcanzado consenso. Se trata de una versión mucho mas simple, y se ha presentado una nueva versión equivalente a esta misma propuesta. En APNIC ha alcanzado consenso una versión equivalente a esta propuesta. En AfriNIC se ha presentado la misma propuesta.

Public Comments by LACNIC Staff

LACNIC STAFF´S IMPACT ANALYSIS - Proposal LAC-2018-5 - version 2

LACNIC Staff's Interpretation of the Proposal
---------------------------------------------
Applicability
-----------
This proposal would apply to RIRs, requiring that they provide a valid abuse contact.

Modifications to the current text
---------------------------------
According to the modifications presented in policy proposal 2018-4, the Policy Manual would be modified as specified below.

• Addition of the following sections:
o 12. Registration and validation of "abuse-c" and "abuse-mailbox"
o 12.1. Description of "abuse-c" and "abuse-mailbox"
o 12.2. "abuse-mailbox” characteristics
o 12.3. Purpose of validating "abuse-c"/"abuse-mailbox"
o 12.4. Validation of "abuse-c"/"abuse-mailbox"
o 12.5. Escalation to LACNIC

• Section 12. Appendixes would be renumbered as section 13. Appendixes.


LACNIC Staff Comments

------------------------
• Sections 12.4 and 12.5 specify that “Lack of compliance will imply a more exhaustive follow-up, in accordance with the relevant LACNIC policies/procedures, especially 7.1. Resource recovery. However, it is not clear how LACNIC should proceed – whether policy 7.1 should be applied in every case.


• It should be noted that in order to implement this proposal LACNIC would need to invest new resources to handle those cases requiring follow-up. 


• This proposal makes reference to inetnum6 objects. LACNIC's whois only references inetnum objects, both for IPv4 and IPv6.


• LACNIC recommends not numbering the Appendix, but instead including it as A. (appendix). The purpose of this recommendation is to avoid having to update appendix numbers each time a section is added to the manual, as this could potentially result in errors due to the large number of references to the appendix (section 12) that appear throughout the text of the Policy Manual.

Impact of the policy on the registration system and address management
-------------------------------------------------------------------------
This proposal would involve developing a process to automatically monitor abuse-c and abuse-mailbox.

Privacy Policy