Atualização da política de contato de abuso (Draft 3) Arquivado

Proposta

1.0 Resumo do problema tratado nesta proposta

A política atual não implica a obrigação de registrar um contato de abuso e especifica um formato para comunicação pessoal e para “denúncia automática”, que em comparação com outros RIRs torna-se confuso, pois um único e-mail será mais eficiente, pois, no final, os relatórios são copiados para os dois e-mails.

Como resultado, alguns detentores de recursos podem não ter essas informações de contato registradas e atualizadas para seus recursos. De fato, existem até casos de caixas de correio inexistentes ou que não são monitoradas ativamente.

Na prática, esse contato se torna ineficaz para denunciar abusos e geralmente gera problemas de segurança e custos para as vítimas.

Esta proposta visa solucionar este problema e garantir a existência de um contato abuse-c adequado e o processo para sua utilização, mais uniforme em todas as RIRs, a fim de facilitar a denúncia de abuso entre regiões. 

As referências políticas existentes a um “Documento de Boas Práticas”, que não é considerado obrigatório e, de fato, não estão sendo usadas pela comunidade. Essa proposta não altera o escopo desse documento e, de fato, um vínculo entre os poucos objetos IRT existentes e o novo deve ser estabelecido automaticamente.

Desta forma, o contato de abuso do AfriNIC estará alinhado com outros RIRs. APNIC agora está usando o IRT, mas como uma proposta equivalente foi aceita, um “link” (alias) automatizado para o IRT pré-existente será criado, de modo que abuse-c e abuse-mailbox prevalecem.

Não há necessidade de excluir os outros dados opcionais hoje incluídos no IRT. Essa política apenas garante que a caixa de correio de abuso esteja disponível e verificada periodicamente.

 

2.0 Resumo de como esta proposta aborda o problema

A comunidade da Internet é baseada na colaboração. No entanto, em muitos casos, isso não é suficiente e todos precisamos entrar em contato com os LIRs que podem estar enfrentando problemas em suas redes e desconhecem a situação.

Esta proposta cria uma nova seção no Manual de Política para resolver esse problema por meio de uma verificação simples e periódica, e estabelece as regras básicas para a realização dessa verificação e, assim, evita custos desnecessários a terceiros que precisam entrar em contato com as pessoas responsáveis ​​pela solução do problema. abusos de uma rede específica. 

A proposta garante que o custo do processamento do abuso recaia sobre o detentor do recurso cujo cliente está causando o abuso (e de quem ele recebe compensação financeira pelo serviço), em vez de recair sobre a vítima, como seria o caso se eles tivessem recorrer aos tribunais, evitando custos (advogados, solicitadores etc.) e economizando tempo para ambas as partes.

Para isso, o atributo abuse-c se torna obrigatório nos objetos "aut-num", "inetnum" e "inet6num", assim como em qualquer outro que possa ser usado no futuro. Este atributo é um contato de abuso, que deve conter pelo menos o atributo "abuse-mailbox".

Espera-se que a proposta seja implementada em 90 dias, a ser confirmada pelo AfriNIC, um prazo razoável para permitir que a equipe desenvolva a ferramenta e os LIRs atualizem seus contatos de abuso-c.

 

3. Proposta 

3.1 Alterando 8.0 do CPM, como segue:

Atual	Proposto
8.1 Introdução Esta política especifica um objeto dedicado que deve ser usado como o local preferido para publicar informações de contato público de abuso na região de serviço do AFRINIC.  O objeto mencionado pode ser referenciado nos objetos inetnum, inet6num e aut-num no AFRINIC whois Base de dados. Ele fornece uma maneira mais precisa e eficiente para denúncias de abuso chegarem ao contato de rede correto	8.1 Introdução Esta política especifica um objeto obrigatório que deve ser usado para publicar informações de contato público de abuso na região de serviço do AFRINIC. O objeto mencionado deve ser referenciado nos objetos inetnum, inet6num e aut-num no AFRINIC whois Base de dados. Ele fornece uma maneira mais precisa e eficiente para denúncias de abuso chegarem ao contato correto.
8.2 Detalhes da política: Para disponibilizar um novo ou usar um já existente whois objeto de banco de dados que implementa as seguintes propriedades: Uma referência única por inetnum, inet6num e aut-num Contém 2 atributos de email: "e-mail:" para comunicação pessoal "abuse-mailbox:" para manipulação automática de relatórios O objeto deve ser acessível através do whois protocolo. AFRINIC para publicar um Documento de boas práticas que incentiva todos os membros a usar ativamente o objeto para publicar informações de contato de abuso.	8.2 Descrição de “abuse-c” e “abuse-mailbox” Os recursos alocados / atribuídos pelo AfriNIC devem incluir um atributo de contato obrigatório "abuse-c" (contato de abuso) em seus correspondentes WHOIS entrada, com pelo menos uma caixa de entrada de e-mail válida, monitorada e ativamente gerenciada (caixa de correio de abuso) destinada a receber relatórios manuais ou automáticos sobre comportamento abusivo, questões de segurança e similares. O atributo "abuse-mailbox" deve estar disponível de forma irrestrita via whois, APIs e técnicas futuras.  Considerando a natureza hierárquica dos objetos de endereço IP, os objetos filhos daqueles distribuídos diretamente pelo AfriNIC podem ser cobertos por objetos pai ou podem ter seu próprio atributo "abuse-c". Seguindo as práticas usuais, outros atributos de "e-mail" podem ser incluídos para outros fins.
8.3 Vantagens e desvantagens da política 8.3.1 Vantagens As redes poderão fornecer suas próprias informações de contato direto para os departamentos de abuso. As reclamações de abuso não serão mais enviadas para o contato "errado". Isso permite uma maior flexibilidade administrativa e operacional, e uma manipulação mais rápida do abuso será possível.   8.3.2 Desvantagens Este objeto, como todos os outros objetos existentes, enfrentará o problema de precisão de dados. Esta política visa resolver o problema da falta de lugar para informações de contato abusivas e não vai melhorar a precisão dos dados no whois base de dados. No entanto, sugere-se à AFRINIC que ofereça uma forma de receber relatos sobre objetos que não funcionam ou não são precisos.	8.3 Sobre a "caixa de correio de abuso" Os e-mails enviados para "caixa de correio de abuso" devem exigir intervenção manual do destinatário em algum momento e podem não ser filtrados, porque em certos casos isso pode impedir o recebimento de relatórios de abuso. Por exemplo, em um caso de spam em que o relatório de abuso pode incluir a própria mensagem de spam ou URLs ou conteúdo geralmente classificado como spam. A "caixa de correio de abuso" pode enviar inicialmente uma resposta automática, por exemplo, atribuindo um número de tíquete, aplicando procedimentos de classificação, solicitando mais informações, etc. No entanto, não deve exigir que o relator de abuso preencha um formulário, pois isso implicará que cada empresa que precisa relatar casos de abuso (uma tarefa que é normalmente automatizada), seria forçada a desenvolver uma interface específica para cada ISP no mundo que exige o preenchimento de formulários, o que não é viável nem lógico, pois colocaria o custo de processar o abuso sobre aqueles que apresentam a reclamação e, portanto, são vítimas do abuso, em vez de ser pago por aqueles cujo cliente causa o abuso (e de quem obtém rendimentos).  A título de informação, é importante notar que é razoável esperar que o procedimento de denúncia de abuso envie, com a denúncia de abuso inicial, os logs, uma cópia da mensagem de spam (anexando um exemplo de e-mail de spam ou seus cabeçalhos completos) , ou evidência equivalente (dependendo do tipo de abuso). Da mesma forma, é razoável esperar que o e-mail de resposta automática inicial possa especificar que a reclamação não será processada a menos que tal evidência tenha sido enviada, permitindo assim ao remetente a oportunidade de repetir a apresentação e incluir evidências relevantes. Isso permite relatórios automáticos, por exemplo, via fail2ban, SpamCop ou outros, mantendo os custos no mínimo para ambas as partes envolvidas. Normalmente, se um número de tíquete foi gerado, ele deve ser mantido (normalmente como parte do assunto) por meio de comunicações sucessivas.
	8.4 Objetivos da validação "abuse-c" / "abuse-mailbox" O procedimento, que será desenvolvido pela AFRINIC, deve atender aos seguintes objetivos: Um processo simples que garante a sua funcionalidade e permite que os helpdesks que tratam das denúncias de abusos verifiquem se as solicitações de validação realmente vêm da AFRINIC e não de terceiros (o que pode envolver riscos de segurança), evitando, por exemplo, um único URL "direto" para validação. Evite o processamento exclusivamente automatizado. Confirme se a pessoa que realiza a validação entende o procedimento e a política, se ela monitora regularmente a "caixa de correio de abuso", se as medidas são tomadas e se o relatório de abuso recebe uma resposta. Período de validação não superior a 15 dias. Se a validação falhar, avance para o LIR e defina um novo período de validação que não exceda 15 dias. Os períodos de validação “inicial” e “escalonamento” podem ser modificados pela AFRINIC, se considerado apropriado, informando a comunidade sobre a motivação. Por exemplo, pode ser mais longo para a primeira validação, uma vez que esta política é implementada, e encurtado depois quando a porcentagem de falhas diminui, então a qualidade dos contatos aumenta e, consequentemente, uma diminuição nos tempos médios de resposta ao abuso pode ser esperada. (A título de exemplo, um procedimento detalhado está incluído nesta proposta de política em "Informações Adicionais").
	8.5 Validação de "abuse-c" / "abuse-mailbox" O AFRINIC validará a conformidade com os itens acima, quando os atributos "abuse-c" e / ou "abuse-mailbox" forem criados ou atualizados, bem como periodicamente, pelo menos uma vez a cada 6 meses, e sempre que o AFRINIC considerar adequado. A falta de conformidade levará a um acompanhamento mais exaustivo, avisos e bloqueio de determinados serviços, a critério da AFRINIC, de acordo com as políticas / procedimentos relevantes. A frequência da validação periódica pode ser modificada se o AFRINIC considerar apropriado e informar a comunidade das suas razões. Por exemplo, uma única validação poderia ser feita no primeiro ano, para facilitar a aderência à política, e depois o número de validações anuais poderia aumentar progressivamente, chegando até mesmo a trimestrais, com o objetivo de melhorar a qualidade dos contatos.
	8.6 Encaminhamento para AFRINIC A fim de permitir o escalonamento de comportamento fraudulento (por exemplo, uma "caixa de correio de abuso" que responde apenas aos e-mails da AFRINIC ou a mensagens com um assunto ou conteúdo específico), ou o não cumprimento dos demais aspectos desta política (incorreto ou falta de resposta aos casos de abuso), um método de escalonamento deve ser fornecido, permitindo assim uma revalidação (de acordo com a seção 8.5 acima).

 

3.2 Informações adicionais:

Uma vez que esta proposta seja implementada, AFRINIC publicará o IRT como um alias para o abuse-c, a fim de facilitar a busca em whois para as mesmas informações, independentemente de estar procurando por abuse-c ou IRT. O resto das informações reais no IRT, podem ser mantidas de acordo com as diretrizes reais (que deverão ser atualizadas AFRINIC). Isso é feito a fim de assimilar o IRT à maioria dos RIRs onde há abuso-c. 

Exemplo de procedimento de validação. 

1. AFRINIC inicia a validação automaticamente, enviando DOIS emails consecutivos para a "caixa de correio de abuso". 

2. Esses emails serão enviados contendo apenas texto simples.

3. A critério da AFRINIC, em geral ou em casos específicos (por exemplo, para confirmação em casos de escalonamento sob 8.6), a AFRINIC pode usar domínios diferentes do afrinic. * E até mesmo modificar o assunto e o corpo da mensagem, a fim de realizar essas validações de forma mais eficaz.

4. O primeiro e-mail conterá o URL onde será realizada a validação ("validacion.afrinic.net") e poderá conter informações sobre o procedimento, um breve resumo desta política, etc.

5. O segundo e-mail conterá um código de validação alfanumérico exclusivo. 

6. O responsável pela “caixa postal de abuso” deve ir até a URL e colar o código recebido no segundo e-mail do formulário.

7. Este URL deve ser desenhado de forma a impedir a utilização de um processo automatizado (por exemplo, "captcha"). Além disso, deve conter um texto que confirme que a pessoa que realiza a validação compreende o procedimento e a política, que monitora regularmente a "caixa de correio de abuso", que medidas são tomadas para resolver os casos de abuso relatados e que o relatório de abuso recebe uma resposta, com uma "caixa de seleção" que deve ser aceita para prosseguir.

8. O código alfanumérico só será válido por um período máximo de 15 dias úteis. 

9. Se o código não for inserido dentro desse tempo, o sistema marcará o "abuse-c" como "temporariamente inválido" e alertará a equipe da AFRINIC para que possam iniciar um acompanhamento personalizado com o detentor do recurso.

10. Se nenhuma resposta for recebida confirmando que a situação foi corrigida, após um período adicional de 15 dias úteis, o "abuse-c" será permanentemente marcado como "inválido".

11. A AFRINIC deve garantir que todos os meios possíveis de "avisar" o detentor do recurso sejam colocados em prática, como e-mails periódicos para outras caixas de e-mail, pop-ups de alerta, etc. Todos eles devem conter o texto da política e lembretes sobre as consequências em caso de violação contínua da política. Meios de bloquear o acesso a certos serviços também devem ser considerados.

12. O processo de validação será repetido automaticamente (itens 1 a 8 acima). Se for satisfatório, o "abuse-c" será marcado como "válido"; caso contrário, será considerado uma violação da política. 

13. Deve haver ferramentas como um formulário, caixa de correio (por exemplo, uma caixa de correio como "Este endereço de e-mail está protegido contra spambots. Você deve habilitar o JavaScript para visualizá-lo."), ou outros no futuro, para escalar o incumprimento desta política e mesmo a intermediação da AFRINIC e, se for caso disso, a aplicação das políticas / procedimentos pertinentes, especialmente aqueles relacionados com a revogação de recursos.

 

Referências

Uma proposta equivalente foi aceita no APNIC e está em discussão nas regiões ARIN, LACNIC e RIPE.

 

Avaliação da equipe

Versão PDF

Proposta	AFPUB-2018-GEN-001-DRAFT03
Título	Atualização da política de contato de abuso - v3
UR da proposta	https://afrinic.net/policy/proposals/2018-gen-001-d3#proposal
Avaliadas	20 de Julho de 2019

1.0 Entendimento da proposta pela equipe

1. Texto da política de substituição para CPM 8.0 atual (Informações de contato de abuso) - [seção 8.1]
2. Introduz um atributo obrigatório "abuse-c" em inetnum, inet6num e aut-num whois objetos de banco de dados. O valor deste atributo é um endereço de e-mail (abuse-mailbox), para o qual todas as informações relacionadas ao abuso devem ser enviadas. A caixa de correio de abuso é opcional em objetos filho de alocações diretas dos pais ou atribuições emitidas pela AFRINIC - [seção 8.2]
3. A caixa de correio de abuso deve ser válida e ativamente monitorada por meio de verificação de período - [seção 8.2]
4. O e-mail enviado para a caixa de correio de abuso deve precisar de intervenção manual do destinatário em algum momento- [seção 8.3]
5. AFRINIC deve provisionar um sistema para validar a caixa de correio de abuso. O processo real é deixado ao critério da equipe AFRINIC, mas poderia seguir um procedimento de exemplo na seção 3.2 da proposta de política, com um intervalo mínimo de validação recomendado de pelo menos uma vez a cada 6 meses - [seção 8.4]
6. As caixas de correio Abuse-c que falharem nos testes de validação levarão ao bloqueio eventual de certos serviços, a critério da AFRINIC (e de acordo com as políticas / procedimentos relevantes) - [seção 8.5]
7. Um mecanismo de encaminhamento para o AFRINIC deve ser fornecido, onde qualquer preocupação com o processo de validação pode ser relatada pela comunidade e / ou membros. Isso também pode ajudar nas revalidações manuais. - [seg 8.6]

2.0 Comentários da equipe

1. Já existe uma solução através do objeto IRT, que atualmente é opcional - (e que parece atender à intenção da proposta) - que pode ser tornada obrigatória para objetos de recursos emitidos diretamente pela AFRINIC. Uma vantagem adicional de usar o IRT é que ele pode conter mais informações do que apenas um endereço de e-mail, como endereço físico, números de telefone e chaves PGP para comunicação segura. 
2. Durante a Reunião de Políticas Públicas AFRINIC30, o autor esclareceu que o IRT pode ser um 'pseudônimo' do abuso-c. Observamos, no entanto, que é confuso usar IRT como um apelido para abuse-c e vice-versa - não saberíamos como implementar tal requisito, a menos que o autor forneça especificações detalhadas por meio da proposta de política ou do (DBWG ) grupo de trabalho do banco de dados.
3. Na proposta 8.5, onde as caixas de correio abuse-c que falham nos testes de validação levarão a um eventual bloqueio de certos serviços, a critério da AFRINIC (e de acordo com as políticas / procedimentos relevantes). A proposta de política precisa ser clara sobre quais serviços específicos devem ser bloqueados. No entanto, é importante observar que, sem essa cláusula em primeiro lugar, uma violação da política (como a falta de abuso válido-c se esta proposta for aprovada) equivale a uma violação do RSA, o que pode levar à eventual revogação de o mesmo RSA e serviços associados.

3.0 Observações legais 

nenhum

• Implementação:
• Linha do tempo e impacto: Cerca de 6 meses de trabalho de desenvolvimento de software.
• Requisitos de implementação: Modificações para WHOIS base de código dependendo da solução que eventualmente será ratificada.

 

 

Histórico de Revisão

Histórico de Revisão

Data	Detalhes
12 agosto 2018	Versão 1: AFPUB-2018-GEN-001-DRAFT01 Inicie Draft Postado em rpd
20 Novembro de 2018	Versão 2: AFPUB-2018-GEN-001-DRAFT02 Versão 2 publicada no rpd
5 de Junho de 2019	Versão 3: AFPUB-2018-GEN-001-DRAFT03 Seção 8.5 - As ações de acompanhamento de membros cujos endereços de email de abuso falham na validação são deixadas ao critério da AFRINIC, de acordo com as políticas / procedimentos relevantes. Seção 8.6 - O processo de encaminhamento para fraude de validação deve ser fornecido pelo AFRINIC (anteriormente, apenas um endereço de email para encaminhamento era fornecido)