FR2867004A1 - Procede, systeme et dispositif de temporisation d'un flux de paquets de donnees - Google Patents

Procede, systeme et dispositif de temporisation d'un flux de paquets de donnees Download PDF

Info

Publication number
FR2867004A1
FR2867004A1 FR0450404A FR0450404A FR2867004A1 FR 2867004 A1 FR2867004 A1 FR 2867004A1 FR 0450404 A FR0450404 A FR 0450404A FR 0450404 A FR0450404 A FR 0450404A FR 2867004 A1 FR2867004 A1 FR 2867004A1
Authority
FR
France
Prior art keywords
data
module
software
receiver
transmitter
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.)
Granted
Application number
FR0450404A
Other languages
English (en)
Other versions
FR2867004B1 (fr
Inventor
Cecile Bucari
Rodolphe Hugel
Olivier Schott
Nicolas Stehle
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Everbee Networks SA
Original Assignee
Everbee Networks SA
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Everbee Networks SA filed Critical Everbee Networks SA
Priority to FR0450404A priority Critical patent/FR2867004B1/fr
Priority to PCT/FR2005/050137 priority patent/WO2005086455A2/fr
Priority to EP05739712A priority patent/EP1723772A2/fr
Publication of FR2867004A1 publication Critical patent/FR2867004A1/fr
Application granted granted Critical
Publication of FR2867004B1 publication Critical patent/FR2867004B1/fr
Anticipated expiration legal-status Critical
Expired - Fee Related legal-status Critical Current

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/02—Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
    • H04L63/0227—Filtering policies
    • H04L63/0236—Filtering by address, protocol, port number or service, e.g. IP-address or URL
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/14—Session management
    • H04L67/142—Managing session states for stateless protocols; Signalling session states; State transitions; Keeping-state mechanisms
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/56—Provisioning of proxy services
    • H04L67/564—Enhancement of application control based on intercepted application data
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/56—Provisioning of proxy services
    • H04L67/568—Storing data temporarily at an intermediate stage, e.g. caching
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/60—Scheduling or organising the servicing of application requests, e.g. requests for application data transmissions using the analysis and optimisation of the required network resources
    • H04L67/62—Establishing a time schedule for servicing the requests
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
    • H04L69/322—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
    • H04L69/329—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the application layer [OSI layer 7]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/2866—Architectures; Arrangements
    • H04L67/2871—Implementation details of single intermediate entities
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/56—Provisioning of proxy services
    • H04L67/565—Conversion or adaptation of application format or content

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

La présente invention concerne un procédé et un système s'appliquant à un dispositif placé en coupure dans un réseau informatique, traversé par un flux de paquets de données et ayant pour objectif l'analyse et/ou la modification sélective et/ou le filtrage sélectif du flux de paquets de données.Le présente invention permet au dispositif de réaliser ces objectifs en minimisant les ressources informatiques nécessaires, mémoire et/ou puissance de calcul, tout en améliorant les performances du dispositif.Le présente invention consiste à retenir temporairement dans le dispositif tout ou partie des données, notamment des données des couches applicatives, du flux de paquets de données, de façon transparente pour l'émetteur et le récepteur du flux de paquets de données, indépendamment des données temporisées et en adaptant dynamiquement la taille des données temporisées aux objectifs.

Description

PROCEDE, SYSTEME ET DISPOSITIF DE TEMPORISATION D'UN FLUX DE
PAQUETS DE DONNEES
Préambule de la description
Domaine concerné La présente invention concerne un procédé et un système s'appliquant à un dispositif placé en coupure dans un réseau informatique, traversé par un flux de paquets de données et ayant pour objectif l'analyse et/ou la modification sélective et/ou le filtrage sélectif du flux de paquets de données.
Le procédé permet au dispositif de réaliser ces objectifs en minimisant les ressources informatiques nécessaires, mémoire et/ou puissance de calcul, tout en améliorant les performances du dispositif.
Les règles (protocole) de circulation des données sur le réseau Internet sont connues sous le nom de Protocole Internet (IP pour Internet Protocol, cf. RFC 791). Ce protocole est basé sur le modèle standard OSI (cf. ISO/IEC 7498-1:1994).
Le modèle OSI structure les données transitant sur le réseau en 7 couches: La couche 7, ou couche application, permet l'interface avec les applications.
La couche 6, ou couche présentation, définit le format des données.
La couche 5, ou couche session, définit l'ouverture des sessions sur les machines du réseau.
La couche 4, ou couche transport, permet de contrôler le transport des données et de gérer les erreurs. Le protocole TCP (cf. Transmission Control Protocol RFC 793) est l'implémentation de la couche transport la plus courante.
La couche 3, ou couche réseau, définit l'acheminement (routage) des données.
La couche 2, ou couche liaison de données, définit 10 l'interface avec la carte réseau.
La couche 1, ou couche physique, définit la façon dont les données sont converties en signaux numériques.
Nous utiliserons le terme de couches applicatives pour désigner les couches 5 à 7 du modèle OSI. Ces couches applicatives contiennent l'ensemble des informations nécessaires aux applications communiquant sur le réseau pour fonctionner et se comprendre.
Nous réserverons le terme de couches basses pour désigner les couches 1 à 4 du modèle OSI.
Les utilisateurs portent aujourd'hui un intérêt manifeste pour la sécurité des réseaux informatiques et demandent des moyens de lutte encore plus efficaces, entre autres contre les intrusions, contre les virus, contre les courriels non sollicités envoyés en masse, appelés usuellement "spam" et contre les fenêtres de publicité s'ouvrant automatiquement au- dessus des pages Web, appelées usuellement "popups" Les attentes des utilisateurs sont multiples. ils souhaitent que tous ces services de sécurité soient combinés dans une solution tout-en-un, facile à déployer et transparente, c'est-à-dire une solution n'impliquant aucune installation sur la (ou les) machine(s) protégée(s) et ne nécessitant pas de re- configuration des applications déjà installées. Par ailleurs, ils ne souhaitent pas qu'une part significative des ressources de la (ou des) machine(s) protégée(s) soient utilisée par ces services de sécurité. Enfin, les utilisateurs "nomades", en nombre croissant, demandent une sécurité personnelle qu'ils peuvent transporter avec eux dans leurs déplacements.
Pour répondre à ces multiples attentes, les services de sécurité tendent de plus en plus à être réalisés sur des systèmes embarqués placés en coupure sur le réseau, c'est-à-dire placés dans une position telle que tout le flux de communication émis par et à destination de la (ou des) machine (s) protégée (s) traverse le système. Ces systèmes apparaissent le plus souvent comme des "boîtes noires", expression que nous utiliserons par la suite.
Ces "boîtes noires" de sécurité cherchent à intégrer tous les services de sécurité dans un dispositif unique afin d'offrir une solution tout-en-un. Elles doivent de plus être petites, pour être aisément transportables, et réalisées à un coût raisonnable de façon à être abordables par tous les utilisateurs potentiels du réseau.
Mais ces "boîtes noires" sont aujourd'hui confrontées aux limites des systèmes embarqués: les nouveaux services de sécurité demandés par les utilisateurs exigent une inspection temps réel de plus en plus en profonde du flux réseau. Ils nécessitent des ressources informatiques de plus en plus importantes, tant au niveau de la puissance de calcul que de la capacité mémoire: En effet, un nombre toujours croissant de services de sécurité doit être réalisé simultanément. Par ailleurs, ces nouveaux services de sécurité sont de plus en plus orientés application: ils nécessitent une analyse approfondie des flux réseaux allant jusqu'aux couches applicatives (par opposition aux services de type pare-feu se limitant à l'étude des couches transport et réseaux), et requièrent donc des traitements exhaustifs et coûteux.
Or pour un système embarqué, les ressources informatiques sont limitées par les contraintes de coût et 35 d'encombrement. Les services offerts restent donc souvent limités et ne parviennent pas à répondre au niveau croissant d'exigence des utilisateurs, d'autant plus que ces limitations sont accentuées par la position des "boîtes noires" en coupure sur le réseau.
Problème posé Pour circuler sur le réseau Internet, un message doit suivre les règles de circulation de données du protocole IP décrit précédemment: pour pouvoir être transmis à travers le réseau, un message est divisé par la machine émettrice en nombreux petits paquets comme les pièces d'un puzzle. Chaque paquet se voit ajouter un en-tête, une sorte d'enveloppe contenant l'ensemble des informations garantissant sa transmission: chaque paquet est, entre autres, numéroté et contient les adresses réseau des machines émettrices et réceptrices, appelées adresses IP. Ces paquets circulent sur le réseau séparément les uns des autres puis arrivent sur la machine réceptrice dans un ordre qui peut être différent de leur ordre initial, on parle de déséquencement. Ces paquets sont enfin rassemblés par la machine réceptrice qui lit puis supprime les en-têtes et reconstitue alors le message initial en réordonnant les paquets.
Il en découle que les "boîtes noires" de sécurité voient passer les messages, en temps réel, sous forme de flux de paquets de données. Or, pour réaliser des services de sécurité sur ces flux, elles doivent analyser les messages, les modifier et/ou en supprimer certaines parties.
On mesure alors toute la difficulté de réaliser un service sur un message lorsque l'on est trop limité en place mémoire pour stocker le message dans son intégralité et que l'on doit travailler à la volée sur des morceaux de ce message, des paquets qui, difficulté supplémentaire, peuvent être déséquencés.
Le problème à résoudre est donc de pouvoir offrir aux systèmes réalisant des services sur le réseau, un moyen leur permettant de réaliser ces services, tout en gardant la contrainte de limitation des ressources informatiques et sans perdre les avantages des "boîtes noires" cités plus haut.
Art antérieur Les solutions adoptées aujourd'hui dans les systèmes embarqués pour réaliser des services du type de ceux cités plus haut, implémentent une technologie dite inspection de session ou "stateful inspection" : une table tient à jour la liste des flux qui ont été autorisés à traverser la "boîte noire" et ces flux autorisés peuvent être modifiés afin de réaliser les services.
Lorsque l'analyse du flux est réalisée jusqu'aux couches applicatives (couche 5 à 7 du modèle OSI), la technologie est alors dite inspection de contenu ou "content inspection".
Cependant, parmi les solutions actuelles implémentant une inspection de contenu, rares sont celles qui sont capables de modifier le flux. La plupart ne peuvent qu'interdire un flux lorsque l'analyse révèle une menace pour la sécurité du réseau.
En outre, soumise aux contraintes dues à leur position en coupure sur le réseau, ces "boîtes noires" ne peuvent réaliser qu'un traitement paquet par paquet: elles décident à chaque paquet des modifications à faire sur le flux de paquet, puis décident de transmettre (ou non) le paquet. Les paquets sont donc traités séparément les uns des autres. Les modifications apportées à un paquet ne peuvent donc prendre en compte le contenu des paquets précédents ou suivants.
Au mieux, une sorte d'historique du flux est réalisé en prenant une "photo" de chaque paquet à son arrivée et en mettant ces photos bout à bout pour reconstituer une fenêtre du flux. La "boîte noire" peut dans ce cas consulter l'historique du flux lorsqu'elle reçoit un paquet. Mais sa décision de modifier et/ou de transmettre un paquet reste prise paquet par paquet et ne prend toujours pas en compte le contenu des paquets suivants.
L'invention, objet du présent brevet, permet de résoudre les problèmes évoqués précédemment sans présenter les inconvénients de l'art antérieur. Elle pallie aux problèmes et aux limitations des technologies existantes en proposant une solution inventive.
Solution Procédé L'invention concerne un procédé s'appliquant à un dispositif placé en coupure dans un réseau informatique et traversé par un flux de paquets de données. Le dispositif a pour objectif l'analyse et/ou la modification sélective et/ou le filtrage sélectif du flux de paquets de données. Le procédé permet au dispositif de réaliser ces objectifs en minimisant les ressources informatiques nécessaires, mémoire et/ou puissance de calcul, tout en améliorant les performances du dispositif. Le procédé comprend une étape de temporisation. La temporisation consiste à retenir temporairement dans le dispositif tout ou partie des données, notamment des données des couches applicatives, du flux de paquets de données, de façon transparente pour l'émetteur et le récepteur du flux de paquets de données, indépendamment des données temporisées et en adaptant dynamiquement la taille des données temporisées aux objectifs.
De préférence, selon l'invention le dispositif comprend un logiciel, un premier module, un deuxième module et au moins une mémoire dont une partie de taille variable, ci-après appelée fenêtre de temporisation, est destinée à la temporisation.
De préférence, selon l'invention la temporisation logiciel de fixer la et d'initialiser le la temporisation comprend une sous-étape pour le premier module de recevoir tout 35 ou partie des paquets du flux.
comprend une sous-étape initiale pour le taille de la fenêtre de temporisation premier module et le deuxième module.
De préférence, selon l'invention De préférence, selon l'invention la temporisation comprend une sous-étape pour le premier module de se substituer au récepteur auprès de l'émetteur pour toutes les opérations d'échange d'information avec l'émetteur que le récepteur aurait effectuées s'il avait procédé lui-même à la réception, de sorte que la temporisation est transparente pour l'émetteur.
De préférence, selon l'invention la temporisation comprend une sous-étape pour le premier module de placer dans la fenêtre de temporisation, tout ou parties des données, notamment applicatives, du paquet reçu par le premier module.
De préférence, selon l'invention la temporisation comprend une sous-étape pour le logiciel d'être informé que de nouvelles données sont disponibles dans la fenêtre de temporisation.
De préférence, selon l'invention la temporisation comprend une sous-étape pour le logiciel d'analyser et/ou de modifier sélectivement et/ou de filtrer sélectivement les données contenues dans la fenêtre de temporisation.
De préférence, selon l'invention la temporisation comprend une sous-étape pour le logiciel d'informer le deuxième module que des données de la fenêtre de temporisation sont à émettre.
De préférence, selon l'invention la temporisation comprend une sous-étape pour le deuxième module d'émettre les 25 données à émettre vers le récepteur.
De préférence, selon l'invention, le procédé comprend en outre une sousétape, pour le deuxième module, de se substituer à l'émetteur auprès du récepteur pour toutes les opérations d'échange d'information avec le récepteur que l'émetteur aurait effectuées s'il avait procédé lui-même à l'émission de données, de sorte que la temporisation est transparente pour le récepteur.
De préférence, selon l'invention, la temporisation comprend une sousétape pour le deuxième module d'informer le 35 premier module et/ou le logiciel que les données ont été émises.
De préférence, selon l'invention, la temporisation comprend une sousétape pour le logiciel de modifier la taille de la fenêtre de temporisation.
Système L'invention concerne un système qui comprend un dispositif placé en coupure dans un réseau informatique et traversé par un flux de paquets de données. Le dispositif a pour objectif l'analyse et/ou la modification sélective et/ou le filtrage sélectif du flux de paquets de données. Le dispositif réalise ces objectifs en minimisant les ressources informatiques nécessaires, mémoire et/ou puissance de calcul, tout en améliorant les performances du dispositif. Le dispositif comprend des moyens de temporisation. Les moyens de temporisation retiennent temporairement dans le dispositif tout ou partie des données, notamment des données de la couche applicative, du flux de paquets de données, de façon transparente pour l'émetteur et le récepteur du flux de paquets de données, indépendamment des données temporisées et en adaptant dynamiquement la taille des données temporisées aux objectifs.
De préférence, selon l'invention, le dispositif comprend un logiciel, un premier module, un deuxième module et au moins une mémoire dont une partie de taille variable, ci-après appelée fenêtre de temporisation.
De préférence, selon l'invention le dispositif comprend des moyens d'initialisation permettant au logiciel de fixer la taille de la fenêtre de temporisation et d'initialiser le premier module et le deuxième module.
De préférence, selon l'invention, le dispositif 30 comprend des moyens de réception permettant au premier module de recevoir tout ou partie des paquets du flux.
De préférence, selon l'invention, le premier module se substitue au récepteur auprès de l'émetteur pour toutes les opérations d'échange d'information avec l'émetteur que le récepteur aurait effectuées s'il avait procédé lui-même à la réception, de sorte que la temporisation est transparente pour l'émetteur.
De préférence, selon l'invention, le premier module place dans la fenêtre de temporisation, tout ou parties des données, notamment applicatives, du paquet reçu par le premier module.
De préférence, selon l'invention, le logiciel est informé que de nouvelles données sont disponibles dans la fenêtre de temporisation.
De préférence, selon l'invention, le logiciel est associé à des moyens de traitement informatique pour analyser et/ou modifier sélectivement et/ou filtrer sélectivement les données contenues dans la fenêtre de temporisation.
De préférence, selon l'invention, le logiciel informe 15 le deuxième module que des données de la fenêtre de temporisation sont à émettre.
De préférence, selon l'invention, le deuxième module comprend des moyens d'émission des données à émettre vers le récepteur.
De préférence, selon l'invention, le deuxième module se substitue à l'émetteur auprès du récepteur pour toutes les opérations d'échange d'information avec le récepteur que l'émetteur aurait effectuées s'il avait procédé lui-même à l'émission de données, de sorte que la temporisation est transparente pour le récepteur.
De préférence, selon l'invention, le deuxième module informe le premier module et/ou le logiciel que les données ont été émises.
De préférence, selon l'invention, le logiciel est 30 associé à des moyens de modification de la taille de la fenêtre de temporisation.
Description détaillée
D'autres caractéristiques et avantages de l'invention apparaîtront à la lecture de la description de variantes de réalisation de l'invention données à titre d'exemple indicatif et non limitatif, et de la - figure 1 qui représente le schéma général de l'interconnexion du système agissant dans l'invention avec un 5 réseau informatique.
Le système objet de la présente invention, s'applique à un dispositif D placé en coupure sur un réseau informatique R quelconque: il peut s'agir d'Internet, d'un réseau Intranet, d'un réseau domestique ou bien de seulement deux postes reliés entre eux. On entend par coupure la séparation physique du réseau R en deux sous réseaux reliés entre eux à l'aide du dispositif D. Ainsi tout le flux de paquets de données transitant d'un sous réseau à destination de l'autre sous réseau doit traverser le dispositif D. Le dispositif D a pour but la réalisation, à la volée, de services de sécurité sur le flux de paquets de données FPD qui le traverse. Nous utiliserons les termes émetteur A et récepteur B pour désigner l'émetteur du flux de paquets de données FPD et le récepteur du flux de paquets de données FPD.
Les services sont réalisés par un logiciel L. Dans une réalisation particulière de l'invention, le logiciel L utilise des blocs "hardware" spécialisés pour réaliser tout ou partie des services.
Le dispositif D possède une mémoire ME partagée par le 25 logiciel L et par d'autres traitements informatiques réalisés par le dispositif D. Prenons l'exemple illustratif et non limitatif d'un service "anti-spam" réalisé sur les flux de réception de courriers électroniques.
Ce service "anti-spam" consiste à analyser uniquement le champ objet des courriers électroniques et, lorsqu'un courrier non sollicité est identifié, à ajouter la balise "[SPAM]" au début de l'objet du mail afin d'informer l'utilisateur. Le courrier peut alors être automatiquement dirigé dans une boîte aux lettres spéciale.
Les réceptions de courriers électroniques sont réalisées sur des flux suivant les protocoles TCP/IP, c'est-à-dire des flux séquencés comprenant un système d'acquittement ("acknoledgement"). Le système d'acquittement est un des services de fiabilité offerts par TCP. un acquittement est généré et envoyé par le récepteur d'un message à son émetteur pour signaler à ce dernier qu'il a bien reçu une partie des données du message. La partie des données bien reçues est désignée dans l'acquittement, ce sont les données acquittées.
Prenons le cas où le champ objet du mail est découpé sur deux paquets, le premier contenant les données applicatives "Pu" et le suivant contenant les données applicatives "blicité".
A la réception du premier paquet contenant "Pu", le logiciel L identifie au cours de son analyse (de type inspection de contenu) la présence du champ objet. L'analyse montre aussi que cet objet n'est pas complet. Le logiciel L décide donc d'initier une temporisation du flux de paquets de données FPD.
Le logiciel L alloue alors la fenêtre de temporisation FT au sein de la mémoire ME. Il fixe la taille de la fenêtre de temporisation FT à 50 caractères car c'est la taille moyenne d'un objet de courrier électronique. Le logiciel L place enfin les données des couches applicatives du paquet courant, c'est-à-dire "Pu", dans la fenêtre de temporisation FT. Le logiciel L initialise de plus un premier module M1 et un second module M2 avec les données des couches basses du paquet courant. Conformément au protocoles TCP/IP, ces données contiennent entre autres les adresses IP du récepteur B et de l'émetteur A mais aussi le numéro de séquencement (Si) et le numéro d'acquittement (Al) du paquet courant.
Le premier module M1 génère alors un acquittement pour les données du paquet temporisé "Pu" et l'envoie à l'émetteur A il est capable de générer cet acquittement puisque, à son initialisation, il a reçu (Sl) et (Al). Il calcule donc pour cet acquittement, un numéro de séquencement valant (Al) et un numéro d'acquittement valant: (Si) + la longueur des données "Pu". En outre, le premier module M1 utilise comme adresse IP d'émetteur du paquet d'acquittement, l'adresse IP du récepteur B de sorte que pour l'émetteur A c'est le récepteur B qui semblera avoir envoyé l'acquittement: la temporisation du paquet "Pu" sera transparente pour l'émetteur A. La temporisation est alors initialisée.
Lorsque le second paquet contenant la fin de l'objet "blicité" arrive dans le dispositif D, c'est le premier module 10 M1 qui le reçoit.
Il génère alors un acquittement pour les données de ce second paquet et l'envoie à l'émetteur A: là encore le module M1 est capable de générer cet acquittement puisqu'il est consécutif à celui généré pendant la phase d'initialisation. Il calcule donc pour cet acquittement, un numéro de séquencement valant à nouveau (Al) et un numéro d'acquittement valant: (Si) + la longueur des données "Publicité". Cette fois encore, le premier module M1 utilise comme adresse IP d'émetteur du paquet d'acquittement, l'adresse IP du récepteur B de sorte que pour l'émetteur A c'est le récepteur B qui semblera avoir envoyé l'acquittement. La temporisation du paquet "blicité" sera transparente pour l'émetteur A. Les données applicatives reçues (c'est-à-dire "blicité") étant consécutives à celles présentes dans la fenêtre de temporisation FT (c'est-à-dire "Pu"), et, la taille de ces données étant inférieure à la taille disponible dans la fenêtre de temporisation FT, le premier module M1 place "blicité" dans la fenêtre, reconstituant ainsi l'objet "Publicité".
Il signale enfin au logiciel L que la fenêtre de 30 temporisation FT contient de nouvelles données.
Celui-ci peut alors reprendre son analyse sur le champ objet "Publicité" entier et identifier le courrier non sollicité. Il modifie alors l'objet "Publicité" en "[SPAM] Publicité". Le traitement de cet objet étant terminé, il signale au second module M2 que toutes les données de la fenêtre de temporisation FT peuvent être émises.
Le second module M2 émet alors les données modifiées "[SPAM] Publicité" vers le récepteur B, les supprime de la fenêtre de temporisation FT et signale à L et au premier module M1 que les données ont été supprimées de la fenêtre de temporisation FT.
Il est capable de générer vers le récepteur B un flux cohérent puisque les numéros de séquencement et d'acquittement à utiliser sont ceux du paquet "Pu" qu'il a reçus à son initialisation: (Sl) et (A1).
L'ajout de la balise "[SPAM]" dans les données engendre donc un décalage du séquencement global du flux FPD égal à la taille des données ajoutées: en effet, à l'entrée du dispositif D "Publicité" avait un séquencement (S1). A la sortie du dispositif D, la chaîne "Publicité" a un séquencement égal à : (Si) + la taille de la balise "[SPAM] ".
Par ailleurs, la suite de protocoles TCP/IP inclut un système de somme de contrôle (checksum) afin de garantir contre toute modification des données du paquet, c'est une sorte de signature des données du paquet insérée dans son en-tête (dans la couche OSI 4). Le second module M2 calcule donc la somme de contrôle correspondant aux données modifiées et l'insère dans le flux FPD généré.
En outre, le second module M2 utilise couine adresse IP d'émetteur du paquet d'acquittement, l'adresse IP de l'émetteur A de sorte que pour le récepteur B c'est l'émetteur A qui semblera avoir envoyé le flux FPD: la temporisation sera transparente pour le récepteur B. Lorsque L reçoit l'information que les données ont été émises, il signale aux modules M1 et M2 que la temporisation est terminée et désalloue la fenêtre de temporisation FT, libérant ainsi une partie de la mémoire ME.
Le reste du flux FPD venant de l'émetteur A sera cependant modifié par le second module M2 au niveau des données des couches basses. En effet, pour que le flux FPD reste cohérent, les numéros de séquencement et d'acquittement doivent continuer d'être décalés de la taille des données qui ont été ajoutées.
Cet exemple montre bien avec quelle facilité la présente invention permet au système de réaliser le service.
Cet exemple ne limite pas la présente invention à un placement de données des couches applicatives dans la fenêtre de temporisation FT. Les données placées dans la fenêtre de temporisation FT peuvent provenir de n'importe quelle couche OSI si cela est nécessaire.
Cet exemple ne limite pas les modules M1 et M2 de la présente invention aux traitements décrits dans l'exemple.
Les modules Ml et M2 peuvent prendre en charge n'importe quel traitement sur le flux FPD, notamment jusqu'au niveau des couches applicatives. Par exemple, le premier module M1 peut avoir besoin de générer des données applicatives et de les envoyer à l'émetteur A, pour forcer l'application émettrice à continuer de lui envoyer le flux FPD.
Avantageusement, les modules M1 et M2 disposent chacun d'une mémoire tampon d'émission et d'une mémoire tampon de réception propres, ci-après appelées buffer d'émission et buffer de réception.
Ceci permet au premier module Ml de recevoir et d'acquitter des données de l'émetteur A alors même que la fenêtre de temporisation FT n'a pas d'espace disponible. Cela rend donc le placement de données dans la fenêtre de temporisation FT asynchrone avec la réception des paquets. En effet, le premier module Ml peut placer des données dès que de l'espace se libère dans la fenêtre, c'est-à-dire dès qu'il reçoit l'information du second module M2 que des données ont été libérées.
Lorsque le buffer de réception propre au premier module M1 est plein, les paquets envoyés par l'émetteur A ne sont plus acquittés. L'émetteur A devra donc, selon les règles du protocole TCP/IP, ré-émettre ces paquets.
Symétriquement, l'avantage pour le second module M2 est de rendre asynchrone la libération de données de la fenêtre de temporisation FT et l'émission de données vers le récepteur B. Dans l'exemple décrit précédemment, prenons le cas où le champ objet du courrier "Publicité" est, cette fois, découpé sur trois paquets reçus de manière déséquencée, c'est-à-dire le premier paquet reçu contenant "Pu", le second contenant "cité" et le dernier paquet reçu contenant "bli".
Les traitements sont identiques à ceux décrits 15 précédemment pour le premier paquet reçu.
Lorsque le second paquet contenant "cité" est reçu, le premier module M1 ne place pas les données "cité" dans la fenêtre de temporisation FT car elles ne sont pas séquencées avec les données "Pu" déjà présentes dans la fenêtre de temporisation FT.
Lorsque le troisième paquet, contenant "bli" est reçu, le premier module M1 place alors à la fois les données "bli" et les données "cité" dans la fenêtre de temporisation FT, reconstituant ainsi l'objet "Publicité".
La suite des traitements est identique à celle décrite précédemment.
Cet exemple montre bien avec quelle facilité la présente invention permet au système de réaliser le service même lorsque le flux de paquet de données FPD est déséquencé.
Avantageusement, lorsque le premier module M1 place des données dans la fenêtre de temporisation FT, il ne tient pas compte de la répartition en paquets que suivaient ces données lors de leur réception.
Prenons un exemple où L a fixé la taille de la fenêtre 35 de temporisation FT à 150 octets. Si le premier module Ml reçoit deux paquets de 100 octets de données applicatives, il place dans la fenêtre les données du premier paquet en entier et la moitié des données du second, remplissant ainsi lafenêtre de temporisation FT. Cela optimise donc la quantité de données placées dans la fenêtre, c'est-à-dire la quantité de données pouvant être analysée par le logiciel L. Avantageusement, les données des couches basses correspondant aux données applicatives temporisées sont conservées sous forme de liste chaînée par le système objet de la présente invention. Avantageusement, le logiciel L peut modifier cette liste chaînée. Cela permet ainsi au système de réaliser des services nécessitant une analyse et/ou des modifications des couches basses, notamment des services NAT-PT (cf. RFC 3022, Traditional IP Network Translator, P. Srisuresh, K. Egevans, January 2001 and RFC 2766, cf. Network Address Translation Protocol Translation (NAT-PT), G. Tsirtsis, P. Srisuresh, February 2000).
L'exemple décrit précédemment montre aussi que la présente invention permet au système d'adapter la quantité de 20 mémoire utilisée aux besoins du service à réaliser.
En effet, le logiciel L est capable de commencer la temporisation au milieu du flux de paquets de données FPD, optimisant ainsi les coûts de traitement et la quantité de mémoire utilisée sur le début du flux. De plus, le logiciel L est capable d'augmenter et/ou de réduire la taille de la fenêtre de temporisation FT à tout moment, optimisant ainsi la quantité de mémoire utilisée. Enfin le logiciel L est capable d'arrêter la temporisation avant la fin du flux en libérant totalement la fenêtre de temporisation FT, optimisant ainsi la quantité de mémoire utilisée sur la fin du flux FPD.
La temporisation n'est donc réalisée qu'au moment où elle est nécessaire et utilise une quantité de mémoire adaptée.
Avantageusement, dans le cas où le logiciel L arrête la temporisation au cours du flux FPD, le buffer de réception du second module M2 peut être libéré : le buffer d'émission du premier module Ml devient alors aussi buffer de réception pour le second module M2.
Avantageusement, dans le cas où le logiciel L arrête la temporisation sans avoir jamais modifié le flux FPD, il peut signaler au second module M2 qu'il n'y a pas de changement à appliquer sur les données des couches basses sur la suite du flux FPD, optimisant encore les coûts de traitement.
Avantageusement, les modules Ml et M2 sont réalisés tout ou partie en "hardware".
Avantageusement, le logiciel L a accès à des blocs "hardware" pour réaliser tout ou partie de l'analyse et/ou de la modification du flux de paquets de données FPD.
L'exemple décrit précédemment montre aussi que la présente invention permet au système de temporiser n'importe quel type de flux, indépendamment des données des couches applicatives, c'est-à-dire, indépendamment de l'application transitant sur le réseau R. Dans tous les exemples décrits précédemment, les modules Ml et M2 jouent des rôles symétriques pour le traitement du flux inverse au flux FPD: lorsque l'émetteur A devient récepteur et le récepteur B devient émetteur, une nouvelle fenêtre de temporisation FT est créée, le premier module M1 joue le rôle du second module M2 et inversement. Le logiciel L peut alors avantageusement lier les traitements sur les deux flux inverses l'un de l'autre.
Le système objet de la présente invention permet ainsi à un dispositif de réaliser des services sur un flux de paquets de données en minimisant les ressources informatiques nécessaires, mémoire et/ou puissance de calcul, tout en améliorant les performances du dispositif. Il est donc particulièrement adapté aux systèmes embarqués, soumis à des contraintes sur les ressources informatiques pour des raisons de coût et d'encombrement.

Claims (26)

REVENDICATIONS
1. Procédé s'appliquant à un dispositif (D) placé en coupure dans un réseau informatique (R) et traversé par un flux de paquets de données (FPD); ledit dispositif (D) ayant pour objectif l'analyse et/ou la modification sélective et/ou le filtrage sélectif dudit flux de paquets de données (FPD); ledit procédé permettant audit dispositif (D) de réaliser lesdits objectifs en minimisant les ressources informatiques nécessaires, mémoire et/ou puissance de calcul, tout en améliorant les performances dudit dispositif (D); ledit procédé comprenant une étape de temporisation; ladite temporisation consistant à retenir temporairement dans ledit dispositif (D) tout ou partie des données, notamment des données des couches applicatives, dudit flux de paquets de données (FPD), de façon transparente pour l'émetteur (A) et le récepteur (B) dudit flux de paquets de données (FPD), indépendamment desdites données temporisées et en adaptant dynamiquement la taille desdites données temporisées auxdits objectifs.
2. Procédé selon la revendication 1; ledit dispositif (D) comprenant un logiciel (L), un premier module (Ml), un deuxième module (M2) et au moins une mémoire (ME) dont une partie de taille variable, ci-après appelée fenêtre de temporisation (FT), est destinée à ladite temporisation.
3. Procédé selon la revendication 2; ladite temporisation comprenant la sous-étape initiale pour ledit logiciel (L) de fixer la taille de ladite fenêtre de temporisation (FT) et d'initialiser ledit premier module (Ml) et ledit deuxième module (M2).
4. Procédé selon l'une quelconque des revendications 2 30 ou 3; ladite temporisation comprenant la sous-étape pour ledit premier module (Ml) de recevoir tout ou partie des paquets dudit flux (FPD).
5. Procédé selon l'une quelconque des revendications 2 à 4, ladite temporisation comprenant la sous-étape pour ledit premier module (Ml) de se substituer audit recepteur (B) auprès dudit émetteur (A) pour toutes les opérations d'échange d'information avec ledit émetteur (A) que ledit récepteur (B) aurait effectuées s'il avait procédé lui-même à la réception, de sorte que ladite temporisation est transparente pour ledit émetteur (A).
6. Procédé selon l'une quelconque des revendications 2 à 5; ladite temporisation comprenant la sous-étape pour ledit premier module (Ml) de placer dans ladite fenêtre de temporisation (FT), tout ou parties des données, notamment applicatives, dudit paquet reçu par ledit premier module (Ml).
7. Procédé selon l'une quelconque des revendications 2 à 6; ladite temporisation comprenant la sous-étape pour ledit logiciel (L) d'être informé que de nouvelles données sont disponibles dans ladite fenêtre de temporisation (FT).
8. Procédé selon l'une quelconque des revendications 2 à 7; ladite temporisation comprenant la sous-étape pour ledit logiciel (L) d'analyser et/ou de modifier sélectivement et/ou de filtrer sélectivement les données contenues dans ladite fenêtre de temporisation (FT).
9. Procédé selon la revendication 8; ladite temporisation comprenant la sous-étape pour ledit logiciel (L) d'informer ledit deuxième module (M2) que des données de ladite fenêtre de temporisation (FT) sont à émettre.
10. Procédé selon la revendication 9; ladite temporisation comprenant la sous-étape pour ledit deuxième module (M2) d'émettre lesdites données à émettre vers ledit récepteur (B).
11. Procédé selon la revendication 10; caractérisé en ce que ledit deuxième module (M2) se substitue audit émetteur (A) auprès dudit récepteur (B) pour toutes les opérations d'échange d'information avec ledit récepteur (B) que ledit émetteur (A) aurait effectuées s'il avait procédé lui-même à ladite émission de données, de sorte que ladite temporisation est transparente pour ledit récepteur (B).
12. Procédé selon l'une quelconque des revendications 10 ou 11; ladite temporisation comprenant la sous-étape pour ledit deuxième module (M2) d'informer ledit premier module (Ml) et/ou ledit logiciel (L) que lesdites données ont été émises.
13. Procédé selon l'une quelconque des revendications 2 à 12; ladite temporisation comprenant la sous-étape pour ledit logiciel (L) de modifier la taille de la fenêtre de temporisation (FT).
14. Système comprenant un dispositif (D) placé en coupure dans un réseau informatique (R) et traversé par un flux de paquets de données (FPD); ledit dispositif (D) ayant pour objectif l'analyse et/ou la modification sélective et/ou le filtrage sélectif dudit flux de paquets de données (FPD); ledit dispositif (D) réalisant lesdits objectifs en minimisant les ressources informatiques nécessaires, mémoire et/ou puissance de calcul, tout en améliorant les performances dudit dispositif (D) ; ledit dispositif comprenant des moyens de temporisation; lesdits moyens de temporisation retenant temporairement dans ledit dispositif (D) tout ou partie des données, notamment des données de la couche applicative, dudit flux de paquets de données (FPD), de façon transparente pour l'émetteur (A) et le récepteur (B) dudit flux de paquets de données (FPD), indépendamment desdites données temporisées et en adaptant dynamiquement la taille desdites données temporisées auxdits objectifs.
15. Système selon la revendication 14; ledit dispositif (D) comprenant un logiciel (L), un premier module (Ml), un deuxième module (M2) et au moins une mémoire (ME) dont une partie de taille variable, ci-après appelée fenêtre de temporisation (FT).
16. Système selon la revendication 15; ledit dispositif (D) comprenant des moyens d'initialisation permettant audit logiciel (L) de fixer la taille de ladite fenêtre de temporisation (FT) et d'initialiser ledit premier module (Ml) et ledit deuxième module (M2).
17. Système selon l'une quelconque des revendications 15 ou 16; ledit dispositif (D) comprenant des moyens de réception permettant audit premier module (Ml) de recevoir tout ou partie des paquets dudit flux (FPD).
18. Système selon l'une quelconque des revendications 15 à 17, ledit premier module (Ml) se substituant audit recepteur (B) auprès dudit émetteur (A) pour toutes les opérations d'échange d'information avec ledit émetteur A que ledit récepteur (B) aurait effectuées s'il avait procédé lui-même à la réception, de sorte que ladite temporisation est transparente pour ledit émetteur (A).
19. Système selon l'une quelconque des revendications 15 à 18; ledit premier module (Ml) plaçant dans ladite fenêtre de temporisation (FT), tout ou parties des données, notamment applicatives, dudit paquet reçu par ledit premier module (Ml).
20. Système selon l'une quelconque des revendications 15 à 19; ledit logiciel (L) étant informé que de nouvelles données sont disponibles dans ladite fenêtre de temporisation (FT).
21. Système selon l'une quelconque des revendications 15 à 20; ledit logiciel (L) étant associé à des moyens de traitement informatique pour analyser et/ou modifier sélectivement et/ou filtrer sélectivement les données contenues dans ladite fenêtre de temporisation (FT).
22. Système selon la revendication 21; ledit logiciel (L) informant ledit deuxième module (M2) que des données de ladite fenêtre de temporisation (FT) sont à émettre.
23. Système selon la revendication 22; ledit deuxième module (M2) comprenant des moyens d'émission desdites données à émettre vers ledit récepteur (B).
24. Système selon la revendication 23; ledit deuxième module (M2) se substituant audit émetteur (A) auprès dudit récepteur (B) pour toutes les opérations d'échange d'information avec ledit récepteur (B) que ledit émetteur (A) aurait effectuées s'il avait procédé lui-même à ladite émission de données, de sorte que ladite temporisation est transparente pour ledit récepteur (B).
25. Système selon l'une quelconque des revendications 23 ou 24; ledit deuxième module (M2) informant ledit premier module (Ml) et/ou ledit logiciel (L) que lesdites données ont été émises.
26. Système selon l'une quelconque des revendications 10 15 à 25; ledit logiciel (L) étant associer à des moyens de modification de la taille de la fenêtre de temporisation (FT).
FR0450404A 2004-03-01 2004-03-01 Procede, systeme et dispositif de temporisation d'un flux de paquets de donnees Expired - Fee Related FR2867004B1 (fr)

Priority Applications (3)

Application Number Priority Date Filing Date Title
FR0450404A FR2867004B1 (fr) 2004-03-01 2004-03-01 Procede, systeme et dispositif de temporisation d'un flux de paquets de donnees
PCT/FR2005/050137 WO2005086455A2 (fr) 2004-03-01 2005-03-01 Procede, systeme et dispositif de temporisation d'un flux de paquets de donnees
EP05739712A EP1723772A2 (fr) 2004-03-01 2005-03-01 Procede, systeme et dispositif de temporisation d'un flux de paquets de donnees

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
FR0450404A FR2867004B1 (fr) 2004-03-01 2004-03-01 Procede, systeme et dispositif de temporisation d'un flux de paquets de donnees

Publications (2)

Publication Number Publication Date
FR2867004A1 true FR2867004A1 (fr) 2005-09-02
FR2867004B1 FR2867004B1 (fr) 2006-09-08

Family

ID=34834272

Family Applications (1)

Application Number Title Priority Date Filing Date
FR0450404A Expired - Fee Related FR2867004B1 (fr) 2004-03-01 2004-03-01 Procede, systeme et dispositif de temporisation d'un flux de paquets de donnees

Country Status (3)

Country Link
EP (1) EP1723772A2 (fr)
FR (1) FR2867004B1 (fr)
WO (1) WO2005086455A2 (fr)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1804457A1 (fr) * 2005-12-28 2007-07-04 Zyxel Communications Corporation Terminal et procédé d'exécution de l'ordinateur correspondant à la détection de données malveillantes pour le réseau informatique

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20020133598A1 (en) * 2001-03-16 2002-09-19 Strahm Frederick William Network communication
US20020159447A1 (en) * 2001-04-27 2002-10-31 Carey James Horan Methods, systems and computer program products for translating internet protocol (IP) addresses located in a payload of a packet
US20030005103A1 (en) * 1998-06-15 2003-01-02 Narad Charles E. Cumulative status of arithmetic operations
US20040004968A1 (en) * 2002-07-03 2004-01-08 Ericsson Inc. System and method for dynamic simultaneous connection to multiple service providers
US6693909B1 (en) * 2000-05-05 2004-02-17 Fujitsu Network Communications, Inc. Method and system for transporting traffic in a packet-switched network

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5623600A (en) * 1995-09-26 1997-04-22 Trend Micro, Incorporated Virus detection and removal apparatus for computer networks
EP1750384B1 (fr) * 1997-07-24 2009-09-30 Axway Inc. Pare-feu e-mail
US9392002B2 (en) * 2002-01-31 2016-07-12 Nokia Technologies Oy System and method of providing virus protection at a gateway

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20030005103A1 (en) * 1998-06-15 2003-01-02 Narad Charles E. Cumulative status of arithmetic operations
US6693909B1 (en) * 2000-05-05 2004-02-17 Fujitsu Network Communications, Inc. Method and system for transporting traffic in a packet-switched network
US20020133598A1 (en) * 2001-03-16 2002-09-19 Strahm Frederick William Network communication
US20020159447A1 (en) * 2001-04-27 2002-10-31 Carey James Horan Methods, systems and computer program products for translating internet protocol (IP) addresses located in a payload of a packet
US20040004968A1 (en) * 2002-07-03 2004-01-08 Ericsson Inc. System and method for dynamic simultaneous connection to multiple service providers

Non-Patent Citations (3)

* Cited by examiner, † Cited by third party
Title
FRANTZEN M ET AL: "A Framework for Understanding Vulnerabilities in Firewalls Using a Dataflow Model of Firewall Internals<1>", COMPUTERS & SECURITY, ELSEVIER SCIENCE PUBLISHERS. AMSTERDAM, NL, vol. 20, no. 3, 1 May 2001 (2001-05-01), pages 263 - 270, XP004255237, ISSN: 0167-4048 *
R. BRADEN, D. CLARK, S. CROCKER, C. HUITEMA: "RFC 1636 - Report of IAB Workshop on Security in the Internet Architecture", REQUEST FOR COMMENTS, June 1994 (1994-06-01), XP015007423 *
YAKOMBA YAVWA: "The Firewall Technology", 2 May 2000 (2000-05-02), XP002294671, Retrieved from the Internet <URL:http://citeseer.ist.psu.edu/cache/papers/cs/14568/http:zSzzSzwww.cs.uct.ac.zazSzcourseszSzCS400WzSzNISzSzpapers00zSzjacobzSzfirewall.pdf/yavwa00firewall.pdf> [retrieved on 20040901] *

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1804457A1 (fr) * 2005-12-28 2007-07-04 Zyxel Communications Corporation Terminal et procédé d'exécution de l'ordinateur correspondant à la détection de données malveillantes pour le réseau informatique
US7761915B2 (en) 2005-12-28 2010-07-20 Zyxel Communications Corp. Terminal and related computer-implemented method for detecting malicious data for computer network

Also Published As

Publication number Publication date
WO2005086455A3 (fr) 2005-12-29
FR2867004B1 (fr) 2006-09-08
EP1723772A2 (fr) 2006-11-22
WO2005086455A2 (fr) 2005-09-15

Similar Documents

Publication Publication Date Title
BE1022510B1 (fr) Etablir une connexion de transfert de données
EP2064853B1 (fr) Procédé d&#39;optimisation du contrôle du trafic dans un réseau de télécommunication par paquets
FR2923969A1 (fr) Procede de gestion de trames dans un reseau global de communication, produit programme d&#39;ordinateur, moyen de stockage et tete de tunnel correspondants
FR2926939A1 (fr) Procede de transmission de donnees avec anticipation des acquittements, dispositif d&#39;entree, produit programme d&#39;ordinateur et moyen de stockage correspondants
FR2805112A1 (fr) Procede et unite de controle de flux d&#39;une connexion tcp sur un reseau a debit controle
FR2919778A1 (fr) Procede de transmission de paquets de donnees dans un tunnel, produit programme d&#39;ordinateur, moyen de stockage et tete de tunnel correspondants
FR2909241A1 (fr) Procedes et dispositifs de gestion dynamique des erreurs de transmission par des points d&#39;interconnexion de reseaux.
FR2954029A1 (fr) Procede de transmission de paquets d&#39;un flux de donnees bidirectionnel passager, dispositif gestionnaire, produit programme d&#39;ordinateur et moyen de stockage correspondants
EP3643044B1 (fr) Procédé d&#39;activation de traitements appliqués à une session de données
WO2016062606A1 (fr) Procédé de création d&#39;un sous flux de paquets de données
FR2984554A1 (fr) Bus logiciel
WO2020260813A1 (fr) Procédé de gestion d&#39;une communication entre terminaux dans un réseau de communication, et dispositifs pour la mise en oeuvre du procédé
WO2019106308A1 (fr) Procédé d&#39;acheminement de données d&#39;une session initialisée entre un terminal et un serveur
EP3216189B1 (fr) Délégation d&#39;intermédiation sur un échange de données chiffrées
FR3042081A1 (fr) &#34;procede de controle d&#39;un systeme de communications de donnees par paquets et systeme de communications mettant en œuvre le procede&#34;
CA2830750C (fr) Procede et dispositif d&#39;extraction de donnees d&#39;un flux de donnees circulant sur un reseau ip
EP3991392A1 (fr) Procede de gestion d&#39;une communication entre terminaux dans un reseau de communication, et dispositifs et systeme pour la mise en oeuvre du procede
WO2013178910A1 (fr) Technique de communication dans un reseau de communication centre sur les informations
FR2867004A1 (fr) Procede, systeme et dispositif de temporisation d&#39;un flux de paquets de donnees
FR2809560A1 (fr) Procede et architecture de systeme de communication securise entre deux entites connectees a un reseau de type internet, comprenant un segment de transmissions sans fil
FR2915650A1 (fr) Procede et dispositif d&#39;interface entre les protocoles udp ou tcp et sctp
EP1647125A1 (fr) Description de contenu de paquets dans un reseau de communication par paquets
EP1501248B1 (fr) Système et procédé de messagerie électronique
EP3664377B1 (fr) Procédé et dispositif de mesure d&#39;un paramètre représentatif d&#39;un temps de transmission dans un tunnel de communication chiffré
EP1142261B1 (fr) Procede de transport de paquets entre une interface d&#39;acces et un reseau partage

Legal Events

Date Code Title Description
ST Notification of lapse

Effective date: 20081125