EP4222994A1 - Procedes de configuration d'un equipement utilisateur, de negociation avec une entite du reseau, et de gestion d'une connexion, et dispositifs associes - Google Patents

Procedes de configuration d'un equipement utilisateur, de negociation avec une entite du reseau, et de gestion d'une connexion, et dispositifs associes

Info

Publication number
EP4222994A1
EP4222994A1 EP21798076.2A EP21798076A EP4222994A1 EP 4222994 A1 EP4222994 A1 EP 4222994A1 EP 21798076 A EP21798076 A EP 21798076A EP 4222994 A1 EP4222994 A1 EP 4222994A1
Authority
EP
European Patent Office
Prior art keywords
user equipment
entity
network
procedure
encryption
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
EP21798076.2A
Other languages
German (de)
English (en)
Inventor
Mohamed Boucadair
Christian Jacquenet
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Orange SA
Original Assignee
Orange SA
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Orange SA filed Critical Orange SA
Publication of EP4222994A1 publication Critical patent/EP4222994A1/fr
Pending legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/03—Protecting confidentiality, e.g. by encryption
    • H04W12/033—Protecting confidentiality, e.g. by encryption of the user plane, e.g. user's traffic
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/20—Network architectures or network communication protocols for network security for managing network security; network security policies in general
    • H04L63/205—Network architectures or network communication protocols for network security for managing network security; network security policies in general involving negotiation or determination of the one or more network security mechanisms to be used, e.g. by negotiation between the client and the server or between peers or by selection according to the capabilities of the entities involved
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/30—Security of mobile devices; Security of mobile applications
    • H04W12/37—Managing security policies for mobile devices or for controlling mobile applications
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/16—Implementing security features at a particular protocol layer
    • H04L63/166—Implementing security features at a particular protocol layer at the transport layer
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/03—Protecting confidentiality, e.g. by encryption
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/03—Protecting confidentiality, e.g. by encryption
    • H04W12/037—Protecting confidentiality, e.g. by encryption of the control plane, e.g. signalling traffic
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/08—Access security
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W76/00—Connection management
    • H04W76/10—Connection setup
    • H04W76/12—Setup of transport tunnels
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W92/00—Interfaces specially adapted for wireless communication networks
    • H04W92/04—Interfaces between hierarchically different network devices
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload

Definitions

  • the invention relates to the general field of telecommunications.
  • the invention relates more particularly to the management of encrypted communications in a telecommunications network.
  • the invention has a preferred application in particular in the context of a 5G telecommunications network as defined by the 3GPP (Third Generation Partnership Project) standard. However, it can also apply within the framework of another network such as a 4G network, a proprietary network, etc.
  • the user equipment of telecommunications networks and in particular terminals such as smart telephones (or “smartphones” in English) or personal computers (or PC for “Personal Computers” in English), are now capable of activating and to exploit several logical interfaces linked to one or more physical interfaces, allowing them to connect simultaneously or not to different types of networks (for example, fixed network, mobile network, wireless LAN) via different IP addresses (for “ Internet Protocol” in English).
  • Such user equipment is called “multi-interface” (or MIF for “Multi-InterFace” in English).
  • MIF characteristic of a user equipment is volatile because its ability to use several interfaces depends on the conditions of connection to the network(s), its location, or still other factors.
  • a MIF user equipment can in particular exploit all or part of the interfaces available to it during the establishment of a simple connection with a correspondent (that is to say established along a single path with this correspondent), or even after establishing a simple connection.
  • a MIF user equipment does not know a priori whether it is possible for it to use several distinct paths to establish communication with a given correspondent: the user equipment only acquires this information if necessary only at the end of a phase during which it attempts to establish communication with the correspondent using multiple paths.
  • a user equipment When a user equipment has several interfaces capable of connecting it to different access networks (for example fixed, mobile, WLAN for "Wireless Local Area Network”) to connect to a core network, it then benefits so-called “hybrid” access, combining different access network technologies.
  • the service offers concerning user equipment with hybrid access are based on the introduction into the core network of functions making it possible to aggregate all the network connections of user equipment (for example: WLAN and 4G, or ADSL, WLAN and 5G).
  • link aggregation consists of grouping together several links associated with several logical interfaces as if it were a single link associated with a single interface, in particular with the aim of increasing the throughput beyond the limits.
  • Link aggregation applies to everything type of traffic carried along these links, including IP traffic.
  • the MPTCP protocol (for "Multi-Path Transmission Control Protocol" in English) was initially proposed to meet the requirements posed by a context where a user device has the ability to connect to a network via several interfaces to establish a communication based on the TCP protocol.
  • the MPTCP protocol responds in particular to the needs of ensuring session continuity transparently for the user in the event of mobility of the user's equipment.
  • the TCP connections of a user equipment are identified by an IP address and a port number, so that any modification of these identification information is likely to penalize the operation of a current TCP connection, and , hence the service using said TCP connection.
  • Such a change of IP address or port number is particularly harmful when the user equipment is assigned a new IP address, or because the user equipment is connected to another network, or even when the interface to which the associated IP address is no longer available.
  • Means for informing the remote TCP correspondent that an IP address is no longer valid are then necessary to ensure the maintenance of an existing connection (for example, in the case of long-lasting TCP connections).
  • the MPTCP protocol was proposed in particular to minimize the risks of untimely breaking of the TCP connections linked to such modifications of the IP addressing.
  • the MPTCP protocol only constitutes a partial solution to the general problem of link aggregation because, by definition, it does not make it possible to establish connections using a transport protocol other than TCP over multiple paths, such as for example the transport protocol UDP (for "User Datagram Protocol” in English) or other transport protocols.
  • UDP for "User Datagram Protocol” in English
  • transport protocols have been proposed, standardized and implemented by the Internet community to meet the needs of applications. For example, some applications require more transport functions than those offered by the TCP and UDP protocols, while others consider that the transport functions offered by TCP or UDP are not (all) necessary given their needs.
  • the transport functions are defined as being the list of services offered by a protocol used to multiplex connections at the level of the transport layer. This list contains, for example, ordered data transmission, reliable data transmission, congestion control, or integrity control.
  • DCCP Datagram Congestion Control Protocol
  • UDP User Datagram Congestion Control Protocol
  • TCP connection-oriented protocol
  • the UDP-lite protocol is a simple version of the UDP protocol which has been proposed for applications which do not require all the functions offered by UDP (such as, for example, integrity checking), while the TLS (for "Transport Layer Security” in English) and DTLS (for "Datagram TLS” in English) protocols have been standardized for the encryption needs of applications at the the transport layer;
  • the QUIC protocol is a protocol which is based on the UDP transport protocol and which aims to reduce the latency times generally observed when establishing TCP connections while avoiding blocking problems (or “Head-of- line blocking”, in English);
  • QUIC encrypts not only the payload data but also the connection control information; the QUIC information sent in clear is limited to the strict minimum, and includes for example the connection identifier.
  • the known solutions relying on the MPTCP protocol and on the assistance of the network are not reusable for the QUIC protocol, since the QUIC traffic cannot be intercepted by the network due to its encryption.
  • the QUIC protocol uses only one path at a time to send the data packets relating to the same connection, which does not meet the needs of the ATSSS functions defined by the 3GPP standard.
  • ATSSS UPF for "User Plane Function”
  • ATSSS UPF located in the operator's 5G network and responsible for associating the data received from the user equipment via the different access networks (in other words, via different paths) and relay them to the remote server.
  • the DI document describes three options using the QUIC protocol as an encapsulation mechanism between the user equipment and the ATSSS UPF function located in the operator's network, for any type of traffic (TCP, UDP, IP, QUIC , etc.).
  • the QUIC connections established between the user equipment and the ATSSS UPF are either simple connections (i.e. each of these connections is established according to the basic QUIC procedure described in the document by J lyendar et al. entitled “QUIC: A UDP-based Multiplexed and Secure Transport”, draft-ietf-quic-transport, May 2020), i.e. connections established according to a new extension to the QUIC protocol defined to support QUIC connections through multiple paths.
  • simple QUIC connections are used, an application function associating the different connections with each other is then necessary.
  • FIG. 1 illustrates the protocol stacks required (and the resulting encapsulation diagrams) at the level of each entity of the aforementioned reference architecture (user equipment UE, N3IWF entities (for “Non-3GPP InterWorking Function”) and operator's 5G network UPF, gNB base station and remote server) for the implementation of the ATSSS UPF function, depending on the access network used by the UE user equipment to connect to the 5G network (network 3GPP access network (or “5G-AN” for 5G Access Network in English) or non-3GPP access network, such as a WLAN network for example).
  • 5G network network 3GPP access network (or “5G-AN” for 5G Access Network in English) or non-3GPP access network, such as a WLAN network for example).
  • an overhead of 142 bytes is observed at least for IPv6 packets sent by user equipment.
  • Such an overhead can cause the transmission of ICMP (Internet Control Message Protocol) PTB (for “Packet Too Big”) messages or the fragmentation of transmitted packets if, for example, the maximum transmission unit or MTU (for "Maximum Transmission Unit” in English) defined for the path taken has not been modified to take into account the overhead induced by the different encapsulations and to avoid the fragmentation of the packets likely to penalize the integrity of the communication .
  • ICMP Internet Control Message Protocol
  • MTU for "Maximum Transmission Unit” in English
  • QUIC packets sent via a 3GPP access network undergo two encryptions in addition to the encryption performed at the radio level, namely, the encryption required between the user equipment and the remote server and the encryption required through the QUIC connection between the user equipment and the ATSSS UPF.
  • QUIC packets sent via a non-3GPP access network undergo an additional third encryption required between the user equipment and the N3IWF, which is responsible for relaying messages received from a non-3GPP access network to the 5G core network.
  • the invention proposes a mechanism which advantageously makes it possible, according to the embodiment envisaged, to remedy all or part of the drawbacks of the prior art previously highlighted in the context of a 5G telecommunications network and to an ATSSS UPF transport function located in the network which makes it possible to manage the multiple communication paths which a MIF user equipment can benefit from in order to communicate with a remote device, whatever the transport protocol used (and in particular, not only TCP).
  • the invention is applicable in other contexts, and in particular to networks other than a 5G network (for example to a 4G network), to functions other than an ATSSS function (for example a TCP/HTTP acceleration function), as well as to other protocols than the QUIC protocol (for example, to the secure protocols TLS, DTLS, IPsec (for “Internet Protocol security” in English)).
  • networks other than a 5G network for example to a 4G network
  • functions other than an ATSSS function for example a TCP/HTTP acceleration function
  • other protocols than the QUIC protocol for example, to the secure protocols TLS, DTLS, IPsec (for “Internet Protocol security” in English).
  • the invention proposes, according to a first aspect, a method for configuring user equipment, intended to be implemented by this user equipment, and comprising a deactivation step, for at least one encrypted communication of the user equipment with a remote device via a network, of at least one encryption procedure selected by the user equipment and implemented with a first entity of the network involved in routing data exchanged between the user equipment and the remote device during the encrypted communication, these data being the subject of at least one other encryption procedure distinct from said at least one deactivated encryption procedure.
  • the invention also relates to user equipment of a telecommunications network comprising a deactivation module, configured to deactivate, for at least one encrypted communication of the user equipment with a remote device via the network, at least one encryption procedure selected by this user equipment and implemented with a first entity of the network involved in routing data exchanged between the user equipment and the remote device during the encrypted communication, these data being the subject of at least one other encryption procedure distinct from said at least one deactivated encryption procedure.
  • a deactivation module configured to deactivate, for at least one encrypted communication of the user equipment with a remote device via the network, at least one encryption procedure selected by this user equipment and implemented with a first entity of the network involved in routing data exchanged between the user equipment and the remote device during the encrypted communication, these data being the subject of at least one other encryption procedure distinct from said at least one deactivated encryption procedure.
  • encryption procedure is used here to designate both encryption and decryption operations implemented between the user equipment and the first entity.
  • deactivation of an encryption procedure at the level of the user equipment obviously results in a deactivation of the corresponding decryption procedure at the level of the first entity, and vice versa in the case of two-way communications between the user equipment and the first entity.
  • the user equipment can be a terminal, fixed or mobile, such as for example a personal computer or a "smartphone", capable of connecting to the network via one or more access networks or even a CPE type equipment (for “Customer Premises Equipment” in English) connected to the network via at least one access network, etc.
  • the remote device can designate any endpoint of the communication with the user equipment, such as for example a server, hosted by the network or by another network, or another user equipment, etc. No assumption is made on the structure of this remote equipment which can be either hardware or software.
  • the invention offers the possibility for user equipment to decide on its own initiative whether it is appropriate to deactivate during its communications with remote devices via the network, one or more encryption procedures implemented during the routing of the data exchanged with these remote devices.
  • This deactivation is possible provided that at least one alternative encryption procedure exists to protect the data exchanged with the remote device, this procedure being able to be applied at any level of the layers of the OSI model (for "Open Systems Interconnection" in English) (physical layer, transport, application, etc.).
  • this alternative encryption procedure can be:
  • an encryption procedure implemented on a network used by the user equipment to exchange said data with the remote device, such as for example on an access network;
  • the user equipment can in this way deactivate all or part of the redundant encryption procedures implemented in the network, while preserving the security of its communications, that of the core network (or core network), but also of the remote device.
  • This deactivation makes it possible to save the resources of the user equipment (for the processing necessary for the encryption/decryption of the data). This results in an optimization of the overall performance of the user equipment and communications (via in particular the optimization of the load of the intermediate equipment).
  • the user equipment which selects the encryption procedures to be deactivated.
  • This selection can be made according to various information, which may in particular come from the network (transmitted for example to the user equipment in the form of rules or in any other form), and in particular from the entities involved in the routing of the data themselves. themselves (sometimes hereinafter referred to as “entities or transport functions”) or entities capable of controlling and configuring these entities (sometimes hereinafter referred to as “entities or control functions”).
  • entities or transport functions entities capable of controlling and configuring these entities
  • entities or control functions entities capable of controlling and configuring these entities
  • the invention therefore advantageously makes it possible to optimize the encapsulation procedures typically implemented in a 3GPP network and which lead to the establishment of tunnels.
  • the establishment of tunnels makes explicit reference to such encapsulation procedures.
  • the deactivation step can also include deactivation of a procedure for establishing a tunnel with the first entity.
  • This deactivation of the establishment of a tunnel with the first entity can be decided by the user equipment as soon as the routing of the data involves this first entity (concept of engineering or traffic management (or " traffic steering", in English)). This may be the case in particular when a tunnel responsible for routing the data so that they pass through this first entity already exists, or when the routing of the data via the first entity is ensured by routing options at the source, where the source transmitting the data has the ability to explicitly indicate the entity or entities through which the data must pass (for example “Segment Routing”).
  • the deactivation of one or more encapsulation procedures leading to the establishment of a tunnel also makes it possible to reduce the overhead induced by the encapsulation of the data which borrows these tunnels as well as the time required to establish these tunnels. Also, this embodiment contributes to the optimization of the overall performance of the user equipment and of the communications (for example by avoiding the fragmentation of the packets).
  • the deactivation of a procedure for establishing a tunnel can be decided by the user equipment with an entity distinct from the first entity with which it has decided to deactivate encryption procedure.
  • the deactivation of encryption procedure(s) and the deactivation of tunnel establishment procedure(s) are not mutually exclusive, they can also be decided by the user equipment independently and on separate connections.
  • the invention generally allows the user equipment to control the level of security that it wishes to associate with encrypted communication with a remote device. For example, depending on the reputation of the access network that he wishes to use during this encrypted communication, he can decide whether or not to deactivate one or more redundant encryption procedures during this encrypted communication.
  • the invention applies to any type of transport function involved in the routing of data between user equipment and a remote device, it has a preferred application in the previously introduced context of functions managing the aggregation of links, such as for example the ATSSS UPF function defined by the 3GPP standard, and the use of secure protocols based on protocols other than the TCP protocol (for example UDP or QUIC). Applied in this context, the invention in fact makes it possible to envisage functional parity between the TCP and UDP protocols for the management of communications established on multiple paths.
  • the step of deactivating said at least one encryption procedure and/or establishing a tunnel is conditioned by the receipt of a prior authorization from a second entity of the network, and requested by the user equipment.
  • the deactivation module is configured to deactivate said at least one encryption procedure following prior authorization received from a second network entity and requested by the user equipment.
  • the second entity of the network requested by the user equipment can be for example the first entity with which the user equipment wishes to deactivate the encryption procedure and/or the procedure for establishing a tunnel, or a network control capable of configuring the first entity to deactivate this encryption procedure and/or this procedure for establishing a tunnel, or yet another network control entity capable of relaying the authorization request from the user equipment to this control entity.
  • the deactivation of the encryption procedure and/or of the procedure for establishing a tunnel follows prior negotiation with the network, at the initiative of the user equipment.
  • Solicitation of the user equipment for authorization from the network can take place at various times, for example when attaching the user equipment to the network, activating a network session, at regular intervals, on explicit activation of the user or of an application via a dedicated interface or API (for "Application Programming Interface"), etc.
  • the authorization can be explicit or implicit, aiming at an encryption procedure and/or a procedure for establishing a particular tunnel or, on the contrary, consist of more general rules provided by the network concerning the encryption procedures and /or establishment of a tunnel which can be deactivated by the user equipment with network transport functions during its communications.
  • This embodiment allows the network operator to retain control over the procedures that can be deactivated, in particular in order to maintain the security of its network and/or to satisfy certain operator policies. In addition, this allows coordination of user equipment with the network.
  • the operator can thus control the management of these communications, and preserve the security of the network by preventing the ATSSS service from being used by unauthorized user equipment.
  • coordination with the network simplifies the use of QUIC clients.
  • the configuration method comprises, prior to the deactivation step, a step of receiving, from the second entity of the network, at least one piece of information called deactivation context (of encryption procedure(s) and/or of procedure(s) for establishing tunnel(s)) providing at least one indication of at least one encryption procedure and/or of at least one procedure for establishing a tunnel that can be deactivated by the user equipment.
  • deactivation context of encryption procedure(s) and/or of procedure(s) for establishing tunnel(s)
  • said at least one piece of deactivation context information may comprise at least one indication:
  • At least one network entity with which an encryption procedure and/or a procedure for establishing a tunnel can be deactivated for example an ATSSS UPF function
  • At least one type of connection during which such a procedure can be deactivated for example a QUIC connection used to establish a secure tunnel or an IPsec tunnel established with the remote device
  • At least one access network to said network for which such a procedure can be deactivated for example a 3GPP access network.
  • the network can also provide the user equipment with indications concerning the encryption and/or establishment of a tunnel procedures which cannot be deactivated.
  • the deactivation context information provided by the second network entity to the user equipment can for example be integrated into rules (such as the ATSSS rules defined in the 3GPP standard), each rule being able to specify several elements to which the rule applies, such as in particular the nature of the access network interface (for example 3GPP or non-3GPP), the identifier of the application, the first network entity (for example ATSSS UPF entity), the possibility or not of deactivating the encryption procedure and/or the procedure for establishing a tunnel implementation with this first network entity, etc.
  • rules such as the ATSSS rules defined in the 3GPP standard
  • each rule being able to specify several elements to which the rule applies, such as in particular the nature of the access network interface (for example 3GPP or non-3GPP), the identifier of the application, the first network entity (for example ATSSS UPF entity), the possibility or not of deactivating the encryption procedure and/or the procedure for establishing a tunnel implementation with this first network entity, etc.
  • rules such as the ATSSS rules defined in the 3
  • the deactivation context information may comprise a security key intended to be presented by the user equipment to the first entity of the network with which the encryption procedure and/or the procedure for establishing 'a tunnel is disabled.
  • Such a security key allows the first entity to carry out security checks with the user equipment and in particular to ensure that the latter is indeed authorized by the network to deactivate the procedure or procedures in question.
  • the verification key is presented only when establishing a connection with or via the first entity.
  • said at least one encryption procedure and/or procedure for establishing a tunnel selected by the user equipment is (are) selected as a function of said at least one least one deactivation context information received from the second entity.
  • the deactivation of the encryption procedure and/or of the procedure for establishing a tunnel selection born(s) by the user equipment follows a negotiation beforehand with the network.
  • the user equipment deactivates by default an encryption procedure and/or a procedure for establishing a tunnel to communicate with the remote device via the first entity, and according to the response of the first entity , adapts this mode of operation if necessary by restoring the encryption procedure and/or the procedure for establishing a tunnel deactivated by default.
  • said user equipment further comprises a communication module configured to:
  • the rejection of the first connection by the first entity can take. It can be for example an error message, a refusal message, etc. If the first connection is accepted by the first entity, then the user equipment continues to use this first connection to transmit its data via the first entity to the remote device, in other words, the unencrypted connection (possibly carried out via an unencrypted tunnel ) and established with or through the first entity.
  • prior negotiation with the network and deactivation by default are not mutually exclusive: the user equipment can, for certain transport functions, set up negotiation with the network while with others, disable encryption and/or encapsulation procedures by default.
  • the invention offers great flexibility depending on the context in which it is applied.
  • the invention relies on the user equipment, but also on the first and second entities of the network.
  • the invention relates to a method of negotiation between an entity of a network, called the second entity, and a user equipment of said network, said method comprising:
  • - a step of reception by the second entity of a request for authorization of deactivation by the user equipment, for at least one encrypted communication of the user equipment with a remote device via said network, of at least one encryption procedure implemented with at least one entity of the network, called first entity, involved in routing data exchanged between said user equipment and said remote device during said encrypted communication; - if the request is accepted, a step of sending by said second entity at least one piece of information called deactivation context, intended for said user equipment, said at least one piece of information providing at least one indication on at least one said procedure of encryption that can be disabled by said user equipment.
  • the invention also relates to an entity of a network, called the second entity, comprising:
  • reception module configured to process a request for authorization of deactivation by a user equipment of said network, for at least one encrypted communication of the user equipment with a remote device via said network, of at least one procedure encryption implemented with at least one entity of the network, called first entity, involved in routing data exchanged between said user equipment and said remote device during said encrypted communication;
  • a sending module activated if the request is accepted, and configured to send at least one piece of information called deactivation context, intended for said user equipment, said at least one piece of information providing at least one indication on at least one said procedure of encryption that can be disabled by said user equipment.
  • the negotiation method further comprises a configuration step by the second entity of the first entity of the network to process data exchanged between the user equipment and the remote device during the encrypted communication when an encryption procedure with the first entity is disabled by the user equipment.
  • the second entity further comprises a configuration module, programmed to configure the first entity of the network to process data exchanged between said user equipment and said remote device during said encrypted communication when an encryption procedure with said first entity is disabled by said user equipment.
  • the authorization request may also relate to a procedure for establishing a tunnel with the first entity as described previously, and if necessary, said at least one deactivation context information item comprises at least one indication on a so-called procedure for establishing a tunnel that can be deactivated and the configuration module of the second entity be able to configure the first entity so that it is able to process data passing through it without being encapsulated to be routed through this tunnel.
  • the invention relates to a method for managing a connection of user equipment of a network by a first entity of the network, this first entity being involved in routing data exchanged between the user equipment and a remote device during an encrypted communication, this management method comprising:
  • - a step of receiving, from the user equipment, a request to establish a first connection with or via the first entity in which at least one encryption procedure between the first entity and said user equipment, selected by said user equipment, is deactivated;
  • a step of processing data exchanged, during said encrypted communication, between said user equipment and said remote device via said first connection - otherwise, a step of processing data exchanged, during the encrypted communication, between the user equipment and the remote device via a second connection established by the user equipment with or via the first entity in which said encryption procedure is activated between the user equipment and the first entity.
  • the acceptance of the second connection can be explicit or implicit since the first entity does not reject this second connection and processes the data exchanged via this second connection.
  • the step of processing the data exchanged via the second connection entails the acceptance of the second connection by the first entity.
  • the invention also targets a network entity, called the first entity, likely to be involved in the routing of data exchanged between network user equipment and a remote device during an encrypted communication, this first entity comprising:
  • deactivation module configured to deactivate, during said encrypted communication, an encryption procedure with the user equipment, selected by said user equipment
  • a processing module configured to process data exchanged, during said encrypted communication, between the user equipment and the remote device and passing through the first entity.
  • the first entity comprises:
  • a first processing module configured to process a request, received from the user equipment, to establish a first connection with or via the first entity in which at least one encryption procedure between the first entity and said user equipment, selected by said user equipment, is deactivated during said encrypted communication;
  • a second processing module activated if the establishment request is accepted, and configured to process data exchanged, during the encrypted communication, between the user equipment and the remote device via said first connection;
  • a third processing module activated if the establishment request is rejected, and configured to process data exchanged, during said encrypted communication, between the user equipment and the remote device via a second connection established by the user equipment wherein said encryption procedure is implemented between the user equipment and the first entity.
  • the user equipment can also decide to deactivate during the first connection a procedure for establishing a tunnel with the first entity, in which case the second processing module of the first entity is, if the request to establish the first connection is accepted, configured to process data that is not encapsulated according to said disabled procedure. If the request to establish the first connection is rejected, then the user equipment establishes a second connection in which the encryption procedure and/or the procedure for establishing a tunnel with the first entity is (are) re-established( s).
  • the configuration, negotiation and management methods are implemented by a computer.
  • the invention also relates to a computer program on a recording medium, this program being able to be implemented in a computer or more generally in user equipment in accordance with the invention and comprises instructions adapted to the implementation of a configuration method as described below above.
  • the invention also relates, according to a fourth aspect, to a computer program on a recording medium, this program being able to be implemented in a computer or more generally in a “first” entity of the network in accordance with the invention and comprises instructions adapted to the implementation of a method for managing a connection as described above.
  • the invention also relates to a computer program on a recording medium, this program being able to be implemented in a computer or more generally in a "second" entity of the network in accordance with the invention and includes instructions adapted to the implementation of a negotiation process as described above.
  • Each of these programs may use any programming language, and be in the form of source code, object code, or intermediate code between source code and object code, such as in partially compiled form, or in any other desirable shape.
  • the invention also relates to an information medium or a recording medium readable by a computer, and comprising instructions of a computer program as mentioned above.
  • the information or recording medium can be any entity or device capable of storing the programs.
  • the medium may comprise a storage means, such as a ROM, for example a CD ROM or a microelectronic circuit ROM, or else a magnetic recording means, for example a hard disk, or a flash memory.
  • the information or recording medium can be a transmissible medium such as an electrical or optical signal, which can be routed via an electrical or optical cable, by radio link, by optical link without wire or by other means.
  • the program according to the invention can in particular be downloaded from an Internet-type network.
  • the information or recording medium may be an integrated circuit in which a program is incorporated, the circuit being adapted to execute or to be used in the execution of the supply and obtaining methods according to the 'invention.
  • the invention also relates to a telecommunications system comprising at least one user equipment of a network according to the invention and at least a first and/or a second entity of the network according to the invention.
  • the negotiation method, the management method, the first and second entities and the telecommunications system benefit from the same advantages mentioned above as the configuration method and the user equipment according to the invention.
  • the configuration method, the negotiation method, the management method, the user equipment, the first and second entities and the telecommunications system according to invention have all or part of the aforementioned characteristics in combination.
  • FIG. 1 already described, represents the protocol stacks implemented at the level of user equipment and of various entities of a network for supporting the ATSSS service defined by the 3GPP standard;
  • FIG. 2 represents, in its environment, a telecommunications system according to the invention in a particular embodiment
  • FIG. 3 represents the hardware architecture of a user equipment of the telecommunications system of FIG. 2, in accordance with the invention, in a particular embodiment;
  • FIG. 4 represents the hardware architecture of an FF (for "Forwarding Function” in English) entity hosting a transport function and/or of a CF (for "Control Function” in English) entity for controlling such an entity, in accordance with the invention, in a particular embodiment;
  • FF Forwarding Function
  • CF Control Function
  • FIG. 5 Figure 5A illustrates the establishment of tunnels between the user equipment UE and various FF entities in the prior art, while Figures 5B and 5C illustrate an example implementation of the invention
  • FIGS. 6A and 6B represent respectively the steps implemented by a user equipment, an entity hosting a transport function and one, respectively several, control entities in a first variant of the invention (variant 1);
  • FIG. 7 illustrates an example of application of the first variant of the invention in the context of an ATSSS service defined by the 3GPP standard
  • FIG. 8 represent the steps implemented by a user equipment and several FF entities hosting a transport function in a second variant of the invention (variant 2);
  • FIG. 9 illustrates an example of the result of the application of the second variant
  • FIGS. 10A and 10B represent, in the form of flowcharts, the various steps implemented by a user equipment and by an entity FF hosting a transport function in a third variant of the invention (variant 3).
  • Figure 2 shows, in its environment, a telecommunications system 1 according to the invention, in a particular embodiment.
  • the system 1 comprises at least one user equipment UE1, in accordance with the invention, and having taken out a subscription with an operator OP of a telecommunications network NW to benefit services offered by this network.
  • the user equipment UE1 is for example here a terminal such as a smartphone.
  • it may be another type of terminal (for example a personal computer or PC), or equipment of the CPE type to which one or more terminals can be connected via a local network.
  • the network NW of the operator OP is a 5G network based on a core network or core network CN.
  • the user equipment UE1 can use two access networks AN1 and AN2 to connect to the core network CN (it can be connected simultaneously or not to these two networks access): the access network AN1 is a 3GPP access network managed by the operator OP (in other words, a trusted network or TAN for "Trusted Access Network” in English), while the network of access AN2 is an access network managed by another administrative entity than the operator OP (and therefore considered as an “untrusted” network (or UAN for “Untrusted Access Network”), such as for example a WLAN network
  • the access network AN1 is a 3GPP access network managed by the operator OP (in other words, a trusted network or TAN for "Trusted Access Network" in English)
  • the network of access AN2 is an access network managed by another administrative entity than the operator OP (and therefore considered as an “untrusted” network (or UAN for “Untrusted Access Network”), such as for example a WLAN network
  • UAN for “Untrusted Access Network”
  • mechanisms are put in place to secure access to the services offered by the CN core network but also to protect the CN core network from attacks from sources external to the CN network.
  • Other security mechanisms are put in place within the core network CN to protect it from attacks whose sources would be located inside the network.
  • These security mechanisms are also intended to prevent the intermediate networks from accessing the sensitive data transported by the data flows exchanged between a user equipment (such as the user equipment UE) and the core network CN or with a remote server via said CN core network.
  • the core network CN comprises several functional entities, also referred to as "functions" in support of the services provided by the network NW.
  • an entity or a function of the core network CN can designate either a physical device (for example a server, a router) or a software function (for example a virtual machine).
  • the CN core network notably comprises an AGW entity (for "Access Gateway” in English) as defined by the 3GPP standard, used to control access to the core network CN from a UAN access network, and various entities or functions generally referenced by FF (for "Forwarding Functions"), and involved in routing data traffic via the CN core network.
  • AGW entity for "Access Gateway” in English
  • FF for "Forwarding Functions”
  • No assumption is made as to the termination of a connection by such an FF entity; the invention also applies to FF entities embedding proxy functions which relay connections.
  • Examples of AGW entity and FF entity are respectively the N3IWF and ATSSS UPF functions mentioned previously.
  • Another example of an FF entity is a router. It is noted that the AGW entity can integrate an FF entity involved in the routing of the data passing through the core network CN in addition to its function of controlling access to the core network.
  • the FF entities are also used for the connection of the core network CN to third-party networks, such as the Internet network for example.
  • the routing of traffic sent or intended for user equipment connected to the core network CN may involve one or more entities FF of the core network CN.
  • No assumption is made as to the location of the remote device with which the user equipment UE1 exchanges traffic: it may be equipment such as a server, located in the core network CN or connected to the core network CN (for example the server SI in Figure 2) or in another network such as for example in the Internet network (for example the servers S2, S3, ..., Sn in FIG. 2, “n” denoting an integer), or even of another user device connected or not to the core network CN (not represented in FIG. 2).
  • no assumption is made as to the software and physical structure (hardware) of this remote device.
  • the remote device can be dedicated equipment or a software instance.
  • the network CN also includes so-called control entities CF (for “Control Functions”), responsible for controlling one or more entities FF and/or one or more user equipment items.
  • control entities CF for “Control Functions”
  • Examples of such control entities in the context of a 5G 3GPP network such as the CN core network are Access and Mobility Management Functions (AMFs), session management or SMF (for "Session Management Function” in English), policy control PCF (for "Policy Control Function” in English).
  • AMFs Access and Mobility Management Functions
  • SMF Session Management Function
  • PCF policy control Function
  • No assumption is made here as to the structuring of the CF control entities (interconnection, hierarchy, functional capacities, etc.).
  • the same physical element (or node) of the core network CN can host FF and CF entities.
  • the invention offers the possibility for the user equipment UE1 to deactivate all or part of the encryption and/or establishment of tunnels procedures implemented with network entities involved in the routing of the traffic intended for or sent by the user equipment UE1.
  • Variants 1 and 2 prior negotiation takes place with the network before deactivation one or more encryption procedures by the user equipment UE1 with one or more entities FF; in variant 1, the negotiation takes place with the CF control entities managing this or these FF entities, while in variant 2, the negotiation takes place with the FF entity or entities directly;
  • Variant 3 deactivation is implemented by default by the user equipment UE without prior negotiation with the network.
  • deactivation of one or more procedures for establishing a tunnel in addition to or replacing the encryption procedures.
  • the deactivation of encryption procedures and procedures for establishing a tunnel are not mutually exclusive and can be decided jointly by the user equipment UE1, or on the contrary independently.
  • the user equipment UE1 has the hardware architecture of a computer as represented in FIG. 3. It comprises in particular a processor 2, a random access memory 3, a read only memory 4, a non-volatile memory 5, and communication means 6 comprising in particular various physical and protocol interfaces allowing the user equipment UE1 to connect to the access networks allowing it to access the core network CN, namely here the access networks AN1 and AN2. Such interfaces are known per se and not described in detail.
  • the read only memory 4 constitutes a recording medium in accordance with the invention, readable by the processor 2 and on which is recorded a computer program in accordance with the invention, namely a computer program PROG-UE (l) for variant 1, PROG-UE(2) for variant 2, and PROG-UE(3) for variant 3.
  • PROG-UE(1), PROG-UE(2) and PROG-UE(3) define functional modules of the user equipment UE1 which rely on or control the hardware elements 2 to 6 mentioned above. These modules include in particular, in the three variant embodiments considered here, as shown in Figure 2:
  • the encrypted communication between the user equipment UE1 and the remote device may require the establishment of a plurality of connections between the user equipment UE1, respectively the remote device, and each of the FF entities involved in traffic routing (for example for the QUIC protocol).
  • This encrypted communication can also, as a variant, be based on associations between the user equipment UE1 and each of the entities FF (for example, for the IPsec protocol);
  • a selection module 7B configured to select one or more encryption procedures implemented with these FF entities and which can be deactivated during encrypted communication. It is noted that a prerequisite for being able to deactivate an encryption procedure applied to the data exchanged during the communication is the existence of another encryption procedure protecting this data (at least the payload data). Furthermore, according to the variant embodiment envisaged, the selection module 7B can select the encryption procedure or procedures to be deactivated according to information coming from the network as described further below; and
  • a deactivation module 7C configured to deactivate the encryption procedure(s) selected by the selection module 7B.
  • the PROG-UE(1) and PROG-UE(2) programs also define another functional module of the user equipment UE1 activated during the implementation of variants 1 and 2, namely a 7D module of negotiation with the network (represented in dashed lines in FIG. 2) configured to request from the network a prior authorization to deactivate one or more encryption procedures.
  • This negotiation module 7D is configured in variant 1 to negotiate with a CN core network control CF entity while in variant 2, it is configured to negotiate directly with the FF entity or entities involved in the routing of the data exchanged between the user equipment UE and its correspondent.
  • the PROG-UE(3) program defines the modules 7A-7C so that the procedure(s) encryption selected by the selection module 7B are deactivated by default by the deactivation module 7C when establishing the connection with the remote device transiting via the entity or entities FF concerned. For each FF entity, module 7A is then configured for:
  • the first connection is either the connection established with the remote device to support encrypted communication, or a connection established with the FF entity required for the data exchanged between the user equipment UE1 and the remote device to be routed via this FF entity);
  • the entities FF and CF of the telecommunications system 1 also have the hardware architecture of a computer as represented in FIG. 4. When two entities FF and CF are collocated, they can of course share this architecture.
  • Each entity CF or FF notably comprises a processor 8, a random access memory 9, a read only memory 10, a non-volatile memory 11, and communication means 12 enabling them to communicate in particular with other entities of the core network CN or other networks.
  • the ROM 10 constitutes a recording medium in accordance with the invention, readable by the processor 8 and on which is recorded, for the FF entities, a computer program PROG-FF(1) for variant 1 , PROG-FF(2) for variant 2, and PROG-FF(3) for variant 3, and for the CF entities, a computer program PROF-CF(1) for variant 1.
  • the variants 2 and 3 described here, the CF functions of the NW network comply with the 3GPP standard.
  • PROG-FF(1), PROG-FF(2) and PROG-FF(3) define functional modules of an FF entity in accordance with the invention which rely on or control the hardware elements 8 to 12 cited above.
  • These functional modules of the FF entity include, as shown in Figure 2:
  • a communication module 13A configured to communicate with the user equipment UE1 during an encrypted communication of this user equipment UE1 with a remote device (for example the server SI).
  • the communication between the module 13A and the user equipment UE1 can be based on the establishment of one or more connections (corresponding to multiple paths) between the module 13A and the user equipment UE1, on an association, etc. ., depending on the context of application of the invention;
  • deactivation module 13B configured to deactivate on the initiative of the user equipment UE1 one or more encryption procedures implemented by the communication module 13A with the user equipment UE1 during the encrypted communication transiting via the entity FF;
  • processing module 13C configured to process data exchanged during this encrypted communication between the two devices via the entity FF, whether or not these data are the subject of an encryption procedure between the user device UE1 and the entity FF.
  • the processing module 13C is configured in particular so, when an encryption procedure is deactivated in accordance with the invention, to be able to process the data passing through the entity FF (in other words, to no longer apply the corresponding decryption procedure to the deactivated encryption procedure, and to no longer encrypt the data packets that it receives from the remote device and sends to the user equipment UE1).
  • additional modules or a different configuration of the modules 13A-13C can be defined by the programs PROG-FF(1), PROG-FF(2) and PROG-FF(3).
  • the program PROG-FF(l) further defines a second communication module 13D (represented in dashed lines in Figure 2) configured to interact with the CF entity controlling the FF entity in order to create a connection context used by the modules 13A-13C during the encrypted communication of the user equipment UE1 in which, on the latter's initiative, an encryption procedure is deactivated with the FF entity and processes the data passing through the FF entity.
  • a second communication module 13D represented in dashed lines in Figure 2
  • an encryption procedure is deactivated with the FF entity and processes the data passing through the FF entity.
  • the second communication module 13D is also configured to transmit to the CF entity at least one piece of so-called deactivation context information, denoted here "Optimized -IN FO", intended for the user equipment UE1 and providing the latter with at least one indication of at least one encryption procedure that can be deactivated with the FF entity.
  • deactivation context information denoted here "Optimized -IN FO”
  • This or these deactivation context information(s) are then used by the selection module 7B of the user equipment UE1 to select an encryption procedure to be deactivated.
  • the program PROG-FF(2) defines a negotiation module 13E (shown in broken lines in FIG. 2) configured to interact with the user equipment UE1 directly (and in particular with its negotiation module 7D): the negotiation module 13E is configured to receive and process a request for authorization of deactivation by the user equipment UE of at least one encryption procedure implemented with the entity FF, and if the authorization request is accepted, to send to the user equipment UE1, at least one deactivation context information “Optimized-INFO” as mentioned previously in the variant 1.
  • the negotiation module 13E is also configured here to create, if the request from the user equipment UE is accepted, a connection context aimed at allowing the communication module 13A to manage the c encrypted communication from the user equipment UE in which an encryption procedure with the entity FF, selected by the user equipment UE in accordance with the “Optimized-INFO” information or information, is deactivated by the deactivation module 13B, and the module 13C to process the corresponding data.
  • the entity FF has the means of a second entity within the meaning of the invention.
  • the module 13A is configured to process a request received from the user equipment UE1 to establish a first connection with or via the entity FF in which at least one procedure encryption between the user equipment UE1 and the entity FF, selected by the user equipment UE1, is deactivated during encrypted communication between the user equipment UE and the remote device (for example the SI server).
  • the deactivation module 13B is configured to deactivate said encryption procedure, and the module 13C is activated to process the data exchanged between the user equipment UE1 and the remote device, passing through the entity FF via the first connection.
  • the module 13C is activated to process the data exchanged between the user equipment UE1 and the remote device, passing through the entity FF, via a second connection established between the user equipment UE1 and the remote device, in which said encryption procedure with the FF entity is maintained and implemented.
  • the program PROG-CF(l) defines functional modules of a CF entity in accordance with the invention (second entity within the meaning of the invention) managing an FF entity as mentioned above. above for variant 1, these functional modules relying on or controlling the hardware elements 8 to 12 mentioned above.
  • the functional modules of the CF entity include here in particular, as illustrated in Figure 2:
  • a negotiation module 14A configured to: receive a request for authorization of deactivation by the user equipment UE1, for at least one encrypted communication from the user equipment UE1 with a remote device (for example SI) via the core network CN, at least one encryption procedure implemented with an entity FF involved in routing data exchanged between the user equipment UE1 and the remote device during the encrypted communication; and sending, if the request is accepted, at least one “Optimized-INFO” deactivation context information item, as mentioned previously, intended for the user equipment UE1; and
  • a configuration module 14B activated if the FF entity in question is under the control of the CF entity, and programmed to configure this FF entity so that it is able to communicate with the user equipment UE1 while the or the encryption procedures selected by the latter are deactivated, and thus process the data exchanged between the user equipment UE1 and the remote device passing through it.
  • the configuration module 14B interacts with the second communication module 13D of the entity FF with a view to creating a connection context used by the modules 13A-13C as indicated previously.
  • the configuration module 14B receives from the second communication module 13D of the entity FF, during this interaction, the aforementioned deactivation context information “Optimized-INFO” intended for the user equipment UE1.
  • the program PROG-CF(1) further defines a communication module 14C of the entity CF with at least one other control entity CF, which is activated if the authorization request received of the user equipment UE1 relates to entities FF which are not managed directly by the entity CF. Indeed, in this case, the communication module 14C relays the authorization request from the user equipment UE1 to the control entity or entities CF concerned and relays the responses received from this or these control entities CF to the equipment user UE1.
  • modules 13A-13E of the FF entities and 14A-14C of the CF entities are explained in more detail later for each of the variant embodiments envisaged.
  • the QUIC protocol not only encrypts the application data (also referred to as “useful data”) exchanged between the user equipment UE1 and the server SI, but also the connection control information with the exception a limited number of them, such as the connection identifier.
  • the application data exchanged between the user equipment UE1 and the server SI may or may not be encrypted by another encryption procedure (for example applied at the level of the physical layer).
  • the data exchanged between the user equipment UE1 and the server SI pass through a plurality of entities FF of the telecommunications system 1, involved in the routing of these data in the CN core network.
  • at least one connection is established between the user equipment UE1 and each entity FF via which passes the data exchanged between the user equipment UE1 and the server SI (the invention applies to a simple connection such as a multi-path connection), and the QUIC protocol is used to perform the encapsulation and encryption of the data passing through each connection, as recommended in the solutions proposed by the 3GPP standard, mentioned above, to provide a service ATSSS to any type of traffic (carried by any type of transport protocols, TCP or not).
  • FIG. 5A The application of this encapsulation mode to each entity FF traversed by the data packets is illustrated in FIG. 5A for three entities FF1, FF2 and FF3. It results in the establishment of at least three tunnels (i.e. three encapsulation schemes) and the implementation of at least four encryption procedures by the user equipment UE1 linked to the use of the QUIC protocol between the user equipment UE1 and the server SI on the one hand, and between the user equipment UE1 and each of the entities FF1, FF2 and FF3 on the other hand. It is noted that between the user equipment UE1 and the first entity FF1 traversed, the three tunnels, respectively the four ciphers, are nested one inside the other leading to a correspondingly greater overhead.
  • an IPsec/ESP tunnel (and therefore an additional encapsulation) (for "Encapsulating Security Payload” in English) (not represented in FIG. 5A) can be added between the user equipment UE1 and the AGW entity if the access network used by the user equipment UE1 to access the core network CN is a non-3GPP network, considered to be unreliable (UAN network). Note that what has just been described for the user equipment UE1 also applies to the server SI.
  • a protocol other than QUIC can be used between the user equipment UE1 and the server SI, such as for example TCP, UDP, etc., and/or to establish secure tunnels between the user equipment UE1 and each of the entities FF of the network through which pass the data exchanged between the user equipment UE1 and the server SI, such as for example the protocols TLS, DTLS, IPsec, etc.
  • the communications between the user equipment UE1 and each entity FF involved in the routing of the data can be based on an association rather than on a dedicated connection (for example when the IPsec protocol is used), etc.
  • Variant 1 is illustrated in FIGS. 6 and 7.
  • the user equipment UE1 negotiates beforehand with the core network CN and more particularly with the control entities CF, the deactivation of one or several encryption procedures implemented by the user equipment UE1 with the entities FF managed by these control entities, and involved in the routing of the data exchanged between the user equipment UE1 and the server SI.
  • the entities FF1, FF2 and FF3 involved in the routing of the data exchanged between the user equipment UE1 and the server SI during their encrypted communication are managed by the same entity CFI control.
  • each entity FF is managed by a different control entity: it is then implemented by the user equipment UE1 with each control entity, or with an entity dedicated control unit which acts as a relay between the user equipment UE1 and the control entities managing the entities FF, as illustrated in FIG. 6B (cf. relay steps E10b and E40b).
  • the negotiation can be initiated by the user equipment UE1 via its negotiation module 7D at any time, for example when attaching the user equipment UE1 to the core network CN, when activating a network session, at regular intervals, upon explicit activation by the user of the user equipment UE1, upon activation by an application (for example by the ATSSS application embedded in the user equipment UE1) via a dedicated API, etc.
  • the user equipment UE1 requests authorization from the network by sending an authorization request to the CFI control entity to deactivate at least one encryption procedure with at least least one entity FF involved in the routing of data during the encrypted communication established by the user equipment UE1 with the server SI (entities FF1, FF2 and FF3 in the example considered) (step E10).
  • This authorization request here takes the form of a request named “Optimized-Configuration-Request” intended for the CFI entity.
  • the “Optimized-Configuration-Request” authorization request may explicitly specify the entities FF1, FF2 and FF3 targeted by the user equipment UE1 or, alternatively, it may be a more general authorization request aimed at knowing the FF entities of the network involved in the routing of the data being able to whether or not affected by such deactivation. It is noted that the user equipment UE1 has been configured beforehand with information allowing it to identify which control entity to request to obtain such authorization, in a manner known per se and not described here. The request can however pass through other entities (for example through an AGW entity) before reaching the CFI destination entity.
  • the “Optimized-Configuration-Request” request is ignored by the CFI entity or an error message (for example a “Fail” message) is returned to the user equipment UE1.
  • the user equipment UE1 is then configured here not to resend such a request before the expiry of a determined period, typically 24 hours, to allow it to detect a change in the configuration of the core network CN.
  • the “Optimized-Configuration-Request” request is then processed here by the CFI entity and in particular by its module 14A negotiation and its configuration module 14B. As a variant, it can be relayed by the communication module 14C of the entity CFI to another entity CF for processing, for example to the entity CF2 as illustrated in FIG. 6B.
  • the entity CFI (respectively CF2 in the example illustrated in FIG. 6B) checks whether the user equipment UE is authorized (i.e. enabled) to send such a request, for example by implementing an identification/authentication procedure for the user equipment UE, known per se and not described here (step E20).
  • the CFI entity determines that the user equipment UE is authorized to request such a procedure (as assumed here)
  • the CFI entity (respectively CF2) via its configuration module 14B then interacts with the entities FF likely to be involved in the routing of the data exchanged between the user equipment UE and the server SI, namely here with the entities FF1, FF2 and FF3 (step E30).
  • the entities FF likely to be involved in the routing of the data exchanged between the user equipment UE and the server SI, namely here with the entities FF1, FF2 and FF3
  • This interaction consists here of sending a control message, called for example "FF-Control", by the CFI entity to the FF1 entity (and more particularly to its communication module 13D) aimed at configure the latter so that it is able to establish a connection with the user equipment UE1 in which one or more encryption procedures selected by the latter are deactivated, and process the data exchanged between the user equipment UE1 and the remote device passing through this connection.
  • This control message informs the entity FF1 that it must set up such a deactivation for the user equipment UE1, upon request from the latter, and thus contribute to optimizing the switching performance of the user equipment UE1.
  • the "FF-Control" message triggers in the variant described here, at the level of the FF1 entity, the creation of a context CNT(Id(UEl), DESACT) associated with an identifier Id(UEl) of the user equipment UE1 (for example to an IP address allocated to this user equipment UE1 by the network), in anticipation of such a connection with the user equipment UE1 (or established directly with the entity FF1 within the framework of the use of the QUIC protocol envisaged for illustrative purposes here, or established with the remote server SI via the FF1 entity, if an association between the FF1 entity and the user equipment UE1 is sufficient for the processing by the FF1 entity of the data of the user equipment UE1 (for example, presentation of a NONCE security key) ).
  • the “DESACT” field explicitly indicates that, during this connection, if the user equipment UE1 so chooses, at least one encryption procedure with the entity FF1, chosen by the user equipment UE1, will be deactivated.
  • the context CNT(Id(UE1), DESACT) is intended to be used by the modules 13A-13C of the entity FF1 for the processing of the data passing through the entity FF1 during this connection. It is stored in a memory of the entity FF1 (for example in its non-volatile memory 11).
  • the entity FF1 determines under which conditions (that is to say in which context) it is able to set up such a deactivation with the user equipment UE1 (for example, for which access network(s) or which application(s), which encryption procedure(s), with or without presentation of a security token, etc.).
  • the entity FF1 then acknowledges, via its communication module 13D, the “FF-Control” message by sending an acknowledgment message ACK to the entity CFI (respectively CF2) (step E40).
  • the acknowledgment message ACK here comprises at least one information “Optimized INFO” deactivation context, as mentioned previously, reflecting the conditions thus determined by the entity FF1.
  • This or these “Optimized INFO” information(s) thus include in particular at least one indication of at least one encryption procedure that can be deactivated by said user equipment at the level of the entity FF1.
  • Such an indication is for example an application supported by the user equipment UE (for example, the ATSSS application), a type of connection (for example a QUIC connection), an access network used by the user equipment eligible for deactivation of an encryption procedure with the FF1 entity, or at least one specific encryption procedure used with the FF1 entity which can be deactivated (for example the QUIC encryption procedure associated with the tunnel set up between the equipment user UE1 and the function FF1) or on the contrary which cannot be deactivated by the user equipment UE1.
  • an application supported by the user equipment UE for example, the ATSSS application
  • a type of connection for example a QUIC connection
  • an access network used by the user equipment eligible for deactivation of an encryption procedure with the FF1 entity for example the QUIC encryption procedure associated with the tunnel set up between the equipment user UE1 and the function FF1
  • at least one specific encryption procedure used with the FF1 entity which can be deactivated for example the QUIC encryption procedure associated with the tunnel set up between the equipment user
  • the deactivation context information(s) transmitted in the acknowledgment message can also include a security key named NONCE here, intended to be presented by the user equipment UE1 to the entity FF1 when the user equipment UE1 is going to establish a connection with the latter (or via the latter, if the transport protocol considered for routing the data does not require the establishment of a connection between the user equipment UE1 and the entity FF1) during which at least one encryption procedure with the FF1 entity is disabled.
  • This NONCE security key is intended to allow the FF1 entity to carry out security checks when a user equipment tries to establish a connection with it (or via the FF1 entity in the context mentioned above) to which one or more commonly implemented encryption procedures are disabled by the user equipment in question.
  • the entity CFI proceeds with the entities FF2 and FF3 as has just been described for the entity FF1 (parallel or successively). If control entities distinct from the CFI entity (for example the CF2 entity) are involved in these exchanges, they relay to the CFI entity the acknowledgment messages received from the entities FF1 to FF3. Then, the CFI entity responds positively to the authorization request from the user equipment UE1 by means of a response message named here “Optimized-Configuration-Accept” sent to the user equipment UE1 via its module 14A negotiation (step E50).
  • the “Optimized-Configuration-Accept” response message includes the “Optimized INFO” deactivation context information provided by each of the FF entities requested (FF1, FF2 and FF3 in the example considered here).
  • the information provided by each of the requested entities FF is aggregated and provided as is to the user equipment UE1 in the “Optimized-Configuration-Accept” message.
  • they can be processed by the entity CFI before being communicated to the user equipment UE1, for example being synthesized in the form of rules, etc.
  • the user equipment UE1 On receipt of the authorization from the CFI entity by its negotiation module 7D, the user equipment UE1 extracts from the “Optimized-Configuration-Accept” message the deactivation context information “Optimized INFO” and stores it , for example in its non-volatile memory (step E60).
  • This “Optimized INFO” deactivation context information is then used by the user equipment selection module 7B UE to identify the communications (in other words the connections in the example of the QUIC protocol considered here) eligible for deactivation of one or more encryption procedures applied to the data exchanged during its encrypted communication with the server SI via an entity FF.
  • the selection of these communications can be based on the selection of the interfaces eligible for the deactivation of one or more encryption procedures.
  • the selection module 7B chooses (“selects”) one or more encryption procedures from among the encryption procedures implemented in the communications identified as eligible according to at least one determined selection criterion (step E70).
  • the user equipment UE1 ensures in particular that on the communication(s) concerned by a deactivation of an encryption procedure, the data transmitted remain protected despite this deactivation by at least least one other encryption procedure.
  • This other encryption procedure is for example:
  • an encryption procedure implemented with another entity of the network involved in the routing of said data for example, the user equipment UE1 can decide to deactivate the encryption procedure implemented with the entity FF1 as soon as the data packets exchanged with the server SI are protected by another encryption procedure implemented with the entity FF2 and/or the entity FF3); and or
  • an encryption procedure implemented on an access network to the core network CN used by the user equipment UE1 to exchange data packets with the server SI for example an encryption procedure implemented when establishing an IPsec tunnel between the user equipment UE1 and an N3IWF function when the access network is considered as UAN;
  • an encryption procedure implemented with the server SI to exchange data packets for example, the encryption procedure of the QUIC protocol when this protocol is used between the user equipment UE1 and the server SI).
  • the user equipment UE1 deactivates, via its deactivation module 7C, the encryption procedure(s) selected by its selection module 7B (step E80).
  • the user equipment UE1 deactivates, via its deactivation module 7C, the encryption procedure(s) selected by its selection module 7B (step E80).
  • the user equipment UE1 deactivates, via its deactivation module 7C, the encryption procedure(s) selected by its selection module 7B (step E80).
  • the user equipment UE1 deactivates, via its deactivation module 7C, the encryption procedure(s) selected by its selection module 7B (step E80).
  • Figures 5B and 5C illustrate examples, to be compared with the state of the art illustrated in Figure 5A, in which respectively:
  • the user equipment UE1 can process the connections established on each of the paths as illustrated respectively in Figures 5B and 5C.
  • FIGS. 5A, 5B and 5C The advantages provided by the invention therefore appear clearly with regard to FIGS. 5A, 5B and 5C, in terms of optimizing the complexity of the processing implemented when establishing connections with or via the various FF entities .
  • the invention can also be applied in a similar way to the deactivation of tunnels between the user equipment UE1 and the various FF entities, the prerequisite for deactivating a procedure for establishing a tunnel with an FF entity being the assurance of data routing via this FF entity, for example via source routing options, or by using another tunnel.
  • other criteria can be considered to decide der of the deactivation of a tunnel, such as the overhead generated by the encapsulation required to establish this tunnel, the latency induced by the establishment of this tunnel, etc.
  • the deactivation of a tunnel between the user equipment UE1 and a given FF entity can be concomitant with or, on the contrary, independent of the deactivation of a corresponding encryption procedure (for example when the tunnel in question is a secure tunnel).
  • FIG. 7 illustrates an example of implementation of variant 1 of the invention for the ATSSS service defined by the 3GPP standard in combination with the use of the QUIC protocol to establish a secure tunnel between the user equipment UE1 and the entities FF involved in the routing of the data exchanged between the user equipment UE1 and the server SI.
  • two entities FF1 and FF2 are considered respectively constituted by an entity UPF and an entity NW3IF, and two entities CFI and CF2 constituted respectively by an entity AMF and by an entity SMF.
  • the UPF, N3IWF, AMF and SMF entities have the characteristics defined in the 3GPP standard (for example in document TS 23.501 introduced previously). They are further configured here to implement the invention according to variant 1, as well as the messages conventionally exchanged between these entities.
  • steps E10 to E80 of variant 1 are implemented as previously described, considering the following elements:
  • This message includes in particular a “PDU Session ID” identifier of the session as well as a “MA PDU” parameter indicating that the session uses multiple paths (established by the user equipment UE1 for example via the access networks AN1 and AN2 ).
  • the “PDU Session Establishment Request” message is moreover modified here so as to integrate a new field named “Optimized-QUIC”, reflecting the authorization request requested by the user equipment UE1.
  • the “FF-Control” configuration message sent by the CF2 entity to the FF1 entity takes the form here of an “N4 Session Establishment” message defined by the 3GPP standard in which is inserted a new “Optimized-connection” field as described previously to inform the FF1 entity of the equipment request UE1 user;
  • the “Optimized INFO” information is also partly integrated into ATSSS rules or “ATSSS rules” (only partly here to advantageously preserve the format of the ATSSS rules defined by the 3GPP standard). Examples of these rules are provided below:
  • the ATSSS rules each include an "interface" parameter identifying the relevant access network interface of the user equipment UE1, set to 3GPP or non-3GPP here (however, a more precise qualification indicating the type of access network concerned), an "application” parameter containing an identifier or a label of the application of the user equipment UE1 to which the rule applies, an "FF” parameter identifying the FF entity with which applies the rule, and a "NULL_Encryption_Status” parameter, set to Enable or Disable here, to indicate whether the encryption procedure(s) in relation to the other rule parameters can be disabled or not with the FF entity to which the rule applies.
  • each ATSSS rule allow the user equipment UE1 to determine which encryption procedure(s) it is authorized to deactivate.
  • a rule indicating the identifier of a “3GPP” access network interface and an identifier of an FF function for example a UPF function at the level of a PGW gateway (for “Packet data network Gateway » in English) with which the user equipment UE1 normally uses an encryption procedure at the level of the physical layer of the OSI model allows the user equipment UE1 to identify that it can deactivate this encryption procedure with the PGW entity /UPF implemented at the physical layer level.
  • another rule can indicate the possible deactivation of an encryption procedure with an ATSSS UPF function, which the user equipment UE1 will interpret as the possibility of deactivating the QUIC encryption procedure implemented when establishing a tunnel with this ATSSS UPF
  • other parameters necessary for establishing QUIC tunnels with the FF entities involved d in the routing of data between
  • the user equipment UE1 deactivates the QUIC encryption procedure on each of the connections established with this entity (here it maintains the establishment of QUIC tunnels with this entity). Note however that, as mentioned above, the user equipment UE can consider other criteria to select the connections on which the QUIC encryption procedures (or other encryption procedures depending on the rules and the deactivation context information provided to it) are deactivated, while respecting the constraints imposed by the ATSSS rules. Thus, in the example of FIG. 7, no additional encryption is put in place between the user equipment UE1 and the ATSSS entity UPF during the activation of the ATSSS service. This optimization is applied for the incoming and outgoing traffic relating to the user equipment UE1.
  • Variant 2 is illustrated in Figures 8 and 9.
  • the user equipment UE1 negotiates beforehand and directly with each of the entities FF involved in the routing of the data exchanged with the remote server SI, the deactivation of one or more encryption procedures implemented by the user equipment UE1 with these entities FF.
  • This variant 2 like variant 1, can also be envisaged for the deactivation of tunnels with the FF entities.
  • variant 2 which are identical or similar to the corresponding elements of variant 1 are not described in detail below (for example the deactivation context information, the criteria applied by the user equipment UE1 to select the encryption procedures to be deactivated, the connection CNT contexts created, etc.).
  • the user equipment UE1 can be configured with one or more FF entities to be used to access a given service: in the example of the ATSSS service, it can in particular be configured with the identities (or identifiers) of the FF entities N3IWF , UPF, etc.
  • the user equipment UE1 determines that redundant ciphers will be implemented for the processing of the same data, when it establishes communication with a device remote and identifies the FF entities with which these redundant ciphers will be implemented (step F10). For example, the user equipment UE1 determines that the N3IWF and ATSSS UPF entities will be requested to process the same application data during communication with a remote device such as the SI server, and that this application data is already encrypted, in particular by means of the QUIC or TLS protocol. Criteria similar to those indicated in variant 1 can be considered by the selection module 7B.
  • the user equipment UE1 then activates its negotiation module 7D to trigger a negotiation procedure with each of the entities FF thus identified, with a view to deactivating the encryption procedures implemented with the latter.
  • this negotiation is triggered upstream of the communication, in order to prepare in advance the connection contexts which will be used for routing the data packets via the FF entities.
  • the user equipment UE1 sends to all or part of the identified FF entities an “Optimized-Configuration-Request” request requesting the authorization of each of these FF entities in order to be able to deactivate the encryption procedures normally provided with these entities during its future encrypted communications (typically here the encryption procedures linked to the QUIC connections that it will establish with each of these entities) (steps F20, F50, F80 for the entities FF1, FF2 and FFm respectively).
  • this request may target a particular communication, or a set of determined communications (for example the communications which will be established by the user equipment UE1 for a determined duration). It can take, by way of illustration within the framework of the QUIC protocol, the form of a new QUIC frame called for example TUNNEL-NULL-ENCRYPTION, comprising a "Status" parameter set to "Enable”.
  • the entities FF1, FF2,..., FFm are contacted successively.
  • the user equipment UE1 can in fact choose to contact the entities FF in no particular order, in parallel or sequentially.
  • an FF entity for example FF1, FF2,..., FFm in the example of FIG. 8
  • the latter determines whether the FF entity supports the optimization procedure required by the user equipment UE1 aimed at deactivating the encryption procedure(s) for the data transmitted or intended for the user equipment UE1 and transiting via this FF entity, normally provided for by the 3GPP standard (for example the QUIC encryption procedures) (steps F30, F60 and F90 for the entities FF1, FF2 and FFm respectively).
  • the requested FF entity supports the optimization procedure, in other words the deactivation of at least one encryption procedure that it usually puts in place with the user equipment UE1 during its encrypted communications via the core network CN, then it accepts the request from the user equipment UE1 and responds to it with an “Optimized-Configuration-Accept” acceptance message as mentioned previously for variant 1. It is noted that the entity FF can carry out checks additional security measures before responding positively to the user equipment UE1 (for example to an authentication).
  • the requested FF entity does not support the procedure required by the user equipment UE1, it can ignore its request or return an error message to it (for example a “Fail” message), as described previously for variant 1.
  • the entity FF1 responds by means of such a message and rejects the authorization request from the user equipment UE1 (step F40), while the entities FF2 and FFm respond positively to the user equipment UE (steps F70 and F100).
  • the acceptance by an entity FF of the deactivation of the QUIC encryption procedure with the user equipment UE1 triggers the sending in the “Optimized-Configuration-Accept” acceptance message of at least one item of information “Optimized INFO” of deactivation context as mentioned previously.
  • This or these “Optimized INFO” information(s) comprise, as in variant 1, at least one indication of at least one encryption procedure (for example the QUIC encryption procedure) that can be deactivated by the user equipment UE1 with the entity FF in question.
  • Such an indication is for example an application of the user equipment UE1, a type of connection (for example a QUIC connection), an access network used by the user equipment UE1 eligible for deactivation of an encryption procedure with the entity FF, or at least one specific encryption procedure used with the entity FF which can be deactivated or on the contrary which cannot be deactivated by the user equipment UE1.
  • the deactivation context information(s) can also comprise a NONCE security key intended to be presented by the user equipment UE1 to the entity FF when the user equipment UE1 will establish a connection with the latter during which at least one procedure encryption with the FF entity is disabled.
  • the entity FF is configured to be able to establish a connection (in the considered example of the QUIC protocol) or more generally a communication with the user equipment UE1 in which the encryption procedure(s) selected by the latter are deactivated and to process the data packets exchanged between the user equipment UE1 and the server SI transiting via the entity FF.
  • This configuration includes in particular here the creation of a connection context CNT(Id(UEl),DESACT) in anticipation of this connection or this communication with the user equipment UE1, intended to be used by the modules 13A-13C of the FF entity for processing packets passing through the FF entity.
  • the connection context CNT(Id(UE1), DESACT) is stored in a memory of the entity FF (for example in its non-volatile memory 11) (step F1 10).
  • the user equipment UE1 Upon receipt of the authorizations from the entities FF2,..., FFm by its negotiation module 7D, the user equipment UE1 extracts from the message "Optimized-Configuration-Accept” the deactivation context information "Optimized INFO" and stores them, for example in its non-volatile memory (step F100).
  • the user equipment UE1 deactivates, via its deactivation module 7C, the encryption procedure(s) for which it has received authorization from the entities FF (step F120).
  • the user equipment UE1 when for routing the data packets exchanged during its encrypted communication with the server SI, it establishes QUIC connections via its communication module 7A with the entity or entities FF of the core network CN associated with the or encryption procedures disabled or a connection with the SI server via this or these FF entities, these connections are set up without implementing this or these encryption procedures with the FF entity or entities in question (in the example of figure 8, the QUIC tunnels are established with encryption with the entity FF1 (step F130) and without encryption with the entities FF2 and FFm (steps F140, F150)).
  • FIG. 9 illustrates the result of the deactivations operated by the user equipment UE in the example of FIG. 8 where the entities FF2, FFm have accepted deactivations, while such a deactivation has been refused by the entity FF1 (for the sake of simplification, only the entities FF1, FF2 and FFm are represented in figure 9).
  • QUIC encapsulation and encryption are maintained on the connection(s) established between the user equipment UE and the FF1 entity, while the QUIC encryptions are deactivated on the connections established with the other FF2 entities FFm (the user equipment UE1 however maintains the tunnels established with these entities in the example of Figure 9).
  • the user equipment UE1 determines before starting its negotiation, the entities with which it wishes to deactivate one or more encryption procedures, then from then on that these entities accept such deactivation, it deactivates through its deactivation module 7C the encryption procedures implemented with these entities when it establishes connections with the latter.
  • the user equipment UE1 can carry out a first selection of the FF entities with which it wishes to deactivate one or more encryption procedures, trigger a negotiation with them as described above, then from the information of “Optimized INFO” deactivation context received from the latter, proceed to a second selection, possibly smaller, of the FF entities with which it will effectively deactivate the encryption procedures during an encrypted communication with a remote device.
  • Variant 3 is illustrated in FIGS. 10A and 10B which respectively represent the various steps implemented in this variant 3 by the user equipment UE1 and by each entity FF requested by the user equipment UE1.
  • the user equipment UE1 deactivates by default the encryption procedures with all or part of the entities FF involved in the routing of the data exchanged with a remote device during an encrypted communication with this remote device.
  • the elements of variant 3 which are identical or similar to the corresponding elements of variants 1 and/or 2 (for example the deactivation context information, the criteria applied by the user equipment UE1 to select the encryption procedures to be deactivated, etc.).
  • the user equipment UE1 deactivates by default via its deactivation module 7C, the encryption procedures (for example the QUIC encryption procedures here) usually implemented with these entities FF when establishing a connection supporting encrypted communication from the user equipment UE1 with a remote device such as the server SI (step G20).
  • the encryption procedures for example the QUIC encryption procedures here
  • the QUIC tunnels established with these FF entities are maintained.
  • the user equipment UE1 attempts to establish a connection (first connection within the meaning of the invention) with or via this FF entity in which the encryption procedure is deactivated (step G30) .
  • the user equipment UE1 sends for this purpose to the FF entity, via its communication module 7A, a new QUIC frame here named “TUNNEL-NULL-ENCRYPTION” having a “Status” parameter set to “Enable”, newly created for the purposes of the invention.
  • the purpose of this QUIC frame is to request the FF entity to establish a connection with the FF entity in which the encryption procedure provided for by the QUIC protocol is deactivated (formalized by the "Status" parameter set to "Enable ").
  • the FF entity upon receipt of this frame by the FF entity (step H 10), and more particularly by its communication module 13A, the latter determines whether the FF entity accepts the procedure of optimization required by the user equipment UE1 aimed at deactivating the QUIC encryption of the data transmitted or intended for the user equipment UE1 and transiting via this entity FF (test step H20).
  • Other encryption procedures can also be disabled, in addition to or in place of QUIC encryption.
  • the requested FF entity supports and accepts the deactivation of the encryption proposed by default by the user equipment UE1 (answer yes to the test step H20), then it accepts to establish the connection with the user equipment UE1 (step H30).
  • the FF entity deactivation module 13B is then configured so that the FF entity is able to process the unencrypted packets exchanged via this connection between the user equipment UE1 and the server SI (H40).
  • the connection without encryption is then established between the user equipment UE1 and the entity FF (step G50, FIG. 10A): it follows that the data exchanged between the user equipment UE1 and the remote server SI pass via the entity FF in a tunnel established between the user equipment UE1 and the entity FF without implementing encryption.
  • the requested entity FF does not support, for example because of a configuration of the core network CN, the deactivation of the encryption proposed by the user equipment UE1 or refuses to establish a connection with the user equipment UE1 without applying the encryption procedure provided by the QUIC protocol (answer no to step H20), then it refuses the request to establish a connection requested by the user equipment UE1 (step H50).
  • this refusal is formulated via the sending by the communication module 13A of the entity FF of a QUIC frame TUNNEL-NULL-ENCRYPTION having the Status parameter set to "Disable”, possibly completed with a code explaining the reason for the refusal formulated by the FF entity (for example, a threshold for establishing tunnels without encryption reached).
  • the FF entity accepts the connection request sent by the user equipment UE1, the second connection is established and the data exchanged between the user equipment UE1 and the remote server SI pass via the FF entity in the tunnel cipher established between the user equipment UE1 and the entity FF (steps G70 and H60).
  • the user equipment UE1 proceeds in this way for each of the entities FF of the core network CN involved in the routing of the data packets exchanged between the user equipment UE1 and its correspondent (for example the server SI).
  • the user equipment UE1 can be configured to implement these three variants in a combined manner, for example according to the entities FF considered.
  • the invention is applicable to the deactivation of encryption procedures implemented at the level of the physical layer of the OSI model.
  • the encryption at the level of the physical layer of the OSI model for access to a 3GPP network is based on the PDCP protocol (for "Packet data Convergence Protocol" in English) described in particular in the documents 3GPP TS 25.323 V16.0.0 or TS 38.323 V16.1.0.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

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.

Description

Description
Titre de l'invention : 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
Technique antérieure
[0001] L'invention se rapporte au domaine général des télécommunications.
[0002] 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.
[0003] 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).
[0004] 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.
[0005] 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.
[0006] 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.
[0007] 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.
[0008] 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é.
[0009] 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.
[0010] 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).
[0011] 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.
[0012] 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.
[0013] 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 DI). Dans ce document DI, 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.
[0014] Le document DI 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. lyendar et al. intitulé « QUIC: A UDP-based Multiplexed and Secure Transport », draft-ietf-quic-trans- port, 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.
[0015] Les trois options discutées actuellement par le 3GPP souffrent toutefois des inconvénients suivants.
[0016] 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).
[0017] 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.
[0018] 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.
[0019] 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.
Exposé de l'invention
[0020] 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)).
[0021] 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.
[0022] 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.
[0023] 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é.
[0024] 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.
[0025] 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.
[0026] 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).
[0027] 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.
[0028] 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.
[0029] 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é.
[0030] 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 »).
[0031] 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).
[0032] 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.
[0033] 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.
[0034] 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.
[0035] 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.
[0036] 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.
[0037] 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.
[0038] 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.
[0039] 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.
[0040] 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.
[0041] 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.
[0042] 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.
[0043] 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.
[0044] 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).
[0045] 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.
[0046] 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.
[0047] 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.
[0048] 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é.
[0049] 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é.
[0050] 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.
[0051] 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élection né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.
[0052] 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é.
[0053] 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é.
[0054] 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é.
[0055] 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.
[0056] 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.
[0057] 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.
[0058] 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.
[0059] 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.
[0060] 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.
[0061] 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.
[0062] 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é.
[0063] 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é.
[0064] 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é.
[0065] 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é.
[0066] 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).
[0067] 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.
[0068] 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.
[0069] 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.
[0070] 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.
[0071] 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.
[0072] 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.
[0073] 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.
[0074] 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.
[0075] Le programme selon l'invention peut être en particulier téléchargé sur un réseau de type Internet.
[0076] 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.
[0077] 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.
[0078] 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.
[0079] 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.
Brève description des dessins
[0080] 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 :
[Fig. 1] 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 ;
[Fig. 2] 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 ;
[Fig. 3] 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 ;
[Fig. 4] 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 ;
[Fig. 5] 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 ;
[Fig. 6] 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) ;
[Fig. 7] 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 ;
[Fig. 8] 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) ;
[Fig. 9] la figure 9 illustre un exemple de résultat de l'application de la deuxième variante ;
[Fig. 10] 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
[0081] 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.
[0082] 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.
[0083] 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.
[0084] 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.
[0085] 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.
[0086] 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).
[0087] 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.
[0088] 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.
[0089] 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 SI 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.
[0090] 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).
[0091] 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.
[0092] 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.
[0093] 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.
[0094] 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.
[0095] 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.
[0096] 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(l) pour la variante 1, PROG-UE(2) pour la variante 2, et PROG-UE(3) pour la variante 3.
[0097] Les programmes PROG-UE(l), 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 SI) 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.
[0098] Les programmes PROG-UE(l) 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.
[0099] 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.
[0100] Le fonctionnement des modules 7A à 7D est expliqué plus en détail ultérieurement pour chacune des variantes de réalisation envisagées.
[0101] 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 colo- calisées, elles peuvent bien entendu partager cette architecture.
[0102] 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.
[0103] 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(l) 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(l) 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.
[0104] Les programmes PROG-FF(l), 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 SI). 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).
[0105] 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).
[0106] 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(l) 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 -IN FO », 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.
[0107] 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.
[0108] 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 SI).
[0109] 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.
[0110] 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.
[OUI] Dans la variante 1, le programme PROG-CF(l) 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 SI) 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(l) 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.
[0112] 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.
[0113] 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.
[0114] 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 SI. 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.).
[0115] 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 SI. 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 SI, 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 SI peuvent être ou non chiffrées par une autre procédure de chiffrement (par exemple appliquée au niveau de la couche physique).
[0116] 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 SI 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 SI (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).
[0117] 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 SI 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 SI.
[0118] 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 SI, 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 SI, 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. [0119] Nous allons maintenant décrire dans ce contexte chacune des variantes de réalisation. [0120] Variante 1 :
[0121] 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 SI. 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 SI lors de leur communication chiffrée sont gérées par une même entité de contrôle CFI. 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 ElOb et E40b).
[0122] 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.
[0123] 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 CFI 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 SI (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é CFI. 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 CFI.
[0124] A réception de la requête par l'entité CFI, 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-Confi- guration-Request » est ignorée par l'entité CFI 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.
[0125] 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é CFI 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é CFI vers une autre entité CF pour traitement, par exemple vers l'entité CF2 comme illustrée sur la figure 6B.
[0126] Plus spécifiquement, dans la variante 1 décrite ici, l'entité CFI (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).
[0127] Si l'entité CFI (respectivement CF2) détermine que l'équipement utilisateur UE est autorisé à solliciter une telle procédure (comme cela est supposé ici), l'entité CFI (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 SI, à 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.
[0128] Cette interaction consiste ici en l'envoi d'un message de contrôle, nommé par exemple « FF-Control », par l'entité CFI à 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.
[0129] 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(UEl), DESACT) associé à un identifiant Id(UEl) 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 SI 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(UEl), 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).
[0130] 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.).
[0131] L'entité FF1 acquitte ensuite, via son module 13D de communication, le message « FF- Control » en envoyant un message d'acquittement ACK à l'entité CFI (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.
[0132] Comme mentionné précédemment, l'entité CFI (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é CFI (par exemple l'entité CF2) sont impliquées dans ces échanges, elles relaient vers l'entité CFI les messages d'acquittement reçus des entités FF1 à FF3. [0133] Puis, l'entité CFI 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-Confi- guration-Accept ». En variante, elles peuvent faire l'objet d'un traitement par l'entité CFI avant d'être communiquées à l'équipement utilisateur UE1, par exemple être synthétisées sous forme de règles, etc.
[0134] A la réception de l'autorisation de l'entité CFI 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).
[0135] 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 SI 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).
[0136] 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 SI 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 SI (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 SI 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 SI).
[0137] 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. [0138] 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.
[0139] 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 SI, 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 SI 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.
[0140] 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 SI (à 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 SI 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).
[0141] 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.
[0142] 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.
[0143] 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éci- der 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é).
[0144] 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 SI.
[0145] 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 CFI 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.
[0146] 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é CFI 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 « Op- timized-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_NlN2Mes- sageTransfert » 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_Encryp- tion_Status= Enable ; ....
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 SI 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_Encryp- tion_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.
[0147] Variante 2 :
[0148] 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 SI, 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.
[0149] 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.).
[0150] 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.
[0151] 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 SI, 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.
[0152] 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.
[0153] 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 »
[0154] 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.
[0155] 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).
[0156] 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).
[0157] 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.
[0158] 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).
[0159] 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.
[0160] 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 SI transitant via l'entité FF. Cette configuration comprend notamment ici la création d'un contexte de connexion CNT(Id(UEl),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(UEl), DESACT) est stocké dans une mémoire de l'entité FF (par exemple dans sa mémoire non volatile 11) (étape Fl 10).
[0161] 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).
[0162] 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 SI, 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 SI 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)).
[0163] 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).
[0164] 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.
[0165] Variante 3 :
[0166] La variante 3 est illustrée sur les figures 1OA et 1OB 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.
[0167] 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.).
[0168] 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 SI, 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.
[0169] 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 SI (étape G20). Dans l'exemple envisagé ici, les tunnels QUIC établis avec ces entités FF sont maintenus.
[0170] 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 « TUN- NEL-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 »).
[0171] En référence à la figure 1OB, sur réception de cette trame par l'entité FF (étape H 10), 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.
[0172] 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 SI (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 SI transitent via l'entité FF dans un tunnel établi entre l'équipement utilisateur UE1 et l'entité FF sans mettre en œuvre de chiffrement.
[0173] 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).
[0174] 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).
[0175] 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 SI transitent via l'entité FF dans le tunnel chiffré établi entre l'équipement utilisateur UE1 et l'entité FF (étapes G70 et H60).
[0176] 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 SI).
[0177] 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.
[0178] 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.
[0179] 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 « se- curityModeCommand » 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 [eeaO] integrityProtAlgorithm ::= ENUMERATED [eiaO] EXTENSION ::= SEQUENCE nonCriticalExtension :: = SEQUENCE OPTIONAL:Omit
Cet exemple n'est toutefois donné qu'à titre illustratif et n'est nullement limitatif de l'invention. [0180] 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.

Claims

36 Revendications
[Revendication 1] 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 (SI) 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.
[Revendication 2] 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é.
[Revendication 3] 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.
[Revendication 4] 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.
[Revendication 5] 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.
[Revendication 6] 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 37
- d'au moins un réseau d'accès audit réseau pour lequel une dite procédure peut être désactivée.
[Revendication 7] 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.
[Revendication 8] 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é.
[Revendication 9] 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é.
[Revendication 10] 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.
[Revendication 11] 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.
[Revendication 12] 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 (SI) lors d'une communication chiffrée, ledit procédé de gestion comprenant : une étape (H 10) 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é.
[Revendication 13] 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.
[Revendication 14] 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.
[Revendication 15] 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.
[Revendication 16] 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.
[Revendication 17] 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é.
[Revendication 18] 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.
[Revendication 19] 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é.
[Revendication 20] 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é.
[Revendication 21] 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.
EP21798076.2A 2020-09-29 2021-09-27 Procedes de configuration d'un equipement utilisateur, de negociation avec une entite du reseau, et de gestion d'une connexion, et dispositifs associes Pending EP4222994A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR2009920A FR3114723A1 (fr) 2020-09-29 2020-09-29 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.
PCT/FR2021/051663 WO2022069825A1 (fr) 2020-09-29 2021-09-27 Procedes de configuration d'un equipement utilisateur, de negociation avec une entite du reseau, et de gestion d'une connexion, et dispositifs associes.

Publications (1)

Publication Number Publication Date
EP4222994A1 true EP4222994A1 (fr) 2023-08-09

Family

ID=74592056

Family Applications (1)

Application Number Title Priority Date Filing Date
EP21798076.2A Pending EP4222994A1 (fr) 2020-09-29 2021-09-27 Procedes de configuration d'un equipement utilisateur, de negociation avec une entite du reseau, et de gestion d'une connexion, et dispositifs associes

Country Status (8)

Country Link
US (1) US20230370848A1 (fr)
EP (1) EP4222994A1 (fr)
JP (1) JP2023544555A (fr)
KR (1) KR20230078721A (fr)
CN (1) CN116325848A (fr)
BR (1) BR112023005395A2 (fr)
FR (1) FR3114723A1 (fr)
WO (1) WO2022069825A1 (fr)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2024088552A1 (fr) * 2022-11-03 2024-05-02 Lenovo (Singapore) Pte. Ltd. Amélioration des performances de fonction de plan utilisateur dans un réseau de communication sans fil

Also Published As

Publication number Publication date
FR3114723A1 (fr) 2022-04-01
CN116325848A (zh) 2023-06-23
BR112023005395A2 (pt) 2023-04-25
JP2023544555A (ja) 2023-10-24
WO2022069825A1 (fr) 2022-04-07
KR20230078721A (ko) 2023-06-02
US20230370848A1 (en) 2023-11-16

Similar Documents

Publication Publication Date Title
EP3476095B1 (fr) Procédé de communication udp via des chemins multiples entre deux terminaux
EP3476096B1 (fr) Procédé de communication udp via des chemins multiples entre deux terminaux
FR3067550A1 (fr) Procede de communication quic via des chemins multiples
EP3284224B1 (fr) Procédé d'émulation dune connexion à chemins multiples
EP3318023B1 (fr) Procédé d'optimisation de la charge d'un concentrateur de connexions réseau
EP3613186B1 (fr) Système et procédé de communications
EP1371207A1 (fr) Dispositif portable pour securiser le trafic de paquets dans une plate-forme hote
EP3695571B1 (fr) Dispositif et procédé de transmission de données
WO2020260813A1 (fr) Procédé de gestion d'une communication entre terminaux dans un réseau de communication, et dispositifs pour la mise en oeuvre du procédé
WO2022069825A1 (fr) Procedes de configuration d'un equipement utilisateur, de negociation avec une entite du reseau, et de gestion d'une connexion, et dispositifs associes.
EP3811587A1 (fr) Procédé de modification de messages par un équipement sur un chemin de communication établi entre deux noeuds
FR2849313A1 (fr) Dispositif de controle de traitements associes a des flux au sein d'un reseau de communications
WO2023111432A1 (fr) Mécanismes de communication avec un service accessible via un réseau de télécommunication prenant en compte la mobilité des services, des utilisateurs et des équipements
EP4128701A1 (fr) Procédé de gestion de communications et dispositifs associés
EP4338375A1 (fr) Procede de defense contre une tentative de deconnexion entre deux entites, systeme associe
FR2924294A1 (fr) Procede de transmission et systeme de telecommunications

Legal Events

Date Code Title Description
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: UNKNOWN

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE INTERNATIONAL PUBLICATION HAS BEEN MADE

PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: REQUEST FOR EXAMINATION WAS MADE

17P Request for examination filed

Effective date: 20230414

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR

DAV Request for validation of the european patent (deleted)
DAX Request for extension of the european patent (deleted)
RAP3 Party data changed (applicant data changed or rights of an application transferred)

Owner name: ORANGE