Adicionar ao carrinho
|
Atualização da política de contato de abuso |
|||
|
IDENTIDADE: |
AFPUB-2018-GEN-001-DRAFT07 |
Data de envio: |
17 de maio de 2021 |
|
Autor: |
Jordi Palet Martinez jordi.palet noipv6company.com A IPv6 Empresa |
Versão: |
7.0 |
|
Estado: |
Consenso (Aguardando Ratificação pelo Conselho) |
Altera: |
CPM arte 8.0
|
|
Resumo do marco do PDP
|
|||
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 fica 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. Na verdade, existem até casos de uma caixa de correio inexistente ou que não é monitorada ativamente.
Na prática, esse contato torna-se ineficaz para denunciar abusos e geralmente dá origem a 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. Esta política garante que isso pode ser verificado de forma automática e periódica pela AFRINIC, sem entrar nos detalhes operacionais de como fazê-lo. Na verdade, há uma atividade AFRINIC (https://afrinic.net/stats/contact-update) que visa a verificação dos contactos, no entanto, só reportou para 2017. Mais uma vez, esta proposta, garante que esta atividade seja realizada de forma automatizada (na medida do possível), poupando custos para os membros e 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 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 sobre como lidar com a transição. Esta política apenas garante que abuse-c e abuse-mailbox 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 nós precisamos ser capazes de entrar em contato com os LIRs que podem estar enfrentando um problema em suas redes e não estão cientes da 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 pela AFRINIC, um período de tempo razoável para permitir que os funcionários desenvolvam a ferramenta e os membros atualizem seus contatos abuse-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 atributo 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:
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 e-mail válida, monitorada e gerenciada ativamente (caixa de correio de abuso) destinada a receber relatórios em relação a comportamento abusivo, questões de segurança e outros. 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 pais 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
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":
|
|
8.4 Objetivos da validação "abuse-c" / "abuse-mailbox" O procedimento, que será desenvolvido pela AFRINIC, deve atender aos seguintes objetivos:
|
|
|
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 responde apenas aos e-mails da AFRINIC ou a mensagens com um assunto ou conteúdo específico), ou falha no cumprimento dos demais aspectos desta política (incorreto ou falta de resposta a casos de abuso) podem ser relatados à AFRINIC para uma revalidação (conforme seção 8.5 acima). |
|
|
8.7 Arranque lento e acompanhamento do progresso Os períodos iniciais / escalonados e a periodicidade de validação definidos por esta política podem ser alterados anualmente pela AFRINIC, considerando os procedimentos internos, as necessidades de pessoal e os dados reais, considerando tanto o início lento quanto o acompanhamento da precisão dos dados. As razões para as emendas serão devidamente comunicadas à comunidade. |
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.
Isso facilitará a AFRINIC para um "início lento" para implementar a política e garantir que nenhuma equipe adicional seja necessária nas fases iniciais de implementação, pois dependendo da taxa de contatos malsucedidos, eles podem precisar de mais tempo para a primeira passagem por todos os Filiação. Por exemplo, pode-se esperar que a primeira passagem leve 12-24 meses e seja feita por diferentes tipos de membros (LIRs / usuários finais / outros), com um lote a cada mês ou mesmo segurando o próximo lote no caso de um alta taxa de falha, etc.
Como em todas as outras políticas, esta não define condições específicas diferentes para titulares de legado. Esta é uma questão AFRINIC genérica que deve ser tratada de maneira uniforme em todo o manual de políticas.
Da mesma forma, a política não prevê as consequências do descumprimento, já que é genericamente declarado no RSA.
A política não define o que é abuso, pois essa definição não se enquadra de forma alguma nas ações do ponto de vista AFRINIC. Cada participante da Internet deve definir o que é abuso para eles, e se outros não respeitarem isso, eles podem usar o abuso-c para contatá-los e em caso de inação para resolver o caso, eles devem escalar o assunto de acordo com seus próprios procedimentos, que em alguns casos, também podem depender de seus regulamentos locais. Tudo isso está fora do âmbito do AFRINIC.
Não há impacto adicional do GDPR por esta política, pois ela já está coberta por todas as regulamentações existentes da AFRINIC sobre o assunto.
Esta proposta não impõe nenhum cronograma de implementação, que é deixado para as práticas operacionais, prioridades e necessidades de pessoal da AFRINIC.
4. Referências
Uma proposta equivalente foi aceita em APNIC (já implementada) e LACNIC (em implementação). Uma nova versão está sendo elaborada para RIPE e ARIN.
Histórico de Revisão
Histórico de Revisão
|
Data |
Adicionar ao carrinho |
|
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 |
|
|
2nd novembro 2019 |
Versão 4: AFPUB-2018-GEN-001-DRAFT04 Simplificação geral do texto |
|
21 Novembro de 2019 |
Versão 5: AFPUB-2018-GEN-001-DRAFT05 Esclarecimentos adicionais do texto |
| 5 agosto 2020 |
Versão 6: AFPUB-2018-GEN-001-DRAFT06 Melhorias editoriais Erro de digitação corrigido em 'Referências' (2020/09/15) |
| 17 de maio de 2021 |
Versão 7: AFPUB-2018-GEN-001-DRAFT07 Mais esclarecimentos de texto com base na discussão anterior e IA |
Avaliação de impacto da política AFRINIC
Avaliação da equipe AFRINIC
1 Interpretação e compreensão da proposta pela equipe
Esta proposta de política solicita que a AFRINIC implemente um contato e uma caixa de correio de abuso adequados. Ele atualiza a Seção 8.0 do Manual de Política Consolidado. No momento, AFRINIC WHOIS objetos; aut-num, inetnum e inet6num não contêm o atributo abuse-c.
A - O abuso-c: -
- deve ser usado para publicar informações de contato público de abuso na região de serviço AFRINIC.
- são verificados automática e periodicamente com o uso de automação, sempre que possível pela AFRINIC, a fim de facilitar a denúncia de abuso em / entre regiões.
- não substitui os dados incluídos no objeto IRT no AFRINIC WHOIS banco de dados implementado no momento
- é obrigatório nos objetos de recursos “aut-num”, "inetnum" e "inet6num" nos recursos alocados / atribuídos pelo AFRINIC, bem como outros recursos que podem ser usados no futuro
- presentes em objetos filho daqueles diretamente distribuídos por AFRINIC (atribuições, subalocações) podem ser novos ou herdados dos recursos pai delegados por AFRINIC
- deve ter pelo menos um atributo de caixa de correio de abuso válido e monitorado ativamente
- deve apontar para uma pessoa ou função, com pelo menos uma caixa de entrada de e-mail válida, monitorada e gerenciada ativamente (caixa de correio de abuso)
- O atributo "abuse-mailbox" deve estar disponível de forma irrestrita via WHOIS, APIs e técnicas futuras.
B - validação Abuse-c / abuse-mailbox
A AFRINIC deve desenvolver o procedimento para validação abuse-c / abuse-mailbox que atenda aos seguintes objetivos: -
- Um processo simples que garante o contato de abuso é capaz de cumprir sua finalidade.
- Confirma que o detentor do recurso:
- leu o procedimento e a política
- monitorar regularmente a caixa de correio de abuso
- medidas são tomadas
- relatórios de abuso recebem uma resposta.
- período de validação inicial não superior a 15 dias.
- Se a validação falhar, passe para outros contatos LIR e defina um novo período de validação para não exceder 15 dias.
Frequência de validação conduzida pela AFRINIC: -
- No momento em que abuse-c / abuse-mailbox são criados
- No momento em que abuse-c / abuse-mailbox são atualizados
- Periodicamente - pelo menos uma vez a cada 6 meses
- sempre que AFRINIC achar necessário.
C. Escalonamento para AFRINIC
A AFRINIC deve garantir que os repórteres possam escalar e relatar comportamento fraudulento, como: -
- Caixa de correio de abuso sem resposta
- Abuso de caixa de correio que responde apenas aos e-mails da AFRINIC ou a mensagens com um assunto ou conteúdo específico)
- Incumprimento dos restantes aspectos desta política (incorrecto ou falta de resposta a casos de abuso)
Esses casos irão desencadear a revalidação do contato abuse-c.
D. AFRINIC deve: -
- Forneça um prazo razoável para permitir que a equipe desenvolva a ferramenta e os membros atualizem seus contatos abuse-c.
- O período inicial de aplicação de conformidade com a política não é especificado e, portanto, o alinhamento implícito com o período de validação de 6 meses é assumido
Benefício para AFRINIC
- A precisão do WHOIS O banco de dados em termos de contatos de abuso aumentará à medida que seus membros adotarem e implementarem um contato de abuso em conformidade com esta política.
- O número de relatórios de abuso de tíquetes registrados pode reduzir, pois os repórteres poderão consultar WHOIS DB para obter os endereços de e-mail de abuso para os quais essas denúncias devem ser direcionadas.
2 Recomendações AFRINIC
nenhum
3 pedidos de esclarecimento da AFRINIC
nenhum
4 Impacto nas funções de registro
Se esta política proposta chegar a um consenso;
- espera-se uma melhoria na precisão e na atualidade dos dados de registro, já que os atributos “abuse-mailbox:” devem estar atualizados e corretos.
- o número de e-mails de abuso que são direcionados às filas AFRINIC devido à falta de contatos de abuso deve reduzir atualmente.
| Mês | Jun-20 | Jul-20 | Ago-20 | Sep-20 | Oct-20 | Nov-20 | Dez-20 | Jan-21 | Feb-21 | Mar-21 | Apr-21 | Maio-21 |
| Nº de ingressos | 557 | 1054 | 129 | 100 | 61 | 81 | 112 | 117 | 86 | 133 | 106 | 122 |
4.1 processos
O (s) processo (s) que orientam o gerenciamento das informações de contato dos membros do recurso serão corrigidos para incluir o contato de abuso.
Procedimentos 4.2
Os procedimentos da MS exigirão atualizações da seguinte forma: -
- Um novo procedimento / subprocesso a ser desenvolvido para a validação da caixa de correio abuse-c / abuse.
Documentação 4.3
Atualização do site com uma diretriz de política abuse-c
4.4 Sistemas - RPKI
Sem Impacto
4.5 Sistemas - WHOIS
O abuso-c deve ser um objeto de pessoa / função no whois base de dados. abuse-mailbox já é um atributo do objeto pessoa / função.
- O atributo abuse-c deve ser adicionado no WHOIS banco de dados como um atributo para objetos inetnum, inet6num e aut-num
- descontinuar objeto IRT
- Remova os atributos mnt-irt dos objetos inetnum, inet6num e aut-num.
- Adicione regras de validação para forçar a caixa de correio de abuso em objetos de pessoa e função que são referenciados por meio do atributo abuse-c.
- A WHOIS consulta do inetnum, inet6num e aut-num deve fornecer o contato de abuso na resposta.
Análise Detalhada
| objeto | Eu conto com WHOIS DB | Protegido por MNT-IRT |
| inetnum | 139268 | 232 |
| inet6num | 31230 | 33 |
| número automático | 1915 | 32 |
Organizações membros: 28 de um total de 1857 membros de recursos adotaram a política de contato de abuso atual e 27 objetos IRT (de 42 objetos IRT criados no WHOIS DB) são referenciados em seus recursos no whois base de dados.
4.6 Sistemas - MyAFRINIC
Uma vez que os membros são capazes de gerenciar suas informações de contato de MyAFRINIC, o desenvolvimento de software será necessário para implementar esta política em MyAFRINIC
- A codificação será necessária para garantir a criação / atualizações / importação de contatos abusados
- Contatos de abuso não devem ter credenciais de login em MyAFRINIC a menos que esteja sendo usado em outra função também e, portanto, será mantido por contatos administrativos / técnicos
- Atualização da emissão de recursos / atualização das regras de negócios para tornar o abuse-c obrigatório (todos ou excluem o TBC legado)
- Atualizações dos formulários de subalocação e atribuição com regra de negócios sobre abuse-c
- Uma ferramenta para validar as caixas de correio, conforme exigido por esta proposta de política, terá que ser implementada e os contatos de abuso sinalizados como válidos / inválidos
- Uma ferramenta para permitir que os membros implementem o abuse-c será desenvolvida.
4.7 Sistemas - NMRP
Como o abuse-c se tornará obrigatório, também serão necessárias alterações no NMRP, onde o requerente deve fornecer o e-mail da caixa de correio do abuso a ser adicionado aos recursos se a solicitação for aprovada.
4.8 Sistemas - Infraestrutura
Sem impacto
4.9 Sistemas - Netsuite
Sem impacto
4.10 Impacto nos detentores de recursos
Além dos objetos de pessoa / função existentes que servem como contatos administrativos e técnicos, os membros devem: -
- fornecer um contato abuse-c para AFRINIC que seja válido, monitorado e gerenciado ativamente
- garantir que os e-mails enviados para a caixa de correio abuse no contato abuse-c
- Requer sua intervenção
- 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.
- Certifique-se de que seus procedimentos internos de tratamento de abusos reflitam o acima, a fim de cumprir a política.
- O suporte de serviço (incluindo help desk / aplicações de recursos) deve ser oferecido apenas aos membros que estão em conformidade com esta política.
- Certifique-se de que eles mantenham suas informações de contato, inclusive de abuso-c precisas em todos os momentos, para estar em conformidade com esta política e com o RSA
5 Impacto Financeiro
Sem impacto
6 impacto legal
Caso esta política chegue a um consenso, o não cumprimento desta política por um membro da AFRINIC será considerado uma violação da cláusula RSA e o membro será incentivado a remediar a violação. A não conformidade persistente pode acarretar a revogação do RSA de acordo com a cláusula.
7 cronogramas de implementação
A AFRINIC tomou nota de que pode alterar anualmente os períodos iniciais / escalonados e a periodicidade de validação definida por esta política, considerando os procedimentos internos, as necessidades de pessoal e os dados reais, considerando tanto o início lento quanto o acompanhamento da precisão do dados. As razões para as emendas serão devidamente comunicadas à comunidade.
A este respeito, se esta política obtiver consenso, a AFRINIC adotará uma implementação em fases, mantendo a comunidade informada.