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)

Applications Claiming Priority (2)

Publications (1)

Family

ID=74592056

Family Applications (1)

Country Status (8)

Families Citing this family (2)

• 2020
  • 2020-09-29 FR FR2009920A patent/FR3114723A1/fr not_active Withdrawn
• 2021
  • 2021-09-27 US US18/246,757 patent/US20230370848A1/en active Pending
  • 2021-09-27 EP EP21798076.2A patent/EP4222994A1/de active Pending
  • 2021-09-27 KR KR1020237013841A patent/KR20230078721A/ko active Search and Examination
  • 2021-09-27 WO PCT/FR2021/051663 patent/WO2022069825A1/fr active Application Filing
  • 2021-09-27 JP JP2023519373A patent/JP2023544555A/ja active Pending
  • 2021-09-27 BR BR112023005395A patent/BR112023005395A2/pt unknown
  • 2021-09-27 CN CN202180066812.4A patent/CN116325848A/zh active Pending

Also Published As

Similar Documents

Legal Events