Résumé

  • Le certificat EE d’un ROA doit contenir les ressources IP, sans inherit, tandis que l’extension de délégation des identifiants AS doit être absente.
  • Le numéro d’AS autorisé se trouve dans asID, au sein de la charge signée. Le ROA établit une autorisation bornée, non l’identité de l’opérateur ni la non-répudiation.
  • Objet, VRP, route observée, réception par le routeur, politique locale, chemin retenu et livraison constituent des reçus différents.

Le contrôle de conformité a refusé un certificat « plus complet »

Un ingénieur avait ajouté au certificat l’AS figurant dans le ROA. La chaîne cryptographique était correcte, le préfixe correspondait et l’ajout paraissait prudent. Le validateur devait pourtant rejeter l’objet entier.

Le RFC 9582 ne demande pas au certificat de certifier l’AS destinataire. Il exige l’extension IP de RFC 3779, vérifie que chaque préfixe de la charge y est contenu et interdit inherit. Puis il impose l’absence de l’extension de délégation des identifiants AS. Le droit de signer vient des ressources d’adresses ; le choix de l’AS autorisé vient de la charge CMS signée.

Cette asymétrie donne sa précision au contrat. Le certificat répond : « ce signataire dispose de cette autorité sur ces adresses ». asID répond : « cette autorité permet à cet AS d’originer ces préfixes ». Il ne répond pas : « voici l’identité juridique ou humaine de l’AS ».

La section de sécurité le dit sans détour : l’infrastructure fournit une autorisation, pas une authentification explicite, et le ROA n’a pas vocation à établir la non-répudiation. Une interface qui affiche « AS authentifié » ajoute donc une affirmation que le standard n’a jamais transportée.

L’autorisation a une géométrie exacte

Un ROA contient un seul AS. Pour deux AS autorisés sur le même espace, il faut deux objets. Cette règle permet de retirer ou remplacer une autorisation sans confondre les autres, à condition que l’exploitation conserve l’identité de chaque objet au lieu de fusionner tous les résultats.

Chaque entrée d’adresse contient un préfixe et, éventuellement, maxLength. Sans ce champ, seul le préfixe exact est autorisé. Avec lui, l’autorisation s’étend aux sous-préfixes jusqu’à la longueur indiquée. Un /24 avec 26 ne signifie pas « tout ce qui se trouve sous le /24 » ; il s’arrête avant /27.

RFC 9319 recommande la prudence parce qu’un maxLength trop large agrandit la surface qu’un AS peut annoncer valablement. Cette question de portée ne doit pourtant pas être transformée en question d’identité. Un objet minimal et un objet large restent des autorisations de routage, pas des certificats d’existence, d’intention ou d’exploitation.

Une représentation unique ne produit pas un état unique

La structure ASN.1 permet plusieurs représentations du même ensemble. RFC 9582 définit donc un tuple afi, adresse initiale, longueur de préfixe et longueur maximale effective, puis un ordre total. Les tuples identiques sont des doublons. Cette canonicalisation facilite comparaison et déduplication.

Elle n’abolit pas le temps. Un objet canonique peut manquer dans un miroir, attendre le prochain cycle d’un validateur ou ne pas être arrivé au routeur. Deux validateurs peuvent observer des instantanés différents. La propreté des octets n’est ni fraîcheur, ni distribution, ni exécution.

La validation suit un ordre : profil générique RFC 6488, chemin de certificat, contenu, ressources IP, absence d’inherit, absence de l’extension AS, puis règles de structure. Un seul échec invalide le ROA entier. Il n’est pas permis de sauver localement une ligne et de lui conserver l’autorité du signataire.

La route arrive après le ROA

Le VRP dérivé d’un ROA valide devient une donnée de comparaison. RFC 6811 confronte ensuite une route reçue—préfixe, longueur, origine—à ces données et produit Valid, Invalid ou NotFound. L’objet ne prouve pas que la route existe ; la route ne réécrit pas l’objet.

La chaîne continue. RFC 8210 transporte les données validées vers le routeur. RFC 7115 et RFC 8893 laissent la décision d’importation ou d’exportation à la politique locale. Le routeur peut recevoir le VRP, calculer un état, appliquer une exception, choisir un autre chemin ou ne rien transporter vers ce préfixe.

La proposition honnête doit donc conserver son horodatage et sa portée : selon tel ancrage de confiance et tel instantané, cet objet autorisait cet AS à annoncer cet ensemble. Elle ne nomme pas l’entreprise, ne constate pas une annonce et ne promet aucune livraison.

Sources