Brevet FR3094163A1 — publié le 20200925

Description Titre de l'invention : Procédé de sécurisation de la transmission d'au moins un paquet de données le long d'un chemin de données d'un réseau de télécommunications, produit programme d'ordinateur et dispositif correspondants. Domaine de l'invention [0001] Le domaine de l'invention est celui de la mise en oeuvre des réseaux de télécommu- nications. L'invention se rapporte plus particulièrement à la sécurisation de la transmission de données dans de tels réseaux de télécommunications. [0002] L'invention a de nombreuses applications, notamment, mais non exclusivement, dans le domaine des réseaux de télécommunications de dernières générations ou de générations futures. Art antérieur et ses inconvénients [0003] Il existe des méthodes permettant de vérifier le passage de paquets de données par une succession de noeuds d'un chemin de données d'un réseau de télécommunications. Plus particulièrement, ces méthodes sont adaptées pour vérifier le passage dans des noeuds dits de confiance, c'est-à-dire connus de l'entité en charge de la vérification des entités du réseau. A titre d'exemple, on peut citer le protocole PoT (pour « Proof of Transit » en anglais) développé par Cisco® et standardisé au sein de l'IETF (pour « Internet Engineering Task Force » en anglais). [0004] Cependant, de telles méthodes sont la plupart du temps dites « administrées » dans le sens où elles supposent une pré-configuration des noeuds du chemin sur lequel on veut pratiquer la vérification. Dans le cas du protocole PoT, cette pré-configuration est complexe et lourde : L'algorithme de calcul est fonction de la topologie du chemin Par exemple, la puissance du polynôme utilisé pour la vérification dépend du nombre de noeuds du chemin de données. De plus la protection de l'algorithme nécessite la détermination dynamique de polynômes associant les routeurs d'extrémités du chemin de données. De même, de telles méthodes ne supportent pas de variations sur le chemin de données et s'appliquent donc à des réseaux dont la topologie est très maitrisée. [0005] Par ailleurs, de telles méthodes ne permettent que de prouver le passage de paquets de données par des noeuds de confiance d'un chemin de données, mais ne disent rien sur ce qui se passe entre deux de ces noeuds de confiance. [0006] Il existe ainsi un besoin pour une technique permettant de sécuriser la transmission de données le long d'un chemin de données en permettant d'estimer si une modification de topologie a pu se produire le long du chemin de données entre deux noeuds de confiance, e.g. si un dispositif tiers qui ne fait pas partie des dispositifs de confiance 2 a été ajouté sur le chemin de données, ou si une partie des fonctions matérielles implantées le long du chemin ont été déportées de manière virtualisée. [0007] Il existe également un besoin pour que la technique en question soit simple à mettre en oeuvre. Exposé de l'invention [0008] Dans un mode de réalisation de l'invention, il est proposé un procédé de sécurisation de la transmission d'au moins un paquet de données le long d'un chemin de données d'un réseau de télécommunications. Selon un tel procédé, un dispositif de sécurisation effectue les étapes suivantes : - obtention d'un délai d'errance représentatif d'un écart. entre un délai de transit de bout-en-bout effectif dudit au moins un paquet de données le long du chemin de données et un délai de transit de bout-en-bout attendu dudit au moins un paquet de données le long du chemin de données ; et - sécurisation de la transmission par mise en oeuvre d'au moins une action de sécurisation à partir du délai d'errance. [0009] Ainsi, l'invention propose une solution nouvelle et inventive pour sécuriser la transmission de données dans un réseau de télécommunications. [0010] Plus particulièrement, l'obtention d'un délai d'errance associé à un paquet ayant suivi un chemin de données donné permet de déterminer si le délai qu'il a effectivement mis pour parcourir le chemin en question (i.e. le délai de transit de bouten-bout effectif le long du chemin de données, le chemin s'étendant entre deux noeuds quelconques du réseau) est différent du délai tel qu'attendu, par exemple en tenant compte des contraintes connues d'implémentation physique du chemin de données, pour parcourir le chemin en question (i.e. le délai de transit de bout-en-bout attendu le long du chemin de données). Si tel est le cas, il peut être déduit que le chemin en question a été modifié, par exemple quand un dispositif tiers qui ne fait pas partie des dispositifs de confiance a été ajouté sur le chemin de données, ou si une partie des fonctions matérielles implantées le long du chemin a été déportée de manière virtualisée [0011] Selon un mode de réalisation, l'obtention du délai d'errance correspond à un calcul du délai d'errance comprenant une obtention du délai de transit de bout-en-bout effectif par : - mesure préalable du délai de transit de bout-en-bout le long du chemin de données ; ou par - mesure préalable d'une demie valeur du délai de transit aller-retour le long du chemin de données. [0012] Par exemple, lorsque le (ou les) paquet de données est formaté selon le protocole 3 QUIC, les temps de transit aller-retour total et sur les segments aval et amont sont obtenues par observation du changement de la valeur du « spinbit » selon ce protocole. De la sorte les délais de transit effectif de bout-en-bout et relatifs au point d'observation sont obtenus de manière aisée. [0013] Selon un mode de réalisation, le chemin de données passe par au moins un noeud du réseau. Pour chacun des noeuds, le calcul du délai d'errance comprend une obtention d'un délai de franchissement du noeud pour ledit au moins un paquet de données. Le délai de transit de bout-en-bout attendu est fonction dudit au moins un délai de franchissement. [0014] Selon un mode de réalisation, le chemin de données passe par au moins deux noeuds du réseau. Pour chaque paire de noeuds parmi les au moins deux noeuds, le calcul du délai d'errance comprend une obtention d'un délai de propagation dudit au moins un paquet de données le long du chemin de données entre les noeuds de la paire de noeuds. Le délai de transit de bout-en-bout attendu est fonction dudit au moins un délai de propagation. Le délai de propagation est un paramètre physique qui est généralement disponible dans les équipements ou lors des déploiements des liens. [0015] Ainsi, le délai de transit de bout-en-bout attendu est plus précis car prenant en compte également le délai sur les interconnexions entre les noeuds. [0016] Selon un mode de réalisation, le délai d'errance est calculé comme une fonction du délai de transit de bout-en-bout effectif auquel est soustrait ledit au moins un délai de franchissement et/ou ledit au moins un délai de propagation. [0017] Ainsi, le calcul du délai d'en-ance est simple et robuste. [0018] Selon un mode de réalisation, le chemin de données s'étend entre un premier et un deuxième noeud de réseau du réseau, le dispositif de sécurisation étant logé dans le deuxième noeud de réseau. Ledit au moins un délai de franchissement est obtenu à partir d'au moins un paramètre véhiculé au sein dudit au moins un paquet de données. [0019] Par exemple, dans le cas de plusieurs paquets de données d'une connexion du protocole QUIC, le délai de franchissement agrégé localement puis véhiculé par le dernier paquet de type RESET ou GOAWAY du flux en question. Ainsi, les délais de franchissement sont aisément véhiculés le long du chemin de données jusqu'au dispositif calculant le délai d'errance. [0020] Selon un mode de réalisation, lorsque le dispositif de sécurisation est logé dans le deuxième noeud de réseau, ladite au moins une action de sécurisation appartient au groupe comprenant : - inscription du délai d'errance dans ledit au moins un paquet de données. Ainsi le délai d'errance reste associé au (ou aux) paquet de données quelle que soit sa destination, permettant par là-même une vérification ultérieure qu'il (ou qu'ils) a pu être altéré le long du chemin de données ; - inscription du délai d'errance en association avec le chemin de données dans un plan de routage d'un domaine autonome du réseau auquel appartient le chemin de données. Ainsi une sécurisation globale du réseau est obtenue via une cartographie des délais d'errance des chemins de données du réseau ; [0021] - destruction ou duplication pour analyse dudit au moins un paquet de données lorsque le délai d'errance est supérieur à un seuil prédéterminé ; - transmission du délai d'errance à au moins un autre dispositif inclus dans un noeud qui n'est pas situé le long du chemin de données pour mise en oeuvre d'une autre action de sécurisation. Ainsi une action de sécurisation spécifique peut être mise en oeuvre par un dispositif dédié ; et - une combinaison de tout ou partie des alternatives du groupe précité. [0022] Ainsi, un réseau à très faible errance peut être constitué sur la base d'une sélection uniquement des routes dont l'errance est inférieure à une valeur prédéterminée. [0023] Selon un mode de réalisation, le dispositif de sécurisation n'est pas situé le long du chemin de données. Le délai de franchissement est reçu à partir dudit au moins un noeud via au moins un autre paquet de données distinct dudit au moins un paquet de données. [0024] Selon un mode de réalisation, lorsque le dispositif de sécurisation n'est pas situé le long du chemin de données, le délai de franchissement est reçu sous une forme encryptée, le dispositif de sécurisation et ledit au moins un noeud partageant la connaissance d'au moins une information d'encryptage. [0025] Ainsi, le transfert du délai de franchissement depuis le (ou les) noeud vers le dispositif de sécurisation est sécurisé. Par exemple, l'information d'encryptage peut utiliser certains paramètres partagés du protocole PoT. [0026] Selon un mode de réalisation, ladite au moins une information d'encryptage est obtenue par ledit au moins un noeud via ledit au moins paquet de données. [0027] Selon un mode de réalisation, lorsque le dispositif de sécurisation n'est pas situé le long du chemin de données, ladite au moins une action de sécurisation appartient au groupe comprenant : - inscription du délai d'errance en association avec le chemin de données dans un plan de routage d'un domaine autonome du réseau auquel appartient le chemin de données. Ainsi une sécurisation globale du réseau est obtenue via une cartographie des délais d'errance des chemins de données du réseau ; - transmission du délai d'errance à au moins un autre dispositif inclus dans un noeud qui n'est pas situé le long du chemin de données pour mise en oeuvre d'une autre action de sécurisation. Ainsi une action de sécurisation spécifique peut être mise en oeuvre par un dispositif dédié ; et - une combinaison de tout ou partie des alternatives précitées du groupe. 100281 Selon un mode de réalisation, l'obtention du délai d'errance correspond à une réception, via un autre paquet de données distinct dudit au moins un paquet de données, du délai d'errance depuis un autre dispositif situé le long du chemin de données. Ladite au moins une action de sécurisation appartient au groupe comprenant : - inscription du délai d'errance en association avec le chemin de données dans un plan de routage d'un domaine autonome du réseau auquel appartient le chemin de données. Ainsi une sécurisation globale du réseau est obtenue via une cartographie des délais d'errance des chemins de données du réseau ; - transmission du délai d'errance à au moins un autre dispositif inclus dans un noeud qui n'est pas situé le long du chemin de données pour mise en oeuvre d'une autre action de sécurisation. Ainsi une action de sécurisation spécifique peut être mise en oeuvre par un dispositif dédié ; et - une combinaison de tout ou partie des alternatives précitées du groupe. [0029] Selon un mode de réalisation, le procédé de sécurisation est mis en oeuvre succes- sivement pour une pluralité de chemins de données du réseau. [0030] L'invention concerne également un programme d'ordinateur comprenant des ins- tructions de code de programme pour la mise en oeuvre du procédé tel que décrit précédemment, selon l'un quelconque de ses différents modes de réalisation, lorsqu'il est exécuté sur un ordinateur. [0031] Dans un mode de réalisation de l'invention, il est proposé un dispositif de sécu- risation de la transmission d'au moins un paquet de données le long d'un chemin de données d'un réseau de télécommunications. Un tel dispositif de sécurisation comprend une machine de calcul reprogrammable ou une machine de calcul dédiée configurée pour mettre en oeuvre les étapes du procédé de sécurisation selon l'invention (selon l'un quelconque des différents modes de réalisation précités). [0032] Ainsi, les caractéristiques et avantages de ce dispositif sont les mêmes que ceux des étapes correspondantes du procédé de sécurisation décrit précédemment. Par conséquent, ils ne sont pas détaillés plus amplement. [0033] Dans un mode de réalisation de l'invention, il est proposé un noeud d'un réseau de té- lécommunications. Un tel noeud de réseau comprend au moins un dispositif de sécurisation précité (selon l'un quelconque des différents modes de réalisation précités). Liste des figures [0034] D'autres buts, caractéristiques et avantages de l'invention apparaîtront plus clairement à la lecture de la description suivante, donnée à titre de simple exemple illustratif, et non limitatif, en relation avec les figures, parmi lesquelles : [0035] [fig.1] représente un chemin de données d'un domaine autonome d'un réseau de télécommunications le long duquel la transmission de données est sécurisée par mise en oeuvre 6 d'un procédé de sécurisation selon un mode de réalisation de l'invention ; [0036] [fig.2] représente les étapes d'un procédé de sécurisation de la transmission dc données le long d'un chemin de données selon un mode de réalisation de l'invention ; [0037] [fig.3] représente un exemple d'échanges entre entités d'un réseau de télécommunication implémentant le procédé de sécurisation de la transmission de données selon un mode de réalisation de l'invention ; [0038] [fig.4] représente un exemple d'échanges entre entités d'un réseau de télécommunication implémentant le procédé de sécurisation de la transmission de données selon un autre mode de réalisation de l'invention ; [0039] [fig.5] représente un exemple d'échanges entre entités d'un réseau de télécommunication implémentant le procédé de sécurisation de la transmission de données selon encore un autre mode de réalisation de l'invention ; [0040] [fig.6] représente un exemple de structure de dispositif permettant la mise en oeuvre des étapes du procédé de la [fig. 2] selon un mode de réalisation de l'invention. [0041] Description détaillée de modes de réalisation de l'invention [0042] Le principe général de l'invention repose sur une obtention d'un délai d'errance d'un (ou de plusieurs) paquets de données le long d'un chemin de données (e.g. qui s'étend entre deux des noeuds du réseau). Plus particulièrement, le délai d'errance est représentatif d'un écart entre : [0043] - un délai de transit de bout-en-bout effectif du paquet de données le long du chemin de données (i.e. le délai que le paquet a effectivement mis pour parcourir le chemin de données) ; et [0044] - un délai de transit de bout-en-bout attendu du paquet de données le long du chemin de données (i.e. tout ou partie du délai connu, e.g. associé aux noeuds de confiance, que le paquet est supposé mettre pour parcourir le chemin de données). [0045] Une telle métrique est pertinente afin de sécuriser la transmission de données dans le réseau et une action de sécurisation peut être mise en oeuvre sur la base d'un tel délai d'errance. Par exemple, une valeur du délai d'errance supérieure à un seuil prédéterminé est représentative du fait que le chemin de données emprunté par le paquet de données a pu être modifié, par exemple quand un dispositif tiers qui ne fait pas partie des dispositifs de confiance a été ajouté sur le chemin de données, ou si une partie des fonctions matérielles implantées le long du chemin a été déportée de manière virtualisée. 7 [0046] On présente désormais, en relation avec la [fig.1] un chemin de données d'un domaine autonome AS (pour « Autonomous System » en anglais) d'un réseau de télécommunications le long duquel la transmission de données est sécurisée par un procédé de sécurisation selon un mode de réalisation de l' invention. [0047] Plus particulièrement, un terminal utilisateur UE (pour « User Equipment » en anglais) envoie un paquet de données à destination d'un serveur Scrv via le chemin de données passant par les cinq noeuds de réseau, Ni à N5, qui sont ici des noeuds de confiance. Par exemple, la confiance dans les noeuds N1 à N5 est établie en mettant en oeuvre le mécanisme PoT. [0048] Un dispositif 100 de sécurisation met en oeuvre le procédé de sécurisation décrit plus avant ci-dessous en relation avec les étapes représentées sur la [fig.2] afin de sécuriser le chemin de données entre le terminal UE et le serveur Serv. [0049] Plus particulièrement, lors d'une étape E200, un délai d'errance représentatif d'un écart entre un délai de transit de bout-en-bout effectif d'un (ou plusieurs) paquet de données le long du chemin de données et un délai de transit de bout-en-bout attendu du (ou des) paquet de données le long du chemin de données est obtenu. [0050] Dans le mode de réalisation de la [fig.1] , l'obtention du délai d'errance correspond à un calcul du délai d'errance par le dispositif 100. [0051] Pour ce faire, le dispositif 100 obtient un délai de franchissement de tout ou partie des noeuds de confiance pour le (ou les) paquet de données, le délai de transit de bouten-bout attendu au niveau du noeud dans lequel se situe le dispositif 100 étant fonction du (ou (les) délai de franchissement en question. [0052] Par exemple, le délai de franchissement est fourni par le noeud de confiance cor- respondant (i.e. NI ou N2 ou N3 ou N4 ou N5) au dispositif 100 afin de déterminer le délai d'errance. Pour ce faire, dans le mode de réalisation de la [fig.1] , chaque noeud de confiance ajoute son propre délai de franchissement à la valeur des délais de franchissements des noeuds précédemment traversés par le paquet ou flux le long du chemin de données. La valeur de délai de franchissement cumulatif ainsi obtenue est véhiculée dans un champ prédéfini du paquet ou du flux en question (e.g. dans le dernier paquet RESET ou GOAWAY d'une connexion QUIC, ou périodiquement dans n'importe quel paquet du flux, ou encore dans un paquet ajouté au flux comme un paquet ICMP, etc.). Il s'agit d'un mode de réalisation dit « in-band » (i.e. le 8 délai de franchissement est inclus dans le (ou les) paquets de données sous forme d'un champ particulier). [0053] Dans d'autres modes de réalisation dit « out-of-band » la valeur du délai de fran- chissement est exportée vers le dispositif de sécurisation via un (ou plusieurs) paquet qui n'est pas un paquet de données transitant via le chemin de données. Par exemple, la valeur du délai de franchissement est exportée via un protocole PSAMP (pour « Packct SAMPling » en anglais) dans le cas d'un seul paquet, ou IPFIX (pour « Internet Protocol Flow Information Export » en anglais, e.g. netflow v9 pour Cisco0 et Juniper) pour le cas d'un flux de paquets. [0054] De retour à la [fig.1] , le tableau 1 ci-dessous donne des exemples de délais de franchissement (prenant en compte par exemple les délais de traitement dans les entités en question, de commutation, etc.) mis en jeu dans les différentes entités représentées sur la [fig. 1] lorsqu'elles sont connues. [Tableaux1] Délai de franchissement d'une entité (ms) Ni 15 N2 Inconnu N3 10 N4 Inconnu N5 Inconnu [0055] Par ailleurs, afin de calculer le délai d'emince, le dispositif 100 obtient le délai bout- en-bout effectif (i.e. entre le terminal et le serveur). Par exemple, le délai de bouten-bout effectif est obtenu par le dispositif 100 via la demie-valeur du délai d'aller-retour du chemin de données. La valeur du délai d'aller-retour en question est obtenue par exemple via le « spinbit » lorsque le paquet de données est selon le protocole QUIC. Dans d'autres modes de réalisation, le délai bout-en-bout effectif est obtenu par mesure préalable du délai de transit le long du chemin de données. [0056] En supposant que le délai de transit de bout-en-bout effectif dans le cas présent soit égal à 200ms, le dispositif 100 calcule le délai d'errance en soustrayant les délais de franchissement connus, ici 15 et 10 ms au délai de transit de bout-en-bout effectif. On obtient alors 200 - 15 - 10 = 175ms. [0057] Par ailleurs, en supposant que le délai de propagation entre noeuds de confiance le long du chemin est connu, le délai d'errance peut être raffiné dans certains modes de 9 réalisation en tenant compte du délai de propagation en question dans le calcul du délai de transit de bout-en-bout attendu. Un tel délai de propagation est obtenu par exemple par mesure préalable. [0058] Par exemple, en supposant que le délai de propagation est égal à 30 ms dans la topologie de la [fig.1] , le délai d'errance peut être raffiné en soustrayant les 30 ms en question à la valeur précédemment calculée, i.e. 175ms. On obtient au final un délai d'errance calculé comme étant égal à 175 -30 = 145ms. [0059] Dans d'autres modes de réalisation non représentés sur la [fig.1] , le dispositif 100 de sécurisation est implémenté non pas dans le serveur Serv, mais dans un des noeuds de confiance Ni à Ni Dans ce cas, le dispositif 100 calcule le délai d'errance par rapport à sa position le long du chemin de données. [0060] Par ailleurs, dans d'autres modes de réalisation décrits ci-dessous en relation avec les [fig.3] , [fig. 4] et [fig. 5], le dispositif de sécurisation ne calcule pas le délai d'errance, mais le reçoit d'un dispositif tiers qui a effectué le calcul. Dans ce cas, l'étape E200 d'obtention du délai d'errance se réduit à une étape de réception du délai d'errance. [0061] Lors d'une étape E210, la transmission de données est sécurisée par mise en oeuvre d'une (ou plusieurs) action de sécurisation à partir du délai d'errance obtenu à l'étape E200. [0062] [fig.1] Par exemple, dans le mode de réalisation de la dans lequel le dispositif 100 de sécurisation calcule le délai d'errance sur la base d'informations (e.g. les délais de franchissement) comprises dans le (ou les) paquets de données (cas « in-band» précité), l'action de sécurisation appartient au groupe comprenant : - inscription du délai d'errance dans le (ou les) paquet de données ; - inscription du délai d'errance en association avec le chemin de données dans un plan de routage d'un domaine autonome AS du réseau auquel appartient le chemin de données (e.g. en utilisant un protocole EGP (pour « Exterior Gateway Protocol » en anglais) du type BGP (pour « Border Gateway Protocol » en anglais)) ; - destruction ou duplication pour analyse (e.g. via la transmission du paquet dupliqué à un équipement (l'analyse) du (ou des) paquet de données lorsque le délai d'errance est supérieur à un seuil prédéterminé ; - transmission du délai d'errance à au moins un autre dispositif inclus dans un noeud qui n'est pas situé le long du chemin de données pour mise en oeuvre d'une autre action de sécurisation (e.g. vers un collecteur implémentant un protocole IPFIX (pour « Internet Protocol Flow Information Export » en anglais)) ; et - une combinaison de tout ou partie des alternatives précitées du groupe [0063] On présente désormais, en relation avec la [fig.3] une mise en oeuvre du procédé de sécurisation selon un mode de réalisation de l' invention. [0064] Dans le mode de réalisation de la [fig.3] , les premier et deuxième domaines autonomes AS1 et AS2 du réseau comprennent chacun un chemin de données reliant un terminal utilisateur UE1 ou UE2 à un routeur de bordure ASBR1 ou ASBR2 (pour « Autonomous System Border Router » en anglais) via un noeud de réseau de confiance du type router R AS1 ou R AS2. D'autres domaines autonomes, indices j et k sont également présents dont seuls les routeurs de bordure ASBRj et ASBRk sont représentés afin d' interfaçage avec les autres domaines autonomes du réseau. [0065] Tout ou partie des routeurs de bordure ASBR1, ASBR2, ASBRj, ASBRk comprend un dispositif 100' de sécurisation selon un mode de réalisation différent du mode de réalisation décrit ci-dessus en relation avec la [fig.1] . Plus particulièrement, le dispositif 100' de sécurisation ne calcule pas le délai d'errance, mais le reçoit d'un dispositif tiers qui a préalablement effectué le calcul. Par exemple le dispositif 100' compris dans le routeur de bordure ASBR1 reçoit (flèche 300_1) le délai d'errance envoyé par le noeud de réseau R_AS1 qui, lui, met en oeuvre le procédé selon le mode de réalisation décrit ci-dessus en relation avec la [fig. 1] (e.g. le noeud de réseau R_AS1 comprend un dispositif 100 de sécurisation comme décrit ci-dessus). Il en est de même avec le dispositif 100' compris dans le routeur de bordure ASBR2 qui reçoit (flèche 300_2) le délai d'errance envoyé par le noeud de réseau R_AS2 qui, lui, met en oeuvre le procédé selon le mode de réalisation décrit ci-dessus en relation avec la [fig. 1]. [0066] De manière générale, les routeurs de bordure ASBRI, ASBR2, ASBRj, ASBRk peuvent recevoir les délais d'errance des différents chemins de données, par exemple lorsque le procédé de sécurisation est mis en oeuvre successivement pour une pluralité de chemins de données du réseau. Une telle réception se fait par exemple via des informations selon un protocole IGP (pour « Interior gateway protocol » en anglais). Les routeurs de bordure ASBR1, ASBR2, ASBRj, ASBRk agrègent les délais d'errance des chemins de données pour lesquels ils reçoivent de tels délais d'errance et les insèrent comme métriques dans un protocole EGP (e.g. selon le protocole BGP) à destination des autres domaines autonomes (flèches 300_3). De telles transmissions 11 peuvent par exemple se faire en parallèle des transmissions des informations EGP « classiques » (flèches 300 4). [0067] De la sorte, selon le mode de réalisation de la [fig.3] dans lequel le dispositif 100' de sécurisation reçoit le délai d'errance, l'action de sécurisation appartient au groupe comprenant : [0068] - inscription du délai d'errance en association avec le chemin de données dans un plan de routage d'un domaine autonome du réseau auquel appartient le chemin de données ; [0069] - transmission du délai d'errance à au moins un autre dispositif inclus dans un noeud qui n'est pas situé le long du chemin de données pour mise en oeuvre d'une autre action de sécurisation (e.g. une inscription par un dispositif tiers du délai d'errance en association avec le chemin de données dans un plan de routage) ; et [0070] - une combinaison de tout ou partie des alternatives précitées du groupe. [0071] Dans d'autres modes de réalisation non illustrés, les routeurs de bordure ASBR1, ASBR2, ASBRj, ASBRk comprennent le dispositif 100 de sécurisation selon le mode de réalisation de la [fig.1] . De la sorte, le calcul du délai d'errance du chemin de données sur lequel se trouve un routeur de bordure donné est effectué dans le routeur de bordure en question. [0072] On présente désormais, en relation avec la [fig.4] une mise en oeuvre du procédé de sécurisation selon un autre mode de réalisation de l'invention. [0073] Plus particulièrement, le mode de réalisation représenté sur la [fig.4] reprend les éléments du mode de réalisation de la [fig. 3]. Seul un réflecteur de route RR1, RR_ASj, RR_ASk (pour « Route Retlector » en anglais) est utilisé dans les domaines autonomes correspondants. [0074] De la sorte, le dispositif 100' de sécurisation est par exemple ici inclus dans le ré- flecteur de route RR1 de sorte à injecter les délais d'errance des chemins de données reçus du routeur de bordure ASBR1 (flèche 400_1) comme métriques dans l'EGP (e.g. selon le protocole BOP). Selon le mode de réalisation considéré discuté ci-dessus en relation avec la [fig.3] , le routeur de bordure ASBR1 a calculé lui-même le délai d'errance associé au chemin de données sur lequel il se trouve (e.g. le routeur de bordure ASBR1 comprend un dispositif 100 comme illustré sur la [fig. 4]) ou reçu le délai d'errance en question 12 (calculé par un noeud de confiance du chemin en question qui, lui, comprend e.g. un dispositif 100 dans ce cas non illustré sur la [fig. 4]) ainsi qu'éventuellement les délais d'errance associés aux autres chemins du domaine autonome considéré. [0075] De retour à la [fig.4] , l'EGP mis à jour est envoyé au routcur de bordure ASBR1 (flèche 400_2) afin de transmission vers les autres domaines autonomes (flèches 300 3). De telles transmissions peuvent par exemple se faire en parallèle des transmissions des informations EGP « classiques » (flèches 300_4). [0076] Ainsi, selon le mode de réalisation de la [fig.4] l'action de sécurisation de sécurisation est de même nature que dans le mode de réalisation décrit ci-dessus en relation avec la [fig. 3]. [0077] On présente désormais, en relation avec la [fig.5] une mise en oeuvre du procédé de sécurisation selon encore un autre mode de réalisation de l'invention. [0078] Dans le mode de réalisation de la [fig.5] , le dispositif 100" de sécurisation calcule le délai d'errance sur la base d'informations (e.g. les délais de franchissement) qui lui sont transmises par un moyen autre que via le (ou les) paquets de données. En d'autres termes, le (ou les) paquets de données transitant le long du chemin de données pour lequel on veut obtenir le délai d'errance ne véhicule pas les délais de franchissement (mode de réalisation « out-of-band> précité). En effet, le dispositif 100" de sécurisation est ici situé dans un collecteur Coll du type IPFIX. Dans d'autres modes de réalisation, le dispositif 100" est situé dans un noeud de confiance qui n'est pas situé sur le chemin de données à sécuriser. [0079] Plus particulièrement, le dispositif 100" de sécurisation reçoit le (ou les) délai de franchissement à partir d'un noeud NI, N2, N3, N5, N6 de confiance correspondant via un (ou plusieurs) autre paquet de données distinct du (ou des) paquet de données transitant sur chemin de données pour lesquels le dispositif 100" de sécurisation va calculer le délai d'errance. [0080] Pour ce faire, le contrôleur configure (flèches 500_1) en plus le niveau d'agrégation du flux et l'adresse du collecteur Coll dans chaque noeud Ni, N2, N3, N5, N6. Le contrôleur Contr configure en plus le niveau d'agrégation du flux et les caractéristiques de la connexion avec le collecteur Coll (adresse, clés, etc.). [0081] Ensuite les paquets de données transportent « in-band » (i.e. dans un champ de 13 données qu'ils véhiculent eux-mêmes) les deux paramètres : [0082] - RND ; et [0083] - PoT : somme partielle du secret partagé que les noeuds N1, N2, N3, N5, N6 calculent (la constante du polynôme POLY1 selon PoT). [0084] Comme rappelé ci-dessus, dans le mode de réalisation de la [fig.5] , le dispositif 100" de sécurisation calcule le délai d'errance sur la base d'informations (e.g. les délais de franchissement) qui ne lui sont pas transmises via le (ou les) paquets de données transitant le long du chemin de données pour lequel on veut calculer le délai d'errance (cas « out-of-band » précité). De la sorte, les noeuds N1, N2, N3, N5, N6 n'insèrent pas leur délai de franchissement dans les paquets de données transitant sur le chemin de données en question. Un noeud N1, N2, N3, N5 ou N6 ne peut donc pas calculer de délai d'errance. [0085] Afin de protéger les échanges le contrôleur Contr active le protocole PoT sur le chemin N1 vers N5 dans N1, N2 et Ni Plus particulièrement, le contrôleur Contr configure (flèches 500_l) le secret commun POLY2 et le secret de chaque noeud N1, N2, N5 du chemin (xi,yi) au niveau de chacun des noeuds en question, ainsi que du résultat attendu au niveau du dernier noeud du chemin, ici Ni N5 est donc le seul à (après le contrôleur Contr) connaitrc la mesure de PoT attendu (aka la constante de POLY1). Ensuite chaque noeud protège sa valeur de délai de franchissement à l'aide d'au moins un des paramètres de PoT connus ou calculable par le contrôleur Conti; par exemple POLYI, POLY2, RND et le secret de chaque noeud (xi,yi). Par exemple. Ceci peimet : [0086] - La détection de la modification et authentification des noeuds de passage dans les noeuds : (xi,yi) est utilisé comme clé de signature HMAC (pour « keyed-hash message authentication code » en anglais), [0087] - La protection en lecture : RND et utilisé comme clé de chiffrement par exemple avec de l'AES (pour « Advanced Encryption Standard » en anglais). L'activation de PoT peut être partielle et limitée à POLYI. [0088] Optionnellement, pour un flux de paquets d'une connexion selon le protocole QUIC allant du terminal utilisateur UE au serveur Serv, chaque noeud Ni, N2, N3, N5 ou N6 synchronise l'exportation du ticket [PFDC sur les fronts montants des « spinbit » des paquets QUIC et ajoute les mesures de demi temps de transit effectif aller-retour obtenu dans le ticket. Cela permet deux choses : [0089] - chaque noeud NI, N2, N3, N5 ou N6 exporte (flèches 500_2) vers le collecteur Coll un ticket décrivant la même séquence de paquets de données. Ceci augmente la précision de la comparaison et de l'agrégation des délais de franchissement ; et [0090] - le demi temps de transit effectif aller-retour obtenu, notamment au niveau du noeud 14 N5, permet un calcul de délai d'errance très précis. [0091] Un exemple de format de ticket est : [0092] [0093] Flux identifier quintuplé, ... [0094] tO, [0095] tl, [0096] nombre d'octets, [0097] nombre paquets, [0098] délai de franchissement local cumulé, [0099] Spatial dclay : {demi temps de transit effectif aller-retour montant, demi temps de transit effectif aller-retour descendant} [0100] [0101] Le dispositif 100" du collecteur Coll reçoit les délais de franchissement des différents noeuds N1, N2, N3, N5, N6. Il les déchiffre à l'aide des «decryption kcys » reçues du contrôleur Contr lors de la configuration comme décrit ci-dessus (En d'autres termes, le dispositif 100" déchiffre (ou décrypte) les délais de franchissement des différents noeuds N1, N2, N3, N5, N6 sur la base d'informations d'encryptage qui ont été obtenues par les différents noeuds en question N1, N2, N3, N5, N6 via le (ou les) paquets de données transitant le long du chemin de données considéré. De telles informations d'encryptage sont utilisées par les différents noeuds en question pour chiffrer (ou encrypter) leur délai de franchissement respectif). Le dispositif 100" regroupe les délais de franchissement reçus des différents noeuds Ni, N2, N3, N5. N6 par flux de paquets de données suivant les flow agrégation également reçues du contrôleur Contr lors de la configuration. Le dispositif 100" calcule un délai d'errance pour le chemin de données correspondant à l'agrégation demandée. [0102] Le dispositif 100" regroupe les résultats dans une matrice de délais d'errance. Les entrées de la matrice correspondent au niveau d'agrégation du flux choisi (host, network, système autonome). Le dispositif 100" permet l'accès à la matrice à l'aide par exemple du protocole ALTO (pour « Application-Layer Traffic Optimization » en anglais). Le dispositif 100" de sécurisation mesure la variation de délai d'errance. II signale une augmentation excessive comme une attaque possible d'un noeud du chemin sur le flux de paquets. [0103] Alternativement, ou en combinaison, le dispositif 100" de sécurisation transmet le (ou les) délai d'errance à au moins un autre dispositif inclus dans un noeud qui n'est pas situé le long du chemin de données pour mise en oeuvre d'une autre action de sécurisation (e.g. une inscription par un dispositif tiers du (ou des) délai d'errance en association avec le chemin de données dans un plan de routage). [0104] Ainsi, selon le mode de réalisation de la [fig.5] l'action de sécurisation est de même nature que dans le mode de réalisation décrit ci-dessus en relation avec les [fig,. 3] et [fig. 4]. [0105] Par exemple, le dispositif 100" de sécurisation transmet le (ou les) délai d'errance à un réflecteur de route RR (e.g. le réflecteur de route RR comprend un dispositif 100' comme illustré sur la [fig.5] ) de sorte à injecter le (ou les) délai d'errance des chemins de données calculés ou reçus (flèche 500_3) comme métriques dans l'EGP (e.g. selon le protocole BOP). L'EGP mis à jour est renvoyé par le réflecteur de route RR à tout ou partie des noeuds N1, N2, N3, N5, N6 (flèche 500 4). [0106] Dans d'autres modes de réalisation, d'autres types de protection que celle mise en oeuvre dans le protocole PoT sont utilisées pour la transmission des données (e.g. le (ou les) délai de franchissement ou de lien) au dispositif de sécurisation. [0107] Dans encore d'autres modes de réalisation, aucune protection des données n'est mise en oeuvre pour la transmission des données (e.g. le (ou les) délai de franchissement ou de lien) au dispositif de sécurisation. [0108] On présente désormais, en relation avec la [fig.6] un exemple de structure de dispositif 600 permettant de mettre en oeuvre les étapes du procédé de sécurisation de la [fig. 2] selon un mode de réalisation de l'invention. [0109] Le dispositif 600 comprend une mémoire vive 603 (par exemple une mémoire RAM), une unité de traitement 602 équipée par exemple d'un processeur, et pilotée par un programme d'ordinateur stocké dans une mémoire morte 601 (par exemple une mémoire ROM ou un disque dur). A l'initialisation, les instructions de code du programme d'ordinateur sont par exemple chargées dans la mémoire vive 603 avant d'être exécutées par le processeur de l'unité de traitement 602. [0110] Cette [fig.6] illustre seulement une manière particulière, parmi plusieurs possibles, de réaliser le dispositif 600 afin qu'il effectue certaines étapes du procédé de sécurisation selon l'invention (selon l'un quelconque des modes de réalisation et/ou variantes décrit(e)s ci-dessus en relation avec la [fig. 2]). En effet, ces étapes peuvent être réalisées indifféremment sur une machine de calcul reprograrnmable (un ordinateur PC, un processeur DSP ou un microcontrôleur) exécutant un programme comprenant une séquence d'instructions, ou sur une machine de calcul dédiée (par exemple un ensemble de portes logiques comme un FPGA ou un ASIC, ou tout autre module matériel). 16 [0111] Dans le cas où le dispositif 600 est réalisé avec une machine de calcul repro- grammable, le programme correspondant (c'est-à-dire la séquence d'instructions) pourra être stocké dans un médium de stockage amovible (tel que par exemple une disquette, un CD-ROM ou un DVD-ROM) ou non, ce médium de stockage étant lisible partiellement ou totalement par un ordinateur ou un processeur. [0112] Dans certains modes de réalisation, le dispositif 600 implémente l'un quelconque des dispositifs de sécurisation 100, 100' ou 100". [0113] Dans certains modes de réalisation, le dispositif 600 implémente plusieurs ou la totalité des dispositifs de sécurisation 100, 100' ou 100". [0114] Dans certains modes de réalisation, le dispositif 600 est inclus dans un noeud de réseau (e.g. Ni, N2, N3, N4, N5, N6, RR, Coll, ASBR, R AS, etc.). 17 [Revendication 1] [Revendication 2] [Revendication 3] [Revendication 4] [Revendication 5]