Résumé

  • Sur un pare-feu sans fonction NAT, PRR peut réussir tout en renvoyant des tuples vides : aucun binding, aucune pinhole et aucun changement du traitement des paquets n’ont eu lieu.
  • PER apporte une autorité différente en installant une règle locale. Sa réponse ne constate pourtant ni le franchissement des autres équipements ni la réception distante.

L’équipe d’exploitation avait classé les réponses vides comme erreurs partielles. Elle relançait donc les réservations jusqu’à épuiser sa fenêtre de changement. Le pare-feu, lui, se comportait exactement comme le modèle MIDCOM le prévoyait.

RFC 5189 ne décrit pas un protocole concret. Il fixe une sémantique minimale pour qu’un agent puisse agir sur un NAT, un filtre ou un équipement combiné. Cette abstraction n’efface pas les différences entre appareils ; elle oblige au contraire le reçu à déclarer ce que l’appareil pouvait réellement faire.

La réussite ne promet pas toujours une ressource

PRR demande au middlebox de réserver une adresse, une plage de ports, les deux ou rien, selon sa configuration. Sur un NAT traditionnel, la réservation se situe normalement à l’extérieur. Un twice-NAT peut réserver des deux côtés. Un pare-feu pur ne possède aucun tuple de traduction à immobiliser.

Il peut néanmoins accepter la transaction, créer un identifiant de règle, rattacher cette règle à un groupe et lui accorder une durée. Les champs d’adresse restent vides. Le moteur MIDCOM passe à RESERVED, mais le moteur de filtrage ne change pas sa décision sur un paquet.

Deux interprétations faciles seraient donc fausses. « Champ vide » ne signifie pas que la transaction a échoué. « Transaction réussie » ne signifie pas qu’une adresse existe ni que le pare-feu est ouvert. Le reçu complet doit conserver la capacité déclarée du middlebox, le type PRR, les valeurs vides et l’état RESERVED.

Cette précision ressemble à de la comptabilité, mais elle protège l’action suivante. Si une application attend une adresse publique, un résultat vide change son scénario. Si elle voulait seulement faire avancer un workflow commun à plusieurs middleboxes, le même résultat peut être suffisant.

PER change le traitement, pas le reste du monde

PER est la règle d’activation. Sur un NAT, elle établit des bindings. Sur un filtre, elle installe une ou plusieurs autorisations. Sur un équipement combiné, elle compose ces actes. Elle peut réutiliser une réservation ou atteindre directement l’état ENABLED.

Lorsqu’elle remplace PRR, la règle activée peut garder le même identifiant. Une base qui ne versionne pas l’état réécrit alors le passé : l’identifiant apparaît ENABLED aujourd’hui, donc la réservation d’hier semble avoir ouvert le chemin. Il faut enregistrer la transition, pas seulement la clé.

Si PER échoue, la réservation référencée demeure. Ce détail détermine la réparation. Réessayer l’activation, supprimer la réservation ou attendre son expiration sont trois décisions différentes. Effacer PRR dès le premier échec détruirait une ressource encore valide ; l’oublier pourrait immobiliser un tuple jusqu’à la fin de sa durée.

Même PER réussie reste un reçu local. Elle prouve que le middlebox a accepté une opération atomique et établi sa règle. Elle ne voit pas une ACL située plus loin, une route absente, un service arrêté ou un refus applicatif. Pour conclure à la communication, il faut une observation de paquets de chaque côté, puis un reçu de l’extrémité.

Fermer la session ne ferme pas la règle

La session MIDCOM transporte les requêtes et notifications. La règle possède une autre durée de vie. Après une terminaison volontaire, asynchrone ou provoquée par une coupure de connexion, RFC 5189 conserve les règles établies jusqu’à leur expiration ou jusqu’à un autre événement terminal.

Cette indépendance évite qu’une panne du contrôleur supprime immédiatement des flux utiles. Elle produit aussi une dette d’attribution : le canal de contrôle a disparu tandis que la permission demeure. Le registre doit pouvoir relier la règle restante à l’agent authentifié, à la requête initiale, à la durée accordée et aux événements ultérieurs.

La durée demandée n’est qu’une proposition. Le middlebox accorde une valeur plafonnée par sa capacité annoncée. Une modification à zéro termine la règle ; une notification asynchrone peut signaler un changement décidé ailleurs. Afficher l’heure demandée comme heure d’expiration invente une autorité que l’équipement n’a pas donnée.

Propriété, groupes et décisions concurrentes

L’agent authentifié qui crée la règle en devient propriétaire. Cette propriété ne change pas pendant la vie de la règle, même si la politique locale autorise un autre agent à agir pour ce propriétaire. Toutes les règles d’un groupe partagent le même propriétaire.

Le groupe n’est pas un objet éternel. Il naît avec son premier membre et disparaît avec le dernier. Sa durée reflète le maximum des durées restantes, puis une opération GLC peut donner une durée commune à tous les membres ou les supprimer ensemble.

Un seul voyant de groupe masque donc des réalités différentes. Une réservation et une autorisation peuvent mourir lors de la même opération, mais seule la seconde modifiait le passage des paquets. Les inventaires doivent conserver état, fonction et chronologie de chaque membre.

RFC 5189 règle aussi la concurrence : les requêtes sont atomiques entre elles ; un conflit nouveau est rejeté tandis que la règle existante reste ; des chevauchements non conflictuels peuvent être acceptés. Une transaction asynchrone peut néanmoins interrompre le traitement. Une implémentation qui découpe l’opération sémantique doit expliquer comment elle retrouve cette atomicité.

Le reçu exploitable

Il commence par les identités immuables de changement, session, agent et middlebox. Il conserve l’authentification, le propriétaire, les capacités, les interfaces, la transaction, l’identifiant de règle, le groupe et l’état précédent.

Pour PRR, il garde contraintes, protocole, parité, plage, tuples renvoyés et valeurs vides. Pour PER, il garde la référence PRR ou l’activation directe, les extrémités, la direction, les wildcards, bindings et pinholes annoncés. Pour les deux, il sépare durée demandée, maximum et durée accordée.

Les échecs doivent indiquer si la réservation survit. Les lectures de statut et REN, GEN ou STN s’ajoutent dans l’ordre. La fin de session ne doit jamais remplir automatiquement la fin de règle.

Enfin viennent capture avant/après, réception distante et résultat applicatif. En leur absence, la formule honnête est « règle locale établie, résultat inconnu ». C’est moins spectaculaire qu’un voyant vert, mais beaucoup plus utile pour décider.

Sources

  1. RFC 5189 HTML
  2. RFC 5189 texte
  3. Notice RFC 5189
  4. Datatracker RFC 5189
  5. Historique RFC 5189
  6. Références RFC 5189
  7. Errata RFC 5189
  8. RFC 3989
  9. Notice RFC 3989
  10. RFC 3303
  11. Notice RFC 3303
  12. RFC 3304
  13. Notice RFC 3304
  14. RFC 3198
  15. RFC 3234
  16. RFC 3022
  17. RFC 6887
  18. Heng Lu — couches de réalité
  19. Heng Lu — spécification initiale minimale
  20. Heng Lu — primauté du code exécuté