Registro y validación del contacto de abuso

Idioma Original Español Fecha Publicación 05/03/2018 Ultima Modificación 16/03/2019
Periodo de ultimos comentarios No aplica Fecha de ratificación No aplica Fecha de implementación No aplica
Estado En discusión Descargar TXT PDF XML DOCX
Ver otras versiones 1.0 2.0 3.0 4.0 (comparar)

Autores

Nombre: Jordi Palet Martinez
Email: jordi.palet@theipv6company.com
Organización: The IPv6 Company

Datos de la Propuesta

Tipo Politica: LACNIC
Id: LAC-2018-5
Última versión: 4
Presentaciones:

Resumen

La propuesta permite garantizar y validar los contactos de abuso del WHOIS (abuse-c y abuse-mailbox) de las organizaciones y poder así reportar los casos de abuso y resolverlos.

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

Justificación

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 está activamente monitorizado.

La falta de validación de los contactos ha vuelto ineficaz el reporte de casos de abusos, generando problemas de seguridad y costes para las víctimas.

Para tratar de resolver este problema, se plantea una sencilla verificación periódica del contacto de abuso, evitando así costes innecesarios a terceras partes.

La propuesta garantiza que el coste de procesar los abusos recaiga sobre el receptor del recurso que, quién directa o indirectamente (su cliente y del cual recibe posiblemente compensación por el servicio), es responsable del abuso, en lugar de recaer sobre la víctima. Téngase en cuenta que ello evita el posible agravamiento, tiempo y gatos judiciales para ambas partes si se acude a dicha instancia.

Para ello, el atributo 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”.

Texto

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, o la que considere oportuna el staff en el momento de su implementación, una vez alcanzado el consenso.

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 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 tecnologías.

Teniendo en cuenta la naturaleza jerárquica de los objetos, los heredados de aquellos distribuidos directamente por LACNIC (por ejemplo, sub-asignaciones), estan cubiertos por los objetos de nivel superior y su propio atributo “abuse-c” es opcional.

Siguiendo prácticas habituales, otros atributos “email” 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, en algunos casos, la recepción de un reporte de abuso. Por ejemplo, un reporte de spam, al incluir el propio mensaje de spam o URLs o contenidos habitualmente clasificados como spam.

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 entidad que necesite reportar abusos, generalmente de forma automatizada, se vea obligada a desarrollar una interfaz específica para cada receptor de recursos al que tiene que reportar un abuso. Ello sería inviable, ya que haría recaer el coste del procesado de los abusos en el que envía la reclamación, víctima del abuso, en lugar de sobre aquel que (directa o indirectamente) causa el abuso.

Lo razonable, es que quien informa del abuso, lo haga en el primer reporte, enviando información suficiente (log, copia del spam o cabeceras completas, lo equivalente en cada tipo de abuso). Igualmente, es razonable que el email inicial de auto-respuesta indique que, si no se ha enviado dicha información, 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) Garantizar su funcionalidad y permitir a los “helpdesk” que atienden los reportes de abuso, la verificación de que la validación efectivamente proviene de LACNIC y no de terceras fuentes (implicando 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 y las políticas de LACNIC
• monitoriza regularmente el “abuse-mailbox”
• toma medidas al respecto
• responde al reporte de abuso.
4) Plazo de validación “inicial” de 15 días.
5) Si no se valida correctamente, “escalado” con el receptor original del recurso (LIR, usuario final, etc.) en un plazo adicional de 15 días.

Los plazos de validación podrán ser modificados a criterio de LACNIC, informando a la comunidad de los motivos.

(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 la política de forma periódica, al menos dos veces al año, y cuando se creen o modifiquen los atributos del “abuse-c”.

La frecuencia de validación podrá ser modificada a criterio de LACNIC, informando a la comunidad de los motivos.

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.6), LACNIC podrá utilizar dominios diferentes a lacnic.*, e incluso modificar el asunto y cuerpo del mensaje, para realizar dichas validaciones.

12.5. De los incumplimientos

El incumplimiento por parte de cualquier organización, implicará el bloqueo de MiLACNIC y medidas equivalentes en los sistemas de los NIRs, para todos los recursos asociados con dicha organización. Quedan exceptuadas las cuestiones exclusivamente contractuales y relacionadas con pagos, así como la actualización de los contactos abuse-c/abuse-mailbox, de tal forma que puedan ser automáticamente re-validados para permitir el desbloqueo de MiLACNIC.

Cualquier acceso a MiLACNIC, durante dicho bloqueo, mostrará un mensaje de advertencia, incluyendo el texto de esta política, y para permitir continuar será necesario que dicho mensaje sea “leído” hasta el final, y se confirme mediante un check-box o similar.

De mantenerse el incumplimiento, LACNIC actuará de conformidad con sus políticas y procedimientos pertinentes.


12.6. Mecanismo de escalado a LACNIC

LACNIC contará con mecanismos (formulario, correo electrónico, otros) para facilitar el escalado en los casos en los que se quiera reportar un incumplimiento de esta política, lo cual activará la re-validación y otras medidas que LACNIC pueda considerar oportunas.

Información Adicional

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

Tiempo de Implementacion

90 días, de forma prudencial y a confirmar con LACNIC, para permitir tanto al staff el desarrollo de la herramienta, como a los receptores de recursos de LACNIC actualizar sus contactos abuse-c. LACNIC podrá enviar un recordatorio con la ratificación de la propuesta por parte del Directorio.

Referencias

En RIPE se adoptó una propuesta similar pero solo de verificación automática, y el debate reciente de la lista, precisamente ha indicado la necesidad de hacerlo de forma “no exclusivamente automática”, pues el procedimiento actual permite numerosos engaños.

Además, se está tramitando una propuesta similar que será publicada en pocas semanas.

En APNIC ha alcanzado consenso una versión equivalente a esta propuesta.

En AfriNIC se ha presentado la misma propuesta.

Se prevé presentar una propuesta equivalente en ARIN.

Notas públicas del Staff de LACNIC

ANÁLISIS DE IMPACTO DEL STAFF DE LACNIC - Propuesta LAC-2018-5 - versión 3

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

Aplicación
-----------
Esta propuesta se aplicaría a los receptores de recursos de LACNIC para que registren un contacto de abuso válido, tanto para ASNs, IPv4 e IPv6.

Modificación del texto actual
-----------------------------
De acuerdo a las modificaciones presentadas en la propuesta 2018-5, el manual de políticas quedaría como se muestra a continuación en las siguientes secciones:

• Se agregan las secciones:

o 12. “Registro y Validación de "abuse-c" y "abuse-mailbox”
o 12.1 “Descripción del "abuse-c" y "abuse-mailbox”
o 12.2. “Características del "abuse-mailbox"
o 12.3. Objetivos de la validación del "abuse-c"/"abuse-mailbox
o 12.4. Validación del "abuse-c"/"abuse-mailbox"
o 12.5. Mecanismo de escalado a LACNIC

• La sección 12. Apéndices deja de tener numeración para poder incorporar nuevas secciones sin necesidad de renumerar los apéndices constantemente.

Comentarios del staff
-----------------------
• Cambios con respecto a la versión anterior la propuesta:
o Incorpora las recomendaciones del staff de LACNIC de las versiones anteriores sobre:
- usar el término inetnum tanto para IPv4 como para IPv6
- poner la sección de apéndices sin numeración
o Agrega que el procedimiento establecido por LACNIC debe impedir que el proceso de validación sea exclusivamente automatizado.
o Modifica que el plazo de validación inicial no debe ser superior a 15 días hábiles en lugar de 2.
o Indica que, si el contacto de abuso no se valida correctamente en la etapa inicial, se escala con el receptor del recurso en un plazo no superior a 15 días, en lugar de 3.
o Agrega que los plazos de validación “inicial” y “escalado” pueden ser modificados por LACNIC.
o Cambia la validación periódica que LACNIC debería hacer de una vez cada 3 meses a 2 veces al año. Además, permite que LACNIC modifique la frecuencia de validación si lo considera oportuno.
o Propone una alternativa para el caso de incumplimiento:
- Bloqueo inicial de milacnic para todos los recursos de la organización, excepto para la actualización de contactos abuse-c/abuse-mailbox
- Si se actualizan correctamente los contactos de abuso, serán revalidados para permitir el desbloqueo de milacnic.
- En el caso de que se siga incumpliendo se procedería a aplicar la sección 7.1. Recuperación de recursos.

Recomendaciones
• En la sección 12.4 y 12.5, cuando se indica “El incumplimiento, implicará un seguimiento más exhaustivo, de conformidad con las políticas/procedimientos pertinentes de LACNIC y especialmente "7.1. Recuperación de recursos", no especifica cómo deberá proceder LACNIC, si deberá aplicar la política 7.1 en todos los casos o no.

• Se observa que para la implementación de esta propuesta LACNIC necesitará invertir nuevos recursos para atender el seguimiento de todos los casos que lo necesiten.

• Se recomienda que la propuesta no defina plazos, sino que determine acciones y que los plazos necesarios se definan en base a razones operativas.

• Se sugiere que durante el bloqueo de Mi LACNIC también se debería permitir acceder al contrato y a la parte de pago en milacnic a pesar del incumplimiento.

• Con respecto a la información adicional que menciona la propuesta, indica que “una propuesta similar sobre el contacto de abuso alcanzó consenso en RIPE NCC en junio del 2018”. (https://www.ripe.net/participate/policies/proposals/2017-02).
La propuesta 2017-2 de RIPE NCC es más flexible: no indica plazos y la validación que implementará RIPE es más simple, revisará que exista un dominio y que haya un servidor de correo configurado únicamente.

Impacto en el sistema de registro
---------------------------------
Esta propuesta implicará la creación de un proceso para el control automático del abuse-c y abuse-mailbox.

ANÁLISIS DE IMPACTO DEL STAFF DE LACNIC - Propuesta LAC-2018-5 - versión 2

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

Aplicación
-----------
Esta propuesta se aplicaría a los LIRs para que dejen un registro de un contacto de abuso válido.

Modificación del texto actual
-----------------------------
El manual de políticas quedaría como se muestra a continuación en las siguientes secciones:

• Se agregan las secciones:
o 12. “Registro y Validación de "abuse-c" y "abuse-mailbox”
o 12.1 “Descripción del "abuse-c" y "abuse-mailbox”
o 12.2. “Características del "abuse-mailbox"
o 12.3. Objetivos de la validación del "abuse-c"/"abuse-mailbox
o 12.4. Validación del "abuse-c"/"abuse-mailbox"
o 12.5. Mecanismo de escalado a LACNIC

La sección 12. Apéndices pasa a ser la sección 13. Apéndices

Comentarios del staff
-----------------------
• En la sección 12.4 y 12.5, cuando se indica “El incumplimiento, implicará un seguimiento más exhaustivo, de conformidad con las políticas/procedimientos pertinentes de LACNIC y especialmente "7.1. Recuperación de recursos", LACNIC entiende que en este caso aplicaría la política 7.1.

• Se observa que para la implementación de esta propuesta LACNIC necesitará invertir nuevos recursos para atender el seguimiento de todos los casos que lo necesiten. 


• En la propuesta se hace referencia al objeto “inetnum6 “. En el whois de LACNIC, solamente se hace referencia al objeto inetnum, tanto para IPv4 e IPv6.


• Se recomienda poner la sección del apéndice sin numeración, sino como A. (apéndice). Esta recomendación es con el fin de no tener que actualizar la numeración del apéndice tantas veces como secciones que se agreguen al manual, lo cual podría generar errores debido a todas las referencias al apéndice (sección 12), que aparecen en todo el texto del manual de políticas.

Impacto en el sistema de registro
---------------------------------
Esta propuesta implicará la creación de un proceso para el control automático del abuse-c y abuse-mailbox.

Política de privacidad