- Plus de détails
- Proposition
- Historique des révisions
- Analyse d'impact de la politique AFRINIC
- Implémentation
Plus de détails
|
RPKI ROAs for Unallocated and Unassigned AFRINIC Address Space |
|||
|
ID: |
AFPUB-2019-GEN-006-DRAFT03 |
Date de soumission: |
19th Avril 2021 |
|
Auteur : |
Frank Habicht geier à geier.ne.tz Association des FAI de Tanzanie Marc Elkins mje chez posix.co.za POSIX Jordi Palet Martínez jordi.palet sur theipv6company.com Le IPv6 L'entreprise Haitham El Nakhal Hytham sur tra.gov.eg Autorité de régulation nationale des télécommunications (NTRA) |
Version: |
3.0 |
|
Statut: |
Ratifié |
Modifie: |
Nouvelle section |
Proposition
1.0 Résumé du problème traité par cette proposition
L'espace d'adressage géré par AFRINIC qui est soit « Non alloué » soit « Non attribué » est considéré comme un « espace d'adressage Bogon ». Tel que défini dans la RFC3871, un « Bogon » (pluriel : « bogons ») est un paquet avec une adresse IP source dans un bloc d'adresses non encore alloué par l'IANA ou le RIRs ainsi que toutes les adresses réservées à un usage privé ou spécial par les RFC.
Le but de la création de RPKI ROA avec l'origine AS0 pour l'espace d'adressage non alloué et non attribué d'AFRINIC est de restreindre la propagation des annonces BGP couvrant cet espace bogon. Lorsque AFRINIC émet un ROA avec AS0 pour l'espace d'adressage non alloué sous l'administration d'AFRINIC, les annonces BGP couvrant cet espace seront marquées comme invalides par les réseaux effectuant une validation de l'origine BGP basée sur RPKI à l'aide du TAL d'AFRINIC.
2.0 Résumé de la façon dont cette proposition résout le problème
Cette proposition charge AFRINIC de créer des ROA pour tous les espaces d'adressage non attribués et non attribués sous son contrôle. Cela permettra aux réseaux effectuant la validation de l'origine BGP basée sur RPKI de rejeter facilement toutes les annonces de bogon couvrant les ressources gérées par AFRINIC.
Actuellement, en l'absence de ROA, ces bogons sont marqués comme NotFound. Étant donné que de nombreux opérateurs ont mis en œuvre ROV et planifient ou suppriment déjà Invalid, tous les ROA AS0 qu'AFRINIC créera pour l'espace d'adressage non alloué seront également supprimés.
Le processus pour les périodes de validité du ROA et la libération des ROA avant affectation / allocation par AFRINIC est laissé au personnel d'AFRINIC pour définir les procédures internes habituelles.
Il est suggéré que, si cette politique est adoptée, elle soit placée comme une nouvelle section à la fin de la RPC. Cette modification éditoriale peut être effectuée par le personnel, renumérotant / réorganisant toutes les sections pertinentes, même en ajustant les titres / sous-titres pour la nouvelle section afin de mieux correspondre au texte adopté.
3. Proposition
La nouvelle section CPM est la suivante :
|
Actuel |
Proposition |
|
1 RPKI ROA pour l'espace d'adressage AFRINIC non alloué et non attribué
AFRINIC créera des ROA d'origine AS0 pour tous les espaces d'adressage non alloués et non attribués (IPv4 et IPv6) dont il est l'administrateur actuel. Tout détenteur de ressources peut créer un ROA AS0 (zéro) pour les ressources dont il dispose sous son compte / son administration. Un ROK RPKI est une attestation positive qu'un détenteur de préfixe a autorisé un système autonome à créer une route pour ce préfixe vers la table de routage BGP globale. Un ROA RPKI pour les mêmes préfixes d'origine AS0 (zéro) montre une intention négative du détenteur de la ressource de faire publier les préfixes dans la table de routage BGP globale. Seul AFRINIC a le pouvoir de créer des ERP RPKI pour l'espace d'adressage non encore alloué ou attribué à ses membres. Si AFRINIC souhaite allouer de l'espace d'adressage à l'un de ses membres, le ou les ROA RPKI d'origine AS0 devront être révoqués au préalable. L'espace d'adressage ne peut être alloué qu'une fois que la ou les ROA d'origine AS0 ont été entièrement supprimées et ne sont pas visibles dans les référentiels. Les ROA AS0 pourraient être sous un localisateur d'ancre de confiance (TAL) distinct, de sorte qu'il devient un service opt-in et fournit des mesures séparées, au moins dans les phases de déploiement initial. Ceci et d'autres détails opérationnels sont laissés à la discrétion d'AFRINIC. AFRINIC ne devrait ajouter des ressources récupérées qu'à la fin du processus de récupération.
|
Références 4.0
Une proposition équivalente a déjà atteint un consensus au sein de l'APNIC et du LACNIC.
Historique des révisions
Historique des révisions
|
Date |
Plus de détails |
| 19th Avril 2021 |
Version 3: AFPUB-2019-GEN-006-DRAFT03 Prise en compte des ressources récupérées |
| 30ème Juillet 2020 |
Version 2: AFPUB-2019-GEN-006-DRAFT02 TAL distincte |
|
4ème Novembre 2019 |
Version 1: AFPUB-2019-GEN-006-DRAFT01 Initiales Draft Publié sur rpd |
Analyse d'impact de la politique AFRINIC
ÉVALUATION DU PERSONNEL AFRINIC
1. Interprétation du personnel et compréhension de la proposition
- Cette proposition oblige AFRINIC à créer des ROA d'origine AS0 pour tous ses non alloués et non attribués IPv4 et IPv6 l'espace d'adressage qu'il administre actuellement. L'espace non alloué et non attribué ici signifie l'espace disponible et réservé selon le fichier de statistiques déléguées étendu AFRINIC.
- Les nouveaux préfixes reçus de l'IANA/PTI auraient immédiatement des ROA AS0.
- Tous les préfixes renvoyés par ou récupérés auprès des membres auront également un ROA AS0
- Lorsque AFRINIC alloue un espace d'adressage à l'un de ses membres ressources, le ROA ou les ROA RPKI d'origine AS0 couvrant l'espace devront d'abord être révoqués ET ne pas être visibles dans les référentiels, avant que l'allocation / l'affectation ne puisse avoir lieu.
- Le processus de validité des ROA et de libération des ROA avant affectation / allocation par AFRINIC est laissé au personnel d'AFRINIC à définir dans les procédures internes.
- Les ROA AS0 pourraient être sous un localisateur d'ancre de confiance (TAL) distinct, de sorte qu'il devient un service opt-in et fournit des mesures séparées, au moins dans les phases de déploiement initial.
- La période de validité de ces ROA est de 10 ans (comme c'est le cas actuellement pour tous les ROA), sauf si une période de validité spécifique est spécifiée par les auteurs de la proposition de politique.
- AFRINIC ne devrait ajouter des ROA aux ressources récupérées qu'à la fin du processus de récupération.
Impact sur les membres
Aucun impact sur les ressources des membres car les ROA AS0 seront créés sur les ressources non allouées et non affectées IPv4 et IPv6 Ressources. AFRINIC s'assurera que le ROA RPKI ou les ROA d'origine AS0 couvrant l'espace devront d'abord être révoqués ET ne pas être visibles dans les référentiels avant que l'allocation / l'affectation ne puisse arriver à un Membre Ressource.
2.0 Commentaires du personnel d'AFRINIC sur la clarté de la politique
Aucune
3.0 Demandes de clarification du personnel d'AFRINIC
Aucun.
4.0 Commentaires du personnel sur les domaines d'impact
Impact sur les fonctions de registre
- Une mise à niveau du système de gestion des stocks AFRINIC sera nécessaire afin de mettre en œuvre cette politique
- Automatisation de la création de ROA AS0 pour les ressources actuellement non allouées dans son inventaire ainsi que les ressources entrantes (soit à partir de la récupération de ressources, des retours ou du réapprovisionnement de son pool depuis IANA/PTI)
- Ajustements du processus d'émission des ressources ainsi que des délais pour s'assurer que les ROA sont révoqués et que les ROA révoqués sont supprimés des référentiels des validateurs avant que les ressources ne soient émises.
- Une mise à jour sur les interfaces des systèmes AFRINIC et les contrôles internes utilisés pour la gestion des ressources et des transferts sera nécessaire
- Améliorer la surveillance globale pour s'assurer que les membres ne créent pas systématiquement des ROA avec AS0 avec les préfixes dont ils ont besoin pour annoncer conformément aux politiques en vertu desquelles ils ont reçu ces ressources.
- Les politiques existantes mises en œuvre ou en cours d'implémentation seront prises en considération afin qu'une vérification soit effectuée pour déterminer quels préfixes l'utilisation des préfixes ne nécessite pas d'annonce dans le routage global
- La documentation des membres pour la gestion des ROA doit être mise à jour
Impact sur le système RPKI
Côté RPKI, 3 options ont été étudiées notamment,
- Utilisez l'arborescence AFRINIC RPKI existante
- Certificat de production supplémentaire (0/0) pour l'espace non alloué uniquement
- Nouvelle ancre de confiance avec un seul certificat de production
AFRINIC recommande l'option C car elle devient alors un service opt-in et ne pollue pas le RPKI actuel.
Évaluation juridique
Pas de commentaires
Évaluation financière
Aucun CAPEX ne sera requis pour la mise en œuvre de cette proposition de politique.
5.0 Implémentation
Si cette proposition parvient à un consensus et est ratifiée, la mise en œuvre sera effectuée sur une nouvelle ancre de confiance (séparée) afin qu'elle devienne un service opt-in et n'affecte pas la configuration actuelle de la RPKI.
Journal
Depuis qu'AFRINIC a planifié la migration vers myafrinic v2 au T4-2021. L'inventaire AFRINIC des ressources non allouées et non allouées sera intégré sur le myafrinicla plate-forme v2 et l'équipe technique pourront implémenter les ROA AS) sur celles-ci. Nous avons été informés que la politique peut être entièrement mise en œuvre d'ici le T2-2022.
