L’Afnic contribue à ENE5AI, un projet de recherche de 5G souveraine

Mais ce modèle n’est pas toujours adapté : certaines applications requièrent des latences extrêmement faibles que le cloud ne peut pas apporter ou garantir. Il s’agit de cas d’utilisation comme la télémédecine, la robotique, le pilotage de drones, le « cloud gaming » et ainsi de suite.

De ce besoin émerge un nouveau modèle d’informatique distribuée, qu’on appelle « edge computing ». Le mot « edge » désigne la bordure entre un réseau privé d’une organisation et les autres réseaux qui composent internet ; c’est donc un point stratégique pour y placer des services qui bénéficient à tous les usagers du réseau de l’organisation avec une latence minimale. Grâce à la tendance de la conteneurisation, il est possible de déployer le même service dans de nombreux réseaux en bordure, pour ainsi fournir ce même service avec des temps de réponse très rapides.

De plus, l’émergence des objets connectés ouvre de nombreuses opportunités dans des cas d’usage industriels. Mais leurs contraintes fait qu’il n’est pas toujours possible d’embarquer beaucoup de puissance de calcul ; les calculs intensifs sont alors délégués à des serveurs moins contraints avec lesquels les objets connectés communiquent.

C’est dans ce contexte précis que la 5G a été pensée : un des buts de cette nouvelle norme de téléphonie mobile est de proposer un médium adapté aux nouveaux besoins des nouveaux terminaux. Les terminaux ne sont plus forcément des téléphones, mais peuvent être des objets connectés, tandis que le réseau s’adapte en fonction du besoin : débits très élevés, ou latence très faible.

On peut alors se demander en quoi la 5G peut être bénéfique dans des cas d’usage industriels, et ce que le DNS peut apporter pour rendre possible des applications nouvelles. Pour apporter des réponses à ces questions, un projet a été lancé. Baptisé « Edge Networking pour des Entreprises 5G, Agiles et Intelligentes » (ENE5AI), coordonné par Gandi, ce projet qui a réuni 14 organismes, dont l’Afnic, est un des projets lauréat de l’appel “Solutions souveraines pour les réseaux de télécommunication” dans le cadre de la stratégie nationale d’accélération 5G.

Le projet ENE5AI, pour valider des cas d’utilisation de la 5G

L’objectif du projet ENE5AI était de concevoir une infrastructure numérique souveraine sur une architecture edge et reposant sur la 5G, puis de la tester sur cinq cas d’usage divers : l’industrie dite « industrie 4.0 », les réseaux de transport d’électricité intelligents (aussi appelés smart grids), la sécurité civile avec l’exemple d’une intervention des pompiers sur un grand incendie, le contrôle par une collectivité territoriale de la gestion de l’eau et le pilotage intelligent d’un réseau de centres de données.

Or un réseau aussi complexe et interconnectant autant d’acteurs divers et variés ne peut pas fonctionner adéquatement sans un service de résolution de noms comme le DNS. Les noms de domaine sont une abstraction utile pour que les usagers et les gestionnaires d’un réseau n’aient plus à se soucier de l’emplacement physique d’un service.

En effet, la 4G utilise déjà des noms de domaine pour identifier des services. Un exemple est celui qui donne accès aux appels Wi-Fi : pour cela, un téléphone muni d’un forfait Orange est configuré pour se connecter à une machine identifiée par le nom de domaine epdg.epc.mnc001.mcc208.pub.3gppnetwork.org. Dans ce nom, on y voit l’Evolved Packet Data Gateway (ePDG) appartenant à Orange, identifié ici par le Mobile Country Code (MCC) 208 et le Mobile Network Code (MNC) 01.

De la même manière, l’ensemble des fonctions qui composent un cœur de réseau 5G ont besoin d’un schéma de nommage, plutôt que d’être référencées par des adresses IP : c’est une condition nécessaire pour qu’un cœur de réseau puisse s’adapter et évoluer sans avoir à reconfigurer un parc de millions de terminaux à chaque changement. Le DNS est donc plus que jamais pertinent dans le fonctionnement d’un réseau 5G.

Bien entendu, il ne s’agit pas du DNS tel qu’il était spécifié en 1983 : la spécification originelle du protocole n’intégrait pas de considérations de sécurité. Un résolveur DNS moderne dans l’/edge/ doit donc impérativement offrir les garanties de sécurité qui ont été ajoutées plus tard au DNS et qui font maintenant partie de l’état de l’art : l’intégrité, avec DNSSEC, ainsi que la confidentialité des échanges entre client et résolveur, avec un transport chiffré.

Parmi ces transports chiffrés, les principales alternatives sont DoT (DNS sur TLS), DoH (DNS sur HTTPS) ou DoQ (DNS sur QUIC). Parmi ces trois options se cache en fait un quatrième qui concilie à la fois les avantages de HTTPS et QUIC, qui est DoH3, ou DNS sur HTTP/3.

DNS sur HTTP/3 serait-il le transport le plus adapté aux réseaux 5G ? Je pense que oui, pour les raisons suivantes.

Tout d’abord, HTTP/3 repose sur le protocole QUIC et non pas TCP. Avec QUIC, l’établissement d’une connexion se fait en quatre paquets et incorpore un handshake TLS 1.3, ce qui fait d’une pierre deux coups comparé à TLS ou aux versions plus anciennes de HTTPS. Plusieurs études, comme Kosek et al., 2023 ou Sengupta et al., 2023, montrent que DoQ est le DNS chiffré le plus efficient et rapide comparé à DoH (spécifié à l’époque où la version la plus récente de HTTP était HTTP/2), donc DoH3 a le potentiel d’être aussi performant que DoQ.

Enfin, le protocole HTTP est déjà omniprésent dans les cœurs de réseau 5G, car les fonctions qui en constituent le plan de contrôle communiquent entre eux au moyen d’API REST standardisées. Puisque la norme 5G n’impose aucune version de HTTP, il serait intéressant d’y généraliser le HTTP/3. Le choix de HTTP/3 comme transport du DNS s’inscrirait alors parfaitement dans cette continuité.

La contribution de l’Afnic : un résolveur DoH3 utilisable dans l’edge

L’Afnic a contribué au projet ENE5AI par la conception d’un environnement de résolution de noms s’appuyant sur le DNS et qui serait adapté aux réseaux edge et à la 5G.

Afnic Labs avait déjà expérimenté par le passé avec un résolveur public DoH et DoT, mais qui ne prenait en charge que HTTP/2. Pour passer de HTTP/2 à HTTP/3, il a été nécessaire d’en adapter l’architecture.

Le résolveur a également été conçu être facile à déployer dans des environnements conteneurisés. La taille des images de conteneur a été réduite au plus strict nécessaire, aussi bien pour réduire la surface d’attaque que pour réduire le stockage nécessaire pour le déployer. Ainsi, il est possible de déployer ce résolveur en de nombreux exemplaires au plus près des utilisateurs finaux.

La solution retenue repose sur plusieurs composants qui permet d’intégrer à la fois un service de résolution et son accessibilité via HTTP/3.

Conclusion

Le DNS sur HTTP/3 est un développement prometteur qui promet la confidentialité des requêtes DNS faites par les usagers de réseaux fixes ou mobiles, tandis que le surcoût de l’établissement d’une session chiffré entre terminal et résolveur reste maîtrisé.

Un résolveur prenant en charge DoH3 et déployable au plus près des usagers est un élément indispensable d’une architecture réseau moderne. Pendant ce temps, on nous promet déjà la 6G et les nouvelles possibilités qu’elle offre, comme les réseaux véhiculaires. À quoi ressemblerait un service de résolution de noms dans un tel réseau ?