FR2894418A1 - Procede permettant d'assurer l'acheminement securise de messages sur des reseaux informatiques en assurant le franchissement de dispositifs tels que des routeurs, des coupe-feu et des serveurs proxys. - Google Patents

Procede permettant d'assurer l'acheminement securise de messages sur des reseaux informatiques en assurant le franchissement de dispositifs tels que des routeurs, des coupe-feu et des serveurs proxys. Download PDF

Info

Publication number
FR2894418A1
FR2894418A1 FR0512399A FR0512399A FR2894418A1 FR 2894418 A1 FR2894418 A1 FR 2894418A1 FR 0512399 A FR0512399 A FR 0512399A FR 0512399 A FR0512399 A FR 0512399A FR 2894418 A1 FR2894418 A1 FR 2894418A1
Authority
FR
France
Prior art keywords
tunnel
data
field
server
client
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
FR0512399A
Other languages
English (en)
Other versions
FR2894418B1 (fr
Inventor
Thierry Zucchi
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.)
Individual
Original Assignee
Individual
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 Individual filed Critical Individual
Priority to FR0512399A priority Critical patent/FR2894418B1/fr
Publication of FR2894418A1 publication Critical patent/FR2894418A1/fr
Application granted granted Critical
Publication of FR2894418B1 publication Critical patent/FR2894418B1/fr
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • 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/34—Network arrangements or protocols for supporting network services or applications involving the movement of software or configuration parameters 
    • 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/563—Data redirection of data network streams

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

La présente invention a pour objet un procédé permettant d'acheminer un flux de données sur les réseaux IP. Il comprend la réalisation des étapes suivantes :- l'ouverture d'un tunnel entre un client de tunnel et un serveur de tunnel ;- l'émission d'une requête par le client de tunnel vers le serveur de tunnel ayant pour objet d'obtenir les références d'un couple constitué par l'adresse IP et le port publics ;- l'accomplissement préalable et éventuel d'un traitement spécifique d'encapsulation des données constituant ladite requête à transmettre ;- la réception de cette requête par le serveur de tunnel et l'émission d'une réponse à destination du client de tunnel ;- la réception de cette réponse par le client de tunnel ;- l'envoi par le client de tunnel d'une requête à destination d'une entité déterminée contenant l'instruction de diriger les réponses à cette requête en utilisant l'adresse IP et le port publics constituant ledit couple ;- la transmission par le serveur de tunnel de cette requête modifiée vers ladite entité déterminée ;- l'émission d'une réponse éventuelle par cette entité déterminée ;- la transmission de cette réponse modifiée par le serveur de tunnel à destination du client de tunnel.

Description

10 La présente invention a pour objet un procédé permettant d'assurer
l'acheminement sécurisé de messages sur des réseaux informatiques en assurant le franchissement de dispositifs tels que des routeurs, des coupe-feu et des serveurs proxys. 15 Elle concerne notamment le transport de la parole sur les réseaux IP que l'on désigne sous l'appellation VoIP (Voice over Internet Protocol).
D'une façon générale, le transport de la voix téléphonique sur IP nécessite de pouvoir franchir les routeurs, les coupe-feu et les serveurs proxys présents sur 20 les réseaux afin de pouvoir acheminer les messages de parole à son destinataire. On sait que pour franchir des routeurs effectuant de la NAT (Network Address Translation) ou translation d'adresses réseau, on a proposé des solutions qui ont été synthétisées dans le document de l'IETF : Best Current Practices for NAT Traversal for SIP, draft - ietf ù sipping-nat- 25 scenarios-02, C. Boulton et J. Rosenberg . Parmi ces solutions, figurent : • L'utilisation du protocole STUN (a Simple Traversal of User Datagram Protocol (UDP) through Network Address Translators (NAT) - RFC 3489) qui permet à des applications de découvrir la présence et le type de routeurs NAT (ou plus généralement de 30 dispositifs effectuant de la NAT) qui séparent le réseau privé et le réseau public. Ce protocole permet également aux applications de 1 - 2 déterminer les adresses IP et les ports publiques qui lui ont été assignés par lesdits routeurs NAT. De cette façon, un téléphone supportant le protocole STUN peut indépendamment remplacer son adresse IP et son port sources par l'adresse IP et le port publics assignés par le routeur NAT. Ainsi, après avoir pris connaissance de son adresse IP et de son port publics grâce à une requête STUN émise à destination d'un serveur STUN, un client de VoIP pourra les intégrer dans sa requête INVITE SIP afin que les requêtes / réponses ultérieures du destinataire soient dirigées vers cette adresse et ce port publics. Ce protocole STUN présente néanmoins l'inconvénient de ne pas fonctionner à travers un dispositif effectuant de la NAT symétrique. En effet, dans ce cas, un nouveau couple spécifique adresse IP / port publics est créé pour chaque nouvelle destination par conséquent, en utilisant le protocole STUN, les requêtes/réponses émises par le destinataire ne pourront être dirigées vers ce couple spécifique. • L'utilisation du protocole TURN ( Traversa/ Using Relay NAT ) qui permet à un client de VoIP envoyant une requête TURN à un serveur TURN d'obtenir en réponse un couple adresse IP / port publics permettant de joindre ledit serveur TURN, celui-ci établissant une relation entre ce - dit couple et le couple adresse IP / port publics affecté par le routeur effectuant de la NAT symétrique. De cette manière, les messages à destination dudit client VoIP seront dirigés vers le serveur TURN qui les redirigera ensuite vers ledit routeur NAT. Le protocole TURN présente néanmoins l'inconvénient de ne pas permettre à un client VoIP de commander un serveur tel qu'un serveur Web ou SMTP en utilisant l'adresse IP publique affectée par le serveur TURN. • L'utilisation de la méthodologie ICE (Interactive Connectivity Establishment) qui a recours à différents protocoles tels que les protocoles STUN et TURN afin de proposer une solution unifiée. Cette méthodologie consiste pour le client VoIP à récupérer plusieurs couples adresse IP / port publics en émettant des requêtes STUN et TURN. Ces couples sont ensuite intégrés par ledit client de VoIP dans des paramètres candidate de l'application SDP de sa requête INVITE SIP. Chaque candidate comprend notamment un niveau de priorité et au moins un couple adresse IP / port lié à un protocole (RTP, RTCP) de cette façon, après avoir testé chacun de ces couples adresse IP / port avec son destinataire (en envoyant et en recevant des requêtes STUN), le client VoIP et son destinataire pourront communiquer en échangeant de la parole dans les deux sens. Néanmoins, tout comme le protocole TURN, la méthodologie ICE ne permet pas à un client VoIP de commander un serveur tel qu'un serveur Web ou SMTP en utilisant l'adresse IP publique affectée par le serveur TURN. De plus, cette méthodologie tout comme les protocoles STUN et TURN n'offre pas de solution de cryptage et ne résout pas le problème du franchissement des coupe-feu. On sait également que pour franchir les coupe-feu, on a recours à la mise en place de tunnels. Cette technique qui est désignée sous l'appellation "tunneling" consiste à transporter un protocole et ses données dans un autre : les paquets d'un protocole donné font l'objet éventuellement d'une transformation réversible, puis sont encapsulés par un protocole de niveau équivalent dans le modèle OSI, voire inférieur ; ce protocole d'encapsulation permettant de protéger les données qu'il transporte. Une des solutions de "tunneling" consiste à envoyer des données vers un Client Tunnel - HTTP qui les encapsule dans des tunnels HTTP et les dirige vers les serveurs Tunnel - HTTP . Ces serveurs transmettent ensuite ces données vers la destination désirée et dirigent les réponses vers le Client Tunnel HTTP . Toutefois, ce type de technologie présente au moins l'un des inconvénients suivants : • la difficulté de procéder à un cryptage sélectif des flux ; • une possibilité d'utilisation réduite à un nombre limité de systèmes d'exploitation ; • la nécessité d'utiliser des API ( Application Programming Interface ) qui ne sont disponibles que pour des plateformes spécifiques ; 5 • l'augmentation de la consommation de la bande passante ; • une sollicitation accrue des ressources machine. L'invention a donc plus particulièrement pour but de supprimer ces inconvénients. 10 A cet effet, elle propose un procédé permettant d'acheminer un flux de données sur les réseaux IP en assurant le franchissement de tous les routeurs quel que soit le type de NAT mis en oeuvre, de la plupart des coupe-feu et des serveurs proxys ; cet acheminement des données par la mise en oeuvre dudit 15 procédé pouvant s'effectuer de manière sécurisée tout en optimisant la bande passante.
Selon l'invention, ledit procédé comprend la réalisation des étapes suivantes : • l'ouverture d'un tunnel entre un client de tunnel A et un serveur de 20 tunnel A' ; • l'émission d'une requête par le client de tunnel A vers le serveur de tunnel A' ayant pour objet d'obtenir les références du couple constitué par l'adresse IP et le port publics qui devront être utilisés par le destinataire du client de tunnel A afin de lui acheminer des messages ; 25 • l'accomplissement préalable et éventuel d'un traitement spécifique d'encapsulation des données constituant ladite requête à transmettre ; ce traitement consistant à encapsuler la requête dans une trame dont la structure permet de garantir la communication entre le client de tunnel A et le serveur de tunnel A'; ce traitement spécifique pouvant 30 comprendre une étape supplémentaire consistant à encapsuler ladite trame dans une trame http afin de permettre le franchissement de la plupart des coupe - feu ; • la réception de cette requête par le serveur de tunnel A', la décapsulation éventuelle des paquets la constituant et l'émission d'une réponse à destination du client de tunnel A dans laquelle figure ce couple adresse IP / port publics, cette réponse étant acheminée dans ledit tunnel après avoir éventuellement procédé audit traitement spécifique d'encapsulation ; • la réception de cette réponse par le client de tunnel A et l'accomplissement éventuel d'une décapsulation des paquets la constituant ; • l'envoi par le client de tunnel A d'une requête à destination d'une entité déterminée contenant l'instruction de diriger les réponses à cette requête en utilisant l'adresse IP et le port publics constituant ledit couple ; cette requête étant acheminée entre le client de tunnel A et le serveur de tunnel A' dans ledit tunnel après avoir éventuellement procédé audit traitement spécifique d'encapsulation ; • la décapsulation partielle éventuelle des paquets constituant ladite requête au niveau du serveur de tunnel A' ; • la transmission par le serveur de tunnel A' de cette requête modifiée vers ladite entité déterminée ; • l'émission d'une réponse éventuelle par cette entité déterminée en utilisant les références dudit couple constitué par ladite adresse IP et ledit port publics ; • la réception par le serveur de tunnel A' de cette réponse ; • l'accomplissement éventuel dudit traitement spécifique d'encapsulation par le serveur A' ; • la transmission de cette réponse modifiée par le serveur de tunnel A' à destination du client de tunnel A, cette réponse étant acheminée dans ledit tunnel ; • la réception de cette réponse modifiée par le client de tunnel A et l'accomplissement éventuel d'une décapsulation des paquets la constituant.
De manière avantageuse, le client de tunnel A et le serveur de tunnel A' pourront chacun comprendre au moins une interface de communication (une interface "socket"), cette particularité combinée à la mise en oeuvre dudit procédé permet au client de tunnel A, par l'intermédiaire du serveur de tunnel A', de commander un serveur tel qu'un serveur Web ou SMTP en utilisant l'adresse IP publique affectée par ledit serveur de tunnel A'.
Avantageusement, selon une variante d'exécution de l'invention, le traitement spécifique d'encapsulation pourra également comprendre une étape consistant à crypter le message à transmettre afin de sécuriser la communication. Un mode d'exécution de l'invention sera décrit ci-après, à titre d'exemple non limitatif, avec référence aux dessins annexés dans lesquels :
La figure 1 est une représentation schématique des différents dispositifs 20 nécessaires à la mise en oeuvre du procédé selon l'invention.
La figure 2 est une représentation schématique d'une trame émise dans le cadre d'une communication entre un client de tunnel, un serveur de tunnel et un client de voix sur IP, ladite communication étant établie 25 dans le cadre de la mise en oeuvre du procédé selon l'invention.
La figure 3 est une représentation schématique d'une trame émise dans le cadre d'une communication entre un client de tunnel, un serveur de tunnel et un serveur SIP, ladite communication étant établie dans le 30 cadre de la mise en oeuvre du procédé selon l'invention.15 La figure 4 est une représentation schématique des interfaces de communication, du tunnel, du client de tunnel A, du serveur de tunnel A' et des entités destinataires des requêtes du client de tunnel A.
La figure 5 est une représentation schématique de la trame permettant de garantir la communication entre le client de tunnel A et le serveur de tunnel A'.
La figure 6 est une représentation schématique d'une requête et d'une réponse émises entre le client de tunnel A et un serveur SIP avec une mise en évidence au niveau du serveur de tunnel A' du mécanisme de décapsulation partielle et de réencapsulation de ladite requête / réponse.
La figure 7 est une représentation schématique d'une requête et d'une réponse émises entre le client de tunnel A et un destinataire avec une mise en évidence au niveau du serveur de tunnel A' du mécanisme de décapsulation partielle et de réencapsulation de ladite requête / réponse.
Tel que représenté sur les figures 1 et 4, un client A placé derrière un dispositif effectuant de la NAT 1 sollicite l'ouverture d'un tunnel T avec un serveur de tunnel A' qui comprend au moins une interface de communication PCA' (une interface "socket"). Ce client A est muni d'un dispositif 2 permettant le transport de la parole sur les réseaux IP qui comprend au moins une interface de communication PCA (une interface "socket") et ayant dans cet exemple l'adresse IP "a.b.c.d" et le port source "x" ; la communication entre le client A et le serveur de tunnel A' s'établissant grâce à la présence des interfaces de communications PCA et PCA'.
Le dispositif 2 permettant le transport de la parole sur les réseaux IP peut être 30 notamment un ordinateur ou un téléphone intégrant la technologie VoIP (Voix -8- sur IP) tel qu'un téléphone de type "smartphone" (marque enregistrée). Le dispositif 1 permettant d'effectuer de la NAT peut être un routeur.
Une requête est ensuite émise par le client de tunnel A vers le serveur de tunnel A', cette requête ayant pour objet d'obtenir les références d'un couple constitué par une adresse IP publique et par un port public. Ce couple constitué dans cet exemple par l'adresse IP publique "f.g.h.i" et par le port public "y" qui est spécifique au serveur de tunnel A', est transmis par celui-ci au client de tunnel A qui indiquera aux entités avec lesquelles il souhaite établir une communication, de lui envoyer des messages en utilisant ladite adresse publique "f.g.h.i" et ledit port public "y". Ainsi, le serveur de tunnel A' sert de relais entre le client de tunnel A et toutes les entités avec lesquelles ce dernier communique en effet, ces entités adresseront leurs messages à destination du client de tunnel A en utilisant l'adresse IP "f.g.h.i" et le port "y", lesdits messages seront alors dirigés vers le serveur de tunnel A' qui les redirigera vers le client de tunnel A.
De manière avantageuse, toutes les requêtes et les réponses émises entre le client de tunnel A et le serveur de tunnel A' pourront faire l'objet d'un traitement spécifique d'encapsulation.
Ce traitement d'encapsulation consiste à encapsuler les requêtes ou les réponses transmises ou véhiculant par le serveur de tunnel A', dans une trame spécifique TS dont l'en-tête présente une structure qui fait l'objet d'une représentation schématique sur la figure 5. Ainsi, l'en- tête de cette trame spécifique TS comprend notamment : • deux champs comprenant chacun un caractère tel que par exemple la lettre " A " et la lettre " Z " : ces deux caractères, en l'espèce " A " et Z ", permettent d'indiquer le début de cette trame spécifique TS ; et/ou • un champ " Version " qui comprend un numéro associé à un traitement déterminé des paquets ; et/ou • un champ " Type " qui comporte le type de données du champ " Data ", ces données pouvant être notamment des données classiques ou des données de contrôle ; et/ou • un champ " Subtype " qui comprend le sous-type des données du champ " Data " ; et/ou • un champ " Encryption Type " qui comporte le type d'algorithme de cryptage utilisé pour chiffrer le champ " Data " ; et/ou • un champ " Data length " qui indique la longueur du champ " Données " ; et/ou • un champ " Data offset " qui indique l'emplacement du champ " Data ", à savoir le nombre d'octets de décalage par rapport à la fin de l'en-tête de la trame ; et/ou • un champ " Options length " qui indique la longueur du champ " Options " ; et/ou • un champ " Options offset " qui indique l'emplacement du champ " Options ", à savoir le nombre d'octets de décalage par rapport à la fin de l'en-tête de la trame ; et/ou • un champ " Options " qui comprend des options éventuelles ; le champ pouvant être complété de zéro afin que le champ " Data " débute sur un octet multiple de 4, le premier octet étant à la position 0 ; et/ou • un champ " Data " qui comprend des données éventuelles.
Les données qui figurent dans le champ "Data" peuvent être notamment des données classiques (une requête spécifique ou une réponse à une telle requête par exemple) ou des données de contrôle qui permettent d'une part, de vérifier et de contrôler le bon fonctionnement de la communication et d'autre part, de commander des mécanismes de rafraîchissement des connexions si cela est nécessaire. L'indication de la nature des données figurant dans le champ - 10- "Data" est donnée par la valeur du champ "Type" ainsi, à titre d'exemple, ce dernier champ peut comprendre : • la valeur "DATA" si le champ "Data" comprend des données classiques; et • la valeur "CONTROL" si le champ "Data" comprend des données de contrôle.
Dans l'hypothèse où le champ "Data" comprend des données classiques, le champ " Subtype " peut indiquer par exemple, s'il s'agit d'une trame contenant une requête spécifique ou d'une réponse à une requête spécifique. De manière avantageuse, le champ " Data " peut faire l'objet d'un traitement de cryptage en utilisation un algorithme de cryptage dont le type est spécifié dans le champ " Encryption Type ". Ainsi, à tire d"exemple, l'algorithme de cryptage peut être le DES (Data Encryption Standard) ou l'AES (Advanced Encryption Standard). A titre d'exemple, le champ "Options" peut comprendre une instruction selon laquelle un ou des paquet(s) spécifique(s) doit (doivent) être stocké(s) et conservé(s) pendant un délai déterminé par exemple, au sein du serveur de tunnel A'.
Avantageusement, selon une variante d'exécution de l'invention, le traitement spécifique d'encapsulation peut comprendre une étape supplémentaire consistant à encapsuler ladite trame spécifique TS dans une trame http afin de permettre le franchissement de la plupart des coupe -feu CF et des serveurs proxys en effet, en théorie, seul un coupe û feu CF effectuant un filtrage applicatif pourrait bloquer le trafic.
De cette façon, ce traitement d'encapsulation combiné notamment à l'étape ayant pour objet l'ouverture d'un tunnel T entre un client de tunnel A et un -11- serveur de tunnel A' permet de garantir la communication entre ledit client de tunnel A et ledit serveur de tunnel A'.
L'exemple tel que représenté sur la figure 2, illustre la structure d'une trame circulant entre le client de tunnel A et le serveur de tunnel A', dans le cadre d'une tentative de communication entre le client de tunnel A et un client de voix sur IP. Les paquets DATA et RTP/RTCP sont encapsulés dans la susdite trame spécifique TS qui est elle-même encapsulée dans une trame http avant d'être remise à la couche transport à savoir, TCP.
L'exemple représenté sur la figure 3, illustre la structure d'une trame circulant entre le client de tunnel A et le serveur de tunnel A', dans le cadre d'une tentative de communication entre le client de tunnel A et un serveur SIP. Ainsi, les paquets SIP/SDP sont encapsulés dans la susdite trame spécifique TS qui est elle-même encapsulée dans une trame http avant d'être remise à la couche transport en l'espèce, TCP.
La requête émise par le client de tunnel A est reçue par le serveur de tunnel A'. Un traitement de décapsulation des paquets la constituant est effectué au sein du serveur de tunnel A', cette opération consistant à prélever la trame spécifique TS et la trame http puis à traiter les données figurant dans le champ " Data " de l'en û tête de la trame spécifique TS. Après avoir traité ces données, le serveur de tunnel A' émet une réponse à destination du client de tunnel A dans laquelle figure le couple adresse IP publique " f.g.h.i " / port public " y ", cette réponse faisant l'objet du traitement spécifique d'encapsulation.
Cette réponse est reçue par le client de tunnel A et fait l'objet dudit traitement de décapsulation.30 - 12- Le client de tunnel A peut ensuite émettre une requête à destination d'une entité déterminée avec l'instruction de diriger les réponses en utilisant le couple adresse IP publique " f.g.h.i " / port public " y ". Cette requête est acheminée entre le client de tunnel A et le serveur de tunnel A' dans ledit tunnel T après avoir procédé audit traitement spécifique d'encapsulation.
La requête émise par le client de tunnel A est reçue par le serveur de tunnel A' qui procède audit traitement de décapsulation des paquets puis la dirige à destination de l'entité déterminée.
Cette entité déterminée peut être notamment, mais non exclusivement : • un serveur SIP; ou • un serveur TCP; ou • un serveur UDP; ou • un serveur RTP / RTCP ; ou • un client TCP; ou • un client UDP ; ou • un client RTP / RTCP.
Dans l'hypothèse où il s'agit d'un serveur SIP, la procédure classique d'établissement d'une communication selon le protocole SIP est mise en oeuvre.
Ainsi, avantageusement, le procédé selon l'invention permet par l'intermédiaire du serveur de tunnel A' et des points de communication PCA et PCA' ainsi que de la trame spécifique TS de commander à distance une entité déterminée telle qu'un serveur Web ou SMTP en utilisant un couple adresse IP publique / port public. Dans le cadre de l'établissement d'une telle communication, le serveur de tunnel A' et ladite entité peuvent également respectivement comprendre au moins une interface de communication PCA" (une interface "socket") distincte de l'interface de communication PCA' et au -13- moins une interface de communication (une interface "socket" non représentée). Une réponse éventuelle est émise par cette entité déterminée en utilisant les 5 références dudit couple constitué par ladite adresse IP publique " f.g.h.i " et ledit port "y" public.
Cette réponse est reçue par le serveur de tunnel A' qui procède éventuellement audit traitement spécifique d'encapsulation puis est transmise à destination du 10 client de tunnel A dans le tunnel T.
Cette réponse est reçue par le client de tunnel A qui procède éventuellement au traitement de décapsulation partielle des paquets la constituant.
15 Lorsque la communication entre le client de tunnel A et son destinataire est terminée, le tunnel T est fermé.

Claims (9)

Revendications
1. Procédé permettant d'acheminer un flux de données sur les réseaux IP, caractérisé en ce qu'il comprend la réalisation des étapes suivantes : • l'ouverture d'un tunnel (T) entre un client de tunnel (A) et un serveur de tunnel (A') ; • l'émission d'une requête par le client de tunnel (A) vers le serveur de tunnel (A') ayant pour objet d'obtenir les références du couple constitué par l'adresse IP ("f.g.h.i") et le port ("y") publics qui doivent être utilisés par le destinataire du client de tunnel (A) afin de lui acheminer des messages ; • l'accomplissement préalable et éventuel d'un traitement spécifique d'encapsulation des données constituant ladite requête à transmettre ; ce traitement consistant à encapsuler la requête dans une trame spécifique (TS) ; • la réception de cette requête par le serveur de tunnel (Al), la décapsulation éventuelle des paquets la constituant et l'émission d'une réponse à destination du client de tunnel (A) dans laquelle figure ce couple adresse IP ("f.g.h.i") / port ("y") publics, cette réponse étant acheminée dans ledit tunnel (T) après avoir éventuellement procédé audit traitement spécifique d'encapsulation ; • la réception de cette réponse par le client de tunnel (A) et l'accomplissement éventuel d'une décapsulation des paquets la constituant ; • l'envoi par le client de tunnel (A) d'une requête à destination d'une entité déterminée contenant l'instruction de diriger les réponses à cette requête en utilisant l'adresse IP ("f.g.h.i") et le port ("y") publics constituant ledit couple ; cette requête étant acheminée entre le client de tunnel (A) et le serveur de tunnel (A') dans ledit tunnel (T) après avoir éventuellement procédé audit traitement spécifique d'encapsulation ;-15-• la décapsulation partielle éventuelle des paquets constituant ladite requête au niveau du serveur de tunnel (A') ; • la transmission par le serveur de tunnel (A') de cette requête modifiée vers ladite entité déterminée ; • l'émission d'une réponse éventuelle par cette entité déterminée en utilisant les références dudit couple constitué par ladite adresse IP ("f.g.h.i") et ledit port ("y") publics • la réception par le serveur de tunnel (A') de cette réponse ; • l'accomplissement éventuel dudit traitement spécifique d'encapsulation l0 par le serveur (A') ; • la transmission de cette réponse modifiée par le serveur de tunnel (A') à destination du client de tunnel (A), cette réponse étant acheminée dans ledit tunnel (T) ; • la réception de cette réponse modifiée par le client de tunnel (A) et 15 l'accomplissement éventuel d'une décapsulation des paquets la constituant.
2. Procédé selon la revendication 1, caractérisé en ce que l'en-tête de la trame spécifique (TS) comprend : 20 • deux champs comprenant chacun un caractère : ces deux caractères permettant d'indiquer le début de cette trame spécifique (TS) ; et/ou • un champ " Version " qui comprend un numéro associé à un traitement déterminé des paquets ; et/ou • un champ " Type " qui comporte le type de données du champ " Data ", 25 ces données pouvant être notamment des données classiques ou des données de contrôle ; et/ou • un champ " Subtype " qui comprend le sous-type des données du champ " Data " ; et/ou • un champ " Encryption Type " qui comporte le type d'algorithme de 30 cryptage utilisé pour chiffrer le champ " Data " ; et/ou- 16- • un champ " Data length " qui indique la longueur du champ " Données " ; et/ou • un champ " Data offset " qui indique l'emplacement du champ " Data ", à savoir le nombre d'octets de décalage par rapport à la fin de l'en-tête de la trame ; et/ou • un champ " Options length " qui indique la longueur du champ " Options " ; et/ou • un champ " Options offset " qui indique l'emplacement du champ " Options ", à savoir le nombre d'octets de décalage par rapport à la fin de l'en-tête de la trame ; et/ou • un champ " Options " qui comprend des options éventuelles ; le champ pouvant être complété de zéro afin que le champ " Data " débute sur un octet multiple de 4, le premier octet étant à la position 0 ; et/ou • un champ " Data " qui comprend des données éventuelles.
3. Procédé selon la revendication 2, caractérisé en ce que les données qui figurent dans le champ "Data" sont des données classiques ou des données de contrôle permettant d'une part, de vérifier et de contrôler le bon fonctionnement de la communication et d'autre part, de commander des mécanismes de rafraîchissement des connexions si cela est nécessaire.
4. Procédé selon l'une des revendications 2 et 3, caractérisé en ce que l'algorithme de cryptage dont le type est spécifié dans le 25 champ " Encryption Type " est l'algorithme DES ou AES.
5. Procédé selon l'une des revendications précédentes, caractérisé en ce que le traitement spécifique d'encapsulation comprend une étape supplémentaire consistant à encapsuler ladite trame spécifique (TS) dans 30 une trame http afin de permettre le franchissement de la plupart des coupe - feu (CF) et des serveurs proxys. 2894418 -17-
6. Procédé selon l'une des revendications précédentes, caractérisé en ce que l'opération de décapsulation des paquets consiste à prélever la trame spécifique (TS) et la trame http puis à traiter les données 5 figurant dans le champ " Data " de l'en û tête de la trame spécifique (TS).
7. Dispositif pour la mise en oeuvre du procédé selon la revendication 1, caractérisé en ce que le serveur de tunnel (A') comprend au moins une interface de communication (PCA') et en ce que le client (A) est muni d'un 10 dispositif (2) permettant le transport de la parole sur les réseaux IP qui comprend au moins une interface de communication (PCA).
8. Dispositif selon la revendication 7, caractérisé en ce que l'entité déterminée est : 15 • un serveur SIP; ou • un serveur TCP; ou • un serveur UDP; ou • un serveur RTP / RTCP ; ou • un client TCP; ou 20 • un client UDP ; ou • un client RTP / RTCP.
9. Dispositif selon l'une des revendications 7 et 8, caractérisé en ce que le serveur de tunnel (A') comprend au moins une interface de communication (PCA") distincte de l'interface de communication (PCA') et en ce que l'entité déterminée comprend au moins une interface de communication qui participent à l'élaboration d'une communication entre le serveur de tunnel (A') et l'entité déterminée.
FR0512399A 2005-12-07 2005-12-07 Procede permettant d'assurer l'acheminement securise de messages sur des reseaux informatiques en assurant le franchissement de dispositifs tels que des routeurs, des coupe-feu et des serveurs proxys. Expired - Fee Related FR2894418B1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
FR0512399A FR2894418B1 (fr) 2005-12-07 2005-12-07 Procede permettant d'assurer l'acheminement securise de messages sur des reseaux informatiques en assurant le franchissement de dispositifs tels que des routeurs, des coupe-feu et des serveurs proxys.

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
FR0512399A FR2894418B1 (fr) 2005-12-07 2005-12-07 Procede permettant d'assurer l'acheminement securise de messages sur des reseaux informatiques en assurant le franchissement de dispositifs tels que des routeurs, des coupe-feu et des serveurs proxys.

Publications (2)

Publication Number Publication Date
FR2894418A1 true FR2894418A1 (fr) 2007-06-08
FR2894418B1 FR2894418B1 (fr) 2008-03-14

Family

ID=36118281

Family Applications (1)

Application Number Title Priority Date Filing Date
FR0512399A Expired - Fee Related FR2894418B1 (fr) 2005-12-07 2005-12-07 Procede permettant d'assurer l'acheminement securise de messages sur des reseaux informatiques en assurant le franchissement de dispositifs tels que des routeurs, des coupe-feu et des serveurs proxys.

Country Status (1)

Country Link
FR (1) FR2894418B1 (fr)

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20020184373A1 (en) * 2000-11-01 2002-12-05 International Business Machines Corporation Conversational networking via transport, coding and control conversational protocols
US20030188001A1 (en) * 2002-03-27 2003-10-02 Eisenberg Alfred J. System and method for traversing firewalls, NATs, and proxies with rich media communications and other application protocols
US20030217149A1 (en) * 2002-05-20 2003-11-20 International Business Machines Corporation Method and apparatus for tunneling TCP/IP over HTTP and HTTPS
WO2005009018A1 (fr) * 2003-07-16 2005-01-27 Callkey Limited Etablissement d'appel a base d'ip
US20050125532A1 (en) * 2000-05-26 2005-06-09 Gur Kimchi Traversing firewalls and nats
WO2005089063A2 (fr) * 2004-03-24 2005-09-29 Ipoint Media Ltd. Pare-feu sur multimedias et barrieres de traduction d'adresse de reseau (nat)/traducteur d'adresse de port (pat) dans des reseaux ip

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20050125532A1 (en) * 2000-05-26 2005-06-09 Gur Kimchi Traversing firewalls and nats
US20020184373A1 (en) * 2000-11-01 2002-12-05 International Business Machines Corporation Conversational networking via transport, coding and control conversational protocols
US20030188001A1 (en) * 2002-03-27 2003-10-02 Eisenberg Alfred J. System and method for traversing firewalls, NATs, and proxies with rich media communications and other application protocols
US20030217149A1 (en) * 2002-05-20 2003-11-20 International Business Machines Corporation Method and apparatus for tunneling TCP/IP over HTTP and HTTPS
WO2005009018A1 (fr) * 2003-07-16 2005-01-27 Callkey Limited Etablissement d'appel a base d'ip
WO2005089063A2 (fr) * 2004-03-24 2005-09-29 Ipoint Media Ltd. Pare-feu sur multimedias et barrieres de traduction d'adresse de reseau (nat)/traducteur d'adresse de port (pat) dans des reseaux ip

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
SIPPING WG J ROSENBERG DYNAMICSOFT R MAHY CISCO S SEN NORTEL: "NAT and Firewall Scenarios and Solutions for SIP; draft-ietf-sipping-nat-scenarios-00.txt", IETF STANDARD-WORKING-DRAFT, INTERNET ENGINEERING TASK FORCE, IETF, CH, vol. sipping, 24 June 2002 (2002-06-24), XP015003441, ISSN: 0000-0004 *

Also Published As

Publication number Publication date
FR2894418B1 (fr) 2008-03-14

Similar Documents

Publication Publication Date Title
EP3342127B1 (fr) Dispositif de commande de flux de paquets de réseau ayant une gestion de session étendue
EP3476095B1 (fr) Procédé de communication udp via des chemins multiples entre deux terminaux
US7894364B2 (en) Method for the transmission of data packets in a tunnel, corresponding computer program product, storage means and tunnel end-point
EP2073507A1 (fr) Contrôle de l'interface d'émission d'un message de réponse SIP
US10091099B2 (en) Session continuity in the presence of network address translation
US10298616B2 (en) Apparatus and method of securing network communications
US8817815B2 (en) Traffic optimization over network link
EP3210346B1 (fr) Procédé de création d'un sous flux de paquets de données
WO2009053646A1 (fr) Procédé de traversée d'équipement de traduction d'adresses pour messages de signalisation sip par utilisation temporaire du protocole de transport tcp
EP3549368B1 (fr) Procédé de fractionnement de messages applicatifs dans un réseau ip
EP3503499B1 (fr) Procédé d'optimisation de l'efficacité spectrale dans un contexte d'interconnexion mpls
FR2894418A1 (fr) Procede permettant d'assurer l'acheminement securise de messages sur des reseaux informatiques en assurant le franchissement de dispositifs tels que des routeurs, des coupe-feu et des serveurs proxys.
EP3235217B1 (fr) Procédé d'échanges de données entre deux navigateurs internet, équipement de routage, terminal, programme d'ordinateur et support d'informations corespondants
EP3949287B1 (fr) Passerelle et procédé de différentiation de trafic émis par la passerelle, dispositif et procédé gestion du trafic
EP1704682B1 (fr) Systeme de communication entre reseaux ip prives et publics
EP2258096B1 (fr) Procédé de routage de données d'un flux de communication
Thanthry et al. A novel mechanism for improving performance and security of tcp flows over satellite links
FR2922068A1 (fr) Procede de notification a un dispositif source d'une taille limite de paquets de donnees, produit programme d'ordinateur, moyen de stockage et tete de tunnel correspondants
FR2925251A1 (fr) Procedes de gestion de connexion dans un mode de dechargement d'une tete de tunnel, produit programme d'ordinateur, moyen de stockage et tetes de tunnel correspondants
FR2951045A1 (fr) Procede de gestion de la taille de paquets de donnees d'un flux de donnees, produit programme d'ordinateur, moyen de stockage, et tete de tunnel correspondants.
Villoing Presentation of
EP1432213A1 (fr) Plate-forme de médiation et réseau de transport de messages
FR2901083A1 (fr) Une methode de mise en place des reseaux prives virtuels et de control d'acces distant
Kukkonen Build Mobile Phone Connectivity Over IP Networks
FR2951044A1 (fr) Procede et dispositif de gestion de transmission de donnees sur un lien de communication, produit programme d'ordinateur et moyen de stockage correspondants.

Legal Events

Date Code Title Description
ST Notification of lapse

Effective date: 20100831