LAC-2018-5: Registration and validation of abuse contact

General Information

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

Jordi Palet Martinez - Version [1, 2, 3, 4, 5, 6]
Initial discussion
05/03/2018
Last call for comments
09/12/2019 - 06/01/2019
Ratification by the Board
13/01/2020
Ratified
27/02/2020
Implemented
27/05/2021

Public Comments by LACNIC Staff for this version

LACNIC Staff's Interpretation of the Proposal
---------------------------------------------

Applicability
------------
This proposal applies to organizations receiving resources from LACNIC, who would need to register a valid abuse contact for ASNs, IPv4 and IPv6 addresses.

Modifications to the current text
--------------------------------
Current Section “12. Appendixes” becomes section “A. Appendixes,” located at the end of the Policy Manual. All references are updated as applicable.

The following sections are added:
- 12. Registration and validation of “abuse-c” and “abuse-mailbox”
- 12.1 Description of “abuse-c” and “abuse-mailbox”
- 12.2. About the “abuse-mailbox”
- 12.3. Purpose of “abuse-c”/ “abuse-mailbox” validation
- 12.4. Validation of “abuse-c”/“abuse-mailbox”
- 12.5. Escalation to LACNIC

This new version of the policy proposal:

- Summarizes and reduces the length of Section “12.2. About the “abuse-mailbox” where it describes the characteristics required for an abuse-mailbox.
- Eliminates the section titled “Failure to comply” and adds Subsection 12.4. Validation of “abuse-mailbox”, ‘Failure of an organization to comply with this section occurs if it has not been validated during the “initial” or the “additional” validation periods.’

LACNIC Staff Comments
-------------------------
(Comments are observations to help differentiate the changes presented by the proposal with respect to the current text of the Policy Manual)

1. LACNIC interprets that the proposed periods might be modified as LACNIC sees fit for their better implementation, both the initial validation and the escalation periods as well as the frequency of the periodic validations.

2. LACNIC understands that the purpose of the proposal is not to revoke resources when any type of evidence is discovered, but only in case of repeated and significant breaches of the policies. LACNIC will proceed to revoke resources only as a last resort.

It is important to keep in mind that resource revocation is a complex and permanent process that has a significant impact on the operation of an organization. Therefore, we recommend that resources be revoked only once all other measures have been exhausted and a significant period of time after detecting the failure to comply.

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

4. While the Policy Manual does not specify that each IPv4 block must include an abuse contact, LACNIC's system already supports this format and IPv4 and IPv6 blocks as well as ASNs already include this attribute. The same is true in the case of sub-assignments: abuse-c is the administrative contact of the organization that receives the assignment or sub-assignment.
A LACNIC database was queried for the abuse contacts registered for each type of resource. The following results were obtained:
- Number of IPv4, IPv6, and ASN resources with null or blank abuse contacts: 0
- Number of legacy IPv4 resources with null or blank abuse contacts: 241
- Number of legacy IPv6 resources with null or blank abuse contacts: 0
- Number of legacy ASN resources with null or blank abuse contacts: 146

This means that currently, only legacy resources have a blank/null abuse contact in the database. Any resources that appear in the database with a null or blank abuse contact are legacy resources. LACNIC does not validate such contacts.

5. LACNIC understands that this does not apply to organizations holding legacy resources. While these organizations are also included in the LACNIC database, many do not have any valid contact information (e-mail address, telephone number) nor a contractual obligation to update such information given the date on which they were assigned (prior to 1997). Likewise, organizations holding legacy resources are not required to abide by LACNIC policies, which means that this policy would not apply to such organizations.

6. As for the following text: “Considering the hierarchical nature of the objects, child objects of those directly distributed by LACNIC (for example, sub-assignments) are covered by the parent objects and their own “abuse-c” attribute is optional,”
LACNIC understands this to mean that, in the case of address sub-assignments, the “abuse-c” contact may be covered either by that of the parent organization or by that of its own organization. Therefore, LACNIC interprets that sub-assignments would not be verified.

7. As for item 5) of Section 12.3, LACNIC understands that the validation error would be escalated to the other contacts of the organization.

Recommendations
-------------------
8. We recommend not specifying a specific timeline, but instead defining the necessary actions and allowing the corresponding timeline to be defined based on operational considerations.

Impact of the policy on the registration system
-----------------------------------------------
This proposal would involve developing a procedure to automatically monitor abuse-c and abuse-mailbox.
It would also involve developing a system for the portals of the NIRs and LACNIC.

Official Sources
----------------

Policies in force in the other RIRs
----------------------------------
- RIPE
A policy titled Abuse Contact Management in the RIPE Database is currently in its implementation stage: https://www.ripe.net/publications/docs/ripe-705
However, this policy is more flexible: validation is performed on an annual basis and the validation procedure is simpler, as RIPE only checks that a domain exists and that an email server has been configured.

- APNIC
A policy similar to the one under discussion in the LACNIC region achieved consensus during the past APNIC event and is already in its implementation stage.
https://www.apnic.net/wp-content/uploads/2018/08/prop-125-v001.txt

- ARIN: According to Section 3.6: https://www.arin.net/participate/policy/nrpm/#3-6-annual-validation-of-arin-s-public-whois-point-of-contact-data
ARIN currently uses the following validation procedure: an email notification is sent to each of the points of contact on an annual basis. Each point of contact has up to 60 days in which to respond with an affirmative that their contact information is correct and up to date. If the point of contact does not reply within 60 days, it is marked as invalid in the database. Until the point of contact is updated, these users have limited access to the functionality within ARIN Online.
In addition, a proposal similar to the one under discussion in the LACNIC region has been submitted and will be presented at the ARIN event to be held in April: https://www.arin.net/participate/policy/drafts/2019_5/

- AFRINIC
A proposal similar to the one submitted in the LACNIC region has been under discussion since November 2018. This proposal was presented at the latest AFRINIC event and was sent back for further discussion.
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

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

-


Summary

The current (ASN) policy is not clear regarding the obligation to register an abuse contact (abuse-c) or its specific format, nor as to whether this applies to other whois records.

As a result, some LIRs may not have this contact information registered for their resources. In fact, there are even cases of LIRs that use a non-existent mailbox or one that is not actively monitored.

In practice, this contact becomes ineffective to report abuses and generally gives rise to security issues and costs for the victims.

This proposal aims to solve the problem and ensure the existence of a proper abuse-c contact and the process for its utilization.

Rationale

The Internet community is based on collaboration. In many cases, however, this is not enough and we all need to be able to contact those LIRs which may be experiencing a problem in their networks and may not be aware of the situation.

This proposal creates a new section in the Policy Manual to solve this problem by means of a simple, periodic verification, and establishes the basic rules for performing such verification and thus avoids unnecessary costs to third parties who need to contact the persons responsible for solving the abuses of a specific network.

The proposal guarantees that the cost of processing the abuse falls on the LIR whose client is causing the abuse (and from whom they receive financial compensation for the service), instead of falling on the victim, as would be the case if they had to resort to the courts, thus avoiding costs (lawyers, solicitors, etc.) and saving time for both parties.

For this, the abuse-c attribute – which has so far only been referenced for the "aut-num" object – becomes mandatory in the "inetnum" and "inetnum6" objects, as well as in any others that may be used in the future. This attribute is an abuse contact, which must contain at least the "abuse-mailbox" attribute.

Current Text

Current text: N/A

New text:

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

12.1. Description of "abuse-c" and "abuse-mailbox"
All resources allocated by LACNIC must include a mandatory "abuse-c" contact attribute (abuse contact) in their corresponding WHOIS entry, with at least one valid, monitored and actively managed email inbox (abuse-mailbox) intended for receiving manual or automatic reports regarding abusive behavior, security issues, and the like.

The "abuse-mailbox" attribute must be available in an unrestricted way via whois, APIs and future techniques.

Considering the hierarchical nature of IP address objects, child objects of those directly distributed by LACNIC may be covered by parent objects or they may have their own "abuse-c" attribute.

Following usual practices, other "e-mail" attributes may be included for other purposes.

12.2. About the "abuse-mailbox"

Emails sent to "abuse-mailbox" must require manual intervention by the recipient at some time, and may not be filtered, as in certain cases this might prevent the reception of the abuse reports, for example a case of spam, as it would include the spam message itself or URLs or content usually classified as spam.

The "abuse-mailbox" may initially send an automatic reply, for example, assigning a ticket number, applying classification procedures, requesting further information, etc. However, it may not require the use of a form, as this would imply that each company that needs to report cases of abuse (a task that is typically automated) would be forced to develop a specific interface for each case, which is neither feasible nor logical, as it would place the cost of processing the abuse on those who submit the claim and are therefore victims of the abuse, instead of being paid by the those whose client causes the abuse (and from whom they obtain income).

By way of information, it is worth noting that it is reasonable for the person reporting the abuse to do so from the start and in that first report, sending the logs, or a copy of the spam message (attaching an example of the spam email or its full headers) or similar evidence proving the abuse. Likewise, it is reasonable to expect that the initial auto-reply email will specify that the claim will not be processed unless such evidence has been submitted, thus allowing the sender the opportunity to repeat the submission and include the pertinent evidence. This allows automatic reporting, for example, via fail2ban, SpamCop or others, keeping costs at a minimum for both parties involved.

12.3. Objectives of "abuse-c"/"abuse-mailbox" validation

The procedure, which is to be developed by LACNIC, must meet the following objectives:

1) A simple process that guarantees its functionality and allows the helpdesks that deals with abuse reports to verify that validation requests actually come from LACNIC and not from third parties (which might involve security risks), avoiding, for example, a single "direct" URL for validation.

2) Avoid automated processing.

3) Confirm that the person performing the validation ensure that understands the procedure and the policy, that they regularly monitor the "abuse-mailbox", that measures are taken, and that the abuse report receives a response.

4) Validation period no longer than two (2) business days.

5) If validation fails, escalate to the LIR and set a new validation period not to exceed three (3) business days.

(By way of example, a detailed procedure is included in this policy proposal under "Additional Information")

12.4. Validation of "abuse-c"/"abuse-mailbox"

LACNIC will validate compliance with the items above, both when the "abuse-c" and/or "abuse-mailbox" attributes are created or updated, as well as periodically, not less than once every three months, and whenever LACNIC sees fit.

At the discretion of LACNIC, in general or in specific cases (for example, for confirmation in cases of escalation under 12.5), LACNIC may use domains other than lacnic.*, and even modify the subject and body of the message, in order to perform said validations more effectively.

Lack of compliance will imply a more exhaustive follow-up, in accordance with the relevant LACNIC policies / procedures, especially "7.1. Resource recovery.”

12.5. Escalation to LACNIC

To avoid fraudulent behavior (for example, an "abuse-mailbox" that only replies to LACNIC's emails, or to messages with a specific subject or content), or failure to comply with the remaining aspects of this policy (incorrect or lack of response to cases of abuse) and, therefore, to guarantee the quality of the services in the region with the resources allocated by LACNIC, a mailbox will be available (for example, "escalado-abusos@lacnic.net"), to escalate such situations, thus allowing for a re-validation (according to section 12.4 above) and even the intermediation by LACNIC and, where appropriate, the application of the relevant policies/procedures, especially “7.1. Resource recovery.”

New Text
Analyze Diff

Current text: N/A

New text:

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

12.1. Description of "abuse-c" and "abuse-mailbox"
All resources allocated by LACNIC must include a mandatory "abuse-c" contact attribute (abuse contact) in their corresponding WHOIS entry, with at least one valid, monitored and actively managed email inbox (abuse-mailbox) intended for receiving manual or automatic reports regarding abusive behavior, security issues, and the like.

The "abuse-mailbox" attribute must be available in an unrestricted way via whois, APIs and future techniques.

Considering the hierarchical nature of IP address objects, child objects of those directly distributed by LACNIC may be covered by parent objects or they may have their own "abuse-c" attribute.

Following usual practices, other "e-mail" attributes may be included for other purposes.

12.2. About the "abuse-mailbox"

Emails sent to "abuse-mailbox" must require manual intervention by the recipient at some time, and may not be filtered, as in certain cases this might prevent the reception of the abuse reports, for example a case of spam, as it would include the spam message itself or URLs or content usually classified as spam.

The "abuse-mailbox" may initially send an automatic reply, for example, assigning a ticket number, applying classification procedures, requesting further information, etc. However, it may not require the use of a form, as this would imply that each company that needs to report cases of abuse (a task that is typically automated) would be forced to develop a specific interface for each case, which is neither feasible nor logical, as it would place the cost of processing the abuse on those who submit the claim and are therefore victims of the abuse, instead of being paid by the those whose client causes the abuse (and from whom they obtain income).

By way of information, it is worth noting that it is reasonable for the person reporting the abuse to do so from the start and in that first report, sending the logs, or a copy of the spam message (attaching an example of the spam email or its full headers) or similar evidence proving the abuse. Likewise, it is reasonable to expect that the initial auto-reply email will specify that the claim will not be processed unless such evidence has been submitted, thus allowing the sender the opportunity to repeat the submission and include the pertinent evidence. This allows automatic reporting, for example, via fail2ban, SpamCop or others, keeping costs at a minimum for both parties involved.

12.3. Objectives of "abuse-c"/"abuse-mailbox" validation

The procedure, which is to be developed by LACNIC, must meet the following objectives:

1) A simple process that guarantees its functionality and allows the helpdesks that deals with abuse reports to verify that validation requests actually come from LACNIC and not from third parties (which might involve security risks), avoiding, for example, a single "direct" URL for validation.

2) Avoid automated processing.

3) Confirm that the person performing the validation ensure that understands the procedure and the policy, that they regularly monitor the "abuse-mailbox", that measures are taken, and that the abuse report receives a response.

4) Validation period no longer than two (2) business days.

5) If validation fails, escalate to the LIR and set a new validation period not to exceed three (3) business days.

(By way of example, a detailed procedure is included in this policy proposal under "Additional Information")

12.4. Validation of "abuse-c"/"abuse-mailbox"

LACNIC will validate compliance with the items above, both when the "abuse-c" and/or "abuse-mailbox" attributes are created or updated, as well as periodically, not less than once every three months, and whenever LACNIC sees fit.

At the discretion of LACNIC, in general or in specific cases (for example, for confirmation in cases of escalation under 12.5), LACNIC may use domains other than lacnic.*, and even modify the subject and body of the message, in order to perform said validations more effectively.

Lack of compliance will imply a more exhaustive follow-up, in accordance with the relevant LACNIC policies / procedures, especially "7.1. Resource recovery.”

12.5. Escalation to LACNIC

To avoid fraudulent behavior (for example, an "abuse-mailbox" that only replies to LACNIC's emails, or to messages with a specific subject or content), or failure to comply with the remaining aspects of this policy (incorrect or lack of response to cases of abuse) and, therefore, to guarantee the quality of the services in the region with the resources allocated by LACNIC, a mailbox will be available (for example, "escalado-abusos@lacnic.net"), to escalate such situations, thus allowing for a re-validation (according to section 12.4 above) and even the intermediation by LACNIC and, where appropriate, the application of the relevant policies/procedures, especially “7.1. Resource recovery.”

Additional Information

Example of the validation procedure.

1) LACNIC initiates the validation automatically, sending TWO consecutive emails to the "abuse-mailbox".

2) These emails will be sent containing plain text only.

3) The first email will contain the URL where the validation is to be performed ("validacion.lacnic.net") and may contain information about the procedure, a brief summary of this policy, etc.

4) The second email will contain a unique alphanumeric validation code.

5) The person in charge of the "abuse-mailbox" must go to the URL and paste the code received in the second email in the form.

6) This URL must be designed in such a way that it prevents the use of an automated process (for example, "captcha"). In addition, it must contain a text that confirms that the person performing the validation understands the procedure and the policy, that they regularly monitor the "abuse-mailbox", that measures are taken to solve reported cases of abuse, and that the abuse report receives a response, with a "checkbox" that must be accepted in order to proceed.

7) The alphanumeric code will only be valid for a maximum of two working days.

8) If the code is not entered within that time, the system will mark the "abuse-c" as "temporarily invalid” and will alert LACNIC staff so that they can initiate a personalized follow-up with the LIR.

9) If no reply is received confirming that the situation has been corrected, after an additional period of three business days, the "abuse-c" will be permanently marked as "invalid".

10) The validation process will be repeated automatically (items 1 to 7 above). If satisfactory, the "abuse-c" will be marked as "valid"; otherwise it will be considered in breach of the policy.

Timetable

90 days, to be confirmed by LACNIC, a reasonable time frame to allow both the staff to develop the tool and the LIRs to update their abuse-c contacts.

References

A similar proposal is under discussion in the RIPE region, though at the date on which this proposal was submitted it had not yet reached consensus.


Summary

The current (ASN) policy is not clear regarding the obligation to register an abuse contact (abuse-c) or its specific format, nor as to whether this applies to other whois records.

As a result, some organizations that have received resources from LACNIC may not have this contact information registered for their resources. There are even cases of LIRs/ISPs, end users or others that use a non-existent mailbox or one that is not actively monitored.

In practice, this contact becomes ineffective to report abuses and generally gives rise to security issues and costs for the victims.

This proposal aims to solve the problem by ensuring the existence of a proper abuse-c contact and a process for its utilization.

Rationale

The Internet community is based on collaboration. In many cases, however, this is not enough and we need to be able to contact those LIRs or other recipients of LACNIC resources that may be experiencing a problem in their networks but may not be aware of the situation.

This proposal creates a new section in the Policy Manual to solve this problem by means of a simple, periodic verification, and establishes the basic rules for performing such verification and thus avoids unnecessary costs to third parties who need to contact the persons responsible for solving the abuses of a specific network.

The proposal guarantees that the cost of processing the abuse falls on the LIR whose client is causing the abuse (and from whom they receive financial compensation for the service), instead of falling on the victim, as would be the case if they had to resort to the courts, thus avoiding costs (lawyers, solicitors, etc.) and saving time for both parties.

In this case, the abuse-c attribute – which has so far only been referenced for the “aut-num” object – becomes mandatory in the “inetnum” objects (for both IPv4 and IPv6), as well as in any others that may be used in the future. This attribute is an abuse contact, which must contain at least the “abuse-mailbox” attribute.

Current Text

Current text: N/A

New text:

Note (not to be included in the Policy Manual): Current Section “12. Appendixes” would now be Section “A. Appendixes” and located at the end of the Manual. The entire Policy Manual would be updated to reflect this change of numbering. As the Manual “grows,” any new section added would not require any renumbering. Therefore, the text of this proposal would become Section 12.

12. Registration and validation of “abuse-c” and “abuse-mailbox”.

12.1. Description of “abuse-c” and “abuse-mailbox”
All resources allocated by LACNIC must include a mandatory “abuse-c” contact attribute (abuse contact) in their corresponding WHOIS entry, with at least one valid, monitored and actively managed email inbox (abuse-mailbox) intended for receiving manual or automatic reports regarding abusive behavior, security issues, and the like.

The “abuse-mailbox” attribute must be available in an unrestricted way via whois, APIs and future techniques.

Considering the hierarchical nature of IP address objects, child objects of those directly distributed by LACNIC may be covered by parent objects, or they may have their own “abuse-c” attribute.

Following usual practices, other “e-mail” attributes may be included for other purposes.

12.2. About the “abuse-mailbox”

Emails sent to “abuse-mailbox” must require manual intervention by the recipient at some time, and may not be filtered, as in certain cases this might prevent the reception of abuse reports, e.g. in case of spam, where the message would include the spam message itself or URLs or content usually classified as spam.

The “abuse-mailbox” may initially send an automatic reply, for example, assigning a ticket number, applying classification procedures, requesting further information, etc. However, it may not require the use of a form, as this would imply that each company that needs to report cases of abuse (a task that is typically automated) would be forced to develop a specific interface for each case, which is neither feasible or logical, as it would place the cost of processing abuses on those who submit the claims and are therefore their victims, instead of being paid by the those whose client causes the abuse (and from whom they obtain income).

By way of information, it is worth noting that it is reasonable for the person reporting the abuse to do so from the start, sending in that first report the logs, or a copy of the spam message (attaching an example of the spam email or its full headers) or similar evidence proving the abuse. Likewise, it is reasonable to expect that the initial auto-reply email will specify that the claim will not be processed unless such evidence has been submitted, thus allowing the sender the opportunity to repeat the submission and include the pertinent evidence. This allows automatic reporting, for example, via fail2ban, SpamCop or other reporting services, keeping costs at a minimum for both parties involved.

12.3. Objectives of “abuse-c”/”abuse-mailbox” validation

The procedure, which is to be developed by LACNIC, must meet the following objectives:

1) A simple process that guarantees its functionality and allows the helpdesks that deals with abuse reports to verify that validation requests actually come from LACNIC and not from third parties (which might involve security risks), avoiding, for example, a single “direct” URL for validation.
2) Avoid automated processing.
3) Confirm that the person performing the validation understands the procedure and the policy, that they regularly monitor the “abuse-mailbox”, that measures are taken, and that the abuse report receives a response.
4) “Initial” validation period not to exceed fifteen (15) days.
5) If validation fails, “escalate” to the recipient of the resources (LIR, end user, etc.) and set a new validation period not to exceed fifteen (15) days.

LACNIC may modify the “initial” and “escalated” validation periods if it sees fit, informing the community of the reasons for doing so. For instance, these periods might be shortened once the initial validation of a high percentage of contacts has been completed, in which case the quality of the contacts would increase and response times in case of abuse would decrease.

(By way of example, a detailed procedure is included in this policy proposal under “Additional Information”)

12.4. Validation of “abuse-c”/”abuse-mailbox”
LACNIC will validate compliance with the items above, both when the “abuse-c” and/or “abuse-mailbox” attributes are created or updated, as well as periodically, not less than twice a year and whenever LACNIC sees fit.

This validation frequency may be modified by LACNIC if it sees fit, informing the community of the reasons for doing so. For instance, a single validation might be carried out during the first year to make it easier to adapt to the policy, after which the number of annual validations might gradually increase, perhaps even to a quarterly or monthly frequency, to increase the quality of the contact information.

At the discretion of LACNIC, in general or in specific cases (for example, for confirmation in case of escalation under 12.5), LACNIC may use domains other than lacnic.*, and even modify the subject and body of the message, in order to perform said validations more effectively.

Should an organization fail to comply, this will initially result in the blocking of “milacnic” for all the resources associated with said organization, except for the purpose of updating the abuse-c/abuse-mailbox contacts, so that they can be re-validated to allow the unblocking of “milacnic”.

LACNIC will perform a more exhaustive follow-up and, if the following automatic validation confirms that the non-compliance continues, will act in accordance with the relevant policies and procedures in force, especially “7.1. Resource recovery.”

12.5. Escalation to LACNIC

To avoid fraudulent behavior (for example, an “abuse-mailbox” that only replies to LACNIC's emails, or to messages with a specific subject or content) or failure to comply with the remaining aspects of this policy (incorrect or lack of response to case of abuse) and, therefore, to guarantee the quality of the services in the region with the resources allocated by LACNIC, a mailbox will be available (for example, “escalado-abusos@lacnic.net”) to escalate such situations, thus allowing LACNIC to trigger re-validation according to section 12.4 above or even intermediation by LACNIC and, where appropriate, the application of the relevant policies/procedures, especially “7.1. Resource recovery.”

New Text
Analyze Diff

Current text: N/A

New text:

Note (not to be included in the Policy Manual): Current Section “12. Appendixes” would now be Section “A. Appendixes” and located at the end of the Manual. The entire Policy Manual would be updated to reflect this change of numbering. As the Manual “grows,” any new section added would not require any renumbering. Therefore, the text of this proposal would become Section 12.

12. Registration and validation of “abuse-c” and “abuse-mailbox”.

12.1. Description of “abuse-c” and “abuse-mailbox”
All resources allocated by LACNIC must include a mandatory “abuse-c” contact attribute (abuse contact) in their corresponding WHOIS entry, with at least one valid, monitored and actively managed email inbox (abuse-mailbox) intended for receiving manual or automatic reports regarding abusive behavior, security issues, and the like.

The “abuse-mailbox” attribute must be available in an unrestricted way via whois, APIs and future techniques.

Considering the hierarchical nature of IP address objects, child objects of those directly distributed by LACNIC may be covered by parent objects, or they may have their own “abuse-c” attribute.

Following usual practices, other “e-mail” attributes may be included for other purposes.

12.2. About the “abuse-mailbox”

Emails sent to “abuse-mailbox” must require manual intervention by the recipient at some time, and may not be filtered, as in certain cases this might prevent the reception of abuse reports, e.g. in case of spam, where the message would include the spam message itself or URLs or content usually classified as spam.

The “abuse-mailbox” may initially send an automatic reply, for example, assigning a ticket number, applying classification procedures, requesting further information, etc. However, it may not require the use of a form, as this would imply that each company that needs to report cases of abuse (a task that is typically automated) would be forced to develop a specific interface for each case, which is neither feasible or logical, as it would place the cost of processing abuses on those who submit the claims and are therefore their victims, instead of being paid by the those whose client causes the abuse (and from whom they obtain income).

By way of information, it is worth noting that it is reasonable for the person reporting the abuse to do so from the start, sending in that first report the logs, or a copy of the spam message (attaching an example of the spam email or its full headers) or similar evidence proving the abuse. Likewise, it is reasonable to expect that the initial auto-reply email will specify that the claim will not be processed unless such evidence has been submitted, thus allowing the sender the opportunity to repeat the submission and include the pertinent evidence. This allows automatic reporting, for example, via fail2ban, SpamCop or other reporting services, keeping costs at a minimum for both parties involved.

12.3. Objectives of “abuse-c”/”abuse-mailbox” validation

The procedure, which is to be developed by LACNIC, must meet the following objectives:

1) A simple process that guarantees its functionality and allows the helpdesks that deals with abuse reports to verify that validation requests actually come from LACNIC and not from third parties (which might involve security risks), avoiding, for example, a single “direct” URL for validation.
2) Avoid automated processing.
3) Confirm that the person performing the validation understands the procedure and the policy, that they regularly monitor the “abuse-mailbox”, that measures are taken, and that the abuse report receives a response.
4) “Initial” validation period not to exceed fifteen (15) days.
5) If validation fails, “escalate” to the recipient of the resources (LIR, end user, etc.) and set a new validation period not to exceed fifteen (15) days.

LACNIC may modify the “initial” and “escalated” validation periods if it sees fit, informing the community of the reasons for doing so. For instance, these periods might be shortened once the initial validation of a high percentage of contacts has been completed, in which case the quality of the contacts would increase and response times in case of abuse would decrease.

(By way of example, a detailed procedure is included in this policy proposal under “Additional Information”)

12.4. Validation of “abuse-c”/”abuse-mailbox”
LACNIC will validate compliance with the items above, both when the “abuse-c” and/or “abuse-mailbox” attributes are created or updated, as well as periodically, not less than twice a year and whenever LACNIC sees fit.

This validation frequency may be modified by LACNIC if it sees fit, informing the community of the reasons for doing so. For instance, a single validation might be carried out during the first year to make it easier to adapt to the policy, after which the number of annual validations might gradually increase, perhaps even to a quarterly or monthly frequency, to increase the quality of the contact information.

At the discretion of LACNIC, in general or in specific cases (for example, for confirmation in case of escalation under 12.5), LACNIC may use domains other than lacnic.*, and even modify the subject and body of the message, in order to perform said validations more effectively.

Should an organization fail to comply, this will initially result in the blocking of “milacnic” for all the resources associated with said organization, except for the purpose of updating the abuse-c/abuse-mailbox contacts, so that they can be re-validated to allow the unblocking of “milacnic”.

LACNIC will perform a more exhaustive follow-up and, if the following automatic validation confirms that the non-compliance continues, will act in accordance with the relevant policies and procedures in force, especially “7.1. Resource recovery.”

12.5. Escalation to LACNIC

To avoid fraudulent behavior (for example, an “abuse-mailbox” that only replies to LACNIC's emails, or to messages with a specific subject or content) or failure to comply with the remaining aspects of this policy (incorrect or lack of response to case of abuse) and, therefore, to guarantee the quality of the services in the region with the resources allocated by LACNIC, a mailbox will be available (for example, “escalado-abusos@lacnic.net”) to escalate such situations, thus allowing LACNIC to trigger re-validation according to section 12.4 above or even intermediation by LACNIC and, where appropriate, the application of the relevant policies/procedures, especially “7.1. Resource recovery.”

Additional Information

Example of the validation procedure.
1) LACNIC automatically initiates the validation, sending TWO consecutive emails to the “abuse-mailbox”.
2) These emails will contain plain text only.
3) The first email will contain the URL where the validation is to be performed (“validacion.lacnic.net”) and may contain information about the procedure, a brief summary of this policy, etc.
4) The second email will contain a unique alphanumeric validation code.
5) The person in charge of the “abuse-mailbox” must go to the URL and enter the code received in the second email in the form.
6) This URL must be designed in such a way that it prevents the use of an automated process (for example, “captcha”).
In addition, it must contain a text that confirms that the person performing the validation understands the procedure and the policy, that they regularly monitor the “abuse-mailbox”, that measures are taken to solve reported cases of abuse, and that the abuse report receives a response, with a checkbox that must be accepted in order to proceed.
7) The alphanumeric code will be valid for a maximum of two (2) working days.
8) If the code is not entered within this time frame, the system will mark the “abuse-c” as “temporarily invalid” and will alert LACNIC staff so that they can initiate a personalized follow-up with the resource recipient.
9) If no reply is received confirming that the situation has been corrected, after an additional period of three (3) working days, the “abuse-c” will be permanently marked as “invalid”.
10) The validation process will be repeated automatically (items 1 to 7 above). If satisfactory, the “abuse-c” will be marked as “valid”; otherwise it will be considered in breach of the policy.

Timetable

Ninety (90) days, to be confirmed by LACNIC, to allow both the staff to develop the tool and the LIRs to update their abuse-c contacts.

References

A similar proposal is under discussion in the RIPE region, though at the date on which this proposal was submitted it had not yet reached consensus. It is a much simpler version, and a new version equivalent to this proposal has been presented. In APNIC, a version equivalent to this proposal has reached consensus. In AfriNIC the same proposal has been presented.


Summary

This proposal allows ensuring and validating an organization's WHOIS abuse contacts (abuse-c and abuse-mailbox) and therefore reporting and solving cases of abuse.

It aims to solve the problem by ensuring the existence of a proper abuse-c contact and a process for its utilization.

Rationale

The current (ASN) policy is not clear regarding the obligation to register an abuse contact (abuse-c) or its specific format, nor as to whether this applies to other WHOIS records.

As a result, some organizations that have received resources from LACNIC may not have this contact information on record
for their resources, and there are even cases of LIRs/ISPs, end users or others that use a non-existent email address or one that
is not actively monitored.

Because these contacts are not validated, cases of abuse cannot be effectively reported and this generates security issues and costs for the victims.

To solve this problem, a simple, periodic verification of abuse contacts is proposed that will avoid unnecessary costs to third parties.

The proposal guarantees that the cost of processing the abuses falls on the recipient of the resource who is responsible for the abuse, either directly or indirectly (through a customer, from whom they are possibly receiving financial compensation for the service), instead of falling on the victim. Bear in mind that this will keep the problem from escalating and will save time and legal costs for both parties involved if the matter is taken to court.

In this case, the abuse-c attribute —which has so far only been referenced for the “aut-num” object— becomes mandatory in the “inetnum” objects (for both IPv4 and IPv6), as well as in any others that may be used in the future. This attribute is an abuse contact, which must contain at least the “abuse-mailbox” attribute.

Current Text

Current text: N/A
---------
New text:

12. Registration and validation of “abuse-c” and “abuse-mailbox”

12.1. Description of “abuse-c” and “abuse-mailbox”
All resources that use LACNIC's registration systems must include a mandatory abuse-c contact attribute (abuse contact) in their corresponding WHOIS entries, with at least one valid, monitored and actively managed abuse-mailbox that allows sending manual or automatic reports regarding abusive behavior, security issues, and the like.

Unrestricted access to the “abuse-mailbox” attribute must be available via whois, APIs and future technologies.

Considering the hierarchical nature of the objects, child objects of those directly distributed by LACNIC (for example, sub-assignments) are covered by the parent objects and their own “abuse-c” attribute is optional.

Following usual practices, other “e-mail” attributes may be included for other purposes.

12.2. About the “abuse-mailbox”
Email messages sent to the “abuse-mailbox” must require manual intervention by the recipient at some time and may not be filtered, as in certain cases this might prevent the reception of abuse reports. For example, a spam report that includes the spam message itself or URLs or content typically classified as spam.

The “abuse-mailbox” may initially return an automatic reply, for example, assigning a ticket number, applying classification procedures, requesting further information, etc. However, it may not require the use of a form, as this would mean that each entity that needs to report cases of abuse (a task that is typically automated) would be forced to develop a specific interface for each resource recipient to which it must report an abuse. This would not be viable, as it would place the cost of processing the abuses on those who submit the claims and are therefore the victims of the abuse, not on those who (directly or indirectly) cause the abuse.

It is reasonable for the person reporting the abuse to submit sufficient information in the first report (logs, a copy of the spam message or its full headers, or equivalent information as applicable for each type of abuse). Likewise, it is reasonable for the initial auto-reply email to specify that the claim will not be processed unless such information has been submitted, thus offering the sender the opportunity to repeat the submission and include relevant evidence. This allows automatic reporting, for example, via fail2ban, SpamCop or other reporting services, keeping costs at a minimum for both parties involved. Usually, once a ticket number has been assigned, it is to be expected that the same number will be maintained in all communications (typically as part of the subject).

12.3. Purpose of “abuse-c”/”abuse-mailbox” validation
The procedure, which is to be developed by LACNIC, must meet the following objectives:

1) It must guarantee its functionality and allow the helpdesks that deal with the abuse reports to verify that the validation actually originated from LACNIC and not from other sources (involving security risks, avoiding, for example, a single “direct” URL for validation).
2) A fully automated process should be avoided.
3) It should confirm that the person performing the validation:
• understands the procedure and the LACNIC policies in force;
• regularly monitors the “abuse-mailbox”;
• takes measures in connection thereto;
• responds to the abuse report.
4) An “Initial” validation period of fifteen (15) days.
5) If this validation fails, “escalate” to the original recipient of the resources (LIR, end user, etc.) for an additional period of fifteen (15) days.

The validation periods may be modified at LACNIC's discretion, informing the community of the reasons for doing so.

(By way of recommendation, a detailed procedure is included in this policy proposal under “Additional Information”)

12.4. 12.4. Validation of “abuse-c”/”abuse-mailbox”
LACNIC will periodically validate compliance with the policy, at least twice a year and whenever “abuse-c” attributes are created or modified.

The validation frequency may be modified at LACNIC's discretion, informing the community of the reasons for doing so.

12.5. Failure to comply
Failure of an organization to comply occurs if it has not been validated during the “initial” or the “additional” validation periods. This will result in the blocking of MiLACNIC and equivalent measures in the systems of the NIRs for all the resources associated with the organization. Strictly contractual and payment-related matters will be excepted, as will the possibility of updating the abuse-c/abuse-mailbox contacts so that they may be automatically re-validated to allow MiLACNIC to be unblocked.

Any attempt to access MiLACNIC (or the equivalent systems of the NIRs) while it remains blocked will display a warning message including the text of this policy. Before the system allows the person to continue, this message must be “read” in full and confirmed by selecting a check-box or other similar mechanism. As technology evolves, other equivalent mechanisms may be used.

If the failure to comply continues, LACNIC will act in accordance with its relevant policies and procedures.

12.6. Escalation to LACNIC
Fraudulent behavior (for example, an “abuse-mailbox” that only replies to emails from LACNIC, to a specific subject or to a certain message body) or failure to comply with the remaining aspects of this policy (ignoring or incorrectly managing cases of abuse) may be reported to LACNIC for re-validation according to 12.4.

New Text
Analyze Diff

Current text: N/A
---------
New text:

12. Registration and validation of “abuse-c” and “abuse-mailbox”

12.1. Description of “abuse-c” and “abuse-mailbox”
All resources that use LACNIC's registration systems must include a mandatory abuse-c contact attribute (abuse contact) in their corresponding WHOIS entries, with at least one valid, monitored and actively managed abuse-mailbox that allows sending manual or automatic reports regarding abusive behavior, security issues, and the like.

Unrestricted access to the “abuse-mailbox” attribute must be available via whois, APIs and future technologies.

Considering the hierarchical nature of the objects, child objects of those directly distributed by LACNIC (for example, sub-assignments) are covered by the parent objects and their own “abuse-c” attribute is optional.

Following usual practices, other “e-mail” attributes may be included for other purposes.

12.2. About the “abuse-mailbox”
Email messages sent to the “abuse-mailbox” must require manual intervention by the recipient at some time and may not be filtered, as in certain cases this might prevent the reception of abuse reports. For example, a spam report that includes the spam message itself or URLs or content typically classified as spam.

The “abuse-mailbox” may initially return an automatic reply, for example, assigning a ticket number, applying classification procedures, requesting further information, etc. However, it may not require the use of a form, as this would mean that each entity that needs to report cases of abuse (a task that is typically automated) would be forced to develop a specific interface for each resource recipient to which it must report an abuse. This would not be viable, as it would place the cost of processing the abuses on those who submit the claims and are therefore the victims of the abuse, not on those who (directly or indirectly) cause the abuse.

It is reasonable for the person reporting the abuse to submit sufficient information in the first report (logs, a copy of the spam message or its full headers, or equivalent information as applicable for each type of abuse). Likewise, it is reasonable for the initial auto-reply email to specify that the claim will not be processed unless such information has been submitted, thus offering the sender the opportunity to repeat the submission and include relevant evidence. This allows automatic reporting, for example, via fail2ban, SpamCop or other reporting services, keeping costs at a minimum for both parties involved. Usually, once a ticket number has been assigned, it is to be expected that the same number will be maintained in all communications (typically as part of the subject).

12.3. Purpose of “abuse-c”/”abuse-mailbox” validation
The procedure, which is to be developed by LACNIC, must meet the following objectives:

1) It must guarantee its functionality and allow the helpdesks that deal with the abuse reports to verify that the validation actually originated from LACNIC and not from other sources (involving security risks, avoiding, for example, a single “direct” URL for validation).
2) A fully automated process should be avoided.
3) It should confirm that the person performing the validation:
• understands the procedure and the LACNIC policies in force;
• regularly monitors the “abuse-mailbox”;
• takes measures in connection thereto;
• responds to the abuse report.
4) An “Initial” validation period of fifteen (15) days.
5) If this validation fails, “escalate” to the original recipient of the resources (LIR, end user, etc.) for an additional period of fifteen (15) days.

The validation periods may be modified at LACNIC's discretion, informing the community of the reasons for doing so.

(By way of recommendation, a detailed procedure is included in this policy proposal under “Additional Information”)

12.4. 12.4. Validation of “abuse-c”/”abuse-mailbox”
LACNIC will periodically validate compliance with the policy, at least twice a year and whenever “abuse-c” attributes are created or modified.

The validation frequency may be modified at LACNIC's discretion, informing the community of the reasons for doing so.

12.5. Failure to comply
Failure of an organization to comply occurs if it has not been validated during the “initial” or the “additional” validation periods. This will result in the blocking of MiLACNIC and equivalent measures in the systems of the NIRs for all the resources associated with the organization. Strictly contractual and payment-related matters will be excepted, as will the possibility of updating the abuse-c/abuse-mailbox contacts so that they may be automatically re-validated to allow MiLACNIC to be unblocked.

Any attempt to access MiLACNIC (or the equivalent systems of the NIRs) while it remains blocked will display a warning message including the text of this policy. Before the system allows the person to continue, this message must be “read” in full and confirmed by selecting a check-box or other similar mechanism. As technology evolves, other equivalent mechanisms may be used.

If the failure to comply continues, LACNIC will act in accordance with its relevant policies and procedures.

12.6. Escalation to LACNIC
Fraudulent behavior (for example, an “abuse-mailbox” that only replies to emails from LACNIC, to a specific subject or to a certain message body) or failure to comply with the remaining aspects of this policy (ignoring or incorrectly managing cases of abuse) may be reported to LACNIC for re-validation according to 12.4.

Additional Information

Note (not to be included in the Policy Manual): Current Section “12. Appendixes” would now be Section “A. Appendixes” and located at the end of the Policy Manual and the entire Manual would be updated to reflect this change of numbering. Then, as the Manual continues to “grow,” any new section added would not require any renumbering. The text of this proposal would therefore be included in the Policy Manual as Section 12 or any other number deemed appropriate by the staff at the time of its implementation, once consensus has been reached.

The following text is an example of a validation procedure based on typical helpdesk practices which, for example, avoids clicking on an html link sent via email to prevent phishing or other malicious actions. While this text is not part of the text of the policy, we recommend its consideration, as is the result of the discussions on abuse-c policies that have taken place within the global community.

1) LACNIC automatically initiates the validation by sending TWO consecutive emails to the “abuse-mailbox”.
2) These emails will contain plain text only (thus hiding any URLs intended as phishing or other types of attacks).
3) At the discretion of LACNIC, in general or in specific cases (for example, for confirmation in cases of escalation under 12.6), LACNIC may use domains other than lacnic.* and even modify the subject and body of the message in order to increase the efficiency of said validations.
4) The first email will contain the URL where the validation is to be performed (“validacion.lacnic.net”) and may contain information about the procedure, a brief summary of this policy, etc.
5) The second email will contain a unique alphanumeric validation code.
6) The recipient responsible for the “abuse-mailbox” must go to the URL and paste the code they received in the second email in the corresponding form.
7) This URL must be designed in such a way that it prevents the use of an automated process (for example, “captcha”). In addition, it must contain a text that confirms that the person performing the validation understands the procedure and the policy, that they regularly monitor the “abuse-mailbox”, that appropriate measures are taken to solve reported cases of abuse, and that the abuse report receives a response, with a checkbox that must be accepted in order to proceed.
8) The alphanumeric code will be valid for a maximum of 15 days.
9) If the code is not entered within this period, the system will mark the “abuse-c” as “temporarily invalid” and will alert LACNIC staff so that they can initiate a personalized follow-up with the resource's recipient.
10) If no reply is received confirming that the situation has been corrected, after an additional period of 15 days, the “abuse-c” will be marked as permanently “invalid”.
11) The validation process will be repeated automatically (items 1 to 7 above). If satisfactory, the “abuse-c” will be marked as “valid”; otherwise, it will be considered in breach of the policy.
12) LACNIC will have mechanisms in place (a form, an email address and possibly others in the future) to facilitate the escalation in cases where reporting a breach of this policy is desired. This will allow re-validation (12.4) and LACNIC's intervention in applying the policies, procedures and contractual requirements in force.

Timetable

A reasonable time of ninety days, to be confirmed by LACNIC, to allow the staff to develop the tool and those who received LACNIC resources to update their abuse-c contacts. LACNIC may send a reminder along with notification of the proposal's ratification by the Board.

References

In APNIC, a version equivalent to this proposal has reached consensus.

In the RIPE region, a similar proposal was adopted, except that it only considers an automatic verification. Recent debates on the mailing list have shown the need for this verification to be “more than merely automatic,” as the current procedure allows for multiple forms of deception.

In addition, an equivalent proposal is being processed and will be published shortly.

Equivalent proposals have been submitted in AfriNIC and ARIN.


Summary

This proposal allows ensuring and validating an organization's WHOIS abuse contacts (abuse-c and abuse-mailbox) and thus reporting and solving cases of abuse.

It seeks to solve the problem by ensuring the existence of a proper abuse-c contact and a process for its utilization.

Rationale

The current (ASN) policy is not clear regarding the obligation to register an abuse contact (abuse-c) or its specific format, nor as to whether this applies to other WHOIS records.

As a result, some organizations that have received resources from LACNIC may not have this contact information on record for their resources, and there are even cases of LIRs/ISPs, end users or others that use a non-existent email address or one that is not actively monitored.

Because these contacts are not validated, cases of abuse cannot be effectively reported. This creates security issues and costs for the victims.

To solve this problem, a simple, periodic verification of abuse contacts is proposed that will avoid unnecessary costs to third parties.

The proposal guarantees that the cost of processing an abuse falls on the recipient of the resource who is responsible for the abuse, either directly or indirectly (through a customer, from whom they are possibly receiving financial compensation for the service), instead of falling on the victim. Bear in mind that this will keep the problem from escalating and will save time and legal costs for both parties involved if the matter is taken to court.

In this case, the abuse-c attribute —which has so far only been referenced for the “aut-num” object— becomes mandatory in the “inetnum” objects (for both IPv4 and IPv6), as well as in any others that may be used in the future. This attribute is an abuse contact, which must contain at least the “abuse-mailbox” attribute.

Current Text

Current text: N/A

New text:

12. Registration and validation of “abuse-c” and “abuse-mailbox”

12.1. Description of “abuse-c” and “abuse-mailbox”
All resources that use LACNIC's registration systems must include a mandatory abuse-c contact attribute (abuse contact) in their corresponding WHOIS entries, with at least one valid, monitored, and actively managed abuse-mailbox that allows sending manual or automatic reports regarding abusive behavior, security issues, and the like.

Unrestricted access to the “abuse-mailbox” attribute must be available via whois, APIs and future technologies.

Considering the hierarchical nature of the objects, child objects of those directly distributed by LACNIC (for example, sub-assignments) are covered by the parent objects and their own “abuse-c” attribute is optional.

Following usual practices, other “e-mail” attributes may be included for other purposes.

12.2. About the “abuse-mailbox”

Email messages sent to the “abuse-mailbox” must require manual intervention by the recipient at some time and may not be filtered, as in certain cases this might prevent the reception of abuse reports. For example, a spam report that includes the spam message itself or URLs or content typically classified as spam.

The “abuse-mailbox” may initially return an automatic reply, for example, assigning a ticket number, applying classification procedures, requesting further information, etc. However, it may not require the use of a form, as this would mean that each entity that needs to report cases of abuse (a task that is typically automated) would be forced to develop a specific interface for each resource recipient to which it must submit its reports. This would not be viable, as it would place the cost of processing the abuses on those who submit the claims and are therefore the victims of the abuse, not on those who (directly or indirectly) cause the abuse.

It is reasonable for the person reporting the abuse to submit sufficient information in the first report (logs, a copy of the spam message or its full headers, or equivalent information as applicable for each type of abuse). Likewise, it is reasonable for the initial auto-reply email to specify that the claim will not be processed unless such information has been submitted, thus offering the sender the opportunity to repeat the submission and include relevant evidence. This allows automatic reporting, for example, via fail2ban, SpamCop or other reporting services, keeping costs at a minimum for both parties involved. Usually, once a ticket number has been assigned, it is to be expected that the same number will be maintained in all communications (typically as part of the subject).

12.3. Purpose of “abuse-c”/ “abuse-mailbox” validation

The procedure is to be developed by LACNIC and must meet the following objectives:

1) It must guarantee its functionality and allow the helpdesks that deal with the abuse reports to verify that the validation actually originated from LACNIC and not from other sources (involving security risks, avoiding, for example, a single “direct” URL for validation).
2) A fully automated process should be avoided.
3) It should confirm that the person performing the validation:
• understands the procedure and the LACNIC policies in force;
• regularly monitors the “abuse-mailbox”;
• takes measures in connection thereto;
• responds to the abuse report.
4) An “Initial” validation period of fifteen (15) days.
5) If this validation fails, “escalate” to the original recipient of the resources (LIR, end user, etc.) for an additional period of fifteen (15) days.

The validation periods may be modified at LACNIC's discretion, informing the community of the reasons for doing so.

(By way of recommendation, a detailed procedure is included in this policy proposal under “Additional Information”)

12.4. Validation of “abuse-c”/“abuse-mailbox”

LACNIC will periodically validate compliance with the policy, at least twice a year and whenever “abuse-c” attributes are created or modified.

The validation frequency may be modified at LACNIC's discretion, informing the community of the reasons for doing so.

12.5. Failure to comply

Failure of an organization to comply with this section occurs if it has not been validated during the “initial” or the “additional” validation periods. This will result in the blocking of MiLACNIC and equivalent measures in the systems of the NIRs for all the resources associated with the organization. Strictly contractual and payment-related matters will be excepted, as will the possibility of updating the abuse-c/abuse-mailbox contacts so that they may be automatically re-validated to allow MiLACNIC to be unblocked.

Any attempt to access MiLACNIC (or the equivalent systems of the NIRs) while the system remains blocked will display a warning message including the text of this policy. Before the system allows the person to continue, this message must be “read” in full and confirmed by selecting a checkbox or other similar mechanism. As technology evolves, other equivalent mechanisms may be adopted.

If the failure to comply continues, LACNIC will act in accordance with its relevant policies and procedures.

12.6. Escalation to LACNIC

Fraudulent behavior (for example, an “abuse-mailbox” that only replies to emails from LACNIC or to emails having a specific subject or body) or failure to comply with the remaining aspects of this policy (ignoring or incorrectly managing cases of abuse) may be reported to LACNIC for re-validation according to 12.4.

New Text
Analyze Diff

Current text: N/A

New text:

12. Registration and validation of “abuse-c” and “abuse-mailbox”

12.1. Description of “abuse-c” and “abuse-mailbox”
All resources that use LACNIC's registration systems must include a mandatory abuse-c contact attribute (abuse contact) in their corresponding WHOIS entries, with at least one valid, monitored, and actively managed abuse-mailbox that allows sending manual or automatic reports regarding abusive behavior, security issues, and the like.

Unrestricted access to the “abuse-mailbox” attribute must be available via whois, APIs and future technologies.

Considering the hierarchical nature of the objects, child objects of those directly distributed by LACNIC (for example, sub-assignments) are covered by the parent objects and their own “abuse-c” attribute is optional.

Following usual practices, other “e-mail” attributes may be included for other purposes.

12.2. About the “abuse-mailbox”

Email messages sent to the “abuse-mailbox” must require manual intervention by the recipient at some time and may not be filtered, as in certain cases this might prevent the reception of abuse reports. For example, a spam report that includes the spam message itself or URLs or content typically classified as spam.

The “abuse-mailbox” may initially return an automatic reply, for example, assigning a ticket number, applying classification procedures, requesting further information, etc. However, it may not require the use of a form, as this would mean that each entity that needs to report cases of abuse (a task that is typically automated) would be forced to develop a specific interface for each resource recipient to which it must submit its reports. This would not be viable, as it would place the cost of processing the abuses on those who submit the claims and are therefore the victims of the abuse, not on those who (directly or indirectly) cause the abuse.

It is reasonable for the person reporting the abuse to submit sufficient information in the first report (logs, a copy of the spam message or its full headers, or equivalent information as applicable for each type of abuse). Likewise, it is reasonable for the initial auto-reply email to specify that the claim will not be processed unless such information has been submitted, thus offering the sender the opportunity to repeat the submission and include relevant evidence. This allows automatic reporting, for example, via fail2ban, SpamCop or other reporting services, keeping costs at a minimum for both parties involved. Usually, once a ticket number has been assigned, it is to be expected that the same number will be maintained in all communications (typically as part of the subject).

12.3. Purpose of “abuse-c”/ “abuse-mailbox” validation

The procedure is to be developed by LACNIC and must meet the following objectives:

1) It must guarantee its functionality and allow the helpdesks that deal with the abuse reports to verify that the validation actually originated from LACNIC and not from other sources (involving security risks, avoiding, for example, a single “direct” URL for validation).
2) A fully automated process should be avoided.
3) It should confirm that the person performing the validation:
• understands the procedure and the LACNIC policies in force;
• regularly monitors the “abuse-mailbox”;
• takes measures in connection thereto;
• responds to the abuse report.
4) An “Initial” validation period of fifteen (15) days.
5) If this validation fails, “escalate” to the original recipient of the resources (LIR, end user, etc.) for an additional period of fifteen (15) days.

The validation periods may be modified at LACNIC's discretion, informing the community of the reasons for doing so.

(By way of recommendation, a detailed procedure is included in this policy proposal under “Additional Information”)

12.4. Validation of “abuse-c”/“abuse-mailbox”

LACNIC will periodically validate compliance with the policy, at least twice a year and whenever “abuse-c” attributes are created or modified.

The validation frequency may be modified at LACNIC's discretion, informing the community of the reasons for doing so.

12.5. Failure to comply

Failure of an organization to comply with this section occurs if it has not been validated during the “initial” or the “additional” validation periods. This will result in the blocking of MiLACNIC and equivalent measures in the systems of the NIRs for all the resources associated with the organization. Strictly contractual and payment-related matters will be excepted, as will the possibility of updating the abuse-c/abuse-mailbox contacts so that they may be automatically re-validated to allow MiLACNIC to be unblocked.

Any attempt to access MiLACNIC (or the equivalent systems of the NIRs) while the system remains blocked will display a warning message including the text of this policy. Before the system allows the person to continue, this message must be “read” in full and confirmed by selecting a checkbox or other similar mechanism. As technology evolves, other equivalent mechanisms may be adopted.

If the failure to comply continues, LACNIC will act in accordance with its relevant policies and procedures.

12.6. Escalation to LACNIC

Fraudulent behavior (for example, an “abuse-mailbox” that only replies to emails from LACNIC or to emails having a specific subject or body) or failure to comply with the remaining aspects of this policy (ignoring or incorrectly managing cases of abuse) may be reported to LACNIC for re-validation according to 12.4.

Additional Information

Note (not to be included in the Policy Manual):
Current Section “12. Appendixes” would become Section “A. Appendixes” and be located at the end of the Policy Manual. In addition, the entire Manual would be updated to reflect this change of numbering. Then, as the Manual continues to grow, renumbering would not be necessary when a new section is added. The text of this proposal would therefore be included in the Policy Manual as Section 12 or any other number deemed appropriate by the staff at the time of its implementation, once consensus has been reached.

The following text is an example of a validation procedure based on typical helpdesk practices which, for example, does not require clicking on an html link sent via email to prevent phishing or other malicious actions. While this text is not part of the policy, we recommend its consideration, as it is the result of the discussions on abuse-c policies that have taken place among the global community.

1) LACNIC automatically initiates the validation by sending TWO consecutive emails to the “abuse-mailbox”.
2) These emails will contain plain text only (thus hiding any URLs intended as phishing or other types of attacks).
3) At the discretion of LACNIC, in general or in specific cases (for example, for confirmation in cases of escalation under 12.6), LACNIC may use domains other than lacnic.* and even modify the subject and body of the message in order to increase the efficiency of said validations.
4) The first email will contain the URL where the validation is to be performed (“validacion.lacnic.net”) and may contain information about the procedure, a brief summary of this policy, etc.
5) The second email will contain a unique alphanumeric validation code.
6) The recipient responsible for the “abuse-mailbox” must go to the URL and paste the code they received in the second email in the form.
7) This URL must be designed in such a way that it prevents the use of an automated process (for example, “captcha”). In addition, it must contain a text that confirms that the person performing the validation understands the procedure and the policy, that they regularly monitor the “abuse-mailbox”, that appropriate measures are taken to solve reported cases of abuse, and that the abuse report receives a response, with a checkbox that must be accepted in order to proceed.
8) The alphanumeric code will be valid for a maximum of 15 days.
9) If the code is not entered within this period, the system will mark the “abuse-c” as “temporarily invalid” and will alert LACNIC staff so that they can initiate a personalized follow-up with the resource's recipient.
10) If no reply is received confirming that the situation has been corrected, after an additional period of 15 days, the “abuse-c” will be marked as permanently “invalid”.
11) The validation process will be repeated automatically (items 1 to 7 above). If satisfactory, the “abuse-c” will be marked as “valid”; otherwise, it will be considered in breach of the policy.
12) LACNIC will have mechanisms in place (a form, an email address and possibly others in the future) to facilitate the escalation in cases where reporting a breach of this policy is desired. This will allow re-validation (12.4) and LACNIC's intervention in applying the policies, procedures and contractual requirements in force.

Timetable

-

References

-


Summary

This proposal allows ensuring and validating an organization's WHOIS abuse contacts (abuse-c and abuse-mailbox) and thus reporting and solving cases of abuse.

It seeks to solve the problem by ensuring the existence of a proper abuse-c contact and a process for its utilization.

Rationale

The current (ASN) policy is not clear regarding the obligation to register an abuse contact (abuse-c) or its specific format, nor as to whether this applies to other WHOIS records.

As a result, some organizations that have received resources from LACNIC may not have this contact information on record for their resources, and there are even cases of LIRs/ISPs, end users or others that use a non-existent email address or one that is not actively monitored.

Because these contacts are not validated, cases of abuse cannot be effectively reported. This creates security issues and costs for the victims.

To solve this problem, a simple, periodic verification of abuse contacts is proposed that will avoid unnecessary costs to third parties.

The proposal guarantees that the cost of processing an abuse falls on the recipient of the resource who is responsible for the abuse, either directly or indirectly (through a customer, from whom they are possibly receiving financial compensation for the service), instead of falling on the victim. Bear in mind that this will keep the problem from escalating and will save time and legal costs for both parties involved if the matter is taken to court.

In this case, the abuse-c attribute —which has so far only been referenced for the “aut-num” object— becomes mandatory in the “inetnum” objects (for both IPv4 and IPv6), as well as in any others that may be used in the future. This attribute is an abuse contact, which must contain at least the “abuse-mailbox” attribute.

Current Text

Current text:

N/A

New text:

12. Registration and validation of “abuse-c” and “abuse-mailbox”

12.1. Description of “abuse-c” and “abuse-mailbox”
All resources that use LACNIC's registration systems must include a mandatory abuse-c contact attribute (abuse contact) in their corresponding WHOIS entries, with at least one valid, monitored, and actively managed abuse-mailbox that allows sending manual or automatic reports regarding abusive behavior, security issues, and the like.

Unrestricted access to the “abuse-mailbox” attribute must be available via whois, APIs and future technologies.

Considering the hierarchical nature of the objects, child objects of those directly distributed by LACNIC (for example, sub-assignments) are covered by the parent objects and their own “abuse-c” attribute is optional.

Following usual practices, other “e-mail” attributes may be included for other purposes.

12.2. About the “abuse-mailbox”

The “abuse-mailbox”:
• Must require intervention by the recipient.
• Must not require the use of a form to report abuse.
• Must guarantee that abuse reports, logs, headers, examples, etc. relating to the case of abuse are received.

12.3. Purpose of “abuse-c”/ “abuse-mailbox” validation

The procedure, to be developed by LACNIC, must meet the following objectives:

1) A simple process that guarantees its functionality and the fulfillment of its purpose.
2) It should confirm that the person performing the validation:
• understands the procedure and the LACNIC policies in force;
• regularly monitors the “abuse-mailbox”;
• takes measures in connection thereto;
• responds to the abuse report.
3) Include an “Initial” validation period of fifteen (15) days.
4) If this validation fails, “escalate”, by any possible means, to the rest of the available contacts within an additional period of fifteen (15) days.

12.4. Validation of “abuse-c”/“abuse-mailbox”
LACNIC will periodically validate compliance with the policy, at least twice a year and whenever “abuse-c” attributes are created or modified.

Failure of an organization to comply with this section occurs if it has not been validated during the “initial” or the “additional” validation periods.

12.5. Escalation to LACNIC

Fraudulent behavior (for example, an “abuse-mailbox” that only replies to emails from LACNIC or to emails having a specific subject or body) or failure to comply with the remaining aspects of this policy (ignoring or improper attention to cases of abuse) may be reported to LACNIC for re-validation according to 12.4.

New Text
Analyze Diff

Current text:

N/A

New text:

12. Registration and validation of “abuse-c” and “abuse-mailbox”

12.1. Description of “abuse-c” and “abuse-mailbox”
All resources that use LACNIC's registration systems must include a mandatory abuse-c contact attribute (abuse contact) in their corresponding WHOIS entries, with at least one valid, monitored, and actively managed abuse-mailbox that allows sending manual or automatic reports regarding abusive behavior, security issues, and the like.

Unrestricted access to the “abuse-mailbox” attribute must be available via whois, APIs and future technologies.

Considering the hierarchical nature of the objects, child objects of those directly distributed by LACNIC (for example, sub-assignments) are covered by the parent objects and their own “abuse-c” attribute is optional.

Following usual practices, other “e-mail” attributes may be included for other purposes.

12.2. About the “abuse-mailbox”

The “abuse-mailbox”:
• Must require intervention by the recipient.
• Must not require the use of a form to report abuse.
• Must guarantee that abuse reports, logs, headers, examples, etc. relating to the case of abuse are received.

12.3. Purpose of “abuse-c”/ “abuse-mailbox” validation

The procedure, to be developed by LACNIC, must meet the following objectives:

1) A simple process that guarantees its functionality and the fulfillment of its purpose.
2) It should confirm that the person performing the validation:
• understands the procedure and the LACNIC policies in force;
• regularly monitors the “abuse-mailbox”;
• takes measures in connection thereto;
• responds to the abuse report.
3) Include an “Initial” validation period of fifteen (15) days.
4) If this validation fails, “escalate”, by any possible means, to the rest of the available contacts within an additional period of fifteen (15) days.

12.4. Validation of “abuse-c”/“abuse-mailbox”
LACNIC will periodically validate compliance with the policy, at least twice a year and whenever “abuse-c” attributes are created or modified.

Failure of an organization to comply with this section occurs if it has not been validated during the “initial” or the “additional” validation periods.

12.5. Escalation to LACNIC

Fraudulent behavior (for example, an “abuse-mailbox” that only replies to emails from LACNIC or to emails having a specific subject or body) or failure to comply with the remaining aspects of this policy (ignoring or improper attention to cases of abuse) may be reported to LACNIC for re-validation according to 12.4.

Additional Information

Note (not to be included in the Policy Manual): Current Section “12. Appendixes” would become Section “A. Appendixes” and be located at the end of the Policy Manual. In addition, the entire Manual would be updated to reflect this change of numbering. Then, as the Manual continues to grow, renumbering would not be necessary when a new section is added. The text of this proposal would therefore be included in the Policy Manual as Section 12 or any other number deemed appropriate by the staff at the time of its implementation , once consensus has been reached.

LACNIC may modify the “initial” and “escalated” validation periods if it sees fit, provided that the community is informed of the reasons for such changes. For example, these periods might be extended during the initial implementation phase and then progressively adjusted as a higher portion of contacts is verified.

Similarly, the frequency of the periodic verification may be modified by LACNIC if it sees fit, also informing the community of the reasons for doing so. For example, the first year a single validation might be carried out to facilitate compliance with the policy, and then number of validations might be progressively increased, perhaps conducting them quarterly, to improve the quality of the contacts.

The following text is an example of a validation procedure based on typical helpdesk practices which, for example, does not require clicking on an html link sent via email to prevent phishing or other malicious actions. While this text is not part of the policy, we recommend its consideration, as it is the result of the discussions on abuse-c policies that have taken place among the global community.
(See previous version of the proposal, the form only allows a limited number of characters)

Timetable

-

References

-