Brevet FR3114723A1 — publié le 20220401

Procédés de configuration d’un équipement utilisateur, de négociation avec une entité du réseau, et de gestion d’une connexion, et dispositifs associés. L’invention concerne un procédé de configuration d’un équipement utilisateur (UE1), destiné à être mis en œuvre par cet équipement utilisateur, et comprenant une étape de désactivation, pour au moins une communication chiffrée de cet équipement utilisateur avec un dispositif distant (S1) via un réseau (CN), d’au moins une procédure de chiffrement sélectionnée par l’équipement utilisateur et mise en œuvre avec une première entité (FF) du réseau impliquée dans un acheminement de données échangées entre l’équipement utilisateur et le dispositif distant lors de la communication chiffrée, ces données faisant l’objet d’au moins une autre procédure de chiffrement distincte de ladite au moins une procédure de chiffrement désactivée. Fig. 2 Procédés de configuration d’un équipement utilisateur, de négociation avec une entité du réseau, et de gestion d’une connexion, et dispositifs associés. L’invention se rapporte au domaine général des télécommunications. Elle concerne plus particulièrement la gestion de communications chiffrées dans un réseau de télécommunications. L’invention a une application privilégiée notamment dans le cadre d’un réseau de télécommunications 5G tel que défini par le standard 3GPP (Third Generation Partnership Project). Toutefois, elle peut également s’appliquer dans le cadre d’un autre réseau tel qu’un réseau 4G, un réseau propriétaire, etc. Les équipements utilisateurs des réseaux de télécommunications, et notamment les terminaux tels que les téléphones intelligents (ou « smartphones » en anglais) ou les ordinateurs personnels (ou PC pour « Personal Computers » en anglais), sont désormais capables d’activer et d’exploiter plusieurs interfaces logiques liées à une ou plusieurs interfaces physiques, leur permettant de se connecter simultanément ou non à différents types de réseau (par exemple, réseau fixe, réseau mobile, réseau local sans fil) via différentes adresses IP (pour « Internet Protocol » en anglais). De tels équipements utilisateurs sont dits « multi-interfaces » (ou MIF pour « Multi-InterFace » en anglais). On note que la caractéristique MIF d’un équipement utilisateur est volatile car sa capacité à utiliser plusieurs interfaces dépend des conditions de raccordement au(x) réseau(x), de sa localisation, ou d’autres facteurs encore. Un équipement utilisateur MIF peut notamment exploiter tout ou partie des interfaces dont il dispose durant l’établissement d’une connexion simple avec un correspondant (c’est-à-dire établie le long d’un chemin unique avec ce correspondant), voire après l’établissement d’une connexion simple. Par ailleurs, on note également qu’un équipement utilisateur MIF ne sait pas a priori s’il lui est possible d’utiliser plusieurs chemins distincts pour établir une communication avec un correspondant donné : l’équipement utilisateur n’acquiert cette information le cas échéant qu’à l’issue d’une phase au cours de laquelle il tente d’établir une communication avec le correspondant en utilisant des chemins multiples. Lorsqu’un équipement utilisateur dispose de plusieurs interfaces capables de le raccorder à différents réseaux d’accès (par exemple fixe, mobile, WLAN pour « Wireless Local Area Network ») pour se connecter à un cœur de réseau, il bénéficie alors d’un accès dit « hybride », combinant différentes technologies de réseaux d’accès. Les offres de services concernant un équipement utilisateur disposant d’un accès hybride reposent sur l’introduction dans le cœur de réseau de fonctions permettant d’agréger l’ensemble des connexions réseau d’un équipement utilisateur (par exemple : WLAN et 4G, ou ADSL, WLAN et 5G). A noter que l’agrégation de liens consiste à regrouper plusieurs liens associés à plusieurs interfaces logiques comme s'il s'agissait d'un seul lien associé à une seule interface, notamment dans le but d'accroître le débit au-delà des limites d'un seul lien, d’appliquer les mêmes procédures d’exploitation à l’ensemble des liens ainsi agrégés, de répartir le trafic entre plusieurs liens, ou encore de faire en sorte que d’autres interfaces (et donc, d’autres réseaux d’accès) prennent le relais si l’un de ces liens tombe en panne (principe de redondance). L’agrégation de liens s’applique à tout type de trafic acheminé le long de ces liens, y compris au trafic IP. Le protocole MPTCP (pour « Multi-Path Transmission Control Protocol » en anglais) a été initialement proposé pour répondre aux exigences posées par un contexte où un équipement utilisateur a la capacité de se raccorder à un réseau via plusieurs interfaces pour établir une communication reposant sur le protocole TCP. Le protocole MPTCP répond notamment aux besoins d’assurer une continuité de session de façon transparente pour l’utilisateur en cas de mobilité de l’équipement de l’utilisateur. Pour rappel, les connexions TCP d’un équipement utilisateur sont identifiées par une adresse IP et un numéro de port, de sorte que toute modification de ces informations d’identification est de nature à pénaliser le fonctionnement d’une connexion TCP en cours, et, partant, le service utilisant ladite connexion TCP. Un tel changement d’adresse IP ou de numéro de port est particulièrement préjudiciable lorsque l’équipement utilisateur se voit attribuer une nouvelle adresse IP, ou parce que l’équipement utilisateur est connecté à un autre réseau, ou encore lorsque l'interface à laquelle l'adresse IP est associée n'est plus disponible. Des moyens pour informer le correspondant TCP distant qu’une adresse IP n’est plus valide sont alors nécessaires pour assurer le maintien d’une connexion existante (par exemple, dans le cas de connexions TCP de longue durée). Le protocole MPTCP a été proposé pour notamment minimiser les risques de rupture intempestive des connexions TCP liés à de telles modifications de l’adressage IP. Cependant, le protocole MPTCP ne constitue qu’une solution partielle à la problématique générale d’agrégation de liens car par définition, il ne permet pas d’établir des connexions utilisant un autre protocole de transport que TCP sur des chemins multiples, tel que par exemple le protocole de transport UDP (pour « User Datagram Protocol » en anglais) ou d’autres protocoles de transport. Or, plusieurs protocoles de transport ont été proposés, standardisés et implémentés par la communauté Internet pour satisfaire les besoins des applications. Par exemple, certaines applications nécessitent plus de fonctions transport que celles offertes par les protocoles TCP et UDP, alors que d’autres considèrent que les fonctions transport offertes par TCP ou UDP ne sont pas (toutes) nécessaires compte tenu de leur besoins. Les fonctions transport sont définies comme étant la liste des services offerts par un protocole utilisé pour multiplexer des connexions au niveau de la couche transport. Cette liste contient, par exemple, la transmission ordonnée des données, la transmission fiable des données, le contrôle de congestion, ou le contrôle d’intégrité. C’est ainsi que : le protocole SCTP (pour « Stream Control Transmission Protocol » en anglais) a été spécifié pour satisfaire les besoins des applications qui nécessitent plus de fonctions transport que celles supportées par TCP comme, typiquement, la préservation de la structure des données telle que générée par l’application ou le support des communications via des chemins multiples ; le protocole DCCP (pour « Datagram Congestion Control Protocol » en anglais) est un autre protocole de transport qui a été spécifié pour des applications qui requièrent plus de fonctions transport que celles supportées par UDP (telles que par exemple le support du contrôle de congestion) mais sans forcément hériter des contraintes d’un protocole orienté connexion comme TCP (telles que par exemple assurer une transmission fiable) ; le protocole UDP-lite est une version simple du protocole UDP qui a été proposée pour des applications qui ne nécessitent pas toutes les fonctions offertes par UDP (telles que par exemple le contrôle d’intégrité), alors que les protocoles TLS (pour « Transport Layer Security » en anglais) et DTLS (pour « Datagram TLS » en anglais) ont été standardisés pour les besoins de chiffrement des applications au niveau de la couche transport ; le protocole QUIC est un protocole qui repose sur le protocole de transport UDP et qui a pour ambition de réduire les temps de latence généralement observés lors de l’établissement de connexions TCP tout en évitant les problèmes de blocage (ou « Head-of-line blocking », en anglais); etc. Etant donné que TCP et UDP sont les deux protocoles de transport majoritairement utilisés par les applications pour communiquer sur Internet, l’agrégation de liens devrait faire partie des fonctions supportées par UDP, en écho à ce que supporte TCP. C’est ainsi que le standard 3GPP a édité, pour les réseaux 5G, le rapport TR 23.793 intitulé « 3GPP; Technical Specification Group Services and System Aspects; Study on access traffic steering, switch and splitting support in the 5G system architecture », Release 16, v16.0.0, décembre 2018 dont l’objectif a été d’étudier comment un réseau 5G (ou système 5GS pour « 5G System » en anglais) peut être modifié pour supporter les fonctions d’agrégation de liens, appelées ATSSS dans le rapport 3GPP (pour « Access Traffic Steering, Switching and Splitting » en anglais), entre des réseaux d’accès 3GPP et d’autres réseaux d’accès non-3GPP. L’ensemble des fonctions ATSSS déployées dans un cœur de réseau 5G (ou plus simplement dans la suite « réseau 5G ») doivent pouvoir être utilisées pour acheminer le trafic TCP et le trafic UDP (y compris le trafic QUIC). Une solution spécifique au protocole TCP a ainsi été introduite dans le document 3GPP TS 23.501 intitulé « 3GPP; Technical Specification Group Services and System Aspects; System architecture for the 5G System (5GS); Stage 2 », Release 16, v16.5.1, août 2020. Cette solution s’appuie sur les protocoles MPTCP et Convert Protocol (décrit dans le document RFC 8803 édité par l’IETF). Le 3GPP étudie des solutions pour offrir les fonctions ATSSS au trafic non-TCP, comme par exemple au trafic transporté par le protocole QUIC qui représente en 2020 une part importante du trafic s’appuyant sur le protocole UDP. De façon connue, QUIC chiffre non seulement les données utiles mais également les informations de contrôle d’une connexion ; les informations QUIC envoyées en clair sont limitées au strict minimum, et comprennent par exemple l’identifiant de connexion. Il en résulte que les solutions connues s’appuyant sur le protocole MPTCP et sur l’assistance du réseau ne sont pas réutilisables pour le protocole QUIC, puisque le trafic QUIC ne peut pas être intercepté par le réseau en raison de son chiffrement. Par ailleurs, le protocole QUIC n’utilise qu’un seul chemin à la fois pour envoyer les paquets de données relatifs à une même connexion, ce qui ne répond pas aux besoins des fonctions ATSSS définies par le standard 3GPP. Les options en cours d’étude par le 3GPP pour offrir des fonctions ATSSS en conjonction avec le protocole QUIC sont exposées brièvement dans le document de M. Boucadair et al. intitulé « 3GPP Access Traffic Steering Switching and Splitting (ATSSS) – Overview for IETF Participants », 30 mai 2020 (ci-après document D1). Dans ce document D1, on considère une architecture de référence selon laquelle un équipement utilisateur est attaché à deux réseaux d’accès différents (dont au moins un réseau 3GPP d’un opérateur d’un réseau cœur 5G, l’autre réseau pouvant être géré par une entité administrative distincte), et interagit avec un serveur distant. Cette interaction se fait via une fonction ATSSS UPF (pour « User Plane Function » en anglais), localisée dans le réseau 5G de l’opérateur et chargée d’associer les données reçues de l’équipement utilisateur via les différents réseaux d’accès (autrement dit, via différents chemins) et de les relayer vers le serveur distant. Le document D1 décrit trois options utilisant le protocole QUIC comme mécanisme d’encapsulation entre l’équipement utilisateur et la fonction ATSSS UPF localisée dans le réseau de l’opérateur, pour tout type de trafic (TCP, UDP, IP, QUIC, etc.). Selon ces options, les connexions QUIC établies entre l’équipement utilisateur et la fonction ATSSS UPF sont soit des connexions simples (c’est-à-dire que chacune de ces connexions est établie selon la procédure QUIC de base décrite dans le document de J. Iyendar et al. intitulé « QUIC: A UDP-based Multiplexed and Secure Transport », draft-ietf-quic-transport, mai 2020), soit des connexions établies selon une nouvelle extension au protocole QUIC définie pour supporter les connexions QUIC via des chemins multiples. Lorsque des connexions QUIC simples sont utilisées, une fonction applicative associant les différentes connexions entre elles est alors nécessaire. Les trois options discutées actuellement par le 3GPP souffrent toutefois des inconvénients suivants. L’utilisation du protocole QUIC comme mécanisme d’encapsulation entre l’équipement utilisateur et la fonction ATSSS UPF induit un surplus (ou encore « overhead » en anglais) par rapport aux différents mécanismes d’encapsulation déjà présents dans les réseaux 3GPP. La figure 1 illustre les piles protocolaires requises (et les schémas d’encapsulation en résultant) au niveau de chaque entité de l’architecture de référence précitée (équipement utilisateur UE, entités N3IWF (pour « Non-3GPP InterWorking Function » en anglais) et UPF du réseau 5G de l’opérateur, station de base gNB et serveur distant) pour la mise en œuvre de la fonction ATSSS UPF, en fonction du réseau d’accès utilisé par l’équipement utilisateur UE pour se connecter au réseau 5G (réseau d’accès 3GPP (ou « 5G-AN » pour 5G Access Network en anglais) ou réseau d’accès non-3GPP, tel qu’un réseau WLAN par exemple). A titre d’exemple, si la connexion QUIC entre l’équipement utilisateur UE et la fonction UPF est établie via un réseau d’accès non-3GPP WLAN, un overhead de 142 octets est observé au minimum pour des paquets IPv6 envoyés par un équipement utilisateur. Un tel overhead peut provoquer l’émission de messages ICMP (« Internet Control Message Protocol » en anglais) PTB (pour « Packet Too Big » en anglais) ou la fragmentation des paquets transmis si, par exemple, l’unité de transmission maximum ou MTU (pour « Maximum Transmission Unit » en anglais) définie pour le chemin emprunté n’a pas été modifiée pour tenir compte de l’overhead induit par les différentes encapsulations et éviter la fragmentation des paquets de nature à pénaliser l’intégrité de la communication. Outre l’overhead, le recours à un mécanisme d’encapsulation QUIC induit la mise en œuvre d’un nouveau schéma de chiffrement, qui vient s’ajouter aux schémas de chiffrement déjà existants et mis en œuvre par les autres couches (par exemple au niveau applicatif, au niveau transport, au niveau couche physique). Ces multiples chiffrements peuvent impacter les performances des communications, notamment celles de l’équipement utilisateur, en raison des temps de traitement et des calculs mis en œuvre. Ainsi, typiquement, les paquets QUIC envoyés via un réseau d’accès 3GPP subissent deux chiffrements en plus du chiffrement effectué au niveau radio, à savoir, le chiffrement requis entre l’équipement utilisateur et le serveur distant et le chiffrement requis par la connexion QUIC entre l’équipement utilisateur et la fonction ATSSS UPF. Les paquets QUIC envoyés via un réseau d’accès non-3GPP subissent quant à eux un troisième chiffrement supplémentaire requis entre l’équipement utilisateur et la fonction N3IWF, qui est responsable du relais des messages reçus depuis un réseau d’accès non-3GPP vers le cœur de réseau 5G. L’invention propose un mécanisme qui permet avantageusement, selon le mode de réalisation envisagé, de remédier à tout ou partie des inconvénients de l’état de la technique précédemment soulignés dans le contexte d’un réseau de télécommunications 5G et d’une fonction transport ATSSS UPF localisée dans le réseau qui permet de gérer les multiples chemins de communication dont peut bénéficier un équipement utilisateur MIF pour communiquer avec un dispositif distant, quel que soit le protocole de transport utilisé (et notamment, pas seulement TCP). On note toutefois que bien que le problème technique ait été décrit dans ce contexte particulier en référence au protocole QUIC, l’invention est applicable dans d’autres contextes, et notamment à d’autres réseaux qu’un réseau 5G (par exemple à un réseau 4G), à d’autres fonctions qu’une fonction ATSSS (par exemple une fonction d’accélération TCP/HTTP), ainsi qu’à d’autres protocoles que le protocole QUIC (par exemple, aux protocoles sécurisés TLS, DTLS, IPsec (pour « Internet Protocol security » en anglais)). Plus particulièrement, l’invention propose, selon un premier aspect, un procédé de configuration d’un équipement utilisateur, destiné à être mis en œuvre par cet équipement utilisateur, et comprenant une étape de désactivation, pour au moins une communication chiffrée de l’équipement utilisateur avec un dispositif distant via un réseau, d’au moins une procédure de chiffrement sélectionnée par l’équipement utilisateur et mise en œuvre avec une première entité du réseau impliquée dans un acheminement de données échangées entre l’équipement utilisateur et le dispositif distant lors de la communication chiffrée, ces données faisant l’objet d’au moins une autre procédure de chiffrement distincte de ladite au moins une procédure de chiffrement désactivée. Corrélativement, l’invention vise aussi un équipement utilisateur d’un réseau de télécommunications comprenant un module de désactivation, configuré pour désactiver, pour au moins une communication chiffrée de l’équipement utilisateur avec un dispositif distant via le réseau, d’au moins une procédure de chiffrement sélectionnée par cet équipement utilisateur et mise en œuvre avec une première entité du réseau impliquée dans un acheminement de données échangées entre l’équipement utilisateur et le dispositif distant lors de la communication chiffrée, ces données faisant l’objet d’au moins une autre procédure de chiffrement distincte de ladite au moins une procédure de chiffrement désactivée. On note que l’expression « procédure de chiffrement » est utilisée ici pour désigner aussi bien des opérations de chiffrement que de déchiffrement mises en œuvre entre l’équipement utilisateur et la première entité. La désactivation d’une procédure de chiffrement au niveau de l’équipement utilisateur se traduit de façon évidente par une désactivation de la procédure de déchiffrement correspondante au niveau de la première entité, et inversement dans le cas de communications bidirectionnelles entre l’équipement utilisateur et la première entité. Aucune limitation n’est attachée à la nature de l’équipement utilisateur (ou UE pour « User Equipment » en anglais) considéré, ni à celle du dispositif distant. L’équipement utilisateur peut être un terminal, fixe ou mobile, tel que par exemple un ordinateur personnel ou un « smartphone », susceptible de se connecter au réseau via un ou plusieurs réseaux d’accès ou encore d’un équipement de type CPE (pour « Customer Premises Equipment » en anglais) raccordé au réseau via au moins un réseau d’accès, etc. Le dispositif distant peut désigner tout point de terminaison de la communication avec l’équipement utilisateur, comme par exemple un serveur, hébergé par le réseau ou par un autre réseau, ou un autre équipement utilisateur, etc. Aucune hypothèse n’est faite sur la structure de cet équipement distant qui peut être indifféremment matérielle ou logicielle. Ainsi l’invention offre la possibilité à un équipement utilisateur de décider de sa propre initiative s’il convient de désactiver lors de ses communications avec des dispositifs distants via le réseau, une ou plusieurs procédures de chiffrement mises en œuvre lors de l’acheminement des données échangées avec ces dispositifs distants. Cette désactivation est possible sous réserve qu’au moins une procédure de chiffrement alternative existe pour protéger les données échangées avec le dispositif distant, cette procédure pouvant être appliquée à n’importe quel niveau des couches du modèle OSI (pour « Open Systems Interconnection » en anglais) (couche physique, transport, application, etc.). Par exemple, cette procédure de chiffrement alternative peut être : - une procédure de chiffrement mise en œuvre avec une autre entité du réseau impliquée dans l’acheminement des données ; et/ou - une procédure de chiffrement mise en œuvre sur un réseau utilisé par l’équipement utilisateur pour échanger lesdites données avec le dispositif distant, comme par exemple sur un réseau d’accès ; et/ou - une procédure de chiffrement mise en œuvre avec le dispositif distant pour échanger lesdites données. L’équipement utilisateur peut de la sorte désactiver tout ou partie des procédures de chiffrement redondantes mises en œuvre dans le réseau, tout en préservant la sécurité de ses communications, celle du cœur de réseau (ou réseau cœur), mais également du dispositif distant. Cette désactivation permet d’économiser les ressources de l’équipement utilisateur (pour les traitements nécessaires aux chiffrement/déchiffrement des données). Il en résulte une optimisation des performances globales de l’équipement utilisateur et des communications (via notamment l’optimisation de la charge des équipements intermédiaires). Conformément à l’invention, c’est l’équipement utilisateur qui sélectionne les procédures de chiffrement à désactiver. Cette sélection peut se faire en fonction de diverses informations, pouvant notamment provenir du réseau (transmises par exemple à l’équipement utilisateur sous forme de règles ou sous toute autre forme), et en particulier des entités impliquées dans l’acheminement des données elles-mêmes (désignées parfois dans la suite par « entités ou fonctions transport ») ou des entités aptes à contrôler et à configurer ces entités (désignées parfois dans la suite par « entités ou fonctions de contrôle »). Toutefois, seul l’équipement utilisateur dispose d’une vue suffisamment globale concernant le nombre et la nature des fonctions transport qui vont être sollicitées lors d’une communication (par exemple l’agrégation de liens), et donc concernant les procédures de chiffrement et les encapsulations en résultant, le réseau ne disposant pas de cette connaissance a priori . Grâce à cette connaissance, l’équipement utilisateur est en mesure d’identifier les procédures de chiffrement mais également d’encapsulation qui sont redondantes lors d’une communication, et de désactiver le cas échéant tout ou partie de ces procédures. L’invention permet donc avantageusement d’optimiser les procédures d’encapsulation typiquement mises en œuvre dans un réseau 3GPP et qui conduisent à l’établissement de tunnels. Dans la suite de la description, l’établissement de tunnels fait explicitement référence à de telles procédures d’encapsulation. Ainsi, dans un mode particulier de réalisation, l’étape de désactivation peut comprendre également une désactivation d’une procédure d’établissement d’un tunnel avec la première entité. Cette désactivation de l’établissement d’un tunnel avec la première entité peut être décidée par l’équipement utilisateur dès lors que l’acheminement des données implique cette première entité (notion d’’ingénierie ou de pilotage de trafic (ou « traffic steering », en anglais)). Ce peut être le cas notamment lorsqu’un tunnel chargé d’acheminer les données pour qu’elles transitent par cette première entité existe déjà, ou lorsque l’acheminement des données via la première entité est assuré par des options de routage à la source, où la source émettrice des données à la capacité d’indiquer explicitement le ou les entités par lesquelles les données doivent transiter (par exemple « Segment Routing »). La désactivation d’une ou de plusieurs procédures d’encapsulation conduisant à l’établissement d’un tunnel permet en outre de réduire l’overhead induit par l’encapsulation des données qui empruntent ces tunnels ainsi que le temps requis pour établir ces tunnels. Aussi, ce mode de réalisation contribue à l’optimisation des performances globales de l’équipement utilisateur et des communications (par exemple en évitant la fragmentation des paquets). On note que, dans un autre mode de réalisation, la désactivation d’une procédure d’établissement d’un tunnel peut être décidée par l’équipement utilisateur avec une entité distincte de la première entité avec laquelle il a décidé de désactiver une procédure de chiffrement. Autrement dit, de la même manière que la désactivation de procédure(s) de chiffrement et la désactivation de procédure(s) d’établissement de tunnels ne sont pas mutuellement exclusives, elles peuvent également être décidées par l’équipement utilisateur de manière indépendante et sur des connexions distinctes. L’invention permet de façon générale à l’équipement utilisateur de contrôler le niveau de sécurité qu’il souhaite associer à une communication chiffrée avec un dispositif distant. Par exemple, en fonction de la réputation du réseau d’accès qu’il souhaite utiliser lors de cette communication chiffrée, il peut décider ou non de désactiver une ou plusieurs procédures de chiffrement redondantes lors de cette communication chiffrée. Bien que l’invention s’applique à tout type de fonction transport impliquée dans l’acheminement des données entre un équipement utilisateur et un dispositif distant, elle a une application privilégiée dans le contexte précédemment introduit des fonctions gérant l’agrégation de liens, telles que par exemple la fonction ATSSS UPF définie par le standard 3GPP, et de l’utilisation de protocoles sécurisés basés sur d’autres protocoles que le protocole TCP (par exemple UDP ou QUIC). Appliquée dans ce contexte, l’invention permet en effet d’envisager une parité fonctionnelle entre les protocoles TCP et UDP pour la gestion des communications établies sur des chemins multiples. Typiquement, la désactivation de certaines procédures de chiffrement et/ou d’encapsulation mises en œuvre par les solutions documentées dans le standard 3GPP et reposant sur l’encapsulation des paquets de données avec le protocole QUIC, offre la possibilité d’établir des communications utilisant des chemins multiples de façon comparable à ce qui est mis en œuvre pour TCP, avec l’assistance du réseau, et sans ajouter de délai supplémentaire en raison de multiples chiffrements et encapsulations QUIC requis par ces solutions. Il est ainsi possible de bénéficier des avantages de l’agrégation de liens tout en optimisant l’ingénierie et l’utilisation des tunnels, et plus généralement de rendre un service similaire au trafic TCP pour le trafic non-TCP quel qu’il soit (UDP, QUIC, etc.), d’où cette parité fonctionnelle. Dans un mode particulier de réalisation, l’étape de désactivation de ladite au moins une procédure de chiffrement et/ou d’établissement d’un tunnel est conditionnée par la réception d’une autorisation préalable provenant d’une deuxième entité du réseau, et demandée par l’équipement utilisateur. Corrélativement, dans ce mode de réalisation, le module de désactivation est configuré pour désactiver ladite au moins une procédure de chiffrement suite à une autorisation préalable reçue provenant d’une deuxième entité du réseau et demandée par l’équipement utilisateur. La deuxième entité du réseau sollicitée par l’équipement utilisateur peut être par exemple la première entité avec laquelle l’équipement utilisateur souhaite désactiver la procédure de chiffrement et/ou la procédure d’établissement d’un tunnel, ou une entité de contrôle du réseau apte à configurer la première entité pour désactiver cette procédure de chiffrement et/ou cette procédure d’établissement d’un tunnel, ou encore une autre entité de contrôle du réseau apte à relayer la demande d’autorisation de l’équipement utilisateur vers cette entité de contrôle. Ainsi, dans ce mode de réalisation, la désactivation de la procédure de chiffrement et/ou de la procédure d’établissement d’un tunnel fait suite à une négociation préalable avec le réseau, à l’initiative de l’équipement utilisateur. La sollicitation de l’équipement utilisateur pour obtenir l’autorisation du réseau peut avoir lieu à divers moments, par exemple lors de l’attachement de l’équipement utilisateur au réseau, de l’activation d’une session réseau, à intervalle régulier, sur activation explicite de l’utilisateur ou d’une application via une interface ou API (pour « Application Programming Interface ») dédiée, etc. L’autorisation peut être explicite ou implicite, viser une procédure de chiffrement et/ou une procédure d’établissement d’un tunnel en particulier ou au contraire consister en des règles plus générales fournies par le réseau concernant les procédures de chiffrement et/ou d’établissement d’un tunnel qui peuvent être désactivées par l’équipement utilisateur avec des fonctions transport du réseau lors de ses communications. Ce mode de réalisation permet à l’opérateur réseau de garder le contrôle sur les procédures qui peuvent être désactivées, afin notamment de maintenir la sécurité de son réseau et/ou de satisfaire certaines politiques opérateur. En outre, cela permet une coordination des équipements utilisateurs avec le réseau. Dans le contexte des communications utilisant des chemins multiples, l’opérateur peut ainsi contrôler la gestion de ces communications, et préserver la sécurité du réseau en évitant que le service ATSSS ne soit utilisé par des équipements utilisateurs non autorisés. En outre, la coordination avec le réseau simplifie l’utilisation des clients QUIC. Dans un mode particulier de réalisation, le procédé de configuration comprend, préalablement à l’étape de désactivation, une étape de réception, en provenance de la deuxième entité du réseau, d’au moins une information dite de contexte de désactivation (de procédure(s) de chiffrement et/ou de procédure(s) d’établissement de tunnel(s)) fournissant au moins une indication sur au moins une procédure de chiffrement et/ou sur au moins une procédure d’établissement d’un tunnel pouvant être désactivée(s) par l’équipement utilisateur. Par exemple, ladite au moins une information de contexte de désactivation peut comprendre au moins une indication : - d’au moins une entité du réseau avec laquelle une procédure de chiffrement et/ou une procédure d’établissement d’un tunnel peut être désactivée(s) (par exemple une fonction ATSSS UPF) ; et/ou - d’au moins un type de connexion au cours de laquelle une telle procédure peut être désactivée (par exemple une connexion QUIC utilisée pour établir un tunnel sécurisé ou un tunnel IPsec établi avec le dispositif distant) ; et/ou - d’au moins un réseau d’accès audit réseau pour lequel une telle procédure peut être désactivée (par exemple un réseau d’accès 3GPP). En variante ou en complément, le réseau peut également fournir à l’équipement utilisateur des indications concernant les procédures de chiffrement et/ou d’établissement d’un tunnel qui ne peuvent pas être désactivées. Aucune limitation n’est attachée à la forme des informations de contexte de désactivation fournies par la deuxième entité du réseau à l’équipement utilisateur. Ces informations peuvent par exemple être intégrées dans des règles (telles que les règles ATSSS définies dans le standard 3GPP), chaque règle pouvant spécifier plusieurs éléments auxquels la règle s’applique comme notamment la nature de l’interface de réseau d’accès (par exemple 3GPP ou non-3GPP), l’identifiant de l’application, la première entité réseau (par exemple entité ATSSS UPF), la possibilité ou non de désactiver la procédure de chiffrement et/ou la procédure d’établissement d’un tunnel mise en œuvre avec cette première entité réseau, etc. Bien entendu, cet exemple n’est donné qu’à titre illustratif et d’autres informations de contexte de désactivation, présentées sous d’autres formes, peuvent être envisagées. Ainsi, par exemple, les informations de contexte de désactivation peuvent comprendre une clé de sécurité destinée à être présentée par l’équipement utilisateur à la première entité du réseau avec laquelle la procédure de chiffrement et/ou la procédure d’établissement d’un tunnel est désactivée. Une telle clé de sécurité permet à la première entité de réaliser des vérifications de sécurité avec l’équipement utilisateur et en particulier de s’assurer que celui-ci est bien autorisé par le réseau à désactiver la ou les procédures en question. Dans un mode particulier de réalisation, la clé de vérification n’est présentée que lors de l’établissement d’une connexion avec ou via la première entité. Dans un mode particulier de réalisation, ladite au moins une procédure de chiffrement et/ou procédure d’établissement d’un tunnel sélectionnée(s) par l’équipement utilisateur est (sont) sélectionnée(s) en fonction de ladite au moins une information de contexte de désactivation reçue de la deuxième entité. Comme mentionné précédemment, cela permet de s’assurer que la sélection opérée par l’équipement utilisateur est coordonnée avec le réseau et reste sous son contrôle. Dans les modes de réalisation qui viennent d’être évoqués, la désactivation de la procédure de chiffrement et/ou de la procédure d’établissement d’un tunnel sélectionnée(s) par l’équipement utilisateur fait suite à une négociation préalable avec le réseau. En variante, on peut envisager que l’équipement utilisateur désactive par défaut une procédure de chiffrement et/ou une procédure d’établissement d’un tunnel pour communiquer avec le dispositif distant via la première entité, et en fonction de la réponse de la première entité, adapte si besoin ce mode de fonctionnement en rétablissant la procédure de chiffrement et/ou la procédure d’établissement d’un tunnel désactivée(s) par défaut. Plus particulièrement, conformément à cette variante, on peut envisager par exemple que le procédé de configuration comprenne, suite à l’étape de désactivation : - une étape de demande d’établissement d’une première connexion avec ou via la première entité dans laquelle la procédure de chiffrement et/ou la procédure d’établissement d’un tunnel est (sont) désactivée(s) ; et - en cas de rejet de ladite première connexion par la première entité, une étape de demande d’établissement d’une deuxième connexion avec ou via la première entité dans laquelle la procédure de chiffrement et/ou la procédure d’établissement d’un tunnel est (sont) activée(s) entre l’équipement utilisateur et la première entité. Corrélativement, dans ce mode de réalisation, ledit équipement utilisateur comprend en outre un module de communication configuré pour : - demander un établissement d’une première connexion avec ou via la première entité dans laquelle ladite procédure de chiffrement et/ou la procédure d’établissement d’un tunnel est (sont) désactivée(s) ; et - en cas de rejet de ladite première connexion par la première entité, demander un établissement d’une deuxième connexion avec ou via la première entité dans laquelle ladite procédure de chiffrement et/ou la procédure d’établissement d’un tunnel est (sont) activée(s) entre l’équipement utilisateur et la première entité. Aucune limitation n’est attachée à la forme que peut prendre le rejet de la première connexion par la première entité. Il peut s’agir par exemple d’un message d’erreur, d’un message de refus, etc. Si la première connexion est acceptée par la première entité, alors l’équipement utilisateur continue d’utiliser cette première connexion pour transmettre ses données via la première entité au dispositif distant, autrement dit, la connexion non chiffrée (réalisée éventuellement via un tunnel non chiffré) et qu’il a établie avec ou via la première entité. On note que la négociation préalable avec le réseau et la désactivation par défaut ne sont pas mutuellement exclusives : l’équipement utilisateur peut, pour certaines fonctions transport, mettre en place une négociation avec le réseau alors qu’avec d’autres, désactiver par défaut les procédures de chiffrement et/ou d’encapsulation. L’invention offre une grande flexibilité en fonction du contexte dans lequel elle est appliquée. Au vu de ce qui précède, il apparaît clairement que l’invention s’appuie sur l’équipement utilisateur, mais également sur les première et deuxième entités du réseau. Ainsi selon un deuxième aspect, l’invention vise un procédé de négociation entre une entité d’un réseau, dite deuxième entité, et un équipement utilisateur dudit réseau, ledit procédé comprenant : - une étape de réception par la deuxième entité d’une demande d’autorisation d’une désactivation par l’équipement utilisateur, pour au moins une communication chiffrée de l’équipement utilisateur avec un dispositif distant via ledit réseau, d’au moins une procédure de chiffrement mise en œuvre avec au moins une entité du réseau, dite première entité, impliquée dans un acheminement de données échangées entre ledit équipement utilisateur et ledit dispositif distant lors de ladite communication chiffrée ; - si la demande est acceptée, une étape d’envoi par ladite deuxième entité d’au moins une information dite de contexte de désactivation, destinée audit équipement utilisateur, ladite au moins une information fournissant au moins une indication sur au moins une dite procédure de chiffrement pouvant être désactivée par ledit équipement utilisateur. Corrélativement, l’invention concerne aussi une entité d’un réseau, dite deuxième entité, comprenant : - une module de réception, configuré pour traiter une demande d’autorisation d’une désactivation par un équipement utilisateur dudit réseau, pour au moins une communication chiffrée de l’équipement utilisateur avec un dispositif distant via ledit réseau, d’au moins une procédure de chiffrement mise en œuvre avec au moins une entité du réseau, dite première entité, impliquée dans un acheminement de données échangées entre ledit équipement utilisateur et ledit dispositif distant lors de ladite communication chiffrée ; - un module d’envoi, activé si la demande est acceptée, et configuré pour envoyer au moins une information dite de contexte de désactivation, destinée audit équipement utilisateur, ladite au moins une information fournissant au moins une indication sur au moins une dite procédure de chiffrement pouvant être désactivée par ledit équipement utilisateur. Dans un mode particulier de réalisation, le procédé de négociation comprend en outre une étape de configuration par la deuxième entité de la première entité du réseau pour traiter des données échangées entre l’équipement utilisateur et le dispositif distant lors de la communication chiffrée lorsqu’une procédure de chiffrement avec la première entité est désactivée par l’équipement utilisateur. Corrélativement, dans ce mode de réalisation, la deuxième entité comprend en outre un module de configuration, programmé pour configurer la première entité du réseau pour traiter des données échangées entre ledit équipement utilisateur et ledit dispositif distant lors de ladite communication chiffrée lorsqu’une procédure de chiffrement avec ladite première entité est désactivée par ledit équipement utilisateur. On note que la demande d’autorisation peut également porter sur une procédure d’établissement d’un tunnel avec la première entité comme décrit précédemment, et le cas échéant, ladite au moins une information de contexte de désactivation comprendre au moins une indication sur une dite procédure d’établissement d’un tunnel pouvant être désactivée et le module de configuration de la deuxième entité être en mesure de configurer la première entité pour qu’elle soit capable de traiter des données transitant par elle sans être encapsulées pour être acheminées via ce tunnel. Selon un troisième aspect, l’invention concerne un procédé de gestion d’une connexion d’un équipement utilisateur d’un réseau par une première entité du réseau, cette première entité étant impliquée dans un acheminement de données échangées entre l’équipement utilisateur et un dispositif distant lors d’une communication chiffrée, ce procédé de gestion comprenant : - une étape de réception, en provenance de l’équipement utilisateur, d’une demande d’établissement d’une première connexion avec ou via la première entité dans laquelle au moins une procédure de chiffrement entre la première entité et ledit équipement utilisateur, sélectionnée par ledit équipement utilisateur, est désactivée ; - si la première entité accepte l’établissement de la première connexion, une étape de traitement de données échangées, lors de ladite communication chiffrée, entre ledit équipement utilisateur et ledit dispositif distant via ladite première connexion ; - sinon, une étape de traitement de données échangées, lors de la communication chiffrée, entre l’équipement utilisateur et le dispositif distant via une deuxième connexion établie par l’équipement utilisateur avec ou via la première entité dans laquelle ladite procédure de chiffrement est activée entre l’équipement utilisateur et la première entité. On note que l’acceptation de la deuxième connexion peut être explicite ou implicite dès lors que la première entité ne rejette pas cette deuxième connexion et traite les données échangées via cette deuxième connexion. Autrement dit, l’étape de traitement des données échangées via la deuxième connexion emporte l’acceptation de la deuxième connexion par la première entité. Corrélativement, l’invention vise également une entité d’un réseau, dite première entité, susceptible d’être impliquée dans un acheminement de données échangées entre un équipement utilisateur du réseau et un dispositif distant lors d’une communication chiffrée, cette première entité comprenant : - un module de désactivation configuré pour désactiver, lors de ladite communication chiffrée, une procédure de chiffrement avec l’équipement utilisateur, sélectionnée par ledit équipement utilisateur; et - un module de traitement configuré pour traiter des données échangées, lors de ladite communication chiffrée, entre l’équipement utilisateur et le dispositif distant et transitant par la première entité. Dans un mode particulier de réalisation, la première entité comprend : - un premier module de traitement, configuré pour traiter une demande, reçue en provenance de l’équipement utilisateur, d’établissement d’une première connexion avec ou via la première entité dans laquelle au moins une procédure de chiffrement entre la première entité et ledit équipement utilisateur, sélectionnée par ledit équipement utilisateur, est désactivée lors de ladite communication chiffrée ; - un deuxième module de traitement, activé si la demande d’établissement est acceptée, et configuré pour traiter des données échangées, lors de la communication chiffrée, entre l’équipement utilisateur et le dispositif distant via ladite première connexion ; et - un troisième module de traitement, activé si la demande d’établissement est rejetée, et configuré pour traiter des données échangées, lors de ladite communication chiffrée, entre l’équipement utilisateur et le dispositif distant via une deuxième connexion établie par l’équipement utilisateur dans laquelle ladite procédure de chiffrement est mise en œuvre entre l’équipement utilisateur et la première entité. On note ici que l’équipement utilisateur peut également décider de désactiver lors de la première connexion une procédure d’établissement d’un tunnel avec la première entité, auquel cas, le deuxième module de traitement de la première entité est, si la demande d’établissement de la première connexion est acceptée, configuré pour traiter des données qui ne sont pas encapsulées selon ladite procédure désactivée. Si la demande d’établissement de la première connexion est rejetée, alors l’équipement utilisateur établit une deuxième connexion dans laquelle la procédure de chiffrement et/ou la procédure d’établissement d’un tunnel avec la première entité est (sont) rétablie(s). Dans un mode particulier de réalisation de l’invention, les procédés de configuration, de négociation et de gestion sont mis en œuvre par un ordinateur. L’invention vise également un programme d’ordinateur sur un support d’enregistrement, ce programme étant susceptible d’être mis en œuvre dans un ordinateur ou plus généralement dans un équipement utilisateur conforme à l’invention et comporte des instructions adaptées à la mise en œuvre d’un procédé de configuration tel que décrit ci-dessus. L’invention vise également selon un quatrième aspect un programme d’ordinateur sur un support d’enregistrement, ce programme étant susceptible d’être mis en œuvre dans un ordinateur ou plus généralement dans une « première » entité du réseau conforme à l’invention et comporte des instructions adaptées à la mise en œuvre d’un procédé de gestion d’une connexion tel que décrit ci-dessus. L’invention vise également un programme d’ordinateur sur un support d’enregistrement, ce programme étant susceptible d’être mis en œuvre dans un ordinateur ou plus généralement dans une « deuxième » entité du réseau conforme à l’invention et comporte des instructions adaptées à la mise en œuvre d’un procédé de négociation tel que décrit ci-dessus. Chacun de ces programmes peut utiliser n’importe quel langage de programmation, et être sous la forme de code source, code objet, ou de code intermédiaire entre code source et code objet, tel que dans une forme partiellement compilée, ou dans n’importe quelle autre forme souhaitable. L’invention vise aussi un support d'information ou un support d’enregistrement lisibles par un ordinateur, et comportant des instructions d’un programme d'ordinateur tel que mentionné ci-dessus. Le support d'information ou d’enregistrement peut être n'importe quelle entité ou dispositif capable de stocker les programmes. Par exemple, le support peut comporter un moyen de stockage, tel qu'une ROM, par exemple un CD ROM ou une ROM de circuit microélectronique, ou encore un moyen d'enregistrement magnétique, par exemple un disque dur, ou une mémoire flash. D'autre part, le support d'information ou d’enregistrement peut être un support transmissible tel qu'un signal électrique ou optique, qui peut être acheminé via un câble électrique ou optique, par lien radio, par lien optique sans fil ou par d'autres moyens. Le programme selon l'invention peut être en particulier téléchargé sur un réseau de type Internet. Alternativement, le support d'information ou d’enregistrement peut être un circuit intégré dans lequel un programme est incorporé, le circuit étant adapté pour exécuter ou pour être utilisé dans l'exécution des procédés de fourniture et d’obtention selon l’invention. Selon un cinquième aspect, l’invention vise également un système de télécommunications comprenant au moins un équipement utilisateur d’un réseau selon l’invention et au moins une première et/ou une deuxième entité du réseau selon l’invention. Le procédé de négociation, le procédé de gestion, les première et deuxième entités et le système de télécommunications bénéficient des mêmes avantages cités précédemment que le procédé de configuration et l’équipement utilisateur selon l’invention. On peut également envisager, dans d'autres modes de réalisation, que le procédé de configuration, le procédé de négociation, le procédé de gestion, l’équipement utilisateur, les première et deuxième entités et le système de télécommunications selon l'invention présentent en combinaison tout ou partie des caractéristiques précitées. D’autres caractéristiques et avantages de la présente invention ressortiront de la description faite ci-dessous, en référence aux dessins annexés qui en illustrent un exemple de réalisation dépourvu de tout caractère limitatif. Sur les figures : la figure 1, déjà décrite, représente, les piles protocolaires mises en œuvre au niveau d’un équipement utilisateur et de différentes entités d’un réseau pour le support du service ATSSS défini par le standard 3GPP ; la figure 2 représente dans son environnement, un système de télécommunications selon l’invention dans un mode particulier de réalisation ; la figure 3 représente l’architecture matérielle d’un équipement utilisateur du système de télécommunications de la figure 2, conforme à l’invention, dans un mode particulier de réalisation ; la figure 4 représente l’architecture matérielle d’une entité FF (pour « Forwarding Function » en anglais) hébergeant une fonction de transport et/ou d’une entité CF (pour « Control Function » en anglais) de contrôle d’une telle entité, conformes à l’invention, dans un mode particulier de réalisation ; la figure 5A illustre l’établissement de tunnels entre l’équipement utilisateur UE et diverses entités FF dans l’état de la technique, tandis que les figures 5B et 5C illustrent un exemple de mise en œuvre de l’invention ; les figures 6A et 6B représentent respectivement les étapes mises en œuvre par un équipement utilisateur, une entité hébergeant une fonction transport et une, respectivement plusieurs, entités de contrôle dans une première variante de l’invention (variante 1) ; la figure 7 illustre un exemple d’application de la première variante de l’invention dans le contexte d’un service ATSSS défini par le standard 3GPP ; la figure 8 représentent les étapes mises en œuvre par un équipement utilisateur et plusieurs entités FF hébergeant une fonction transport dans une deuxième variante de l’invention (variante 2) ; la figure 9 illustre un exemple de résultat de l’application de la deuxième variante ; les figures 10A et 10B représentent, sous forme d’ordinogrammes, les différentes étapes mises en œuvre par un équipement utilisateur et par une entité FF hébergeant une fonction transport dans une troisième variante de l’invention (variante 3). Description de l’invention La figure 2 représente, dans son environnement, un système 1 de télécommunications conforme à l’invention, dans un mode particulier de réalisation. Dans l’exemple envisagé à la figure 2, le système 1 comprend au moins un équipement utilisateur UE1, conforme à l’invention, et ayant souscrit un abonnement auprès d’un opérateur OP d’un réseau NW de télécommunications pour bénéficier des services offerts par ce réseau. L’équipement utilisateur UE1 est par exemple ici un terminal tel qu’un smartphone. Il peut s’agir en variante d’un autre type de terminal (par exemple un ordinateur personnel ou PC), ou d’un équipement de type CPE auquel peuvent être reliés via un réseau local un ou plusieurs terminaux. Aucune hypothèse n’est faite sur la nature du réseau NW. Il peut s’agir d’un réseau 4G, 5G, d’un réseau propriétaire, etc. Dans l’exemple envisagé ici le réseau NW de l’opérateur OP est un réseau 5G s’appuyant sur un réseau cœur ou cœur de réseau (ou encore « core network » en anglais) CN. Aucune limitation n’est attachée non plus au(x) réseau(x) d’accès (ou AN pour « Access Network(s) ») pouvant être utilisé(s) pour accéder au réseau de l’opérateur OP, et plus particulièrement au réseau cœur CN, ni au nombre de ces réseaux d’accès, ni encore à la technologie utilisée pour se connecter à ces réseaux d’accès. Dans l’exemple envisagé à la figure 2, on fait l’hypothèse que l’équipement utilisateur UE1 peut utiliser deux réseaux d’accès AN1 et AN2 pour se connecter au réseau cœur CN (il peut être connecté simultanément ou non à ces deux réseaux d’accès) : le réseau d’accès AN1 est un réseau d’accès 3GPP géré par l’opérateur OP (autrement dit, un réseau de confiance ou TAN pour « Trusted Access Network » en anglais), tandis que le réseau d’accès AN2 est un réseau d’accès géré par une autre entité administrative que l’opérateur OP (et considéré de ce fait comme un réseau « non fiable » (ou UAN pour « Untrusted Access Network » en anglais), tel que par exemple un réseau WLAN. Bien entendu d’autres configurations de réseaux d’accès peuvent être envisagées. De façon connue en soi et non détaillée ici, des mécanismes sont mis en place pour sécuriser l’accès aux services offerts par le réseau cœur CN mais aussi pour protéger le réseau cœur CN des attaques d’origines extérieures au réseau CN. Bien entendu, d’autres mécanismes de sécurité sont mis en place au sein du réseau cœur CN pour le protéger des attaques dont les sources seraient situées à l’intérieur du réseau. Ces mécanismes de sécurité ont aussi pour objectif d’éviter que les réseaux intermédiaires accèdent aux données sensibles transportées par les flux de données échangés entre un équipement utilisateur (comme l’équipement utilisateur UE) et le réseau cœur CN ou avec un serveur distant via ledit réseau cœur CN. Le réseau cœur CN comprend plusieurs entités fonctionnelles, aussi désignées par « fonctions » en support des services fournis par le réseau NW. Au sens de l’invention, une entité ou une fonction du réseau cœur CN peut désigner indifféremment un dispositif physique (par exemple un serveur, un routeur) ou une fonction logicielle (par exemple une machine virtuelle). Ainsi, dans l’exemple envisagé à la figure 2, le réseau cœur CN comprend notamment une entité AGW (pour « Access Gateway » en anglais) telle que définie par le standard 3GPP, utilisée pour contrôler l’accès au réseau cœur CN depuis un réseau d’accès UAN, et diverses entités ou fonctions référencées de manière générale par FF (pour « Forwarding Functions » en anglais), et impliquées dans l’acheminement du trafic de données via le réseau cœur CN. Aucune hypothèse n’est faite quant à la terminaison d’une connexion par une telle entité FF ; l’invention s’applique également à des entités FF embarquant des fonctions proxys qui relaient des connexions. Des exemples d’entité AGW et d’entité FF sont respectivement les fonctions N3IWF et ATSSS UPF évoquées précédemment. Un autre exemple d’entité FF est un routeur. On note que l’entité AGW peut intégrer une entité FF impliquée dans l’acheminement des données transitant par le réseau cœur CN en plus de sa fonction de contrôle de l’accès au réseau cœur. Les entités FF sont également utilisées pour la connexion du réseau cœur CN à des réseaux tiers, comme par exemple au réseau Internet. L’acheminement du trafic émis ou destiné à un équipement utilisateur connecté au réseau cœur CN, tel que par exemple l’équipement utilisateur UE1, peut impliquer une ou plusieurs entités FF du réseau cœur CN. Aucune hypothèse n’est faite quant à la localisation du dispositif distant avec lequel l’équipement utilisateur UE1 échange du trafic : il peut s’agir d’un équipement tel qu’un serveur, situé dans le réseau cœur CN ou connecté au réseau cœur CN (par exemple le serveur S1 sur la figure 2) ou dans un autre réseau comme par exemple dans le réseau Internet (par exemple les serveurs S2, S3, …, Sn sur la figure 2, « n » désignant un entier), ou encore d’un autre équipement utilisateur connecté ou non au réseau cœur CN (non représenté sur la figure 2). Aussi, aucune hypothèse n’est faite quant à la structure logicielle et physique (hardware) de ce dispositif distant. Le dispositif distant peut être un équipement dédié ou une instance logicielle. Dans l’exemple envisagé ici, par souci de simplification, on considère que toutes les entités FF impliquées dans l’acheminement du trafic à destination ou en provenance de l’équipement utilisateur UE1 sont gérées par le même opérateur, à savoir l’opérateur OP. Toutefois, en pratique, des tunnels peuvent être mis en place pour l’acheminement de ce trafic impliquant des entités FF localisées dans d’autres domaines que celui de l’opérateur OP (par exemple pour fournir des services d’itinérance ou « roaming » en anglais). Le réseau CN comprend également des entités dites de contrôle CF (pour « Control Functions » en anglais), responsables du contrôle d’une ou de plusieurs entités FF et/ou d’un ou de plusieurs équipements utilisateurs. Des exemples de telles entités de contrôle dans le contexte d’un réseau 5G 3GPP comme le réseau cœur CN sont les fonctions de gestion de l’accès et de la mobilité ou AMF (pour « Access and Mobility Management Function » en anglais), de gestion de sessions ou SMF (pour « Session Management Function » en anglais), de contrôle de politiques PCF (pour « Policy Control Function » en anglais). Aucune hypothèse n’est faite ici quant à la structuration des entités de contrôle CF (interconnexion, hiérarchie, capacités fonctionnelles, etc.). On note en outre qu’un même élément (ou nœud) physique du réseau cœur CN peut héberger des entités FF et CF. Dans le mode de réalisation décrit ici, tout ou partie des entités FF et CF précitées se distinguent des entités correspondantes définies par le standard 3GPP en ce qu’elles sont conformes à l’invention et appartiennent au système 1 de télécommunications. Comme mentionné précédemment, l’invention offre la possibilité à l’équipement utilisateur UE1 de désactiver tout ou partie des procédures de chiffrement et/ou d’établissement de tunnels mises en œuvre avec des entités du réseau impliquées dans l’acheminement du trafic destiné ou émis par l’équipement utilisateur UE1. Dans la suite de la description, par souci de simplification on se limite à la désactivation de procédures de chiffrement et on envisage trois variantes de réalisation de l’invention dans lesquelles : Variantes 1 et 2 : une négociation préalable a lieu avec le réseau avant désactivation d’une ou de plusieurs procédures de chiffrement par l’équipement utilisateur UE1 avec une ou plusieurs entités FF ; dans la variante 1, la négociation a lieu avec les entités de contrôle CF gérant cette ou ces entités FF, tandis que dans la variante 2, la négociation a lieu avec la ou les entités FF directement ; ou Variante 3 : la désactivation est mise en œuvre par défaut par l’équipement utilisateur UE sans négociation préalable avec le réseau. On note que des variantes similaires ou identiques peuvent être envisagées pour la désactivation d’une ou de plusieurs procédures d’établissement d’un tunnel en plus ou en remplacement des procédures de chiffrement. La désactivation de procédures de chiffrement et de procédures d’établissement d’un tunnel ne sont pas mutuellement exclusives et peuvent être décidées conjointement par l’équipement utilisateur UE1, ou au contraire de façon indépendante. Dans chacune des variantes de réalisation 1 à 3 décrites ici, l’équipement utilisateur UE1 a l’architecture matérielle d’un ordinateur telle que représentée à la figure 3 . Il comprend notamment un processeur 2, une mémoire vive 3, une mémoire morte 4, une mémoire non volatile 5, et des moyens de communication 6 comprenant notamment diverses interfaces physiques et protocolaires permettant à l’équipement utilisateur UE1 de se connecter aux réseaux d’accès lui permettant d’accéder au réseau cœur CN, à savoir ici aux réseaux d’accès AN1 et AN2. De telles interfaces sont connues en soi et non décrites en détail. La mémoire morte 4 constitue un support d’enregistrement conforme à l’invention, lisible par le processeur 2 et sur lequel est enregistré un programme d’ordinateur conforme à l’invention, à savoir un programme d’ordinateur PROG-UE(1) pour la variante 1, PROG-UE(2) pour la variante 2, et PROG-UE(3) pour la variante 3. Les programmes PROG-UE(1), PROG-UE(2) et PROG-UE(3) définissent des modules fonctionnels de l’équipement utilisateur UE1 qui s’appuient ou commandent les éléments matériels 2 à 6 précités. Ces modules comprennent notamment, dans les trois variantes de réalisation envisagées ici, comme représenté sur la figure 2 : - un module 7A de communication configuré pour établir au moins une connexion avec le dispositif distant (par exemple avec le serveur S1) supportant une communication chiffrée, cette connexion transitant via différentes entités FF du réseau cœur CN impliquées dans l’acheminement du trafic échangé entre l’équipement utilisateur UE1 et ce dispositif distant. On note qu’aucune hypothèse n’est faite quant à la terminaison d’une connexion par une entité FF impliquée dans l’acheminement du trafic. Selon le protocole de transport envisagé, la communication chiffrée entre l’équipement utilisateur UE1 et le dispositif distant peut nécessiter l’établissement d’une pluralité de connexions entre l’équipement utilisateur UE1, respectivement le dispositif distant, et chacune des entités FF impliquées dans l’acheminement du trafic (par exemple pour le protocole QUIC). Cette communication chiffrée peut également en variante s’appuyer sur des associations entre l’équipement utilisateur UE1 et chacune des entités FF (par exemple, pour le protocole IPsec) ; - un module 7B de sélection configuré pour sélectionner une ou plusieurs procédures de chiffrement mises en œuvre avec ces entités FF et pouvant être désactivées lors de la communication chiffrée. On note qu’un prérequis pour pouvoir désactiver une procédure de chiffrement appliquée aux données échangées lors de la communication est l’existence d’une autre procédure de chiffrement protégeant ces données (au moins les données utiles). En outre, selon la variante de réalisation envisagée, le module 7B de sélection peut sélectionner la ou les procédures de chiffrement à désactiver en fonction d’informations provenant du réseau comme décrit davantage ultérieurement ; et - un module 7C de désactivation configuré pour désactiver la ou les procédures de chiffrement sélectionnées par le module 7B de sélection. Les programmes PROG-UE(1) et PROG-UE(2) définissent en outre un autre module fonctionnel de l’équipement utilisateur UE1 activé lors de la mise en œuvre des variantes 1 et 2, à savoir un module 7D de négociation avec le réseau (représenté en traits discontinus sur la figure 2) configuré pour requérir auprès du réseau une autorisation préalable pour désactiver une ou plusieurs procédures de chiffrement. Ce module 7D de négociation est configuré dans la variante 1 pour négocier avec une entité CF de contrôle du réseau cœur CN tandis que dans la variante 2, il est configuré pour négocier directement avec la ou les entités FF impliquées dans l’acheminement des données échangées entre l’équipement utilisateur UE et son correspondant. Le programme PROG-UE(3) définit les modules 7A-7C de sorte que la ou les procédures de chiffrement sélectionnées par le module 7B de sélection sont désactivées par défaut par le module 7C de désactivation lors de l’établissement de de la connexion avec le dispositif distant transitant via la ou les entités FF concernées. Pour chaque entité FF, le module 7A est alors configuré pour : - demander l’établissement d’une première connexion avec ou via cette entité FF dans laquelle la ou les procédures de chiffrement sélectionnées sont désactivées (au regard de ce qui a été indiqué précédemment, la première connexion est soit la connexion établie avec le dispositif distant pour supporter la communication chiffrée, soit une connexion établie avec l’entité FF requise pour que les données échangées entre l’équipement utilisateur UE1 et le dispositif distant soient acheminées via cette entité FF) ; - en cas de rejet de cette première connexion par l’entité FF, demander l’établissement d’une deuxième connexion avec ou via l’entité FF (cf. remarque ci-dessus) dans laquelle la ou les procédures de chiffrement sélectionnées sont (ré-)activées entre l’équipement utilisateur UE1 et l’entité FF. Le fonctionnement des modules 7A à 7D est expliqué plus en détail ultérieurement pour chacune des variantes de réalisation envisagées. Par ailleurs, dans chacune des variantes de réalisation envisagées ici, les entités FF et CF du système 1 de télécommunications ont également l’architecture matérielle d’un ordinateur telle que représentée à la figure 4 . Quand deux entités FF et CF sont colocalisées, elles peuvent bien entendu partager cette architecture. Chaque entité CF ou FF comprend notamment un processeur 8, une mémoire vive 9, une mémoire morte 10, une mémoire non volatile 11, et des moyens de communication 12 leur permettant de communiquer notamment avec d’autres entités du réseau cœur CN ou d’autres réseaux. La mémoire morte 10 constitue un support d’enregistrement conforme à l’invention, lisible par le processeur 8 et sur lequel est enregistré, pour les entités FF, un programme d’ordinateur PROG-FF(1) pour la variante 1, PROG-FF(2) pour la variante 2, et PROG-FF(3) pour la variante 3, et pour les entités CF, un programme d’ordinateur PROF-CF(1) pour la variante 1. On note que les variantes 2 et 3 décrites ici, les fonctions CF du réseau NW sont conformes au standard 3GPP. Les programmes PROG-FF(1), PROG-FF(2) et PROG-FF(3) définissent des modules fonctionnels d’une entité FF conforme à l’invention qui s’appuient ou commandent les éléments matériels 8 à 12 précités. Ces modules fonctionnels de l’entité FF comprennent, comme illustré sur la figure 2 : - un module 13A de communication, configuré pour communiquer avec l’équipement utilisateur UE1 lors d’une communication chiffrée de cet équipement utilisateur UE1 avec un dispositif distant (par exemple le serveur S1). La communication entre le module 13A et l’équipement utilisateur UE1 peut s’appuyer sur l’établissement d’une ou de plusieurs connexions (correspondant à des chemins multiples) entre le module 13A et l’équipement utilisateur UE1, sur une association, etc., selon le contexte d’application de l’invention ; - un module 13B de désactivation, configuré pour désactiver à l’initiative de l’équipement utilisateur UE1 une ou plusieurs procédures de chiffrement mises en œuvre par le module 13A de communication avec l’équipement utilisateur UE1 durant la communication chiffrée transitant via l’entité FF ; et - un module 13C de traitement, configuré pour traiter des données échangées lors de cette communication chiffrée entre les deux équipements via l’entité FF, que ces données fassent ou non l’objet d’une procédure de chiffrement entre l’équipement utilisateur UE1 et l’entité FF. Le module 13C de traitement est configuré notamment pour, lorsqu’une procédure de chiffrement est désactivée conformément à l’invention, être en mesure de traiter les données transitant par l’entité FF (autrement dit, de ne plus appliquer la procédure de déchiffrement correspondant à la procédure de chiffrement désactivée, et de ne plus chiffrer les paquets de données qu’elle reçoit du dispositif distant et envoie à destination de l’équipement utilisateur UE1). Selon la variante de réalisation envisagée, des modules additionnels ou une configuration différentes des modules 13A-13C peuvent être définis par les programmes PROG-FF(1), PROG-FF(2) et PROG-FF(3). Ainsi, selon la variante 1 (négociation préalable entre l’équipement utilisateur UE1 et l’entité de contrôle CF gérant l’entité FF considérée), le programme PROG-FF(1) définit en outre un deuxième module 13D de communication (représenté en traits discontinus sur la figure 2) configuré pour interagir avec l’entité CF de contrôle de l’entité FF en vue de créer un contexte de connexion utilisé par les modules 13A-13C lors de la communication chiffrée de l’équipement utilisateur UE1 dans laquelle, à l’initiative de ce dernier, une procédure de chiffrement est désactivée avec l’entité FF et traiter les données transitant via l’entité FF. Le deuxième module 13D de communication est également configuré pour transmettre à l’entité CF au moins une information dite de contexte de désactivation, notée ici « Optimized-INFO », destinée à l’équipement utilisateur UE1 et fournissant à ce dernier au moins une indication sur au moins une procédure de chiffrement pouvant être désactivée avec l’entité FF. Cette ou ces informations de contexte de désactivation sont alors utilisées par le module 7B de sélection de l’équipement utilisateur UE1 pour sélectionner une procédure de chiffrement à désactiver. Selon la variante 2 (négociation préalable entre l’équipement utilisateur UE1 et l’entité FF considérée), le programme PROG-FF(2) définit un module 13E de négociation (représenté en traits discontinus sur la figure 2) configuré pour interagir avec l’équipement utilisateur UE1 directement (et notamment avec son module 7D de négociation) : le module 13E de négociation est configuré pour recevoir et traiter une demande d’autorisation d’une désactivation par l’équipement utilisateur UE d’au moins une procédure de chiffrement mise en œuvre avec l’entité FF, et si la demande d’autorisation est acceptée, pour envoyer à l’équipement utilisateur UE1, au moins une information de contexte de désactivation « Optimized-INFO » telle que mentionnée précédemment dans la variante 1. Le module 13E de négociation est également configuré ici pour créer, si la demande de l’équipement utilisateur UE est acceptée, un contexte de connexion visant à permettre au module 13A de communication de gérer la communication chiffrée de l’équipement utilisateur UE dans laquelle une procédure de chiffrement avec l’entité FF, sélectionnée par l’équipement utilisateur UE en accord avec la ou les informations « Optimized-INFO », est désactivée par le module 13B de désactivation, et au module 13C de traiter les données correspondantes. On note que dans la variante 2, l’entité FF dispose des moyens d’une deuxième entité au sens de l’invention. Enfin, selon la variante 3, le module 13A est configuré pour traiter une demande, reçue en provenance de l’équipement utilisateur UE1 d’établissement d’une première connexion avec ou via l’entité FF dans laquelle au moins une procédure de chiffrement entre l’équipement utilisateur UE1 et l’entité FF, sélectionnée par l’équipement utilisateur UE1, est désactivée lors de la communication chiffrée entre l’équipement utilisateur UE et le dispositif distant (par exemple le serveur S1). Si la demande d’établissement de la première connexion est acceptée par l’entité FF (par son module 13A ici), alors le module 13B de désactivation est configuré pour désactiver ladite procédure de chiffrement, et le module 13C est activé pour traiter les données échangées entre l’équipement utilisateur UE1 et le dispositif distant, transitant par l’entité FF via la première connexion. Sinon, le module 13C est activé pour traiter les données échangées entre l’équipement utilisateur UE1 et le dispositif distant, transitant par l’entité FF, via une deuxième connexion établie entre l’équipement utilisateur UE1 et le dispositif distant, dans laquelle ladite procédure de chiffrement avec l’entité FF est maintenue et mise en œuvre. Dans la variante 1, le programme PROG-CF(1) définit des modules fonctionnels d’une entité CF conforme à l’invention (deuxième entité au sens de l’invention) gérant une entité FF telle qu’évoquée ci-dessus pour la variante 1, ces modules fonctionnels s’appuyant ou commandant les éléments matériels 8 à 12 précités. Les modules fonctionnels de l’entité CF comprennent ici notamment, comme illustré sur la figure 2 : - un module 14A de négociation, configuré pour : recevoir une demande d’autorisation d’une désactivation par l’équipement utilisateur UE1, pour au moins une communication chiffrée de l’équipement utilisateur UE1 avec un dispositif distant (par exemple S1) via le réseau cœur CN, d’au moins une procédure de chiffrement mise en œuvre avec une entité FF impliquée dans un acheminement de données échangées entre l’équipement utilisateur UE1 et l’dispositif distant lors de la communication chiffrée ; et envoyer, si la demande est acceptée, au moins une information de contexte de désactivation « Optimized-INFO », telle que mentionnée précédemment, destinée à l’équipement utilisateur UE1 ; et - un module 14B de configuration, activé si l’entité FF en question est sous le contrôle de l’entité CF, et programmé pour configurer cette entité FF pour qu’elle soit en mesure de communiquer avec l’équipement utilisateur UE1 alors que la ou les procédures de chiffrement sélectionnées par ce dernier sont désactivées, et ainsi traiter les données échangées entre l’équipement utilisateur UE1 et le dispositif distant transitant par elle. Dans la variante 1 décrite ici, le module 14B de configuration interagit avec le deuxième module 13D de communication de l’entité FF en vue de créer un contexte de connexion utilisé par les modules 13A-13C comme indiqué précédemment. Le module 14B de configuration reçoit du deuxième module 13D de communication de l’entité FF, lors de cette interaction, les ou les informations précitées de contexte de désactivation « Optimized-INFO » destinées à l’équipement utilisateur UE1. Dans la variante 1 de réalisation envisagée ici, le programme PROG-CF(1) définit en outre un module 14C de communication de l’entité CF avec au moins une autre entité de contrôle CF, qui est activé si la demande d’autorisation reçue de l’équipement utilisateur UE1 concerne des entités FF qui ne sont pas gérées directement par l’entité CF. En effet, dans ce cas, le module 14C de communication relaye la demande d’autorisation de l’équipement utilisateur UE1 vers la ou les entités de contrôle CF concernées et relaye les réponses reçues de cette ou ces entités de contrôle CF vers l’équipement utilisateur UE1. Le fonctionnement des modules 13A-13E des entités FF et 14A-14C des entités CF est expliqué plus en détail ultérieurement pour chacune des variantes de réalisation envisagées. Nous allons maintenant décrire, en référence aux figures 5 à 10 , les principales étapes des procédés de configuration, de négociation et de gestion mis en œuvre par l’équipement utilisateur UE1, les entités CF et/ou les entités FF conformément à l’invention dans les variantes de réalisation 1 à 3 précédemment introduites. On se place ici pour décrire ces trois variantes de réalisation, dans le contexte d’une communication chiffrée, via le réseau NW et plus particulièrement le réseau cœur CN, entre l’équipement utilisateur UE1 et un dispositif distant, par exemple le serveur S1. Aucune limitation n’est attachée aux mécanismes de chiffrement mis en œuvre lors de cette communication chiffrée. De façon connue en soi, une pluralité de procédures de chiffrement sont généralement mises en œuvre sur un réseau, que ce soit au niveau du réseau d’accès, du réseau cœur, et/ou entre les équipements en communication. Ces mécanismes de chiffrement peuvent être en outre activés au niveau des différentes couches du modèle OSI (couche physique, couche liaison, couche réseau, couche transport, couche application, etc.). Dans l’exemple envisagé ici, on se place dans le contexte d’une communication chiffrée utilisant le protocole QUIC entre l’équipement utilisateur UE1 et le serveur S1. De façon connue et comme rappelé précédemment, le protocole QUIC chiffre non seulement les données applicatives (aussi désignées par « données utiles ») échangées entre l’équipement utilisateur UE1 et le serveur S1, mais également les informations de contrôle de connexion à l’exception d’un nombre limité d’entre elles, comme par exemple l’identifiant de connexion. Outre le chiffrement QUIC, les données applicatives échangées entre l’équipement utilisateur UE1 et le serveur S1 peuvent être ou non chiffrées par une autre procédure de chiffrement (par exemple appliquée au niveau de la couche physique). On suppose que lors de cette communication chiffrée selon le protocole QUIC, les données échangées entre l’équipement utilisateur UE1 et le serveur S1 transitent via une pluralité d’entités FF du système 1 de télécommunications, impliquées dans l’acheminement de ces données dans le réseau cœur CN. Dans l’exemple envisagé ici, au moins une connexion est établie entre l’équipement utilisateur UE1 et chaque entité FF via laquelle transite les données échangées entre l’équipement utilisateur UE1 et le serveur S1 (l’invention s’applique à une connexion simple comme à une connexion selon des chemins multiples), et le protocole QUIC est utilisé pour procéder à l’encapsulation et au chiffrement des données transitant par chaque connexion, comme préconisé dans les solutions proposées par le standard 3GPP, mentionnées précédemment, pour fournir un service ATSSS à tout type de trafic (transporté par tout type de protocoles de transport, TCP ou non). L’application de ce mode d’encapsulation à chaque entité FF traversée par les paquets de données est illustrée sur la figure 5A pour trois entités FF1, FF2 et FF3. Elle se traduit par l’établissement d’au moins trois tunnels (soit trois schémas d’encapsulation) et de la mise en œuvre d’au moins quatre procédures de chiffrement par l’équipement utilisateur UE1 liés à l’utilisation du protocole QUIC entre l’équipement utilisateur UE1 et le serveur S1 d’une part, et entre l’équipement utilisateur UE1 et chacune des entités FF1, FF2 et FF3 d’autre part. On note qu’entre l’équipement utilisateur UE1 et la première entité FF1 traversée, les trois tunnels, respectivement les quatre chiffrements, sont imbriqués les uns dans les autres conduisant à un overhead d’autant plus important. Conformément au standard 3GPP, à ces quatre tunnels, peut s’ajouter un tunnel (et donc une encapsulation supplémentaire) IPsec/ESP (pour « Encapsulating Security Payload » en anglais) (non représenté sur la figure 5A) entre l’équipement utilisateur UE1 et l’entité AGW si le réseau d’accès utilisé par l’équipement utilisateur UE1 pour accéder au réseau cœur CN est un réseau non-3GPP, considéré comme non fiable (réseau UAN). On note que ce qui vient d’être décrit pour l’équipement utilisateur UE1 vaut également pour le serveur S1. Les hypothèses précédentes ne sont pas limitatives en soi et l’invention s’applique dans d’autres contextes. Ainsi un autre protocole que QUIC peut être utilisé entre l’équipement utilisateur UE1 et le serveur S1, comme par exemple TCP, UDP, etc., et/ou pour établir des tunnels sécurisés entre l’équipement utilisateur UE1 et chacune des entités FF du réseau par lesquelles transitent les données échangées entre l’équipement utilisateur UE1 et le serveur S1, comme par exemple les protocoles TLS, DTLS, IPsec, etc. En outre, les communications entre l’équipement utilisateur UE1 et chaque entité FF impliquée dans l’acheminement des données peut s’appuyer sur une association plutôt que sur une connexion dédiée (par exemple lorsque le protocole IPsec est utilisé), etc. Nous allons maintenant décrire dans ce contexte chacune des variantes de réalisation. Variante 1 : La variante 1 est illustrée sur les figures 6 et 7 . Pour mémoire selon cette variante 1, l’équipement utilisateur UE1 négocie préalablement avec le réseau cœur CN et plus particulièrement avec les entités de contrôle CF, la désactivation d’une ou de plusieurs procédures de chiffrement mises en œuvre par l’équipement utilisateur UE1 avec les entités FF gérées par ces entités de contrôle, et impliquées dans l’acheminement des données échangées entre l’équipement utilisateur UE1 et le serveur S1. Par souci de simplification, on suppose dans la suite de la description que les entités FF1, FF2 et FF3 impliquées dans l’acheminement des données échangées entre l’équipement utilisateur UE1 et le serveur S1 lors de leur communication chiffrée sont gérées par une même entité de contrôle CF1. Toutefois la procédure décrite ci-après peut s’appliquer également dans un contexte où chaque entité FF est gérée par une entité de contrôle différente : elle est alors mise en œuvre par l’équipement utilisateur UE1 avec chaque entité de contrôle, ou avec une entité de contrôle dédiée qui sert de relais entre l’équipement utilisateur UE1 et les entités de contrôle gérant les entités FF, comme illustré sur la figure 6B (cf. étapes de relais E10b et E40b). La négociation peut être initiée par l’équipement utilisateur UE1 via son module 7D de négociation à tout moment, par exemple lors de l’attachement de l’équipement utilisateur UE1 au réseau cœur CN, lors de l’activation d’une session réseau, à intervalle régulier, sur activation explicite de l’utilisateur de l’équipement utilisateur UE1, sur activation par une application (par exemple par l’application ATSSS embarquée dans l’équipement utilisateur UE1) via une API dédiée, etc. Plus précisément, en référence à la figure 6A , l’équipement utilisateur UE1 sollicite l’autorisation du réseau en envoyant à destination de l’entité de contrôle CF1 une demande d’autorisation pour désactiver au moins une procédure de chiffrement avec au moins une entité FF impliquée dans l’acheminement des données lors de la communication chiffrée établie par l’équipement utilisateur UE1 avec le serveur S1 (entités FF1, FF2 et FF3 dans l’exemple envisagé) (étape E10). Cette demande d’autorisation prend la forme ici d’une requête nommée « Optimized-Configuration-Request » destinée à l’entité CF1. La demande d’autorisation « Optimized-Configuration-Request » peut spécifier explicitement les entités FF1, FF2 et FF3 visées par l’équipement utilisateur UE1 ou en variante, il peut s’agir d’une demande d’autorisation plus générale visant à connaître les entités FF du réseau impliquées dans l’acheminement des données pouvant être concernées ou non par une telle désactivation. On note que l’équipement utilisateur UE1 a été configuré préalablement avec des informations lui permettant d’identifier quelle entité de contrôle solliciter pour obtenir une telle autorisation, de façon connue en soi et non décrite ici. La requête peut toutefois transiter par d’autres entités (par exemple par une entité AGW) avant d’atteindre l’entité destinataire CF1. A réception de la requête par l’entité CF1, si le réseau cœur CN ne supporte pas l’invention, autrement dit, n’offre pas la possibilité de désactiver une procédure de chiffrement dans les conditions proposées par l’invention, alors la requête « Optimized-Configuration-Request » est ignorée par l’entité CF1 ou un message d’erreur (par exemple un message « Fail ») est retourné à l’équipement utilisateur UE1. L’équipement utilisateur UE1 est alors configuré ici pour ne pas renvoyer une telle requête avant l’expiration d’un délai déterminé, typiquement 24 heures, pour lui permettre de détecter un changement de la configuration du réseau cœur CN. Si au contraire, le réseau cœur CN supporte l’invention (comme supposé sur les figures 6A et 6B), la requête « Optimized-Configuration-Request » est alors traitée ici par l’entité CF1 et notamment par son module 14A de négociation et son module 14B de configuration. En variante, elle peut être relayée par le module 14C de communication de l’entité CF1 vers une autre entité CF pour traitement, par exemple vers l’entité CF2 comme illustrée sur la figure 6B. Plus spécifiquement, dans la variante 1 décrite ici, l’entité CF1 (respectivement CF2 dans l’exemple illustré à la figure 6B) vérifie si l’équipement utilisateur UE est autorisé (c.-à-d. habilité) à émettre une telle requête, par exemple en mettant en œuvre une procédure d’identification/d’authentification de l’équipement utilisateur UE, connue en soi et non décrite ici (étape E20). Si l’entité CF1 (respectivement CF2) détermine que l’équipement utilisateur UE est autorisé à solliciter une telle procédure (comme cela est supposé ici), l’entité CF1 (respectivement CF2) via son module 14B de configuration interagit alors avec les entités FF susceptibles d’être impliquées dans l’acheminement des données échangées entre l’équipement utilisateur UE et le serveur S1, à savoir ici avec les entités FF1, FF2 et FF3 (étape E30). Par souci de simplification sur les figures 6A et 6B, seule l’interaction avec l’entité FF1 est représentée. Cette interaction consiste ici en l’envoi d’un message de contrôle, nommé par exemple « FF-Control », par l’entité CF1 à l’entité FF1 (et plus particulièrement à son module 13D de communication) visant à configurer cette dernière pour qu’elle soit en mesure d’établir une connexion avec l’équipement utilisateur UE1 dans laquelle une ou des procédures de chiffrement sélectionnées par ce dernier sont désactivées, et traiter les données échangées entre l’équipement utilisateur UE1 et l’dispositif distant transitant via cette connexion. Ce message de contrôle informe l’entité FF1 qu’elle doit mettre en place une telle désactivation pour l’équipement utilisateur UE1, sur sollicitation de ce dernier, et contribuer ainsi à l’optimisation des performances de commutation de l’équipement utilisateur UE1. Le message « FF-Control » déclenche dans la variante décrite ici, au niveau de l’entité FF1, la création d’un contexte CNT(Id(UE1), DESACT) associé à un identifiant Id(UE1) de l’équipement utilisateur UE1 (par exemple à une adresse IP allouée à cet équipement utilisateur UE1 par le réseau), en prévision d’une telle connexion avec l’équipement utilisateur UE1 (soit établie directement avec l’entité FF1 dans le cadre de l’utilisation du protocole QUIC envisagée à titre illustratif ici, soit établie avec le serveur distant S1 via l’entité FF1, si une association entre l’entité FF1 et l’équipement utilisateur UE1 suffit pour le traitement par l’entité FF1 des données de l’équipement utilisateur UE1 (par exemple, présentation d’une clé de sécurité NONCE)). Le champ « DESACT » indique explicitement que, lors de cette connexion, si l’équipement utilisateur UE1 en fait le choix, au moins une procédure de chiffrement avec l’entité FF1, choisie par l’équipement utilisateur UE1, sera désactivée. Le contexte CNT(Id(UE1), DESACT) est destiné à être utilisé par les modules 13A-13C de l’entité FF1 pour le traitement des données transitant par l’entité FF1 lors de cette connexion. Il est stocké dans une mémoire de l’entité FF1 (par exemple dans sa mémoire non volatile 11). Suite à la création de ce contexte, l’entité FF1 détermine dans quelles conditions (c’est-à-dire dans quel contexte) elle est en mesure de mettre en place une telle désactivation avec l’équipement utilisateur UE1 (par exemple, pour quel(s) réseau(x) d’accès ou quelle(s) application(s), quelle(s) procédure(s) de chiffrement, avec ou sans présentation de jeton de sécurité, etc.). L’entité FF1 acquitte ensuite, via son module 13D de communication, le message « FF-Control » en envoyant un message d’acquittement ACK à l’entité CF1 (respectivement CF2) (étape E40). Le message d’acquittement ACK comprend ici au moins une information « Optimized INFO » de contexte de désactivation, telle que mentionnée précédemment, reflétant les conditions ainsi déterminées par l’entité FF1. Cette ou ces informations « Optimized INFO » comprennent ainsi notamment au moins une indication sur au moins une procédure de chiffrement pouvant être désactivée par ledit équipement utilisateur au niveau de l’entité FF1. Une telle indication est par exemple une application supportée par l’équipement utilisateur UE (par exemple, l’application ATSSS), un type de connexion (par exemple une connexion QUIC), un réseau d’accès utilisé par l’équipement utilisateur éligible à une désactivation d’une procédure de chiffrement avec l’entité FF1, ou au moins une procédure de chiffrement spécifique utilisée avec l’entité FF1 qui peut être désactivée (par exemple la procédure de chiffrement QUIC associée au tunnel mis en place entre l’équipement utilisateur UE1 et la fonction FF1) ou au contraire qui ne peut pas être désactivée par l’équipement utilisateur UE1. La ou les informations de contexte de désactivation transmises dans le message d’acquittement peuvent également comprendre une clé de sécurité nommée NONCE ici, destinée à être présentée par l’équipement utilisateur UE1 à l’entité FF1 lorsque l’équipement utilisateur UE1 va établir une connexion avec cette dernière (ou via cette dernière, si le protocole de transport considéré pour acheminer les données ne nécessite pas l’établissement de connexion entre l’équipement utilisateur UE1 et l’entité FF1) durant laquelle au moins une procédure de chiffrement avec l’entité FF1 est désactivée. Cette clé de sécurité NONCE est destinée à permettre à l’entité FF1 de réaliser des vérifications de sécurité lors qu’un équipement utilisateur tente d’établir une connexion avec elle (ou via l’entité FF1 dans le contexte évoqué ci-dessus) pour laquelle une ou plusieurs procédures de chiffrement habituellement mises en œuvre sont désactivées par l’équipement utilisateur en question. Comme mentionné précédemment, l’entité CF1 (respectivement CF2) procède avec les entités FF2 et FF3 comme cela vient d’être décrit pour l’entité FF1 (de façon parallèle ou successive). Si des entités de contrôle distinctes de l’entité CF1 (par exemple l’entité CF2) sont impliquées dans ces échanges, elles relaient vers l’entité CF1 les messages d’acquittement reçus des entités FF1 à FF3. Puis, l’entité CF1 répond positivement à la demande d’autorisation de l’équipement utilisateur UE1 au moyen d’un message de réponse nommé ici « Optimized-Configuration-Accept » envoyé à l’équipement utilisateur UE1 via son module 14A de négociation (étape E50). Le message de réponse « Optimized-Configuration-Accept » comprend les informations « Optimized INFO » de contexte de désactivation fournies par chacune des entités FF sollicitées (FF1, FF2 et FF3 dans l’exemple envisagé ici). Par souci de simplification ici, les informations fournies par chacune des entités FF sollicitées sont agrégées et fournies en l’état à l’équipement utilisateur UE1 dans le message « Optimized-Configuration-Accept ». En variante, elles peuvent faire l’objet d’un traitement par l’entité CF1 avant d’être communiquées à l’équipement utilisateur UE1, par exemple être synthétisées sous forme de règles, etc. A la réception de l’autorisation de l’entité CF1 par son module 7D de négociation, l’équipement utilisateur UE1 extrait du message « Optimized-Configuration-Accept » les informations de contexte de désactivation « Optimized INFO » et les mémorise, par exemple dans sa mémoire non volatile (étape E60). Ces informations de contexte de désactivation « Optimized INFO » sont alors utilisées par le module 7B de sélection de l’équipement utilisateur UE pour identifier les communications (autrement dit les connexions dans l’exemple du protocole QUIC envisagé ici) éligibles à la désactivation d’une ou plusieurs procédures de chiffrement appliquées aux données échangées lors de sa communication chiffrée avec le serveur S1 via une entité FF. La sélection de ces communications peut reposer sur la sélection des interfaces éligibles à la désactivation d’une ou plusieurs procédures de chiffrement. Puis le module 7B de sélection choisit (« sélectionne ») une ou plusieurs procédures de chiffrement parmi les procédures de chiffrement mises en œuvre dans les communications identifiées comme éligibles en fonction d’au moins un critère de sélection déterminé (étape E70). Comme mentionné précédemment, lors de cette sélection, l’équipement utilisateur UE1 s’assure notamment que sur la ou les communications concernées par une désactivation d’une procédure de chiffrement, les données transmises restent protégées en dépit de cette désactivation par au moins une autre procédure de chiffrement. Cette autre procédure de chiffrement est par exemple : - une procédure de chiffrement mise en œuvre avec une autre entité du réseau impliquée dans l’acheminement desdites données (par exemple, l’équipement utilisateur UE1 peut décider de désactiver la procédure de chiffrement mise en œuvre avec l’entité FF1 dès lors que les paquets de données échangés avec le serveur S1 sont protégés par une autre procédure de chiffrement mise en œuvre avec l’entité FF2 et/ou l’entité FF3) ; et/ou - une procédure de chiffrement mise en œuvre sur un réseau d’accès au réseau cœur CN utilisé par l’équipement utilisateur UE1 pour échanger des paquets de données avec le serveur S1 (par exemple une procédure de chiffrement mise en œuvre lors de l’établissement d’un tunnel IPsec entre l’équipement utilisateur UE1 et une fonction N3IWF lorsque le réseau d’accès est considéré comme UAN) ; et/ou - une procédure de chiffrement mise en œuvre avec le serveur S1 pour échanger des paquets de données (par exemple, la procédure de chiffrement du protocole QUIC lorsque ce protocole est utilisé entre l’équipement utilisateur UE1 et le serveur S1). Ces exemples ne sont donnés qu’à titre illustratif et d’autres mécanismes/procédures de chiffrement peuvent être envisagé(e)s en variante. D’autres critères de sélection peuvent être envisagés, en complément du critère précité, comme par exemple la capacité CPU (pour « Central Processing Unit » en anglais) de l’équipement utilisateur UE1, la taille maximale des paquets (ou MTU pour « Maximum Transmission Unit ») pouvant être transmise lors de la communication avec l’entité FF1, ou la latence de l’application requérant la connexion avec l’entité FF1, etc. Ces critères peuvent être propres à l’équipement utilisateur UE1, à la connexion avec le réseau cœur, etc. Puis l’équipement utilisateur UE1 désactive, par l’intermédiaire de son module 7C de désactivation, la ou les procédures de chiffrement sélectionnées par son module 7B de sélection (étape E80). Autrement dit, lorsque pour l’acheminement des données échangées lors de sa communication chiffrée avec le serveur S1, il établit des connexions QUIC via son module 7A de communication avec la ou les entités FF du réseau cœur CN associée(s) à la ou les procédures de chiffrement désactivées ou une connexion avec le serveur S1 transitant via cette ou ces entités FF, ces connexions sont mises en place sans mettre en œuvre cette ou ces procédures de chiffrement avec la ou les entités FF en question. Les figures 5B et 5C illustrent des exemples, à comparer avec la situation de l’état de la technique illustrée sur la figure 5A, dans lesquels respectivement : - toutes les procédures de chiffrement entre l’équipement utilisateur UE1 et les entités FF impliquées dans l’acheminement des données entre l’équipement utilisateur UE1 et le serveur S1 (à savoir les entités FF1, FF2 et FF3) ont été désactivées par ce dernier lorsque le réseau d’accès utilisé par l’équipement utilisateur UE1 est le réseau d’accès 3GPP AN1, considéré par le réseau cœur CN comme un réseau TAN (cf. figure 5B) ; - toutes les procédures de chiffrement entre l’équipement utilisateur UE1 et les entités FF impliquées dans l’acheminement des données entre l’équipement utilisateur UE1 et le serveur S1 ont été désactivées par ce dernier à l’exception de la procédure de chiffrement appliquée avec la première entité FF1, lorsque le réseau d’accès utilisé par l’équipement utilisateur UE1 est le réseau d’accès AN2, considéré comme un réseau UAN (cf. figure 5C). On note que dans le cas d’une connexion à chemins multiples exploitant les deux interfaces physiques dont dispose l’équipement utilisateur UE1 pour pouvoir accéder au réseau cœur via les deux réseaux d’accès AN1 et AN2, l’équipement utilisateur UE1 peut traiter les connexions établies sur chacun des chemins comme illustré respectivement sur les figures 5B et 5C. Les avantages apportés par l’invention apparaissent donc clairement au regard des figures 5A, 5B et 5C, en matière d’optimisation de la complexité des traitements mis en œuvre lors de l’établissement des connexions avec ou via les différentes entités FF. On note que dans l’exemple envisagé ici, seules les procédures de chiffrement font l’objet le cas échéant d’une désactivation, les tunnels mis en place entre l’équipement utilisateur UE1 et chacune des entités FF étant maintenus. Toutefois cette hypothèse n’est pas limitative en soi de l’invention. En effet, l’invention peut s’appliquer également de façon similaire à la désactivation de tunnels entre l’équipement utilisateur UE1 et les différentes entités FF, le prérequis pour désactiver une procédure d’établissement d’un tunnel avec une entité FF étant l’assurance d’un acheminement des données via cette entité FF, par l’intermédiaire par exemple d’options de routage à la source, ou en utilisant un autre tunnel. Bien entendu, d’autres critères peuvent être envisagés pour décider de la désactivation d’un tunnel, comme par exemple l’overhead généré par l’encapsulation requise pour établir ce tunnel, la latence induite par l’établissement de ce tunnel, etc. En outre, il convient de noter que comme évoqué précédemment, la désactivation d’un tunnel entre l’équipement utilisateur UE1 et une entité FF donnée peut être concomitante à ou au contraire indépendante de la désactivation d’une procédure de chiffrement correspondante (par exemple lorsque le tunnel en question est un tunnel sécurisé). La figure 7 illustre un exemple de mise en œuvre de la variante 1 de l’invention pour le service ATSSS défini par le standard 3GPP en combinaison avec l’utilisation du protocole QUIC pour établir un tunnel sécurisé entre l’équipement utilisateur UE1 et les entités FF impliquées dans l’acheminement des données échangées entre l’équipement utilisateur UE1 et le serveur S1. Dans cet exemple, en référence aux notations précédemment introduites, on considère deux entités FF1 et FF2 constituées respectivement par une entité UPF et une entité NW3IF, et deux entités CF1 et CF2 constituées respectivement par une entité AMF et par une entité SMF. Les entités UPF, N3IWF, AMF et SMF ont les caractéristiques définies dans le standard 3GPP (par exemple dans le document TS 23.501 introduit précédemment). Elles sont en outre configurées ici pour mettre en œuvre l’invention selon la variante 1, de même que les messages classiquement échangés entre ces entités. Plus spécifiquement, dans l’exemple de la figure 7, les étapes E10 à E80 de la variante 1 sont mises en œuvre telles que décrites précédemment en considérant les éléments suivants : - la demande d’autorisation « Optimized-Configuration-Request » envoyée à l’étape E10 est transmise à l’entité CF1 par l’intermédiaire du message « PDU Session Establishment Request » d’établissement d’une session, connu du standard 3GPP, permettant à l’équipement utilisateur UE1 de récupérer la configuration des tunnels (QUIC ici) à mettre en place entre l’équipement utilisateur UE1 et la fonction ATSSS supportée par l’entité FF1=UPF. Ce message comprend notamment un identifiant « PDU Session ID » de la session ainsi qu’un paramètre « MA PDU » indiquant que la session utilise des chemins multiples (établis par l’équipement utilisateur UE1 par exemple via les réseaux d’accès AN1 et AN2). On note que le message identifie de façon implicite l’entité FF1=UPF hébergeant la fonction ATSSS, visée par la demande d’autorisation de l’équipement utilisateur UE1, par l’intermédiaire de la présence du paramètre « MA PDU ». Le message « PDU Session Establishment Request » est par ailleurs modifié ici de sorte à intégrer un nouveau champ nommé « Optimized-QUIC », reflétant la demande d’autorisation sollicitée par l’équipement utilisateur UE1. - la demande d’autorisation est reçue par l’entité de contrôle CF1=AMF, qui, après avoir vérifié au cours de l’étape E20 que le réseau cœur CN met en œuvre l’invention et que l’équipement utilisateur UE1 est autorisé à désactiver une procédure de chiffrement comme le propose l’invention, relaye la demande d’autorisation vers l’entité de contrôle CF2=SMF chargée de la gestion de l’entité FF1=UPF et apte à traiter cette demande ; - l’entité de contrôle CF2=SMF interagit alors avec l’entité FF1=UPF au cours de l’étape E30 comme décrit précédemment : le message de configuration « FF-Control » envoyé par l’entité CF2 à l’entité FF1 prend la forme ici d’un message « N4 Session Establishment » défini par le standard 3GPP dans lequel est inséré un nouveau champ « Optimized-connection » tel que décrit précédemment pour faire part à l’entité FF1 de la demande de l’équipement utilisateur UE1 ; - l’acquittement envoyé par l’entité FF1=UPF à l’entité CF2=SMF avec la ou les informations de contexte de désactivation « Optimized INFO » est un message « N4 Session Ack », comprenant un nouveau champ contenant la ou les informations « Optimized INFO » ; - l’entité CF2 obtient de façon similaire (à la nature des messages près) des informations de contexte de désactivation « Optimized INFO » de l’entité FF2=NW3IF ; - l’entité CF2=SMF relaye la ou les informations « Optimized INFO » fournies par les entités FF1 et FF2 vers l’entité CF1=AMF dans un message « Namf_Comm_N1N2MessageTransfert » tel que défini par le standard 3GPP, modifié de sorte à contenir les informations « Optimized INFO ». Dans l’exemple envisagé à la figure 7, les informations « Optimized INFO » sont également en partie intégrées dans des règles ATSSS ou « ATSSS rules » (seulement en partie ici pour conserver avantageusement le format des règles ATSSS définies par le standard 3GPP). Des exemples de ces règles sont fournis ci-dessous : Règle ATSSS 1 : interface=3GPP ; application=id ; FF=ATSSS UPF ; NULL_Encryption_Status=Enable ; …. Règle ATSSS 2 : interface=non-3GPP ; application=id ; FF=ATSSS UPF ; NULL_Encryption_Status=Enable ; …. Règle ATSSS 3 : interface=non-3GPP ; application=id ; FF=ATSSS N3IWF ; NULL_Encryption_Status=Disable ; …. Dans ces exemples, les règles ATSSS comprennent chacune un paramètre « interface » identifiant l’interface de réseau d’accès concernée de l’équipement utilisateur UE1, positionné à 3GPP ou non-3GPP ici (on peut toutefois envisager une qualification plus précise indiquant le type de réseau d’accès concerné), un paramètre « application » contenant un identifiant ou un label de l’application de l’équipement utilisateur UE1 à laquelle s’applique la règle, un paramètre « FF » identifiant l’entité FF avec laquelle s’applique la règle, et un paramètre « NULL_Encryption_Status », positionné à Enable ou Disable ici, pour indiquer si la ou les procédures de chiffrement en relation avec les autres paramètres de la règle peuvent être ou non désactivée avec l’entité FF à laquelle s’applique la règle. On note que l'ensemble des paramètres ainsi renseignés dans chaque règle ATSSS permettent à l’équipement utilisateur UE1 de déterminer quelle(s) procédure(s) de chiffrement il est autorisé à désactiver. A titre illustratif, une règle indiquant l’identifiant d’une interface de réseau d’accès « 3GPP » et un identifiant d’une fonction FF (par exemple une fonction UPF au niveau d’une passerelle PGW (pour « Packet data network GateWay » en anglais) avec laquelle l’équipement utilisateur UE1 utilise normalement une procédure de chiffrement au niveau de la couche physique du modèle OSI permet à l’équipement utilisateur UE1 d’identifier qu’il peut désactiver cette procédure de chiffrement avec l’entité PGW/UPF mise en œuvre au niveau de la couche physique. Selon un autre exemple, une autre règle peut indiquer la désactivation possible d’une procédure de chiffrement avec une fonction ATSSS UPF, que l’équipement utilisateur UE1 interprètera comme la possibilité de désactiver la procédure de chiffrement QUIC mise en œuvre lors de l’établissement d’un tunnel avec cette fonction ATSSS UPF. En outre, d’autres paramètres nécessaires à l’établissement des tunnels QUIC avec les entités FF impliquées dans l’acheminement des données entre l’équipement utilisateur UE1 et le serveur distant S1 peuvent être ajoutés à ces règles, comme par exemple un paramètre de sécurité NONCE, etc., ou alors fournis dans le champ « Optimized INFO » comme proposé ici ; - les règles ATSSS et les informations « Optimized INFO » intégrant les informations de contexte de désactivation sont relayées ici à l’étape E50 par l’entité CF1=AMF à l’équipement utilisateur UE1 dans un message « PDU Session Establishment Accept », autorisant l’équipement utilisateur UE1 à bénéficier de l’invention, et lui indiquant les connexions éligibles à la désactivation du chiffrement (caractérisées ici par un paramètre « NULL_Encryption_Status » positionné à Enable). Dans l’exemple envisagé à la figure 7, dès lors qu’une interface d’accès est associée à un paramètre « NULL_Encryption_Status » positionné à Enable pour l’entité ATSSS UPF, l’équipement utilisateur UE1 désactive la procédure de chiffrement QUIC sur chacune des connexions établies avec cette entité (il maintient ici l’établissement des tunnels QUIC avec cette entité). On note toutefois que, comme mentionné précédemment, l’équipement utilisateur UE peut considérer d’autres critères pour sélectionner les connexions sur lesquelles les procédures de chiffrement QUIC (ou d’autres procédures de chiffrement en fonction des règles et des informations de contexte de désactivation qui lui sont fournies) sont désactivées, tout en respectant les contraintes imposées par les règles ATSSS. Ainsi, dans l’exemple de la figure 7, aucun chiffrement supplémentaire n’est mis en place entre l’équipement utilisateur UE1 et l’entité ATSSS UPF lors de l’activation du service ATSSS. Cette optimisation est appliquée pour les trafics entrant et sortant relatifs à l’équipement utilisateur UE1. Variante 2 : La variante 2 est illustrée sur les figures 8 et 9 . Pour mémoire selon cette variante 2, l’équipement utilisateur UE1 négocie préalablement et directement avec chacune des entités FF impliquées dans l’acheminement des données échangées avec le serveur distant S1, la désactivation d’une ou de plusieurs procédures de chiffrement mises en œuvre par l’équipement utilisateur UE1 avec ces entités FF. Cette variante 2, comme la variante 1, peut être envisagée également pour la désactivation de tunnels avec les entités FF. Par souci de simplification, on ne décrit pas en détail ci-après les éléments de la variante 2 qui sont identiques ou similaires aux éléments correspondant de la variante 1 (par exemple les informations de contexte de désactivation, les critères appliqués par l’équipement utilisateur UE1 pour sélectionner les procédures de chiffrement à désactiver, les contextes CNT de connexion créés, etc.). En référence à la figure 8 , on suppose dans la suite de la description que les entités FF1, FF2, …, FFm, « m » désignant un entier supérieur ou égal à 1, sont explicitement configurées (déclarées) dans l’équipement utilisateur UE1, en utilisant par exemple des mécanismes connus de l’homme du métier comme DHCP (pour « Dynamic Host Configuration Protocol » en anglais) ou PCO (pour « Protocol Configuration Option » en anglais). Par exemple, l’équipement utilisateur UE1 peut être configuré avec une ou plusieurs entités FF à utiliser pour accéder à un service donné : dans l’exemple du service ATSSS, il peut être notamment configuré avec les identités (ou identifiants) des entités FF N3IWF, UPF, etc. A partir de cette configuration, l’équipement utilisateur UE1, et notamment son module 7B de sélection, détermine que des chiffrements redondants vont être mis en place pour le traitement des mêmes données, lorsqu’il va établir une communication avec un dispositif distant et identifie les entités FF avec lesquelles ces chiffrements redondants vont être mis en place (étape F10). Par exemple, l’équipement utilisateur UE1 détermine que les entités N3IWF et ATSSS UPF seront sollicitées pour le traitement des mêmes données applicatives lors d’une communication avec un dispositif distant tel que le serveur S1, et que ces données applicatives sont déjà chiffrées, notamment au moyen du protocole QUIC ou TLS. Des critères similaires à ceux indiqués dans la variante 1 peuvent être considérés par le module 7B de sélection. L’équipement utilisateur UE1 active alors son module 7D de négociation pour déclencher une procédure de négociation avec chacune des entités FF ainsi identifiées, en vue de désactiver les procédures de chiffrement mises en œuvre avec ces dernières. Dans la variante 2 telle qu’elle est envisagée ici, cette négociation est déclenchée en amont de la communication, afin de préparer à l’avance les contextes de connexion qui seront utilisés pour l’acheminement des paquets de données via les entités FF. Plus spécifiquement, l’équipement utilisateur UE1 envoie à tout ou partie des entités FF identifiées une requête « Optimized-Configuration-Request » sollicitant l’autorisation de chacune de ces entités FF pour pouvoir désactiver les procédures de chiffrement normalement prévues avec ces entités lors de ses futures communications chiffrées (typiquement ici les procédures de chiffrement liées aux connexions QUIC qu’il va établir avec chacune de ces entités) (étapes F20, F50, F80 pour les entités FF1, FF2 et FFm respectivement). Par souci de simplification, seuls les échanges avec les entités FF1, FF2 et FFm sont représentés sur la figure 8. On note que cette demande peut viser une communication en particulier, ou un ensemble de communications déterminées (par exemple les communications qui seront établies par l’équipement utilisateur UE1 pendant une durée déterminée). Elle peut prendre, à titre illustratif dans le cadre du protocole QUIC, la forme d’une nouvelle trame QUIC appelée par exemple TUNNEL-NULL-ENCRYPTION, comprenant un paramètre « Status » positionné à « Enable » Dans l’exemple illustré sur la figure 8, les entités FF1, FF2,…, FFm sont contactées successivement. L'équipement utilisateur UE1 peut en effet choisir de contacter les entités FF sans ordre particulier, en parallèle ou séquentiellement. En variante, on peut envisager qu’il les contacte dans un ordre spécifique, par exemple selon un ordre de préférence déterminé par le module 7B de sélection lors de la détermination des procédures de chiffrement pouvant être désactivées. Sur réception de la requête « Optimized-Configuration-Request » par une entité FF (par exemple FF1, FF2,…, FFm dans l’exemple de la figure 8), et plus particulièrement par son module 13E de négociation, celui-ci détermine si l’entité FF supporte la procédure d’optimisation requise par l’équipement utilisateur UE1 visant à désactiver la ou les procédures de chiffrement des données émis ou destinés à l’équipement utilisateur UE1 et transitant via cette entité FF, normalement prévues par le standard 3GPP (par exemple les procédures de chiffrement QUIC) (étapes F30, F60 et F90 pour les entités FF1, FF2 et FFm respectivement). Si l’entité FF sollicitée supporte la procédure d’optimisation, autrement dit la désactivation d’au moins une procédure de chiffrement qu’elle met habituellement en place avec l’équipement utilisateur UE1 lors de ses communications chiffrées via le réseau cœur CN, alors elle accepte la requête de l’équipement utilisateur UE1 et lui répond avec un message d’acceptation « Optimized-Configuration-Accept » tel que mentionné précédemment pour la variante 1. On note que l’entité FF peut procéder à des contrôles de sécurité additionnels avant de répondre positivement à l’équipement utilisateur UE1 (par exemple à une authentification). Si l’entité FF sollicitée ne supporte pas la procédure requise par l’équipement utilisateur UE1, elle peut ignorer sa requête ou lui retourner un message d’erreur (par exemple un message « Fail »), comme décrit précédemment pour la variante 1. Dans l’exemple envisagé à la figure 8, l’entité FF1 répond au moyen d’un tel message et rejette la demande d’autorisation de l’équipement utilisateur UE1 (étape F40), tandis que les entités FF2 et FFm répondent positivement à l’équipement utilisateur UE (étapes F70 et F100). L’acceptation par une entité FF de la désactivation de la procédure de chiffrement QUIC avec l’équipement utilisateur UE1 déclenche l’envoi dans le message d’acceptation « Optimized-Configuration-Accept » d’au moins une information « Optimized INFO » de contexte de désactivation telle que mentionnée précédemment. Cette ou ces informations « Optimized INFO » comprennent, comme dans la variante 1, au moins une indication sur au moins une procédure de chiffrement (par exemple la procédure de chiffrement QUIC) pouvant être désactivée par l’équipement utilisateur UE1 avec l’entité FF en question. Une telle indication est par exemple une application de l’équipement utilisateur UE1, un type de connexion (par exemple une connexion QUIC), un réseau d’accès utilisé par l’équipement utilisateur UE1 éligibles à une désactivation d’une procédure de chiffrement avec l’entité FF, ou au moins une procédure de chiffrement spécifique utilisée avec l’entité FF qui peut être désactivée ou au contraire qui ne peut pas être désactivée par l’équipement utilisateur UE1. La ou les informations de contexte de désactivation peuvent également comprendre une clé de sécurité NONCE destinée à être présentée par l’équipement utilisateur UE1 à l’entité FF lorsque l’équipement utilisateur UE1 va établir une connexion avec cette dernière durant laquelle au moins une procédure de chiffrement avec l’entité FF est désactivée. En outre, l’entité FF est configurée pour être en mesure d’établir une connexion (dans l’exemple envisagé du protocole QUIC) ou plus généralement une communication avec l’équipement utilisateur UE1 dans laquelle la ou les procédures de chiffrement sélectionnées par ce dernier sont désactivées et de traiter les paquets de données échangés entre l’équipement utilisateur UE1 et le serveur S1 transitant via l’entité FF. Cette configuration comprend notamment ici la création d’un contexte de connexion CNT(Id(UE1),DESACT) en prévision de cette connexion ou cette communication avec l’équipement utilisateur UE1, destiné à être utilisé par les modules 13A-13C de l’entité FF pour le traitement des paquets transitant par l’entité FF. Le contexte de connexion CNT(Id(UE1), DESACT) est stocké dans une mémoire de l’entité FF (par exemple dans sa mémoire non volatile 11) (étape F110). A la réception des autorisations des entités FF2,…, FFm par son module 7D de négociation, l’équipement utilisateur UE1 extrait du message « Optimized-Configuration-Accept » les informations de contexte de désactivation « Optimized INFO » et les mémorise, par exemple dans sa mémoire non volatile (étape F100). Puis, comme dans la variante 1, l’équipement utilisateur UE1 désactive, par l’intermédiaire de son module 7C de désactivation, la ou les procédures de chiffrement pour lesquelles il a reçu une autorisation des entités FF (étape F120). Autrement dit, lorsque pour l’acheminement des paquets de données échangés lors de sa communication chiffrée avec le serveur S1, il établit des connexions QUIC via son module 7A de communication avec la ou les entités FF du réseau cœur CN associée(s) avec la ou les procédures de chiffrement désactivées ou une connexion avec le serveur S1 via cette ou ces entités FF, ces connexions sont mises en place sans mettre en œuvre cette ou ces procédures de chiffrement avec la ou les entités FF en question (dans l’exemple de la figure 8, les tunnels QUIC sont établis avec chiffrement avec l’entité FF1 (étape F130) et sans chiffrement avec les entités FF2 et FFm (étapes F140, F150)). La figure 9 illustre le résultat des désactivations opérées par l’équipement utilisateur UE dans l’exemple de la figure 8 où les entités FF2, …, FFm ont accepté des désactivations, tandis qu’une telle désactivation a été refusée par l’entité FF1 (par souci de simplification, seules les entités FF1, FF2 et FFm sont représentées sur la figure 9). L’encapsulation et le chiffrement QUIC sont maintenus sur la ou les connexions établies entre l’équipement utilisateur UE et l’entité FF1, tandis que les chiffrements QUIC sont désactivés sur les connexions établies avec les autres entités FF2 ,…, FFm (l’équipement utilisateur UE1 maintient toutefois les tunnels établis avec ces entités dans l’exemple de la figure 9). On note que dans la variante 2 telle qu’elle vient d’être décrite, l’équipement utilisateur UE1 détermine avant d’entamer sa négociation, les entités avec lesquelles il souhaite désactiver une ou plusieurs procédures de chiffrement, puis dès lors que ces entités acceptent une telle désactivation, il désactive par le biais de son module 7C de désactivation les procédures de chiffrement mises en œuvre avec ces entités lorsqu’il établit des connexions avec ces dernières. Dans une adaptation de la variante 2, l’équipement utilisateur UE1 peut procéder à une première sélection des entités FF avec lesquelles il souhaite désactiver une ou plusieurs procédures de chiffrement, déclencher une négociation avec celles-ci comme décrit précédemment, puis à partir des informations de contexte de désactivation « Optimized INFO » reçues de ces dernières, procéder à une deuxième sélection, éventuellement plus réduite, des entités FF avec lesquelles il va effectivement désactiver les procédures de chiffrement lors d’une communication chiffrée avec un dispositif distant. Variante 3 : La variante 3 est illustrée sur les figures 10A et 10B qui représentent respectivement les différentes étapes mises en œuvre dans cette variante 3 par l’équipement utilisateur UE1 et par chaque entité FF sollicitée par l’équipement utilisateur UE1. Pour mémoire selon la variante 3, l’équipement utilisateur UE1 désactive par défaut les procédures de chiffrement avec tout ou partie des entités FF impliquées dans l’acheminement des données échangées avec un dispositif distant lors d’une communication chiffrée avec cet dispositif distant. Par souci de simplification, on ne décrit pas en détail ci-après les éléments de la variante 3 qui sont identiques ou similaires aux éléments correspondants des variantes 1 et/ou 2 (par exemple les informations de contexte de désactivation, les critères appliqués par l’équipement utilisateur UE1 pour sélectionner les procédures de chiffrement à désactiver, etc.). En référence à la figure 10A, comme dans la variante 2, on suppose que des entités FF1, FF2, …, FFm, « m » désignant un entier supérieur ou égal à 1, sont explicitement configurées (déclarées) dans l’équipement utilisateur UE1, en utilisant par exemple des mécanismes connus de l’homme du métier comme DHCP (pour « Dynamic Host Configuration Protocol » en anglais) ou PCO (pour « Protocol Configuration Option » en anglais) et qu’à partir de cette configuration, l’équipement utilisateur UE1 via son module 7B de sélection détermine que des chiffrements redondants vont être mis en place pour le traitement des mêmes paquets de données, lorsqu’il va établir une communication chiffrée avec un dispositif distant comme par exemple le serveur S1, et identifie les entités FF avec lesquelles ces chiffrements redondants vont être mis en place (étape G10). On note que le module 7B de sélection peut opérer une sélection parmi les entités FF ainsi identifiées, selon des critères similaires à ceux qui ont été précédemment décrits en référence aux variantes 1 et 2, ou tenter de désactiver les procédures de chiffrement avec chacune des entités FF identifiées. Pour les entités FF sélectionnées par son module 7B de sélection, l’équipement utilisateur UE1 désactive par défaut via son module 7C de désactivation, les procédures de chiffrement (par exemple les procédures de chiffrement QUIC ici) habituellement mises en œuvre avec ces entités FF lors de l’établissement d’une connexion supportant une communication chiffrée de l’équipement utilisateur UE1 avec un dispositif distant tel que le serveur S1 (étape G20). Dans l’exemple envisagé ici, les tunnels QUIC établis avec ces entités FF sont maintenus. Puis, pour chaque entité FF sélectionnée, l’équipement utilisateur UE1 tente d’établir une connexion (première connexion au sens de l’invention) avec ou via cette entité FF dans laquelle la procédure de chiffrement est désactivée (étape G30). Dans l’exemple envisagé ici de l’utilisation du protocole QUIC pour l’encapsulation des données transitant par l’entité FF en question, l’équipement utilisateur UE1 envoie à cet effet à l’entité FF, via son module 7A de communication, une nouvelle trame QUIC nommée ici « TUNNEL-NULL-ENCRYPTION » ayant un paramètre « Status » positionné à « Enable », nouvellement créée pour les besoins de l’invention. Cette trame QUIC a pour objet de demander à l’entité FF l’établissement d’une connexion avec l’entité FF dans laquelle la procédure de chiffrement prévue par le protocole QUIC est désactivée (formalisé par le paramètre « Status » positionné à « Enable »). En référence à la figure 10B , sur réception de cette trame par l’entité FF (étape H10), et plus particulièrement par son module 13A de communication, celui-ci détermine si l’entité FF accepte la procédure d’optimisation requise par l’équipement utilisateur UE1 visant à désactiver le chiffrement QUIC des données émises ou destinées à l’équipement utilisateur UE1 et transitant via cette entité FF (étape test H20). D’autres procédures de chiffrement peuvent également être désactivées, en complément ou en remplacement du chiffrement QUIC. Si l’entité FF sollicitée supporte et accepte la désactivation du chiffrement proposée par défaut par l’équipement utilisateur UE1 (réponse oui à l’étape test H20), alors elle accepte d’établir la connexion avec l’équipement utilisateur UE1 (étape H30). Le module 13B de désactivation de l’entité FF est alors configuré pour que l’entité FF soit en mesure de traiter les paquets non chiffrés échangés via cette connexion entre l’équipement utilisateur UE1 et le serveur S1 (H40). La connexion sans chiffrement est alors établie entre l’équipement utilisateur UE1 et l’entité FF (étape G50, figure 10A) : il s’ensuit que les données échangées entre l’équipement utilisateur UE1 et le serveur distant S1 transitent via l’entité FF dans un tunnel établi entre l’équipement utilisateur UE1 et l’entité FF sans mettre en œuvre de chiffrement. Si au contraire, l’entité FF sollicitée ne supporte pas, en raison par exemple d’une configuration du réseau cœur CN, la désactivation du chiffrement proposée par l’équipement utilisateur UE1 ou refuse d’établir une connexion avec l’équipement utilisateur UE1 sans appliquer la procédure de chiffrement prévue par le protocole QUIC (réponse non à l’étape H20), alors elle refuse la demande d’établissement d’une connexion sollicitée par l’équipement utilisateur UE1 (étape H50). Dans la variante 3 décrite ici, ce refus est formulé via l’envoi par le module 13A de communication de l’entité FF d’une trame QUIC TUNNEL-NULL-ENCRYPTION ayant le paramètre Status positionné à « Disable », éventuellement complété d’un code expliquant la raison du refus formulé par l’entité FF (par exemple, un seuil d’établissement de tunnels sans chiffrement atteint). Sur réception de la trame TUNNEL-NULL-ENCRYPTION(Status=Disable), l’équipement utilisateur UE1 annule, via son module 7C de désactivation, la désactivation de la procédure de chiffrement QUIC appliquée par défaut lors de la première connexion et tente d’établir une deuxième connexion avec ou via l’entité FF dans laquelle cette procédure de chiffrement est appliquée (étape G60). Si l’entité FF accepte la demande de connexion envoyée par l’équipement utilisateur UE1, la deuxième connexion est établie et les données échangées entre l’équipement utilisateur UE1 et le serveur distant S1 transitent via l’entité FF dans le tunnel chiffré établi entre l’équipement utilisateur UE1 et l’entité FF (étapes G70 et H60). L’équipement utilisateur UE1 procède de la sorte pour chacune des entités FF du réseau cœur CN impliquées dans l’acheminement des paquets de données échangés entre l’équipement utilisateur UE1 et son correspondant (par exemple le serveur S1). On note que bien que les trois variantes aient été décrites distinctement, l’équipement utilisateur UE1 peut être configuré pour mettre en œuvre ces trois variantes de façon combinée, par exemple en fonction des entités FF considérées. En outre, comme mentionné précédemment, bien que ces trois variantes aient été décrites en relation avec la désactivation de procédures de chiffrement, elles peuvent également être appliquées de façon similaire ou identique à la désactivation de procédures d’encapsulation et/ou à la désactivation de procédures de chiffrement et d’encapsulation. Par ailleurs, ces trois variantes ont été illustrées en considérant plus particulièrement la désactivation de la procédure de chiffrement QUIC. Toutefois, comme mentionné précédemment, d’autres procédures de chiffrement, intervenant notamment au niveau d’autres couches du modèle OSI, peuvent être désactivées par l’intermédiaire de l’invention. Par exemple, l’invention est applicable à la désactivation de procédures de chiffrement mises en œuvre au niveau de la couche physique du modèle OSI. A titre illustratif, le chiffrement au niveau de la couche physique du modèle OSI pour l’accès à un réseau 3GPP repose sur le protocole PDCP (pour « Packet data Convergence Protocol » en anglais) décrit notamment dans les documents 3GPP TS 25.323 v16.0.0 ou TS 38.323 v16.1.0. Selon ce protocole, le chiffrement par défaut qui est appliqué s’appuie sur un algorithme tel que EEA2, connu en soi, et sur l’utilisation d’une commande « securityModeCommand » en mode RRC (pour « Radio Resource Control » en anglais). Pour désactiver cette procédure de chiffrement sur une connexion avec une entité FF, on peut par exemple utiliser le mode « NULL » caractéristique des algorithmes EEA0 ou EIA0, et envisager l’exécution par l’équipement utilisateur UE1 du contexte RRC suivant : securityModeCommand-r8 ::= SEQUENCE [0] securityConfigSMC ::= SEQUENCE securityAlgorithmConfig ::= SEQUENCE cipheringAlgorithm ::= ENUMERATED [eea0] integrityProtAlgorithm ::= ENUMERATED [eia0] EXTENSION ::= SEQUENCE nonCriticalExtension ::= SEQUENCE OPTIONAL:Omit Cet exemple n’est toutefois donné qu’à titre illustratif et n’est nullement limitatif de l’invention. Les trois variantes ont également été décrites dans l’hypothèse que la communication chiffrée entre l’équipement utilisateur UE1 et le dispositif distant s’appuient sur l’établissement de connexions entre l’équipement utilisateur UE1, respectivement le dispositif distant, et chacune des entités FF impliquées dans l’acheminement des données échangées entre l’équipement utilisateur UE1 et le dispositif distant. Toutefois comme mentionné à plusieurs reprises, cette hypothèse n’est pas limitative en soi et l’invention est applicable dans d’autres contextes où par exemple les échanges entre l’équipement utilisateur UE1 et les entités FF s’appuient sur une association plutôt qu’une connexion. Procédé de configuration d’un équipement utilisateur (UE1), destiné à être mis en œuvre par ledit équipement utilisateur, et comprenant une étape de désactivation (E80,F120,G20) pour au moins une communication chiffrée dudit équipement utilisateur avec un dispositif distant (S1) via un réseau (CN), d’au moins une procédure de chiffrement sélectionnée par ledit équipement utilisateur et mise en œuvre avec une première entité (FF) du réseau impliquée dans un acheminement de données échangées entre l’équipement utilisateur et le dispositif distant lors de ladite communication chiffrée, lesdites données faisant l’objet d’au moins une autre procédure de chiffrement distincte de ladite au moins une procédure de chiffrement désactivée. Procédé de configuration selon la revendication 1 dans lequel l’étape de désactivation comprend en outre une désactivation d’une procédure d’établissement d’un tunnel avec ladite première entité. Procédé de configuration selon la revendication 1 ou 2 dans lequel ladite au moins une autre procédure de chiffrement est : une procédure de chiffrement mise en œuvre avec une autre entité du réseau impliquée dans l’acheminement desdites données ; et/ou une procédure de chiffrement mise en œuvre sur un réseau utilisé par ledit équipement utilisateur pour échanger lesdites données avec ledit dispositif distant ; et/ou une procédure de chiffrement mise en œuvre avec ledit dispositif distant pour échanger lesdites données. Procédé de configuration selon l’une quelconque des revendications 1 à 3 dans lequel l’étape de désactivation est conditionnée par la réception (E50,F40,F70,F100) d’une autorisation préalable provenant d’une deuxième entité du réseau (CF,FF) et demandée par l’équipement utilisateur. Procédé de configuration selon la revendication 4 comprenant en outre, préalablement à ladite étape de désactivation, une étape de réception, en provenance de ladite deuxième entité du réseau, d’au moins une information (Optimized-INFO) dite de contexte de désactivation fournissant au moins une indication sur au moins une procédure de chiffrement et/ou au moins une procédure d’établissement d’un tunnel pouvant être désactivée(s) par ledit équipement utilisateur. Procédure de configuration selon la revendication 5 dans laquelle ladite au moins une information de contexte de désactivation comprend au moins une indication : - d’au moins une entité du réseau avec laquelle une procédure de chiffrement et/ou une procédure d’établissement d’un tunnel peut être désactivée ; et/ou - d’au moins un type de connexion au cours de laquelle une dite procédure peut être désactivée ; et/ou - d’au moins un réseau d’accès audit réseau pour lequel une dite procédure peut être désactivée. Procédure de configuration selon la revendication 5 ou 6 dans laquelle ladite au moins une information de contexte de désactivation comprend en outre une clé de sécurité destinée à être présentée par ledit équipement utilisateur à ladite première entité du réseau avec laquelle la procédure de chiffrement et/ou la procédure d’établissement d’un tunnel est désactivée. Procédé de configuration selon l’une quelconque des revendications 5 à 7 dans laquelle ladite au moins une procédure de chiffrement et/ou la procédure d’établissement d’un tunnel sélectionnée(s) par ledit équipement utilisateur est (sont) sélectionnée(s) en fonction de ladite au moins une information de contexte de désactivation reçue de la deuxième entité. Procédure de configuration selon l’une quelconque des revendications 1 à 3 comprenant, suite à l’étape de désactivation : une étape (G30) de demande d’établissement d’une première connexion avec ou via la première entité dans laquelle la procédure de chiffrement et/ou la procédure d’établissement d’un tunnel est (sont) désactivée(s) ; en cas de rejet de ladite première connexion par la première entité, une étape (G70) de demande d’établissement d’une deuxième connexion avec ou via la première entité dans laquelle ladite procédure de chiffrement et/ou la procédure d’établissement d’un tunnel est (sont) activée(s) entre l’équipement utilisateur et la première entité. Procédé de négociation entre une entité (CF,FF) d’un réseau (CN), dite deuxième entité, et un équipement utilisateur (UE1) dudit réseau, ledit procédé comprenant : une étape de réception par la deuxième entité d’une demande d’autorisation d’une désactivation par l’équipement utilisateur, pour au moins une communication chiffrée de l’équipement utilisateur avec un dispositif distant via ledit réseau, d’au moins une procédure de chiffrement mise en œuvre avec au moins une entité du réseau, dite première entité, impliquée dans un acheminement de données échangées entre ledit équipement utilisateur et ledit dispositif distant lors de ladite communication chiffrée ; si la demande est acceptée, une étape d’envoi par ladite deuxième entité d’au moins une information dite de contexte de désactivation, destinée audit équipement utilisateur, ladite au moins une information fournissant au moins une indication sur au moins une dite procédure de chiffrement pouvant être désactivée par ledit équipement utilisateur. Procédé de négociation selon la revendication 10 comprenant en outre une étape de configuration (E30) par la deuxième entité (CF) de ladite première entité (FF) pour traiter des données échangées entre ledit équipement utilisateur et ledit dispositif distant lors de ladite communication chiffrée lorsqu’une procédure de chiffrement avec ladite première entité est désactivée par ledit équipement utilisateur. Procédé de gestion d’une connexion d’un équipement utilisateur (UE1) d’un réseau (CN) par une première entité (FF) du réseau impliquée dans un acheminement de données échangées entre ledit équipement utilisateur et un dispositif distant (S1) lors d’une communication chiffrée, ledit procédé de gestion comprenant : une étape (H10) de réception, en provenance de l’équipement utilisateur, d’une demande d’établissement d’une première connexion avec ou via la première entité dans laquelle au moins une procédure de chiffrement entre la première entité et ledit équipement utilisateur, sélectionnée par ledit équipement utilisateur, est désactivée ; si la première entité accepte l’établissement de la première connexion (H30), une étape (H40) de traitement de données échangées, lors de ladite communication chiffrée, entre ledit équipement utilisateur et ledit dispositif distant via ladite première connexion ; sinon (H50), une étape de traitement (H60) de données échangées, lors de ladite communication chiffrée, entre ledit équipement utilisateur et ledit dispositif distant via une deuxième connexion établie par l’équipement utilisateur avec ou via la première entité dans laquelle ladite procédure de chiffrement est activée entre l’équipement utilisateur et la première entité. Procédé selon l’une quelconque des revendications 1 à 12 dans lequel ladite deuxième entité est ladite première entité (FF), ou une entité (CF) de contrôle du réseau apte à configurer ladite première entité pour désactiver ladite procédure de chiffrement ou une autre entité de contrôle du réseau apte à relayer la demande d’autorisation de l’équipement utilisateur vers cette entité de contrôle. Procédé selon l’une quelconque des revendications 1 à 13 dans lequel le protocole QUIC est mis en œuvre lors de ladite communication chiffrée. Equipement utilisateur (UE1) d’un réseau de télécommunications (CN) comprenant un module (7C) de désactivation, configuré pour désactiver, pour au moins une communication chiffrée dudit équipement utilisateur avec un dispositif distant via le réseau, d’au moins une procédure de chiffrement sélectionnée par ledit équipement utilisateur et mise en œuvre avec une première entité du réseau impliquée dans un acheminement de données échangées entre l’équipement utilisateur et le dispositif distant lors de ladite communication chiffrée, lesdites données faisant l’objet d’au moins une autre procédure de chiffrement distincte de ladite au moins une procédure de chiffrement désactivée. Equipement utilisateur selon la revendication 15, dans lequel le module de désactivation est configuré pour désactiver ladite au moins une procédure de chiffrement suite à une autorisation préalable reçue en provenance d’une deuxième entité du réseau demandée par l’équipement utilisateur. Equipement utilisateur selon la revendication 15 comprenant en outre un module de communication (7A) configuré pour : demander un établissement d’une première connexion avec ou via la première entité dans laquelle ladite procédure de chiffrement est désactivée ; en cas de rejet de la première connexion par la première entité, demander un établissement d’une deuxième connexion avec ou via la première entité dans laquelle ladite procédure de chiffrement est activée entre l’équipement utilisateur et la première entité. Entité (CF,FF) d’un réseau, dite deuxième entité, comprenant : une module (14A,13E) de réception, configuré pour traiter une demande d’autorisation d’une désactivation par un équipement utilisateur dudit réseau, pour au moins une communication chiffrée de l’équipement utilisateur avec un dispositif distant via ledit réseau, d’au moins une procédure de chiffrement mise en œuvre avec au moins une entité du réseau, dite première entité, impliquée dans un acheminement de données échangées entre ledit équipement utilisateur et ledit dispositif distant lors de ladite communication chiffrée ; un module d’envoi (14A,13E), activé si la demande est acceptée, et configuré pour envoyer au moins une information dite de contexte de désactivation, destinée audit équipement utilisateur, ladite au moins une information fournissant au moins une indication sur au moins une dite procédure de chiffrement pouvant être désactivée par ledit équipement utilisateur. Entité d’un réseau (FF), dite première entité, susceptible d’être impliquée dans un acheminement de données échangées entre un équipement utilisateur du réseau et un dispositif distant lors d’une communication chiffrée, ladite première entité comprenant : un module de désactivation (13B) configuré pour désactiver, lors de ladite communication chiffrée, une procédure de chiffrement avec l’équipement utilisateur, sélectionnée par ledit équipement utilisateur ; et un module de traitement (13C) configuré pour traiter des données échangées lors de ladite communication chiffrée entre l’équipement utilisateur et le dispositif distant, transitant via la première entité. Première entité d’un réseau selon la revendication 19 comprenant : un premier module de traitement (13A), configuré pour traiter une demande, reçue en provenance de l’équipement utilisateur, d’établissement d’une première connexion avec ou via la première entité dans laquelle au moins une procédure de chiffrement entre la première entité et ledit équipement utilisateur, sélectionnée par ledit équipement utilisateur, est désactivée lors de ladite communication chiffrée ; un deuxième module de traitement (13C), activé si la demande d’établissement est acceptée, et configuré pour traiter des données échangées, lors de la communication chiffrée, entre l’équipement utilisateur et le dispositif distant via ladite première connexion ; et un troisième module de traitement (13C), activé si la demande d’établissement est rejetée, et configuré pour traiter des données échangées, lors de ladite communication chiffrée, entre l’équipement utilisateur et le dispositif distant via une deuxième connexion établie par l’équipement utilisateur dans laquelle ladite procédure de chiffrement est mise en œuvre entre l’équipement utilisateur et la première entité. Système (1) de télécommunications comprenant : au moins un équipement utilisateur (UE1) d’un réseau (CN) selon l’une quelconque des revendications 15 à 17 ; et au moins une entité (CF,FF) du réseau la revendication 18 et/ou une entité (FF) du réseau selon la revendication 19 ou 20.