Method for communication between first device and remote server, corresponding method for managing communication, first device, remote server and computer program

Abstract

The invention relates to a method implemented by a remote server for managing communications of a first device, comprising: establishing (21) a first secure connection between the first device and the remote server via a first communication interface of the first device; and sending (22) an instruction for managing at least one current MAC address associated with at least one second communication interface of the first device using the first secure connection.

Description

Technical Field

[0001] The field of the invention is that of communication within at least one communication network, for example a computer network implementing the IP protocol.

[0002] More specifically, the invention relates to the management of at least one MAC (Media Access Control) address assigned to at least one interface of a device connected to a communication network.

[0003] In particular, the present invention proposes a solution that helps to protect the confidentiality of communications. Background Art

[0004] The QUIC protocol is a communication protocol based on the UDP (User Datagram Protocol) protocol of the transport layer. Compared with the TCP (Transmission Control Protocol) protocol, the QUIC protocol significantly reduces the waiting time usually observed when establishing a TCP connection.

[0005] Unlike the TLS (Transport Layer Security) protocol, the QUIC protocol encrypts not only the payload, but also the connection control information. As a result, conventional solutions for inserting application proxies cannot be directly reused for communications established using the QUIC protocol. The QUIC connection control information transmitted in plain text is kept to a strict minimum. For example, a QUIC packet includes an unencrypted header with one or more flags, one or more connection identifiers, and a packet number.

[0006] In order to support changes in the IP address of a device (such as an endpoint) without having to terminate the current QUIC connection, the QUIC protocol does not rely on transport identifiers, which are sometimes called "transport addresses", defined by the quadruplet {source IP address, source port number, destination IP address, destination port number}, but instead relies on at least one connection identifier, called a CID ("connection identifier") or CONNECTION_ID.

[0007] The QUIC specification defines two types of CIDs: destination CID and source CID.

[0008] The QUIC protocol supports a connection migration mechanism that maintains a QUIC connection active in the event that one of the addresses (or port numbers) of the devices involved in establishing and maintaining the QUIC connection changes (including address changes performed by NATs (Network Address Translations) placed on the path taken by data exchanged as part of the QUIC connection). Thus, connection migration includes switching from one transport identifier defined by the four-tuple {source address, source port, destination address, destination port} to another transport identifier. In the following, and by way of example, a communication path is identified by a transport identifier defined by the four-tuple {source address, source port, destination address, destination port}. Modifying at least one parameter in this four-tuple produces a new communication path. However, it should be noted that this definition does not require that the corresponding "physical" paths be completely or partially disjoint (in other words, modifying the at least one parameter does not mean that the physical path (i.e., the route taken by the data) is different). Devices involved in establishing and maintaining a QUIC connection can use PATH_CHALLENGE and PATH_RESPONSE frames exchanged between these devices to verify, for example, the new address used by the QUIC device that initiated the connection establishment to verify the connection migration. In the case where the remote device advertises a new address, the same connection migration process is established.

[0009] Although this solution maintains the QUIC connection in the event of a change in the communication path (i.e., in the event of a change in one of the addresses or port numbers of the 4-tuple {source IP address, source port number, destination IP address, destination port number}), it has the disadvantage of making it possible to track the communications of users of devices with which a QUIC connection has been established. This may adversely affect the confidentiality of data exchanged by users of such devices or characteristics of data of these users.

[0010] A first solution to try and limit communication tracking in case of connection migration is based on using new connection identifiers within the same QUIC connection for communications established on other paths.

[0011] However, such solutions are not sufficient to provide strict guarantees that QUIC connections cannot be tracked, especially when the same MAC address is used by devices such as terminals for communications established over different paths.

[0012] Recall in this regard that a MAC address is an identifier assigned to a network interface for communication purposes. These identifiers are usually assigned by the manufacturer of the network adapter. A MAC address is generally considered to be unique and permanent (i.e., it does not change over time), making it possible to track and identify a device, such as a terminal, even when the device is in motion.

[0013] Therefore, a new solution to improve the confidentiality of communications is needed. Summary of the invention

[0014] The present invention proposes a solution in the form of a method implemented by a remote server for managing communications of a first device, comprising:

[0015] - establishing a first secure connection between the first device and the remote server via a first communication interface of the first device,

[0016] - using said first secure connection to send instructions for managing at least one current MAC address associated with at least one second communication interface of said first device.

[0017] It should be noted that the first and second communication interfaces of the first device may be the same interface or separate interfaces. For example, the first device is a terminal (fixed or mobile, such as a computer, a smart phone, etc.) comprising one or more communication interfaces (e.g., a WLAN (wireless LAN) interface, an Ethernet interface, etc.).

[0018] The first device and the remote server may be connected to the same network, such as an access network, or to separate networks. For example, the first device is connected to a local area network, such as a home network or a company intranet. Such a network may be a hierarchical network, i.e., a network in which one or more IP routers have been deployed. The first device may be connected to the remote server via an access router. The remote server may specifically be connected to an access network or another network to which the terminal is connected. The IP connection may be provided via a wired network, a wireless network (e.g., 5G), or both.

[0019] No assumptions are made in the remainder about the nature of the devices involved or the architecture of the network(s). Similarly, no assumptions are made about the nature of the service(s) established based on the MAC address.

[0020] According to at least one embodiment of the present invention, the server may trigger a process for managing the current MAC address by transmitting an instruction for managing the current MAC address to the first device. For example, such a management instruction belongs to the group including:

[0021] - a request to update said at least one current MAC address,

[0022] - A request to extend the validity period of the at least one current MAC address.

[0023] Thus, according to at least one embodiment, the proposed solution avoids tracking communications by managing MAC addresses (e.g., when updating a current MAC address or when extending its validity period) and thus helps maintain the confidentiality of data exchanged by users of such devices or data characteristics of these users.

[0024] For example, such a process initiated by a server for managing MAC addresses is called an ADET (“Advanced Anti-Tracking System”) process.

[0025] In particular, extending the validity period of the at least one current MAC address may be more efficient in certain situations and / or for certain services, or in anticipation of a possible update request. This significantly makes the process more robust (e.g., by preventing the MAC addresses of all active interfaces of a device from being updated simultaneously).

[0026] In particular, the instruction for managing the current MAC address is sent using a secure connection, which improves the security of the exchange between the first device and the remote server.

[0027] For example, the first secure connection is based on a secure communication protocol such as QUIC, MP-QUIC (Multi-Path QUIC), or the CoAP (Constrained Application Protocol) protocol when used in conjunction with the DTLS (Datagram Transport Layer Security) protocol or the like.

[0028] When using the MP-QUIC protocol, connection migration can be replaced with a function for adding / removing a communication path between the server and the first device.

[0029] Therefore, the proposed solution provides the advantage of using functions supported by a secure communication protocol.

[0030] If the secure connection implements a protocol such as QUIC, a request to update at least one current MAC address is sent, for example, in a QUIC frame, which is referred to herein as "MAC_RENEW".

[0031] According to a particular embodiment, communication is established on a first communication path between the first device and the remote server and using the at least one current MAC address, and instructions for managing the at least one current MAC address are sent after an event related to the communication is detected, the event belonging to the group consisting of:

[0032] - the lifetime of the at least one current MAC address,

[0033] - a validity period of the at least one current MAC address, or in other words a deadline for updating the at least one current MAC address,

[0034] - Detection of a migration of said communication established on said first communication path to at least one second communication path.

[0035] According to at least one embodiment of the present invention, the remote server may therefore trigger a process for managing current MAC addresses upon detecting an event related to communication using at least one current MAC address associated with an interface of the first device.

[0036] For example, the remote server can use the at least one current MAC address associated with at least one second interface of the first device to detect long-term communication and request the first device to update the (multiple) current MAC addresses involved. In this way, the remote server can control the life of the MAC address used by the client.

[0037] As a variant, the remote server may detect the migration of the communication of at least one first communication path to at least one second communication path. For example, the remote server detects the migration of the communication after receiving a message with a new transmission identifier (eg, a new source IP address) sent by the first device.

[0038] The MAC address update request may also be sent to the first device prior to migration. For example, a QUIC notification may be transmitted by a remote server to the first device to notify it of an upcoming migration.

[0039] According to this embodiment, the risk of tracking the first device can therefore be avoided or at least reduced, especially in case of long-term communications or connection migrations.

[0040] It should be noted that such communication may be established between the first device and a server, or between the first device and a second device connected to the same network as the first device or to a separate network.

[0041] In a particular embodiment, communication is established on a first communication path between a first device and a remote server and using the at least one current MAC address, and the remote server delays data transmission on the first path for a defined period of time (e.g., approximately a few milliseconds or seconds), or as long as the remote server has not received confirmation of the association of at least one new MAC address with the at least one second interface of the first device, the remote server delays data transmission on the first path in order to continue communication on the first communication path.

[0042] The defined period may be configurable.

[0043] In other words, the remote server does not use the first communication path during the updating of at least one MAC address associated with at least one interface of the first device, and applies a delay (hereinafter referred to as a "pause" period), for example by storing data in a buffer memory. Thus, no payload is sent within a given period (e.g., approximately 100 ms).

[0044] In another specific embodiment, communication is established on a first communication path between a first device and a remote server and using the at least one current MAC address, the remote server sends data on at least one second path between the first device and the remote server within a defined time period (for example, approximately a few milliseconds or seconds, which time period is configurable), or as long as the remote server has not received confirmation of the association of at least one new MAC address with the at least one second interface of the first device, the remote server sends data on at least one second communication path between the first device and the remote server, so as to continue communication on the first communication path.

[0045] In other words, the remote server does not use the first communication path during the updating of at least one MAC address associated with at least one interface of the first device, and sends data on at least one second communication path (alternative path). Therefore, the payload can be sent on another path that is available within a given period (e.g., approximately 1 s).

[0046] In a particular embodiment, the remote server may specifically send a request to the first device to extend the validity period of a MAC address associated with an interface of the first device used to communicate with the remote server on the second path in order to ensure that the MAC address is not modified during a defined period of time, or as long as the remote server has not received a confirmation of the association of a new MAC address with the interface of the first device and used to communicate with the server on the first path.

[0047] These various embodiments prevent or at least reduce the risk of data loss when updating a MAC address.

[0048] In a particular embodiment, the instructions for managing at least one current MAC address include at least one element belonging to the group consisting of:

[0049] - one or more interface identifiers (for identifying the interface(s) on the first device to be associated with the new MAC address),

[0050] - One or more network path identifiers (for identifying currently and / or previously used communication paths between the first device and a remote server). For example, such identifiers may be addresses, address identifiers, etc.

[0051] -etc.

[0052] These identifiers, when present, may be used by the first device to select an interface associated with a MAC address to manage.

[0053] The present invention also relates to a method for communication between a first device and a remote server, the method being implemented by the first device and comprising:

[0054] - establishing a first secure connection between the first device and the remote server via a first communication interface of the first device,

[0055] - receiving, using said first secure connection, instructions for managing at least one current MAC address associated with at least one second communication interface of said first device,

[0056] - Execute said management instructions.

[0057] According to this embodiment, management of at least one MAC address of the first device is implemented at the request of the remote server.

[0058] As described above, the server may thus trigger a process for managing at least one current MAC address associated with at least one interface of the first device, for example upon detecting an event related to a communication using the current MAC address.

[0059] In particular, in at least one embodiment, the proposed solution avoids tracking communications by managing MAC addresses and thus helps maintain the confidentiality of data exchanged by users of such devices or characteristics of data of these users.

[0060] In certain embodiments, execution of the management instructions includes associating at least one new MAC address with the at least one second interface.

[0061] In this way, at least one current MAC address may be updated and replaced with a new MAC address.

[0062] In a particular embodiment, the at least one new MAC address is selected such that it cannot be correlated with the at least one current MAC address.

[0063] In this way, a malicious device cannot detect that these MAC addresses are associated with the same device.

[0064] In particular, recall that if the same MAC address associated with at least one terminal interface is exposed on different communication paths, communications established on different paths can be correlated.

[0065] According to this embodiment, the proposed solution therefore provides a solution that helps to maintain the confidentiality of communications by avoiding exposing information making it possible to infer the presence of a migration of a communication established on a first communication path to a communication established on at least one second communication path.

[0066] In certain embodiments, the association of at least one new MAC address with the at least one second interface implements a conventional MAC address update technique, such as a MAC address random generation technique (randomization).

[0067] In another embodiment, the association of at least one new MAC address with said at least one second interface implements a new technique referred to herein as MUSC (Utility MAC Address Update for Service Continuity), as described in French patent application FR 2205880 filed on 16 / 06 / 2022.

[0068] In particular, this process can be implemented when the at least one current MAC address is used to communicate with at least one second device located on the communication path between the first device and the remote server, or to communicate via at least one second device, or to communicate with an intermediate device located on the communication path between the first device and the second device, or to communicate via the intermediate device.

[0069] In particular, such a second device may be an access router connecting said first device to a remote server.An intermediate device may be another router located on the path between the first device and the second device.

[0070] For example, a first device implements:

[0071] - establishing a second secure connection between the first device and the second device via a third communication interface of the first device,

[0072] - Using the second secure connection to send a message comprising at least one encrypted MAC address, the at least one encrypted MAC address being associated with or capable of being associated with the third interface and being used to communicate with or via the second device or the intermediate device.

[0073] It should be noted that the first, second and third communication interfaces of the first device may be the same interface or separate interfaces.

[0074] Thus, according to this embodiment of the invention, the first device can declare to the second device its current MAC address for communicating with or via the second device, or at least one candidate MAC address that it wants to use for communicating with or via the second device. Encrypting at least one MAC address increases the confidentiality of the information item sent. In addition, this embodiment allows the MAC address / these MAC addresses to be passed to the second device when the second device is not directly connected to the first device (for example in the case of a hierarchical network). Finally, the device receiving the message can compare the source MAC address of the message (which can be carried in plain text in the message header) with the encrypted MAC address declared in the message in order to detect any fraudulent manipulation of the MAC address.

[0075] Thus, according to at least one embodiment, the proposed solution helps to maintain the confidentiality of communications.

[0076] For example, the second secure connection is based on a secure communication protocol, such as the QUIC protocol, CoAP over DTLS protocol, etc. Therefore, the proposed solution provides the advantage of using functionality supported by a secure communication protocol, rather than simply relying on the use of MAC addresses. The use of a secure channel and the encryption of MAC addresses are particularly helpful for obtaining authorization to access the network based on the MAC address, even if the access control is activated by a device that is not on the same link (i.e., located several IP hops away).

[0077] The message corresponds, for example, to at least one frame belonging to the group comprising:

[0078] a frame describing a current MAC address used by the first device to communicate with or via the second device, such as a QUIC frame referred to herein as “CURRENT_MAC_ADDRESS”,

[0079] a frame describing a candidate MAC address that the first device intends to use to communicate with or via the second device, such as a QUIC frame referred to herein as a “CANDIDATE_MAC_ADDRESS”,

[0080] - A frame that describes a list of MAC addresses that a first device intends to use to communicate with or via a second device, such as a QUIC frame referred to herein as "LIST_MAC_ADDRESS."

[0081] In a particular embodiment, the proposed solution specifically provides continuity of service even in case of a MAC address update.

[0082] In particular, the proposed solution does not require any explicit authentication or establishment of a security association between a first device (eg, a terminal) and a second device (eg, an access router) for each packet exchange with a device external to the network.

[0083] In certain embodiments, the first device and the server may exchange messages to confirm that they are capable of implementing the present invention in accordance with at least one embodiment.

[0084] For example, the first device implements sending a first parameter signaling to the server, that is, the first device supports a MAC address management process (ADET process) initiated by the server. For example, upon receiving the first parameter, the server also implements sending a second parameter signaling to the first device, that is, the server can manage the MAC address of the first device.

[0085] For example, such parameter is a QUIC transport parameter, referred to herein as "mac-update", and is set to "1" to indicate that a device sending a QUIC message including such parameter supports the method according to the present invention.

[0086] Such parameter exchange may be implemented before the server sends a MAC address management instruction.

[0087] In other embodiments, the present invention relates to a corresponding first device and a remote server.

[0088] One embodiment of the present invention is also intended to protect one or more computer programs and at least one computer-readable data medium, wherein the one or more computer programs include instructions suitable for implementing at least one step of the method according to at least one embodiment of the present invention as described above when the program or these programs are executed by a processor, and the at least one computer-readable data medium includes instructions of at least one computer program as described above. BRIEF DESCRIPTION OF THE DRAWINGS

[0089] Other characteristics and advantages of the invention will appear more clearly on reading the following description of specific embodiments provided as simple illustrative and non-limiting examples and the accompanying drawings, in which:

[0090] - Figure 1 An example of a network architecture is shown;

[0091] - Figure 2 The main steps implemented by the first device and the remote server according to at least one embodiment of the present invention are shown;

[0092] - Figure 3 shows a parameter exchange for verifying compatibility of a first device and a remote device according to one embodiment of the present invention;

[0093] - Figure 4 An example of a network architecture implementing a MUSC process on one of the communication paths between a first device and a remote server is shown;

[0094] - Figure 5 shows an example of messages exchanged between a first device, a first access router, and a remote server when implementing a MUSC process after receiving a management instruction from a remote server;

[0095] - Figure 6 An example of a network architecture for implementing the MUSC process on each available communication path after receiving management instructions from a remote server is shown;

[0096] - Figure 7 shows examples of messages exchanged between a first device, a first access router, and a remote server, and between a first device, a second access router, and a remote server when implementing a MUSC process for each available communication path after receiving a management instruction from a remote server;

[0097] - Figure 8 A simplified structure of a first device (respectively, a second remote server) according to a specific embodiment is shown. DETAILED DESCRIPTION

[0098] Basic principles

[0099] The general principle of the invention is based on managing, by a remote server, at least one current MAC address associated with at least one communication interface of a first device in order to limit the risk of the first device being tracked and thus help maintain the confidentiality of communications.

[0100] The first device and the remote server may be connected to the same network, such as an access network, or to separate networks. Figure 1 As shown, the first device H 11 is considered as a multi-interface terminal, which can connect to one or more access networks using the same interface or separate interfaces.

[0101] In the following, it is considered that the first device is connected to at least one access network, for example, to a first access network NET. #1 121 and a second access network NET. #2 122. The remote server S 13 can be connected to an external network, such as a network of an operator, with which the user of the first device has subscribed to an Internet service provider 131 (ISP, Internet Service Provider) or another network managed by a third party, or directly connected to the access network NET. #1 121 and / or NET. #2 122. The first device 11 can communicate with the remote server 13 via a first access router R1 1211 of the first access network NET. #1 121, and / or via a second access router R2 1221 of the second access network NET. #2 122.

[0102] As previously mentioned, other network architectures or other types of equipment may be used in the context of the present invention.

[0103] As discussed with respect to the prior art, the first device 11 conventionally uses the same MAC address (e.g., @MAC1) to communicate with the server 13 regardless of the communication path used (the first communication path via the first access router 1211 or the second communication path via the second access router 1221), especially when the same interface is used to connect to these access networks. In other words, the same MAC address is exposed on various communication paths, and the communications established on these various paths can be correlated. Therefore, even in the case where the access network to which the first device is connected changes, a malicious device can easily track the communications from the first device 11.

[0104] The proposed solution makes it possible to manage at least one MAC address associated with at least one interface of the first device 11, for example by modifying the MAC address in the event of a migration of communication from a first communication path to at least one second communication path. The same procedure can also be used when maintaining communication on several communication paths (i.e. when using resources associated with various paths simultaneously without communication migration). It is also possible to control the lifetime of a MAC address, or to extend its validity period, for example, depending on the service called.

[0105] Figure 2 The remote server and the first device (eg, Figure 1 The main steps of the method according to at least one embodiment of the present invention are implemented by a server 13 and a first device 11).

[0106] During a first step 21, a first secure connection is established between the first device and a remote server via a first communication interface of the first device. The establishment of such a secure connection is conventional and will not be described in more detail here.

[0107] The server 13 may then send (22) to the first device 11 using the first secure connection instructions for managing at least one current MAC address associated with at least one second communication interface of the first device (the first and second communication interfaces may be the same interface or separate interfaces).

[0108] Such a management instruction is, for example, a request to update the current MAC address or a request to extend the validity period of the current MAC address.

[0109] For example, when the usage period of the current MAC address is greater than a defined period, when the validity period of the current MAC address is reached (corresponding to the deadline for updating the current MAC address) and / or after the communication established on the first communication path is migrated to at least one second communication path, etc., the server can trigger the transmission of instructions for managing at least one MAC address.

[0110] Thus, the first device 11 may use the first secure connection to receive ( 23 ) instructions for managing at least one current MAC address associated with at least one second communication interface of the first device.

[0111] The first device may then execute (24) corresponding management instructions, such as updating the current MAC address @MAC1 and associating at least one new MAC address @MAC2 with a relevant interface of the first device.

[0112] According to certain embodiments, the first device may implement conventional procedures for associating at least one MAC address with at least one of its interfaces.

[0113] In another embodiment, the first device may implement a new procedure for associating at least one MAC address with at least one of its interfaces, called the MUSC procedure, as described in the above-mentioned French patent application FR 2205880.

[0114] Such a MUSC process may specifically be performed between a first device and a second device (eg, Figure 1 The method is implemented between the first access router 1211 and / or the second access router 1221).

[0115] Example

[0116] Various embodiments of the invention are described below, according to which the first secure connection between the server and the first device uses the QUIC protocol. As already indicated, in other embodiments, the first secure connection may use CoAP over the DTLS protocol or any other protocol that establishes a secure connection. No assumptions are made about the use of the QUIC protocol. The proposed solution may also be applied to QUIC communications established over several paths by using MP-QUIC resources. The use of all or part of these various paths may be negotiated between the server and the first device.

[0117] like Figure 3 As illustrated in , according to a specific embodiment, the first device can use new QUIC transmission parameters (as provided in Section 7.4.2 of document RFC 9000, May 2021) (referred to herein as "mac-update") to signal to the server that it supports a MAC address management procedure (ADET procedure) initiated by the server. For example, the first device 11 implements sending 31 first parameter signaling to the server 13, i.e., the first device 11 is able to use the first secure connection to modify its current MAC address or extend its validity period. If the server also supports the ADET procedure, it can respond using the new "mac-update" QUIC transmission parameters, also using the first secure connection. In other words, the server 13 implements sending 32 second parameter signaling to the first device 11, i.e., the server 13 is able to manage at least one MAC address associated with at least one interface of the first device.

[0118] These first and second parameters are, for example, set to "1" (mac-update=0x1) to indicate support of the ADET procedure.

[0119] The server may then send a MAC address management instruction to the first device, such as a request to update at least one of its current MAC addresses in a QUIC frame, referred to herein as “MAC_RENEW” 33.

[0120] Below about Figure 4 and Figure 5 One embodiment of the present invention is presented.

[0121] Figure 4 An example of a network architecture is shown, according to which the first device 11 can communicate with the remote server 13 via the first access router R1 1211 of the first access network NET. #1 121.

[0122] Figure 5shows an example of messages exchanged between the first device 11, the first access router 1211, and the remote server 13 when implementing the MUSC process after receiving a management instruction from the remote server;

[0123] A QUIC Connect. #1 secure connection (51) is established between the first device 11 and the server 13. The QUIC Connect. #1 secure connection established between the first device 11 and the server 13 via the first access router 1211 is characterized by a connection identifier CID (particularly a source CID).

[0124] As about Figure 3 As explained, according to one embodiment of the present invention, a "mac-update" QUIC transport parameter may be exchanged between the first device 11 and the server 13 to verify that they support a MAC Address Management Procedure (ADET Procedure).

[0125] It is assumed hereinafter that the first device 11 and the server 13 support the ADET procedure.

[0126] Through the first communication path via the first access router 1211, data D can be exchanged between the first device 11 and the server 13, in particular, via the QUIC connection #1 secure connection.

[0127] For example, it is considered that the server 13 detects that the first device 11 has established a long-term communication (e.g., longer than a given threshold recommended for the current service) with a second device located on the first communication path (e.g., with the server 13 or with the first access router 1211), and communicates with the second device or via the second device using the current MAC address @MAC1 associated with the communication interface of the first device.

[0128] The server 13 may then trigger a MAC address management procedure in order to prevent the first device from permanently establishing communications based on the use of the same MAC address.

[0129] To this end, the server 13 may transmit a request to update the @MAC1 address used by the first device 11 so that the MAC address used to send packets on the first path is modified. The server 13 may transmit a MAC_RENEW frame to the first device 11, for example, via the QUIC connection #1 secure connection, and then a MAC address negotiation cycle may be triggered.

[0130] In particular, a MUSC process may be implemented between the first device 11 and the second device to associate a new MAC address with an interface used by the first device to communicate with or via the second device. For example, the second device is considered to be the first access router 1211.

[0131] To this end, a QUIC connection #2 secure connection (52) is established between the first device 11 and the first access router 1211. For example, such a secure connection uses the QUIC protocol, CoAP over DTLS protocol, etc.

[0132] The first device 11 may then use the QUIC connection #2 secure connection to send a message to the first access router 1211. Such a message includes at least one encrypted MAC address that is associated with or can be associated with the considered interface of the first device and is used to communicate with or via the first access router 1211, or to communicate with or via an intermediate device located on the communication path between the first device and the first access router 1211.

[0133] Thus, the first access router 1211 may receive such a message and verify the received MAC address(es).

[0134] Various types of messages may be transmitted from the first device 11 to the first access router 1211 .

[0135] exist Figure 4 In the example of , the first device 11 can generate at least one new MAC address @MAC2 and send this new address @MAC2 encrypted in the message using the QUIC connection #2 secure connection. The first access router 1211 can then verify the new address @MAC2 and, if applicable, update the filtering rules it maintains.

[0136] For example, once the new address @MAC2 is associated with the considered interface of the first device, the new address @MAC2 becomes the current MAC address associated with the considered interface. A message corresponding to at least one QUIC frame may then be sent from the first device 11 to the first access router 1211, the QUIC frame describing the current MAC address used by the first device to communicate with or via the first access router 1211, referred to herein as "CURRENT_MAC_ADDRESS", for example.

[0137] Insertion of the current MAC address in the new frame and thus its encryption in connection with the use of the QUIC secure connection enables the first access router 1211 to compare the information carried in the encrypted portion of the message (e.g., the current MAC address) with the information communicated in the plain text in the QUIC connection (e.g., the source MAC address) and detect any manipulation of the information communicated in the plain text. Insertion of the current MAC address in the new frame also allows the current MAC address to be communicated to the first access router 1211 even if it is not directly connected to the first device (e.g., in the case of an intermediate device such as a router).

[0138] The first device 11 can then communicate with the server 13 using the first QUIC connection #1 secure connection (53) via the first access router 1211 using the address @MAC2.

[0139] It should be noted that before sending encrypted messages via the QUIC connection #2 secure connection, according to one embodiment of the present invention, "mac-update" QUIC transmission parameters can be exchanged between the first device 11 and the first access router 1211 to verify that they support the MUSC process.

[0140] For example, the first device uses a new "mac-update" QUIC transmission parameter to signal that it supports the MUSC procedure to the first access router 1211. If the first access router 1211 also supports the MUSC procedure, it may respond using a new "mac-update" QUIC transmission parameter.

[0141] These first and second parameters are, for example, set to "1" (mac-update=0x1) to indicate support of the MUSC process.

[0142] about Figure 6 and Figure 7 , another exemplary embodiment of the present invention is now presented, according to which the MUSC procedure may be implemented before the ADET procedure. In fact, no assumptions are made about the order in which these various steps of the present invention are invoked.

[0143] Figure 6 An example of a network architecture is shown, according to which the first device 11 can communicate with the remote server 13 via the first access router R1 1211 of the first access network NET. #1 121 and / or via the second access router R2 1221 of the second access network NET. #2 122.

[0144] Figure 7 shows examples of messages exchanged between the first device 11, the first access router 1211, and the server 13, and between the first device 11, the second access router 1221, and the server 13 when the MUSC process is implemented for each available communication path between the first device and the remote server after receiving a management instruction from the remote server;

[0145] According to this second example, the MUSC process may be implemented between the first device 11 and a second device located on a communication path between the first device 11 and the server 13. For example, a first MUSC process may be implemented between the first device 11 and the first access router 1211, and a second MUSC process may be implemented between the first device 11 and the second access router 1221. As many MUSC processes as communication paths between the first device 11 and the server 13 may be implemented.

[0146] The first MUSC program implements the following steps.

[0147] QUIC Connection #1 A secure connection (71) is established between the first device 11 and the first access router 1211. For example, such a secure connection uses the QUIC protocol, or as a variation, uses CoAP over DTLS protocol, etc.

[0148] As described above, according to one embodiment of the present invention, it is possible to exchange "mac-update" QUIC transmission parameters between the first device 11 and the first access router 1211 to verify that they support the MUSC process.

[0149] The first device 11 can then use the QUIC connection #1 secure connection to send a message to the first access router 1211. Figure 5 As indicated, such a message includes at least one encrypted MAC address that is associated with or capable of being associated with the considered interface of the first device and is used to communicate with or via the first access router 1211, or to communicate with or via an intermediate device located on a communication path between the first device and the first access router 1211.

[0150] Thus, the first access router 1211 may receive such a message and verify the received MAC address(es).

[0151] Various types of messages may be transmitted from the first device 11 to the first access router 1211 .

[0152] According to a first example, the message corresponds to a "CURRENT_MAC_ADDRESS" QUIC frame describing the current MAC address used by the first device to communicate with or via the first router access 121. Thus, such current MAC address has been assigned to the interface used to contact the first access router 1211.

[0153] According to a second example, the first device 11 may prepare for MAC address migration by first indicating to the first access router 1211 at least one MAC address (referred to as a candidate MAC address) that it plans to use.

[0154] According to this second example, a message is sent from the first device 11 to the first access router 1211 via the first QUIC connection. For example, secure connection #1 corresponds to a QUIC frame, referred to herein as "LIST_MAC_ADDRESS," including at least one cryptographic candidate MAC address (e.g., a5:c7:ef:82:58:e9, e1:44:5c:32:3c:72, ee:3c:50:18:7e:44) that the first device intends to use to communicate with or via the first access router 1211. At this stage, none of these candidate MAC addresses are associated with the considered interface of the first device 11.

[0155] In particular, the first device 11 may verify with the first access router 1211 that the candidate MAC address is available before associating the candidate MAC address with the interface of the first device 11. In particular, this makes it possible to avoid conflicts with MAC addresses used by other devices connected to the same network and to avoid affecting service access time due to MAC address changes.

[0156] According to a third example, a message is sent by the first device 11 via a QUIC connection to the first access router 1211. The #1 secure connection corresponds to a QUIC frame including at least one encrypted candidate address, for example referred to herein as "CANDIDATE_MAC_ADDRESS".

[0157] Thus, according to these various examples, a first device implements a MUSC process to associate a MAC address with at least one of its interfaces and to verify the MAC address.

[0158] As a variant, the first device may use a default MAC address configured, for example, by a user of the first device or by an operating system.

[0159] exist Figure 7 In the example illustrated in , consider, for example, that the first device 11 sends a message corresponding to a “CURRENT_MAC_ADDRESS” QUIC frame with address @MAC1 to the first access router 1211 .

[0160] A QUIC Connection #2 secure connection (72) is also established between the first device 11 and the server 13 (before, during, or after establishing the QUIC Connection #1 secure connection). Several connection identifiers may be used.

[0161] For example, the QUIC connection #2 secure connection established between the first device 11 and the server 13 via the first access router 1211 (respectively, the second access router 1221) is characterized by a first (respectively, second) connection identifier, in particular a source CID pre-negotiated (Section 19.15 of RFC 9000) with the server 13. Therefore, it is considered that there is only one single secure connection between the first device 11 and the server 13, corresponding to the various communication paths between the first device 11 and the server 13.

[0162] As about Figure 3 As explained, according to one embodiment of the present invention, a "mac-update" QUIC transport parameter may be exchanged between the first device 11 and the server 13 to verify that they support the MAC Address Management Procedure (ADET).

[0163] In particular, data D may be exchanged between the first device 11 and the server 13 via a first communication path via the first access router 1211, via a QUIC connection #2 secure connection.

[0164] For example, if the first device 11 is mobile or if traffic via the first access router 1211 is congested, the first device 11 may migrate communication established with the server 13 over a first path via the first access router 1211 to a second path via the second access router 1221 .

[0165] Consider, for example, the use of server 13 detecting new transmission identifiers (e.g., when data packets from first device 11 and destined for server 13 arrive via at least one new path or a new source IP address during a connection migration attempt). For example, server 13 detects that it is receiving data packets from various source addresses.

[0166] According to one embodiment of the present invention, the server 13 may trigger a MAC address management process to prevent the first device from still using the current MAC address @MAC1 to communicate with the second access router 1221 or to communicate via the second access router 1221 .

[0167] To this end, the server 13 may transmit a request to update the address @MAC1 used by the first device 11 so that the MAC address used to send packets via the second path is different from the MAC address used to send data on the first path. The server 13 may transmit a MAC_RENEW frame to the first device 11, for example, via the QUIC Connection #2 secure connection, and may trigger a MAC address negotiation cycle. Recall that the order of the various QUIC Connection #1 (71) and QUIC Connection #2 (72) secure connections is not important.

[0168] In particular, a MUSC process may be implemented between the first device 11 and the second router access 1221 to associate a new MAC address with an interface used by the first device to communicate with or via the second router access 1221 .

[0169] To this end, a QUIC connection #3 secure connection is established between the first device 11 and the second access router 1221 (73). For example, such a secure connection uses the QUIC protocol, or as a variant, uses CoAP over DTLS protocol, etc.

[0170] exist Figure 7 In the example of , the first device 11 can generate at least one new MAC address @MAC2 and send this new address @MAC2 encrypted in the CURRENT_MAC_ADDRESS message using the QUIC connection #3 secure connection. The second access router 1221 can then verify the new address @MAC2 and, if applicable, update the filtering rules it maintains.

[0171] The first device 11 can then communicate with the server 13 using the QUIC connection #2 secure connection (74) via the second access router 1221 using the address @MAC2. A new connection identifier can be used during the migration. This identifier can be pre-exchanged according to the procedure described in Section 19.15 of RFC 9000.

[0172] Therefore, a QUIC connection #2 secure connection is established on two paths via the first access router 1211 and via the second access router 1221, and either or both of the paths can be used to exchange data between the first device 11 and the server 13.

[0173] In certain embodiments, as a variant or in addition, the remote server may transmit a request to extend the validity period of at least one current MAC address (e.g., address @MAC1 used for communication on the first path). Thus, address @MAC1 may be retained for communication via the first access router 1211, and address @MAC2 may be used for communication via the second access router 1221. It should be noted that the MAC addresses used on the alternative path are not passed to the access routers located on other paths.

[0174] Therefore, even if the same interface of the first device 11 will be used for communication with various access networks, the proposed solution can negotiate different MAC addresses for the first device 11 according to the access network to which it is attached. For example, the first device 11 can communicate with the first access router 1211 via the first interface of the first device 11 using the MAC address @MAC1, and the first device 11 can communicate with the second access router 1221 via the first interface of the first device 11 using the MAC address @MAC2.

[0175] In these various embodiments, the new MAC address(es) are selected such that it / they cannot be correlated with the current MAC address(es) in order to prevent tracking of the first device. Thus, the first device uses a new MAC address that cannot be correlated with a previously used MAC address, e.g., within the last 24 hours.

[0176] According to at least one embodiment, the first device 11 can in particular establish a secure connection with the server 13 (according to Figure 5 QUIC connection #1 or according to Figure 7 QUIC connection #2) sends a message to confirm its MAC address update.

[0177] For example, such a message sent from the first device to the server is referred to herein as “MAC_RENEWED” and comprises a new MAC address associated with the considered interface of the first device 11 .

[0178] According to at least one embodiment, communication using the current MAC address @MAC1 is established on a first communication path via the first access router 1211, and the remote server 13 delays the transmission of data on the first path for a defined period of time or as long as the remote server has not received confirmation of the association of at least one new MAC address with the first device, the remote server 13 delays the transmission of data on the first path in order to continue the communication on the first path (for example, as long as the remote server has not received a MAC_RENEWED message).

[0179] In other words, the server 13 may apply a "pause" period during the updating of the MAC address of the first device 11 associated with the first path in order to avoid or at least reduce the risk of packet loss when the MAC address is modified by the first device 11 according to an indication received from the server 13. For example, the server 13 does not transmit any payload on the first path for a short configurable period (e.g., approximately 100 ms).

[0180] According to at least one embodiment, communication using the current MAC address @MAC1 is established on a first communication path via the first access router 1211, and the remote server 13 sends data on at least one other path within a defined time period, or as long as the remote server has not received confirmation of the association of at least one new MAC address with the first device, sends data on at least one other path in order to continue communication on the first path (for example, as long as the remote server has not received a MAC_RENEWED message).

[0181] In other words, the server 13 may use another path during the updating of the MAC address of the first device 11 associated with the first path, so as to avoid or at least reduce the risk of packet loss when the MAC address is modified by the first device 11 according to the indication received from the server 13. For example, the server 13 transmits the payload on at least one other available path (e.g., the second path via the second access router) within a short configurable period (e.g., about 1 s). It may also transmit the data in duplicate via the first path and via at least one other available path, so as to ensure that the first device receives the payload.

[0182] According to certain embodiments, the server may send a request to extend the validity period of the MAC address @MAC2 used for communication on the second path while updating the MAC address @MAC1 used for communication on the first path.

[0183] According to at least one embodiment, the first device may reject the implementation of the ADET procedure, in particular if a similar management instruction has been received (e.g., the same instruction has been received multiple times, a similar management instruction has been received from another server, etc.) or conflicts with a previously received management instruction. To this end, a new error message may be sent by the first device to the server, for example using a new QUIC frame referred to herein as "REJECT_MAC_RENEW".

[0184] In the embodiment presented above, the server 13 initiates an update of at least one MAC address of the first device. Therefore, the server transmits a "MAC_RENEW" QUIC frame to the first device. However, it is considered that the first device cannot transmit a "MAC_RENEW" QUIC frame to the server. In other words, the first device does not initiate an update of at least one MAC address associated with one of its interfaces. If the server receives a "MAC_RENEW" message, the server may ignore it.

[0185] The above has been about Figure 6 and Figure 7An implementation of a MUSC process for associating a MAC address on an interface of a first device for all paths available between the first device and a server is described. As a variant, such a process may be implemented only on certain paths. As a variant, such a process may be implemented upon receiving a MAC address update request transmitted by a remote server (a MAC_RENEW QUIC frame is received by the first device).

[0186] According to one embodiment, a new MAC address may be generated for at least one interface or one path of the first device in a conventional manner. In this case, the first device locally implements a process for generating a MAC address that cannot be associated with a MAC address used in the past (e.g., within the past 24 hours).

[0187] In a particular embodiment, the MAC address random generation is implemented locally by the first device. In particular, the server may request the first device to prolong the validity of at least one MAC address associated with at least one of its interfaces (which may be the interface for which the address update is performed or another interface, in particular in the case of short-term communications).

[0188] Compatible devices

[0189] Finally, about Figure 8 , presents a simplified structure of a first device H and a server S according to at least one embodiment of the present invention.

[0190] According to an embodiment of the present invention, the first device H (correspondingly, the server S) includes a memory 81 H (Accordingly, 81 S )、Processing unit 82 H (Correspondingly, 82 S ), which is equipped with, for example, a programmable computing machine or a dedicated computing machine, such as a processor P, and is controlled by a computer program 83 H (Accordingly, 83 S ) control to implement the steps of the communication method (correspondingly, the communication management method) according to at least one embodiment of the present invention.

[0191] During initialization, the computer program 83 H (Correspondingly 83 S ) is executed by the processing unit 82 H (Correspondingly 82 S ) are loaded into RAM memory before being executed by the processor.

[0192] The processing unit 82 of the first device H The processor according to the computer program 83 H The instructions implement the steps of the previously described communication method to:

[0193] - establishing a first secure connection between the first device and the remote server via a first communication interface of the first device,

[0194] - using said first secure connection to send instructions for managing at least one current MAC address associated with at least one second communication interface of said first device.

[0195] The processing unit 82 of the server S The processor according to the computer program 83 S The instructions implement the steps of the previously described communication management method to:

[0196] - establishing a first secure connection between the first device and a remote server via a first communication interface of the first device,

[0197] - receiving, using said first secure connection, instructions for managing at least one current MAC address associated with at least one second communication interface of said first device,

[0198] - Execute said management instructions.

Claims

1. A method implemented by a remote server (13) for managing communications of a first device (11), comprising: - establishing (21) a first secure connection between the first device and the remote server via a first communication interface of the first device, the first device and the remote server being connected to separate networks, - using said first secure connection to send (22) instructions for managing at least one current MAC address associated with at least one second communication interface of said first device, said instructions being sent for execution of the management instructions by said first device.

2. The method according to claim 1, characterized in that establishing communication on a first communication path between the first device (11) and the remote server (13) and using the at least one current MAC address, sending the instruction for managing the at least one current MAC address after detecting an event related to the communication belonging to the group comprising: - the lifetime of the at least one current MAC address, - a validity period of the at least one current MAC address, - Detection of a migration of said communication established on said first communication path to at least one second communication path.

3. The method according to any one of claims 1 and 2, characterized in that Communication is established on a first communication path between the first device (11) and the remote server (13) and using the at least one current MAC address, the remote server delaying data transmission on the first path for a defined period of time, or as long as the remote server has not received confirmation of the association of at least one new MAC address with the at least one second interface of the first device, the remote server delaying data transmission on the first path in order to continue the communication on the first communication path.

4. The method according to any one of claims 1 to 3, characterized in that Communication is established on a first communication path between the first device (11) and the remote server (13) and using the at least one current MAC address, the remote server sending data on at least one second communication path between the first device and the remote server within a defined period of time, or as long as the remote server has not received confirmation of the association of at least one new MAC address with the at least one second interface of the first device, the remote server sending data on at least one second communication path between the first device and the remote server, so as to continue the communication on the first communication path.

5. The method according to any one of claims 1 to 4, characterized in that The instructions for managing at least one current MAC address include at least one element belonging to the group consisting of: - at least one identifier for identifying said at least one second communication interface, - at least one identifier of a communication path for identifying at least one currently and / or previously used communication path between said first device (11) and said remote server (13).

6. A method for communication between a first device (11) and a remote server (13), the method being implemented by the first device, comprising: - establishing (21) a first secure connection between the first device and the remote server via a first communication interface of the first device, the first device and the remote server being connected to separate networks, - using said first secure connection to receive (23) instructions for managing at least one current MAC address associated with at least one second communication interface of said first device, -Execute (24) the management instruction.

7. The method according to claim 6, characterized in that Execution of the management instructions enables association of at least one new MAC address with the at least one second interface.

8. The method according to claim 7, characterized in that The at least one new MAC address is selected such that the at least one new MAC address cannot be correlated with the at least one current MAC address.

9. The method according to any one of claims 6 to 8, characterized in that The at least one current MAC address is used to communicate with at least one second device (1211, 1221) located on the communication path between the first device (11) and the remote server (13), or to communicate via the at least one second device (1211, 1221), or to communicate with an intermediate device located on the communication path between the first device and the second device, or to communicate via the intermediate device.

10. The method according to claim 9, characterized in that The method comprises: - establishing a second secure connection between the first device (11) and the second device (1211, 1221) via a third communication interface of the first device, - Using the second secure connection to send a message comprising at least one encrypted MAC address, the at least one encrypted MAC address being associated with or capable of being associated with the third interface and being used to communicate with or via the second device or the intermediate device.

11. The method according to any one of claims 1 to 10, characterized in that The first and / or second secure connection implements the QUIC protocol.

12. The method according to any one of claims 1 to 11, characterized in that The instructions for managing at least one current MAC address belong to the group consisting of: - a request to update said at least one current MAC address, - A request to extend the validity period of said at least one current MAC address.

13. A remote server (13), comprising at least one processor, wherein the at least one processor is configured to: - establishing a first secure connection between the first device (11) and the remote server via a first communication interface of the first device (11), the first device and the remote server being connected to separate networks, - using said first secure connection to send instructions for managing at least one current MAC address associated with at least one second communication interface of said first device, for execution of said management instructions by said first device.

14. A first device (11), comprising at least one processor, wherein the at least one processor is configured to: - establishing a first secure connection between the first device and a remote server (13) via a first communication interface of the first device, the first device and the remote server being connected to separate networks, - receiving, using said first secure connection, instructions for managing at least one current MAC address associated with at least one second communication interface of said first device, - Execute said management instructions.

15. A computer program comprising instructions which, when executed by a processor, cause the processor to implement the steps of the method according to any one of claims 1 to 12.

Images