Résumé

  • ASPA atteste les fournisseurs amont autorisés et complète la validation d’origine par une preuve sur le chemin.
  • La publication, la validation, la classification et le rejet sont quatre étapes distinctes.
  • En déploiement partiel, Unknown signifie preuve insuffisante; ce n’est ni Valid ni Invalid.

L’objet est visible, la route reste acceptée

Le tableau RPKI affiche un nouvel ASPA correctement signé. Le même chemin client volontairement invalide est ensuite annoncé à un routeur de production. Il reste installé parce que la politique d’import de production ne consomme pas le résultat ASPA du validateur. L’objet n’a pas échoué: le test isole l’absence d’action de la politique d’import.

APNIC décrit ASPA comme la liste signée des fournisseurs autorisés d’un ASN. Une ROA répond à la question de l’origine d’un préfixe; elle ne garantit pas la cohérence du chemin. Le projet IETF applique donc des procédures différentes selon qu’une route arrive d’un client, d’un pair, d’un fournisseur, d’un client de route server ou d’un sibling.

Le déploiement est progressif. L’absence d’attestation sur un saut produit souvent Unknown. Les recommandations opérationnelles de RIPE maintiennent ces routes acceptées afin qu’une couverture incomplète ne provoque pas une panne. Dire que toutes les routes acceptées sont validées effacerait cette incertitude.

ASPA ne couvre pas tout. Le projet IETF recommande OTC en complément pour certaines fuites initiées localement. Le résultat cryptographique ne prouve ni l’acheminement des paquets, ni l’intention de trafic, ni la réalité commerciale d’une relation.