Registro y validación del contacto de abuso - N/D

General information

Español
26/09/2019
Implementada
100 %.

Jordi Palet Martinez - Version [1, 2, 3, 4, 5, 6]
En discusión
04/03/2018
Ultimos comentarios
08/12/2019 - 05/01/2019
Ratificación del directorio
12/01/2020
Ratificada
26/02/2020
Implementada
27/05/2021

Public comments by LACNIC staff for this version

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. Acerca 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:

- Resume y acorta la sub sección 12.2. Acerca del “abuse-mailbox en la que se describen las características que debe tener el abuse-mailbox.
- Elimina la sección “De los incumplimientos” y agrega a la sub sección 12.4. Validación del “abuse-mailbox”, “El incumplimiento por parte de cualquier organización se produce si no se ha validado en el plazo “inicial” ni “adicional”.

Comentarios del staff:
------------------------
(Los comentarios son observaciones para ayudar a diferenciar los cambios que presenta la propuesta con respecto al texto actual del Manual de Políticas)

1. LACNIC interpreta que los plazos propuestos podrían ser modificados de acuerdo a lo que crea conveniente para su mejor implementación. Tantos los plazos de validación inicial y escalado, como la frecuencia de validación periódica.

2. LACNIC entiende que el objetivo de la propuesta no es revocar ante cualquier tipo de evidencia, sino ante el incumplimiento reiterado y significativo de las políticas. LACNIC procederá a realizar revocaciones en una última instancia.

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.

3. 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 caso de que haya incumplimiento.

4. 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. Sin embargo, LACNIC no hace ningún tipo de validación sobre los contactos.

5. LACNIC entiende que esto no aplica para las organizaciones con recursos legados. Si bien estas organizaciones están en la misma base de datos de LACNIC, muchos no tienen un contacto válido (e-mail, teléfono) ni obligación contractual de actualizarlo debido a la antigüedad de la asignación (antes de 1997). Las organizaciones con recursos legados tampoco están obligadas a regirse por las políticas de LACNIC por lo que esta política tampoco sería aplicable a ellos.

6. 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. Por lo tanto LACNIC interpreta que no se realizarían las verificaciones de las sub asignaciones.

7. En el punto 5) de la sección 12.3, LACNIC asume que el “escalado” sería con el resto de los contactos de la organización.

Recomendaciones
------------------
8. 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.

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

Políticas sobre el contacto de abuso en otros RIRs
--------------------------------------------------
- RIPE
Hay una propuesta 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


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 (Describe the problem you intend to solve)

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.

Current 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 y monitorizado, 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. Procedimiento de validación del "abuse-c"/"abuse-mailbox"

Con el objetivo de simplificar el proceso, garantizar su funcionalidad, y permitir que los "helpdesk" que atienden los reportes de abuso puedan validar que efectivamente las peticiones de validación provienen de LACNIC y no te de terceras fuentes (que pudieran implicar riesgos de seguridad), se establece el siguiente procedimiento para la 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.

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, al menos 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 "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".

New text
Analyze diff

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 y monitorizado, 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. Procedimiento de validación del "abuse-c"/"abuse-mailbox"

Con el objetivo de simplificar el proceso, garantizar su funcionalidad, y permitir que los "helpdesk" que atienden los reportes de abuso puedan validar que efectivamente las peticiones de validación provienen de LACNIC y no te de terceras fuentes (que pudieran implicar riesgos de seguridad), se establece el siguiente procedimiento para la 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.

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, al menos 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 "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

En RIPE se está tramitando una propuesta similar, aunque aún está en debate y no ha alcanzado consenso.

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

-

Presented at:

-


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 (Describe the problem you intend to solve)

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

Current 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".

New text
Analyze diff

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

Presented at:

LACNIC 30 (24/09/2018)
LACNIC 29 (30/04/2018)


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 (Describe the problem you intend to solve)

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

Current 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”.

New text
Analyze diff

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.

Presented at:

-


Summary

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.

Rationale (Describe the problem you intend to solve)

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

Current 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, 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.

New text
Analyze diff

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.

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

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

References

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.

Presented at:

-


Summary

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.

Rationale (Describe the problem you intend to solve)

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

Current 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 que utilicen los sistemas de registro de LACNIC deben incluir obligatoriamente, en las entradas de WHOIS correspondientes, 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. Habitualmente, cabe esperar que, si se ha asignado un número de ticket, el mismo sea mantenido en todas las comunicaciones (típicamente como parte del asunto).

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 resto de los contactos disponibles, 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 recomendación, 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.

12.5. De los incumplimientos

El incumplimiento por parte de cualquier organización se produce si no se ha validado en el plazo “inicial” ni “adicional”. Ello 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 (o sistemas equivalentes de los NIRs), 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. Se podrán utilizar mecanismos equivalentes adaptados al avance de la tecnología.

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


12.6. Mecanismo de escalado a LACNIC

Comportamientos fraudulentos (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), podrán ser reportados a LACNIC, para su re-validación según 12.4.

New text
Analyze diff

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 que utilicen los sistemas de registro de LACNIC deben incluir obligatoriamente, en las entradas de WHOIS correspondientes, 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. Habitualmente, cabe esperar que, si se ha asignado un número de ticket, el mismo sea mantenido en todas las comunicaciones (típicamente como parte del asunto).

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 resto de los contactos disponibles, 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 recomendación, 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.

12.5. De los incumplimientos

El incumplimiento por parte de cualquier organización se produce si no se ha validado en el plazo “inicial” ni “adicional”. Ello 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 (o sistemas equivalentes de los NIRs), 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. Se podrán utilizar mecanismos equivalentes adaptados al avance de la tecnología.

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


12.6. Mecanismo de escalado a LACNIC

Comportamientos fraudulentos (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), podrán ser reportados a LACNIC, para su re-validación según 12.4.

Additional information

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.

El texto siguiente es un ejemplo de procedimiento de validación, considerando prácticas habituales en los “helpdesk” (mesas de ayuda), que por ejemplo impiden clicar en un enlace html de un email, para evitar casos de phishing u otros. Aun cuando este texto no es parte del texto de la política, se recomienda su estricta consideración, dado que es resultado de discusiones relacionadas con políticas de abuse-c en la comunidad global.

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) 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 de forma mas eficaz.
4) 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.
5) El segundo de los emails contendrá un código alfanumérico único de validación.
6) 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.
7) 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.
8) El código alfanumérico sólo será válido durante un máximo de 15 días.
9) 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.
10) 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, el “abuse-c” será marcado de forma permanente como “inválido”.
11) 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.
12) LACNIC contará con mecanismos (formulario, correo electrónico y otros en el futuro) para facilitar el escalado en los casos en los que se quiera reportar un incumplimiento de esta política. Ello permitirá la re-validación (12.4) y la intervención de LACNIC en aplicación de las políticas, procedimientos y requisitos contractuales vigentes.

Timetable

-

References

-

Presented at:

LACNIC 31 (06/05/2019)


Summary

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.

Rationale (Describe the problem you intend to solve)

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

Current 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 que utilicen los sistemas de registro de LACNIC deben incluir obligatoriamente, en las entradas de WHOIS correspondientes, 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), están 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. Acerca del “abuse-mailbox”

El “abuse-mailbox” tiene las siguientes características:
• Requiere intervención por parte del destinatario.
• No debe exigir el uso de un formulario para reportar un abuso.
• Debe garantizar que los reportes de abuso, logs, cabeceras, ejemplos, etc., relativos al caso de abuso, sean recibidos.

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 el cumplimiento de su propósito.
2) 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.
3) Plazo de validación “inicial” de 15 días.
4) Si no se valida correctamente, escalado, por cualquier medio posible, con el resto de los contactos disponibles, en un plazo “adicional” de 15 días.

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

El incumplimiento por parte de cualquier organización se produce si no se ha validado en el plazo “inicial” ni “adicional”.

12.5. Mecanismo de escalado a LACNIC

Comportamientos fraudulentos (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), podrán ser reportados a LACNIC, para su re-validación según 12.4.

New text
Analyze diff

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 que utilicen los sistemas de registro de LACNIC deben incluir obligatoriamente, en las entradas de WHOIS correspondientes, 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), están 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. Acerca del “abuse-mailbox”

El “abuse-mailbox” tiene las siguientes características:
• Requiere intervención por parte del destinatario.
• No debe exigir el uso de un formulario para reportar un abuso.
• Debe garantizar que los reportes de abuso, logs, cabeceras, ejemplos, etc., relativos al caso de abuso, sean recibidos.

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 el cumplimiento de su propósito.
2) 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.
3) Plazo de validación “inicial” de 15 días.
4) Si no se valida correctamente, escalado, por cualquier medio posible, con el resto de los contactos disponibles, en un plazo “adicional” de 15 días.

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

El incumplimiento por parte de cualquier organización se produce si no se ha validado en el plazo “inicial” ni “adicional”.

12.5. Mecanismo de escalado a LACNIC

Comportamientos fraudulentos (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), podrán ser reportados a LACNIC, para su re-validación según 12.4.

Additional information

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.

Los plazos de validación “inicial” y “escalado”, pueden ser modificados por LACNIC, si se considera apropiado, siempre y cuando se informe a la comunidad acerca de los motivos para dicho cambio. Por ejemplo, en la fase inicial de la implementación, estos períodos podrían extenderse y ajustarse progresivamente según un mayor porcentaje de contactos son verificados.

De forma similar, la frecuencia de la validación periódica, puede ser modificada por LACNIC, si lo considera necesario, informando también a la comunidad acerca de los motivos. Por ejemplo, el primer año se podría realizar una sola validación para facilitar el cumplimiento de la política, y el número de validaciones incrementarse progresivamente, quizás incluso trimestralmente, con el objetivo de mejorar la calidad de los contactos.

El texto siguiente es un ejemplo de procedimiento de validación, considerando prácticas habituales en los “helpdesk” (mesas de ayuda), que por ejemplo impiden clicar en un enlace html de un email, para evitar casos de phishing u otros. Aun cuando este texto no es parte del texto de la política, se recomienda su estricta consideración, dado que es resultado de discusiones relacionadas con políticas de abuse-c en la comunidad global.
(ver version anterior, el formulario limita el número de caracteres)

Timetable

-

References

-

Presented at:

LACNIC 32 (06/10/2019)

--> --> --> --> --> -->