Interpretação da proposta pela equipe de LACNIC
---------------------------------------------------
Aplicação da proposta
-----------------------
Esta proposta seria aplicada aos receptores de recursos de LACNIC para que registrem um contato de abuso válido para ASNs, IPv4 e IPv6.
Modificação do texto atual
--------------------------
A seção atual “12. Apêndices” passa a ser “A. Apêndices", no final do Manual de Políticas, e todas suas referências são atualizadas.
Serão acrescentadas as seções:
o 12. “Registro e Validação de "abuse-c" e "abuse-mailbox”
o 12.1 “Descrição do "abuse-c" e "abuse-mailbox”
o 12.2. Acerca do "abuse-mailbox"
o 12.3. Objetivos da validação do "abuse-c"/"abuse-mailbox"
o 12.4. Validação do "abuse-c"/"abuse-mailbox"
o 12.5. Mecanismo de escalado para LACNIC
A nova versão acrescenta:
- Resume e reduz a subseção 12.2. Acerca do “abuse-mailbox” na que as características que o “abuse-mailbox” deve ter são descritas.
- Elimina a seção “Dos incumprimentos” e acrescenta a subseção 12.4. Validação do “abuse-mailbox”, “O incumprimento por parte de qualquer organização ocorre se não foi validado no prazo "inicial" ou "adicional".
Comentários da equipe
------------------------
(Comentários são observações para ajudar a diferenciar as alterações apresentadas pela proposta em relação ao texto atual do Manual de Políticas)
1. LACNIC interpreta que os prazos propostos poderiam ser modificados de acordo com o que julgar apropriado para sua melhor implementação. Tanto os prazos de validação inicial e escalado, quanto a frequência de validação periódica.
2. LACNIC entende que o objetivo da proposta não é revogar perante qualquer tipo de evidência, mas perante o incumprimento repetido e significativo das políticas. LACNIC procederá a revogar em uma última instância.
É importante lembrar que a revogação de recursos é permanente, tem alto impacto nas operações das organizações e é um processo complexo. Por esse motivo, recomendamos que essa instância seja aplicada apenas quando todos os recursos sejam esgotados e tenha passado um prazo significativo após a irregularidade ser detectada.
3. Observa-se que, para a implementação desta proposta, LACNIC precisará investir novos recursos para atender o acompanhamento de todos os casos que precisarem se houver incumprimento.
4. Mesmo que o Manual de Políticas não indique que o bloco IPv4 deva conter um contato de abuso, o sistema de LACNIC já suporta esta modalidade e os blocos IPv4, IPv6 e ASN já possuem este atributo. O mesmo acontece no caso das subdesignações, o abuse-c usado é o ponto de contato administrativo da organização que recebe a designação ou a subdesignação.
Foi feita uma consulta ao Banco de Dados de LACNIC sobre o registro dos contatos de abuso de cada tipo de recursos e se obtiveram os seguintes resultados:
- Número de recursos IPv4, IPv6, ASN com contatos de abuso null ou vazio: 0
- Número de recursos legados IPv4 com contatos de abuso null ou vazio: 241
- Número de recursos legados IPv6 com contatos de abuso null ou vazio: 0
- Número de recursos legados ASN com contatos de abuso null ou vazio: 146
Portanto, atualmente não existe nenhum recurso que não seja legado com o contato de abuso vazio/null. Todos os que aparecem na BD com null/vazio sai legados. No entanto, LACNIC não faz qualquer tipo de validação sobre os contatos
5. LACNIC entende que isso não aplica para as organizações com recursos legados. Embora estas organizações estejam no mesmo banco de dados de LACNIC, muitas não têm um contato válido (e-mail, telefone) ou obrigação contratual de atualizá-lo devido à antiguidade da designação (antes de 1997). As organizações com recursos legados também não são obrigadas a cumprir as políticas de LACNIC, portanto, esta política também não seria aplicável a elas.
6. Em relação ao seguinte texto: “Levando em conta a natureza hierárquica dos objetos, os herdados de aqueles alocados diretamente por LACNIC (por exemplo, subdesignações), são cobertos pelos objetos de nível superior e seu próprio atributo "abuse-c” é optativo.”
LACNIC entende que isso significa que, no caso de subdesignações de endereços, o contato de "abuse-c" pode estar coberto pelo da organização de nível superior ou pelo de sua própria organização. Portanto LACNIC interpreta que as verificações das subdesignações não seriam realizadas.
7. No ponto 5) da seção 12.3, LACNIC assume que o “escalado” seria com o restante dos contatos da organização.
Recomendações
-----------------
8. Recomenda-se que a proposta não defina prazos, mas determine ações e que os prazos necessários sejam definidos com base em razões operacionais
Impacto no sistema de registro
---------------------------------
Esta proposta implicará a criação de um processo para o controle automático do abuse-c e abuse-mailbox.
Implicará também um desenvolvimento para o sistema o portal dos NIRs e de LACNIC.
Fontes oficiais de referência
-----------------------------
Políticas sobre o contato de abuso nos outros RIRs
--------------------------------------------------
- RIPE
Há uma proposta em fase de implementação: https://www.ripe.net/publications/docs/ripe-705
No entanto, é mais flexível: a frequência é anual e é mais simples, RIPE irá verificar que exista um domínio e que haja apenas um servidor de correio configurado.
- APNIC
Uma política semelhante à de LACNIC alcançou consenso no último evento de APNIC e está em fase de implementação.
https://www.apnic.net/wp-content/uploads/2018/08/prop-125-v001.txt
- ARIN: De acordo à seção 3.6: https://www.arin.net/participate/policy/nrpm/#3-6-annual-validation-of-arin-s-public-whois-point-of-contact-data
Atualmente ARIN usa o seguinte procedimento de validação: envia um e-mail uma vez por ano para cada contato registrado. Cada contato tem um máximo de 60 dias para responder que o contato é correto e está atualizado. Se o contato não responder após 60 dias, será marcado como inválido no banco de dados. Estes usuários terão acesso limitado às funcionalidades de ARIN on-line até o contato seja atualizado.
Também há uma proposta semelhante à de LACNIC que será apresentada no evento de abril de ARIN: https://www.arin.net/participate/policy/drafts/2019_5/
- AFRINIC
Há uma proposta semelhante à de LACNIC que está em discussão desde novembro de 2018. Foi apresentada no último evento e voltou a discussão.
https://afrinic.net/policy/2018-gen-001-d2#proposal
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.
Justificativa(Descrever o problema que deseja solucionar)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.
Texto atualTexto 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".
Texto novoTexto 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".
Informações adicionaisEn RIPE se está tramitando una propuesta similar, aunque aún está en debate y no ha alcanzado consenso.
Tempo de implementação90 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.
Referências-
Apresentada em:-
A política atual (ASN) não é clara em relação à obrigação de registrar um contato de abuse (abuse-c) nem ao formato específico, e se pode ser aplicada a outros casos de registros no whois.
Como resultado, pode haver LIR que não tenham esse contato registrado para seus recursos, ou ainda há casos de LIR que usam uma caixa de correio inexistente ou que não é processada.
Na prática, isso faz com que esse contato seja ineficaz para denunciar abusos e problemas de segurança e custos para as vítimas, em geral.
Esta proposta visa resolver o problema e garantir a existência de um contato abuse-c correto e o processo para seu uso.
Justificativa(Descrever o problema que deseja solucionar)A comunidade da Internet é baseada na colaboração, mas muitas vezes isso não é suficiente, pelo que seria necessário que todos nós pudéssemos contatar com aqueles LIR que têm um problema na rede, mas não o conhecem.
Esta proposta cria uma nova seção no manual de políticas, para permitir resolver este problema mediante uma simples verificação periódica, e estabelece as regras básicas para isso e, assim, evitar custos desnecessários para terceiros em sua função de contatar com os responsáveis de resolver os abusos de uma determinada rede.
A proposta garante que o custo do processamento dos abusos fica por conta do LIR cujo cliente está causando o abuso (e do qual recebe compensação financeira pelo serviço), em vez de recair sobre a vítima, como aconteceria se houvesse que ir ao tribunal, evitando assim o agravamento econômico (advogados, procuradores, etc.) e no tempo, para ambas as partes.
Para isso, o atributo abuse-c, que até agora era apenas referenciado para o objeto "aut-num", torna-se obrigatório nos objetos "inetnum" e "inetnum6", e qualquer um que venha surgir no futuro. Este atributo é um contato de abuso, que deve conter no mínimo o atributo "abuse-mailbox".
Texto atualTexto atual: Não existe
Novo texto:
12. Registro e validação de "abuse-c" e "abuse-mailbox"
12.1. Descrição do "abuse-c" e "abuse-mailbox"
Todos os recursos alocados por LACNIC devem incluir obrigatoriamente, na entrada do WHOIS correspondente, o atributo de contato "abuse-c" (contato de abuso) com pelo menos um único e-mail (abuse-mailbox) válido, monitorado e devidamente atendido, que permita o envio de relatórios manuais ou automáticos de comportamentos abusivos, segurança e outros semelhantes.
O atributo "abuse-mailbox" deve estar disponível sem restrições através de whois, APIs e técnicas futuras.
Levando em conta a natureza hierárquica dos objetos de endereços IP, os objetos herdados de aqueles alocados diretamente por LACNIC, podem estar cobertos pelos objetos de nível superior ou ter seu próprio atributo "abuse-c".
Seguindo práticas usuais, outros atributos "e-mail" podem ser incluídos para outros fins.
12.2. Características do "abuse-mailbox"
Os e-mails enviados para "abuse-mailbox" devem exigir intervenção manual em algum momento, por parte do destinatário, e não podem estar filtrados, pois isso poderia impedir, que em alguns casos, o envio de um relatório de abuso, por exemplo, por spam, ao incluir a própria mensagem de spam ou URL ou conteúdos geralmente classificados como spam, evite sua recepção.
A caixa de correio "abuse-mailbox" poderá devolver inicialmente uma resposta automática, por exemplo, designando um número de bilhete, aplicando procedimentos de classificação, solicitando mais informações, etc. No entanto, não poderá exigir o uso de um formulário, pois isso implicaria que cada empresa que precise reportar abusos, geralmente de forma automatizada, seja forçada a desenvolver uma interface específica para cada caso de abuso, o que é inviável e ilógico, uma vez que faria recair o custo do processado dos abusos em quem envia a reclamação, quer dizer, a vítima do abuso, em vez de ser pago por aquele cujo cliente (e de quem recebe renda) causa o abuso.
Para fins de informação, vale a pena mencionar que o razoável é, que a pessoa que denuncia o abuso, faça isso desde o primeiro momento e nesse primeiro relatório, enviando os logs ou cópia do spam (anexando um exemplo do e-mail de spam ou seus cabeçalhos completos) ou similares, que demonstrem o abuso. Da mesma forma, é razoável esperar que o e-mail inicial de auto-resposta indique que, se esses registros não tiverem sido enviados, não serão atendidos, dando assim a oportunidade de repetir o envio com a evidência pertinente. Isso permite relatórios automatizados, por exemplo, mediante fail2ban, SpamCop ou outros, com um custo mínimo para ambas as partes.
12.3. Objetivos da validação do "abuse-c"/"abuse-mailbox"
O procedimento, que deverá ser desenvolvido por LACNIC, deve atender aos seguintes objetivos:
1) Processo simples que garanta a sua funcionalidade e permita aos "helpdesk" que atendem aos relatórios de abuso, verificar que os pedidos de validação são realmente provenientes de LACNIC e não de terceiras fontes (o que poderia envolver riscos de segurança), evitando, por exemplo, uma única URL "direta" para a validação..
2) Impedir um processo automatizado.
3) Confirmar que quem valida garante conhecer o procedimento, a política, que monitora regularmente o "abuse-mailbox", que toma medidas e responde ao relatório de abuso.
4) Período de validação não superior a 2 dias úteis.
5) Se não for validado corretamente, escalado com o LIR e um novo prazo, não superior a 3 dias úteis.
(como exemplo, propõe-se um procedimento detalhado em "Informações adicionais" desta proposta de política).
12.4. Validação do "abuse-c" e "abuse-mailbox"
LACNIC validará o cumprimento dos pontos acima, tanto no momento em que os atributos "abuse-c" e/ou "abuse-mailbox" são criados quanto modificados, periodicamente, não menos de uma vez a cada três meses e a qualquer momento que LACNIC considerar oportuno..
Ao critério de LACNIC, em forma generalizada ou em casos específicos (por exemplo, para a confirmação em casos de escalado de acordo com o ponto 12.5), LACNIC, para realizar as referidas validações, poderá usar domínios que não sejam lacnic.*, e até mesmo modificar o assunto e o corpo da mensagem,
O descumprimento implicará um acompanhamento mais exaustivo, de acordo com as políticas/procedimentos pertinentes de LACNIC e, principalmente, "7.1. Recuperação de recursos".
12.5. Mecanismo de escalado para LACNIC
A fim de evitar engano (por exemplo, "abuse-mailbox" que respondem somente aos e-mails de LACNIC, a um determinado assunto ou corpo da mensagem), ou a violação do restante dos aspectos desta política (a incorreta ou não atenção dos casos de abuso) e, portanto, para garantir a qualidade dos serviços na região com os recursos alocados por LACNIC, será disponibilizada uma caixa de correio (por exemplo, "escalado-abusos@lacnic.net"), que permita escalar as referidas situações, permitindo assim a revalidação (de acordo com o ponto 12.4 acima) e até a intermediação de LACNIC e, quando apropriado, a aplicação das políticas/procedimentos pertinentes e, principalmente, "7.1. Recuperação de recursos".
Texto novoTexto atual: Não existe
Novo texto:
12. Registro e validação de "abuse-c" e "abuse-mailbox"
12.1. Descrição do "abuse-c" e "abuse-mailbox"
Todos os recursos alocados por LACNIC devem incluir obrigatoriamente, na entrada do WHOIS correspondente, o atributo de contato "abuse-c" (contato de abuso) com pelo menos um único e-mail (abuse-mailbox) válido, monitorado e devidamente atendido, que permita o envio de relatórios manuais ou automáticos de comportamentos abusivos, segurança e outros semelhantes.
O atributo "abuse-mailbox" deve estar disponível sem restrições através de whois, APIs e técnicas futuras.
Levando em conta a natureza hierárquica dos objetos de endereços IP, os objetos herdados de aqueles alocados diretamente por LACNIC, podem estar cobertos pelos objetos de nível superior ou ter seu próprio atributo "abuse-c".
Seguindo práticas usuais, outros atributos "e-mail" podem ser incluídos para outros fins.
12.2. Características do "abuse-mailbox"
Os e-mails enviados para "abuse-mailbox" devem exigir intervenção manual em algum momento, por parte do destinatário, e não podem estar filtrados, pois isso poderia impedir, que em alguns casos, o envio de um relatório de abuso, por exemplo, por spam, ao incluir a própria mensagem de spam ou URL ou conteúdos geralmente classificados como spam, evite sua recepção.
A caixa de correio "abuse-mailbox" poderá devolver inicialmente uma resposta automática, por exemplo, designando um número de bilhete, aplicando procedimentos de classificação, solicitando mais informações, etc. No entanto, não poderá exigir o uso de um formulário, pois isso implicaria que cada empresa que precise reportar abusos, geralmente de forma automatizada, seja forçada a desenvolver uma interface específica para cada caso de abuso, o que é inviável e ilógico, uma vez que faria recair o custo do processado dos abusos em quem envia a reclamação, quer dizer, a vítima do abuso, em vez de ser pago por aquele cujo cliente (e de quem recebe renda) causa o abuso.
Para fins de informação, vale a pena mencionar que o razoável é, que a pessoa que denuncia o abuso, faça isso desde o primeiro momento e nesse primeiro relatório, enviando os logs ou cópia do spam (anexando um exemplo do e-mail de spam ou seus cabeçalhos completos) ou similares, que demonstrem o abuso. Da mesma forma, é razoável esperar que o e-mail inicial de auto-resposta indique que, se esses registros não tiverem sido enviados, não serão atendidos, dando assim a oportunidade de repetir o envio com a evidência pertinente. Isso permite relatórios automatizados, por exemplo, mediante fail2ban, SpamCop ou outros, com um custo mínimo para ambas as partes.
12.3. Objetivos da validação do "abuse-c"/"abuse-mailbox"
O procedimento, que deverá ser desenvolvido por LACNIC, deve atender aos seguintes objetivos:
1) Processo simples que garanta a sua funcionalidade e permita aos "helpdesk" que atendem aos relatórios de abuso, verificar que os pedidos de validação são realmente provenientes de LACNIC e não de terceiras fontes (o que poderia envolver riscos de segurança), evitando, por exemplo, uma única URL "direta" para a validação..
2) Impedir um processo automatizado.
3) Confirmar que quem valida garante conhecer o procedimento, a política, que monitora regularmente o "abuse-mailbox", que toma medidas e responde ao relatório de abuso.
4) Período de validação não superior a 2 dias úteis.
5) Se não for validado corretamente, escalado com o LIR e um novo prazo, não superior a 3 dias úteis.
(como exemplo, propõe-se um procedimento detalhado em "Informações adicionais" desta proposta de política).
12.4. Validação do "abuse-c" e "abuse-mailbox"
LACNIC validará o cumprimento dos pontos acima, tanto no momento em que os atributos "abuse-c" e/ou "abuse-mailbox" são criados quanto modificados, periodicamente, não menos de uma vez a cada três meses e a qualquer momento que LACNIC considerar oportuno..
Ao critério de LACNIC, em forma generalizada ou em casos específicos (por exemplo, para a confirmação em casos de escalado de acordo com o ponto 12.5), LACNIC, para realizar as referidas validações, poderá usar domínios que não sejam lacnic.*, e até mesmo modificar o assunto e o corpo da mensagem,
O descumprimento implicará um acompanhamento mais exaustivo, de acordo com as políticas/procedimentos pertinentes de LACNIC e, principalmente, "7.1. Recuperação de recursos".
12.5. Mecanismo de escalado para LACNIC
A fim de evitar engano (por exemplo, "abuse-mailbox" que respondem somente aos e-mails de LACNIC, a um determinado assunto ou corpo da mensagem), ou a violação do restante dos aspectos desta política (a incorreta ou não atenção dos casos de abuso) e, portanto, para garantir a qualidade dos serviços na região com os recursos alocados por LACNIC, será disponibilizada uma caixa de correio (por exemplo, "escalado-abusos@lacnic.net"), que permita escalar as referidas situações, permitindo assim a revalidação (de acordo com o ponto 12.4 acima) e até a intermediação de LACNIC e, quando apropriado, a aplicação das políticas/procedimentos pertinentes e, principalmente, "7.1. Recuperação de recursos".
Informações adicionaisExemplo de procedimento de validação.
1) A validação começa de forma automatizada, por parte de LACNIC, com o envio de DOIS e-mails consecutivos para o "abuse-mailbox".
2) Esses e-mails terão exclusivamente formato de texto.
3) O primeiro dos e-mails vai conter a URL onde a validação deve ser realizada, que será "validacion.lacnic.net", e poderá conter informações sobre o procedimento, extrato desta política, etc.
4) O segundo dos e-mails vai conter um código alfanumérico único de validação.
5) O receptor que atende o "abuse-mailbox", deverá acessar à URL e colar no formulário o código recebido no segundo e-mail.
6) Esta URL deverá estar projetada de forma de impedir um processo automatizado (por exemplo, "captcha") e conterá um texto que confirme que o receptor da validação conhece o procedimento, a política e que monitora regularmente o "abuse-mailbox" e que são tomadas medidas adequadas para resolver os abusos relatados e responder a eles, com um "checkbox" que deve ser necessariamente aceito.
7) O código alfanumérico apenas será válido por um máximo de 2 dias úteis.
8) Se o código não for inserido nesse prazo, o sistema marcará o "abuse-c" como "provisoriamente inválido" e alertará equipe de LACNIC para que possa ser iniciado o acompanhamento personalizado com o LIR.
9) No caso de não obter uma resposta com a confirmação da correção da situação, em um período adicional de 3 dias úteis, o "abuse-c" será marcado de forma permanente como "inválido"..
10) O processo de validação será repetido automaticamente (pontos 1 a 7 acima) e, neste caso, o "abuse-c" será marcado como "válido" se for satisfatório, caso contrário, seria um caso de descumprimento da política.
Tempo de implementação90 dias, de forma prudencial e a ser confirmado com LACNIC, para permitir que o pessoal desenvolva a ferramenta e que os LIR atualizem seus contatos "abuse-c".
ReferênciasEm RIPE, uma proposta semelhante está sendo processada, embora ainda esteja em debate e não tenha atingido consenso (na data de envio desta proposta).
Apresentada em:LACNIC 30 (24/09/2018)
LACNIC 29 (30/04/2018)
A política atual (ASN) não é clara em relação à obrigação de registrar um contato de abuse (abuse-c) nem ao formato específico, e se pode ser aplicada a outros casos de registros no whois.
Como resultado, pode haver receptores de recursos de LACNIC que não tenham esse contato registrado para seus recursos, ou ainda há casos de LIRs/ISPs, usuários finais ou outros, que usam uma caixa de correio inexistente ou que não é processada.
Na prática, isso faz com que esse contato seja ineficaz para denunciar abusos e problemas de segurança e custos para as vítimas, em geral.
Esta proposta visa resolver o problema e garantir a existência de um contato abuse-c correto e o processo para seu uso.
Justificativa(Descrever o problema que deseja solucionar)A comunidade da Internet é baseada na colaboração, mas muitas vezes isso não é suficiente, pelo que seria necessário que todos nós pudéssemos contatar com aqueles LIRs ou outros receptores de recursos de LACNIC que têm um problema na rede, mas não o conhecem.
Esta proposta cria uma nova seção no manual de políticas, para permitir resolver este problema mediante uma simples verificação periódica, e estabelece as regras básicas para isso e, assim, evitar custos desnecessários para terceiros em sua função de contatar com os responsáveis de resolver os abusos de uma determinada rede.
A proposta garante que o custo do processamento dos abusos fica por conta do LIR cujo cliente está causando o abuso (e do qual recebe compensação financeira pelo serviço), em vez de recair sobre a vítima, como aconteceria se houvesse que ir ao tribunal, evitando assim o agravamento econômico (advogados, procuradores, etc.) e no tempo, para ambas as partes.
Para isso, o atributo abuse-c, que até agora era apenas referenciado para o objeto "aut-num", torna-se obrigatório nos objetos "inetnum" (tanto para o IPv4 quanto para o IPv6), e qualquer um que venha surgir no futuro. Este atributo é um contato de abuso, que deve conter no mínimo o atributo "abuse-mailbox".
Texto atualTexto atual: Não existe
Texto novo:
Nota (não deve ser incluído no manual de políticas): A seção atual “12. Apêndices "passa a ser" A. Apêndices", no final do manual de políticas, e todas as referências a ela são renumeradas em todo o manual de políticas. Dessa forma, as novas seções do manual não requererão renumerações futuras, segundo o manual for "crescendo". O texto desta proposta passa a ser, portanto, a seção 12.
12. Registro e validação de "abuse-c" e "abuse-mailbox"
12.1. Descrição do "abuse-c" e "abuse-mailbox"
Todos os recursos alocados por LACNIC devem incluir obrigatoriamente, na entrada do WHOIS correspondente, o atributo de contato "abuse-c" (contato de abuso) com pelo menos um único e-mail (abuse-mailbox) válido, monitorado e devidamente atendido, que permita o envio de relatórios manuais ou automáticos de comportamentos abusivos, segurança e outros semelhantes.
O atributo "abuse-mailbox" deve estar disponível sem restrições através de whois, APIs e técnicas futuras.
Levando em conta a natureza hierárquica dos objetos de endereços IP, os objetos herdados de aqueles alocados diretamente por LACNIC, podem estar cobertos pelos objetos de nível superior ou ter seu próprio atributo "abuse-c".
Seguindo práticas usuais, outros atributos "e-mail" podem ser incluídos para outros fins.
12.2. Características do "abuse-mailbox"
Os e-mails enviados para "abuse-mailbox" devem exigir intervenção manual em algum momento, por parte do destinatário, e não podem estar filtrados, pois isso poderia impedir, que em alguns casos, o envio de um relatório de abuso, por exemplo por spam, ao incluir a própria mensagem de spam ou URLs ou conteúdos geralmente classificados como spam, evite sua recepção.
A caixa de correio "abuse-mailbox" poderá enviar inicialmente uma resposta automática, por exemplo, designando um número de ticket, aplicando procedimentos de classificação, solicitando mais informações, etc. No entanto, não poderá requerer o uso de um formulário, pois isso implicaria que cada empresa que precise denunciar abusos, geralmente de forma automatizada,
seja forçada a desenvolver uma interface específica para cada caso de abuso, o que é inviável e ilógico, uma vez que faria com que o custo do processado dos abusos caísse em quem envia a reclamação e, portanto, é vítima de abuso, em vez de ser paga por aquele cujo cliente (e de quem recebe renda), causa o abuso.
Para fins de informação, vale a pena mencionar que o razoável é que a pessoa que denuncia o abuso, faça isso desde o primeiro momento e nesse primeiro relatório, enviando os logs ou cópia do spam (anexando um exemplo do e-mail de spam ou seus cabeçalhos completos) ou similares, que demonstrem o abuso. Da mesma forma, é razoável esperar que o e-mail inicial de auto-resposta indique que, se esses registros não tiverem sido enviados, não serão atendidos, dando assim a oportunidade de repetir o envio com a evidência pertinente. Isso permite relatórios automatizados, por exemplo, mediante fail2ban, SpamCop ou outros, com um custo mínimo para ambas as partes.
12.3. Objetivos da validação do "abuse-c"/"abuse-mailbox"
O procedimento, que deverá ser desenvolvido por LACNIC, deve atender aos seguintes objetivos:
1) Processo simples que garanta a sua funcionalidade e permita aos "helpdesk" que atendem os relatórios de abuso, verificar que os pedidos de validação são realmente provenientes de LACNIC e não de terceiras fontes (o que poderia envolver riscos de segurança), evitando, por exemplo, uma única URL "direta" para a validação.
2) Impedir um processo exclusivamente automatizado.
3) Confirmar que quem valida garante conhecer o procedimento, a política, que monitora regularmente o "abuse-mailbox", que toma medidas e responde ao relatório de abuso.
4) Prazo de validação “inicial” não superior a 15 dias.
5) Se não for validado corretamente, “escalado” com o receptor do recurso (LIR, usuário final, etc.) e um novo prazo, não superior a 15 dias.
Os prazos de validação "inicial" e "escalado" poderão ser modificados por LACNIC, se considerar apropriado, informando a comunidade dos motivos. Por exemplo, poderiam ser reduzidos uma vez que uma alta porcentagem de contatos tenha sido validada de forma inicial, de modo que a qualidade dos contatos é incrementada e o tempo de resposta para os casos de abuso é reduzido.
(como exemplo, propõe-se um procedimento detalhado em "Informações adicionais" desta proposta de política).
12.4. Validação do "abuse-c"/"abuse-mailbox"
LACNIC validará o cumprimento dos pontos acima, tanto no momento em que os atributos "abuse-c" e/ou "abuse-mailbox" são criados quanto modificados, periodicamente, não menos de duas vezes por ano e a qualquer momento que LACNIC considerar oportuno..
A frequência periódica de validação poderia ser modificada por LACNIC, se considerar apropriada, informando à comunidade os motivos. Por exemplo, uma única validação poderia ser realizada no primeiro ano, para facilitar o tempo de adaptação à política e, posteriormente, progressivamente, aumentar o número de validações anuais, chegando a ser inclusive trimestrais ou mensais, com o objetivo de aumentar a qualidade dos contatos.
A critério de LACNIC, em forma generalizada ou em casos específicos (por exemplo, para a confirmação em casos de escalado de acordo com o ponto 12.5), LACNIC, para realizar as referidas validações, poderá usar domínios que não sejam lacnic.*, e até mesmo modificar o assunto e o corpo da mensagem,
A violação por parte de qualquer organização, implicará inicialmente o bloqueio de "milacnic" para todos os recursos associados com essa organização, exceto para a atualização dos contatos abuse-c/abuse-mailbox, de tal forma que possam ser revalidados para permitir o desbloqueio de "milacnic".
LACNIC realizará um acompanhamento mais exaustivo e, no caso em que na validação automática seguinte continue sendo confirmado o descumprimento, agirá de acordo com as políticas e procedimentos pertinentes de LACNIC e, especialmente, "7.1. Recuperação de recursos”.
12.5. Mecanismo de escalado para LACNIC
CA fim de evitar engano (por exemplo, "abuse-mailbox" que respondem somente aos e-mails de LACNIC, a um determinado assunto ou corpo da mensagem), ou a violação do restante dos aspectos desta política (a incorreta ou não atenção dos casos de abuso) e, portanto, para garantir a qualidade dos serviços na região com os recursos alocados por LACNIC será disponibilizada uma caixa de correio (por exemplo, “escalado-abusos@lacnic.net”), que permita escalar as referidas situações, permitindo assim a revalidação (de acordo com o ponto 12.4 acima) e até a intermediação de LACNIC e, quando apropriado, a aplicação das políticas/procedimentos pertinentes e, principalmente, "7.1. Recuperação de recursos”.
Texto novoTexto atual: Não existe
Texto novo:
Nota (não deve ser incluído no manual de políticas): A seção atual “12. Apêndices "passa a ser" A. Apêndices", no final do manual de políticas, e todas as referências a ela são renumeradas em todo o manual de políticas. Dessa forma, as novas seções do manual não requererão renumerações futuras, segundo o manual for "crescendo". O texto desta proposta passa a ser, portanto, a seção 12.
12. Registro e validação de "abuse-c" e "abuse-mailbox"
12.1. Descrição do "abuse-c" e "abuse-mailbox"
Todos os recursos alocados por LACNIC devem incluir obrigatoriamente, na entrada do WHOIS correspondente, o atributo de contato "abuse-c" (contato de abuso) com pelo menos um único e-mail (abuse-mailbox) válido, monitorado e devidamente atendido, que permita o envio de relatórios manuais ou automáticos de comportamentos abusivos, segurança e outros semelhantes.
O atributo "abuse-mailbox" deve estar disponível sem restrições através de whois, APIs e técnicas futuras.
Levando em conta a natureza hierárquica dos objetos de endereços IP, os objetos herdados de aqueles alocados diretamente por LACNIC, podem estar cobertos pelos objetos de nível superior ou ter seu próprio atributo "abuse-c".
Seguindo práticas usuais, outros atributos "e-mail" podem ser incluídos para outros fins.
12.2. Características do "abuse-mailbox"
Os e-mails enviados para "abuse-mailbox" devem exigir intervenção manual em algum momento, por parte do destinatário, e não podem estar filtrados, pois isso poderia impedir, que em alguns casos, o envio de um relatório de abuso, por exemplo por spam, ao incluir a própria mensagem de spam ou URLs ou conteúdos geralmente classificados como spam, evite sua recepção.
A caixa de correio "abuse-mailbox" poderá enviar inicialmente uma resposta automática, por exemplo, designando um número de ticket, aplicando procedimentos de classificação, solicitando mais informações, etc. No entanto, não poderá requerer o uso de um formulário, pois isso implicaria que cada empresa que precise denunciar abusos, geralmente de forma automatizada,
seja forçada a desenvolver uma interface específica para cada caso de abuso, o que é inviável e ilógico, uma vez que faria com que o custo do processado dos abusos caísse em quem envia a reclamação e, portanto, é vítima de abuso, em vez de ser paga por aquele cujo cliente (e de quem recebe renda), causa o abuso.
Para fins de informação, vale a pena mencionar que o razoável é que a pessoa que denuncia o abuso, faça isso desde o primeiro momento e nesse primeiro relatório, enviando os logs ou cópia do spam (anexando um exemplo do e-mail de spam ou seus cabeçalhos completos) ou similares, que demonstrem o abuso. Da mesma forma, é razoável esperar que o e-mail inicial de auto-resposta indique que, se esses registros não tiverem sido enviados, não serão atendidos, dando assim a oportunidade de repetir o envio com a evidência pertinente. Isso permite relatórios automatizados, por exemplo, mediante fail2ban, SpamCop ou outros, com um custo mínimo para ambas as partes.
12.3. Objetivos da validação do "abuse-c"/"abuse-mailbox"
O procedimento, que deverá ser desenvolvido por LACNIC, deve atender aos seguintes objetivos:
1) Processo simples que garanta a sua funcionalidade e permita aos "helpdesk" que atendem os relatórios de abuso, verificar que os pedidos de validação são realmente provenientes de LACNIC e não de terceiras fontes (o que poderia envolver riscos de segurança), evitando, por exemplo, uma única URL "direta" para a validação.
2) Impedir um processo exclusivamente automatizado.
3) Confirmar que quem valida garante conhecer o procedimento, a política, que monitora regularmente o "abuse-mailbox", que toma medidas e responde ao relatório de abuso.
4) Prazo de validação “inicial” não superior a 15 dias.
5) Se não for validado corretamente, “escalado” com o receptor do recurso (LIR, usuário final, etc.) e um novo prazo, não superior a 15 dias.
Os prazos de validação "inicial" e "escalado" poderão ser modificados por LACNIC, se considerar apropriado, informando a comunidade dos motivos. Por exemplo, poderiam ser reduzidos uma vez que uma alta porcentagem de contatos tenha sido validada de forma inicial, de modo que a qualidade dos contatos é incrementada e o tempo de resposta para os casos de abuso é reduzido.
(como exemplo, propõe-se um procedimento detalhado em "Informações adicionais" desta proposta de política).
12.4. Validação do "abuse-c"/"abuse-mailbox"
LACNIC validará o cumprimento dos pontos acima, tanto no momento em que os atributos "abuse-c" e/ou "abuse-mailbox" são criados quanto modificados, periodicamente, não menos de duas vezes por ano e a qualquer momento que LACNIC considerar oportuno..
A frequência periódica de validação poderia ser modificada por LACNIC, se considerar apropriada, informando à comunidade os motivos. Por exemplo, uma única validação poderia ser realizada no primeiro ano, para facilitar o tempo de adaptação à política e, posteriormente, progressivamente, aumentar o número de validações anuais, chegando a ser inclusive trimestrais ou mensais, com o objetivo de aumentar a qualidade dos contatos.
A critério de LACNIC, em forma generalizada ou em casos específicos (por exemplo, para a confirmação em casos de escalado de acordo com o ponto 12.5), LACNIC, para realizar as referidas validações, poderá usar domínios que não sejam lacnic.*, e até mesmo modificar o assunto e o corpo da mensagem,
A violação por parte de qualquer organização, implicará inicialmente o bloqueio de "milacnic" para todos os recursos associados com essa organização, exceto para a atualização dos contatos abuse-c/abuse-mailbox, de tal forma que possam ser revalidados para permitir o desbloqueio de "milacnic".
LACNIC realizará um acompanhamento mais exaustivo e, no caso em que na validação automática seguinte continue sendo confirmado o descumprimento, agirá de acordo com as políticas e procedimentos pertinentes de LACNIC e, especialmente, "7.1. Recuperação de recursos”.
12.5. Mecanismo de escalado para LACNIC
CA fim de evitar engano (por exemplo, "abuse-mailbox" que respondem somente aos e-mails de LACNIC, a um determinado assunto ou corpo da mensagem), ou a violação do restante dos aspectos desta política (a incorreta ou não atenção dos casos de abuso) e, portanto, para garantir a qualidade dos serviços na região com os recursos alocados por LACNIC será disponibilizada uma caixa de correio (por exemplo, “escalado-abusos@lacnic.net”), que permita escalar as referidas situações, permitindo assim a revalidação (de acordo com o ponto 12.4 acima) e até a intermediação de LACNIC e, quando apropriado, a aplicação das políticas/procedimentos pertinentes e, principalmente, "7.1. Recuperação de recursos”.
Informações adicionaisExemplo de procedimento de validação.
1) A validação começa de forma automatizada, por parte de LACNIC, com o envio de DOIS e-mails consecutivos para o "abuse-mailbox".
2) Esses e-mails terão exclusivamente formato de texto (e, portanto, ocultam URLs que correspondem a ataques como "phishing" etc.).
3) O primeiro dos e-mails vai conter a URL onde a validação deve ser realizada, que será "validacion.lacnic.net", e poderá conter informações sobre o procedimento, extrato desta política, etc.
4) O segundo dos e-mails vai conter um código alfanumérico único de validação.
5) O receptor que atende o "abuse-mailbox" deverá acessar à URL e colar no formulário o código recebido no segundo e-mail.
6) Essa URL deverá estar projetada de forma de impedir um processo automatizado (por exemplo, "captcha") e conterá um texto que confirme que o receptor da validação conhece o procedimento, a política e que monitora regularmente o "abuse-mailbox" e que são tomadas medidas adequadas para resolver os abusos relatados e responder a eles, com um "checkbox" que deve ser necessariamente aceito.
7) O código alfanumérico apenas será válido por um máximo de 2 dias úteis.
8) Se o código não for inserido nesse prazo, o sistema marcará o "abuse-c" como "provisoriamente inválido" e alertará a equipe de LACNIC para que possa ser iniciado o acompanhamento personalizado com o receptor do recurso.
9) No caso de não obter uma resposta com a confirmação da correção da situação, em um período adicional de 3 dias úteis, o "abuse-c" será marcado de forma permanente como "inválido".
O processo de validação será repetido automaticamente (pontos 1 a 7 acima) e, neste caso, o "abuse-c" será marcado como "válido" se for satisfatório, caso contrário, seria um caso de descumprimento da política.
90 dias, de forma prudencial e a ser confirmado com LACNIC, para permitir que o pessoal desenvolva a ferramenta e que os LIR atualizem seus contatos "abuse-c".
ReferênciasUma proposta semelhante está sendo encaminhada no RIPE, embora ainda esteja em debate e tenha alcançado consenso. Trata-se de uma versão muito mais simples, e foi apresentada uma nova versão equivalente a esta mesma proposta. Em APNIC alcançou consenso uma versão equivalente a esta proposta. No AfriNIC, foi apresentada a mesma proposta.
Apresentada em:-
A proposta permite garantir e validar os contatos de abuso do WHOIS (abuse-c e abuse-mailbox) das organizações e poder assim informar os casos de abuso e resolvê-los.
Esta proposta visa resolver o problema e garantir a existência de um contato abuse-c correto e o processo para seu uso.
Justificativa(Descrever o problema que deseja solucionar)A política atual (ASN) não é clara em relação à obrigação de registrar um contato de abuse (abuse-c) nem ao formato específico, e se pode ser aplicada a outros casos de registros no WHOIS.
Como resultado, pode haver receptores de recursos de LACNIC que não têm esse contato registrado para seus recursos, ou ainda há casos de LIRs/ISPs, usuários finais ou outros, que usam uma caixa de correio inexistente ou que não está ativamente monitorada.
A falta de validação dos contatos tornou o relato de casos de abuso ineficaz, gerando problemas de segurança e custos para as vítimas.
Para tentar resolver este problema, é feita uma simples verificação periódica do contato de abuso, evitando assim custos desnecessários para terceiros.
A proposta garante que o custo de processar os abusos recaia sobre o receptor do recurso quem, direta ou indiretamente (seu cliente e de quem ele possivelmente recebe compensação pelo serviço), é responsável pelo abuso, em vez de recair sobre a vítima. Leve em conta que isso evita o possível agravamento, tempo e despesas legais para ambas as partes se forem para essa instância.
Para isso, o atributo abuse-c, que até agora era apenas referenciado para o objeto "aut-num", torna-se obrigatório nos objetos "inetnum" (tanto para o IPv4 quanto para o IPv6), e qualquer um que venha surgir no futuro. Este atributo é um contato de abuso, que irá conter no mínimo o atributo "abuse-mailbox".
Texto atualTexto atual: Não existe
---------
Texto novo:
12. Registro e validação de "abuse-c" e "abuse-mailbox"
12.1. Descrição do "abuse-c" e "abuse-mailbox"
Todos os recursos que usem os sistemas de registro de LACNIC devem incluir obrigatoriamente, nas entradas do WHOIS correspondentes, o atributo de contato abuse-c (contato de abuso) como mínimo com um e-mail abuse-mailbox válido, monitorado e devidamente atendido, que permita o envio de relatórios manuais ou automáticos de comportamentos abusivos, segurança e semelhantes.
O atributo abuse-mailbox deve estar disponível sem restrições via WHOIS, APIs e futuras tecnologias.
Levando em conta a natureza hierárquica dos objetos, os herdados de aqueles alocados diretamente por LACNIC (por exemplo, subdesignações), estar cobertos pelos objetos de nível superior e seu próprio atributo "abuse-c” é optativo.
Seguindo práticas usuais, outros atributos "e-mail" podem ser incluídos para outros fins.
12.2. Características do "abuse-mailbox"
Os e-mails enviados para "abuse-mailbox" devem exigir intervenção manual em algum momento, por parte do destinatário, e não podem ser filtrados, pois isso poderia impedir, em alguns casos, a recepção de um relatório de abuso. Por exemplo, um relatório de spam, ao incluir a própria mensagem de spam ou URLs ou conteúdos geralmente classificados como spam.
A caixa de correio "abuse-mailbox" poderá enviar inicialmente uma resposta automática, por exemplo, designando um número de bilhete, aplicando procedimentos de classificação, solicitando mais informações, etc. No entanto, não poderá requerer o uso de um formulário, pois isso implicaria que cada entidade que precisar denunciar abusos, geralmente de forma automatizada, seja forçada a desenvolver uma interface específica para cada receptor de recursos a quem tem que informar um abuso. Isso seria inviável, uma vez que faria recair o custo do processado dos abusos em quem envia a reclamação, vítima do abuso, em vez de ser pago por aquele que, direta ou indiretamente, provoca o abuso.
O razoável é que quem denuncia o abuso, faça isso no primeiro relatório, enviando informações suficientes (log, cópia de spam ou cabeçalhos completos, o equivalente em cada tipo de abuso). Da mesma forma, é razoável que o e-mail inicial de resposta automática indique que, se essas informações não tiverem sido enviadas, não será atendido, dando assim a oportunidade de repetir o envio com a evidência pertinente. Isso permite relatórios automatizados, por exemplo, mediante fail2ban, SpamCop ou outros, com um custo mínimo para ambas as partes. Normalmente, espera-se que, se um número de bilhete tiver sido designado, ele será mantido em todas as comunicações (tipicamente como parte do assunto).
12.3. Objetivos da validação do "abuse-c"/"abuse-mailbox"
O procedimento, que deverá ser desenvolvido por LACNIC, deve atender aos seguintes objetivos:
1) Garantir sua funcionalidade e permitir os "helpdesk" que lidam com os relatórios de abuso, a verificação de que a validação realmente vem de LACNIC e não de terceiras fontes (envolvendo riscos de segurança, evitando, por exemplo, uma única URL "direta" para a validação).
2) Impedir um processo exclusivamente automatizado.
3) Confirmar que quem valida:
• garante conhecer o procedimento e as políticas de LACNIC
• monitora regularmente o “abuse-mailbox”
• toma medidas a esse respeito
• responde ao relatório de abuso.
4) Prazo de validação “inicial” de 15 dias.
5) Se não for validado corretamente, “escalado” com o restante dos contatos disponíveis, em um prazo “adicional” de 15 dias.
Os prazos de validação poderão ser modificados a critério de LACNIC, informando a comunidade dos motivos.
(Na forma de recomendação, propõe-se um procedimento detalhado em "informações adicionais" desta proposta de política).
12.4. Validação do "abuse-c"/"abuse-mailbox"
LACNIC validará o cumprimento da política periodicamente, pelo menos duas vezes por ano, e quando os atributos "abuse-c" forem criados ou modificados.
A frequência de validação poderá ser modificada a critério de LACNIC, informando a comunidade dos motivos.
12.5. Dos incumprimentos
O incumprimento por parte de qualquer organização ocorre se não foi validado no prazo "inicial" ou "adicional". Isso implicará o bloqueio de MiLACNIC e medidas equivalentes nos sistemas dos NIRs, para todos os recursos associados a essa organização. Excluem-se as questões exclusivamente contratuais e relacionadas a pagamentos, bem como a atualização dos contatos abuse-c/abuse-mailbox, de modo que possam ser revalidados automaticamente para permitir o desbloqueio de MiLACNIC.
Qualquer acesso a MiLACNIC (ou sistemas equivalentes dos NIRs) durante o referido bloqueio, mostrará uma mensagem de aviso, incluindo o texto desta política, e para permitir continuar será necessário que essa mensagem seja "lida" até o final, e confirmada por meio de um check-box ou semelhante. Mecanismos equivalentes adaptados ao progresso da tecnologia poderão ser usados.
Se o incumprimento for mantido, LACNIC atuará de acordo com suas políticas e procedimentos pertinentes.
12.6. Mecanismo de escalado para LACNIC
Comportamentos fraudulentos (por exemplo, "abuse-mailbox” que respondem apenas a e-mails de LACNIC, a um assunto específico ou corpo da mensagem) ou o incumprimento dos demais aspectos desta política (incorreta ou não atenção aos casos de abuso), poderão ser denunciados a LACNIC, para sua revalidação segundo 12.4.
Texto atual: Não existe
---------
Texto novo:
12. Registro e validação de "abuse-c" e "abuse-mailbox"
12.1. Descrição do "abuse-c" e "abuse-mailbox"
Todos os recursos que usem os sistemas de registro de LACNIC devem incluir obrigatoriamente, nas entradas do WHOIS correspondentes, o atributo de contato abuse-c (contato de abuso) como mínimo com um e-mail abuse-mailbox válido, monitorado e devidamente atendido, que permita o envio de relatórios manuais ou automáticos de comportamentos abusivos, segurança e semelhantes.
O atributo abuse-mailbox deve estar disponível sem restrições via WHOIS, APIs e futuras tecnologias.
Levando em conta a natureza hierárquica dos objetos, os herdados de aqueles alocados diretamente por LACNIC (por exemplo, subdesignações), estar cobertos pelos objetos de nível superior e seu próprio atributo "abuse-c” é optativo.
Seguindo práticas usuais, outros atributos "e-mail" podem ser incluídos para outros fins.
12.2. Características do "abuse-mailbox"
Os e-mails enviados para "abuse-mailbox" devem exigir intervenção manual em algum momento, por parte do destinatário, e não podem ser filtrados, pois isso poderia impedir, em alguns casos, a recepção de um relatório de abuso. Por exemplo, um relatório de spam, ao incluir a própria mensagem de spam ou URLs ou conteúdos geralmente classificados como spam.
A caixa de correio "abuse-mailbox" poderá enviar inicialmente uma resposta automática, por exemplo, designando um número de bilhete, aplicando procedimentos de classificação, solicitando mais informações, etc. No entanto, não poderá requerer o uso de um formulário, pois isso implicaria que cada entidade que precisar denunciar abusos, geralmente de forma automatizada, seja forçada a desenvolver uma interface específica para cada receptor de recursos a quem tem que informar um abuso. Isso seria inviável, uma vez que faria recair o custo do processado dos abusos em quem envia a reclamação, vítima do abuso, em vez de ser pago por aquele que, direta ou indiretamente, provoca o abuso.
O razoável é que quem denuncia o abuso, faça isso no primeiro relatório, enviando informações suficientes (log, cópia de spam ou cabeçalhos completos, o equivalente em cada tipo de abuso). Da mesma forma, é razoável que o e-mail inicial de resposta automática indique que, se essas informações não tiverem sido enviadas, não será atendido, dando assim a oportunidade de repetir o envio com a evidência pertinente. Isso permite relatórios automatizados, por exemplo, mediante fail2ban, SpamCop ou outros, com um custo mínimo para ambas as partes. Normalmente, espera-se que, se um número de bilhete tiver sido designado, ele será mantido em todas as comunicações (tipicamente como parte do assunto).
12.3. Objetivos da validação do "abuse-c"/"abuse-mailbox"
O procedimento, que deverá ser desenvolvido por LACNIC, deve atender aos seguintes objetivos:
1) Garantir sua funcionalidade e permitir os "helpdesk" que lidam com os relatórios de abuso, a verificação de que a validação realmente vem de LACNIC e não de terceiras fontes (envolvendo riscos de segurança, evitando, por exemplo, uma única URL "direta" para a validação).
2) Impedir um processo exclusivamente automatizado.
3) Confirmar que quem valida:
• garante conhecer o procedimento e as políticas de LACNIC
• monitora regularmente o “abuse-mailbox”
• toma medidas a esse respeito
• responde ao relatório de abuso.
4) Prazo de validação “inicial” de 15 dias.
5) Se não for validado corretamente, “escalado” com o restante dos contatos disponíveis, em um prazo “adicional” de 15 dias.
Os prazos de validação poderão ser modificados a critério de LACNIC, informando a comunidade dos motivos.
(Na forma de recomendação, propõe-se um procedimento detalhado em "informações adicionais" desta proposta de política).
12.4. Validação do "abuse-c"/"abuse-mailbox"
LACNIC validará o cumprimento da política periodicamente, pelo menos duas vezes por ano, e quando os atributos "abuse-c" forem criados ou modificados.
A frequência de validação poderá ser modificada a critério de LACNIC, informando a comunidade dos motivos.
12.5. Dos incumprimentos
O incumprimento por parte de qualquer organização ocorre se não foi validado no prazo "inicial" ou "adicional". Isso implicará o bloqueio de MiLACNIC e medidas equivalentes nos sistemas dos NIRs, para todos os recursos associados a essa organização. Excluem-se as questões exclusivamente contratuais e relacionadas a pagamentos, bem como a atualização dos contatos abuse-c/abuse-mailbox, de modo que possam ser revalidados automaticamente para permitir o desbloqueio de MiLACNIC.
Qualquer acesso a MiLACNIC (ou sistemas equivalentes dos NIRs) durante o referido bloqueio, mostrará uma mensagem de aviso, incluindo o texto desta política, e para permitir continuar será necessário que essa mensagem seja "lida" até o final, e confirmada por meio de um check-box ou semelhante. Mecanismos equivalentes adaptados ao progresso da tecnologia poderão ser usados.
Se o incumprimento for mantido, LACNIC atuará de acordo com suas políticas e procedimentos pertinentes.
12.6. Mecanismo de escalado para LACNIC
Comportamentos fraudulentos (por exemplo, "abuse-mailbox” que respondem apenas a e-mails de LACNIC, a um assunto específico ou corpo da mensagem) ou o incumprimento dos demais aspectos desta política (incorreta ou não atenção aos casos de abuso), poderão ser denunciados a LACNIC, para sua revalidação segundo 12.4.
Nota (não deve ser incluído no manual de políticas): A seção atual “12. Apêndices "passa a ser" A. Apêndices ", no final do manual de políticas, e todas as referências a ela são renumeradas em todo o manual de políticas. Dessa forma, as novas seções do manual não requererão renumerações futuras, segundo o manual for "crescendo". O texto desta proposta torna-se, portanto, a seção 12, ou a considerada apropriada pelo pessoal no momento de sua implementação, uma vez que o consenso tenha sido alcançado.
O texto a seguir é um exemplo de procedimento de validação, considerando as práticas usuais nos "helpdesk" (mesas de ajuda), que, por exemplo, impedem clicar em um link html de um e-mail, para evitar casos de phishing ou outros. Mesmo quando este texto não faz parte do texto da política, recomenda-se sua consideração estrita, uma vez que é o resultado de discussões relacionadas a políticas de abuse-c na comunidade global.
1) A validação começa de forma automatizada, por parte de LACNIC, com o envio de DOIS e-mails consecutivos para o "abuse-mailbox".
2) Esses e-mails terão exclusivamente formato de texto (e, portanto, ocultam URLs que correspondem a ataques como "phishing" etc.).
3) A critério de LACNIC, de forma generalizada ou em casos específicos (por exemplo, para a confirmação em casos de escalado de acordo com o ponto 12.6), LACNIC, para realizar as referidas validações, poderá usar domínios diferentes a lacnic.*, e até mesmo modificar o assunto e corpo da mensagem.
4) O primeiro dos e-mails vai conter a URL onde a validação deve ser realizada, que será "validacion.lacnic.net", e poderá conter informações sobre o procedimento, extrato desta política, etc.
5) O segundo dos e-mails vai conter um código alfanumérico único de validação.
6) O receptor que atende o "abuse-mailbox", deverá acessar à URL e colar no formulário o código recebido no segundo e-mail.
7) Esta URL deverá estar projetada de forma de impedir um processo automatizado (por exemplo, "captcha") e conterá um texto que confirme que o receptor da validação conhece o procedimento, a política e que monitora regularmente o "abuse-mailbox" e que são tomadas medidas adequadas para resolver os abusos relatados e responder a eles, com um "checkbox" que deverá ser necessariamente aceito.
8) O código alfanumérico apenas será válido por um máximo de 15 dias.
9) Se o código não for inserido nesse prazo, o sistema marcará o "abuse-c" como "provisoriamente inválido" e alertará a equipe de LACNIC para que possa ser iniciado o acompanhamento personalizado com o receptor do recurso.
10) No caso de não obter uma resposta com a confirmação da correção da situação, em um prazo adicional de 15 dias, o "abuse-c" será marcado de forma permanente como "inválido".
11) O processo de validação será repetido automaticamente (pontos 1 a 7 acima) e, neste caso, o "abuse-c" será marcado como "válido" se for satisfatório, caso contrário, seria um caso de incumprimento da política.
12) LACNIC terá mecanismos (formulário, e-mail e outros no futuro) para facilitar o escalamento nos casos em que se queira denunciar uma violação desta política. Isso permitirá a revalidação (12.4) e a intervenção de LACNIC na aplicação das políticas, procedimentos e requisitos contratuais em vigor.
90 dias, de maneira prudencial e a confirmar com LACNIC, para permitir tanto à equipe o desenvolvimento da ferramenta, quanto aos receptores de recursos de LACNIC atualizar seus contatos abuse-c, LACNIC poderá enviar um lembrete com a ratificação da proposta por parte da Diretoria.
ReferênciasEm APNIC, uma versão equivalente a esta proposta chegou a consenso.
No RIPE, uma proposta semelhante foi adotada, mas apenas para verificação automática, e o recente debate na lista indicou precisamente a necessidade de fazê-lo de maneira "não exclusivamente automática", uma vez que o procedimento atual permite inúmeras fraudes.
Além disso, uma proposta equivalente está sendo processada e será publicada em breve.
Em AfriNIC e ARIN se apresentou uma proposta equivalente.
Apresentada em:-
A proposta permite garantir e validar os contatos de abuso do WHOIS (abuse-c e abuse-mailbox) das organizações e poder assim informar os casos de abuso e resolvê-los.
Esta proposta visa resolver o problema e garantir a existência de um contato abuse-c correto e o processo para seu uso.
Justificativa(Descrever o problema que deseja solucionar)A política atual (ASN) não é clara em relação à obrigação de registrar um contato de abuse (abuse-c) nem ao formato específico, e se pode ser aplicada a outros casos de registros no WHOIS.
Como resultado, pode haver receptores de recursos de LACNIC que não têm esse contato registrado para seus recursos, ou ainda há casos de LIRs/ISPs, usuários finais ou outros, que usam uma caixa de correio inexistente ou que não está ativamente monitorada.
A falta de validação dos contatos tornou o relato de casos de abuso ineficaz, gerando problemas de segurança e custos para as vítimas.
Para tentar resolver este problema, é feita uma simples verificação periódica do contato de abuso, evitando assim custos desnecessários para terceiros.
A proposta garante que o custo de processar os abusos recaia sobre o receptor do recurso quem, direta ou indiretamente (seu cliente e de quem ele possivelmente recebe compensação pelo serviço), é responsável pelo abuso, em vez de recair sobre a vítima. Leve em conta que isso evita o possível agravamento, tempo e despesas legais para ambas as partes se forem para essa instância.
Para isso, o atributo abuse-c, que até agora era apenas referenciado para o objeto "aut-num", torna-se obrigatório nos objetos "inetnum" (tanto para o IPv4 quanto para o IPv6), e qualquer um que venha surgir no futuro. Este atributo é um contato de abuso, que irá conter no mínimo o atributo "abuse-mailbox".
Texto atualTexto atual: Não existe
Texto novo:
12. Registro e validação de "abuse-c" e "abuse-mailbox"
12.1. Descrição do "abuse-c" e "abuse-mailbox"
Todos os recursos que usem os sistemas de registro de LACNIC devem incluir obrigatoriamente, nas entradas do WHOIS correspondentes, o atributo de contato abuse-c (contato de abuso) como mínimo com um e-mail abuse-mailbox válido, monitorado e devidamente atendido, que permita o envio de relatórios manuais ou automáticos de comportamentos abusivos, segurança e semelhantes.
O atributo abuse-mailbox deve estar disponível sem restrições via WHOIS, APIs e futuras tecnologias.
Levando em conta a natureza hierárquica dos objetos, os herdados de aqueles alocados diretamente por LACNIC (por exemplo, subdesignações), estar cobertos pelos objetos de nível superior e seu próprio atributo "abuse-c” é optativo.
Seguindo práticas usuais, outros atributos "e-mail" podem ser incluídos para outros fins.
12.2. Características do "abuse-mailbox"
Os e-mails enviados para "abuse-mailbox" devem exigir intervenção manual em algum momento, por parte do destinatário, e não podem ser filtrados, pois isso poderia impedir, em alguns casos, a recepção de um relatório de abuso. Por exemplo, um relatório de spam, ao incluir a própria mensagem de spam ou URLs ou conteúdos geralmente classificados como spam.
A caixa de correio "abuse-mailbox" poderá enviar inicialmente uma resposta automática, por exemplo, designando um número de bilhete, aplicando procedimentos de classificação, solicitando mais informações, etc. No entanto, não poderá requerer o uso de um formulário, pois isso implicaria que cada entidade que precisar denunciar abusos, geralmente de forma automatizada, seja forçada a desenvolver uma interface específica para cada receptor de recursos a quem tem que informar um abuso. Isso seria inviável, uma vez que faria recair o custo do processado dos abusos em quem envia a reclamação, vítima do abuso, em vez de ser pago por aquele que, direta ou indiretamente, provoca o abuso.
O razoável é que quem denuncia o abuso, faça isso no primeiro relatório, enviando informações suficientes (log, cópia de spam ou cabeçalhos completos, o equivalente em cada tipo de abuso). Da mesma forma, é razoável que o e-mail inicial de auto-resposta indique que, se essas informações não tiverem sido enviadas, não será atendido, dando assim a oportunidade de repetir o envio com a evidência pertinente. Isso permite relatórios automatizados, por exemplo, mediante fail2ban, SpamCop ou outros, com um custo mínimo para ambas as partes. Normalmente, espera-se que, se um número de bilhete tiver sido designado, ele será mantido em todas as comunicações (tipicamente como parte do assunto).
12.3. Objetivos da validação do "abuse-c"/"abuse-mailbox"
O procedimento, que deverá ser desenvolvido por LACNIC, deve atender aos seguintes objetivos:
1) Garantir sua funcionalidade e permitir os "helpdesk" que lidam com os relatórios de abuso, a verificação de que a validação realmente provem de LACNIC e não de terceiras fontes (envolvendo riscos de segurança, evitando, por exemplo, uma única URL "direta" para a validação).
2) Impedir um processo exclusivamente automatizado.
3) Confirmar que quem valida:
• garante conhecer o procedimento e as políticas de LACNIC
• monitora regularmente o “abuse-mailbox”
• toma medidas a esse respeito
• responde ao relatório de abuso.
4) Prazo de validação “inicial” de 15 dias.
5) Se não for validado corretamente, “escalado” com o restante dos contatos disponíveis, em um prazo “adicional” de 15 dias.
Os prazos de validação poderão ser modificados a critério de LACNIC, informando a comunidade dos motivos.
(na forma de recomendação, propõe-se um procedimento detalhado em "informações adicionais" desta proposta de política).
12.4. Validação do "abuse-c"/"abuse-mailbox"
LACNIC validará o cumprimento da política periodicamente, pelo menos duas vezes por ano, e quando os atributos "abuse-c" forem criados ou modificados.
A frequência de validação poderá ser modificada a critério de LACNIC, informando a comunidade dos motivos.
12.5. Dos incumprimentos
O incumprimento por parte de qualquer organização ocorre se não foi validado no prazo "inicial" ou "adicional". Isso implicará o bloqueio de MiLACNIC e medidas equivalentes nos sistemas dos NIRs, para todos os recursos associados a essa organização. Excluem-se as questões exclusivamente contratuais e relacionadas a pagamentos, bem como a atualização dos contatos abuse-c/abuse-mailbox, de modo que possam ser revalidados automaticamente para permitir o desbloqueio de MiLACNIC.
Qualquer acesso a MiLACNIC (ou sistemas equivalentes dos NIRs) durante o referido bloqueio, mostrará uma mensagem de aviso, incluindo o texto desta política, e para permitir continuar será necessário que essa mensagem seja "lida" até o final, e confirmada por meio de um check-box ou semelhante. Mecanismos equivalentes adaptados ao progresso da tecnologia poderão ser usados.
Se o incumprimento for mantido, LACNIC atuará de acordo com suas políticas e procedimentos pertinentes.
12.6. Mecanismo de escalado para LACNIC
Comportamentos fraudulentos (por exemplo, "abuse-mailbox” que respondem apenas a e-mails de LACNIC, a um assunto específico ou corpo da mensagem) ou o incumprimento dos demais aspectos desta política (incorreta ou não atenção aos casos de abuso), poderão ser denunciados a LACNIC, para sua revalidação segundo 12.4.
Texto novoTexto atual: Não existe
Texto novo:
12. Registro e validação de "abuse-c" e "abuse-mailbox"
12.1. Descrição do "abuse-c" e "abuse-mailbox"
Todos os recursos que usem os sistemas de registro de LACNIC devem incluir obrigatoriamente, nas entradas do WHOIS correspondentes, o atributo de contato abuse-c (contato de abuso) como mínimo com um e-mail abuse-mailbox válido, monitorado e devidamente atendido, que permita o envio de relatórios manuais ou automáticos de comportamentos abusivos, segurança e semelhantes.
O atributo abuse-mailbox deve estar disponível sem restrições via WHOIS, APIs e futuras tecnologias.
Levando em conta a natureza hierárquica dos objetos, os herdados de aqueles alocados diretamente por LACNIC (por exemplo, subdesignações), estar cobertos pelos objetos de nível superior e seu próprio atributo "abuse-c” é optativo.
Seguindo práticas usuais, outros atributos "e-mail" podem ser incluídos para outros fins.
12.2. Características do "abuse-mailbox"
Os e-mails enviados para "abuse-mailbox" devem exigir intervenção manual em algum momento, por parte do destinatário, e não podem ser filtrados, pois isso poderia impedir, em alguns casos, a recepção de um relatório de abuso. Por exemplo, um relatório de spam, ao incluir a própria mensagem de spam ou URLs ou conteúdos geralmente classificados como spam.
A caixa de correio "abuse-mailbox" poderá enviar inicialmente uma resposta automática, por exemplo, designando um número de bilhete, aplicando procedimentos de classificação, solicitando mais informações, etc. No entanto, não poderá requerer o uso de um formulário, pois isso implicaria que cada entidade que precisar denunciar abusos, geralmente de forma automatizada, seja forçada a desenvolver uma interface específica para cada receptor de recursos a quem tem que informar um abuso. Isso seria inviável, uma vez que faria recair o custo do processado dos abusos em quem envia a reclamação, vítima do abuso, em vez de ser pago por aquele que, direta ou indiretamente, provoca o abuso.
O razoável é que quem denuncia o abuso, faça isso no primeiro relatório, enviando informações suficientes (log, cópia de spam ou cabeçalhos completos, o equivalente em cada tipo de abuso). Da mesma forma, é razoável que o e-mail inicial de auto-resposta indique que, se essas informações não tiverem sido enviadas, não será atendido, dando assim a oportunidade de repetir o envio com a evidência pertinente. Isso permite relatórios automatizados, por exemplo, mediante fail2ban, SpamCop ou outros, com um custo mínimo para ambas as partes. Normalmente, espera-se que, se um número de bilhete tiver sido designado, ele será mantido em todas as comunicações (tipicamente como parte do assunto).
12.3. Objetivos da validação do "abuse-c"/"abuse-mailbox"
O procedimento, que deverá ser desenvolvido por LACNIC, deve atender aos seguintes objetivos:
1) Garantir sua funcionalidade e permitir os "helpdesk" que lidam com os relatórios de abuso, a verificação de que a validação realmente provem de LACNIC e não de terceiras fontes (envolvendo riscos de segurança, evitando, por exemplo, uma única URL "direta" para a validação).
2) Impedir um processo exclusivamente automatizado.
3) Confirmar que quem valida:
• garante conhecer o procedimento e as políticas de LACNIC
• monitora regularmente o “abuse-mailbox”
• toma medidas a esse respeito
• responde ao relatório de abuso.
4) Prazo de validação “inicial” de 15 dias.
5) Se não for validado corretamente, “escalado” com o restante dos contatos disponíveis, em um prazo “adicional” de 15 dias.
Os prazos de validação poderão ser modificados a critério de LACNIC, informando a comunidade dos motivos.
(na forma de recomendação, propõe-se um procedimento detalhado em "informações adicionais" desta proposta de política).
12.4. Validação do "abuse-c"/"abuse-mailbox"
LACNIC validará o cumprimento da política periodicamente, pelo menos duas vezes por ano, e quando os atributos "abuse-c" forem criados ou modificados.
A frequência de validação poderá ser modificada a critério de LACNIC, informando a comunidade dos motivos.
12.5. Dos incumprimentos
O incumprimento por parte de qualquer organização ocorre se não foi validado no prazo "inicial" ou "adicional". Isso implicará o bloqueio de MiLACNIC e medidas equivalentes nos sistemas dos NIRs, para todos os recursos associados a essa organização. Excluem-se as questões exclusivamente contratuais e relacionadas a pagamentos, bem como a atualização dos contatos abuse-c/abuse-mailbox, de modo que possam ser revalidados automaticamente para permitir o desbloqueio de MiLACNIC.
Qualquer acesso a MiLACNIC (ou sistemas equivalentes dos NIRs) durante o referido bloqueio, mostrará uma mensagem de aviso, incluindo o texto desta política, e para permitir continuar será necessário que essa mensagem seja "lida" até o final, e confirmada por meio de um check-box ou semelhante. Mecanismos equivalentes adaptados ao progresso da tecnologia poderão ser usados.
Se o incumprimento for mantido, LACNIC atuará de acordo com suas políticas e procedimentos pertinentes.
12.6. Mecanismo de escalado para LACNIC
Comportamentos fraudulentos (por exemplo, "abuse-mailbox” que respondem apenas a e-mails de LACNIC, a um assunto específico ou corpo da mensagem) ou o incumprimento dos demais aspectos desta política (incorreta ou não atenção aos casos de abuso), poderão ser denunciados a LACNIC, para sua revalidação segundo 12.4.
Informações adicionaisNota (não deve ser incluído no manual de políticas):
A seção atual “12. Apêndices "passa a ser" A. Apêndices ", no final do manual de políticas, e todas as referências a ela são renumeradas em todo o manual de políticas. Dessa forma, as novas seções do manual não requererão renumerações futuras, segundo o manual for "crescendo". O texto desta proposta torna-se, portanto, a seção 12, ou a considerada apropriada pelo pessoal no momento de sua implementação, uma vez que o consenso tenha sido alcançado.
O texto a seguir é um exemplo de procedimento de validação, considerando as práticas usuais nos "helpdesk" (mesas de ajuda), que, por exemplo, impedem clicar em um link html de um e-mail, para evitar casos de phishing ou outros. Mesmo quando este texto não faz parte do texto da política, recomenda-se sua consideração estrita, uma vez que é o resultado de discussões relacionadas a políticas de abuse-c na comunidade global.
1) A validação começa de forma automatizada, por parte de LACNIC, com o envio de DOIS e-mails consecutivos para o "abuse-mailbox”.
2) Esses e-mails terão exclusivamente formato texto (e, portanto, ocultar URLs que correspondam a ataques como "phishing" etc.).
3) A critério de LACNIC, de forma generalizada ou em casos específicos (por exemplo, para a confirmação em casos de escalado de acordo com o ponto 12.6), LACNIC, poderá usar outros domínios além do lacnic.*, e inclusive modificar o assunto e corpo da mensagem, para realizar ditas validações de forma mais eficaz.
4) O primeiro dos e-mails vai conter a URL onde a validação deve ser realizada, que será "validacion.lacnic.net", e poderá conter informações sobre o procedimento, extrato desta política, etc.
5) O segundo dos e-mails vai conter um código alfanumérico único de validação.
6) O receptor que atende o "abuse-mailbox", deverá acessar à URL e inserir no formulário o código recebido no segundo e-mail.
7) Esta URL deverá estar projetada de forma de impedir um processo automatizado (por exemplo, "captcha") e conterá um texto que confirme que o receptor da validação conhece o procedimento, a política e que monitora regularmente o "abuse-mailbox" e que são tomadas medidas adequadas para resolver os abusos relatados e responder a eles, com um "checkbox" que deverá ser necessariamente aceito.
8) O código alfanumérico apenas será válido por um máximo de 15 dias.
9) Se o código não for inserido nesse prazo, o sistema marcará o "abuse-c" como "provisoriamente inválido" e alertará a equipe de LACNIC para que possa ser iniciado o acompanhamento personalizado com o receptor do recurso.
10) No caso de não obter uma resposta com a confirmação da correção da situação, em um prazo adicional de 15 dias, o "abuse-c" será marcado de forma permanente como "inválido".
11) O processo de validação será repetido automaticamente (pontos 1 a 7 acima) e, neste caso, o "abuse-c" será marcado como "válido" se for satisfatório, caso contrário, seria um caso de descumprimento da política.
12) LACNIC terá mecanismos (formulário, e-mail e outros no futuro) para facilitar o escalamento nos casos em que se queira denunciar uma violação desta política. Isso permitirá a revalidação (12.4) e a intervenção de LACNIC na aplicação das políticas, procedimentos e requisitos contratuais em vigor.
-
Referências-
Apresentada em:LACNIC 31 (06/05/2019)
A proposta permite garantir e validar os contatos de abuso do WHOIS (abuse-c e abuse-mailbox) das organizações e poder assim informar os casos de abuso e resolvê-los.
Esta proposta visa resolver o problema e garantir a existência de um contato abuse-c correto e o processo para seu uso.
Justificativa(Descrever o problema que deseja solucionar)A política atual (ASN) não é clara em relação à obrigação de registrar um contato de abuse (abuse-c) nem ao formato específico, e se pode ser aplicada a outros casos de registros no WHOIS.
Como resultado, pode haver receptores de recursos de LACNIC que não têm esse contato registrado para seus recursos, ou ainda há casos de LIRs/ISPs, usuários finais ou outros, que usam uma caixa de correio inexistente ou que não está ativamente monitorada.
A falta de validação dos contatos tornou o relato de casos de abuso ineficaz, gerando problemas de segurança e custos para as vítimas.
Para tentar resolver este problema, é feita uma simples verificação periódica do contato de abuso, evitando assim custos desnecessários para terceiros.
A proposta garante que o custo de processar os abusos recaia sobre o receptor do recurso quem, direta ou indiretamente (seu cliente e de quem ele possivelmente recebe compensação pelo serviço), é responsável pelo abuso, em vez de recair sobre a vítima. Leve em conta que isso evita o possível agravamento, tempo e despesas legais para ambas as partes se forem para essa instância.
Para isso, o atributo abuse-c, que até agora era apenas referenciado para o objeto "aut-num", torna-se obrigatório nos objetos "inetnum" (tanto para o IPv4 quanto para o IPv6), e qualquer um que venha surgir no futuro. Este atributo é um contato de abuso, que irá conter no mínimo o atributo "abuse-mailbox".
Texto atualTexto atual:
Não existe
Texto novo:
12. Registro e validação de "abuse-c" e "abuse-mailbox"
12.1. Descrição do "abuse-c" e "abuse-mailbox"
Todos os recursos que usem os sistemas de registro de LACNIC devem incluir obrigatoriamente, nas entradas do WHOIS correspondentes, o atributo de contato abuse-c (contato de abuso) como mínimo com um e-mail abuse-mailbox válido, monitorado e devidamente atendido, que permita o envio de relatórios manuais ou automáticos de comportamentos abusivos, segurança e semelhantes.
O atributo abuse-mailbox deve estar disponível sem restrições via WHOIS, APIs e futuras tecnologias.
Levando em conta a natureza hierárquica dos objetos, os herdados de aqueles alocados diretamente por LACNIC (por exemplo, subdesignações), são cobertos pelos objetos de nível superior e seu próprio atributo "abuse-c” é optativo.
Seguindo práticas usuais, outros atributos "e-mail" podem ser incluídos para outros fins.
12.2. Acerca do "abuse-mailbox"
O “abuse-mailbox” possui as seguintes características:
• Requer intervenção do destinatário.
• Não deve exigir o uso de um formulário para denunciar um abuso.
• Deve garantir que as denúncias de abuso, logs, cabeçalhos, exemplos etc., relacionadas ao caso de abuso, sejam recebidas.
12.3. Objetivos da validação do "abuse-c"/"abuse-mailbox"
O procedimento, que deverá ser desenvolvido pelo LACNIC, deve atender aos seguintes objetivos:
1) Processo simples que garanta sua funcionalidade e o cumprimento de sua finalidade.
2) Confirmar que quem valida:
• garante conhecer o procedimento e as políticas de LACNIC
• monitora regularmente o “abuse-mailbox”
• toma medidas a esse respeito
• responde ao relatório de abuso.
3) Prazo de validação “inicial” de 15 dias.
4) Se não for validado corretamente, escalado, por qualquer meio possível, com o restante dos contatos disponíveis, em um prazo “adicional” de 15 dias.
12.4. Validação do "abuse-c"/"abuse-mailbox"
LACNIC validará o cumprimento da política periodicamente, pelo menos duas vezes por ano, e quando os atributos "abuse-c" forem criados ou modificados.
O incumprimento por parte de qualquer organização ocorre se não foi validado no prazo "inicial" ou "adicional".
12.5. Mecanismo de escalado para LACNIC
Comportamentos fraudulentos (por exemplo, "abuse-mailbox” que respondem apenas a e-mails de LACNIC, a um assunto específico ou corpo da mensagem) ou o incumprimento dos demais aspectos desta política (incorreta ou não atenção aos casos de abuso), poderão ser denunciados a LACNIC, para sua revalidação segundo 12.4.
Texto novoTexto atual:
Não existe
Texto novo:
12. Registro e validação de "abuse-c" e "abuse-mailbox"
12.1. Descrição do "abuse-c" e "abuse-mailbox"
Todos os recursos que usem os sistemas de registro de LACNIC devem incluir obrigatoriamente, nas entradas do WHOIS correspondentes, o atributo de contato abuse-c (contato de abuso) como mínimo com um e-mail abuse-mailbox válido, monitorado e devidamente atendido, que permita o envio de relatórios manuais ou automáticos de comportamentos abusivos, segurança e semelhantes.
O atributo abuse-mailbox deve estar disponível sem restrições via WHOIS, APIs e futuras tecnologias.
Levando em conta a natureza hierárquica dos objetos, os herdados de aqueles alocados diretamente por LACNIC (por exemplo, subdesignações), são cobertos pelos objetos de nível superior e seu próprio atributo "abuse-c” é optativo.
Seguindo práticas usuais, outros atributos "e-mail" podem ser incluídos para outros fins.
12.2. Acerca do "abuse-mailbox"
O “abuse-mailbox” possui as seguintes características:
• Requer intervenção do destinatário.
• Não deve exigir o uso de um formulário para denunciar um abuso.
• Deve garantir que as denúncias de abuso, logs, cabeçalhos, exemplos etc., relacionadas ao caso de abuso, sejam recebidas.
12.3. Objetivos da validação do "abuse-c"/"abuse-mailbox"
O procedimento, que deverá ser desenvolvido pelo LACNIC, deve atender aos seguintes objetivos:
1) Processo simples que garanta sua funcionalidade e o cumprimento de sua finalidade.
2) Confirmar que quem valida:
• garante conhecer o procedimento e as políticas de LACNIC
• monitora regularmente o “abuse-mailbox”
• toma medidas a esse respeito
• responde ao relatório de abuso.
3) Prazo de validação “inicial” de 15 dias.
4) Se não for validado corretamente, escalado, por qualquer meio possível, com o restante dos contatos disponíveis, em um prazo “adicional” de 15 dias.
12.4. Validação do "abuse-c"/"abuse-mailbox"
LACNIC validará o cumprimento da política periodicamente, pelo menos duas vezes por ano, e quando os atributos "abuse-c" forem criados ou modificados.
O incumprimento por parte de qualquer organização ocorre se não foi validado no prazo "inicial" ou "adicional".
12.5. Mecanismo de escalado para LACNIC
Comportamentos fraudulentos (por exemplo, "abuse-mailbox” que respondem apenas a e-mails de LACNIC, a um assunto específico ou corpo da mensagem) ou o incumprimento dos demais aspectos desta política (incorreta ou não atenção aos casos de abuso), poderão ser denunciados a LACNIC, para sua revalidação segundo 12.4.
Informações adicionaisNota (não deve ser incluído no manual de políticas): A seção atual “12. Apêndices "passa a ser" A. Apêndices ", no final do manual de políticas, e todas as referências a ela são renumeradas em todo o manual de políticas. Dessa forma, as novas seções do manual não requererão renumerações futuras, segundo o manual for "crescendo". O texto desta proposta torna-se, portanto, a seção 12, ou a considerada apropriada pelo pessoal no momento de sua implementação, uma vez que o consenso tenha sido alcançado.
Os prazos de validação "inicial" e "escalado" podem ser modificados por LACNIC, se for considerado apropriado, desde que a comunidade seja informada sobre os motivos dessa mudança. Por exemplo, na fase inicial da implementação, esses períodos poderiam ser estendidos e ajustados progressivamente à medida que uma porcentagem maior de contatos seja verificada.
Igualmente, a frequência da validação periódica pode ser modificada por LACNIC, se considerar necessário, informando também à comunidade acerca dos motivos. Por exemplo, no primeiro ano, uma única validação poderia ser realizada para facilitar o cumprimento da política, e o número de validações aumentar progressivamente, talvez até trimestralmente, a fim de melhorar a qualidade dos contatos.
O texto a seguir é um exemplo de procedimento de validação, considerando as práticas usuais nos "helpdesk" (mesas de ajuda), que, por exemplo, impedem clicar em um link html de um e-mail, para evitar casos de phishing ou outros. Mesmo quando este texto não faz parte do texto da política, recomenda-se sua consideração estrita, uma vez que é o resultado de discussões relacionadas a políticas de abuse-c na comunidade global.
(Veja versão anterior, o formulário limita o número de caracteres).
Tempo de implementação-
Referências-
Apresentada em:LACNIC 32 (06/10/2019)