Adicionar ao carrinho
| Ref. Nome: AFPUB-2018-GEN-001-DRAFT02 |
Versões: 2.0 Estado: Em discussão |
Autor: Jordi Palet Martinez jordi.palet [at] oipv6company.com A IPv6 Empresa
|
| Altera: CPM arte 8.0 | ||
| Submetido: 20 Novembro de 2018 |
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 LIRs podem não ter essas informações de contato registradas e atualizadas para seus recursos. Na verdade, existem até casos de LIRs que usam uma caixa de correio inexistente ou que não é monitorada 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 AFRINIC estará alinhado com outros RIRs. APNIC agora está usando o IRT, mas como uma proposta equivalente foi aceita, um “link” automatizado com o IRT 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 recai sobre o LIR cujo cliente está causando o abuso (e de quem recebe uma compensação financeira pelo serviço), em vez de recair sobre a vítima, como seria o caso se tivesse que recorrer aos tribunais, evitando custos (advogados, solicitadores, etc.) e poupando tempo a 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 prazo razoável para permitir que a equipe desenvolva a ferramenta e os LIRs 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 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:
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" Todos os recursos alocados 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 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
Vantagens 8.3.1
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 ponto e não podem 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 o 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 do 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. |
|
8.4 Objetivos da validação "abuse-c" / "abuse-mailbox" O procedimento, que será desenvolvido pela AFRINIC, deve atender aos seguintes objetivos: 1) Um processo simples que garante sua funcionalidade e permite que os helpdesks que tratam de denúncias de abuso 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 "direto" URL para validação. 2) Evite o processamento automatizado. 3) Confirme se a pessoa que realiza a validação compreende o procedimento e a política, se ela monitora regularmente a "caixa de correio de abuso", se as medidas são tomadas e se a denúncia de abuso recebe uma resposta. 4) Período de validação não superior a 15 dias. 5) Se a validação falhar, encaminhe para o LIR e defina um novo período de validação não superior a 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 critério da AFRINIC, em geral ou em casos específicos (por exemplo, para confirmação em casos de escalonamento em 8.6), AFRINIC pode usar domínios diferentes de AFRINIC. *, E até mesmo modificar o assunto e o corpo da mensagem, a fim de realizar essas validações de forma mais eficaz. A AFRINIC fará um acompanhamento mais exaustivo, de acordo com as políticas / procedimentos relevantes da AFRINIC, especialmente aqueles relacionados com a revogação de recursos. 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 Para evitar comportamento fraudulento (por exemplo, uma "caixa de correio abusiva" que responde apenas aos e-mails da AFRINIC ou a mensagens com um assunto ou conteúdo específico) ou a falha no cumprimento dos demais aspectos desta política (incorreto ou falta de resposta a casos de abuso) e, portanto, para garantir a qualidade dos serviços na região com os recursos alocados pela AFRINIC, um método de escalonamento deve ser fornecido (por exemplo, uma caixa de correio como "abuso-escalation@AFRINIC.net"), permitindo assim a revalidação (de acordo com o ponto 8.5 acima) e ainda a intermediação pela AFRINIC e, se for caso disso, a aplicação das políticas / procedimentos pertinentes, especialmente os relativos à revogação de recursos. |
3.2 Informações adicionais
Após a implementação desta proposta, a AFRINIC publicará o IRT também como 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 atuais (que deverão ser atualizadas pela AFRINIC). Isso é feito a fim de assimilar o IRT à maioria dos RIRs onde há abuso-c.
Exemplo de procedimento de validação.
- AFRINIC inicia a validação automaticamente, enviando DOIS emails consecutivos para a "caixa de correio de abuso".
- Esses emails serão enviados contendo apenas texto simples.
- O primeiro e-mail conterá a 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.
- O segundo e-mail conterá um código de validação alfanumérico exclusivo.
- 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.
- 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.
- O código alfanumérico só será válido por no máximo dois dias úteis.
- 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 AFRINIC para que possam iniciar um acompanhamento personalizado com o LIR.
- Se nenhuma resposta for recebida confirmando que a situação foi corrigida, após um período adicional de três dias úteis, o "abuse-c" será permanentemente marcado como "inválido".
- O processo de validação será repetido automaticamente (itens 1 a 7 acima). Se for satisfatório, o "abuse-c" será marcado como "válido"; caso contrário, será considerado uma violação da política.
4. Histórico de Revisões
|
Data |
Adicionar ao carrinho |
| 20 Novembro de 2018 |
Versão 2: AFPUB-2018-GEN-001-DRAFT02 |
|
12 Março de 2018 |
Versão 1: AFPUB-2018-GEN-001-DRAFT01 Inicie Draft Postado em rpd |
5. Referências
Uma proposta semelhante foi discutida na região do RIPE e está aguardando que os co-presidentes declarem consenso.
Histórico de Revisão
|
Data |
Adicionar ao carrinho |
| 20 Novembro de 2018 |
Versão 2: AFPUB-2018-GEN-001-DRAFT02 |
|
12 Março de 2018 |
Versão 1: AFPUB-2018-GEN-001-DRAFT01 Inicie Draft Postado em rpd |
Avaliação da equipe
| Proposta | AFPUB-2018-GEN-001-DRAFT02 |
| Título | Atualização da política de contato de abuso |
| URL da proposta | https://www.afrinic.net/policy/2018-gen-001-d2#proposal |
| Avaliadas | 20 de Abril de 2019 |
1.0 Entendimento da proposta pela equipe
- Texto da política de substituição para CPM 8.0 atual (Informações de contato de abuso) - [seção 8.1]
- 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]
- A caixa de correio de abuso deve ser válida e ativamente monitorada - [seção 8.2]
- O e-mail enviado para a caixa de correio de abuso deve precisar de intervenção manual do destinatário - [seção 8.3]
- 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 - [seção 8.4]
- AFRINIC deve bloquear MyAFRINIC acesso para membros não cumpridores. Todas as funções em MyAFRINIC diferente de atualizar a caixa de correio de abuso deve ser bloqueado até que a caixa de correio de abuso tenha sido validada com sucesso. - [seg 8.5]
- Um mecanismo de encaminhamento para o AFRINIC (por exemplo, por meio de um endereço de e-mail) 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
- Já existe uma solução através do objeto IRT, que atualmente é opcional - (e que parece ir ao encontro da 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.
- No texto da proposta 3.2, "Após a implementação desta proposta, a AFRINIC publicará o IRT também como abuse-c, a fim de facilitar a busca em whois para as mesmas informações, independentemente se estiver procurando por abuse-c ou IRT ... "A proposta deve ser clara quanto à solução exata SEJA a caixa de correio de abuso (com um endereço de e-mail) e / ou um objeto IRT. A IRT está atualmente um valor do atributo "mnt-irt". Não está claro se "IRT" deve ser um valor para o atributo abuse-c ou se "abuse-mailbox" referenciado em "irt" deve ter o valor de o atributo abuse-c, ou se o atributo "mnt-irt" deve ser renomeado para "abuse-c". Em qualquer caso, a proposta precisa ser mais clara em uma solução, mas recomendamos manter o IRT e torná-lo obrigatório.
- Na proposta de 8.5 onde MyAFRINIC o acesso a membros com contatos inválidos de abuso é bloqueado, as contas bloqueadas não poderiam votar na AGMM ou em outras eleições que exigem que os membros votem online, pois isso é feito por meio MyAFRINIC. (Opinião do consultor jurídico na Seção 3.0 abaixo). A proposta, entretanto, não é clara sobre o significado de "bloqueio do acesso dessa conta aos seus recursos". Sugerimos reformulação para especificar que nenhum objeto de banco de dados (incluindo WHOIS e objetos IRR) podem ser editados, exceto para adicionar abuse-c ou abuse-mailbox. Se o autor pretende que a votação seja bloqueada, a medida punitiva é certamente desproporcional à ofensa, mas não é um ato ilegal na lei de Maurício.
- Na proposta 8.6, é melhor não especificar um endereço de e-mail (para intervenções manuais e escalonamentos), pois isso pode mudar. É melhor reformular como "AFRINIC deve fornecer um método para denunciar ou escalar .. endereços de e-mail de abuso inválidos"
3.0 Comentários do consultor jurídico
O não cumprimento de uma obrigação administrativa, como a atualização das informações de contato, não pode ser interpretado como uma ofensa grave para justificar o bloqueio do acesso que levaria à perda dos direitos de voto. Esta sanção final é desproporcional ao não cumprimento e deve ser revista. No entanto, não é um ato ilegal na lei de Maurício.
Implementação 4.0
4.1 Cronograma e impacto: Cerca de 6 meses de trabalho de desenvolvimento de software.
4.2 Requisitos de Implementação: Modificações para WHOIS base de código dependendo da solução que eventualmente será ratificada.