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

Proposta

1. 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. Isso também é contraditório com o RSA, que afirma que as informações nos bancos de dados devem ser precisas. Essa política garante que isso possa ser verificado automática e periodicamente pelo AFRINIC, sem inserir os detalhes operacionais de como fazê-lo. De fato, há uma atividade AFRINIC (https://afrinic.net/stats/contact-update), que tem como objetivo verificar os contatos, no entanto, foi relatado apenas para 2017. Novamente, esta proposta garante que essa atividade seja realizada de maneira automatizada (na medida do possível), economizando custos para a associação e a comunidade.

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. Esta 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, por exemplo, agora está usando o IRT, mas como uma proposta equivalente foi aceita, um “link” automatizado (alias ou ponteiro) para o IRT pré-existente será criado, então abuse-c e abuse-mailbox prevalecem.

Não há necessidade de excluir os outros dados opcionais hoje incluídos no IRT; é uma decisão operacional do AFRINIC como lidar com a transição. Essa política apenas garante que abuso-ce caixa de correio-abuso estejam disponíveis e verificados periodicamente.

 

2. 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 membros 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 atributo obrigatório (abuse-c) que deve ser usado para publicar informações de contato público sobre 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 "abuse-c" obrigatório (contato de abuso), apontando para uma pessoa ou função, com pelo menos uma caixa de entrada de email válida, monitorada e gerenciada ativamente (caixa de correio de abuso) destinada a receber relatórios 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 práticas usuais, outros atributos de "email" 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" Emails enviados para "abuse-mailbox": Exigir intervenção do destinatário. Não deve exigir que o repórter preencha um formulário. Deve garantir que os relatórios de abuso e logs, exemplos ou cabeçalhos relacionados sejam recebidos.
	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 o contato de abuso é capaz de cumprir sua finalidade. Confirme se o detentor do recurso entende o procedimento e a política, que monitora regularmente a caixa de correio de abuso, que medidas são tomadas e que os relatórios de abuso recebem uma resposta. Período de validação inicial não superior a 15 dias. Se a validação falhar, encaminhe para os contatos de outros membros e defina um novo período de validação não superior a 15 dias.
	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.
	8.6 Encaminhamento para AFRINIC Comportamento fraudulento (por exemplo, uma "caixa de correio de abuso" que apenas responde aos e-mails da AFRINIC ou a mensagens com um assunto ou conteúdo específico) ou falha no cumprimento dos aspectos restantes desta política (incorreta ou falta de resposta a casos de abuso) podem ser relatados ao AFRINIC para uma revalidação (conforme a seção 8.5 acima).

 

  

3.2 Informações adicionais:

Se esta proposta chegar a um consenso, para cumpri-la, a AFRINIC deve renomear mnt-IRT para abuse-c. É uma decisão AFRINIC operacional se um pseudônimo (ponteiro, atributo duplicado ou qualquer outra alternativa) para mnt-IRT é mantido e por quanto tempo (período de transição), a fim de facilitar a busca em whois para as mesmas informações, independentemente se estiver procurando por abuse-c ou mnt-IRT. É uma decisão operacional AFRINIC manter e por quanto tempo, o IRT ou excluí-lo, bem como o resto das informações reais no IRT. A AFRINIC também decidirá como atualizar melhor as diretrizes atuais (https://www.afrinic.net/library/membership765-abuse-policy-bcp) ou se eles não forem mais necessários. Isso é feito a fim de assimilar o IRT à maioria dos RIRs onde há abuso-c.

Como uma questão de esclarecimento, os períodos de validação “inicial” e “escalada” podem ser modificados pelo AFRINIC, se considerado apropriado, desde que informe a comunidade de sua motivação para fazê-lo. Por exemplo, na fase de implementação, os períodos podem ser estendidos e ajustados à medida que uma porcentagem maior de contatos se torna precisa.

Da mesma forma, a frequência da validação periódica pode ser modificada se o AFRINIC considerar apropriado e informar a comunidade de suas razões para fazê-lo.

Por exemplo, uma única validação pode ser feita no primeiro ano para facilitar a adesão à política. O número de validações anuais pode aumentar ao longo do tempo, talvez se tornando trimestral, com o objetivo de melhorar a qualidade dos contatos.

 

 4. Referências            

Uma proposta equivalente foi aceita no APNIC (já implementada) e está sendo discutida nas regiões ARIN, LACNIC e RIPE.

 

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 Inicie Draft Postado em rpd
5 de Junho de 2019	Versão 3: AFPUB-2018-GEN-001-DRAFT03
2nd novembro 2019	Versão 4: AFPUB-2018-GEN-001-DRAFT04 Simplificação geral do texto
22nd novembro 2019	Versão 5: AFPUB-2018-GEN-001-DRAFT05 Esclarecimentos adicionais do texto