Registro y validación del contacto de abuso

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

Authors

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

General opinion

Proposal Data

Policy Type: LACNIC
Id: LAC-2018-5
Last version: 4
Presented at: LACNIC 29, LACNIC 30 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 LIRs que no tienen dicho contacto registrado para sus recursos, o incluso hay casos de LIRs 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 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" e "inetnum6", 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:

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 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 no superior a 2 días hábiles.
5) Si no se valida correctamente, escalado con el LIR y un nuevo plazo, no superior a 3 días hábiles.

(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 una vez cada tres meses y en cualquier momento que LACNIC considere oportuno.

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, implicará un seguimiento más exhaustivo, de conformidad con las políticas/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í la 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.
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 LIR.
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 no ha alcanzado consenso (a fecha de envío de esta propuesta).

Public Comments by LACNIC Staff

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

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

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

Modificación del texto actual
-----------------------------
La sección actual “12. Apéndices” pasa ser “A. Apéndices”, al final del Manual de Políticas, y se actualizan todas sus referencias.

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 nueva versión incorpora:
---------------------------
1. La sugerencia del staff que durante el bloqueo de Mi LACNIC también se permitiría acceder al contrato y a la parte de pago en Mi LACNIC a pesar del incumplimiento.
2. Mejora la redacción en algunas frases.

Comentarios del staff
----------------------
1. Si bien el Manual de Políticas no indica que el bloque IPv4 debe contener un contacto de abuso, el sistema de LACNIC ya soporta esta modalidad y los bloques IPv4, IPv6 y ASN ya poseen este atributo. Lo mismo sucede en el caso de las sub asignaciones, el abuse-c utilizado es el punto de contacto administrativo de la organización que recibe la asignación o la sub asignación.
Se realizó una consulta a la Base de Datos de LACNIC sobre el registro de los contactos de abuso de cada tipo de recursos y se obtuvieron los siguientes resultados:
- Cantidad de recursos IPv4, IPv6, ASN con contacto de abuso null o vacío: 0
- Cantidad de recursos legados IPv4 con contactos de abuso null o vacío: 241
- Cantidad de recursos legados IPv6 con contactos de abuso null o vacío: 0
- Cantidad de recursos legados ASN con contactos de abuso null o vacío: 146
Por lo tanto, actualmente no existe ningún recurso que no sea legado con el contacto de abuso vacío/null. Todos los que aparecen el la BD con null/vacío son legados.

2. LACNIC entiende que esto no aplica para las organizaciones con recursos legados, ya que no se menciona nada al respecto para este tipo de organizaciones.

3. Con relación al siguiente texto: “ Teniendo en cuenta la naturaleza jerárquica de los objetos, los heredados de aquellos distribuidos directamente por LACNIC (por ejemplo, sub-asignaciones), están cubiertos por los objetos de nivel superior y su propio atributo “abuse-c” es opcional.”
LACNIC entiende que esto significa que en caso de sub asignaciones de direcciones, el contacto de “abuse-c” puede estar cubierto por el de la organización de nivel superior o por el de su propia organización.

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

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

5. En la sección 12.5, cuando se indica “De mantenerse el incumplimiento, LACNIC actuará de conformidad con sus políticas y procedimientos pertinentes”:
5.1. no se especifica cómo deberá proceder LACNIC. LACNIC interpreta que el incumplimiento de esta política no determina la revocación de los recursos dado que se eliminó en la versión anterior. Si se pretende que el incumplimiento de esta política sea causal de revocación el autor deberá dejarlo explícito en el texto propuesto.
5.2. al indicar “de mantenerse el incumplimiento (...) LACNIC entiende que la siguiente verificación del incumplimiento sería en la segunda validación del año.

6. Es importante recordar que la revocación de recursos es de carácter permanente, tiene alto impacto sobre la operativa de las organizaciones y es un proceso complejo. Por este motivo recomendamos que esta instancia únicamente se aplique agotados todos los recursos y pasado un plazo significativo luego de que la irregularidad es detectada.

7. En la sección 12.1 se indica: “Todos los recursos distribuidos (…)”. Se recomienda modificar por: “Todos los recursos distribuidos y asignados (…)”. De esta forma se busca mantener el lenguaje del Manual de Políticas, para indicar que “distribuidos” hace referencia a los ISPs y “asignados” a los Usuarios Finales.

8. En el punto 5) de la sección 12.3, LACNIC asume que el “escalado” sería con el contacto administrativo de la organización. Se recomienda aclarar la redacción.

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

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.
Además implicará un desarrollo para el sistema el portal de los NIRs y de LACNIC para el bloqueo inicial.

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

Políticas sobre el contacto de abuso en otros RIRs
--------------------------------------------------

- RIPE
Hay una en fase de implementación: https://www.ripe.net/publications/docs/ripe-705
Sin embargo, es más flexible: la frecuencia es cada un año y es más simple, RIPE revisará que exista un dominio y que haya un servidor de correo configurado únicamente.

- APNIC
Una política similar a la de LACNIC llegó a consenso en el último evento de APNIC y está en fase de implementación.
https://www.apnic.net/wp-content/uploads/2018/08/prop-125-v001.txt

- ARIN
De acuerdo a la sección 3.6: https://www.arin.net/participate/policy/nrpm/#3-6-annual-validation-of-arin-s-public-whois-point-of-contact-data
Actualmente ARIN utiliza el siguiente procedimiento de validación: envía un correo una vez al año a cada contacto registrado. Cada contacto tiene un máximo de 60 días para responder que el contacto es correcto y está actualizado. De no responder luego de los 60 días, el contacto será marcado como inválido en la base de datos. Estos usuarios tendrán acceso limitado a las funcionalidades de ARIN online hasta que actualicen el contacto.
Además, hay una propuesta similar a la de LACNIC que se presentará en el evento de abril de ARIN: https://www.arin.net/participate/policy/drafts/2019_5/

- AFRINIC
Hay una propuesta similar a la de LACNIC que está en discusión desde noviembre del 2018. Se presentó en el último evento y volvió a discusión.
https://afrinic.net/policy/2018-gen-001-d2#proposal

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.

Privacy Policy