Détails
|
Mise à jour de la politique Abuse Contact Policy Update |
|||
|
ID: |
AFPUB-2018-GEN-001-DRAFT06 |
Date de soumission: |
5 Août 2020 |
|
Auteur : |
Jordi Palet Martínez jordi.palet sur theipv6company.com The IPv6 Company |
Version: |
6.0 |
|
Obsolètes: |
Modifie: |
Art CPM 8.0
|
|
Proposition
1. 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 RIRCela 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 coordonnées 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 les abus et engendre généralement des problèmes de sécurité et des coûts pour les victimes. Ceci est également contradictoire avec RSA, qui stipule que les informations contenues dans les bases de données doivent être exactes. Cette politique garantit que cela peut être vérifié automatiquement et périodiquement par AFRINIC, sans entrer dans les détails opérationnels de la manière de le faire. En fait, il existe une activité AFRINIC (https://afrinic.net/stats/contact-update) qui vise à la vérification des contacts, cependant, il n'a rapporté que pour 2017. Encore une fois, cette proposition garantit que cette activité se fait de manière automatisée (autant que possible), ce qui économise des coûts pour les membres et la communauté.
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, par exemple, utilise désormais l'IRT, mais comme une proposition équivalente a été acceptée, un «lien» automatisé (alias ou pointeur) vers l'IRT préexistant sera créé, de sorte que abuse-c et abuse-mailbox prévalent.
Il n'est pas nécessaire de supprimer les autres données optionnelles aujourd'hui incluses dans l'IRT, c'est une décision opérationnelle AFRINIC sur la manière de gérer la transition. Cette politique garantit simplement que abuse-c et abuse-mailbox sont disponibles et vérifiés périodiquement.
2. Résumé de la manière 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 un problème dans leurs réseaux et qui ne sont pas au courant 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 l'AFRINIC, un délai raisonnable pour permettre à la fois au personnel de développer l'outil et aux membres de mettre à jour leurs contacts en matière 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 attribut obligatoire (abus-c) qui doit être utilisé pour publier les informations de contact public concernant les abus dans la région de service AFRINIC. L'attribut 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:
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), pointant vers une personne ou un rôle, avec au moins une boîte de réception (boîte aux lettres abusive) valide, surveillée et activement gérée destinée à recevoir des rapports 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 enfants 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
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" Emails envoyés à "abuse-mailbox":
|
|
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:
|
|
|
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. |
|
|
8.6 Escalade vers AFRINIC Comportement frauduleux (par exemple, une «boîte aux lettres d'abus» qui ne répond qu'aux e-mails d'AFRINIC, ou aux messages avec un sujet ou un contenu spécifique), ou non-respect des autres aspects de cette politique (erreur ou absence de réponse aux abus) peuvent être signalés à l'AFRINIC pour une revalidation (conformément au paragraphe 8.5 ci-dessus) |
3.2 Informations supplémentaires:
Si cette proposition atteint un consensus, pour s'y conformer, AFRINIC doit renommer mnt-IRT en abuse-c. C'est une décision AFRINIC opérationnelle si un alias (pointeur, attribut dupliqué, ou toute autre alternative) vers mnt-IRT est conservé et pour combien de temps (période de transition), afin de faciliter la recherche dans whois pour les mêmes informations, que vous recherchiez abuse-c ou mnt-IRT. C'est une décision opérationnelle AFRINIC de conserver et pour combien de temps, l'IRT ou le supprimer, ainsi que le reste des informations réelles dans l'IRT. AFRINIC décidera également comment mieux mettre à jour les directives actuelles (https://www.afrinic.net/library/membership765-abuse-policy-bcp) ou s'ils ne sont plus nécessaires. Ceci est fait afin d'assimiler l'IRT à la majorité des RIRs où il est abusif-c.
A titre de clarification, les périodes de validation «initiale» et «escalade» peuvent être modifiées par AFRINIC, si cela est jugé opportun, à condition qu'il informe la communauté de sa motivation pour le faire. Par exemple, dans la phase de mise en œuvre, les périodes peuvent être prolongées et ajustées à mesure qu'un pourcentage plus élevé de contacts devient précis.
De même, la fréquence de la validation périodique peut être modifiée si AFRINIC le juge approprié et informe la communauté des raisons pour lesquelles elle le fait.
Par exemple, une seule validation peut être effectuée au cours de la première année pour faciliter le respect de la politique. Le nombre de validations annuelles pourrait augmenter dans le temps, devenant peut-être trimestriel, dans le but d'améliorer la qualité des contacts.
4. Références
Une proposition équivalente a été acceptée dans l'APNIC (déjà mis en œuvre) et le LACNIC (en cours de mise en œuvre) et est en cours de discussion dans le RIPE.
Historique des révisions
Historique des révisions
|
Date |
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 Initiales Draft Publié sur rpd |
|
5 Juin 2019 |
|
|
2nd Novembre 2019 |
Version 4 : AFPUB-2018-GEN-001-DRAFT04 Simplification globale du texte |
|
21 Novembre 2019 |
Version 5 : AFPUB-2018-GEN-001-DRAFT05 Précisions supplémentaires sur le texte |
| 5 Août 2020 |
Version 6 : AFPUB-2018-GEN-001-DRAFT06 Améliorations éditoriales Correction d'une faute de frappe dans 'Références' (2020/09/15) |
Analyse d'impact de la politique AFRINIC
Évaluation du personnel AFRINIC
| Date d'évaluation | Concernant la proposition |
|---|---|
| 24 août 2020 | AFPUB-2018-GEN-001-DRAFT06 |
1. Interprétation du personnel et compréhension de la proposition
Cette proposition de politique demande à AFRINIC de mettre en place un contact et une boîte aux lettres d'abus appropriés. Il met à jour la section 8.0 du Manuel des politiques consolidées. En ce moment, AFRINIC WHOIS objets - aut-num, inetnum et inet6num ne contiennent pas l'attribut abuse-c
A - L'abus-c: -
- doit être utilisé pour publier des coordonnées publiques d'abus dans la région de service AFRINIC.
- sont vérifiées automatiquement et périodiquement à l'aide de l'automatisation, si possible par AFRINIC afin de faciliter le signalement des abus dans / entre les régions.
- ne remplace pas les données incluses dans l'objet IRT sur l'AFRINIC whois base de données mise en œuvre pour le moment
- est obligatoire dans les objets de ressources «aut-num», «inetnum» et «inet6num» dans les ressources allouées / assignées par AFRINIC ainsi que dans d'autres ressources qui pourraient être utilisées à l'avenir
- présents dans les objets enfants de ceux directement distribués par AfriNIC (Affectations, sous-allocations) peuvent être soit nouveaux, soit hérités des ressources parent déléguées par AFRINIC
- doit avoir au moins un attribut de boîte aux lettres d'abus valide et activement surveillé
- doit pointer vers une personne ou un rôle, avec au moins une boîte de réception électronique valide, surveillée et activement gérée (abuse-mailbox)
- L'attribut "abuse-mailbox" doit être disponible sans restriction via whois, API et techniques futures.
B - Validation de la boîte aux lettres Abuse-c / abuse-mail
AFRINIC développera la procédure de validation abuse-c / abuse-mailbox répondant aux objectifs suivants: -
- Un processus simple qui garantit que le contact abusif est capable de remplir son objectif.
- Confirme que le détenteur de la ressource:
- a lu la procédure et la politique
- surveiller régulièrement la boîte aux lettres d'abus
- des mesures sont prises
- les rapports d'abus reçoivent une réponse.
- Période de validation initiale ne dépassant pas 15 jours.
- Si la validation échoue, passez à d'autres contacts LIR et définissez une nouvelle période de validation ne dépassant pas 15 jours.
Fréquence de validation effectuée par AFRINIC: -
- Au moment de la création de abuse-c / abuse-mailbox
- Au moment où abuse-c / abuse-mailbox sont mis à jour
- Périodiquement - pas moins d'une fois tous les 6 mois
- Chaque fois qu'AFRINIC le juge bon.
C. Escalade vers AFRINIC
AFRINIC veillera à ce que les journalistes puissent escalader et signaler les comportements frauduleux tels que: -
- Boîte aux lettres d'abus qui ne répond pas
- Abuse-mailbox qui ne répond qu'aux emails d'AFRINIC, ou aux messages avec un sujet ou un contenu spécifique)
- Non-respect des autres aspects de cette politique (incorrects ou absence de réponse aux cas d'abus)
De tels cas, lorsqu'ils sont signalés, déclencheront la revalidation du contact abuse-c.
D. AFRINIC doit: -
- confirmer si la proposition peut être mise en œuvre dans les 90 jours tel que rédigé, ou;
- prévoir un délai raisonnable pour permettre à la fois au personnel de développer l'outil et aux membres de mettre à jour leurs contacts en cas d'abus.
La période initiale d'application de la conformité à la politique n'est pas spécifiée et, par conséquent, un alignement implicite avec la période de validation de 6 mois est supposé
Bénéficiez à AFRINIC
La précision du whois base de données en termes d'abus de contacts augmentera au fur et à mesure que ses membres adopteront et mettront en place un contact d'abus conformément à cette politique.
Impact sur les membres
Outre les objets Personne / rôle existants qui servent de contacts administratifs et techniques, les membres doivent: -
- fournir un contact abuse-c à AFRINIC qui est valide, surveillé et activement géré
- assurez-vous que les e-mails envoyés à la boîte aux lettres abuse-c dans le contact abuse-c
- Exiger leur intervention
- Ne doit pas obliger le journaliste à remplir un formulaire.
- Doit garantir la réception des rapports d'abus et des journaux, exemples ou en-têtes de courrier électronique associés.
- Assurez-vous que leurs procédures internes de traitement des abus reflètent ce qui précède afin de se conformer à la politique.
- Le support technique (y compris le service d'assistance / les applications de ressources) pour les membres existants ne sera offert que si le respect de cette politique est respecté
- S'assurer qu'ils conservent à tout moment leurs informations de contact, y compris abuse-c, afin d'être en conformité avec cette politique et le RSA
2.0 Commentaires du personnel d'AFRINIC sur la clarté de la politique
Aucune
3.0 Demandes de clarification du personnel d'AFRINIC
AFRINIC suppose que abuse-c ne sera pas obligatoire pour inetnum et aut-num qui détiennent le statut hérité. Des conseils clairs de l'auteur sont nécessaires à ce sujet.
4.0 Commentaires du personnel sur les domaines d'impact
4.1 Impact sur les fonctions de registre
1. Si cette politique proposée parvient à un consensus, une amélioration de l'exactitude et de l'actualité des données du registre est attendue, car les attributs «abuse-mailbox:» devraient être à jour et corrects. Cela réduira également le nombre d'e-mails d'abus qui sont dirigés vers les files d'attente AFRINIC en raison du manque de contacts d'abus actuellement.
2. Les procédures MS nécessiteront des mises à jour comme suit: -
Nouvelle procédure / sous-processus à développer pour la validation de la boîte aux lettres abuse-c / abuse-mail.
3. WHOIS
- L'abus-c doit être un objet de personne / rôle sur le WHOIS base de données. abuse-mailbox est déjà un attribut de l'objet person / role.
- L'attribut abuse-c doit être ajouté sur le WHOIS base de données comme attribut aux objets inetnum, inet6num et aut-num
- Objet IRT obsolète
- Supprimez les attributs mnt-irt des objets inetnum, inet6num et aut-num.
- Ajoutez des règles de validation pour forcer la boîte aux lettres abuse sur les objets de personne et de rôle qui sont référencés via l'attribut abuse-c.
- A WHOIS la requête de l'inetnum, inet6num et aut-num doit fournir le contact d'abus dans la réponse.
4. MyAFRINIC
- Un codage sera nécessaire pour assurer la création / les mises à jour / l'importation des contacts d'abus
- Les contacts d'abus ne doivent pas avoir d'identifiants de connexion sur MyAFRINIC à moins qu'il ne soit également utilisé dans un autre rôle et qu'il soit donc maintenu par des contacts administratifs/techniques
- Mise à jour de l'émission des ressources / mise à jour des règles de gestion pour rendre abuse-c obligatoire (tout ou hors héritage TBC)
- Mises à jour des formulaires de sous-allocation et d'affectation avec la règle métier sur l'abus-c
- Un outil pour valider les boîtes aux lettres tel que mandaté par cette proposition de politique devra être mis en œuvre et abuser des contacts marqués comme valides / non valides
- Un outil permettant aux membres de mettre en œuvre l'abus-c sera développé.
5. NMRP
Étant donné que l'abus-c deviendra obligatoire, des modifications seront également nécessaires sur le NMRP où le demandeur doit fournir l'e-mail de la boîte aux lettres d'abus à ajouter aux ressources si la demande est approuvée.
4.2 Impact sur les opérations des services aux membres
Panne:
| Objet | Compter WHOIS DB | Protégé par mnt-irt |
|---|---|---|
| Inetnum | 139268 | 232 |
| Inet6num | 31230 | 33 |
| num-aut | 1915 | 32 |
Organisations membres: 28 sur un total de 1857 membres ressources ont adopté la politique actuelle de contact en cas d'abus et 27 objets IRT (sur 42 objets IRT créés dans le whois db) sont référencés dans leurs ressources sur le whois base de données.
- La base de données AFRINIC contient environ 7,000 6 aut-nums distincts et inet (27) nums de premier niveau (alloués directement par AFRINIC) et seuls XNUMX objets IRT distincts sont référencés. Cela implique une charge de travail considérablement élevée pour le service MS lors de la validation initiale pour que tous les membres se conforment à la politique. Cette activité peut nécessiter une approche par étapes pour s'assurer que la charge de travail est gérable. Bien que le processus soit automatisé autant que possible, un soutien considérable aux membres sera fourni par les services aux membres.
- La documentation des membres sur le site Web d'AFRINIC sera améliorée avec des lignes directrices sur la politique de contact en cas d'abus
- L'application initiale de la conformité à la politique nécessitera probablement plus de 6 mois de période de validation pour que le personnel fournisse le soutien nécessaire à tous les membres. Cela augmentera la charge de travail du département des services aux membres si la période initiale d'application de la conformité à la politique est alignée sur la période de validation de 6 mois. Le département aura besoin de personnel supplémentaire pour s'assurer que tous les membres reçoivent le soutien nécessaire dans les 6 mois.
Alternativement, une période de 12 mois serait faisable pour effectuer la mise en œuvre initiale de la politique, et si elle est alignée sur la période de validation, elle se fondra facilement avec une autre activité interne où la vérification des informations sur les membres sera effectuée à un cycle de 12 mois.
5.0 Legal
Au cas où cette politique parviendrait à un consensus, le non-respect de cette politique par un membre d'AFRINIC sera considéré comme une violation de la clause RSA et le membre sera encouragé à remédier à la violation. Le non-respect persistant peut entraîner la révocation du RSA conformément à la clause.
6.0 Finance
Recrutement de personnel de soutien supplémentaire pour faire face à l'augmentation des tickets que la mise en œuvre de la politique entraînera.
7.0 Calendrier de mise en œuvre
En raison du nombre important de systèmes impactés et du codage requis pour intégrer les membres d'AFRINIC à l'adoption du contact abuse-c, 90 jours pour la mise en œuvre ne peuvent pas être respectés. L'équipe AFRINIC peut mettre en œuvre la politique dans les 6 mois suivant le dernier appel comme mandaté par le CPM sur ses systèmes et 12 mois pour amener les membres à se conformer à la politique.