Résumé

  • Le client choisit une paire de CE parmi celles que le contrat autorise ; le fournisseur conserve la décision d'admission, le calcul du segment PE-PE et l'allocation des ressources.
  • Le cœur peut rester secret alors que les adresses et les lieux des CE sont connus du fournisseur ; contrat, authentification, état du brassage optique et livraison observée sont quatre preuves distinctes.

La commande n'était pas une carte du réseau

Le geste paraît simple : un client sélectionne deux sites et demande qu'ils soient reliés. Le portail confirme la demande. Dans beaucoup de comptes rendus, ce moment devient aussitôt « le client contrôle son VPN ». Le RFC 5253 emploie une notion plus précise.

Le client contrôle la topologie de son L1VPN au sens où il peut demander la création, la modification ou la suppression d'une connexion entre des CE admissibles. Le fournisseur contrôle entièrement le segment PE-PE qui traverse son infrastructure. Il choisit la méthode de calcul, le segment préétabli éventuel, les ressources et les restrictions. Si le CE tente d'imposer un itinéraire interne au moyen d'un ERO, le PE rejette cette prétention.

Cette frontière protège les deux parties. Le client ne doit pas connaître la mécanique du cœur pour exprimer son besoin. Le fournisseur n'a pas à abandonner son ingénierie pour offrir une activation à la demande. Mais la frontière rend mensongère toute preuve unique appelée « connexion réussie ». L'acceptation de la demande, la sélection du chemin, la réservation, la programmation du brassage et l'arrivée des données n'ont ni le même auteur ni le même instant.

L'absence d'échange de routes est un choix de périmètre

En mode de base, CE et PE n'échangent pas d'informations de routage. Le CE obtient le CPI distant par configuration, par annuaire ou par une procédure propre au L1VPN. Dans le domaine du fournisseur, le routage continue, et les PE peuvent diffuser entre eux les informations d'appartenance.

Ce découpage réduit l'exposition du cœur et évite que le service dépende d'une fusion des plans de routage. Il ne supprime pas la dépendance opérationnelle. La demande du client doit correspondre à une table PIT, à une appartenance valide, à une règle de connectivité et à une capacité disponible. Chaque étape peut évoluer sans que le client en voie les détails.

Le chemin PE-PE peut être calculé à la demande, pré-calculé, voire pré-signalé. Le calcul peut appartenir au PE, à un PCE ou à un système de gestion. Plusieurs segments peuvent exister entre la même paire de PE. Un identifiant de chemin peut désigner l'un d'eux sans révéler sa composition.

Le fournisseur vend donc un résultat borné, pas le plan de ses fibres. En contrepartie, il doit être capable de relier le résultat annoncé à une trace interne : version de politique, calcul retenu, ressource admise, état programmé et mesure obtenue.

Une abstraction commerciale exige une preuve à deux faces

Les politiques peuvent s'appliquer par L1VPN ou par connexion et s'appuyer sur les contrats. Le fournisseur peut réserver des ressources à certains clients, affecter un segment précis à un VPN et décider si une création se fait immédiatement ou à partir d'un segment préétabli.

Cette souplesse est la valeur du service. Elle est aussi le lieu d'un risque documentaire. Une clé de chemin ne prouve pas la route actuelle. Un accusé RSVP-TE ne révèle pas la version de politique. Une mention « protégé » ne prouve ni la diversité physique ni le temps de bascule. Un état commercial « actif » ne lit pas les matrices de commutation.

La bonne preuve respecte la confidentialité. Côté fournisseur, elle relie l'identifiant de demande au calcul, à l'admission, aux deux extrémités programmées et au test de continuité. Côté client, elle relie les extrémités convenues, l'identité distante, la protection de la charge utile et le résultat mesuré. Les deux registres n'exposent pas les mêmes champs, mais ils doivent parler de la même connexion.

La confidentialité n'est pas réciproque

Le RFC offre plusieurs moyens de cacher le cœur : aucune route n'est distribuée du PE au CE, le RRO peut être filtré, une adresse interne dans une notification peut être remplacée par celle du PE, et une clé peut représenter un segment confidentiel.

Le fournisseur ne peut pas rester aussi ignorant du client. Il connaît au minimum les adresses et les emplacements des CE. Sans eux, il ne saurait rattacher les ports au bon L1VPN ni appliquer les restrictions de connectivité. D'autres éléments de la topologie du client peuvent demeurer secrets, mais les points d'attache sont structurellement visibles.

Cette asymétrie n'est pas, à elle seule, un abus. Elle crée néanmoins un pouvoir informationnel. Les lieux de raccordement peuvent révéler une concentration géographique, un site critique ou la forme d'une redondance. Ces données doivent donc avoir une finalité, des droits d'accès, une durée de conservation et une piste d'audit.

Symétriquement, la confidentialité du cœur ne doit pas devenir l'impossibilité de vérifier le service. Le fournisseur peut garder ses nœuds secrets tout en attestant une classe de diversité, un objectif de restauration et une mesure de livraison. Secret d'architecture et absence de responsabilité ne sont pas synonymes.

Le contrat identifie ; le protocole authentifie, s'il est configuré

Lorsqu'un CE est ajouté, son identité est établie dans le cadre du contrat et un canal de contrôle est créé. Le RFC ajoute une réserve décisive : l'entité de contrôle n'est pas authentifiée par cette seule opération. Il faut employer les procédures d'authentification RSVP-TE.

Le contrat répond à « qui devrait être autorisé ? ». La configuration répond à « quelle adresse le représente ? ». L'authentification répond à « qui a émis ce message ? ». L'intégrité répond à « le message a-t-il changé ? ». L'autorisation répond enfin à « cette requête, même authentique, est-elle permise ? ».

Un voyant « client de confiance » ne peut pas remplacer ces questions. Une clé peut survivre à la fin d'un contrat. Un CE légitime peut demander une paire interdite. Un message authentifié peut déboucher sur un mauvais brassage.

Même la séparation physique n'est pas un verdict cryptographique. Un canal dédié par client peut être considéré sûr, mais le RFC exige que des protections supplémentaires, comme IPsec, restent disponibles. Sur un canal partagé, les mécanismes de sécurité doivent être disponibles et appliqués. Une topologie privée réduit une exposition ; elle ne signe pas chaque message.

Un refus tardif consomme quand même le réseau

La restriction de connectivité peut être appliquée à l'entrée ou à la sortie. Le résultat politique est le même si la connexion interdite n'est jamais établie. Le coût, lui, diffère.

À l'entrée, une règle connue arrête la requête avant qu'elle traverse le cœur. À la sortie, les nœuds intermédiaires ont déjà traité la signalisation et peut-être conservé un état temporaire. Le RFC note explicitement ce gaspillage.

Compter seulement les refus donne donc une image flatteuse et incomplète. Il faut mesurer le lieu du refus, le nombre de systèmes touchés, la durée de l'état provisoire et la concurrence avec les demandes légitimes. Une défense en profondeur conserve un contrôle en sortie ; elle ne justifie pas d'envoyer toute requête impossible jusqu'au point le plus coûteux.

Le mot « protégé » doit nommer la panne

Le mode de base sait demander la protection du segment PE-PE, de liens et du canal de contrôle. Il ne permet pas toutes les combinaisons. Une même demande de protection de lien ne peut pas ne viser que l'accès ou que le cœur. Le modèle ne combine pas simultanément une reprise par lien sur la partie CE-PE et une reprise par segment dans le cœur. La récupération CE-CE par double rattachement à des PE distincts est hors périmètre.

Il faut donc contractualiser l'unité de panne : fibre d'accès, segment du cœur, équipement, site, groupe de risques partagés ou service multirattaché. L'acceptation d'un objet de protection n'est pas la preuve que les secours sont disjoints. Le retour du plan de contrôle n'est pas le retour du brassage. Le retour de la lumière n'est pas celui de l'application.

Chaque horloge doit être conservée. Sans cela, une moyenne de disponibilité dissimule l'endroit où l'engagement a réellement échoué.

Une fibre dédiée peut atteindre le mauvais destinataire

Une liaison optique dédiée est difficile à intercepter et l'appartenance exclusive à un L1VPN apporte une isolation réelle. Le RFC maintient pourtant le risque de mauvaise connexion : un brassage erroné peut livrer les données au mauvais consommateur.

La politique d'appartenance limite les couples possibles au même L1VPN. Elle ne regarde pas les photons arriver. Pour une charge utile sensible, le client reste invité à protéger sa propre couche, par exemple avec IPsec pour du trafic IP.

La preuve la plus forte est bilatérale. Le fournisseur relit les deux brassages et l'état des ressources. Le client authentifie l'extrémité et effectue une mesure bout en bout. Aucun des deux ne certifie le domaine invisible de l'autre à partir de son seul accusé de contrôle.

Garder la couture visible

Pour chaque connexion, il faut conserver séparément la révision du contrat, l'ensemble des CE admissibles, le pair et le titre d'authentification du canal, les deux extrémités demandées, la décision d'entrée, le segment choisi, la révision du calcul, l'admission, la relecture des deux brassages, le périmètre de protection, les informations topologiques masquées et le test de livraison.

Le client n'a pas besoin d'une carte du cœur pour contester un résultat. Le fournisseur n'a pas besoin de publier cette carte pour démontrer que la demande du client n'a jamais commandé sa route interne. Tous deux ont besoin d'une interface de preuve définie avant la panne.

Le RFC 5253 ne crée pas un pouvoir collectif indistinct. Il organise une couture entre intention et exécution. La rendre auditable est la condition pour qu'une liaison secrète reste un service explicable.

Sources