Résumé

  • Le RFC 8212 laisse TCP et le FSM atteindre Established, mais rend les routes reçues inéligibles sans Import Policy et interdit leur entrée dans Adj-RIB-Out sans Export Policy.
  • Import et export sont deux autorisations locales par famille. Un permit all explicite satisfait la présence ; le standard protège l’omission, non une décision erronée.
  • Installation neuve, nœud mis à niveau et exception insecure-mode peuvent diverger. La preuve couvre le mode effectif, le hash de politique, les RIB avant/après, la réception distante, le FIB et le trafic.

À minuit, le remplacement d’un routeur semble réussi. TCP 179 tient, les compteurs progressent, mais FRRouting affiche (Policy) en IPv4. IPv6, hérité d’un autre modèle, annonce un agrégat. Le même équipement est vivant dans deux familles et autorisé dans une seule.

Une connexion n’accorde aucune route

Le RFC 4271 sépare la machine d’état et les RIB. Le RFC 8212 modifie la décision et la dissémination, pas le handshake.

À l’import, des UPDATE peuvent exister en Adj-RIB-In ou dans une capture. Sans politique explicite, ils n’entrent pas dans le Decision Process. « Le voisin n’a rien envoyé » diffère de « nous n’avons rien autorisé ».

À l’export, Loc-RIB et FIB peuvent être complets tandis qu’Adj-RIB-Out reste vide. Le succès local ne crée aucune reachability chez le peer.

Deux décisions locales existent donc : utiliser l’information reçue et divulguer l’information détenue. Le transport ne donne ni l’une ni l’autre.

Deux portes pour chaque famille

Une session peut accepter une default route et n’annoncer que les préfixes clients. Elle peut ouvrir IPv6 avant IPv4. AFI/SAFI et direction sont des clés de politique indépendantes.

Un badge Established cache cette matrice. L’inventaire doit nommer peer, VRF, AS, famille, sens et source de l’attachement. Un peer-group peut fournir une règle qu’un override voisin annule.

La spécification initiale minimale est un refus commun : l’absence ne vaut jamais permission. Préfixes, chemins et relations restent des décisions futures locales.

Explicite ne signifie pas prudent

Le RFC 8212 exige une configuration explicite, pas une politique restrictive. BIRD autorise encore all et none. Un allow-all de laboratoire peut être légitime ; le même sur un transit peut provoquer une fuite.

Un nom de route-map ne prouve rien non plus. L’objet peut utiliser une liste vide, une génération IRR ancienne, un namespace erroné ou être attaché au mauvais voisin.

Conservez le contenu résolu et son hash. Comparez pre-policy et post-import, puis candidats d’export, Adj-RIB-Out et observation distante. Zéro route doit avoir une cause connue : policy absente, deny explicite ou aucun match.

L’historique d’installation change le défaut

Le RFC permet un mode de déviation. Son exemple N+1/N+2 introduit d’abord insecure-mode et des avertissements, puis change le défaut des nouvelles installations. Un upgrade peut conserver l’ancien comportement alors qu’un nœud propre rejette.

Copier le stanza visible ne copie pas cette provenance. FRR expose ebgp-requires-policy, son override et (Policy) ; BIRD exige deux règles explicites. Il faut toutefois vérifier release, migration et valeur runtime.

Toute exception reçoit propriétaire, portée, routes, échéance et test de suppression. Sans date, le moyen de migration devient architecture cachée.

Attacher une règle doit réévaluer l’état

Après ajout d’une Import Policy, les routes peuvent venir d’une table stockée, d’un Route Refresh RFC 2918 ou d’un reset. L’équipe doit connaître le mécanisme et prévoir les attributs.

L’activation export peut libérer immédiatement des milliers de routes locales. Calculez le delta Adj-RIB-Out et demandez au récepteur de confirmer. N’ouvrez pas les deux sens dans une transaction opaque.

Commencez par deny explicite, puis un sentinel import et un sentinel export. Chaque étape a un résultat prédit et un rollback.

Un socle, pas toute la sécurité

Le RFC 7454 décrit filtres de préfixes, AS-path et communautés ; RFC 7908 classe les leaks ; RFC 9234 ajoute Roles/OTC ; RPKI teste l’origine. Aucun ne remplace l’autorisation complète import/export.

Une route origin-valid peut rester indésirable. Maximum-prefix limite une quantité après admission. Default reject empêche seulement qu’un oubli devienne consentement.

Le risque de second ordre est la conformité cérémonielle : créer permit all pour faire passer le déploiement. La primauté du code exécuté exige policy compilée, attachement, RIB, réception distante, FIB et paquets.

Le canari commence vide

Établissez un peer de faible portée sans règles. Prouvez OPEN/KEEPALIVE, éventuel input pré-policy, zéro route éligible et zéro Adj-RIB-Out. Ajoutez deny explicite et montrez que le zéro devient intentionnel.

Autorisez un seul préfixe entrant, prédisez attributs, sélection et next hop. Autorisez ensuite un seul préfixe sortant et vérifiez l’encodage puis la réception. Répétez pour chaque famille et testez aussi les non-matches.

Le rollback retire le grant, vérifie les withdrawals et revient au silence. Désactiver RFC 8212 globalement élargit le pouvoir et n’est pas un rollback.

Established sans routes peut être l’état le plus précis : le canal existe, l’autorité n’existe pas encore. Une exploitation mûre rend ce refus visible, réversible et vérifiable.