FR3094163A1 - 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. - Google Patents
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. Download PDFInfo
- Publication number
- FR3094163A1 FR3094163A1 FR1902974A FR1902974A FR3094163A1 FR 3094163 A1 FR3094163 A1 FR 3094163A1 FR 1902974 A FR1902974 A FR 1902974A FR 1902974 A FR1902974 A FR 1902974A FR 3094163 A1 FR3094163 A1 FR 3094163A1
- Authority
- FR
- France
- Prior art keywords
- delay
- data path
- wandering
- data
- data packet
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Withdrawn
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/14—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
- H04L63/1441—Countermeasures against malicious traffic
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/14—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
- H04L63/1441—Countermeasures against malicious traffic
- H04L63/1466—Active attacks involving interception, injection, modification, spoofing of data unit addresses, e.g. hijacking, packet injection or TCP sequence number attacks
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L45/00—Routing or path finding of packets in data switching networks
- H04L45/42—Centralised routing
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/14—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
- H04L63/1408—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic by monitoring network traffic
- H04L63/1416—Event detection, e.g. attack signature detection
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/14—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
- H04L63/1408—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic by monitoring network traffic
- H04L63/1425—Traffic logging, e.g. anomaly detection
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/20—Network architectures or network communication protocols for network security for managing network security; network security policies in general
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
- H04W12/12—Detection or prevention of fraud
- H04W12/121—Wireless intrusion detection systems [WIDS]; Wireless intrusion prevention systems [WIPS]
- H04W12/122—Counter-measures against attacks; Protection against rogue devices
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
- H04W12/60—Context-dependent security
- H04W12/61—Time-dependent
Landscapes
- Engineering & Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer Hardware Design (AREA)
- Computing Systems (AREA)
- General Engineering & Computer Science (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
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 L'invention concerne 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 (E200) d’un délai d’errance représentatif d’un écart entre un délai de transit de bout-en-bout effectif de l’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 de l’au moins un paquet de données le long du chemin de données ; et- sécurisation (E210) de la transmission par mise en œuvre d’au moins une action de sécurisation à partir du délai d’errance. FIGURE 2
Description
Domaine de l'invention
Le domaine de l'invention est celui de la mise en œuvre des réseaux de télécommunications. 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.
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
Il existe des méthodes permettant de vérifier le passage de paquets de données par une succession de nœuds 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 nœuds 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).
Cependant, de telles méthodes sont la plupart du temps dites « administrées » dans le sens où elles supposent une pré-configuration des nœuds 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 nœuds 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.
Par ailleurs, de telles méthodes ne permettent que de prouver le passage de paquets de données par des nœuds de confiance d’un chemin de données, mais ne disent rien sur ce qui se passe entre deux de ces nœuds de confiance.
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 nœuds de confiance, e.g. si 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 ont été déportées de manière virtualisée.
Il existe également un besoin pour que la technique en question soit simple à mettre en œuvre.
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 œuvre d’au moins une action de sécurisation à partir du délai d’errance.
- 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 œuvre d’au moins une action de sécurisation à partir du délai d’errance.
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.
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 bout-en-bout effectif le long du chemin de données, le chemin s’étendant entre deux nœuds 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.
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.
- 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.
Par exemple, lorsque le (ou les) paquet de données est formaté selon le protocole 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.
Selon un mode de réalisation, le chemin de données passe par au moins un nœud du réseau. Pour chacun des nœuds, le calcul du délai d’errance comprend une obtention d’un délai de franchissement du nœud 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.
Selon un mode de réalisation, le chemin de données passe par au moins deux nœuds du réseau. Pour chaque paire de nœuds parmi les au moins deux nœuds, 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 nœuds de la paire de nœuds. 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.
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 nœuds.
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.
Ainsi, le calcul du délai d’errance est simple et robuste.
Selon un mode de réalisation, le chemin de données s’étend entre un premier et un deuxième nœud de réseau du réseau, le dispositif de sécurisation étant logé dans le deuxième nœud 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.
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.
Selon un mode de réalisation, lorsque le dispositif de sécurisation est logé dans le deuxième nœud 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 ;
- 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 ;
- 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 nœud qui n’est pas situé le long du chemin de données pour mise en œuvre d’une autre action de sécurisation. Ainsi une action de sécurisation spécifique peut être mise en œuvre par un dispositif dédié ; et
- une combinaison de tout ou partie des alternatives du groupe précité.
- transmission du délai d’errance à au moins un autre dispositif inclus dans un nœud qui n’est pas situé le long du chemin de données pour mise en œuvre d’une autre action de sécurisation. Ainsi une action de sécurisation spécifique peut être mise en œuvre par un dispositif dédié ; et
- une combinaison de tout ou partie des alternatives du groupe précité.
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.
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 nœud via au moins un autre paquet de données distinct dudit au moins un paquet de données.
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 nœud partageant la connaissance d’au moins une information d’encryptage.
Ainsi, le transfert du délai de franchissement depuis le (ou les) nœud 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.
Selon un mode de réalisation, ladite au moins une information d’encryptage est obtenue par ledit au moins un nœud via ledit au moins paquet de données.
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 nœud qui n’est pas situé le long du chemin de données pour mise en œuvre d’une autre action de sécurisation. Ainsi une action de sécurisation spécifique peut être mise en œuvre par un dispositif dédié ; et
- une combinaison de tout ou partie des alternatives précitées du groupe.
- 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 nœud qui n’est pas situé le long du chemin de données pour mise en œuvre d’une autre action de sécurisation. Ainsi une action de sécurisation spécifique peut être mise en œuvre par un dispositif dédié ; et
- une combinaison de tout ou partie des alternatives précitées du groupe.
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 nœud qui n’est pas situé le long du chemin de données pour mise en œuvre d’une autre action de sécurisation. Ainsi une action de sécurisation spécifique peut être mise en œuvre par un dispositif dédié ; et
- une combinaison de tout ou partie des alternatives précitées du groupe.
- 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 nœud qui n’est pas situé le long du chemin de données pour mise en œuvre d’une autre action de sécurisation. Ainsi une action de sécurisation spécifique peut être mise en œuvre par un dispositif dédié ; et
- une combinaison de tout ou partie des alternatives précitées du groupe.
Selon un mode de réalisation, le procédé de sécurisation est mis en œuvre successivement pour une pluralité de chemins de données du réseau.
L’invention concerne également un programme d’ordinateur comprenant des instructions de code de programme pour la mise en œuvre 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.
Dans un mode de réalisation de l'invention, il est proposé un dispositif 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. 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 œuvre 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).
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.
Dans un mode de réalisation de l'invention, il est proposé un nœud d’un réseau de télécommunications. Un tel nœud 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
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 :
Description détaillée de modes de réalisation de l'invention
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 nœuds du réseau). Plus particulièrement, le délai d’errance est représentatif d’un écart entre :
- un délai de transit de bout-en-bouteffectifdu 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
- un délai de transit de bout-en-boutattendudu paquet de données le long du chemin de données (i.e. tout ou partie du délai connu, e.g. associé aux nœuds de confiance, que le paquet est supposé mettre pour parcourir le chemin de données).
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 œuvre 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.
On présente désormais, en relation avec la 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.
Plus particulièrement, un terminal utilisateur UE (pour « User Equipement » en anglais) envoie un paquet de données à destination d’un serveur Serv via le chemin de données passant par les cinq nœuds de réseau, N1 à N5, qui sont ici des nœuds de confiance. Par exemple, la confiance dans les nœuds N1 à N5 est établie en mettant en œuvre le mécanisme PoT.
Un dispositif 100 de sécurisation met en œuvre le procédé de sécurisation décrit plus avant ci-dessous en relation avec les étapes représentées sur la afin de sécuriser le chemin de données entre le terminal UE et le serveur Serv.
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-bouteffectifd’un (ou plusieurs) paquet de données le long du chemin de données et un délai de transit de bout-en-boutattendudu (ou des) paquet de données le long du chemin de données est obtenu.
Dans le mode de réalisation de la , l’obtention du délai d’errance correspond à un calcul du délai d’errance par le dispositif 100.
Pour ce faire, le dispositif 100 obtient un délai de franchissement de tout ou partie des nœuds de confiance pour le (ou les) paquet de données, le délai de transit de bout-en-bout attendu au niveau du nœud dans lequel se situe le dispositif 100 étant fonction du (ou des) délai de franchissement en question.
Par exemple, le délai de franchissement est fourni par le nœud de confiance correspondant (i.e. N1 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 , chaque nœud de confiance ajoute son propre délai de franchissement à la valeur des délais de franchissements des nœuds 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 délai de franchissement est inclus dans le (ou les) paquets de données sous forme d’un champ particulier).
Dans d’autres modes de réalisation dit «out-of-band» la valeur du délai de franchissement 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 « Packet 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 Cisco® et Juniper) pour le cas d’un flux de paquets.
De retour à la , 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.
| Délai de franchissement d’une entité (ms) | |
| N1 | 15 |
| N2 | Inconnu |
| N3 | 10 |
| N4 | Inconnu |
| N5 | Inconnu |
Par ailleurs, afin de calculer le délai d’errance, 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 bout-en-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.
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.
Par ailleurs, en supposant que le délai de propagation entre nœuds de confiance le long du chemin est connu, le délai d’errance peut être raffiné dans certains modes de 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.
Par exemple, en supposant que le délai de propagation est égal à 30 ms dans la topologie de la , 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.
Dans d’autres modes de réalisation non représentés sur la , le dispositif 100 de sécurisation est implémenté non pas dans le serveur Serv, mais dans un des nœuds de confiance N1 à N5. Dans ce cas, le dispositif 100 calcule le délai d’errance par rapport à sa position le long du chemin de données.
Par ailleurs, dans d’autres modes de réalisation décrits ci-dessous en relation avec les , [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.
Lors d’uneétape E210, la transmission de données est sécurisée par mise en œuvre d’une (ou plusieurs) action de sécurisation à partir du délai d’errance obtenu à l’étape E200.
- 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 d’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 nœud qui n’est pas situé le long du chemin de données pour mise en œuvre 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
On présente désormais, en relation avec la une mise en œuvre du procédé de sécurisation selon un mode de réalisation de l’invention.
Dans le mode de réalisation de la , 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 nœud de réseau de confiance du type router R_AS1 ou R_AS2. D’autres domaines autonomes, indicés 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.
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 . 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 nœud de réseau R_AS1 qui, lui, met en œuvre le procédé selon le mode de réalisation décrit ci-dessus en relation avec la [fig. 1] (e.g. le nœud 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 nœud de réseau R_AS2 qui, lui, met en œuvre le procédé selon le mode de réalisation décrit ci-dessus en relation avec la [fig. 1].
De manière générale, les routeurs de bordure ASBR1, 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 œuvre 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 peuvent par exemple se faire en parallèle des transmissions des informations EGP « classiques » (flèches 300_4).
De la sorte, selon le mode de réalisation de la dans lequel le dispositif 100’ de sécurisation reçoit le délai d’errance, l’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 ;
- transmission du délai d’errance à au moins un autre dispositif inclus dans un nœud qui n’est pas situé le long du chemin de données pour mise en œuvre 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
- une combinaison de tout ou partie des alternatives précitées du groupe.
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 . 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.
On présente désormais, en relation avec la une mise en œuvre du procédé de sécurisation selon un autre mode de réalisation de l’invention.
Plus particulièrement, le mode de réalisation représenté sur la 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 Reflector » en anglais) est utilisé dans les domaines autonomes correspondants.
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 BGP). Selon le mode de réalisation considéré discuté ci-dessus en relation avec la , 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 (calculé par un nœud 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é.
De retour à la , l’EGP mis à jour est envoyé au routeur 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).
Ainsi, selon le mode de réalisation de la 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].
On présente désormais, en relation avec la une mise en œuvre du procédé de sécurisation selon encore un autre mode de réalisation de l’invention.
Dans le mode de réalisation de la , 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 nœud de confiance qui n’est pas situé sur le chemin de données à sécuriser.
Plus particulièrement, le dispositif 100’’ de sécurisation reçoit le (ou les) délai de franchissement à partir d’un nœud N1, 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.
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 nœud N1, 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.).
Ensuite les paquets de données transportent « in-band » (i.e. dans un champ de données qu’ils véhiculent eux-mêmes) les deux paramètres :
- RND ; et
- PoT : somme partielle du secret partagé que les nœuds N1, N2, N3, N5, N6 calculent (la constante du polynôme POLY1 selon PoT).
Comme rappelé ci-dessus, dans le mode de réalisation de la , 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 nœuds 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 nœud N1, N2, N3, N5 ou N6 ne peut donc pas calculer de délai d’errance.
Afin de protéger les échanges le contrôleur Contr active le protocole PoT sur le chemin N1 vers N5 dans N1, N2 et N5. Plus particulièrement, le contrôleur Contr configure (flèches 500_1) le secret commun POLY2 et le secret de chaque nœud N1, N2, N5 du chemin (xi,yi) au niveau de chacun des nœuds en question, ainsi que du résultat attendu au niveau du dernier nœud du chemin, ici N5. N5 est donc le seul à (après le contrôleur Contr) connaitre la mesure de PoT attendu (aka la constante de POLY1). Ensuite chaque nœud 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 Contr, par exemple POLY1, POLY2, RND et le secret de chaque nœud (xi,yi). Par exemple. Ceci permet :
- La détection de la modification et authentification des nœuds de passage dans les nœuds : (xi,yi) est utilisé comme clé de signature HMAC (pour « keyed-hash message authentication code » en anglais),
- 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 à POLY1.
Optionnellement, pour un flux de paquets d’une connexion selon le protocole QUIC allant du terminal utilisateur UE au serveur Serv, chaque nœud N1, N2, N3, N5 ou N6 synchronise l’exportation du ticket IPFIX 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 :
- chaque nœud N1, 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
- le demi temps de transit effectif aller-retour obtenu, notamment au niveau du nœud N5, permet un calcul de délai d’errance très précis.
Un exemple de format de ticket est :
{
Flux identifier quintuplé, …
t0,
t1,
nombre d’octets,
nombre paquets,
délai de franchissement local cumulé,
Spatial delay : {demi temps de transit effectif aller-retour montant, demi temps de transit effectif aller-retour descendant}
}
Le dispositif 100’’ du collecteur Coll reçoit les délais de franchissement des différents nœuds N1, N2, N3, N5, N6. Il les déchiffre à l’aide des « decryption keys » 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 nœuds N1, N2, N3, N5, N6 sur la base d’informations d’encryptage qui ont été obtenues par les différents nœuds 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 nœuds 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 nœuds N1, 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.
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. Il signale une augmentation excessive comme une attaque possible d’un nœud du chemin sur le flux de paquets.
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 nœud qui n’est pas situé le long du chemin de données pour mise en œuvre 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).
Ainsi, selon le mode de réalisation de la 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].
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 ) 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 BGP). L’EGP mis à jour est renvoyé par le réflecteur de route RR à tout ou partie des nœuds N1, N2, N3, N5, N6 (flèche 500_4).
Dans d’autres modes de réalisation, d’autres types de protection que celle mise en œuvre 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.
Dans encore d’autres modes de réalisation, aucune protection des données n’est mise en œuvre pour la transmission des données (e.g. le (ou les) délai de franchissement ou de lien) au dispositif de sécurisation.
On présente désormais, en relation avec la un exemple de structure de dispositif 600 permettant de mettre en œuvre les étapes du procédé de sécurisation de la [fig. 2] selon un mode de réalisation de l’invention.
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.
Cette 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 reprogrammable (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).
Dans le cas où le dispositif 600 est réalisé avec une machine de calcul reprogrammable, 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.
Dans certains modes de réalisation, le dispositif 600 implémente l’un quelconque des dispositifs de sécurisation 100, 100’ ou 100’’.
Dans certains modes de réalisation, le dispositif 600 implémente plusieurs ou la totalité des dispositifs de sécurisation 100, 100’ ou 100’’.
Dans certains modes de réalisation, le dispositif 600 est inclus dans un nœud de réseau (e.g. N1, N2, N3, N4, N5, N6, RR, Coll, ASBR, R_AS, etc.).
Claims (14)
- 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,
caractérisé en ce qu’un dispositif (100, 100’, 100’’, 600) de sécurisation effectue les étapes suivantes :
-obtention(E200) d’un délai d’errance représentatif d’un écart entre un délai de transit de bout-en-bouteffectifdudit au moins un paquet de données le long dudit chemin de données et un délai de transit de bout-en-boutattendududit au moins un paquet de données le long dudit chemin de données ; et
-sécurisation(E210) de ladite transmission par mise en œuvre d’au moins une action de sécurisation à partir dudit délai d’errance.
- Procédé selon la revendication 1 dans lequel ladite obtention dudit délai d’errance correspond à un calcul dudit délai d’errance comprenant une obtention dudit délai de transit de bout-en-bouteffectifpar :
- mesure préalable dudit délai de transit de bout-en-bout le long dudit chemin de données ; ou par
- mesure préalable d’une demie valeur du délai de transit aller-retour le long dudit chemin de données.
- Procédé selon la revendication 2 dans lequel ledit chemin de données passe par au moins un nœud dudit réseau,
et dans lequel, pour chacun desdits nœuds, ledit calcul dudit délai d’errance comprend une obtention d’un délai de franchissement dudit nœud pour ledit au moins un paquet de données,
ledit délai de transit de bout-en-boutattenduétant fonction dudit au moins un délai de franchissement.
- Procédé selon la revendication 3 dans lequel ledit chemin de données passe par au moins deux nœuds dudit réseau,
et dans lequel, pour chaque paire de nœuds parmi lesdits au moins deux nœuds, ledit calcul dudit délai d’errance comprend une obtention d’un délai de propagation dudit au moins un paquet de données le long dudit chemin de données entre les nœuds de ladite paire de nœuds,
ledit délai de transit de bout-en-boutattenduétant fonction dudit au moins un délai de propagation.
- Procédé selon la revendication 4 dans lequel ledit délai d’errance est calculé comme une fonction dudit délai de transit de bout-en-bouteffectifauquel est soustrait ledit au moins un délai de franchissement et/ou ledit au moins un délai de propagation.
- Procédé selon l’une quelconque des revendications 3 à 5 dans lequel ledit chemin de données s’étend entre un premier et un deuxième nœud de réseau dudit réseau, ledit dispositif (100, 600) de sécurisation étant logé dans ledit deuxième nœud de réseau,
dans lequel 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.
- Procédé selon l’une quelconque des revendications 1 à 6 dans lequel ladite au moins une action de sécurisation appartient au groupe comprenant :
- inscription dudit délai d’errance dans ledit au moins un paquet de données ;
- inscription dudit délai d’errance en association avec ledit chemin de données dans un plan de routage d’un domaine autonome dudit réseau auquel appartient ledit chemin de données ;
- destruction ou duplication pour analyse dudit au moins un paquet de données lorsque ledit délai d’errance est supérieur à un seuil prédéterminé ;
- transmission dudit délai d’errance à au moins un autre dispositif inclus dans un nœud qui n’est pas situé le long dudit chemin de données pour mise en œuvre d’une autre action de sécurisation ; et
- une combinaison de tout ou partie des alternatives précitées du groupe.
- Procédé selon l’une quelconque des revendications 3 à 5 dans lequel ledit dispositif (100’’, 600) de sécurisation n’est pas situé le long dudit chemin de données,
et dans lequel ledit délai de franchissement est reçu à partir dudit au moins un nœud via au moins un autre paquet de données distinct dudit au moins un paquet de données.
- Procédé selon la revendication 8 dans lequel ledit délai de franchissement est reçu sous une forme encryptée, ledit dispositif de sécurisation et ledit au moins un nœud partageant la connaissance d’au moins une information d’encryptage.
- Procédé selon l’une quelconque des revendications 1 à 5, ou selon la revendication 8 ou 9, dans lequel ladite au moins une action de sécurisation appartient au groupe comprenant :
- inscription dudit délai d’errance en association avec ledit chemin de données dans un plan de routage d’un domaine autonome dudit réseau auquel appartient ledit chemin de données ;
- transmission dudit délai d’errance à au moins un autre dispositif inclus dans un nœud qui n’est pas situé le long dudit chemin de données pour mise en œuvre d’une autre action de sécurisation ; et
- une combinaison de tout ou partie des alternatives précitées du groupe.
- Procédé selon la revendication 1 dans lequel ladite obtention dudit délai d’errance correspond à une réception, via un autre paquet de données distinct dudit au moins un paquet de données, dudit délai d’errance depuis un autre dispositif situé le long dudit chemin de données,
et dans lequel ladite au moins une action de sécurisation appartient au groupe comprenant :
- inscription dudit délai d’errance en association avec ledit chemin de données dans un plan de routage d’un domaine autonome dudit réseau auquel appartient ledit chemin de données ;
- transmission dudit délai d’errance à au moins un autre dispositif inclus dans un nœud qui n’est pas situé le long dudit chemin de données pour mise en œuvre d’une autre action de sécurisation ; et
- une combinaison de tout ou partie des alternatives précitées du groupe.
- Produit programme d’ordinateur comprenant des instructions de code de programme pour la mise en œuvre du procédé selon l’une quelconque des revendications 1 à 11, lorsque ledit programme est exécuté sur un ordinateur.
- Dispositif (100, 100’, 100’’, 600) 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,
caractérisé en ce qu’il comprend une machine de calcul reprogrammable (602) ou une machine de calcul dédiée, configurée pour :
- obtenir un délai d’errance représentatif d’un écart entre un délai de transit de bout-en-bouteffectifdudit au moins un paquet de données le long dudit chemin de données et un délai de transit de bout-en-boutattendududit au moins un paquet de données le long dudit chemin de données ; et
- sécuriser ladite transmission par mise en œuvre d’au moins une action de sécurisation à partir dudit délai d’errance.
- Nœud (N1, N2, N3, N4, N5, N6, RR, Coll, ASBR, R_AS) d’un réseau de télécommunicationscaractérisé en ce qu’il comprend au moins un dispositif selon la revendication 13.
Priority Applications (4)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FR1902974A FR3094163A1 (fr) | 2019-03-22 | 2019-03-22 | 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. |
| PCT/FR2020/050530 WO2020193902A1 (fr) | 2019-03-22 | 2020-03-13 | 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 |
| EP20726188.4A EP3942772A1 (fr) | 2019-03-22 | 2020-03-13 | 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 |
| US17/593,620 US20220159037A1 (en) | 2019-03-22 | 2020-03-13 | Method for securing the transmission of at least one data packet along a data path of a telecommunications network, corresponding computer program product and device |
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FR1902974 | 2019-03-22 | ||
| FR1902974A FR3094163A1 (fr) | 2019-03-22 | 2019-03-22 | 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. |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| FR3094163A1 true FR3094163A1 (fr) | 2020-09-25 |
Family
ID=67742595
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| FR1902974A Withdrawn FR3094163A1 (fr) | 2019-03-22 | 2019-03-22 | 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. |
Country Status (4)
| Country | Link |
|---|---|
| US (1) | US20220159037A1 (fr) |
| EP (1) | EP3942772A1 (fr) |
| FR (1) | FR3094163A1 (fr) |
| WO (1) | WO2020193902A1 (fr) |
Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20030033404A1 (en) * | 2001-08-09 | 2003-02-13 | Richardson David E. | Method for automatically monitoring a network |
| US20040107252A1 (en) * | 2002-09-27 | 2004-06-03 | Yuichi Futa | Group judgment device |
| US20100172259A1 (en) * | 2009-01-05 | 2010-07-08 | Qualcomm Incorporated | Detection Of Falsified Wireless Access Points |
| US20150009840A1 (en) * | 2013-07-03 | 2015-01-08 | Niksun, Inc. | Packet time stamp processing methods, systems, and apparatus |
Family Cites Families (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN107431638A (zh) * | 2015-01-27 | 2017-12-01 | 诺基亚通信公司 | 业务流监视 |
-
2019
- 2019-03-22 FR FR1902974A patent/FR3094163A1/fr not_active Withdrawn
-
2020
- 2020-03-13 EP EP20726188.4A patent/EP3942772A1/fr active Pending
- 2020-03-13 US US17/593,620 patent/US20220159037A1/en active Pending
- 2020-03-13 WO PCT/FR2020/050530 patent/WO2020193902A1/fr active Application Filing
Patent Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20030033404A1 (en) * | 2001-08-09 | 2003-02-13 | Richardson David E. | Method for automatically monitoring a network |
| US20040107252A1 (en) * | 2002-09-27 | 2004-06-03 | Yuichi Futa | Group judgment device |
| US20100172259A1 (en) * | 2009-01-05 | 2010-07-08 | Qualcomm Incorporated | Detection Of Falsified Wireless Access Points |
| US20150009840A1 (en) * | 2013-07-03 | 2015-01-08 | Niksun, Inc. | Packet time stamp processing methods, systems, and apparatus |
Also Published As
| Publication number | Publication date |
|---|---|
| US20220159037A1 (en) | 2022-05-19 |
| EP3942772A1 (fr) | 2022-01-26 |
| WO2020193902A1 (fr) | 2020-10-01 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| Meier et al. | {NetHide}: Secure and practical network topology obfuscation | |
| Beverly et al. | Understanding the efficacy of deployed internet source address validation filtering | |
| US20180123910A1 (en) | Minimally invasive monitoring of path quality | |
| US8189489B2 (en) | Characterization of network path quality for network applications and services | |
| US20150029871A1 (en) | Service level agreement validation via service traffic sample-and-replay | |
| US9813300B2 (en) | Media flow tracing in third party devices | |
| FR3009163A1 (fr) | Procede pour l'echange en securite d'une donnee sur un reseau ad-hoc mettant en oeuvre un service de diffusion xcast; noeud associe | |
| Chen et al. | One primitive to diagnose them all: Architectural support for internet diagnostics | |
| Okada et al. | Application identification from encrypted traffic based on characteristic changes by encryption | |
| Chandrasekaran et al. | A server-to-server view of the Internet | |
| FR3086823A1 (fr) | Procede et systeme de surveillance d'une connexion entre deux equipements d'extremites, produit programme d'ordinateur correspondant. | |
| EP2211504A1 (fr) | Procédé de classification coopérative de trafics IP | |
| EP1992111A2 (fr) | Procede de collecte de descriptions de flux portant sur des flux relatifs a au moins un reseau client rattache a un reseau d'interconnexion | |
| Pan et al. | End-to-end measurements for network tomography under multipath routing | |
| Bashir et al. | Classifying P2P activity in Netflow records: A case study on BitTorrent | |
| De Vries et al. | How asymmetric is the internet? a study to support the use of traceroute | |
| WO2019076765A1 (fr) | Gestion de la connexion avec d'autres passerelles residentielles d'une passerelle residentielle mettant en oeuvre l'agregation de liens | |
| FR3094163A1 (fr) | 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. | |
| Xie et al. | Survey on traffic of metro area network with measurement on-line | |
| Karapoola et al. | Net-Police: A network patrolling service for effective mitigation of volumetric DDoS attacks | |
| Abt et al. | Towards Efficient and Privacy-Preserving Network-Based Botnet Detection Using Netflow Data. | |
| Shahzad et al. | Accurate and efficient per-flow latency measurement without probing and time stamping | |
| FR3095729A1 (fr) | Procédés et dispositifs de mesure de réputation dans un réseau de communication | |
| Gossett et al. | An apparatus for P2P classification in Netflow traces | |
| Torres et al. | Characterization of community based-P2P systems and implications for traffic localization |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PLFP | Fee payment |
Year of fee payment: 2 |
|
| PLSC | Publication of the preliminary search report |
Effective date: 20200925 |
|
| ST | Notification of lapse |
Effective date: 20211105 |