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:

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 "abuso-escalation@afrinic.net"), 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

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