FR 3117296 A1 20220610 FR 2010858 A 20201022 Procédés et dispositifs de protection de flux de paquets L'invention concerne un procédé de priorisation d’un flux de paquets, le procédé étant mis en œuvre par le nœud routeur connecté au nœud récepteur et comprenant : la réception d'un message comprenant la valeur attendue du paramètre de protection, en provenance d'un dispositif associé au nœud récepteur, la priorisation des paquets comprenant la valeur attendue du paramètre de protection. Figure pour l'abrégé: Figure 1 Procédé et dispositif de priorisation de flux de paquets 1. Domaine de l'invention L’invention se situe dans le domaine des télécommunications, et plus particulièrement des réseaux constitués de routeurs acheminant des paquets IP. 2. Etat de la technique antérieure Dans de nombreuses usages de type VPN (Virtual Private Network, ou réseau privé virtuel), et en particulier pour les offres de type SD-WAN (Software Defined Wide Area Network, ou réseau métropolitain défini par logiciel) qui gagnent en popularité de nos jours, des tunnels IPsec sont établis entre des sites du VPN d'un client, par exemple une entreprise établie sur plusieurs sites. Ces tunnels IPsec sont transportés par un réseau IP ou MPLS qui n’a pas connaissance de ces tunnels IPsec. Ce réseau "de transport" est typiquement l’Internet du fait de son ubiquité, haut débit et bas coût. Tous les utilisateurs du réseau IP de transport peuvent également envoyer des paquets vers les sites clients. Dans le cas de l’Internet, un très grand nombre d’utilisateurs (de l'ordre du milliard) peuvent donc envoyer des paquets, potentiellement à haut débit. Un attaquant quelconque dans l’Internet peut ainsi envoyer une grande quantité de paquets sur un site client et ainsi saturer l’interface client et/ou ou le routeur client, réalisant ainsi une attaque par déni de service (DOS). Il peut également utiliser de nombreuses sources de trafic différentes toutes dirigées vers une même destination - le site client destinataire des paquets IPsec - réalisant ainsi une attaque par déni de service distribué (DDOS). De ce fait, le tunnel IPsec n’a plus de ressources et la quasi-totalité de son trafic est détruit en amont de sa destination, typiquement sur le dernier routeur du réseau de transport IP/MPLS. Une solution connue est de déployer des équipements de protection capable d’analyser tous les flux/paquets en direction du site client, d’essayer de distinguer le trafic légitime du trafic de DDOS, et de prioriser le trafic légitime au dépends du trafic de DDOS. Cette solution présente plusieurs inconvénients. Cette solution repose sur de la force brute d’analyse de tous les paquets de tous les flux. Elle est donc intrinsèquement couteuse et ne passe pas à l’échelle de la réalité. De plus, le travail nécessaire à l’analyse et la protection est beaucoup plus compliqué que le travail d’envoyer des paquets d’attaques. De ce fait, le défenseur est intrinsèquement dans une position d'infériorité par rapport à l’attaquant. Cette solution ne peut garantir qu’elle peut/pourra distinguer les paquets ou les flux légitimes par rapport aux paquets ou flux d’attaques. Elle se base sur des heuristiques suite aux attaques précédentes ou sur le fait que l’attaquant a des chances d’envoyer des paquets/flux relativement semblables afin de se simplifier la vie, d’optimiser le travail des équipements attaquant et/ou utilise des équipements qu’il ne contrôle pas entièrement (attaques par réflexion). Mais un attaquant suffisamment motivé avec suffisamment de ressources (payées ou volées) a toutes les chances d’échapper à la détection. Enfin, cette solution doit être dimensionnée pour la plus grosse attaque possible, même si celle-ci n’est subie qu’une seule fois par an. Ce coût maximum est difficile à amortir sur l’ensemble des attaques plus petites. Mais si l’opérateur ne fait pas cet investissement, d’une part le client ne peut plus avoir confiance dans l’offre et d’autre part l’attaquant connait le point faible. Un des buts de l'invention est de remédier à ces inconvénients de l'état de la technique. 3. Exposé de l'invention L'invention vient améliorer la situation à l'aide d'un procédé de protection d’un flux de paquets dans un réseau composé de nœuds routeurs de paquets, et de nœuds émetteur et récepteur du flux, le nœud récepteur étant connecté à un nœud routeur traitant le routage d'un paquet à destination du nœud récepteur en fonction d'une valeur attendue d'un paramètre de protection compris dans au moins un champ d'un paquet du flux, le procédé étant mis en œuvre par un dispositif associé au nœud récepteur et comprenant : l'émission d'un message comprenant la valeur attendue du paramètre de protection, à destination du nœud routeur connecté au nœud récepteur. Dans un réseau classique, les routeurs sont gérés par un opérateur qui n'a pas la connaissance de la légitimité des flux traversant les routeurs, car ces flux sont établis par des entités tierces. Une entité tierce est par exemple une entreprise gérant des nœuds émetteurs et récepteurs de flux de paquets entre des sites ou des machines de l'entreprise, ces nœuds émetteurs et récepteurs étant collectivement appelés nœuds clients. Cette entreprise est cliente de l'opérateur des nœuds routeurs, et/ou d'un fournisseur dit OTT (Over The Top), c'est à dire un fournisseur utilisant à des fins commerciales les ressources et les capacités de ces mêmes routeurs qui toutefois restent gérés par leur opérateur. Grâce à l'invention, les flux véhiculés sont protégés par les routeurs, alors que ces flux ne sont pas nécessairement gérés (c’est-à-dire générés, émis ou reçus) par l'opérateur des routeurs. Le message comprenant la valeur du paramètre de protection peut être un message envoyé directement ou indirectement, depuis un équipement de gestion de flux vers un nœud routeur. Cet équipement de gestion de flux est associé au nœud récepteur d'un flux, c’est-à-dire qu'il peut être compris dans un nœud client, c’est-à-dire dans le nœud émetteur ou dans le nœud récepteur, ou dans une autre entité comme par exemple un équipement de supervision ou de contrôle ou de configuration des nœuds clients. Ce peut être par exemple un nœud contrôleur de réseau SD-WAN. Le traitement des paquets effectué par le routeur est fonction du paramètre de protection reçu dans le message. Par exemple, si un paquet reçu par le routeur présente la valeur attendue du paramètre dans un champ déterminé et associé au flux, il est traité selon une politique déterminée à l'avance, c’est-à-dire par exemple qu'il est affecté d’une priorité (QoS) plus forte. Cela n'exclut pas que si au contraire le paquet ne présente pas la valeur attendue du paramètre de protection, un autre aspect de la politique mentionnée plus haut puisse défavoriser le flux auquel appartient le paquet, par exemple en en abaissant la priorité, ou en le filtrant. Selon un aspect du procédé de protection d’un flux de paquets, l'émission du message comprenant la valeur attendue du paramètre de protection est déclenchée par l'obtention d'une information indicative d'une congestion entre le nœud émetteur et le nœud récepteur. Grâce à cet aspect, l'effet d'une attaque peut être neutralisé même après qu'elle ait commencé. En effet, un des premiers effets d'une attaque est l'augmentation du volume des données à destination du nœud récepteur. Cette augmentation peut être détectée à plusieurs niveaux, par exemple au niveau du nœud émetteur qui n'arrive plus à communiquer correctement avec le nœud récepteur, au niveau d'un nœud routeur sur lequel arrive en transit un volume excessif de données à destination du nœud récepteur, ou au niveau du nœud récepteur lui-même qui reçoit un volume excessif de données. Si la congestion n'est pas détectée au niveau du dispositif émettant le message du paramètre de protection, l'information indicative d'une congestion lui est transmise. Dans ce mode, le procédé selon l'invention représente une solution en réaction à une attaque. On comprend également que la valeur du paramètre peut être changée aussi fréquemment que nécessaire, entre autre si l'attaquant découvre la bonne valeur du paramètre de protection. Selon un aspect du procédé de protection d’un flux de paquets, un nouveau message est réémis avec une nouvelle valeur du paramètre de protection, après expiration d'une période définie. Grâce à cet aspect, même si un attaquant découvre la valeur courante du paramètre de protection, elle aura changé même en cas d'attaque au niveau du nœud récepteur, à la condition que cette attaque n'empêche pas la réémission du message. Dans ce mode, le procédé selon l'invention représente une solution en prévention d'une attaque. Selon un aspect du procédé de protection d’un flux de paquets, le message comprend plusieurs valeurs attendues du paramètre de protection, chaque valeur correspondant à une période différente d'utilisation. Grâce à cet aspect, même si un attaquant découvre la valeur courante du paramètre de protection, elle est remplacée par une autre valeur fournie à l’avance. Dans un mode, cela peut être fait de façon planifiée et synchronisée avec l’émetteur du flux, au moyen d’un changement automatique de la valeur du paramètre de protection au bout d'une période déterminée à l'avance, sans qu'il soit nécessaire de réémettre le message. Ceci est particulièrement avantageux si une attaque en cours rend impossible l'émission d’un nouveau message. Dans ce mode, le procédé selon l'invention représente une solution à la fois en réaction à, et en prévention d'une attaque. Dans un autre mode, cela peut aussi être fait en réaction à une attaque, sans qu'il soit nécessaire de réémettre un nouveau message, au moyen d’un changement de la valeur du paramètre de protection qui est par exemple déclenché par l'obtention d'une information indicative d'une congestion entre le nœud émetteur et le nœud récepteur. Dans ce mode le nœud routeur doit également émettre un message pour informer le nœud émetteur du flux à partir de quel moment la valeur du paramètre de protection a changé. L'invention vient de plus améliorer la situation à l'aide d'un procédé de priorisation d’un flux de paquets dans un réseau composé de nœuds routeurs de paquets, et de nœuds émetteur et récepteur du flux, le nœud récepteur étant connecté à un nœud routeur traitant le routage d'un paquet à destination du nœud récepteur en fonction d'une valeur attendue d'un paramètre de protection compris dans au moins un champ d'un paquet du flux, le procédé étant mis en œuvre par le nœud routeur connecté au nœud récepteur et comprenant : la réception d'un message comprenant la valeur attendue du paramètre de protection, en provenance d'un dispositif associé au nœud récepteur, la priorisation des paquets comprenant la valeur attendue du paramètre de protection. On comprend que grâce à ce procédé les flux spécifiés ou attendus par les nœuds clients sont aussi attendus par le nœud récepteur connecté au nœud récepteur. Si ces flux arrivent jusqu'à ce nœud routeur tout en étant destinés au nœud récepteur client, ils sont routés jusqu'au nœud récepteur client en étant priorisés, uniquement si les paquets de tels flux présentent la valeur attendue du paramètre de protection. Cette priorisation est avantageuse dans toute situation de fort trafic à destination du nœud récepteur engendrant des ralentissements au niveau des nœuds routeurs ou des liens entre eux, lorsque tous les flux, sans être forcément illégitimes, ne sont pas ceux attendus par le nœud récepteur. Cet avantage est d'autant plus intéressant en cas d'attaque par DOS ou DDOS vers un nœud client. Le dispositif à l'initiative du message comprenant la valeur du paramètre de protection fait partie du même domaine administratif que le nœud récepteur client, ce domaine étant par exemple celui du réseau client. Le nœud routeur effectuant le filtrage, connecté au nœud récepteur, peut recevoir ce message directement du réseau client. Dans un autre mode de réalisation, il peut aussi le recevoir indirectement, si par exemple un équipement intermédiaire doit en modifier le format et/ou s'il n'est pas possible pour le nœud routeur de recevoir une signalisation directement du réseau client. Cet équipement intermédiaire peut être un contrôleur de flux faisant partie du réseau opérateur comprenant les nœuds routeurs, et ne comprenant pas les nœuds émetteur et récepteur, auquel le dispositif associé au nœud récepteur peut envoyer des signalisations. Selon un aspect du procédé de priorisation d’un flux de paquets, la priorisation comprend la mise des paquets dans une file d'attente ayant accès à une ou plusieurs interfaces de sortie du nœud routeur, l'accès étant prioritaire sur au moins une autre file d'attente. Grâce à cet aspect, le nœud routeur place un paquet marqué dans une file d’attente (queue) différente qui sera servie (utilisée) en priorité lors de l’émission des paquets sur le lien en sortie du nœud routeur. Cela peut être en priorité stricte, c’est-à-dire tant que cette queue a des paquets à envoyer, c’est la seule qui a accès à l’interface de sortie. En priorité moins stricte, la file d’attente prioritaire peut avoir des caractéristiques différentes des autres, par exemple une capacité plus grande (buffer plus grand), une politique d'élimination des paquets en débordement moins agressive ou rapide en cas de congestion, etc. Selon un aspect du procédé de priorisation d’un flux de paquets, le procédé comprend en outre : le filtrage des paquets ne comprenant pas la valeur attendue du paramètre de protection. Grâce à cet aspect, non seulement les flux spécifiés ou attendus par les nœuds clients sont routés en étant priorisés jusqu'à un nœud client par un nœud routeur, mais les autres flux sont modifiés défavorablement (la modification pouvant aller jusqu'à la destruction de tous les paquets du flux). Cette modification défavorable d'un flux est désignée par le terme de "filtrage" dans la suite. Même si les paquets reçus par le nœud routeur indiquent l'adresse de destination du nœud client, ils ne sont donc pas routés vers lui normalement ou selon le traitement par défaut si ces paquets ne présentent pas aussi la valeur attendue du paramètre de protection, dans le ou les champs attendus. Ainsi, une attaque par DOS ou DDOS vers le nœud client devient impossible. Selon un aspect du procédé de priorisation d’un flux de paquets, le filtrage comprend un blocage des paquets, ou une destruction des paquets, ou un abaissement de la priorité des paquets. Grâce à cet aspect, selon une politique appliquée par l'opérateur et décidée en concertation ou non avec le client, lorsqu'un paquet ne présente pas la bonne valeur du paramètre de protection, soit la priorité du paquet est abaissée, ce qui ralentit l'arrivée des paquets du flux sur le nœud client récepteur en lui permettant de continuer à recevoir d'autres flux, soit tous les paquets du flux sont bloqués, ou détruits sans être transmis, ce qui préserve complètement le nœud client récepteur de toute nuisance que ce flux lui causerait. Selon un aspect du procédé de priorisation d’un flux de paquets, le procédé comprend en outre l'émission du message comprenant la valeur attendue du paramètre de protection, vers un nœud routeur voisin du nœud routeur connecté au nœud récepteur. Grâce à cet aspect, la priorisation des flux est rendue possible au niveau d'un nœud voisin du nœud routeur connecté au nœud client, de préférence en amont du flux. Cela est avantageux dans le cas d'une attaque DDoS, où les flux attaquant arrivent sur le dernier nœud routeur en provenance de plusieurs nœuds routeurs immédiatement voisins. La charge de prioriser les flux est ainsi mieux répartie dans le réseau de routeurs. L'émission du message, qui est équivalent à l'émission d'une commande de priorisation, peut n'être déclenchée que sur atteinte d'un seuil, par exemple lorsque le volume de données reçues par le nœud routeur ou sur son interface amont atteint un seuil au-delà duquel le fonctionnement du nœud routeur ou de son interface amont est mis en danger. Selon un aspect du procédé de protection et du procédé de priorisation d’un flux de paquets, le paramètre de protection est inclus dans l'adresse IPv6 de destination des paquets du flux. Grâce à cet aspect, une particularité existante des adresses en IPv6 est exploitée avantageusement. En effet les derniers bits d’une adresse IPv6, par exemple les 64 derniers bits, peuvent être déterminés et modifiés à volonté par l'utilisateur du flux, par exemple le client utilisateur des nœuds émetteur et récepteur, client du réseau opérateur formé par les nœuds routeurs, sans impacter le routage des paquets vers leur destination finale. Ces 64 bits représentent un très grand nombre de valeurs possibles pour le paramètre de protection, ce qui rend leur découverte par un attaquant difficile voire impossible. Selon un aspect du procédé de protection et du procédé de priorisation d’un flux de paquets, le flux est un tunnel IPsec ou un tunnel IP. Grâce à cet aspect, la solution de protection couvre les flux les plus courants et les plus importants car typiquement à destinations de plusieurs destinataires. De plus, certains paramètres existants spécifiques de ces tunnels peuvent avantageusement être utilisés en tant que paramètre de protection selon l'invention. Des exemples de tunnel IP sont L2TP, GRE, UDP, SRv6 (Segment Routing IPv6). Selon un aspect du procédé de protection et du procédé de priorisation d’un flux de paquets, l'au moins un champ comprenant le paramètre de protection est un ou plusieurs des champs d'une liste comprenant: "Security Parameters Index" (SPI) de IPsec, "Protocol" de IPv4, "Next Header" de IPv6, "Flow Label" de IPv6, adresse IP source, ou adresse IP destination, ou port source, ou port destination, de IPv4 ou IPv6. "Key" de GRE, Segment List, ou Segment List [n], ou Tag, ou HMAC TLV de Segment Routing IPv6 (SRv6). Grâce à cet aspect, le flux reçu transitant par le nœud routeur peut être traité en fonction de plusieurs paramètres de protection, ce qui représente une combinaison plus difficile à découvrir par un attaquant, tout en fournissant plus de flexibilité à l’émetteur/récepteur du flux pour adapter la solution à ses cas d’usage. L’utilisation d’un paramètre spécifique à un contexte (tel que SPI, spécifique à IPsec) donne également une meilleure protection qu’un paramètre présent dans les tous paquets, quel que soit le contexte (tel que l'adresse IP ou le port), car il faut que l’attaquant découvre aussi le contexte (tel que le type de tunnel qu'utilise le flux). Selon un aspect du procédé de protection et du procédé de priorisation d’un flux de paquets, le message comprenant la valeur attendue du paramètre de protection est un message d'un des protocoles suivants: BGP Flow Spec, NETCONF, RESTCONF, En ligne de commande (CLI: Command Line Interface), SNMP, API REST, API. Grâce à cet aspect, le procédé selon l'invention s'insère dans une architecture réseau existante en réutilisant un protocole de communication déjà utilisé par des nœuds routeurs. L'invention concerne aussi un dispositif de protection d’un flux de paquets dans un réseau composé de nœuds routeurs de paquets, et de nœuds émetteur et récepteur du flux, le nœud récepteur étant connecté à un nœud routeur traitant le routage d'un paquet à destination du nœud récepteur en fonction d'une valeur attendue d'un paramètre de protection compris dans au moins un champ d'un paquet du flux, le dispositif étant associé au nœud récepteur et comprenant un récepteur, un émetteur, un processeur et une mémoire couplée au processeur avec des instructions destinées à être exécutées par le processeur pour : l'émission d'un message comprenant la valeur attendue du paramètre de protection, à destination du nœud routeur connecté au nœud récepteur. Ce dispositif, apte à mettre en œuvre dans tous ses modes de réalisation le procédé de protection de flux qui vient d'être décrit, est destiné à être mis en œuvre dans un équipement du sous-réseau composés des nœuds émetteur et récepteur du flux, aussi appelé réseau client. Il peut faire partie du nœud récepteur ou du nœud émetteur, ou faire partie d'un équipement de gestion du réseau client, distinct des nœuds émetteur ou récepteur du flux, par exemple un nœud contrôleur SD-WAN si le réseau client est de type SD-WAN. Dans tous les cas ce dispositif est associé au nœud récepteur, c’est-à-fait partie du même domaine administratif. L'invention concerne aussi un dispositif de priorisation d’un flux de paquets dans un réseau composé de nœuds routeurs de paquets, et de nœuds émetteur et récepteur du flux, le nœud récepteur étant connecté à un nœud routeur traitant le routage d'un paquet à destination du nœud récepteur en fonction d'une valeur attendue d'un paramètre de protection compris dans au moins un champ d'un paquet du flux, le dispositif étant mis en œuvre dans le nœud routeur connecté au nœud récepteur et comprenant un récepteur, un émetteur, un processeur et une mémoire couplée au processeur avec des instructions destinées à être exécutées par le processeur pour : la réception d'un message comprenant la valeur attendue du paramètre de protection, en provenance d'un dispositif associé au nœud récepteur, la priorisation des paquets comprenant la valeur attendue du paramètre de protection. Ce dispositif, apte à mettre en œuvre dans tous ses modes de réalisation le procédé de priorisation de flux qui vient d'être décrit, est destiné à être mis en œuvre dans un nœud du sous-réseau composé des nœuds routeurs, aussi appelé réseau opérateur. Plus précisément ce dispositif fait partie du nœud routeur connecté au nœud récepteur du réseau client. L'invention concerne aussi un programme d'ordinateur comprenant des instructions qui, lorsque ces instructions sont exécutées par un processeur, conduisent celui-ci à mettre en œuvre les étapes du procédé de protection, qui vient d'être décrit. L'invention concerne aussi un programme d'ordinateur comprenant des instructions qui, lorsque ces instructions sont exécutées par un processeur, conduisent celui-ci à mettre en œuvre les étapes du procédé de priorisation, qui vient d'être décrit. L’invention vise aussi un support d'informations lisible par un dispositif de protection, et comportant des instructions d'un programme d'ordinateur tel que mentionné ci-dessus. L’invention vise aussi un support d'informations lisible par un dispositif de priorisation, et comportant des instructions d'un programme d'ordinateur tel que mentionné ci-dessus. Les programmes mentionnés ci-dessus peuvent utiliser n’importe quel langage de programmation, et être sous la forme de code source, code objet, ou de code intermédiaire entre code source et code objet, tel que dans une forme partiellement compilée, ou dans n’importe quelle autre forme souhaitable. Les supports d'informations mentionnés ci-dessus peuvent être n'importe quelle entité ou dispositif capable de stocker le programme. Par exemple, un support peut comporter un moyen de stockage, tel qu'une ROM, par exemple un CD ROM ou une ROM de circuit microélectronique, ou encore un moyen d'enregistrement magnétique. Un tel moyen de stockage peut par exemple être un disque dur, une mémoire flash, etc. D'autre part, un support d'informations peut être un support transmissible tel qu'un signal électrique ou optique, qui peut être acheminé via un câble électrique ou optique, par radio ou par d'autres moyens. Un programme selon l'invention peut être en particulier téléchargé sur un réseau de type Internet. Alternativement, un support d'informations peut être un circuit intégré dans lequel un programme est incorporé, le circuit étant adapté pour exécuter ou pour être utilisé dans l'exécution des procédés en question. 4. Présentation des figures D'autres avantages et caractéristiques de l'invention apparaitront plus clairement à la lecture de la description suivante d'un mode de réalisation particulier de l'invention, donné à titre de simple exemple illustratif et non limitatif, et des dessins annexés, parmi lesquels : la représente, de façon schématique, un réseau comprenant des nœuds routeurs et des nœuds clients conformes à l’invention, dans un mode particulier de réalisation, la présente un exemple de structure d'un dispositif de protection, mis en œuvre côté réseau client, selon des aspects de l'invention, la présente un exemple de structure d'un dispositif de priorisation, mis en œuvre côté réseau de routeurs, selon des aspects de l'invention. 5. Description détaillée d'au moins un mode de réalisation de l'invention La représente, de façon schématique, un réseau comprenant des nœuds routeurs et des nœuds clients conformes à l’invention, dans un mode particulier de réalisation. Le réseau N1 comprend un sous-réseau N2 composé de nœuds routeurs R1 à R4 gérés par un opérateur de télécommunications, appelé réseau opérateur, et un sous-réseau N3 composé de nœuds clients C1 à C3 gérés par une entité tierce indépendante de l'opérateur, appelé réseau client. Le réseau opérateur N2 est par exemple un réseau IP/MPLS, aussi dit réseau de transport. Le réseau client N3 peut être de type VPN, SD-WAN, etc. Dans un mode particulier de réalisation, un flux F1 est établi entre le nœud client C1 et le nœud client C3. Le nœud client C1 est connecté au nœud routeur R1, le nœud client C3 est connecté au nœud routeur R3, et le flux F1 émis par le nœud C1 à destination du nœud client C3 emprunte une route B1 commençant au nœud client C1, passant par les nœuds routeurs R1, R2 et R3, et se terminant au nœud client C3. Le nœud client C3 peut recevoir d'autres flux en provenance d'autres sources, comme par exemple un flux F2 émis par la source A1, empruntant ou étant destiné à emprunter une route B2 ayant en commun avec la route B1 le nœud routeur R3 et le nœud client C3. La source A1 peut être tout type d'équipement apte à se connecter à un nœud routeur du réseau opérateur N2. Par simplicité la source A1 est illustrée par un nuage figurant en dehors des réseaux N2 ou N3, mais elle peut faire partie ou non du réseau opérateur N2, ou faire partie ou non du réseau client N3. Un problème survient lorsque le flux F2 émis par la source A1 n'est pas un flux attendu par le nœud client C3 et présente un volume de données susceptible de dégrader le fonctionnement du nœud client C3. Ce problème est souvent nommé dans la littérature attaque par déni de service, ou attaque DoS (Denial of Service, en anglais). La source A1, illustrée dans la comme étant unique par simplicité, peut aussi être multiple, ce qui aggrave le problème. On parle alors d'attaque DoS distribuée, ou attaque DDoS (Distributed DoS, en anglais). Les multiples flux émis par la source multiple A1, autrement dit l'attaquant DDoS, peuvent emprunter des routes différentes mais ils aboutissent tous sur le nœud routeur R3 qui est le dernier nœud routeur avant le nœud attaqué qui est le nœud client C3. Afin de repousser une telle attaque, les flux arrivant sur le nœud routeur R3 et qui ne sont pas légitimement attendus par le nœud client C3 et risquent de lui nuire, doivent être filtrés, c’est-à-dire soit bloqués, soit réduits dans leur volume ou dans leur débit, soit abaissés en terme de priorité (QoS). Abaisser la priorité des flux est particulièrement avantageux s'il est important de laisser passer certains flux légitimes mais non prévisibles venant de l'Internet, tant qu'une attaque n'est pas en cours. Selon l'invention, en remplacement ou en complément de ce filtrage, les flux arrivant sur le nœud routeur R3, et qui sont légitimement attendus par le nœud client C3, sont priorisés par rapport aux autres flux. Dans ce but, selon l'invention, un flux doit pouvoir fournir au nœud routeur R3 un paramètre particulier avant d'être transmis par le nœud routeur R3 à sa destination qui est le nœud client C3. Ce paramètre de protection, comparable à une signature, doit être connu à l'avance par le nœud routeur R3. Il est communiqué dans une signalisation en provenance d'un dispositif du réseau client N3 à destination d'une entité du réseau de transport N2. Selon l'invention, plusieurs méthodes alternatives permettent au nœud routeur R3 d'obtenir les informations nécessaires, dont le paramètre de protection. Le nœud routeur R3 doit pouvoir identifier le nœud client et les flux à protéger. Pour ce faire, la signalisation comprend soit l'adresse de destination des flux, qui correspond à l'adresse IP du nœud client C3, soit une autre information permettant d'identifier le nœud client C3, tel qu'un numéro de port ou d'interface, un nom de domaine (DNS), un certificat cryptographique, etc. Utiliser une adresse IPv6 est particulièrement avantageux car cette adresse est codée sur un nombre de bits suffisamment grand pour aussi y inclure le paramètre de protection. Si la signalisation est émise directement par le nœud client C3, une autre façon pour le nœud routeur R3 d'identifier le nœud client C3 est au travers de l'identifiant de l'émetteur de la signalisation, comme par exemple l'adresse IP d'origine d'un paquet de la signalisation ou l’interface d’arrivée de la signalisation. Plusieurs protocoles de signalisation vers le nœud routeur R3 peuvent être utilisés : Un protocole de signalisation de flux comme BGP FlowSpec (RFC5575 et sa révision draft-ietf-idr-rfc5575bis « Dissemination of Flow Specification Rules ») et ses extensions; Un protocole de configuration tel que NETCONF (RFC 6241 « Network Configuration Protocol (NETCONF) », RESTCONF (RFC 8040 « RESTCONF Protocol », CLI (Command Line Interface) ou SNMP; Une interface propriétaire de type API (Application Programmation Interface). La source de la signalisation peut être : Le nœud client C1 ou le nœud client C3 ; Un contrôleur de communication des flux clients (par exemple un contrôleur SD-WAN), dans le réseau N3. La signalisation peut transiter par un contrôleur de routeurs du réseau opérateur N2, dans les cas où par exemple les routeurs du réseau N2 ne sont pas aptes à recevoir directement du réseau N3 des messages de signalisation. Ce contrôleur agit alors comme équipement intermédiaire qui adapte le protocole ou le format du message de signalisation avant de le réémettre vers un routeur. Dans un mode de réalisation, le nœud client C1 envoie son flux avec le paramètre de protection de son choix (ou du choix du nœud client C3). Le nœud routeur R1 surveille les entêtes de nouveaux flux provenant du nœud client C1. Le nœud routeur R1 découvre le paramètre de protection et le signale au noud routeur R3, directement ou indirectement via un contrôleur de routeurs du réseau opérateur N2. Dans un mode de réalisation, après avoir reçu le paramètre de protection, le nœud routeur R3 le communique aux nœuds routeurs qui lui sont immédiatement voisins, c’est-à-dire les nœuds routeurs R2 et R4. En effet tous les flux destinés au nœud client C3 passent obligatoirement par un des nœuds routeurs immédiatement en amont du nœud routeur R3. Ainsi, la charge de traiter selon l'invention (priorisation, ou priorisation avec filtrage) les flux destinés au nœud client C3 est répartie sur plusieurs nœuds routeurs plutôt que sur un seul. Dans un mode de réalisation, la communication du paramètre de protection vers un nœud routeur amont peut être déclenchée par un nœud routeur aval lorsque le volume de flux reçus par ce routeur atteint un seuil mettant en danger le nœud aval ou le lien entre le nœud routeur amont et le nœud routeur aval. Ainsi, le nœud routeur R3 se protège en déléguant la charge des traitements (priorisation, ou priorisation avec filtrage) au nœud routeur R4, ce qui se trouve utile car c'est par ce nœud que transite le flux F2. Dans un mode de réalisation, le nœud routeur R4 peut lui aussi communiquer le code de protection vers un nœud routeur amont (non illustré dans la ), de façon récursive. Le seuil de déclenchement de cette communication peut être fonction des capacités du nœud routeur R4 et être différent de celui du nœud routeur R3. On comprend qu'il est ainsi possible de remonter la charge de filtrer le flux F2 jusqu'au premier nœud routeur emprunté par le flux F2 dans le réseau N2. L'identification et la localisation de la source A1 peut ainsi être facilitée et l’ensemble du réseau N2 est alors dispensé de transporter le flux F2 qui non seulement est de volume important, mais est destiné à être détruit. En plus d'être communiqué au réseau de transport N2, le paramètre de protection est également inséré dans un ou plusieurs champs des paquets du F1 avant leur émission par le nœud client C1. Dans le cas le plus simple, le paramètre de protection est inséré dans un seul champ d'un paquet, mais dans une variante de réalisation il peut être constitué de plusieurs parties qui sont réparties dans plusieurs champs d'un paquet. Dans un mode de réalisation, le paramètre de protection est inclus dans l'adresse IPv6 de destination des paquets du flux F1, par exemple dans les 64 dernier bits de l'adresse IPv6. Dans un mode de réalisation, le flux F1 est un tunnel IPsec et le paramètre de protection est compris dans le champ SPI (Security Parameters Index). L'avantage du champ SPI est qu'il est un champ spécifique aux tunnels IPsec, et que sa valeur peut être modifiée au besoin sans impacter le routage du flux. Dans un mode de réalisation, le flux F1 est un tunnel IPsec et le paramètre de protection est réparti sur plusieurs champs, dont fait partie le champ SPI de préférence. Les autres champs utilisables sont : le champ Protocol (ou le champ Next Header dans le cas IPv6), le champ adresse IP source, le champ adresse IP destination, le champ port source, le champ port destination. Aussi utilisables sont certains champs de SRv6 (Segment Routing IPv6, RFC 8754), tels que par exemple Segment List, Segment List [n], Tag, HMAC TLV. Dans un mode de réalisation où le flux n'est pas un tunnel IPsec, le champ SPI ne peut pas être utilisé mais les autres champs qui viennent d'être mentionnés sont utilisables. Le champ Key de GRE (Generic Routing Encapsulation) est aussi utilisable. D'autres champs spécifiques aux paquets IPv6 peuvent aussi être utilisés, tels que Routing Header, Destination option, ou Authentication Header. Par sécurité et particulièrement en IPv4, il peut être préférable de répartir le paramètre de protection sur plusieurs champs dont au moins le champ Protocol, car les autres champs (adresses IP et ports) sont plus facilement découvrables par un attaquant. En relation avec la , on présente maintenant un exemple de structure d'un dispositif de protection d'un flux de paquets, selon un aspect de l'invention. Le dispositif 100 de protection met en œuvre le procédé de protection d'un flux de paquets, dont différents modes de réalisation viennent d'être décrits. Un tel dispositif 100 peut être mis en œuvre dans un nœud émetteur ou récepteur du flux, ou dans un contrôleur de communication des flux clients (par exemple un contrôleur SD-WAN). Par exemple, le dispositif 100 comprend un récepteur 101, un émetteur 102, une unité de traitement 130, équipée par exemple d'un microprocesseur µP, et pilotée par un programme d'ordinateur 110, stocké dans une mémoire 120 et mettant en œuvre le procédé de protection selon l'invention. A l’initialisation, les instructions de code du programme d’ordinateur 110 sont par exemple chargées dans une mémoire RAM, avant d’être exécutées par le processeur de l’unité de traitement 130. Une telle mémoire 120, un tel processeur de l’unité de traitement 130, un tel récepteur 101 et un tel émetteur 102 sont aptes à, et configurés pour : l'émission d'un message comprenant la valeur attendue du paramètre de protection, à destination du nœud routeur connecté au nœud récepteur ou destinataire du flux. Avantageusement, ils sont également aptes à, et configurés pour : la réémission d'un nouveau message avec une nouvelle valeur du paramètre de protection, après expiration d'une période définie. En relation avec la , on présente maintenant un exemple de structure d'un dispositif de priorisation d'un flux de paquets, selon un aspect de l'invention. Le dispositif 200 de priorisation met en œuvre le procédé de filtrage d'un flux de paquets, dont différents modes de réalisation viennent d'être décrits. Un tel dispositif 200 peut être mis en œuvre dans un nœud routeur de flux de paquets, par exemple le nœud routeur connecté à un nœud client destinataire des flux. Par exemple, le dispositif 200 comprend un récepteur 201, un émetteur 202, une unité de traitement 230, équipée par exemple d'un microprocesseur µP, et pilotée par un programme d'ordinateur 210, stocké dans une mémoire 220 et mettant en œuvre le procédé de priorisation d'un flux de paquets selon l'invention. A l’initialisation, les instructions de code du programme d’ordinateur 210 sont par exemple chargées dans une mémoire RAM, avant d’être exécutées par le processeur de l’unité de traitement 230. Une telle mémoire 220, un tel processeur de l’unité de traitement 230, un tel récepteur 201 et un tel émetteur 202 sont aptes à, et configurés pour : la réception d'un message comprenant la valeur attendue du paramètre de protection, en provenance d'un dispositif associé au nœud récepteur, la priorisation des paquets comprenant la valeur attendue du paramètre de protection. Avantageusement, ils sont également aptes à, et configurés pour : le filtrage des paquets ne comprenant pas la valeur attendue du paramètre de protection, l'émission du message comprenant la valeur attendue du paramètre de protection, vers un nœud routeur voisin. Les entités décrites et comprises dans les dispositifs décrits en relation avec les figures 2 et 3 peuvent être matérielles ou logicielles. Les figures 2 et 3 illustrent seulement une manière particulière, parmi plusieurs possibles, de réaliser l’algorithme détaillé ci-dessus, en relation avec la . En effet, la technique de l’invention se réalise 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ù l’invention est implantée sur 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 clé USB, 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. Procédé de priorisation d’un flux (F1) de paquets dans un réseau composé de nœuds routeurs (R1-R4) de paquets, et de nœuds (C1-C3) émetteur et récepteur du flux, le nœud récepteur (C3) étant connecté à un nœud routeur (R3) traitant le routage d'un paquet à destination du nœud récepteur en fonction d'une valeur attendue d'un paramètre de protection compris dans au moins un champ d'un paquet du flux, le procédé étant mis en œuvre par le nœud routeur (R3) connecté au nœud récepteur (C3) et comprenant : la réception d'un message comprenant la valeur attendue du paramètre de protection, en provenance d'un dispositif associé au nœud récepteur (C3), la priorisation des paquets comprenant la valeur attendue du paramètre de protection. Procédé de priorisation selon la revendication précédente, où la priorisation comprend une mise des paquets dans une file d'attente ayant accès à une ou plusieurs interfaces de sortie du nœud routeur (R3), l'accès étant prioritaire sur au moins une autre file d'attente. Procédé de priorisation selon les revendications précédentes, comprenant en outre le filtrage des paquets ne comprenant pas la valeur attendue du paramètre de protection. Procédé de priorisation selon la revendication précédente, où le filtrage comprend un blocage des paquets, ou une destruction des paquets, ou un abaissement de la priorité des paquets. Procédé de priorisation selon l'une des revendications précédentes, comprenant en outre l'émission du message comprenant la valeur attendue du paramètre de protection, vers un nœud routeur voisin (R2, R4) du nœud routeur (R3) connecté au nœud récepteur (C3). Procédé selon l'une des revendications précédentes, où le paramètre de protection est inclus dans l'adresse IPv6 de destination des paquets du flux (F1). Procédé selon l'une des revendications précédentes, où le flux (F1) est un tunnel IPsec ou un tunnel IP. Procédé selon l'une des revendications précédentes, où l'au moins un champ comprenant le paramètre de protection est un ou plusieurs des champs d'une liste comprenant: "Security Parameters Index" (SPI) de IPsec, "Protocol" de IPv4, "Next Header" de IPv6, "Flow Label" de IPv6, adresse IP source, ou adresse IP destination, ou port source, ou port destination, de IPv4 ou IPv6. "Key" de GRE, Segment List, ou Segment List [n], ou Tag, ou HMAC TLV de Segment Routing IPv6 (SRv6). Procédé selon l'une des revendications précédentes, où le message comprenant la valeur attendue du paramètre de protection est un message d'un des protocoles suivants: BGP Flow Spec, NETCONF, RESTCONF, En ligne de commande (CLI: Command Line Interface), SNMP, API REST, API. Dispositif (200) de priorisation d’un flux (F1) de paquets dans un réseau (N1) composé de nœuds (R1-R4) routeurs de paquets, et de nœuds (C1-C3) émetteur et récepteur du flux, le nœud récepteur (C3) étant connecté à un nœud routeur (R3) traitant le routage d'un paquet à destination du nœud récepteur en fonction d'une valeur attendue d'un paramètre de protection compris dans au moins un champ d'un paquet du flux, le dispositif étant mis en œuvre dans le nœud routeur (R3) connecté au nœud récepteur (C3) et comprenant un récepteur (201), un émetteur (202), un processeur (230) et une mémoire (220) couplée au processeur avec des instructions destinées à être exécutées par le processeur pour : la réception d'un message comprenant la valeur attendue du paramètre de protection, en provenance d'un dispositif (100) associé au nœud récepteur (C3), la priorisation des paquets comprenant la valeur attendue du paramètre de protection. Programme d'ordinateur (210) , comprenant des instructions qui, lorsque ces instructions sont exécutées par un processeur, conduisent celui-ci à mettre en œuvre les étapes du procédé de priorisation selon la revendication 1. Support d'informations lisible par un dispositif de priorisation (200), et comportant des instructions d'un programme d'ordinateur (210) conforme à la revendication 11.