Qui contrôle la ROA dans un bail IPv4?

Résumé

Une autorisation d’origine de route (ROA) est une déclaration signée selon laquelle un système autonome nommé peut annoncer des préfixes spécifiés. Elle ne constitue pas un transfert de propriété, un ordre aux routeurs, une garantie que la route est bénigne, ni une preuve que l’AS nommé est toujours autorisé en vertu d’un bail privé.
Dans la plupart des baux, le bailleur reste le détenteur direct des ressources et se trouve donc au plus près de la chaîne de certification RPKI. Le preneur exploite le réseau et sait quels AS d’origine et quelles routes plus spécifiques sont nécessaires sur le plan opérationnel. Le fournisseur de transit achemine ou filtre la route. Le RIR exploite une ancre de confiance ou un service de certification parent. Il s’agit de pouvoirs distincts.
Les RPKI hébergés et délégués modifient la garde et l’exécution, pas l’accord commercial sous-jacent. Un service hébergé confie les opérations clés et la publication à un RIR; un service délégué permet au détenteur d’exploiter une autorité de certification (CA) et généralement sa clé privée. Aucun de ces arrangements ne donne, en soi, au preneur des droits en temps voulu ni ne le protège contre une suppression contestée.
Chaque bail devrait intégrer un calendrier d’autorisation précisant les préfixes exacts, les AS d’origine autorisés, les longueurs maximales, les fenêtres de début et de fin, le délai ordinaire de modification, le délai d’urgence, les approbateurs, les canaux d’authentification et les preuves à conserver. Une promesse générique de fournir une lettre d’autorisation ne suffit pas.
Le temps contractuel et le temps RPKI doivent être délibérément alignés. Les services hébergés peuvent renouveler automatiquement les objets signés, les caches se rafraîchissent selon leur propre cadence, et une route peut rester visible après la durée du contrat. L’expiration à minuit n’est donc ni une révocation technique instantanée ni une raison valable de supprimer la seule ROA valide avant que le trafic ait migré.
L’accès d’urgence doit être étroit et redondant. Le preneur doit pouvoir ajouter rapidement une origine d’atténuation ou de remplacement préapprouvée, tandis que le bailleur a besoin de limites empêchant une délégation ouverte. Une double approbation, des préfixes bornés, une autorité d’urgence de courte durée, des journaux indépendants et une revue post-incident peuvent satisfaire les deux besoins.
Un litige commercial ne devrait pas se régler en prenant par surprise le système de routage mondial. Sauf urgence de sécurité active, la suppression d’une ROA devrait suivre une notification, une courte fenêtre de continuité, une escalade indépendante et un retrait coordonné de la route. La révocation finale doit être certaine; le chemin qui y mène ne devrait pas transformer les clients en moyen de pression.

Le bail sépare l’usage de l’attestation

La question délicate dans un bail IPv4 n’est pas de savoir qui possède le routeur, mais qui peut émettre la déclaration cryptographique sur laquelle d’autres routeurs peuvent s’appuyer.

Le preneur peut configurer l’AS d’origine, annoncer le préfixe, servir des clients, répondre aux rapports d’abus et payer la facture de transit. Pourtant, si le préfixe reste certifié au nom du bailleur, le preneur peut être incapable de créer, modifier ou supprimer la ROA qui décrit sa propre annonce en direct. Le bailleur peut être économiquement passif et techniquement décisif. Un compte de portail oublié ou un signataire indisponible peut transformer un changement de routage ordinaire en un risque de panne.

Cela ne rend pas la location défectueuse. Cela signifie qu’un bail repose sur deux systèmes d’autorité différents. Le droit des contrats détermine ce qu’une partie a promis à l’autre. Le RPKI détermine si une autorisation signée peut être validée via une chaîne ancrée dans la hiérarchie des ressources numériques. BGP détermine les chemins que les réseaux annoncent et sélectionnent effectivement. Les contrats de transit déterminent ce qu’un fournisseur amont acceptera. Aucun de ces systèmes ne lit automatiquement les autres.

RFC 9582définit une ROA comme un objet signé par lequel un détenteur de bloc d’adresses autorise un AS à annoncer des routes vers un ou plusieurs préfixes. Sa section sécurité est exceptionnellement utile pour la gouvernance: le RPKI fournit une autorisation plutôt qu’une authentification d’identité ou une non-répudiation. L’objet prouve qu’un chemin de certification valide soutenait la déclaration lorsque les parties utilisatrices l’ont traitée. Il ne divulgue pas le bail, le prix, le client, l’utilisateur bénéficiaire, la raison de la route ou la date limite dans l’accord commercial.

Cette distinction écarte deux raccourcis courants. Le premier dit que la partie capable de créer la ROA doit être le propriétaire économique. Cela ne découle pas. Le second dit que la partie désignée comme origine dans la ROA doit contrôler les droits d’adresse. Cela ne découle pas non plus. Un détenteur peut autoriser l’AS d’un client, un fournisseur amont, un réseau cloud ou un fournisseur d’atténuation sans transférer la ressource. L’objet signé est délibérément plus étroit que la relation environnante.

La bonne question n’est donc pas simplement: « Qui contrôle la ROA? » C’est un ensemble de questions: Qui peut demander un changement? Qui décide que la demande relève du bail? Qui exploite le système de signature? Qui peut arrêter un changement dangereux? Qui peut agir lorsque la partie principale est injoignable? Qui supporte la perte si un changement promis est en retard? Qui doit supprimer l’autorisation lorsque le droit d’acheminer la route prend fin?

Un bail qui ne répond qu’à la première question abandonne le reste à l’improvisation.

Quatre acteurs détiennent quatre types de pouvoirs différents

Le bailleur, le preneur, le fournisseur de transit et l’autorité de certification RIR sont souvent décrits comme s’ils étaient les points d’une seule chaîne de commandement. Il vaut mieux les comprendre comme quatre acteurs aux pouvoirs croisés mais non identiques.

Le bailleur conserve généralement la relation enregistrée dont découle la certification des ressources. Dans un service RPKI hébergé, un utilisateur autorisé pour l’organisation du bailleur peut créer des configurations de ROA via l’interface du RIR. Dans une configuration déléguée, le bailleur peut exploiter sa propre CA et détenir la clé privée correspondante. La capacité décisive du bailleur est l’attestation: il peut faire entrer ou sortir de l’ensemble RPKI validé une déclaration concernant un préfixe et un AS d’origine.

Le preneur possède la connaissance opérationnelle. Il connaît l’origine prévue, la conception du transit, l’état de migration des clients, les plus spécifiques pour l’ingénierie de trafic, les dispositions d’atténuation et la date à laquelle une nouvelle route doit fonctionner. Sa capacité décisive est l’usage: lui-même ou ses fournisseurs peuvent configurer et annoncer des annonces BGP. Cette capacité peut exister même lorsque la route devient invalide au sens RPKI, car le RPKI ne désactive pas BGP. La conséquence pratique dépend des réseaux qui appliquent la validation d’origine de route et de la manière dont ils le font.

Le fournisseur de transit dispose du pouvoir d’acceptation et de propagation. Il peut exiger une lettre d’autorisation, un objet IRR, une ROA correspondante, une preuve contractuelle ou une combinaison de ceux-ci. Il peut construire des filtres de préfixes clients à partir de ses propres enregistrements, d’un IRR, des charges utiles validées RPKI ou d’un examen manuel. Il peut refuser une route pourtant valide si la relation client n’est pas vérifiée, ou acheminer une route non trouvée selon sa politique. Une ROA valide est une preuve pertinente, pas un ordre pour le fournisseur de transit.

L’autorité de certification RIR s’inscrit dans la hiérarchie de certification.RFC 6480décrit une architecture alignée sur l’allocation des ressources de numérotation. Les services RIR émettent ou maintiennent le certificat de ressource parent, hébergent la signature pour de nombreux détenteurs, publient le matériel et relient les modifications des ressources certifiées à la hiérarchie. Le RIR n’est pas partie à la plupart des baux et ne connaît normalement pas leurs conditions commerciales complètes. Son système peut authentifier le compte du détenteur et valider la couverture des ressources sans savoir si la facture d’un preneur est contestée.

Ces pouvoirs ne doivent pas être fusionnés. La capacité du bailleur à supprimer une ROA ne signifie pas qu’il doive contrôler le routeur du preneur. La capacité du preneur à envoyer une annonce ne signifie pas qu’il doive avoir un pouvoir de signature illimité sur l’agrégat du bailleur. Le filtre d’un fournisseur de transit ne règle pas le bail. Le certificat d’un RIR n’arbitre pas l’usage bénéficiaire.

Une bonne gouvernance commence par admettre qu’aucun acteur ne voit la totalité de la relation.

Une ROA autorise une origine, pas une route dans toutes ses dimensions

L’étroitesse de la ROA est une force, mais elle devient dangereuse lorsque les contrats la décrivent de manière trop large.

Une ROA identifie un AS d’origine et un ou plusieurs préfixes. Elle peut inclure une longueur maximale qui autorise certaines annonces plus spécifiques. Si plusieurs AS sont autorisés à annoncer le même préfixe, des ROA distinctes sont nécessaires. L’objet n’indique pas quel fournisseur amont peut acheminer la route, quel chemin AS est acceptable, si l’origine a un accord de service en cours, quel trafic client appartient aux adresses ou si une annonce est géographiquement attendue.

C’est pourquoi un « bail conforme au RPKI » peut dissimuler plus qu’il ne révèle. Un bailleur peut créer une ROA techniquement valide pour le mauvais ASN de l’entreprise. Un preneur peut continuer à annoncer via l’origine autorisée après l’expiration d’un contrat de service. Un AS autorisé peut fuir accidentellement ou annoncer délibérément un plus spécifique permis par une longueur maximale trop large. Une route peut être valide au sens RPKI tout en étant opérationnellement erronée ou abusive.

RFC 6483avertit qu’une ROA peut affecter d’autres annonces couvertes par le même espace d’adressage: les routes provenant d’origines non répertoriées, ou les plus spécifiques dépassant la longueur autorisée, peuvent devenir invalides. Elle recommande de prendre en compte toutes les origines légitimement autorisées et les plus spécifiques pertinents.RFC 7115traite également la validation d’origine comme une donnée opérationnelle plutôt que comme un verdict universel de sélection de route.

Pour un bail, cela signifie que le calendrier ne peut pas simplement dire: « Le bailleur créera une ROA. » Il doit indiquer les paires préfixe-origine exactes et expliquer la politique de plus spécifiques. Si un /20 ne sera annoncé que comme un /20 depuis l’ASN du preneur, une longueur maximale inutilement permissive ne devrait pas être accordée par commodité. Si le preneur a besoin d’annonces /24 depuis deux origines pendant la migration, les deux origines et la période temporaire doivent être explicites.

Le rôle du fournisseur de transit reste distinct. Lesactions MANRS pour les opérateurs de réseaudemandent aux opérateurs de s’assurer de l’exactitude de leurs propres annonces et de celles de leurs clients, de conserver des contacts joignables et de publier des informations que d’autres peuvent valider. Un fournisseur de transit qui vérifie uniquement si une ROA existe n’accomplit pas cette tâche. Il doit encore savoir que son client est la partie autorisée à lui demander d’acheminer la route.

Le bail devrait donc promettre plusieurs faits coordonnés, et non un statut magique: une autorisation commerciale du bailleur, une instruction opérationnelle du preneur, une autorisation d’origine dans le RPKI, des informations de routage exactes et l’acceptation par le fournisseur de transit prévu.

Le RPKI hébergé concentre l’exécution sur le compte du détenteur

Le RPKI hébergé est attrayant car il retire la majeure partie de l’administration cryptographique au détenteur des ressources. Cette commodité clarifie aussi là où se situe la dépendance au bail.

Le guide de l’autorité de certification hébergée de RIPE NCCindique que le service hébergé signe, publie et renouvelle les objets ROA à partir des configurations gérées par un compte autorisé. L’utilisateur gère les informations d’origine et de préfixe prévues; le service s’occupe des clés, du renouvellement des objets et de la publication.La documentation RPKI hébergée d’ARINplace de même l’autorité de certification et la signature chez ARIN et indique que les organisations en aval doivent demander à leur fournisseur amont de soumettre des ROA en leur nom lorsqu’elles ne peuvent pas participer directement.

Pour un bailleur, le service hébergé peut réduire les défaillances opérationnelles. Il n’y a pas de dépôt de CA privé à surveiller pour le preneur ni de clé de signature à placer sur un ordinateur portable d’employé. Pour un preneur, en revanche, la question clé devient la gouvernance du compte. Quelles personnes chez le bailleur peuvent approuver une demande? Y a-t-il une couverture 24 heures sur 24? Le preneur peut-il avoir un rôle restreint, ou chaque modification doit-elle être transcrite par le détenteur? Que se passe-t-il si le compte du bailleur est verrouillé lors d’un contrôle d’identité, d’un changement d’entreprise ou d’un litige?

L’accès au portail ne doit pas être partagé à la légère. Donner au preneur les identifiants généraux du bailleur peut exposer des préfixes non liés, d’autres clients et des actions destructrices. Cela brouille également l’attribution: le bailleur ne peut pas savoir ultérieurement si son employé, son contractant ou son client a effectué une modification. Même si une interface prend en charge plusieurs utilisateurs, l’autorisation devrait être limitée à l’organisation et aux tâches que chaque personne est autorisée à exécuter.

Le modèle hébergé plus sûr traite le preneur comme un demandeur authentifié et le bailleur comme un approbateur borné. Les demandes utilisent un canal défini, identifient le bail et les préfixes, incluent l’origine et la longueur maximale proposées, et reçoivent un enregistrement de transaction. Les modifications de routine ont un délai de service. Les modifications d’urgence utilisent un canal plus rapide avec une authentification distincte. Deux personnes chez le bailleur doivent pouvoir agir, et le preneur doit disposer d’au moins deux demandeurs approuvés.

L’automatisation peut réduire les délais, mais elle doit appliquer le calendrier d’autorisation plutôt que de le contourner. Une demande pour un préfixe répertorié, un ASN répertorié et une longueur maximale autorisée peut être éligible à une approbation rapide. Une demande visant à autoriser un ASN inconnu ou une plage de plus spécifiques plus large doit s’arrêter pour examen humain. La distinction est entre automatiser une promesse connue et élargir silencieusement la promesse.

Le service hébergé résout l’exploitation des clés. Il ne résout pas la délégation commerciale à moins que le contrat et les rôles de compte ne le fassent.

Le RPKI délégué déplace la clé, pas la relation parente

Le RPKI délégué peut donner au détenteur de ressources une plus grande autonomie technique. Il peut aussi créer la fausse impression que le détenteur s’est affranchi de toute dépendance amont.

La comparaison de RIPE NCC entre service hébergé et déléguéindique qu’un opérateur délégué contrôle son certificat de ressource et la clé privée correspondante, et peut choisir où publier.Les options de déploiement d’ARINprécisent qu’un détenteur direct peut exploiter sa propre CA, signer des ROA et, dans le modèle délégué, émettre des certificats de ressource pour les clients. APNIC identifie également le mode auto-hébergé comme RPKI délégué dans sonmatériel de certification des ressources.

Cette architecture peut soutenir une division plus directe. Un bailleur averti peut exécuter une CA parente et émettre un certificat de ressource subordonné limité aux préfixes du preneur. Le preneur peut alors signer des objets dans cet ensemble borné sans recevoir de pouvoir sur les autres ressources du bailleur. À la fin du bail, le bailleur peut révoquer ou laisser expirer le certificat subordonné selon la séquence convenue.

L’élégance apparente s’accompagne d’obligations opérationnelles. Quelqu’un doit sécuriser la clé privée, maintenir la CA, publier les objets courants, gérer les manifestes et les informations de révocation, surveiller la disponibilité, renouveler les clés et conserver l’accès de récupération. Lapolitique de RIPE NCC sur les CA déléguées durablement non fonctionnellesillustre la conséquence d’une défaillance prolongée: après une incapacité étendue à découvrir et valider le matériel à jour, le parent peut révoquer le certificat de ressource délégué. La délégation est un contrôle associé à la maintenance, pas une remise unique.

La relation parente demeure également. Un certificat délégué existe au sein d’une hiérarchie. Si les ressources certifiées changent ou si le certificat parent est révoqué, l’autorité subordonnée est affectée.RFC 8211examine les actions adverses ou erronées des autorités de certification et des gestionnaires de dépôts précisément parce que la possession locale d’une clé n’élimine pas les dépendances hiérarchiques et de publication.

Pour de nombreux preneurs, exploiter une CA serait disproportionné. Pour les grands opérateurs avec des changements d’origine fréquents, plusieurs fournisseurs de transit ou des besoins stricts de continuité, une délégation bornée peut valoir le coût. Le choix devrait dépendre de la fréquence des changements, de la tolérance aux pannes, des compétences du personnel et de la conception du portefeuille du bailleur, et non du prestige de détenir une clé.

Plus important encore, le RPKI délégué ne doit pas devenir un octroi permanent informel. Les ressources subordonnées, la durée du certificat, la règle de renouvellement, les événements de révocation, les obligations de dépôt, les contacts d’urgence et les preuves de destruction ou de transfert en fin de contrat doivent tous figurer dans le bail. Rapprocher la clé privée du preneur réduit un délai tout en augmentant l’importance d’une résiliation disciplinée.

Le calendrier d’autorisation est l’instrument commercial manquant

L’accord principal peut énoncer la contrepartie économique. Un calendrier d’autorisation distinct devrait énoncer la contrepartie de sécurité de routage en des termes qu’un ingénieur et un avocat peuvent tous deux tester.

Le calendrier commence par les CIDR exacts. Il énumère ensuite chaque AS d’origine autorisé, la personne morale contrôlant cet AS, la relation de transit ou d’hébergement prévue et la longueur de préfixe autorisée pour chaque annonce. Si plusieurs origines sont temporaires, le calendrier leur donne des dates de début et de suppression. Si le preneur peut utiliser un fournisseur d’atténuation, l’ASN du fournisseur peut être pré-approuvé sans être activé jusqu’à un incident.

Viennent ensuite les rôles. Nommer le responsable du service et l’approbateur de secours du bailleur, le responsable réseau et le demandeur de secours du preneur, et les contacts chez chaque fournisseur de transit prévu. Utiliser des adresses de rôle et des canaux authentifiés, pas seulement des employés nommés. Les employés partent; l’autorisation doit survivre sans laisser derrière des comptes personnels obsolètes.

Le calendrier fixe ensuite les horloges. Une demande normale peut nécessiter une réalisation dans un délai d’un jour ouvrable. Une migration planifiée peut nécessiter un préavis de cinq ou dix jours ouvrables. Une panne grave peut nécessiter un accusé de réception en quinze minutes et une modification bornée en soixante minutes. Les chiffres précis dépendent du service, mais le silence n’est pas un niveau de service.

L’enregistrement des modifications devrait inclure l’heure de la demande, le demandeur authentifié, le préfixe concerné, l’ancienne et la nouvelle origine, la longueur maximale, la raison commerciale, l’approbation, l’observation de publication et l’observation de validation. Ce n’est pas une bureaucratie pour elle-même. Lorsqu’une route devient invalide, les parties doivent savoir si la ROA n’a jamais été modifiée, modifiée mais pas encore visible, modifiée incorrectement ou rendue inefficace par une autre ROA couvrante.

Enfin, indiquer les demandes que le bailleur peut rejeter. Une demande en dehors du préfixe loué, un ASN non contrôlé par un opérateur approuvé, une longueur maximale plus large que la conception de routage convenue, ou un changement qui invaliderait les routes d’un autre client peuvent nécessiter un avenant plutôt qu’une exécution immédiate. Un rejet doit être motivé et horodaté, et non une invocation vague de sécurité.

Le calendrier doit être versionné avec des signatures ou une acceptation authentifiée équivalente. L’ensemble de ROA en direct doit être comparé avec celui-ci lors de l’activation, après chaque modification approuvée, lors d’une revue périodique et avant la résiliation. L’accord a alors une réponse mesurable au contrôle: le bailleur contrôle la certification dans le cadre d’un mandat pré-convenu; le preneur contrôle les demandes opérationnelles dans le même mandat; ni l’un ni l’autre ne peut élargir silencieusement le risque de l’autre partie.

Le temps contractuel et le temps RPKI sont deux horloges différentes

Les baux utilisent des dates parce que les dates sont lisibles par les tribunaux et les équipes financières. La sécurité du routage fonctionne par publication et récupération, qui partagent rarement la même frontière.

Un bail peut commencer à 00:00 UTC le lundi. La ROA peut être créée plus tôt pour que les caches des parties utilisatrices puissent la récupérer avant la première annonce. Un service hébergé peut renouveler l’objet signé automatiquement tant que sa configuration reste active. Si le bail se termine, le droit commercial peut expirer même si la dernière autorisation publiée reste valide et visible. Inversement, supprimer la configuration à 00:00 ne prouve pas que chaque partie utilisatrice a supprimé la charge utile validée correspondante à 00:01.

Le contrat a donc besoin de trois moments plutôt qu’un. Le moment de préparation de l’autorisation est celui où la route prévue dispose d’une autorisation valide visible et où le fournisseur de transit a confirmé ses filtres. Le moment d’utilisation du service est celui où le preneur peut annoncer et placer le trafic client sur le préfixe. Le moment de fin d’autorisation est celui où l’ancienne origine ne doit plus être représentée comme autorisée dans le RPKI après le retrait du trafic.

Ces moments peuvent se chevaucher sans contradiction. Une ROA peut être préparée avant l’utilisation commerciale, à condition qu’il soit interdit au preneur d’annoncer tôt. Elle peut subsister brièvement pendant un retrait ordonné, à condition qu’il soit interdit au preneur d’ajouter de nouveaux clients et qu’il doive réduire le trafic. L’autorisation résiduelle est une capacité de transition contrôlée, pas une prolongation de l’économie du bail.

Cela explique aussi pourquoi l’expiration de la ROA est un mauvais substitut à la résiliation. Une longue durée de certificat ou d’objet peut dépasser le bail. Une courte durée peut créer un risque de renouvellement évitable pendant le terme. Les systèmes hébergés peuvent renouveler bien avant l’expiration, tandis que les systèmes délégués dépendent d’une opération locale. L’événement déterminant devrait être une instruction explicite de fin, étayée par l’observation, plutôt que l’espoir qu’un minuteur coïncide avec l’accord.

L’inadéquation inverse compte aussi. Si un bailleur supprime la ROA avant que les adresses de remplacement ou l’origine alternative du preneur ne soient prêtes, les réseaux qui rejettent les routes invalides peuvent cesser d’acheminer le trafic. Les clients subissent la panne même si le bailleur est contractuellement correct sur la date finale. Si le bailleur ne la supprime jamais, l’ancien preneur conserve une possibilité plus faible mais réelle d’annoncer une route que certains validateurs considéreront comme autorisée.

L’alignement temporel n’est donc pas de la clémence. C’est la discipline de faire apparaître l’autorisation avant la dépendance et de la faire disparaître après la dépendance, avec aussi peu de chevauchement risqué que le service peut tolérer.

Les droits de modification d’urgence doivent être conçus avant l’urgence

Le test le plus révélateur de la gouvernance de la ROA n’est pas une migration planifiée. C’est une panne un samedi où l’origine approuvée ne peut pas acheminer le trafic et où le seul ingénieur qui signe normalement les modifications dort ou est injoignable.

Une urgence peut nécessiter un nouveau fournisseur de transit, un ASN d’atténuation DDoS, un centre de données de secours, une origine de remplacement après une panne de routeur, ou une annonce temporaire plus spécifique. Elle peut également impliquer des informations d’identification RPKI compromises ou une autorisation accidentelle qui rend les routes légitimes invalides. La partie qui observe l’incident peut être le preneur, le fournisseur de transit, le bailleur ou un réseau externe.

Le bail devrait pré-autoriser des catégories, pas une action illimitée. Une liste d’ASN de réserve peut être vérifiée à la signature. Une longueur de préfixe d’urgence maximale peut être fixée. Le preneur peut être autorisé à activer uniquement les préfixes qu’il loue et pour une courte période seulement. Tout changement plus large nécessite un approbateur supplémentaire. Cela donne à l’opérateur de la vitesse sans lui remettre un chèque en blanc permanent.

L’authentification doit survivre au même incident. Si les demandes ordinaires dépendent d’un domaine de messagerie hébergé derrière le préfixe affecté, le canal peut tomber en panne lorsqu’on en a besoin. Utiliser au moins une méthode hors bande et conserver les contacts dans les deux organisations. Le bailleur doit exiger un code de demande, un rôle nommé, un rappel ou une approbation cryptographique appropriée au risque des parties. L’objectif est de résister à l’usurpation d’identité sans transformer la vérification d’identité en un obstacle de plusieurs heures.

La modification elle-même doit être réversible. Ajouter l’origine étroitement requise; ne pas élargir des ROA non liées. Fixer une expiration ou une date limite de revue pour l’autorisation d’urgence. Confirmer que la nouvelle route est observée et acceptée avant de retirer l’ancien chemin. Après l’incident, supprimer l’autorité temporaire et réconcilier l’ensemble en direct avec le calendrier.

La responsabilité doit suivre les retards contrôlables. Si le preneur n’a pas maintenu les contacts approuvés ou a exigé un ASN non répertorié sans preuve, il doit en supporter la conséquence. Si le bailleur a manqué un délai d’urgence convenu malgré une demande valide, un simple crédit de frais peut ne pas refléter la perte des clients; l’accord peut nécessiter un plafond d’indemnisation, un droit de résiliation ou un droit de passer à une délégation bornée. Si le fournisseur de transit a rejeté une route bien qu’ayant reçu toutes les preuves requises, ses conditions de service sont examinées séparément.

Les droits d’urgence devraient être exercés rarement. Leur valeur est que chaque partie connaît le parcours sous pression, pas que le bailleur devienne un bureau de routage 24 heures sur 24 pour des modifications courantes.

La longueur maximale est une décision de risque commercial

Le champ d’apparence la plus technique d’une ROA peut avoir une conséquence commerciale importante.maxLengthdétermine la spécificité d’une annonce que l’AS autorisé peut émettre tout en restant cohérent avec cette ROA.

Une autorisation trop étroite peut rendre invalide une route légitime d’ingénierie de trafic ou d’atténuation. Une autorisation trop large peut permettre des annonces plus spécifiques qui n’étaient jamais nécessaires au bail. La décision affecte le confinement des défaillances, les pratiques des fournisseurs de transit et la gamme de routes que les validateurs peuvent accepter comme autorisées.

L’erreur de rédaction facile est de fixer la longueur maximale à /24 pour chaque agrégat IPv4 loué parce que le /24 est communément accepté dans la table globale. Cela peut être pratique sur le plan opérationnel, mais cela délègue plus d’autorité que ce dont a besoin un preneur qui n’annonce que l’agrégat. Si un /19 est toujours annoncé comme un /19, un maximum /24 crée de la place pour 32 plus spécifiques distincts sans expliquer pourquoi.RFC 9582indique que le champ doit être omis lorsqu’il est égal à la longueur du préfixe et définit comment il limite l’autorisation de plus spécifiques.

L’erreur inverse est de n’autoriser que l’agrégat lorsque la conception documentée du preneur dépend de plus spécifiques. Un fournisseur de nettoyage d’urgence peut annoncer des /24. Une migration entre deux origines peut diviser temporairement un agrégat. Si le contrat ignore cette conception, le preneur demandera un changement précipité au pire moment.

Le calendrier d’autorisation devrait correspondre au plus petit ensemble de routes attendues, pas à l’ensemble le plus large techniquement possible. Lorsque plusieurs /24 sont attendus de différentes origines, des ROA explicites peuvent rendre la division visible. Lorsqu’un maximum plus large temporaire est justifié, il devrait avoir une date de fin et une raison.

C’est aussi un problème de portefeuille pour les bailleurs. Une large ROA couvrante peut interagir avec des baux plus spécifiques en dessous d’elle. Avant d’approuver un changement, le bailleur doit tester si la route valide d’un autre client deviendrait invalide en raison d’une autorisation couvrante avec une origine différente ou un maximum restrictif. L’inventaire du bailleur doit donc comprendre les chevauchements, pas seulement les lignes de bail.

Le principe commercial est l’autorité minimale nécessaire. Le preneur reçoit suffisamment de permission cryptographique pour exploiter le réseau convenu, y compris une résilience réaliste. Le bailleur ne conserve pas un veto artificiel sur les opérations documentées, mais il ne publie pas non plus une permission plus large que la contrepartie.

Le fournisseur de transit est un contrôle indépendant, pas un simple messager

Les fournisseurs de transit sont souvent traités comme le point de livraison final d’une lettre d’autorisation. Dans un bail mature, ils devraient participer plus tôt.

Avant l’activation, le fournisseur de transit prévu doit confirmer les préfixes exacts et l’ASN d’origine qu’il acceptera, les preuves qu’il exige, la taille minimale de route, le traitement des plus spécifiques, s’il construit des filtres à partir de données IRR ou RPKI, et la rapidité avec laquelle ces filtres se rafraîchissent. Cette confirmation figure à côté du calendrier de ROA car une autorisation techniquement correcte a peu de valeur opérationnelle si le filtre client du fournisseur de transit rejette encore la route.

Le fournisseur de transit doit authentifier son client de manière indépendante. Une ROA valide peut montrer qu’une chaîne de certification autorise l’ASN d’origine pour un préfixe. Elle ne prouve pas que la personne qui ouvre un ticket de transit contrôle cet ASN ni que le bailleur a approuvé le compte commercial. Une lettre d’autorisation peut relier les parties, mais les lettres sont faciles à transférer et difficiles à révoquer globalement. Les enregistrements de compte, les contacts vérifiés et la confirmation directe du bailleur rendent la preuve plus solide.

Pendant le bail, le fournisseur de transit ne devrait pas accepter un changement d’origine uniquement parce qu’une nouvelle ROA est apparue. Le changement peut être accidentel, malveillant ou destiné à un autre fournisseur. Il ne devrait pas non plus ignorer un nouvel état invalide. Il devrait contacter le preneur et le bailleur par des canaux connus, comparer la route avec la liste de préfixes convenue et déterminer si la route ou l’autorisation est erronée.

À la résiliation, le fournisseur de transit a un rôle décisif pour rendre la révocation réelle. Le bailleur peut supprimer une ROA, mais l’ancien preneur peut encore envoyer l’annonce BGP. Le fournisseur de transit peut supprimer l’autorisation de préfixe client et rejeter la route à la frontière directe. Cette action locale est souvent plus rapide et plus certaine que d’attendre que chaque réseau applique des données de validation mises à jour.

Cette division est saine. Le RPKI fournit une autorisation d’origine vérifiable globalement. Le fournisseur de transit applique la relation client au plus près de la source. Le bail relie les deux. Aucun ne devrait être invité à porter la charge entière.

Un fournisseur de transit qui prend en charge les préfixes loués peut publier ses exigences de preuve et son contact d’urgence. La prévisibilité facilite la location sécurisée. Un examen secret et incohérent pousse les opérateurs vers des tickets de dernière minute et des exceptions informelles, ce qui affaiblit à la fois la sécurité et la responsabilité.

Les litiges doivent être isolés du trafic client

La clause la plus difficile est ce qui se passe lorsque le bailleur et le preneur sont en désaccord sur l’argent, la violation, l’abus ou le renouvellement alors que le préfixe transporte encore des services en direct.

Le bailleur peut craindre qu’une période de continuité ne récompense le non-paiement ou ne permette un préjudice. Le preneur peut craindre que le bailleur n’utilise la suppression de ROA comme un coupe-circuit à distance. Les deux préoccupations sont légitimes. La réponse ne peut pas être une autorisation permanente, mais elle ne devrait pas non plus être une embuscade cryptographique non annoncée.

Commencer par distinguer les événements. L’expiration planifiée et le non-renouvellement ordinaire doivent suivre le plan de sortie complet. Une facture contestée devrait déclencher un avis et une courte période de remède, sauf si l’accord rend clairement le paiement immédiat et critique. Des preuves crédibles d’abus actif peuvent justifier des contrôles plus stricts, mais supprimer une ROA n’arrête pas nécessairement la route abusive; le fournisseur de transit direct et l’équipement du preneur restent des points d’intervention plus immédiats.

Une clé de signature compromise nécessite une action de sécurité même si la relation commerciale est saine.

Pendant un litige de bonne foi, geler l’expansion discrétionnaire. Le preneur ne devrait pas ajouter de clients, demander de nouvelles origines ou élargir les longueurs maximales. Le bailleur devrait préserver les dernières autorisations connues sûres pour la période de continuité bornée. Les deux parties devraient informer le fournisseur de transit qu’aucun changement n’est valide sans confirmation double, sauf urgence documentée nécessaire pour protéger le trafic.

Un contact d’escalade indépendant peut déterminer si une demande correspond au calendrier existant sans trancher l’ensemble du procès. La question est étroite: l’action demandée préserve-t-elle un service déjà autorisé, ou élargit-elle les droits? Cette détermination limitée peut maintenir la stabilité du routage pendant que les réclamations commerciales progressent ailleurs.

L’accord devrait également définir un arrêt définitif. La continuité ne peut pas devenir une occupation indéfinie. À la fin de la période de remède ou de migration, le preneur doit retirer les routes, le fournisseur de transit doit supprimer les filtres et le bailleur doit supprimer la ROA. Le manquement de l’une ou l’autre partie produit des preuves et des recours spécifiés. Si la sécurité des clients nécessite une ordonnance judiciaire ou une mesure d’urgence, les parties savent quels actes doivent être restreints.

Les journaux comptent le plus ici. Une partie alléguant une suppression injustifiée devrait pouvoir montrer l’autorisation convenue, la demande, l’accusé de réception, l’heure de modification et l’impact de validation. Un bailleur alléguant une utilisation continue devrait pouvoir montrer des observations de route après la date limite de retrait. L’isolement des litiges ne fonctionne que lorsque les faits peuvent être reconstitués sans faire confiance à la boîte de réception d’une seule partie.

La norme directrice est simple: ne pas faire des utilisateurs d’Internet non concernés le mécanisme d’exécution d’une dette privée, et ne pas utiliser leur dépendance pour rendre un bail perpétuel.

La révocation est nécessaire, mais la suppression n’est pas un remède complet

Un bail doit se terminer avec l’ancien preneur incapable de s’appuyer sur l’autorisation du bailleur. Cela nécessite une révocation ou une suppression au niveau approprié. Cela nécessite également plus qu’une révocation.

Lorsque le moment de fin d’autorisation arrive, le bailleur doit supprimer ou modifier la configuration de ROA pertinente. Dans les arrangements délégués, il peut révoquer le certificat subordonné borné après avoir confirmé qu’aucune autorisation continue n’est requise. Les parties doivent observer les charges utiles validées résultantes depuis plus d’un point d’observation indépendant. Un message de succès de portail est une preuve d’un acte soumis, pas une preuve que l’état public a convergé.

En même temps, le preneur doit retirer la route BGP et ses fournisseurs de transit doivent supprimer l’autorisation client. Les objets de route IRR qui nomment encore l’ancienne origine doivent être supprimés ou mis à jour. Les DNS inverses et les contacts publics ne devraient plus pointer vers un ancien opérateur lorsque cela induirait en erreur les rapports opérationnels ou d’abus. Ces systèmes ont des temps de rafraîchissement et des responsables différents, de sorte qu’un horodatage unique ne peut pas prouver une sortie complète.

La suppression peut également avoir des effets collatéraux. Une ROA peut couvrir plusieurs préfixes, et un certificat délégué peut contenir des ressources au-delà d’un bail si le bailleur l’a mal conçu. L’opérateur doit identifier l’objet ou l’autorisation exacte à modifier. « Révoquer le RPKI du client » n’est pas une instruction sûre à moins que la frontière de certification ne corresponde à la frontière du client.

Le risque résiduel va dans les deux sens. Si la ROA subsiste, l’ancien preneur conserve un avantage de validation s’il continue à annoncer. Si la ROA disparaît alors qu’une route périmée persiste, la route peut devenir invalide et être rejetée de manière inégale, créant une atteignabilité partielle plutôt qu’un silence universel. Si aucune ROA couvrante ne subsiste, la route peut devenir non trouvée et continuer à se propager selon de nombreuses politiques. L’état RPKI n’est donc pas un substitut fiable au retrait à la source.

Un enregistrement d’achèvement devrait indiquer: route retirée par l’ancienne origine; filtre du fournisseur de transit supprimé; ancienne ROA absente ou remplacée; aucune autorisation couvrante involontaire ne subsiste; certificat délégué clôturé le cas échéant; enregistrements IRR réconciliés; et surveillance poursuivie pendant une période d’observation définie. Les exceptions doivent être nommées plutôt que résumées en « fait ».

La révocation protège le bailleur et l’utilisateur suivant. Le retrait coordonné protège les clients actuels. Une sortie responsable fait les deux.

Le RIR doit authentifier l’autorité de certification, pas décider du bail

Les RIR occupent une position sensible car le service hébergé peut en faire le lieu où un changement contesté est exécuté. Cela ne signifie pas qu’ils devraient devenir des tribunaux pour chaque bail IPv4.

Le RIR a un intérêt légitime à authentifier l’organisation habilitée à utiliser son service de certification, à protéger les comptes, à maintenir la hiérarchie et à répondre à une compromission avérée des informations d’identification. Il peut avoir besoin de modifier les ressources certifiées après un transfert, une restitution ou un changement d’enregistrement. La documentation hébergée de RIPE NCC note que les certificats de ressources se mettent à jour lorsque les ressources se déplacent et que les ROA publiées sont ajustées lorsque les ressources sont supprimées. Ce sont des conséquences de la hiérarchie de certification.

Un litige de bail privé est différent. Le RIR ne dispose généralement pas du contrat, de l’historique des paiements, des faits de migration des clients et des preuves de la loi applicable nécessaires pour décider quelle partie est en violation. S’il accepte des instructions non fondées d’un preneur, il peut déplacer l’autorité du détenteur. S’il traite chaque instruction du détenteur comme concluante malgré une ordonnance judiciaire ou une compromission avérée du compte, il peut amplifier le préjudice. La réponse est un rôle étroit avec un processus clair.

Le RIR peut conserver les journaux, authentifier les acteurs du compte, publier l’état du service, fournir des canaux d’urgence documentés pour les incidents de sécurité et se conformer aux ordonnances juridiques valides. Il peut rendre les rôles de compte suffisamment granulaires pour qu’un détenteur n’ait pas à partager des identifiants étendus. Il peut expliquer les effets techniques des choix hébergés et délégués. Il devrait être prudent quant à la conversion d’une politique de location ambiguë en un contrôle discrétionnaire sur les routes en direct.

Cette retenue est cohérente avec la signification limitée de la ROA. Le service de certification vérifie l’autorité au sein de la hiérarchie des ressources de numérotation. Il ne certifie pas chaque raison privée d’exercer cette autorité. L’obligation commerciale reste exécutoire entre les parties et, si nécessaire, par les tribunaux ou les mécanismes de résolution des litiges convenus.

La couche de registre peut encore améliorer la location sans reconnaître une nouvelle catégorie de propriété. Elle peut prendre en charge des utilisateurs à portée limitée, un historique des modifications lisible par machine, des notifications à plusieurs contacts, des actions destructrices retardées lorsque c’est sûr, et des preuves exportables des configurations actuelles et antérieures. Ces outils réduisent la dépendance à un seul titulaire de compte tout en laissant la contrepartie juridique en dehors de la CA.

L’objectif politique devrait être une exécution prévisible, pas une approbation morale de chaque bail. Un système sécurisé peut distinguer la personne techniquement autorisée à signer de la personne contractuellement autorisée à demander sans prétendre qu’il s’agit toujours de la même personne.

Le contrôle a un prix économique

Le contrôle de la ROA est souvent intégré dans le prix du bail comme s’il s’agissait d’une tâche administrative gratuite. Il s’agit d’un service de continuité distinct.

Un bailleur qui promet des changements rapides doit maintenir du personnel formé, des informations d’identification protégées, une surveillance, des approbateurs de secours et une couverture d’incident. Un modèle délégué nécessite l’exploitation de la CA et la fiabilité de la publication. Un preneur qui a besoin de changements d’origine fréquents impose plus de coûts et crée plus de risques d’erreur qu’un preneur avec un seul ASN stable. La tarification devrait rendre ces différences visibles.

L’alternative est une fausse économie. Un bail à bas prix avec une réponse de cinq jours à une modification urgente de ROA peut être inutilisable pour un réseau ayant des engagements de disponibilité stricts. Un preneur peut alors partager les informations d’identification de manière informelle, demander des exceptions à un fournisseur de transit ou maintenir une autorisation trop large pour éviter des retards futurs. Chaque raccourci transforme un besoin de service non tarifé en risque de sécurité.

L’économie plus large de l’identité réseau renforce ce point. La note de Lu Heng surl’identité réseau et la continuité clientsoutient qu’une adresse peut s’intégrer dans les listes blanches des clients, les règles des partenaires, les API et les systèmes de conformité. Une fois que cela se produit, un changement de ROA échoué n’est pas qu’un inconvénient de routage. Il peut interrompre une identité commerciale à laquelle des parties externes font déjà confiance.

Sa discussion surla location IPv4 gérée et le risque de registresoulève un point de marché connexe: obtenir des adresses n’est que la transaction visible; l’opérabilité continue dépend de la manière dont les risques de registre, de routage et de cycle de vie sont portés. Une analyse neutre n’a pas besoin d’accepter chaque conclusion institutionnelle de cet argument pour reconnaître le fait opérationnel. La partie qui vend la continuité devrait décrire et tarifer les actes que la continuité exige.

Cela peut produire des niveaux de service. Un bail de base peut autoriser une origine stable et des changements pendant les heures ouvrables. Un bail résilient peut inclure deux origines, une atténuation pré-approuvée, une réponse 24 heures sur 24 et une réconciliation périodique. Un preneur disposant de sa propre CA compétente peut choisir une délégation bornée et accepter plus de devoirs. Des niveaux transparents valent mieux que prétendre que chaque bail inclut une administration RPKI instantanée et illimitée.

Le contrôle devrait également affecter les recours. Si le bailleur facture la couverture d’urgence et ne la fournit pas, la conséquence devrait être significative. Si le preneur choisit un niveau plus lent et exige ultérieurement une action instantanée, le bailleur ne devrait pas être traité comme ayant promis ce qu’il n’a pas vendu.

Le marché devient plus sûr lorsque la dépendance cryptographique est nommée comme faisant partie du produit plutôt que cachée dans le « support ».

Une répartition pragmatique des droits

Il n’existe pas d’arrangement universel, mais un défaut défendable peut être énoncé clairement.

Le bailleur conserve le contrôle ultime de la relation de certification des ressources et peut refuser les modifications en dehors du périmètre loué. Il doit maintenir au moins deux opérateurs autorisés, protéger les informations d’identification, créer les ROA initiales avant l’activation, respecter les délais définis de modification normale et d’urgence, donner un préavis avant toute action destructrice sauf urgence de sécurité réelle, et supprimer l’autorisation après une sortie vérifiée.

Le preneur contrôle la conception de son réseau dans le cadre du calendrier. Il doit identifier et prouver le contrôle de chaque ASN d’origine, fournir des plans de routage précis, maintenir deux demandeurs authentifiés, informer le bailleur avant les modifications planifiées, éviter les annonces en dehors de l’autorisation, surveiller l’état RPKI, retirer rapidement les routes à la résiliation et conserver la preuve de la fermeture par le fournisseur de transit.

Le fournisseur de transit vérifie indépendamment la relation client-préfixe, prépare les filtres avant l’activation, surveille les divergences, fournit un contact d’urgence direct, refuse les changements d’origine non planifiés en attente de confirmation et supprime l’autorisation à la sortie. Il ne se fie pas à une ROA comme seule preuve de l’autorité du client.

Le RIR ou la CA parente authentifie le détenteur de ressources, exploite ou soutient le modèle de certification choisi, protège la hiérarchie parente, fournit une publication fiable et des enregistrements des modifications, et traite les événements de compromission d’identifiants ou juridiques avérés dans un cadre transparent. Il ne déduit pas le bail privé de BGP et ne tranche pas les factures ordinaires.

Pour les baux à forte variation ou forte dépendance, une CA subordonnée bornée peut rapprocher l’exécution du preneur. Pour les baux à faible variation, le service hébergé avec des engagements de réponse stricts peut être plus sûr. Pour les très courtes durées, le coût de la transition RPKI et du fournisseur de transit peut justifier un préavis plus long ou une conception d’adressage différente. Le choix doit suivre la dépendance opérationnelle, pas l’idéologie.

Chaque modèle a besoin des mêmes garde-fous: périmètre exact, autorité minimale, contacts redondants, réponse mesurée, état visible, chevauchement sûr, résiliation ferme et preuves indépendantes. Supprimez-en un, et le contrôle migre vers quiconque possède le justificatif au moment où quelque chose tourne mal.

Le test est de savoir si l’autorité suit la responsabilité

Un bail IPv4 est durable lorsque la partie responsable du service peut obtenir l’autorisation nécessaire, tandis que la partie responsable de la ressource peut empêcher une expansion non autorisée et garantir une révocation finale.

Cet équilibre ne s’obtient pas en attribuant la ROA à un acteur en une phrase. Il s’obtient en reliant l’autorisation commerciale aux événements opérationnels. L’autorité de certification du bailleur ne doit pas devenir un veto non tarifé sur les modifications courantes du réseau. Le besoin de vitesse du preneur ne doit pas devenir une autorité de signature permanente sur un agrégat. Le fournisseur de transit ne doit pas externaliser la vérification du client à un objet cryptographique. Le RIR ne doit pas être poussé à trancher un contrat qu’il ne peut pas voir.

La technologie expose déjà les distinctions pertinentes. Une ROA nomme un préfixe, une origine et une longueur maximale optionnelle. Le service hébergé centralise les opérations de signature. Le service délégué déplace le contrôle des clés et la maintenance. Les parties utilisatrices récupèrent et valident le matériel publié. Les routeurs appliquent la politique locale. La tâche de gouvernance est de rendre le bail tout aussi précis.

Le bail le plus sûr crée l’autorisation avant que le trafic n’en dépende, maintient l’autorisation alignée sur les routes documentées, permet une adaptation d’urgence étroite, isole les litiges des clients, et retire à la fois la route et sa permission cryptographique à la fin. Il enregistre qui a fait chaque acte et quand.

La réponse finale à « Qui contrôle la ROA? » est donc intentionnellement plurielle. Le bailleur contrôle l’autorité certifiée. Le preneur contrôle le besoin opérationnel. Le fournisseur de transit contrôle l’acceptation directe. Le RIR contrôle un service parent ou hébergé dans son domaine. Le contrat contrôle la manière dont ces pouvoirs se rencontrent.

Si le contrat est muet, le détenteur du justificatif contrôle la crise. Si le contrat est précis, aucun acteur ne contrôle plus que la responsabilité qu’il a accepté de porter.