Mise à jour de la politique relative aux contacts abusifs (Draft 3) Archivé

Proposition

1.0 Résumé du problème traité par cette proposition

La politique actuelle n'implique pas l'obligation d'enregistrer un contact abusif et spécifie un format de communication personnelle et de «signalement automatique», qui, par rapport aux autres RIRs devient déroutant, car un seul e-mail sera plus efficace, car à la fin, les rapports sont copiés dans les deux e-mails.

En conséquence, certains détenteurs de ressources peuvent ne pas avoir ces informations de contact enregistrées et à jour pour leurs ressources. En fait, il existe même des cas de boîte aux lettres inexistante ou qui n'est pas activement surveillée.

En pratique, ce contact devient inefficace pour signaler des abus et entraîne généralement des problèmes de sécurité et des coûts pour les victimes.

Cette proposition vise à résoudre ce problème et à garantir l’existence d’un contact approprié contre les abus et le processus de son utilisation, qui est plus uniforme dans tous les pays. RIRs, afin de faciliter le signalement des abus entre régions. 

Les références politiques existantes à un «document sur les meilleures pratiques», qui n'est pas considéré comme obligatoire et en fait, n'est pas utilisé par la communauté. Cette proposition ne modifie pas la portée de ce document et, en fait, un lien entre les quelques objets IRT existants et le nouveau devrait être automatiquement établi.

De cette façon, le contact d'abus AfriNIC sera en ligne avec d'autres RIRs. L'APNIC utilise maintenant l'IRT, mais comme une proposition équivalente a été acceptée, un «lien» (alias) automatisé vers l'IRT préexistant sera créé, donc l'abus-c et l'abus-boîte aux lettres prévaudront.

Il n'est pas nécessaire de supprimer les autres données facultatives incluses aujourd'hui dans l'IRT. Cette politique garantit simplement que la boîte aux lettres d'abus est disponible et vérifiée périodiquement.

 

2.0 Résumé de la façon dont cette proposition résout le problème

La communauté Internet est basée sur la collaboration. Cependant, dans de nombreux cas, cela ne suffit pas et nous devons tous être en mesure de contacter les LIR qui peuvent rencontrer des problèmes dans leurs réseaux et ne sont pas conscients de la situation.

Cette proposition crée une nouvelle section dans le manuel des politiques pour résoudre ce problème au moyen d'une vérification simple et périodique, et établit les règles de base pour effectuer une telle vérification et évite ainsi des coûts inutiles aux tiers qui doivent contacter les personnes chargées de résoudre le problème. abus d'un réseau spécifique. 

La proposition garantit que le coût du traitement de l'abus incombe au détenteur de la ressource dont le client est à l'origine de l'abus (et de qui il reçoit une compensation financière pour le service), au lieu de tomber sur la victime, comme ce serait le cas s'il avait recourir aux tribunaux, évitant ainsi des frais (avocats, solicitors, etc.) et un gain de temps pour les deux parties.

Pour cela, l'attribut abuse-c devient obligatoire dans les objets "aut-num", "inetnum" et "inet6num", ainsi que dans tous les autres qui pourraient être utilisés à l'avenir. Cet attribut est un contact abusif, qui doit contenir au moins l'attribut "boîte aux lettres abusive".

La proposition devrait être mise en œuvre dans 90 jours, à confirmer par AfriNIC, un délai raisonnable pour permettre à la fois au personnel de développer l'outil et aux LIR de mettre à jour leurs contacts d'abus-c.

 

3. Proposition 

3.1 Modifier le 8.0 de la RPC, comme suit:

Actuel	Proposition
8.1 Introduction Cette politique spécifie un objet dédié qui doit être utilisé comme lieu préféré pour publier des informations de contact public abusives dans la région de service AFRINIC.  L'objet mentionné peut être référencé dans les objets inetnum, inet6num et aut-num dans l'AFRINIC whois Base de données. Il fournit un moyen plus précis et efficace pour les rapports d'abus d'atteindre le bon contact réseau	8.1 Introduction Cette politique spécifie un objet obligatoire qui doit être utilisé pour publier des informations de contact public abusives dans la région de service AFRINIC. L'objet mentionné doit être référencé dans les objets inetnum, inet6num et aut-num dans l'AFRINIC whois Base de données. Il fournit un moyen plus précis et efficace pour les rapports d'abus d'atteindre le bon contact.
8.2 Détails de la politique: Pour rendre disponible un nouveau ou utiliser un déjà existant whois objet de base de données qui implémente les propriétés suivantes: Une référence unique par inetnum, inet6num et aut-num Contient 2 attributs de messagerie: "e-mail:" pour la communication personnelle "abuse-mailbox:" pour la gestion automatique des rapports L'objet doit être accessible via le whois protocole. AFRINIC pour publier un Document sur les meilleures pratiques qui encourage tous les membres à utiliser activement l'objet pour publier des informations de contact d'abus.	8.2 Description de «abuse-c» et «abuse-mailbox» Les ressources allouées / attribuées par AfriNIC doivent inclure un attribut de contact "abus-c" obligatoire (contact abusif) dans leur WHOIS entrée, avec au moins une boîte aux lettres électronique valide, surveillée et gérée activement (boîte aux lettres d'abus) destinée à recevoir des rapports manuels ou automatiques concernant les comportements abusifs, les problèmes de sécurité, etc. L'attribut "abuse-mailbox" doit être disponible sans restriction via whois, API et techniques futures.  Compte tenu de la nature hiérarchique des objets d'adresse IP, les objets 'child' de ceux directement distribués par AFRINIC peuvent être couverts par des objets parents ou ils peuvent avoir leur propre attribut "abuse-c". Suivant les pratiques habituelles, d'autres attributs "e-mail" peuvent être inclus à d'autres fins.
8.3 Avantages et inconvénients de la politique 8.3.1 Avantages Les réseaux pourront fournir leurs propres coordonnées directes aux services d'abus. Les plaintes pour abus ne seront plus envoyées au "mauvais" contact. Cela permet une plus grande flexibilité administrative et opérationnelle, et un traitement plus rapide des abus sera possible.   8.3.2 Inconvénients Cet objet, comme tous les autres objets existants, sera confronté au problème de précision des données. Cette politique vise à résoudre le problème d'une place manquante pour les coordonnées d'abus et n'améliorera pas l'exactitude des données dans le whois base de données. Néanmoins, il est suggéré à AFRINIC de proposer un moyen de recevoir des rapports sur des objets non fonctionnels ou non précis.	8.3 À propos de la "boîte aux lettres d'abus" Les e-mails envoyés à "boîte aux lettres d'abus" doivent nécessiter une intervention manuelle du destinataire à un moment donné et peuvent ne pas être filtrés, car dans certains cas, cela peut empêcher la réception des rapports d'abus. Par exemple, dans un cas de spam où le rapport d'abus peut inclure le message de spam lui-même ou des URL ou du contenu généralement classés comme spam. La "boîte aux lettres d'abus" peut initialement envoyer une réponse automatique, par exemple en attribuant un numéro de ticket, en appliquant des procédures de classification, en demandant des informations supplémentaires, etc. Cependant, elle ne devrait pas exiger que le déclarant d'abus remplisse un formulaire, car cela impliquera que chaque entreprise qui doit signaler des cas d'abus (une tâche qui est généralement automatisée), serait obligée de développer une interface spécifique pour chaque FAI dans le monde qui rend obligatoire le remplissage des formulaires, ce qui n'est ni faisable ni logique, car cela placerait le coût de traiter la maltraitance sur ceux qui présentent la demande et sont donc victimes de la maltraitance, au lieu d'être payés par ceux dont le client est à l'origine de la maltraitance (et dont ils tirent un revenu).  À titre d'information, il convient de noter qu'il est raisonnable de s'attendre à ce que la procédure de signalement des abus envoie, avec le rapport d'abus initial, les journaux, une copie du message de spam (en joignant un exemple de courrier électronique de spam ou ses en-têtes complets) ou des preuves équivalentes (selon le type d'abus). De même, il est raisonnable de s'attendre à ce que l'e-mail de réponse automatique initial précise que la réclamation ne sera traitée que si de telles preuves ont été soumises, permettant ainsi à l'expéditeur de répéter la soumission et d'inclure des preuves pertinentes. Cela permet un reporting automatique, par exemple via fail2ban, SpamCop ou autres, en maintenant les coûts au minimum pour les deux parties impliquées. Généralement, si un numéro de ticket a été généré, il doit être conservé (généralement dans le cadre du sujet) par le biais de communications successives.
	8.4 Objectifs de la validation "abuse-c" / "abuse-mailbox" La procédure, qui sera développée par AFRINIC, doit répondre aux objectifs suivants: Un processus simple qui garantit sa fonctionnalité et permet aux helpdesks qui traitent des rapports d'abus de vérifier que les demandes de validation proviennent bien d'AFRINIC et non de tiers (ce qui pourrait impliquer des risques de sécurité), en évitant, par exemple, une seule URL "directe" pour validation. Évitez les traitements exclusivement automatisés. Confirmez que la personne effectuant la validation comprend la procédure et la politique, qu'elle surveille régulièrement la "boîte aux lettres d'abus", que des mesures sont prises et que le rapport d'abus reçoit une réponse. Période de validation ne dépassant pas 15 jours. Si la validation échoue, passez au LIR et définissez une nouvelle période de validation ne dépassant pas 15 jours. Les périodes de validation «initiale» et «escalade» peuvent être modifiées par AFRINIC, si cela est jugé approprié, en informant la communauté de la motivation. Par exemple, elle pourrait être plus longue pour la première validation, une fois cette politique mise en œuvre, et raccourcie ensuite une fois que le pourcentage d'échecs diminue, de sorte que la qualité des contacts augmente et par conséquent une diminution des temps de réponse moyens en cas d'abus pourrait être attendue. (À titre d'exemple, une procédure détaillée est incluse dans cette proposition de politique sous "Informations supplémentaires").
	8.5 Validation de "abuse-c" / "abuse-mailbox" AFRINIC validera la conformité avec les éléments ci-dessus, à la fois lorsque les attributs "abuse-c" et / ou "abuse-mailbox" sont créés ou mis à jour, ainsi que périodiquement, au moins une fois tous les 6 mois, et chaque fois qu'AFRINIC le juge opportun. Le non-respect entraînera un suivi, des avertissements et un blocage plus exhaustifs de certains services, à la discrétion d'AFRINIC, conformément aux politiques / procédures applicables. La fréquence de la validation périodique pourrait être modifiée si l'AFRINIC le juge approprié et informe la communauté de ses raisons. Par exemple, une seule validation pourrait être effectuée au cours de la première année, pour faciliter le respect de la politique, puis le nombre de validations annuelles pourrait augmenter progressivement, atteignant même trimestriellement, dans le but d'améliorer la qualité des contacts.
	8.6 Escalade vers AFRINIC Afin de permettre l'escalade d'un comportement frauduleux (par exemple, une "boîte aux lettres d'abus" qui ne répond qu'aux e-mails d'AFRINIC, ou à des messages avec un sujet ou un contenu spécifique), ou le non-respect des autres aspects de cette politique (incorrect ou absence de réponse aux cas d'abus), une méthode d'escalade devrait être prévue, permettant ainsi une revalidation (selon la section 8.5 ci-dessus).

 

3.2 Informations supplémentaires:

Depuis la mise en œuvre de cette proposition, AFRINIC publiera l'IRT en tant qu'alias de abuse-c, afin de faciliter la recherche dans whois pour les mêmes informations, peu importe si vous recherchez abuse-c ou IRT. Le reste des informations réelles dans l'IRT, peut être conservé selon les directives actuelles (qui devront être mises à jour AFRINIC). Ceci est fait afin d'assimiler l'IRT à la majorité des RIRs où il est abusif-c. 

Exemple de procédure de validation. 

1. AFRINIC lance automatiquement la validation en envoyant DEUX courriels consécutifs à la "boîte aux lettres d'abus". 

2. Ces e-mails seront envoyés contenant uniquement du texte brut.

3. À la discrétion d'AFRINIC, en général ou dans des cas spécifiques (par exemple, pour confirmation en cas d'escalade sous 8.6), AFRINIC peut utiliser des domaines autres que afrinic. *, Et même modifier le sujet et le corps du message, afin de effectuer lesdites validations plus efficacement.

4. Le premier e-mail contiendra l'URL où la validation doit être effectuée ("validacion.afrinic.net") et peut contenir des informations sur la procédure, un bref résumé de cette politique, etc.

5. Le deuxième e-mail contiendra un code de validation alphanumérique unique. 

6. Le responsable de la "boîte aux lettres d'abus" doit se rendre sur l'URL et coller le code reçu dans le deuxième email du formulaire.

7. Cette URL doit être conçue de manière à empêcher l'utilisation d'un processus automatisé (par exemple, "captcha"). En outre, il doit contenir un texte confirmant que la personne effectuant la validation comprend la procédure et la politique, qu'elle surveille régulièrement la "boîte aux lettres d'abus", que des mesures sont prises pour résoudre les cas d'abus signalés et que le rapport d'abus reçoit une réponse, avec une "case à cocher" qui doit être acceptée pour continuer.

8. Le code alphanumérique ne sera valable que pour un maximum de 15 jours ouvrables. 

9. Si le code n'est pas saisi dans ce délai, le système marquera "abuse-c" comme "temporairement invalide" et alertera le personnel d'AFRINIC afin qu'il puisse initier un suivi personnalisé avec le détenteur de la ressource.

10. Si aucune réponse n'est reçue confirmant que la situation a été corrigée, après un délai supplémentaire de 15 jours ouvrables, le "abuse-c" sera marqué définitivement comme "invalide".

11. AFRINIC doit s'assurer que tous les moyens possibles pour «avertir» le détenteur de la ressource sont mis en place, tels que des courriels périodiques à d'autres boîtes de courriel, des fenêtres pop-up d'alerte, etc. Tous ces éléments doivent contenir le texte de la politique et des rappels sur les conséquences en cas de violation continue de la politique. Des moyens de bloquer l'accès à certains services devraient également être envisagés.

12. Le processus de validation sera répété automatiquement (points 1 à 8 ci-dessus). S'il est satisfaisant, le "abuse-c" sera marqué comme "valide"; sinon, il sera considéré comme contraire à la politique. 

13. Il doit y avoir des outils tels qu'un formulaire, une boîte aux lettres (par exemple, une boîte aux lettres telle que "cette adresse e-mail qui est protégée du spam. Vous devez activer JavaScript pour la voir."), ou d'autres à l'avenir, pour aggraver le non-respect de cette politique et même l'intermédiation par AFRINIC et, le cas échéant, l'application des politiques / procédures pertinentes, en particulier celles relatives à la révocation des ressources.

 

Références

Une proposition équivalente a été acceptée à l'APNIC et est en cours de discussion dans les régions ARIN, LACNIC et RIPE.

 

Évaluation du personnel

Version PDF

Proposition	AFPUB-2018-GEN-001-DRAFT03
Titre	Mise à jour de la politique de contact contre les abus - v3
Proposition UR	https://afrinic.net/policy/proposals/2018-gen-001-d3#proposal
évaluée	20 Juillet 2019

1.0 Compréhension de la proposition par le personnel

1. Texte de la politique de remplacement pour le CPM 8.0 actuel (informations de contact en cas d'abus) - [sec 8.1]
2. Introduit un attribut obligatoire "abuse-c" dans inetnum, inet6num et aut-num whois objets de base de données. La valeur de cet attribut est une adresse e-mail (boîte aux lettres d'abus), à laquelle toutes les informations relatives à l'abus doivent être envoyées. La boîte aux lettres d'abus est facultative dans les objets enfants des allocations ou affectations directes parentes émises par AFRINIC - [sec 8.2]
3. La boîte aux lettres d'abus doit être valide et surveillée activement par la vérification de la période - [sec 8.2]
4. Le courrier électronique envoyé à la boîte aux lettres d'abus doit nécessiter une intervention manuelle du destinataire à un moment donné - [sec 8.3]
5. AFRINIC doit fournir un système pour valider la boîte aux lettres d'abus. Le processus réel est laissé à la discrétion du personnel d'AFRINIC, mais pourrait suivre un exemple de procédure dans la section 3.2 de la proposition de politique, avec un intervalle de validation minimum recommandé d'au moins une fois tous les 6 mois - [sec 8.4]
6. Les boîtes aux lettres Abuse-c qui échouent aux tests de validation entraîneront le blocage éventuel de certains services, à la discrétion d'AFRINIC (et conformément aux politiques / procédures pertinentes) - [sec 8.5]
7. Un mécanisme d'escalade vers AFRINIC doit être fourni lorsque toute préoccupation concernant le processus de validation peut être signalée par la communauté et / ou les membres. Cela peut également aider avec les revalidations manuelles. - [sec 8.6]

2.0 Commentaires du personnel

1. Il existe déjà une solution existante via l'objet IRT, qui est actuellement facultative - (et qui semble répondre à l'intention de la proposition) - qui peut être rendue obligatoire pour les objets ressources directement émis par AFRINIC. Un avantage supplémentaire de l'utilisation de l'IRT est qu'il peut contenir plus d'informations qu'une simple adresse e-mail, comme une adresse physique, des numéros de téléphone et des clés PGP pour une communication sécurisée. 
2. Au cours de la réunion de politique publique AFRINIC30, l'auteur a précisé que l'IRT peut être un «alias» de l'abus-c. Nous notons cependant qu'il est déroutant d'utiliser IRT comme alias de abuse-c et l'inverse - nous ne saurions pas comment mettre en œuvre une telle exigence à moins que l'auteur ne guide avec des spécifications détaillées à travers la proposition de politique ou via le (DBWG ) groupe de travail sur la base de données.
3. Dans la proposition 8.5, où les boîtes aux lettres abuse-c qui échouent aux tests de validation conduiront au blocage éventuel de certains services, à la discrétion d'AFRINIC (et conformément aux politiques / procédures pertinentes). La proposition politique doit indiquer clairement quels services spécifiques doivent être bloqués. Cependant, il est important de noter que sans cette clause en premier lieu, une violation de la politique (telle que l'absence d'abus valide-c si cette proposition était adoptée) équivaut à une violation du RSA, ce qui peut entraîner la révocation éventuelle de le même RSA et les services associés.

3.0 Observations juridiques 

Aucune

• Mise en œuvre:
• Chronologie et impact: environ 6 mois de travail de développement logiciel.
• Exigences de mise en œuvre: modifications WHOIS base de code en fonction de la solution qui sera finalement ratifiée.

 

 

Historique des révisions

Historique des révisions

Date	Plus de détails
12 Août 2018	Version 1 : AFPUB-2018-GEN-001-DRAFT01 Initiales Draft Publié sur rpd
20 Novembre 2018	Version 2 : AFPUB-2018-GEN-001-DRAFT02 Version 2 publiée sur rpd
5 Juin 2019	Version 3 : AFPUB-2018-GEN-001-DRAFT03 Section 8.5 - Les actions de suivi des membres dont les adresses électroniques abusives échouent aux validations sont laissées à la discrétion d'AFRINIC conformément aux politiques / procédures pertinentes. Section 8.6 - Le processus d'escalade pour fraude de validation devrait être fourni par AFRINIC (auparavant, seule une adresse e-mail pour escalade avait été fournie)