Résumé

  • Une PE BGPsec configurée pour deux ASN doit conserver des clés valides pour les deux, y compris l’ancienne jusqu’à migration des sessions eBGP concernées. C’est une condition de chemin, pas un acte de droit des sociétés.
  • La coexistence de ROA, la double signature et le segment pCount=0 décrivent chacun un mécanisme limité. Ils ne certifient ni acquisition, ni contrôle, ni bascule de tous les pairs, ni trafic livré.

Une signature cryptographique rassure parce qu’elle semble ferme. Mais sa fermeté porte sur l’objet exact qu’elle signe, pas sur l’histoire que l’on aimerait lui faire raconter. Dans le cas d’une migration d’ASN, cette différence est essentielle : un routeur peut avoir besoin de l’ancienne identité précisément parce que le changement n’est pas simultané.

RFC 8206 pose un scénario où un fournisseur peut fusionner des AS et où une PE peut encore se présenter à un pair sous l’ancienne ASN. « Peut » n’est pas le nom d’une entreprise ni le constat d’une opération. Le texte ne documente pas une transaction ; il examine ce qui arrive au chemin BGPsec lorsqu’une configuration locale traverse cette période ambiguë. La migration peut être longue, sans changement global ni coordination obligatoire avec tous les clients. Des ASN historiques peuvent donc demeurer visibles sans que cette visibilité explique leur statut institutionnel.

L’origin validation illustre exactement ce piège. Pendant la transition, la nouvelle ASN peut avoir besoin d’un ROA pour les mêmes préfixes que l’ancienne ASN continue d’originer. Deux autorisations d’origine sont admises. Un ROA est une autorisation RPKI à l’usage de la validation d’origine ; il ne dit pas qui possède une société, qui a conclu une fusion, quel routeur est devenu actif, ni quel pair acceptera l’annonce. Le lire comme un certificat de fin de transition, c’est déplacer une preuve hors de son champ.

La validation de chemin ne répare pas ce déplacement. RFC 8205 relie BGPsec à des certificats RPKI attestant des allocations d’ASN et d’espace d’adressage. Le routeur qui émet utilise la clé privée correspondante ; le validateur n’a pas besoin de la détenir. La signature autorise donc une conclusion sur une construction de chemin, dans la politique de confiance du validateur. Elle ne transporte pas un contrat commercial, une déclaration de contrôle ou un reçu de trafic utilisateur.

La solution de RFC 8206 est plus étroite encore. Elle vise une PE configurée localement avec les deux ASN, face à un pair eBGP déjà dans une frontière de confiance connue. À l’export, la PE signe avec les deux ASN et emploie pour la transition ancienne un pCount=0. Pour un voisin non BGPsec, la reconstruction de AS_PATH ne révèle pas ce segment ; le Secure_Path BGPsec le conserve. À l’import, si la CE attend encore l’ancienne ASN, la PE ajoute le segment dans la condition prévue. Ces détails ne font pas de la signature une attestation qui voyage librement de réseau en réseau.

Le RFC refuse d’ailleurs l’hypothèse selon laquelle un domaine client non coordonné accepterait ce pCount=0. Pas de reconfiguration imposée à la CE distante, pas de configuration mondiale, pas d’allongement visible du chemin : l’économie du mécanisme est locale. Elle protège l’interopérabilité au point de contact défini. Elle ne prouve pas que les exigences évitées ont été satisfaites ailleurs.

La règle de conservation de clé doit être lue de la même manière. Les deux clés restent valides et l’ancienne doit l’être jusqu’à ce que les sessions eBGP pertinentes aient migré. Un paquet signé ne proclame pas que cette dernière condition est remplie. Il peut seulement faire partie de la trace permettant à l’opérateur de l’établir, avec l’inventaire des sessions, les configurations de PE, les fenêtres de validité, les journaux de validation et des mesures de transfert. Le validateur distant décide, lui, selon sa propre relation de confiance et d’affaires.

Le principe de spécification initiale minimale de Heng Lu éclaire la retenue de ce dispositif. La règle commune fixe le minimum déterministe nécessaire à l’interopérabilité et à la sécurité. Le calendrier, la garde des clés, le choix des pairs, l’acceptation des clients et l’adoption effective restent des décisions locales. Une RFC publiée ou une clé présente ne transforme pas ces décisions en fait universel.

Il faut donc garder une échelle de preuves distincte : procédure RFC, autorisation ROA, possession de clé, chemin signé, décision de validation, état de session, observation de transfert, résultat de service, puis documents de registre ou d’entreprise. Wesley George est co-auteur d’une spécification Standards Track ; cette qualité ne transforme ni le RFC ni une signature issue du mécanisme en bulletin sur une fusion réelle.

Sources