Que devrait réellement consigner un registre d’adresses de sortie VPN ?
Un registre de sorties n’est utile que si chaque entrée indique sa signification, son éditeur et son expiration. La classification n’est pas l’identification de l’abonné.
Les registres de sortie ressemblent à des listes, et la liste n’est pas la partie difficile. La partie difficile consiste à décider ce que chaque entrée affirme, qui peut la publier et ce qui se passe lorsque l’affirmation cesse d’être vraie. Trois rôles d’adresse différents sont confondus dans ces propositions, et un registre qui les mélange ne peut répondre de manière fiable à aucune question. Suivez une entrée de la publication au retrait et les exigences de conception apparaîtront d’elles-mêmes.
Commencez par l’enregistrement, pas par la liste
La première question n’est pas combien d’adresses inclure, mais ce que signifie une seule ligne. Décrit-elle où les clients se connectent, quelle source une destination peut voir, ou qui détient une allocation dans un registre ? Ce sont trois affirmations avec trois propriétaires et trois modes de défaillance. Un registre qui n’indique pas laquelle il enregistre ne peut être validé, corrigé ni expiré. Bien saisir la signification est le travail de conception, et la liste n’en est que le résultat.
Écrivez la définition de la ligne avant d’écrire le moindre schéma. Si la définition a besoin du mot et, ce sont probablement deux enregistrements qui se font passer pour un seul.
Trois rôles d’adresse qui se ressemblent
Les rôles sont faciles à confondre parce qu’un déploiement peut utiliser les trois à la fois, et le fait souvent. Un service peut terminer les connexions à une adresse et transmettre le trafic depuis une autre, tandis qu’un registre consigne un troisième fait entièrement différent.
| Address role | Who may publish | What it does not prove | Withdrawal trigger |
|---|---|---|---|
| Forwarded exit | The operator that forwards the traffic, or a feed it authorizes | That a subscriber is behind the address, or that all its traffic is tunnelled | The address stops forwarding for that operator, or the prefix is reassigned |
| Registered allocation | The registry, or the holder of the allocation | That the resource is used as a VPN exit, or which application uses it | The allocation is returned, transferred, or the holder changes |
| Tunnel entry | The operator that terminates the tunnel | That traffic exits from the same address, or that the client is a subscriber | The endpoint is decommissioned or its address changes |
Un bloc d’hébergement peut contenir des sorties VPN et des charges de travail sans rapport côte à côte, si bien qu’une correspondance dans le registre ne dit rien sur ce que fait une adresse donnée à un moment donné. Une entrée qui ne nomme pas son rôle n’est la preuve de rien de particulier. C’est nommer le rôle qui rend l’enregistrement réfutable. Indiquez aussi la famille d’adresses, car un registre qui ne couvre silencieusement qu’IPv4 induira en erreur quiconque suppose le contraire.
Suivez une entrée de la publication au retrait
Prenez une sortie hypothétique et suivez-la. Un opérateur publie le préfixe et son rôle à un moment d’entrée en vigueur déclaré, les consommateurs le récupèrent, puis l’adresse cesse de servir de sortie. Chaque étape exige une règle : qui peut publier, ce que le préfixe couvre réellement, quand l’entrée prend effet et comment elle est retirée. Un flux sans chemin de retrait accumule des affirmations obsolètes que personne ne peut distinguer des actuelles.
Séparez l’autorité de publier de l’exactitude de l’étiquette. Un enregistrement de registre reliant une organisation à une ressource prouve l’allocation et non l’usage actuel, et ce sont des affirmations différentes avec des preuves différentes. Les consommateurs doivent savoir à laquelle des deux ils se fient.
Définissez aussi la correction. Une adresse réattribuée à un client, ou un service sans rapport pris par une étiquette incorrecte, a besoin d’un chemin documenté vers un correctif plutôt que d’une discussion dans une file de tickets. Le déclencheur de retrait appartient au même document que la règle de publication.
Ce qu’un flux publié peut et ne peut pas prendre en charge
Les attributs de préfixe publiés sont un modèle établi, et les exemples existants décrivent la géographie ou la propriété plutôt que le comportement. Un flux VPN aurait besoin de sa propre sémantique, de ses propres règles de preuve et de son propre processus de révision, et renommer une liste de pays n’en fournit aucun. Le guide du registre ARIN montre ce que les enregistrements d’allocation affirment et n’affirment pas, et un nouveau flux doit gagner la même clarté sur ses propres affirmations. C’est une tâche de spécification, pas une tâche de réétiquetage.
Ce qu’un tel flux peut prendre en charge est une décision de classification concernant une source réseau. Ce qu’il ne peut pas faire, c’est identifier une personne derrière une adresse partagée, prouver que tout le trafic de cette adresse passe par un tunnel, ou décider si une requête particulière est abusive. Ce sont trois questions distinctes avec trois exigences de preuve distinctes.
Gardez la question juridique hors de la spécification
Une spécification technique ne peut pas trancher si une exigence d’enregistrement proposée est légale, proportionnée ou sage. Cette évaluation nécessite le texte législatif réel, les droits concernés, la juridiction et une analyse juridique qu’un format de données ne peut fournir. Un format peut être bien conçu et soutenir malgré tout une mauvaise politique.
Ce que la spécification peut faire, c’est rendre le débat concret. Définissez d’abord les données proposées, leurs limites et leurs modes de défaillance, afin que l’argument politique porte sur un mécanisme réel plutôt que sur une liste indéfinie que chaque participant imagine différemment. C’est le plus qu’un document technique puisse apporter à une question juridique.