Method for discriminating a message between a terminal and a data server

20230262004 · 2023-08-17

    Inventors

    Cpc classification

    International classification

    Abstract

    A method for discriminating a first message concerning a first application from among a set of messages concerning a plurality of applications, transmitted by a terminal device to a data server via a routing device, able to apply a processing operation to an attribute in relation to the first message. The method is implemented by the terminal device and includes: adding an attribute in relation to the first message to an information packet, the packet grouping attributes to which the processing operation is applied; applying a tag to the information packet including the added attribute; and transmitting the information packet comprising the applied tag to the data server.

    Claims

    1. A discrimination method for discriminating a first message concerning a first application among a set of messages concerning a plurality of applications, transmitted by a terminal equipment to a data server by way of a routing device, which is configured to apply a processing to an attribute relating to the first message, said method being implemented by the terminal equipment and comprising: adding the attribute relating to the first message to an information packet, said packet grouping attributes to which the processing is applied and comprising an attribute corresponding to a specific application, applying a tag for the information packet comprising the added attribute, and transmitting the information packet comprising the applied tag to the data server.

    2. The discrimination method, as claimed in claim 1, wherein the terminal equipment transmits the plurality of messages to the data server in a secure session between the terminal equipment and the data server.

    3. The discrimination method, as claimed in claim 1, wherein the information packet is a packet of a secure stream multiplexing protocol.

    4. The discrimination method, as claimed in claim 3, wherein the secure stream multiplexing protocol is a protocol from among the following protocols: the MPTCP protocol, the SCTP protocol, the QUIC protocol, the HTTP2 protocol, the SPDY protocol, the HTTP3 protocol.

    5. The discrimination method, as claimed in claim 3, wherein the secure stream multiplexing protocol is the QUIC protocol and the application of the tag comprises modifying binary elements among a “spin bit” and/or “reserved bits”.

    6. The discrimination method, as claimed in claim 1, wherein the terminal equipment is an equipment configured to access a local area network routing the plurality of messages from and to terminals of the local area network.

    7. The discrimination method, as claimed in claim 1, further comprising, prior to adding the attribute, selecting said first message according to one or more criteria consisting of: the first application is included in a list of applications that is managed by the terminal equipment, the first message is received from a terminal for which an identifier is included in a list of identifiers that is managed by the terminal equipment, the first message comprises a datum relating to a quality of service, said datum being included in a set of data managed by the terminal.

    8. A processing method for processing an attribute relating to a first message concerning a first application, said first message being transmitted by a terminal equipment to a data server, the method being implemented by a device routing the first message and configured to apply a processing to an attribute relating to the first message, the method comprising: detecting an information packet comprising the attribute added by the terminal equipment, according to a tag applied to the received information packet, and processing the attribute included in the received information packet.

    9. The processing method, as claimed in claim 8, wherein the processing comprises counting at least one datum relating to the application on the basis of the processed attribute.

    10. The processing method, as claimed in claim 8, further comprising receiving and applying a processing relating to a second message concerning the first application, on the basis of an attribute included in a second information packet having an applied tag, said second information packet being received from the data server and to the terminal.

    11. A device for discriminating a first message concerning a first application among a set of messages concerning a plurality of applications, transmitted by a terminal equipment to a data server by way of a routing device, which is configured to apply a processing to an attribute relating to the first message, said device comprising: a processor; a non-transitory computer readable medium comprising instructions stored thereon which when executed by the processor configure the device to: add the attribute relating to the first message to an information packet, said packet grouping attributes to which the processing is applied and comprising an attribute corresponding to a specific application, and apply a tag for the information packet comprising the added attribute; and a transmitter to transmit the information packet comprising the applied tag to the data server.

    12. A device for processing an attribute relating to a first message concerning a first application, said first message being transmitted by a terminal equipment to a data server, which is configured to apply a processing to an attribute relating to the first message, the device comprising: a processor; a non-transitory computer readable medium comprising instructions stored thereon which when executed by the processor configure the device to: detect an information packet comprising the attribute added by the terminal equipment, according to a tag applied to the received information packet, and process the attribute included in the received information packet.

    13. (canceled)

    14. A non-transitory computer readable medium comprising a computer program stored thereon including instructions for implementing a discrimination method when the program is executed by a processor of a terminal equipment, the discrimination method discriminating a first message concerning a first application among a set of messages concerning a plurality of applications, transmitted by a terminal equipment to a data server by way of a routing device, which is configured to apply a processing to an attribute relating to the first message, the discrimination method comprising: adding the attribute relating to the first message to an information packet, said packet grouping attributes to which the processing is applied and comprising an attribute corresponding to a specific application, applying a tag for the information packet comprising the added attribute, and transmitting the information packet comprising the applied tag to the data server.

    15. A non-transitory computer readable medium comprising a computer program stored thereon including instructions for implementing a processing method when the program is executed by a processor of a device, the processing method processing an attribute relating to a first message concerning a first application, said first message being transmitted by a terminal equipment to a data server, the method being implemented by a device routing the first message and configured to apply a processing to an attribute relating to the first message, the processing method comprising: detecting an information packet comprising the attribute added by the terminal equipment, according to a tag applied to the received information packet, and processing the attribute included in the received information packet.

    Description

    4. BRIEF DESCRIPTION OF THE DRAWINGS

    [0105] Other features and advantages of the invention will become more clearly apparent from reading the following description of particular embodiments, given by way of simple illustrative and non-limiting examples, and the appended drawings, in which:

    [0106] FIG. 1 shows an implementation of the discrimination method according to a first aspect of the invention,

    [0107] FIG. 2 shows an implementation of the method for capturing a packet according to an embodiment of the invention,

    [0108] FIG. 3 shows an implementation of the discrimination method according to an embodiment of the invention,

    [0109] FIG. 4 shows an implementation of the discrimination method according to another embodiment of the invention,

    [0110] FIG. 5 shows an implementation of the counting method according to an embodiment of the invention,

    [0111] FIG. 6 shows an implementation of the counting method according to another embodiment of the invention,

    [0112] FIG. 7 shows a discrimination device according to an embodiment of the invention,

    [0113] FIG. 8 shows a processing device according to an embodiment of the invention,

    [0114] FIG. 9 shows a capture device according to an embodiment of the invention,

    [0115] FIG. 10 shows a counting device according to an embodiment of the invention.

    5. DESCRIPTION OF THE EMBODIMENTS

    [0116] In the remainder of the description, embodiments of the invention in a communication infrastructure are presented. This infrastructure may be implemented to route communication data to fixed or mobile terminals, and the infrastructure, which is rolled out on the basis of specific equipments or virtualized functions, may be intended to route and process residential-customer or enterprise data.

    [0117] Reference is made first of all to [FIG. 1], which shows an implementation of a discrimination method according to a first aspect of the invention. According to this first aspect, a terminal equipment 30 conveys multiple messages F1, F2, F3 to a data server 20. These messages F1, F2, F3 are routed in a network 100 comprising in particular an access equipment 40 and a device 50 routing the messages interchanged between the terminal equipment 30 and the data server 20. The messages F1, F2, F3 conveyed by the terminal equipment 20 may be transmitted by the terminal equipment 30 or else transmitted by another terminal, such as the terminal 60, and routed by the terminal equipment 30 to the data server 20 via the access equipment 40 providing for the connection of the terminal equipment 30 to the network 100 and the device 50. According to this aspect, the terminal equipment 30 is an equipment of TCU type in a vehicle 10 transmitting the messages F1 and F2 and the terminal 60 is for example a smartphone of an occupant of the vehicle transmitting the messages F3. The various messages F1, F2, F3 may call for a particular processing by the device 50 and therefore the possibility of being able to discriminate between the various messages. For example, in the knowledge that the conveyance of the messages F1, F2, F3 may be billed to distinct entities, it is necessary to be able to actually record the number of messages F1 and/or F2 and/or F3. Now, using the techniques of the prior art, it may be difficult for the device 50 to access the content of the messages F1, F2, F3 because they may be in particular encrypted. According to this aspect, in the knowledge that the messages F3 need to be billed to the occupant of the vehicle 10, the messages F3 relating to an application used by the occupant are integrated in an information packet and transmitted by the TCU 30 to the data server. To allow the device 50 to easily identify the information packet, the terminal equipment applies a tag, for example by modifying information elements of the unencrypted header of the packet, so that the device 40 is able to easily identify and process said packet among the various messages F1, F2, F3 that it needs to route. The added message F3 may correspond to the data of the application or else to data peculiar to the processing by the device 50. For example, the message F3 may correspond to the volume of data that is interchanged between the terminal 60 and the data server 20. As such, the terminal equipment 30, which may actually intervene in the messages that it transmits itself or on behalf of terminals such as the terminal 60, collaborates with the device by conveying to it information packets that may be processed by the device 50. The access equipment 40 may also play the part of the device 50 and the terminal equipment 30 may also be a residential gateway, also called a box, or else an equipment of smartphone type. The information packet comprising the messages F3 may moreover be encrypted using an encryption key and the device 50 may then decrypt the information packet received from the terminal equipment 30 by using a decryption key corresponding to the encryption key used for the encryption. It should be noted that if messages relating to distinct applications call for processing by the device 50, then the terminal equipment 30 may include in the information packet the messages relating to the two applications, by differentiating for example the various messages by way of the tag applied to the packet. As such, the tag will be able to comprise a tag peculiar to an application. For example, if messages F4, which are not shown in [FIG. 1], are transmitted by the terminal 60 to the data server 20, the terminal equipment will be able to insert the messages F3 and F4 into an information packet that the device 50 will be able to process in accordance with the tag applied by the user equipment 30.

    [0118] With reference to [FIG. 2], an implementation of a method for capturing a packet according to an embodiment of the invention is shown. The entities 10, 20, 30, 40, 50 shown in this [FIG. 2] are identical to the entities 10, 20, 30, 40, 50 shown in [FIG. 1]. In this [FIG. 2], three applications App1, App2, App3 are shown. These applications App1, App2, App3 may be used or activated on the terminal equipment 30 or on a terminal, such as the terminal 60 shown in [FIG. 1]. The device 50, like the access equipment 40, routes the packets relating to the applications App1, App2, App3 transmitted by the terminal equipment 30 to the data server 20 and the packets transmitted by the data server 20 to the terminal equipment 30. An encrypted session is set up between the terminal equipment 30 and the data server 20 to route the packets. One or more encrypted sessions, for example one per application App1, App2 and App3 or one session for all of the applications App1, App2 and App3, may be implemented. The packets interchanged between the terminal equipment 30 and the data server 20 comprise a determination datum of a security key used for encrypting the packets. For example, this may be one or more bits allowing the terminal equipment 30 and the data server 20 to agree on the security key to be used for encrypting and decrypting the data and to indicate the key or a change of key by way of information provided by a determination datum, for example present in the unencrypted header of the packet. The device 50, routing the various packets interchanged between the terminal equipment 30 and the data server 20, analyzes these packets and more particularly analyzes the determination data of the keys of the packets. A succession of packets relating to the application App1 are encrypted using an encryption key, for example a private key, and the determination datum corresponding to this key has a value v1. The device 50, analyzing these data and checking that the value of the datum is unchanged, conveys these packets to the data server. Next, the device receives a packet having a determination datum having a value v0 that had been used for interchanging packets on a previous connection of the session or for sending packets in a previous protection phase for the same connection. This determination datum value v0 is no longer supposed to be used for interchanges of packets between the terminal equipment 30 and the data server, since all of the packets comprise the value v1 as determination datum. The device 50 determines whether said packet is a cooperation packet, comprising data intended for it, and decrypts the content of the packet using a decryption key corresponding to the value v0, this key no longer being used to interchange the data between the terminal equipment 30 and the data server 20. As such, an encryption key previously used for interchanging packets between the terminal equipment 30 and the data server 20 may be reused for conveying information to the device 50 in an encrypted packet using the reused key. This does not impair the end-to-end security between the terminal equipment 30 and the data server 20, since the key used for encrypting the cooperation packet conveyed by the terminal equipment 30 (or the data server 20) to the device 50 is a key that is no longer used for encrypting the packets interchanged between the terminal equipment 30 and the data server 20. The security key associated with the determination datum for which the value is v0 may be provided to the device 50 prior to sending the cooperation packet or subsequently, the device 50 being able to store the cooperation packet in order to decrypt it once the key has been received. The user equipment may thus implement a counting method allowing the device 50 to be informed about the number of packets or the volume of data or information about a session duration in a cooperation packet comprising a counter incremented for each conveyed packet, the counter being able to correspond to the number of transmitted packets, to a volume of data that is incremented for each transmitted packet, or to a duration that is incremented as soon as a new packet is transmitted. The device 50 may thus utilize the information from the counter that is included in the cooperation packet decrypted using the key corresponding to the determination datum of the cooperation packet.

    [0119] Reference is now made to [FIG. 3], which shows an implementation of the discrimination method according to an embodiment of the invention. The entities 10, 20, 30, 40, 50, 60 and 100 are equivalent to the entities having the same labels in [FIG. 1] and [FIG. 2]. In particular, according to one alternative, the terminal equipment 30 is an equipment for accessing a local area network, such as a residential gateway, or an equipment for accessing a vehicle network, such as a TCU. In a step 200, the terminal equipment 30 attaches and connects to the access equipment 40. A session is considered to be set up between the terminal equipment 30 and the data server 20. According to one alternative, the session may be set up by way of a secure connection between the terminal equipment 30 and the data server 20. In a step 300, the smartphone 60 transmits a message relating to an application App1, for example a network gaming application, and intended for the data server 20 to the terminal equipment 30, and the latter conveys this message to the data server 20 in a step 301. In a step 302, the terminal equipment 30 conveys a message relating to an application App2, for example an application for managing the vehicle 10, to the data server 20. The 2 messages call for differentiated processing by the routing device 50, the message relating to the application App2 needing to be backed up by the device 50, in particular in the event of an audit for an insurance. The access equipment 40 and the device 50 route the various messages transmitted in steps 301 and 302 to the data server 20. The terminal equipment 30 holds a list of applications for which a particular action needs to be taken. For example, for the application App2, it needs to transmit a message linked to this application to the device 50. According to another example, the terminal equipment 30 identifies the messages according to the terminal transmitting these messages or even according to information, for example relating to the quality of service, in the message itself. According to this example, the terminal equipment needs to copy an attribute relating to the message to an information packet intended for the device 50.

    [0120] According to one example, in an optional step 303, the terminal equipment 30 selects a message from among all the messages to be conveyed to the data server 20 according to a criterion. For example, the terminal equipment may compare the application concerned by the transmitted message. According to the example, the messages relating to the application App2 need to give rise to a specific processing by the device 50. According to another example, the terminal equipment 30 will be able to convey to the device 50 attributes relating to messages transmitted by one terminal in particular, for example from the terminal 60. According to yet another example, the terminal equipment 30 will be able to convey attributes relating to messages comprising specific routing, protocol or else quality of service or even security information. As such, all messages calling for a specific routing quality will be able to give rise to the provision of an attribute relating to the instant at which the terminal equipment 30 has transmitted the messages so that the device 50 is able to check that the messages in question have indeed been routed while complying with the quality of service criterion indicated in the messages, or else that their distribution over time corresponds to the type of application expected (by using a shallow packet inspection technique).

    [0121] In a step 304, the terminal equipment 30 adds the message, according to one example, to an information packet. Multiple distinct message attributes will be able to be grouped in the information packet in order to limit the number of information packets conveyed. According to one alternative, the attribute relating to the message that has been added may correspond to a portion of the transmitted message or else to one or more pieces of information relating to the application App2, such as: the number of messages, the duration of the session between the terminal equipment 30 and the data server 20 for the application App2, the identifier of the terminal that has transmitted the messages relating to the application App2.

    [0122] The information packet, according to one alternative, may comprise attributes of messages peculiar to a single application, for example if the information packet comprises only attributes relating to the application App2. However, if the same processing needs to be applied to messages of different applications, it may be advantageous to group attributes of messages relating to distinct applications but calling for identical processing by the device in the same information packet. For example, if the processing consists of counting those transmitted packets relating to two applications App4 and App5 that are billed to the same entity, attributes such as message counters relating to the applications App4 and App5 will be able to be conveyed in one information packet. The terminal equipment 30 then applies a tag for the information packet in a step 305, for example by positioning certain binary elements of the information packet at a defined value. According to one example, the information packet may be a packet of a secure stream multiplexing protocol. This type of protocol, which offers integrated protection and the possibility of multiplexing multiple streams, is particularly attractive. Indeed, if the terminal equipment 30 wishes to convey multiple information packets, each packet grouping attributes of messages calling for a specific processing, then it is possible to convey the information packets securely and by multiplexing the various information packets within a single connection between the terminal equipment 30 and the device 50. According to one example, the secure stream multiplexing protocol may be the QUIC protocol or even the HTTP2 or HTTP3 protocol. The QUIC protocol has in particular the advantage of comprising the spinbit and reserved-bits bits that may be used to apply a tag to the information packet. Binary elements of other secure stream multiplexing protocols, such as the spin bit or the reserved-bits bits of the QUIC protocol, may be indiscriminately utilized to apply a tag to the information packet.

    [0123] In a step 306, the terminal equipment 30 transmits the information packet comprising one or more attributes of the messages relating to the application App2. In this embodiment, the information packet is considered to comprise the messages transmitted by the terminal equipment 30 for a period of 300 seconds. This information packet conveyed using the QUIC protocol moreover comprises the spin-bit and reserved-bits bits positioned at 1. The tagging information, allowing the received information packet to be differentiated from other packets, tells the device 50 that this is an information packet and that a processing needs to be applied to the information packet by using the attributes of messages that are present in the information packet received in step 306. In a step 307, the device 50 conveys to a backup unit 70 a message comprising the attributes of messages received in step 307 and thus allowing a history of the messages relating to the application App2 conveyed by the terminal equipment 30 to be preserved. According to one alternative, the information packet is conveyed to the data server 20 in a step 309. This may be the case in particular when the processing by the device 50 consists of duplicating the received information packet so that the sequencing of packets received by the data server 20 is not distorted or rendered incorrect by the removal of a packet from a session between the terminal equipment 30 and the data server 20.

    [0124] According to one alternative, the processing may consist of counting the number of messages conveyed for an application. As such, if the billing is to be differentiated per user (owner of the vehicle 10, owner of the terminal 60, manager of the user equipment 30), it is necessary to count the messages or the volume of data that is generated by the applications and to pass on the costs associated with the number or with the volume to the user or manager using or managing the application. In this case, the attribute will be able to be a number of messages or a volume of data in the transmitted messages.

    [0125] According to another example, the device 50 may also apply a processing to the messages relating to the application App2 that are conveyed by the data server 20 to the terminal equipment 30. According to this example, in a step 310, the data server 20 transmits messages relating to the application App2 to the terminal equipment 30. Steps 311 to 317 are equivalent to steps 303 to 309 described hereinabove if only the data server 20 performs the operations of the terminal equipment 30 and, reciprocally, the terminal equipment 30 performs the operations performed by the data server 20. It should be noted that the access equipment 40 may also perform some or all of the operations performed by the device 50 in addition or not in addition to the operations performed by the device 50.

    [0126] With reference to [FIG. 4], an implementation of the discrimination method according to another embodiment of the invention is shown.

    [0127] The discrimination method and the corresponding processing method activate an extension QFLOW_A to QUIC that forces the interchanges of QUIC packets in “stream management” mode for only the QUIC packets to be recorded as being traffic to be billed to the owner of the SIM card of the TCU module (terminal equipment) of a car: grouping QUIC messages to be recorded in tagged QUIC packets. The QFLOW_A extension modifies the use of the spin-bit field to tag the QUIC packets to be recorded by the device.

    [0128] Moreover, according to one alternative, on the server, activation of the QFLOW_A extension creates in the server a stream table that is used to implement the “stream management” method for the packets transmitted by the server.

    [0129] The manufacturer of the vehicle typically develops the method as OEM (original equipment manufacturer) in the tablet of the dashboard so that the OS (operating system), the web browser or the applications group the QUIC messages of the streams to be recorded in tagged QUIC packets so that the device, for example managed by a mobile operator, identifies them and records them if the processing consists of recording the messages of the streams in question.

    [0130] The QFLOW_A method is described in “stream management” mode: the criterion for grouping the messages in tagged packets is the identifier of the application that generated the messages in tagged packets. It is generally applicable to other grouping modes: for example, another criterion for grouping the messages may be grouping the QUIC control messages in order to expect to be able to bill only the messages of “payload” data (that is to say not including control data of DNS type, for example) to the end customer. Other processings may consist of controlling the signaling for security purposes or routing the control messages faster in a device such as a proxy. One typical use of the product is storing the signaling in order to carry out a later inspection of the messages stored and conveyed in QUIC packets.

    [0131] The method may be applied to a mode without visible tagging of the outside of the packet. A typical use of this mode is speeding up the signaling in devices of “reverse proxy” type or routing the signaling to an inspection function of DPI type (telemetry, problem analysis, security, and so on).

    [0132] The discrimination method may include various modes that can be combined, such as for example: [0133] QFLOW_A mode: only messages transmitted by the TCU client (terminal equipment) are added to a QUIC packet that is tagged, and therefore only transmitted data are recorded as traffic billed by the manufacturer. [0134] QFLOW_B mode: a QUIC extension uses the transport parameter called “spin bit” to indicate that the packet needs to be recorded. This is sufficient to record the volume paid for by the manufacturer (which does not need to be billed to the owner of the car). [0135] QFLOW_C: a QUIC extension uses a transport parameter such as spin bit for indication and the 2 RR bits of the QUIC protocol are used to describe the identifier of an application. As such, 3 bits allow a distinction to be drawn between 8 different applications (for example waze, gmap, and so on) or another grouping criterion (identifier of the terminal, QoS criterion, and so on).

    [0136] The steps of the method in this embodiment proposed in [FIG. 5] are as follows: [0137] Step A: create the QUIC connection between the TCU module (terminal equipment) and the server (data server) without explicitly activating the QFLOW_A extension: the server thus deduces from this that the spin bit of the QUIC protocol is used for the QFLOW_A mode; [0138] Steps B0 (and E0): the TCU module receives messages from the application App Serv 3 of a terminal. The TCU module knows (for example courtesy of a table of applications to be billed) that these messages need to be recorded. The TCU module therefore receives data that need to be recorded by the device. It creates a QUIC packet that will group the data to be recorded by the device. It may structure these data per application if the QUIC packet comprises data of multiple distinct applications. [0139] Step B: the TCU module (and more precisely the QUIC stack of the module) receives data (messages) to be recorded and to be added to a QUIC stream management packet (Stream). The QUIC stack may include the received message or merely a portion of the message, such as the source and destination addresses, the protocol type. [0140] Step C0: the TCU module receives messages relating to the application App Serv 4 that do not need to be recorded by the device. An untagged QUIC message (Norm QUIC) is created and will route these messages to the server, the recipient of these data. [0141] Step C (and step E): the QUIC stack receives data (or messages) and processes them in order to include them in the QUIC packet created in step C0. It transmits the “untagged” QUIC packet to the server. [0142] Step D: the server receives “untagged” QUIC packets, that is to say with a spin-bit value at 0. It should be noted that the device applies no processing to these so-called untagged packets. [0143] Step E: another terminal transmits messages relating to the application App Serv 3. These messages need to be recorded as indicated in step B0. When the tagged QUIC packet comprises a sufficient volume of messages and/or after a certain time after the creation of a Stream packet, the TCI module transmits the QUIC Stream packet to the server. [0144] Step Ebis: the device identifies the QUIC Stream packet by using the spin-bit bit tagged at 1 and applies the processing. In the present case, the device records it and adds the volume of data corresponding to the application App Serv 3 courtesy of the information transmitted in the Stream packet, that is to say the attribute relating to the application App serv 3. [0145] Step F: the QUIC stack of the server receives a QUIC Stream packet and processes the messages in the packet. [0146] Step G: the device routes QUIC packets transmitted by the server to the terminals attached to the TCU module or specifically to the TCU module but does not apply any processing because this is the QFLOW_A mode. In the QFLOW_B mode, the QUIC packets transmitted by the server are processed in accordance with the processing applied to the packets transmitted by the TCU module. [0147] In the QFLOW_B mode, step B above is modified so that the TCU module tells the server to activate the QFLOW_B mode, thus indicating that the spin-bit bit is used to identify the transport of messages to be recorded in the QUIC packets. Steps F and G above are moreover modified as follows: [0148] Step F: when the server receives a QUIC packet with the spin bit at 1, it extracts the QUIC messages (in this embodiment, the messages are themselves QUIC packets) from the packet and stores a list of identifiers associated with the messages in a stream table. Next, it processes each frame: [0149] back up identifiers; [0150] process each QUIC Stream packet; [0151] responses to each QUIC Stream packet; [0152] add the response messages (or attributes relating to the response messages) to the messages received in a QUIC Stream packet; [0153] Step G: send the QUIC Stream packet to the TCU module (indicating the address of the terminals that generated the App Serv 3 messages) [0154] Step Gbis: the device identifies the QUIC Stream packet received from the server and applies the processing of recording the messages on the basis of the messages or the attributes that are present in the QUIC message.

    [0155] The QFLOW_C mode is distinguished from the two modes above by a different identification for the stream packets. The processing applied may be distinguished according to the identification of the received stream packet. For example, the processing may be applied according to the application, according to the entity responsible for paying for the messages, according to the terminal transmitting the messages or else a combination of these criteria:

    [0156] According to one example, in this QFLOW_C mode, the counting is performed according to the entity responsible for paying for the messages. The attributes of the messages are grouped in QUIC packets used for billing a particular entity. [0157] Use of the 3 spin-bit and RR bits to distinguish between multiple counting modes [0158] The bits correspond to a billing entity for the messages:
    {[name com.car.android.app, payer: enterprise A, Id: 010], [0159] [name: com.netflix.android.app, payer: enterprise B, Id: 011], [0160] [name: com.poki.android.app, payer: user C, Id: 110], [0161] [name: com.sponsordata.android.app, payer: TCU manager, Id: 101].

    [0162] According to another example, the counting is managed by application category. In this example, the 3 spin-bit and RR bits of the QUIC header indicate the category of the packet, that is to say a set of applications for which the messages need to be grouped and to be tagged in order to then be processed by the device. An example is proposed below:

    {[name com.car.android.app, id: 100], [0163] [name: com.netflix.android.app, id: 101], [0164] [name: com.poki.android.app, id: 110], [0165] [name: com.sponsordata.android.app, id: 111].

    [0166] With reference to [FIG. 5], an implementation of the method for counting a packet according to an embodiment of the invention is shown.

    [0167] The entities 10, 20, 30, 40, 50, 60 and 100 are equivalent to the entities having the same labels in [FIG. 1], [FIG. 2] and [FIG. 3].

    [0168] In a step 400, the terminal equipment 30 attaches and connects to the access equipment 40. An encrypted session is considered to be set up between the terminal equipment 30 and the data server 20. This means that the data packets interchanged between the terminal equipment 30 and the data server 20 are encrypted using an encryption key, for example a private encryption key, and the data server decrypts the received packets using a decryption key, for example a public key, corresponding to the encryption key. Correspondingly, the packets transmitted by the data server 20 to the terminal equipment 30 are encrypted and then decrypted. In a step 401, the terminal 60 conveys packets relating to an application App4 to the terminal equipment 30 so that the latter conveys them in a step 402 to the data server 20 with which the terminal set up a session. According to one example, the application App4 is a web access application. As indicated above, the packets transmitted in step 402 are encrypted using a security key. The transmitted packets moreover comprise a determination datum informing the data server 20 about the security key actually used for encrypting the packets. According to one example, the determination datum corresponds to values of one or more binary elements of the packet header such as for example a binary phase element as defined for example in the TLS and QUIC protocols allowing the data server to be notified of a change of key, the new key being computed on the basis of an algorithm and from the key previously used for packet interchange. As such, the packets are successively interchanged using different keys, the change of key being indicated by a change of phase. The determination datum may therefore correspond to the phase change bit or even to a phase change bit and additional bits in order to allow the information relating to the key used by the terminal equipment for transmitting the packets to the data server 20 to be enriched. In a step 403, the terminal equipment 30 transmits packets relating to an application App6 to the data server 20. According to one example, the application App6 is a security application allowing the positioning of the vehicle 10 to be determined when it moves and allowing help to be organized in the event of a problem such as a vehicle breakdown or an accident.

    [0169] In the remainder of the embodiment, the counting of the packets relating to an application App5, a video streaming application, is considered to need to be performed by the terminal equipment 30 so that the data relating to the video streaming service used by the terminal 60 are actually billed to the user of said service rather than to the owner of the vehicle 10, for example. This activation may be static, that is to say that a list of applications for which counting needs to be performed is held by the terminal equipment 30. This activation may also be dynamic, for example following receipt of a request transmitted by an administration platform for the applications or for the terminal equipment 30.

    [0170] According to one alternative, in a step 404, the terminal equipment transmits to the device 50 an activation message for activating a method for capturing packets allowing the device to take up a listening position in order to identify cooperation packets conveyed by the terminal equipment 30, so that the packets may be counted. In this step 404, according to one example, the terminal equipment may moreover indicate a connection identifier used that will be added to the cooperation packet and that the device will actually be able to identify. Thus, among all of the packets that are routed by the device 50, it will be able to identify the cooperation packets. It should be noted that this connection identifier may be conveyed in a manner specific to the device 50 if for example no activation message is conveyed. The activation message may, according to another alternative, also comprise the decryption key that will need to be used by the device 50 in order to decrypt the cooperation packet, possibly in accordance with the connection identifier included in the message. This activation message will itself be able to be encrypted using a key initially provided to the device 50 in a message that is not shown in [FIG. 5].

    [0171] According to another alternative, in a step 405, the terminal equipment transmits to the data server 20 an activation message for activating the capture method implemented by the device 50. The aim of this message is firstly to inform the data server 20 that keys initially used for encrypting packets between the terminal equipment 30 and the data server 20 will be able to be used for other purposes, for encrypting cooperation packets. This activation message is also intended to tell the data server 20 to implement the counting method so that the packets interchanged in a bidirectional session between the terminal equipment 30 and the data server 20 are counted so as for example then to be billed to the owner of the terminal 60.

    [0172] In a step 406, the terminal 60 transmits a request to access a video streaming service to the data server 20 by way of the terminal equipment 30 ensuring the connection of the terminal 60 to the network 100.

    [0173] In a step 407, the terminal equipment 30 initializes a counter for the packets received from the terminal 60 and relating to the application App5. The terminal equipment increments the counter with the number of packets received from the terminal 60. It should be noted that the counter may comprise the number of packets or even the volume of data corresponding to the received packets. According to one example, the counter uses the Mbits as the unit of the counter. According to one example, the terminal equipment 30 initializes one counter per terminal and increments the counter for the packets transmitted by the corresponding terminal or else uses a counter for the application App5 independently of the terminal transmitting the packets. According to another example, the counter is incremented according to the packets received from a terminal for a set of applications. As such, all the packets received from the terminal 60 will be able to be recorded. According to this example, the packets relating to the application App4 and App5 are counted by the terminal equipment 30.

    [0174] In steps 408 and 409, the terminal 60 transmits new packets relating to the application App5 and the terminal equipment 30 increments the counter initialized in step 407. In a step 410, the terminal equipment 30 adds the incremented counter to a cooperation packet. This addition may take place after a period that has elapsed following the initialization of the counter, once the counter reaches a certain volume of data or packets or else following the reception of a message from a management server. The terminal equipment 30 moreover determines a determination datum to be added to the cooperation packet. According to one example, this determination datum corresponds to an encryption key previously used by the terminal equipment 30 for transmitting data to the data server 20. For example, the determination datum may be the determination datum used for sending the packets in steps 402 and/or 403, in particular if this datum is no longer used for sending the packets in steps 406 and 409, for example. According to one alternative, the cooperation packet comprises a connection identifier, as possibly indicated in the activation message in step 405. According to another example, the connection identifier comprises binary elements of a protocol, in particular of a secure data multiplexing protocol. This connection identifier may, according to one example, comprise the spin-bit and reserved-bits bits of the QUIC protocol or equivalent bits of the HTTP2 or HTTP3 protocols. The connection identifier may, according to another alternative, comprise the determination datum of the packet. According to this example, the device identifies the cooperation packet on the basis of the determination datum as indicated later on.

    [0175] In a step 411, the terminal equipment conveys the cooperation packet to the data server 20 by way of the device 50. The cooperation packet comprises the determination datum of the encryption key used for encrypting the cooperation packet and also the incremented counter and possibly a connection identifier used by the device 50 to identify the cooperation packet among all the received packets.

    [0176] The device 50, if it has received the activation message in step 404 or else by default as soon as it receives packets, implements an analysis of the packets received from the terminal equipment 30. This analysis may relate to the comparison of values of connection identifiers and/or of determination data of the received packets.

    [0177] In a step 412, the device 50 receives the cooperation packet and identifies it using the connection identifier, if said connection identifier is present in the packet, and/or using the determination datum of the encryption key used. In the latter case, in the knowledge that the previously received packets no longer comprise this determination datum, reception of a packet comprising a distinct determination datum of the packets to be routed in a given interval of time tells the device 50 that this is a cooperation packet. According to one example, when the device 50 no longer receives packets having a value v0 as determination datum during an interval of time and begins to receive packets having a value v1, it may initialize a timer and if it receives a packet having a value v0 as determination datum again after a certain time after the initialization of the timer, it is probable that the packet is an information packet. If this determination datum corresponds to an encryption key recently used for interchanging packets between the terminal equipment 30 and the data server 20, the device 50 will not be able to decrypt this packet, which will have been wrongly identified as a cooperation packet, since it does not hold the key allowing such a packet to be decrypted. As the determination datum of the received information packet is distinguished from the determination data of the data packets received before and/or after reception of the information packet, this information packet may be detected using this determination datum. The encryption/decryption key associated with the determination datum of the information packet was able, according to one example, to be used during a previous session between the terminal equipment 30 and the data server. According to another example, a session context may be maintained between the terminal equipment 30 (or a terminal connected thereto) and the data server 20, and when a new connection is set up, the session context is re-established for example by using cookies and it is possible to reuse a key corresponding to a previous connection of one and the same session for which the context is maintained. According to yet another example, the encryption key associated with the determination datum was used for the session initialization interchanges (handshake) between the terminal equipment 30 and the data server 20. If the identification is also or only reliant on the connection identifier, then it is advisable for the device 50 to compare the value of the connection identifier with one or more values of identifiers corresponding to information packets.

    [0178] According to one alternative, in particular if the device 50 has not previously received the key corresponding to the determination datum of the information packet, in a step 413 the terminal equipment conveys a key allowing the received information packet to be decrypted. This alternative makes it possible to prevent errors and the decryption of packets that are not information packets but for which the determination datum corresponds to a key that is actually used for encrypting/decrypting the data.

    [0179] According to one example, in a step 414, the device conveys the counter to a billing equipment 80 providing for conversion of the counter into billing information that will be conveyed to the user of the terminal 60, the counter being able to comprise information about the application App5, the terminal having transmitted the packets or even timestamp information of the packets relating to the application App5. According to one alternative, in a step 415, the cooperation packet is removed from all of the packets to be transmitted to the data server 20. In the knowledge that the information that is present in the information packet is intended to be processed by the device, the data server 20 has no reason to receive this packet, which moreover contains a determination datum that is normally no longer used for decrypting the packets received from the terminal equipment 30.

    [0180] According to one example, in a step 416, the data server 20 implements the counting method as implemented by the terminal equipment 30 and is capable of counting the packets relating to the application App5, of initializing a counter of these packets and of adding said counter to an information packet conveyed to the terminal equipment so that it is communicated to the device 50 following its identification by a determination datum, which is possibly different from the datum used by the terminal equipment 30 and/or from a connection identifier that is possibly also different from the connection identifier used for the information packets transmitted by the terminal equipment 30. In this regard, interchanges between the data server 20 and the device 50 have been able to occur previously in accordance with step 404 described above.

    [0181] In a step 417, the data server 20 conveys packets relating to the application App5 via the device 50, the access equipment 40 and the terminal equipment 30, in order to convey the video content called for by the terminal 60 in step 408. In a step 416, the device 50 analyzing the packets received from the data server 20 identifies an information packet by using the information described above, and possibly stores said information packet if it does not yet have the key allowing it to be decrypted and the counter to be extracted therefrom in order to convey it to the billing equipment 80 in a step 419.

    [0182] The counting method implemented by the terminal equipment 30 and possibly by the data server 20 thus allows the device 50, in cooperation with the billing equipment 80, to be able to bill for the packets and therefore the data of the application App5. The use of such methods thus allows the data relating to each application to be counted and encryption and decryption keys that are no longer used for transmitting the packets comprising the payload data of the applications, that is to say packets called for in order to access the audio, video or text content of the various applications, to be reused. With reference to [FIG. 6], an implementation of the counting method according to another embodiment of the invention is shown.

    [0183] The counting method and the corresponding capture method may be implemented in accordance with multiple modes labeled RFLOW_A and RFLOW_B.

    [0184] The RFLOW_A mode is a unidirectional mode that requires no modification in the server because the device removes the cooperation packets after receiving a signal from the terminal, or after a time has elapsed or even when reception of a volume of data is reached. The RFLOW_A mode thus defines a cooperation packet in an extension of the QUIC protocol that allows data to be interchanged with the device (application type, counters). The cooperation packet is encrypted using a key referred to as 1-RTT that is used in phase 0 (initialization of the session) of the QUIC protocol. The terminal equipment sends the 1-RTT key of QUIC phase 0 at the moment it desires during or after the end of the connection. The device records all or some of the messages interchanged between the terminal equipment and the data server in order to identify and decode the cooperation packets after receiving the cooperation key allowing the recorded cooperation packets to be decrypted.

    [0185] The RFLOW_B mode is distinguished from the RFLOW_A RFLOW_B mode as follows. In addition to RFLOW_A, the bidirectional RFLOW_B mode activates the extension (the counting method) on the server by sending a QUIC COOP_MODE transport parameter for example at the moment at which the session between the terminal equipment and the data server is set up. As such, the server will not terminate the connection in the event of an error when it receives 1-RTT messages after the transition phase. Indeed, if it does not activate the counting method, it could consider reception of packets encrypted using a key that is normally no longer used to be an error. Moreover, the server will also be able to transmit and receive cooperation packets.

    [0186] FIG. 6 describes an embodiment relating to the RFLOW_A mode.

    [0187] A UA (terminal equipment) sets up a session with a data server (SRV) allowing messages (or packets) to be routed via a device (GW), for example managed by an operator of a communication network.

    [0188] Step 0: The terminal UA and the device GW interchange encryption keys ENC_KEY_UA and decryption keys DEC_KEY_UA

    [0189] Various types of encryption/decryption keys may be used, for example: [0190] A key referred to as external “external PSK” as defined in the document https://tools.ietf.org/html/draft-ietf-tls-tls13-cert-with-extern-psk-07 is provided to the UA by the device GW [0191] A key eSNI for the DNS eSNI recording of the FQDN of the GW as defined in the document https://tools.ietf.org/html/draft-ietf-tls-esni-05

    [0192] Step A: the device activates the method for capturing the packets received from the terminal equipment UA. It should be noted that this step may be performed following reception of an activation message for activating the capture by the UA.

    [0193] Step B: “handshake” messages interchanged between the UA and the SRV. The messages use keys identified by a determination datum corresponding to a phase 0. This key is the future cooperation key. It is subsequently called initial phase 0 key or else reconnection phase 0 key even if it may be any type of key as described in step 0.

    [0194] Step C: data packets relating to applications, for example transmitted by terminals connected to the UA and not shown in [FIG. 6], are interchanged between the UA and the SRV. At this moment, the interchanged packets may comprise determination data corresponding to the phase in progress (0 in the example) or to a new phase (1 in the example). This is because the data packets may be encrypted using a new encryption key.

    [0195] Step D: GW activates the RFLOW extension of the capture method after a time of n ms without a packet comprising a determination datum corresponding to the phase supposed to be active (0 in the example), or after n consecutive packets comprising a determination datum corresponding to the new phase (1 in the example), which should no longer be used for interchanging the packets between the UA and the SRV following the change of encryption key. From this moment on, the packets from the previous phase (for which the determination datum corresponds to phase 0) are considered to be cooperation packets and are captured, and removed from the stream of packets interchanged between the UA and the SRV by GW.

    [0196] According to one example, GW uses the standard tagging bit of the QUIC inverse phase packets as determination datum.

    [0197] By way of generalization, the phase (determination datum) will subsequently be inverted again and will return to phase 0. GW will then suspend the RFLOW extension from detection of a cooperation packet that it does not manage to decrypt. This packet will be transmitted to the server SRV and not stored by GW. The latter will then activate the RFLOW extension after a time of n ms without a phase packet previous to 1 or after n consecutive packets comprising a determination datum corresponding to the new phase (0 in the example). These packets from the previous phase (referred to as cooperation packets) are captured and removed from the stream by GW.

    [0198] Step E: interchange of untagged data packets having a determination datum corresponding to a 1 phase

    [0199] Step F: count the messages (which may be packets or data of different type), and add the counter to a cooperation packet. Set the phase (determination datum) of the cooperation packet to 0. Send the cooperation packet to the GW.

    [0200] Step G: capture the cooperation packet comprising the counter by identifying the 0 phase used as determination datum. It should be noted that the decryption key associated with the initial phase 0 may be sent to the GW by the UA, alternatively or in addition to the sending in step 0.

    [0201] If the RFLOW_B mode is implemented: following the handshake messages interchanged or at the time at which the handshake messages are interchanged, an activation message for activating the extension (of the counting method) is conveyed to the SRV by the UA.

    [0202] Moreover, in this RFLOW_B mode, the GW does not remove the cooperation packets from all of the packets routed between the UA and the SRV by the GW. The cooperation packets having a determination datum corresponding to a cooperation packet (phase 0) are therefore received by the SRV. In accordance with the sessions set up between the UA and the SRV, the server SRV transmits data to the UA, in response or otherwise to the data packets received from the UA. The SRV implements the counting method and the GW also captures the cooperation packets conveyed to the UA by the SRV by selecting the cooperation packets according to the value of the determination datum that is present in the packets that are also received from the server SRV. In this RFLOW_B mode, the UA will also receive the cooperation packets.

    [0203] It should be noted that, according to the previous techniques, in the QUIC and TLS1.3 protocols, the session is reconnected by using the key that is used for the previous connection. According to this mode, the corresponding counting and capture method recycles the 0-RTT key in order to tag the cooperation packets to be identified by the GW.

    [0204] When a new session is involved, that is to say that a session has not been set up previously, an implementation of the method as described below may be rolled out.

    [0205] When the equipments UA and SRV set up a first connection (i.e. the extension pre_shared_key has not been activated), once the handshake has terminated and the master_secret has been obtained, the UA and the SRV derive the cooperation_secret by way of the operation:


    cooperation_secret=QHKDF-Expand(master_secret,“coop s”,hash.length)

    [0206] This secret is then provided to GW, which will be able (like the UA and the SRV) to compute the key and the initialization vector (iv) by way of the following operations:


    key=QHKDF-Expand(cooperation_secret,“key”,key_length)


    iv=QHKDF-Expand(cooperation_secret,“iv”,iv_length)

    [0207] Moreover, it should be noted that the RFLOW_A and RFLOW_B modes may be combined in order to increase the levels of cooperation by creating multiple modes for identifying the cooperation packets by way of GW: [0208] a spin-bit bit S identifies the cooperation packets and the RR bits (R1, R2) distinguish between multiple cooperation modes: [0209] in the RFLOW_A mode, S at 1 indicates that the packet is a cooperation packet (use of DEC_KEY_UA key to decrypt it). [0210] advanced options: use of the bits R1 and R2 distinguishes between 4 types of cooperation packets: [0211] Read: 00 to indicate a QUIC packet that includes an area that can be read by GW; [0212] Delete: 01 to indicate a QUIC packet that can be read by the gateway and needs to be removed by GW; [0213] Update: 10 to indicate a QUIC packet that can be modified plainly by GW (no encryption); [0214] Modif: 11 to indicate an end-to-end QUIC packet open to cooperation in write mode.

    [0215] With reference to [FIG. 7], an example of the structure of a discrimination device 500 according to an embodiment of the invention is shown.

    [0216] The discrimination device 500 implements the discrimination method for which various embodiments have just been described. The discrimination device may be implemented in a device in a communication network such as a terminal equipment, an equipment for accessing a local area network, such as a home gateway, a terminal or an equipment of router type.

    [0217] For example, the device 500 comprises a processing unit 530, which is equipped for example with a microprocessor μP and controlled by a computer program 510 that is stored in a memory 520 and implements the discrimination method according to the invention. On initialization, the code instructions of the computer program 510 are for example loaded into a RAM memory before being executed by the processor of the processing unit 530.

    [0218] Such a device 500 comprises: [0219] a tagging module 502, capable of [0220] adding an attribute relating to the first message to an information packet, said packet grouping attributes to which a processing is applied, [0221] applying a tag for the information packet comprising the added attribute, [0222] a transmitter 503, capable of transmitting the information packet comprising the applied tag to a data server.

    [0223] With reference to [FIG. 8], an example of the structure of a processing device according to an embodiment of the invention is shown.

    [0224] The processing device 600 implements the processing method for which various embodiments have just been described. The processing device 600 may be implemented in a device in a communication network such as a router, a firewall, a stream inspection equipment (deep packet inspection), or even a data server.

    [0225] For example, the device 600 comprises a processing unit 630, which is equipped for example with a microprocessor μP and controlled by a computer program 610 that is stored in a memory 620 and implements the processing method according to the invention. On initialization, the code instructions of the computer program 610 are for example loaded into a RAM memory before being executed by the processor of the processing unit 630.

    [0226] Such a device 600 comprises: [0227] a receiver 601 capable of receiving an information packet from a terminal equipment. [0228] a detector 602, capable of detecting an information packet comprising the attribute added by the terminal equipment, according to a tag applied to the received information packet, [0229] a processing module 603, capable of processing the attribute included in the received information packet.

    [0230] With reference to [FIG. 9], an example of the structure of a capture device 700 according to an embodiment of the invention is shown.

    [0231] The capture device 700 implements the capture method for which various embodiments have just been described. The capture device 700 may be implemented in a device in a communication network such as a router, a firewall, a stream inspection equipment (deep packet inspection), or even a data server.

    [0232] For example, the device 700 comprises a processing unit 730, which is equipped for example with a microprocessor μP and controlled by a computer program 710 that is stored in a memory 720 and implements the capture method according to the invention.

    [0233] On initialization, the code instructions of the computer program 710 are for example loaded into a RAM memory before being executed by the processor of the processing unit 730.

    [0234] Such a device 700 comprises: [0235] a receiver 704, capable of receiving a plurality of packets from a terminal equipment, [0236] an analyzer 701, capable of analyzing a plurality of packets transmitted by a terminal equipment and intended for the server, [0237] an identification module 702, capable of identifying a cooperation packet among the plurality of analyzed packets, said cooperation packet comprising the determination datum corresponding to a security key used for encrypting packets transmitted by the terminal equipment to the data server prior to the terminal equipment's sending said cooperation packet, [0238] a decryption module 703, capable of decrypting the received cooperation packet by using a security key corresponding to the determination datum of the identified cooperation packet.

    [0239] With reference to [FIG. 10], an example of the structure of a counting device 800 according to an embodiment of the invention is shown.

    [0240] The counting device 800 implements the counting method for which various embodiments have just been described. The counting device 800 may be implemented in a device in a communication network such as a terminal equipment or an equipment for accessing a local area network, such as a home gateway, or a terminal or an equipment of router type.

    [0241] For example, the device 800 comprises a processing unit 830, which is equipped for example with a microprocessor μP and controlled by a computer program 810 that is stored in a memory 820 and implements the counting method according to the invention. On initialization, the code instructions of the computer program 810 are for example loaded into a RAM memory before being executed by the processor of the processing unit 830.

    [0242] Such a device 800 comprises: [0243] a transmitter 802, [0244] capable of transmitting a plurality of packets each comprising a determination datum of a security key used for encrypting the packet, [0245] capable of transmitting a cooperation packet comprising the added counter to the data server, [0246] a computer 801, capable of incrementing a counter of the data relating to the application, in particular transmitted to the data server, and capable of adding the incremented counter to a cooperation packet comprising the determination datum corresponding to a security key used for encrypting packets from the plurality interchanged between the terminal equipment and the data server prior to sending said cooperation packet.