EP2055082A1 - Procédé de gestion d'une session de transfert sécurisée au travers d'un dispositif de translation d'adresse, serveur et programme d'ordinateur correspondants - Google Patents

Procédé de gestion d'une session de transfert sécurisée au travers d'un dispositif de translation d'adresse, serveur et programme d'ordinateur correspondants

Info

Publication number
EP2055082A1
EP2055082A1 EP07786843A EP07786843A EP2055082A1 EP 2055082 A1 EP2055082 A1 EP 2055082A1 EP 07786843 A EP07786843 A EP 07786843A EP 07786843 A EP07786843 A EP 07786843A EP 2055082 A1 EP2055082 A1 EP 2055082A1
Authority
EP
European Patent Office
Prior art keywords
server
address
session
stun
transport
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
EP07786843A
Other languages
German (de)
English (en)
Inventor
Gaël BREARD
Marc Bailly
Didier Gorges
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.)
Orange SA
Original Assignee
France Telecom 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 France Telecom SA filed Critical France Telecom SA
Publication of EP2055082A1 publication Critical patent/EP2055082A1/fr
Withdrawn legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/09—Mapping addresses
    • H04L61/25—Mapping addresses of the same type
    • H04L61/2503—Translation of Internet protocol [IP] addresses
    • H04L61/256—NAT traversal
    • H04L61/2575—NAT traversal using address mapping retrieval, e.g. simple traversal of user datagram protocol through session traversal utilities for NAT [STUN]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/09—Mapping addresses
    • H04L61/25—Mapping addresses of the same type
    • H04L61/2503—Translation of Internet protocol [IP] addresses
    • H04L61/2521—Translation architectures other than single NAT servers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/09—Mapping addresses
    • H04L61/25—Mapping addresses of the same type
    • H04L61/2503—Translation of Internet protocol [IP] addresses
    • H04L61/2521—Translation architectures other than single NAT servers
    • H04L61/2532—Clique of NAT servers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/09—Mapping addresses
    • H04L61/25—Mapping addresses of the same type
    • H04L61/2503—Translation of Internet protocol [IP] addresses
    • H04L61/256—NAT traversal
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/09—Mapping addresses
    • H04L61/25—Mapping addresses of the same type
    • H04L61/2503—Translation of Internet protocol [IP] addresses
    • H04L61/256—NAT traversal
    • H04L61/2589—NAT traversal over a relay server, e.g. traversal using relay for network address translation [TURN]
    • 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/16—Implementing security features at a particular protocol layer
    • H04L63/166—Implementing security features at a particular protocol layer at the transport layer

Definitions

  • a method of managing a secure transfer session through an address translation device, server and corresponding computer program is a method of managing a secure transfer session through an address translation device, server and corresponding computer program.
  • the present invention relates to the field of connections between local area networks and communication networks based on the IP protocol.
  • the present invention relates more particularly to the connection of networks called "domestic", integrating communication means such as computers, mobile phones, multimedia consoles and the Internet, in the framework of sharing or exchange in networks. peer-to-peer networks.
  • a device responsible for linking the local network to the Internet integrates, most of the time, one or more NAT devices. Address Translation "for" Translation of Network Addresses ") that allow to” share "a public Internet address (IP) between several devices in the home network.
  • IP Internet address
  • IP IP
  • home router such as a STB
  • connection information can be: the address and the public ports allocated by the NAT, the type of NAT (symmetrical, port restricted, ...) for example.
  • the STUN algorithm applied by the client has several tests to determine the NAT device type. In one of these tests, the LAN STUN client will ask the STUN server to respond to it from an IP address different from the one from which it has responded so far. The objective of this test is to enable the client, by interpreting the reception or not of a response to this request, to know if the NAT device to which it is connected blocks a packet coming from an IP address with which it is connected. never communicated.
  • a STUN server In the current state of the art techniques, a STUN server must, to be able to respond to this type of request, have two different IP addresses. So, when a C STUN client wants to address a STUN A server, he starts by establishing a TLS / TCP connection (encrypted connection) and sends on this connection a SHARED-SECRET-REQUEST request to exchange a shared secret. The STUN A server responds with a SHARED-SECRET-RESPONSE message with a username and password attribute. All subsequent requests, issued using the User Datagram Protocol (UDP) for "User Datagram Exchange Protocol", include a field recalling the user name and other integrity field. message (message integrity) which constitutes a signature of the message using the previously exchanged password.
  • UDP User Datagram Protocol
  • message message integrity
  • a STUN server On receipt of any STUN request of the "Binding-Request" type, a STUN server must announce the other address it has (attribute CHANGED-ADDRESS) and from which it is able to respond if the client C STUN request to reply from a different address ⁇ (see ⁇ 11.2.3 of RFC 3489 STUN)
  • STUN servers as described by the standard are extremely difficult to deploy in P2P networks.
  • the functions of STUN servers are hosted at a central server.
  • such a method comprises: a step of obtaining at least a second datagram sending address from at least one second transfer session management server; so that said client terminal can transfer datagrams to said first server using at least said two addresses.
  • the invention is based on a new and inventive approach to the management of secure datagram transfer sessions by obtaining the IP addresses necessary for the communication session to be carried out with other servers.
  • the second address used in the communication session is that of a second server, which allows the first server to not have two addresses and overcomes a lack of IP addresses.
  • said method comprises the following phases: request to open said secure transfer session sent by said client terminal to said first server; opening said secure transfer session by said first server, engaging said step of obtaining said at least one second address; maintaining said transfer session by said first server, allowing management of transfers from said at least one second address.
  • the management of the communication session comprises successive phases allowing the establishment and maintenance of the session:
  • the terminal requires opening a session to the first server
  • the first server commits to obtaining the second address necessary for the execution of the session with a second server;
  • the first server maintains the session all the time necessary, thus allowing the transfer of data from the second address, and therefore the second server.
  • said opening phase of said session comprises the following steps: transfer, by said first server, of said opening request to said second server; generating said transfer session by said second server; transmitting at least a first piece of information representative of said transfer session to said first server, by said second server; storing, by said first server, said at least one piece of information representative of said transfer session; transferring at least a second piece of information representative of said transfer session to said client, by said first server.
  • obtaining the second address is achieved by a sequence of steps that are initiated by the first server. Indeed, the latter does not open the session, but transmits the opening request to the second server. This second server therefore opens a communication session from which it transmits representative information to the first server so that they can communicate together through this session.
  • the representative information transmitted may either contain the second address, or information allowing to know this second address.
  • the first server then stores the representative information of this session and then transmits a second piece of information representative of this session to the client who requested the opening of the session.
  • This second piece of information representative of the session can either contain the address of the second server, or other information making it possible to acquaint with this second address.
  • said maintenance phase comprises the following steps: transmission, by said client terminal, of a user datagram transfer request using said at least two addresses, to said first server; transmitting said transfer request, by said first server, to said second server, specifying a response address of said client; said first server qualifies a first communication configuration between said client and said first server; said second server qualifying a second communication configuration between said client and said second server, using said response address.
  • the client terminal having obtained a second communication address through the first server, uses one or other of these addresses to communicate with the first server.
  • the client terminal therefore sends a request to the first server indicating as response address (the response address is the address from which it expects to receive the requested information) either of the these addresses.
  • the first server transmits, to the second server, the requests that are intended for this second server.
  • the first server qualifies a first communication configuration with the client that allows the latter to communicate with the first server.
  • the second server qualifies a second configuration of communication with the client.
  • said transfer session comprises at least one session code taking into account at least one of the parameters belonging to the group comprising at least: information representative of an identifier of a user of said client terminal ; information representative of a password of a user of said client terminal.
  • the invention also relates to a server for managing a session for securely transferring user datagrams of a client terminal, said session containing a first datagram sending address and at least one second datagram issuing address, distinct from said first address,
  • such a server comprises: means for obtaining at least a second datagram sending address from at least one second transfer session management server; so that said client terminal can transfer datagrams to said first server using at least said two addresses.
  • such a server comprises means for: opening said secure transfer session by said first server following a request sent by said client terminal, engaging said means for obtaining said at least one second address; - Maintaining said transfer session by said first server, for managing transfers from said at least one second address.
  • such a management server complies with the STUN protocol.
  • the invention also relates to a computer program product downloadable from a communication network and / or stored on a computer readable medium and / or executable by a microprocessor.
  • such a computer program product comprises program code instructions for executing the method of managing a session for securely transferring user datagrams of a client terminal. as previously described. 4 LIST OF FIGURES
  • FIG. 1 shows an example of architecture of a local area network connected to
  • FIG. 2 presents the principle of obtaining a second datagram transmission address according to the invention, in the architecture presented in FIG. 1;
  • FIG. 3 illustrates the establishment of a secure communication session using the STUN protocol in the architecture of FIG. 1;
  • - Figure 4 shows a simplified hardware architecture of a client
  • Figure 5 shows a simplified hardware architecture of a server
  • the invention therefore proposes to substitute the use of a STUN server having two IP addresses, by the use of STUN servers having only one IP address.
  • the invention makes it possible to deploy large-scale peer-to-peer applications.
  • the general principle of the invention is based on a new and inventive implementation of the specifications of the STUN protocol. Indeed, the invention does not require modification of the existing STUN protocol. It is based on a new implementation of this protocol. Thus, one can deploy many STUN servers, without these being in the obligation to have two different IP addresses.
  • the invention therefore goes against current techniques of the prior art which are content not to relocate the features related to the server STUN.
  • STUN in a local network type "domestic" connected to the Internet through a home router. It is clear however that the invention is not limited to this particular application, but can also be implemented in many other fields, and for example in any application where it is desired to deploy STUN servers without it being desired that they have several addresses and more generally in all cases where the characteristics listed later are interesting.
  • client should be understood here and in the remainder of the presentation as designating an entity that requests the resources of another entity to execute a task, a client that can be materialized by an autonomous server, a group of servers or by various elements separately distributed within various means of communication included in the system.
  • a STUN client that requires the establishment of a secure transfer session to a STUN server can also act as a STUN server for another client also requesting the establishment of another transfer session. secured.
  • each of these two servers has an IP address. They are located outside the local area network (LOC N ) of the user and are accessible through the Internet (I Net )
  • LOC N local area network
  • I Net Internet
  • a STUN C STUN client is located within a local area network. It can be a personal computer, a mobile phone, or other multimedia equipment that has a network interface to connect to that local network. This client C STUN communicates on the Internet through a NAT NAT NAT address translation gateway.
  • the servers STUN A and STUN B are able to manage a session for the secure transfer of user datagrams according to the invention.
  • the proposed solution consists in using two STUN servers mono address to honor this type of request.
  • This is transparent from the point of view of the STUN C client that can remain standard, with session support being performed at the server level STUN A.
  • the principle implemented in this embodiment consists in transferring any request requiring a response from a different address to a second server STUN B mono address which is responsible for responding to the client.
  • the principle of obtaining an IP address from a second server is presented.
  • the client C STUN requests (201) the establishment of a session at the server STUN A , which communicates (202) with the server STUN B.
  • This server generates (203) a session from which it sends (204) the elements to STUN A which stores them (205) and furnishes (206) where appropriate a part to CSTUN-
  • CST U N requests (301) a session code from STUNA (through the P NAT elements and from the Internet). To do, the C STUN client sends,
  • STUN A relays (302) the request of the session code to STUN B This operation is performed by the server STUN A which sends a message
  • STUN B generates (303) the access codes and returns them to STUN A. To do this, the STUN server B responds to the STUN server A with a SHARED-SECRET-RESPONSE message including attributes including a username and a password. past ;
  • STUN A stores (304) the access codes (username and password) and sends them to CST U N stuna
  • the server therefore meets the customer CST U N (still TLS) using SHARED-SECRET Message -RESPONSE including attributes including username and password previously stored.
  • This first communication phase makes it possible to establish a secure session between a STUN client C and a STUN server A , which is then considered by the client C STUN as being a genuine STUN server having two IP addresses.
  • a second communication phase according to a first use case that does not require communication between C STUN and STUN B :
  • C STUN wishes to communicate (305) only with STUN A , securely by its session code.
  • the C STUN client sends (via the UDP protocol) a BINDING-REQUEST message to the STUN A server without the CHANGE-REQUEST flag; - STUN A communicates (306) with C STUN to qualify the configuration, securely by its session code.
  • STUN A responds to the client with a BINDING-RESPONSE message by announcing in the CHANGED-ADDRESS attribute the IP address and the STUN port of the STUN B server.
  • CST U N communicates (307) with STUNA to obtain a response from STUNB, securely by its session code.
  • the C STUN client sends (via the UDP protocol) a BINDING-REQUEST message to the STUN A server with the address change flag set
  • STUN A then sends (308) to STUN B the context of its communication with CST U N.
  • the STUNA server transfers the request to STUNB by specifying the address of the client where the response must be made (RESPONSE-ADDRESS then takes the IP address and client port);
  • STUN B uses (309) the session code to communicate with C STUN and qualify the configuration. To do this, the server STUN B (after verifying that the message-integrity is correct) sends the response to the client C STUN - (This from its IP address which is different from that of STUNA).
  • C STUN - This from its IP address which is different from that of STUNA.
  • This embodiment is based on the secret sharing between the STUN server A and the server STUN B and the generation, by this second server STUN B , the access codes necessary for the establishment of the session.
  • Those skilled in the art will have no difficulty in understanding that this implementation allows a recursive allocation of IP addresses. Indeed, if a client requests a server to assign more than two IP addresses, the method according to the invention is able to provide them through the establishment of a new session between for example the server STUN B and another server STUN C adapted to implement the method according to the invention.
  • the client is an entity that solicits resources or information from another entity.
  • the servers STUN A and the server STUN B can quite be also STUN clients.
  • Hardware architecture of the client and the server according to the invention The hardware structure of the client is described, in a very simplified manner, in relation to FIG. 4. It comprises a memory 41, and a processing unit 40 which is equipped with a microprocessor, which is controlled by a computer program (or application) 42, responsible inter alia for the transmission of requests for establishing communication sessions, and requests for data transfer.
  • the processing unit 40 receives as input, via a network input interface module 43, responses to its requests 44, which the microprocessor processes, according to the instructions of the program 42, in response to the requests for establishing the sessions. communication, and data transfer requests 46, which are transmitted via a network output interface module 45.
  • the hardware structure of the server is described, in a very simplified manner, in relation with FIG. 5. It comprises a memory 51, and a processing unit 50 which is equipped with a microprocessor, which is controlled by a computer program ( or application) 52, responsible inter alia for sending requests for establishing communication sessions to a second server, and requests for data transfer, in particular IP addresses.
  • a computer program or application
  • the processing unit 50 receives, via a network input interface module 53, responses to its requests 54, which the microprocessor processes, in accordance with the instructions of the program 52, in response to the requests for establishing the sessions. communication from a client, and data transfer requests 56, which are transmitted via a network output interface module 55.

Landscapes

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

Abstract

L'invention concerne un Procédé de gestion d'une session de transport sécurisée de paquets utilisateurs au travers d'un dispositif de translation d'adresse, entre un terminal client et un premier serveur de gestion de session de transport, ladite session utilisant une première adresse d'émission de paquets et au moins une deuxième adresse d'émission de paquets, distincte de ladite première adresse, Selon l'invention, un tel procédé comprend une étape d'obtention, par ledit premier serveur, de ladite au moins une deuxième adresse d'émission de paquets auprès d'au moins un deuxième serveur de gestion de session de transport, afin que ledit terminal client puisse transférer des paquets à destination dudit premier serveur en utilisant au moins lesdites deux adresses.

Description

Procédé de gestion d'une session de transfert sécurisée au travers d'un dispositif de translation d'adresse, serveur et programme d'ordinateur correspondants.
1 DOMAINE DE L'INVENTION La présente invention se rapporte au domaine des connexions entre des réseaux locaux et des réseaux de communication basés sur le protocole IP. La présente invention se rapporte plus particulièrement à la connexion de réseaux dits « domestiques », intégrant des moyens de communication tels que des ordinateurs, des téléphones mobiles, des consoles multimédia et le réseau Internet, dans le cadre de partage ou d'échange dans des réseaux de pair-à-pair (« peer-to- peer » en anglais).
Au sein des réseaux domestiques, les équipements multimédia communiquent entre eux par le biais d'interfaces réseaux telles que le WiFi, les courants porteurs en ligne (CPL) ou des interfaces ethernet. Ces équipements utilisent ces interfaces pour communiquer par le biais du protocole IP (de l'anglais « Internet Protocol » pour « Protocole Internet »), et chaque équipement du réseau se voit assigner une adresse IP local.
Pour permettre aux équipements du réseau « domestique » d'atteindre l'Internet, un dispositif chargé de faire la liaison entre le réseau local en l'Internet intègre, la plupart du temps, un ou plusieurs dispositifs NAT (de l'anglais « Network Address Translation » pour « Translation d'Adresses Réseau ») qui permettent de « partager » une adresse Internet (IP) publique entre plusieurs équipement du réseau domestique.
2 SOLUTIONS DE L'ART ANTERIEUR 2.1 Art antérieur
Le développement rapide de l'Internet a engendré une pénurie d'adresses
IP. La solution la plus utilisée pour pallier ce problème est l'utilisation de dispositifs NAT. De manière classique, un routeur domestique, telle qu'une STB
(de l'anglais « Set Top Box » pour « Décodeur numérique ») auquel est raccordé le réseau informatique d'une habitation intègre donc un dispositif NAT. Les moyens de communication situés derrière le routeur au sein du réseau local (ou domestique ») sont en « adressage privé » et n'ont pas connaissance a priori du dispositif derrière lequel ils se trouvent, notamment de l'adresse publique utilisée sur Internet pour leurs communications et du type précis comportement NAT utilisé.
Cependant, dans le cadre de certains échanges, notamment ceux de point à point entre deux machines dont au moins une est située derrière un dispositif NAT, au sein d'un réseau local, il peut s'avérer nécessaire pour la machine du réseau local (la machine « cliente »), d'avoir une connaissance de ces informations de connexion avec l'extérieur. De telles informations peuvent être : l'adresse et les ports publics attribués par le NAT, le type de NAT (symétrique, à restriction de port,...) par exemple.
Selon l'art antérieur, un serveur STUN (du nom du protocole normalisé : « Simple Traversai of UDP over NATs » IETF RFC 3489 pour « Protocole simplifié de transfert de datagrammes utilisateurs à travers un système de translation d'adresses sur un réseau ») peut être utilisé pour communiquer, au client du réseau local, l'adresse publique sous laquelle il est vu et le type d'algorithme NAT derrière lequel il est connecté, par l'établissement d'une session de transfert sécurisé. Une telle session s'appuie sur des données de session, parmi lesquelles on trouve deux adresses IP associées au serveur STUN.
L'algorithme STUN appliqué par le client comporte plusieurs tests pour déterminer le type de dispositif NAT. Dans un de ces tests, le client STUN du réseau local va demander au serveur STUN de lui répondre à partir d'une adresse IP différente de celle à partir de laquelle il a répondu jusque là. Ce test à pour objectif de permettre au client, par l'interprétation de la réception ou non d'une réponse à cette requête, de savoir si le dispositif NAT auquel il est raccordé bloque un paquet venant d'une adresse IP avec laquelle il n'a jamais communiqué.
Dans l'état actuel des techniques de l'art antérieur, un serveur STUN doit, pour être capable de répondre à ce type de requête, posséder deux adresses IP différentes. Ainsi, Lorsqu'un client CSTUN veut s'adresser à un serveur STUNA, il commence au préalable par établir une connexion TLS/TCP (connexion cryptée) et envoie sur cette connexion une demande SHARED-SECRET-REQUEST pour échanger un secret partagé. Le serveur STUNA répond par un message SHARED- SECRET-RESPONSE avec en attribut un nom d'utilisateur et un mot de passe. Toutes les requêtes suivantes, émises suivant le protocole UDP (de l'anglais « User Datagram Protocol » pour « Protocole [d'échange] de datagramme utilisateur ») comportent un champ rappelant le nom d'utilisateur et un autre champ d'intégrité de message (« message integrity ») qui constitue une signature du message à l'aide du mot de passe préalablement échangé. Une telle approche permet d'assurer que toutes les requêtes suivantes ont bien été échangées avec le même serveur (la session de communication est donc sécurisée).
A la réception de toute requête STUN de type « Binding-Request », un serveur STUN doit annoncer l'autre adresse qu'il possède (attribut CHANGED- ADDRESS) et à partir de laquelle il est capable de répondre si le client CSTUN lui demande de répondre à partir d'une adresse différente^ (cf. §11.2.3 de la norme RFC 3489 STUN)
2.2 Inconvénients de l'art antérieur
Un problème lié à cette norme survient dans le cadre de déploiements sur des réseaux distribués de type P2P (de l'anglais « peer to peer » pour « pair à pair »). Dans une telle architecture, on souhaite éviter au maximum le nombre de fonctions hébergées sur des serveurs centralisés. A ce titre, l'hébergement de ces fonctions doit être intégré au sein des clients du réseau P2P. Or de tels client ne possèdent généralement qu'une seule adresse IP publique.
Selon les techniques de l'art antérieur et les spécifications du protocole STUN, il est extrêmement difficile de déployer dans le cadre des réseaux P2P, des serveurs STUN tels que décrits par la norme. Ainsi, les fonctions des serveurs STUN sont donc hébergées au sien d'un serveur central.
En effet, la forte pénurie d'adresses IP, due à une croissance extrêmement rapide des demandes d'attribution liées à une forte croissance du nombre de serveurs sur l'Internet, pose problème. Ainsi, il devient difficilement envisageable d'équiper l'ensemble des serveurs STUN domestiques avec deux adresses IP servant uniquement à répondre à des sollicitations de clients souhaitant se connecter en pair à pair.
Un inconvénient corollaire de cette technique de l'art antérieur est la dégradation de la scalabilité des architectures de pair à pair du fait des limitations liées au protocole STUN. 3 RESUME DE L'INVENTION
La solution proposée par l'invention permet notamment de pallier ces inconvénients de l'art antérieur, grâce à un procédé de gestion d'une session de transfert sécurisée de datagrammes utilisateurs au travers d'un dispositif de translation d'adresse, entre un terminal client et un premier serveur de gestion de session de transfert, ladite session contenant une première adresse d'émission de datagrammes et au moins une deuxième adresse d'émission de datagrammes, distincte de ladite première adresse. Selon l'invention, un tel procédé comprend : une étape d'obtention d'au moins une deuxième adresse d'émission de datagrammes auprès d'au moins un deuxième serveur de gestion de session de transfert ; afin que ledit terminal client puisse transférer des datagrammes à destination dudit premier serveur en utilisant au moins lesdites deux adresses.
Ainsi, l'invention repose sur une approche nouvelle et inventive de la gestion des sessions de transfert sécurisé de datagrammes en permettant l'obtention d'adresses IP nécessaires au déroulement de la session de communication auprès d'autres serveurs. La deuxième adresse utilisée dans la session de communication est donc celle d'un deuxième serveur, ce qui permet au premier serveur de ne pas posséder deux adresses et permet de pallier un manque d'adresses IP.
Dans un mode de réalisation particulier de l'invention, ledit procédé comprend les phases suivantes : requête d'ouverture de ladite session de transfert sécurisée émise par ledit terminal client à destination dudit premier serveur ; ouverture de ladite session de transfert sécurisée par ledit premier serveur, engageant ladite étape d'obtention de ladite au moins une deuxième adresse ; maintien de ladite session de transfert par ledit premier serveur, permettant la gestion des transferts en provenance de ladite au moins une deuxième adresse.
Ainsi, la gestion de la session de communication comprend des phases successives permettant l'établissement et le maintien de la session :
Le terminal requiert l'ouverture d'une session vers le premier serveur ;
Le premier serveur engage l'obtention de la deuxième adresse nécessaire à l'exécution de la session auprès d'un deuxième serveur ;
Le premier serveur maintien la session tout le temps nécessaire, permettant ainsi le transfert de données en provenance de la deuxième adresse, et donc du deuxième serveur.
Ces différentes phases de gestion d'une telle session permettent donc d'obtenir la deuxième adresse, de former la session de communication et d'utiliser cette deuxième adresse pour le transfert des données. On économise ainsi des adresses IP, puisque la deuxième adresse provient d'un autre serveur que celui avec lequel le terminal client entre en communication.
Selon un aspect particulier de l'invention, ladite phase d'ouverture de ladite session comprend les étapes suivantes : transfert, par ledit premier serveur, de ladite requête d'ouverture à destination dudit deuxième serveur ; génération de ladite session de transfert par ledit deuxième serveur ; transmission d'au moins une première information représentative de ladite session de transfert audit premier serveur, par ledit deuxième serveur ; stockage, par ledit premier serveur, de ladite au moins une information représentative de ladite session de transfert ; transfert d'au moins une deuxième information représentative de ladite session de transfert audit client, par ledit premier serveur.
Ainsi, l'obtention de la deuxième adresse est réalisée par un enchaînement d'étapes qui sont initiées par le premier serveur. En effet, ce dernier n'ouvre pas la session, mais transmet la requête d'ouverture au deuxième serveur. Ce deuxième serveur ouvre donc une session de communication dont il transmet des informations représentatives au premier serveur afin qu'ils puissent communiquer ensemble par le biais de cette session.
Les informations représentatives transmises peuvent soit contenir la deuxième adresse, soit des informations permettant de prendre connaissance de cette deuxième adresse. Le premier serveur stocke alors l'information représentative de cette session puis il transmet une deuxième information représentative de cette session au client qui a demandé l'ouverture de la session.
Cette deuxième information représentative de la session peut soit contenir l'adresse du deuxième serveur, ou d'autres informations permettant de prendre connaissance de cette deuxième adresse.
Selon un mode de mise en œuvre particulier, que ladite phase de maintien comprend les étapes suivantes : émission, par ledit terminal client, d'une requête de transfert de datagrammes utilisateur utilisant lesdites au moins deux adresses, à destination dudit premier serveur ; transmission de ladite requête de transfert, par ledit premier serveur, à destination dudit deuxième serveur, précisant une adresse de réponse dudit client ; - qualification, par ledit premier serveur, d'une première configuration de communication entre ledit client et ledit premier serveur ; qualification, par ledit deuxième serveur, d'une deuxième configuration de communication entre ledit client et ledit deuxième serveur, utilisant ladite adresse de réponse. Le terminal client, ayant obtenu une seconde adresse de communication par le biais du premier serveur, utilise l'une ou l'autre de ces adresses pour communiquer avec le premier serveur. Le terminal client émet donc une requête à destination du premier serveur en indiquant comme adresse de réponse (l'adresse de réponse est l'adresse en provenance de laquelle il s'attend à recevoir les informations demandées) l'une ou l'autre de ces adresses. Le premier serveur transmet, au deuxième serveur, les requêtes qui sont destinées à ce deuxième serveur.
Le premier serveur qualifie une première configuration de communication avec le client qui permet à celui-ci de communiquer avec le premier serveur. De la même manière, le deuxième serveur qualifie une deuxième configuration de communication avec le client.
Selon un aspect particulier de l'invention, ladite session de transfert comprend au moins un code de session tenant compte d'au moins un des paramètres appartenant au groupe comprenant au moins : une information représentative d'un identifiant d'un utilisateur dudit terminal client ; une information représentative d'un mot de passe d'un utilisateur dudit terminal client. Ainsi, il est possible d'identifier une autorisation d'accès à des services rendus par des serveurs à l'issue de la phase d'établissement de la session de communication.
Selon une caractéristique originale, ledit terminal client, ledit premier et ledit au moins un deuxième serveur respectent le protocole STUN. Le respect du protocole STUN assure que les intervenants dans le procédé de gestion respectent les normes usuelles en vigueur dans l'établissement des sessions de communication à travers les dispositifs de translation d'adresses.
L'invention concerne également serveur de gestion d'une session de transfert sécurisée de datagrammes utilisateurs d'un terminal client, ladite session contenant une première adresse d'émission de datagrammes et au moins une deuxième adresse d'émission de datagrammes, distincte de ladite première adresse,
Selon l'invention, un tel serveur comprend : des moyens d'obtention d'au moins une deuxième adresse d'émission de datagrammes auprès d'au moins un deuxième serveur de gestion de session de transfert ; afin que ledit terminal client puisse transférer des datagrammes à destination dudit premier serveur en utilisant au moins lesdites deux adresses. Selon un aspect original de l'invention, un tel serveur comprend des moyens : d'ouverture de ladite session de transfert sécurisée par ledit premier serveur suite à une requête émise par ledit terminal client, engageant lesdits moyens d'obtention de ladite au moins une deuxième adresse ; - de maintien de ladite session de transfert par ledit premier serveur, permettant la gestion des transferts en provenance de ladite au moins une deuxième adresse.
Selon une caractéristique particulière de l'invention, un tel serveur de gestion respecte le protocole STUN. Dans un autre mode de réalisation, l'invention concerne également un produit programme d'ordinateur téléchargeable depuis un réseau de communication et/ou stocké sur un support lisible par ordinateur et/ou exécutable par un microprocesseur.
Selon l'invention, dans au moins un mode de réalisation, un tel produit programme d'ordinateur comprend des instructions de code de programme pour l'exécution du procédé de gestion d'une session de transfert sécurisée de datagrammes utilisateurs d'un terminal client tel que décrit précédemment. 4 LISTE DES FIGURES
D'autres caractéristiques et avantages de l'invention apparaîtront plus clairement à la lecture de la description suivante d'un mode de réalisation préférentiel, donné à titre de simple exemple illustratif et non limitatif, et des dessins annexés, parmi lesquels : la figure 1 présente un exemple d'architecture d'un réseau local connecté à
Internet et faisant intervenir deux serveur STUN ; - la figure 2 présente le principe d'obtention d'une deuxième adresse d'émission de datagrammes selon l'invention, dans l'architecture présentée dans la figure 1 ; la figure 3 illustre l'établissement d'une session de communication sécurisée en utilisant le protocole STUN dans l'architecture de la figure 1 ; - la figure 4 présente une architecture matérielle simplifiée d'un client
STUN ; la figure 5 présente une architecture matérielle simplifiée d'un serveur
STUN selon l'invention.
5 DESCRIPTION DETAILLEE DE L'INVENTION 5.1 Rappel du principe de l'invention
L'invention propose donc de substituer l'utilisation d'un serveur STUN possédant deux adresses IP, par l'utilisation de serveurs STUN ne possédant qu'une seule adresse IP. Ainsi, l'invention permet de déployer des applications de pair à pair à grande échelle. Le principe général de l'invention repose sur une mise en œuvre nouvelle et inventive des spécifications du protocole STUN. En effet, l'invention ne nécessite pas de modification du protocole STUN existant. Elle se base sur une nouvelle implémentation de ce protocole. Ainsi, on peut déployer de nombreux serveurs STUN, sans que ces derniers soient dans l'obligation de posséder deux adresses IP différentes. L'invention va donc à contre courant des techniques de l'art antérieur qui se contentent de ne pas délocaliser les fonctionnalités liées au serveur STUN.
Par la suite, on présente notamment le cas d'une mise en œuvre de serveur
STUN selon l'invention dans un réseau local de type « domestique » relié à l'Internet par le biais d'un routeur domestique. Il est clair cependant que l'invention ne se limite pas à cette application particulière, mais peut également être mise en œuvre dans de nombreux autres domaines, et par exemple dans toute application où l'on souhaite déployer des serveurs STUN sans que l'on souhaite que ceux-ci possèdes plusieurs adresses et plus généralement dans tous les cas où les caractéristiques listés par la suite sont intéressants.
On précise que le terme « client » doit être compris ici et dans la suite de l'exposé comme désignant une entité qui sollicite les ressources d'une autre entité pour exécuter une tâche, un client pouvant être matérialisé par un serveur autonome, par un groupe de serveurs ou par divers éléments séparément répartis au sein de divers moyens de communication inclus dans le système. Ainsi, à un instant donné, un client STUN qui requiert l'établissement d'une session de transfert sécurisé à un serveur STUN peut également jouer le rôle de serveur STUN pour un autre client demandant également l'établissement d'une autre session de transfert sécurisé. 5.2 Description d'un mode de réalisation
On présente dans ce mode de réalisation, en relation avec la figure 1, la mise en œuvre de deux serveurs STUNA et STUNB selon l'invention. Chacun de ces deux serveurs possède une adresse IP. Ils sont situés à l'extérieur du réseau local (LOCN) de l'utilisateur et sont accessibles par le biais du réseau Internet (INet) Un client STUN CSTUN est situé au sein d'un réseau local. Il peut s'agir d'un ordinateur personnel, d'un téléphone mobile ou d'un autre équipement multimédia disposant d'une interface réseau lui permettant de se connecter à ce réseau local. Ce client CSTUN communique sur Internet par le biais d'une passerelle de translation d'adresse NAT PNAT- Les serveurs STUNA et STUNB sont aptes à gérer une session de transfert sécurisée de datagrammes utilisateurs selon l'invention.
Dans ce mode de réalisation de l'invention, la solution proposée consiste à utiliser deux serveurs STUN mono adresse pour honorer ce type de requête. Toutefois, ceci est transparent du point de vue du client CSTUN qui peut rester standard, la prise en charge de la session étant effectuée au niveau du serveur STUNA. Le principe mis en oeuvre dans ce mode de réalisation consiste à transférer toute requête nécessitant une réponse provenant d'une adresse différente, à un second serveur STUNB mono adresse qui se charge de répondre au client. On présente, en relation avec la figure 2, le principe d'obtention d'une adresse IP en provenance d'un deuxième serveur. Le client CSTUN demande (201) l'établissement d'une session au serveur STUNA, lequel communique (202) avec le serveur STUNB. Ce serveur génère (203) un session dont il fait parvenir (204) les éléments à STUNA qui les stocke (205) et en fournit (206) la cas échéant une partie à CSTUN-
On présente, en relation avec la figure 3, l'enchaînement des opérations menant à l'établissement d'une session de transfert sécurisé selon l'invention. Dans une première phase d'initialisation :
CSTUN demande (301) un code de session auprès de STUNA (à travers les éléments PNAT et du réseau Internet). Pour de faire, le client CSTUN envoie,
(en TLS, c'est-à-dire de manière cryptée, sécurisée, pour que le mot de passe ne circule pas en clair sur le réseau) un message SHARED-SECRET- REQUEST au serveur STUN STUNA ;
STUNA relaie (302) la demande du code de session à STUNB Cette opération est réalisée par le serveur STUNA qui envoie un message
SHARED-SECRET-REQUEST au serveur STUN STUNB ; STUNB génère (303) les codes d'accès et les renvoie à STUNA Pour ce faire le serveur STUNB répond au serveur STUNA avec un message SHARED- SECRET-RESPONSE comprenant des attributs comprenant un nom d'utilisateur et un mot de passe ;
STUNA stocke (304) les codes d'accès (nom d'utilisateur et mot de passe) et les envoie à CSTUN Le serveur STUNA répond donc au client CSTUN (toujours en TLS) en utilisant un message SHARED-SECRET-RESPONSE comprenant des attributs comprenant le nom d'utilisateur et le mot de passe précédemment stocké. Cette première phase de communication permet d'établir une session sécurisée entre un client CSTUN et un serveur STUNA, lequel est considéré alors par le client CSTUN comme étant un authentique serveur STUN possédant deux adresses IP. Dans une deuxième phase de communication, selon un premier cas d'utilisation ne nécessitant pas de communication entre CSTUN et STUNB :
CSTUN souhaite communiquer (305) uniquement avec STUNA, de manière sécurisée par son code de session. Le client CSTUN envoie (par le biais du protocole UDP) un message BINDING-REQUEST au serveur STUNA sans le flag de changement d'adresse positionné (CHANGE-REQUEST) ; - STUNA communique (306) avec CSTUN pour qualifier la configuration, de manière sécurisée par son code de session. Pour ce faire, STUNA répond au client par un message BINDING-RESPONSE en annonçant dans l'attribut CHANGED-ADDRESS l'adresse IP et le port STUN du serveur STUNB.
Dans une deuxième phase de communication, selon un deuxième cas d'utilisation, dans lequel le client CSTUN souhaite obtenir une réponse de la part du serveur sur une nouvelle adresse IP :
CSTUN communique (307) avec STUNA pour obtenir une réponse de STUNB, de manière sécurisée par son code de session. Pour se faire, Le client CSTUN envoie (par le biais du protocole UDP) un message BINDING-REQUEST au serveur STUNA avec le flag de changement d'adresse positionné
(CHANGE-REQUEST) ;
STUNA envoie alors (308) à STUNB le contexte de sa communication avec CSTUN. Ainsi, le serveur STUNA transfert la requête à STUNB en précisant l'adresse du client où doit être faite la réponse (RESPONSE-ADDRESS prend alors l'adresse IP et port du client) ;
STUNB utilise (309) le code de session pour communiquer avec CSTUN et qualifier la configuration. Pour ce faire, le serveur STUNB (après avoir vérifié que le message-integrity est correct) envoie la réponse au client CSTUN- (Ceci à partir de son adresse IP qui est donc différente de celle de STUNA). Ainsi, selon l'invention, il a été possible d'établir une session sécurisée entre un client CSTUN et un serveur STUNA ne possédant qu'une seule adresse IP tout en respectant les normes d'échange du protocole STUN. Du point de vu du client CSTUN, tout s'est passé comme si il n'y avait qu'un serveur possédant deux adresses IP différentes.
Ce mode de réalisation se base sur le partage de secret entre le serveur STUNA et le serveur STUNB et la génération, par ce deuxième serveur STUNB, des codes d'accès nécessaires à l'établissement de la session. L'homme du métier n'aura aucune difficulté à comprendre que cette mise en oeuvre permet une allocation récursive d'adresses IP. En effet, si un client demande à un serveur l'attribution de plus de deux adresses IP, le procédé selon l'invention est apte à les lui fournir par le biais de l'établissement d'une nouvelle session entre par exemple le serveur STUNB et un autre serveur STUNC apte à mettre en oeuvre le procédé selon l'invention. De plus, comme il a déjà été indiqué, le client est une entité qui sollicite des ressources ou des informations à une autre entité. Ainsi, les serveurs STUNA et le serveur STUNB peuvent tout à fait être également des clients STUN.
Il est également possible d'appliquer ce principe d'attribution délocalisé à de nombreux autres domaines que celui de l'établissement de session au travers de NAT en utilisant le protocole STUN. En effet, l'homme du métier n'aura aucune difficulté à mettre en œuvre ce procédé pour la gestion de toute session de communication sécurisée qui nécessite l'utilisation de deux adresses IP différentes pour un même serveur.
5.3 Architecture matérielle du client et du serveur selon l'invention La structure matérielle du client est décrite, de manière très simplifiée, en relation avec la figure 4. Elle comprend une mémoire 41, et une unité de traitement 40 laquelle est équipée d'un microprocesseur, qui est piloté par un programme d'ordinateur (ou application) 42, chargée entre autre de l'émission des requêtes d'établissement des sessions de communication, et des requêtes de transfert de données. L'unité de traitement 40 reçoit en entrée, via un module d'interface d'entrée réseau 43, des réponses à ses requêtes 44, que le microprocesseur traite, selon les instructions du programme 42, en réponse aux requêtes d'établissement des sessions de communication, et des requêtes de transfert de données 46, qui sont transmises via un module d'interface de sortie réseau 45.
La structure matérielle du serveur est décrite, de manière très simplifiée, en relation avec la figure 5. Elle comprend une mémoire 51, et une unité de traitement 50 laquelle est équipée d'un microprocesseur, qui est piloté par un programme d'ordinateur (ou application) 52, chargée entre autre de l'émission des requêtes d'établissement des sessions de communication à destination d'un deuxième serveur, et des requêtes de transfert de données, notamment des adresses IP.
L'unité de traitement 50 reçoit en entrée, via un module d'interface d'entrée réseau 53, des réponses à ses requêtes 54, que le microprocesseur traite, selon les instructions du programme 52, en réponse aux requêtes d'établissement des sessions de communication en provenance d'un client, et des requêtes de transfert de données 56, qui sont transmises via un module d'interface de sortie réseau 55.

Claims

REVENDICATIONS
1. Procédé de gestion d'une session de transport sécurisée de paquets utilisateurs au travers d'un dispositif de translation d'adresse, entre un terminal client et un premier serveur de gestion de session de transport, ladite session utilisant une première adresse d'émission de paquets et au moins une deuxième adresse d'émission de paquets, distincte de ladite première adresse, caractérisé en ce qu'il comprend : une étape d'obtention, par ledit premier serveur, de ladite au moins une deuxième adresse d'émission de paquets auprès d'au moins un deuxième serveur de gestion de session de transport, afin que ledit terminal client puisse transférer des paquets à destination dudit premier serveur en utilisant au moins lesdites deux adresses.
2. Procédé de gestion selon la revendication 1, caractérisé en ce qu'il comprend les phases suivantes : requête d'ouverture de ladite session de transport sécurisée émise par ledit terminal client à destination dudit premier serveur ; ouverture de ladite session de transport sécurisée par ledit premier serveur, engageant ladite étape d'obtention de ladite au moins une deuxième adresse ; maintien de ladite session de transport par ledit premier serveur, permettant la gestion des transports en provenance de ladite au moins une deuxième adresse.
3. Procédé de gestion selon la revendication 2, caractérisé en ce ladite phase d'ouverture de ladite session comprend les étapes suivantes : transport, par ledit premier serveur, de ladite requête d'ouverture à destination dudit deuxième serveur ; génération de ladite session de transport par ledit deuxième serveur ; transmission d'au moins une première information représentative de ladite session de transport audit premier serveur, par ledit deuxième serveur ; stockage, par ledit premier serveur, de ladite au moins une information représentative de ladite session de transport ; transport d'au moins une deuxième information représentative de ladite session de transport audit client, par ledit premier serveur.
4. Procédé de gestion selon l'une quelconque des revendications 2 et 3, caractérisé en ce que ladite phase de maintien comprend les étapes suivantes : émission, par ledit terminal client, d'une requête de transport de paquets utilisateur utilisant lesdites au moins deux adresses, à destination dudit premier serveur ; transmission de ladite requête de transport, par ledit premier serveur, à destination dudit deuxième serveur, précisant une adresse de réponse dudit client ; qualification, par ledit premier serveur, d'une première configuration de communication entre ledit client et ledit premier serveur ; qualification, par ledit deuxième serveur, d'une deuxième configuration de communication entre ledit client et ledit deuxième serveur, utilisant ladite adresse de réponse.
5. Procédé de gestion selon l'une quelconque des revendications 1 à 4, caractérisé en ce que ladite session de transport comprend au moins un code de session tenant compte d'au moins un des paramètres appartenant au groupe comprenant au moins : une information représentative d'un identifiant d'un utilisateur dudit terminal client ; - une information représentative d'un mot de passe d'un utilisateur dudit terminal client.
6. Procédé de gestion selon l'une quelconque des revendications 1 à 5, caractérisé en ce que ledit terminal client, ledit premier et ledit au moins un deuxième serveur respectent le protocole STUN.
7. Serveur de gestion d'une session de transport sécurisée de paquets utilisateurs d'un terminal client, ladite session contenant une première adresse d'émission de paquets et au moins une deuxième adresse d'émission de paquets, distincte de ladite première adresse, caractérisé en ce qu'il comprend : - des moyens d'obtention d'au moins une deuxième adresse d'émission de paquets auprès d'au moins un deuxième serveur de gestion de session de transport ; afin que ledit terminal client puisse transférer des paquets à destination dudit premier serveur en utilisant au moins lesdites deux adresses.
8. Serveur de gestion selon la revendication 7, caractérisé en ce qu'il comprend des moyens : d'ouverture de ladite session de transport sécurisée par ledit premier serveur suite à une requête émise par ledit terminal client, engageant lesdits moyens d'obtention de ladite au moins une deuxième adresse ; - de maintien de ladite session de transport par ledit premier serveur, permettant la gestion des transports en provenance de ladite au moins une deuxième adresse ;
9. Serveur de gestion selon l'une quelconque des revendications 7 et 8, caractérisé en ce qu'il respecte le protocole STUN 10. Produit programme d'ordinateur téléchargeable depuis un réseau de communication et/ou stocké sur un support lisible par ordinateur et/ou exécutable par un microprocesseur, caractérisé en ce qu'il comprend des instructions de code de programme pour l'exécution du procédé de production selon l'une au moins des revendications 1 à 6, lorsqu'il est exécuté sur un ordinateur.
EP07786843A 2006-08-22 2007-06-26 Procédé de gestion d'une session de transfert sécurisée au travers d'un dispositif de translation d'adresse, serveur et programme d'ordinateur correspondants Withdrawn EP2055082A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR0607449 2006-08-22
PCT/EP2007/056362 WO2008022829A1 (fr) 2006-08-22 2007-06-26 Procédé de gestion d'une session de transfert sécurisée au travers d'un dispositif de translation d'adresse, serveur et programme d'ordinateur correspondants

Publications (1)

Publication Number Publication Date
EP2055082A1 true EP2055082A1 (fr) 2009-05-06

Family

ID=37719418

Family Applications (1)

Application Number Title Priority Date Filing Date
EP07786843A Withdrawn EP2055082A1 (fr) 2006-08-22 2007-06-26 Procédé de gestion d'une session de transfert sécurisée au travers d'un dispositif de translation d'adresse, serveur et programme d'ordinateur correspondants

Country Status (3)

Country Link
US (1) US9413590B2 (fr)
EP (1) EP2055082A1 (fr)
WO (1) WO2008022829A1 (fr)

Families Citing this family (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP3472978B1 (fr) 2016-06-21 2021-12-15 Oracle International Corporation Sessioniseur de système de messagerie interactive en langage naturel hébergé par le nuage internet
US10491547B2 (en) 2016-06-21 2019-11-26 Oracle International Corporation Internet cloud-hosted natural language interactive messaging system user resolver
JP6999580B2 (ja) 2016-06-21 2022-01-18 オラクル・インターナショナル・コーポレイション インターネットクラウドでホストされる自然言語による対話型メッセージングシステムサーバ連携
US11240179B2 (en) 2016-09-16 2022-02-01 Oracle International Corporation Internet cloud-hosted natural language interactive messaging system with virtual database
CN109600671B (zh) * 2018-12-13 2021-02-19 四川九州电子科技股份有限公司 一种网络机顶盒快速升级的系统及其方法
CN112543239B (zh) * 2020-12-23 2022-06-24 杭州安司源科技有限公司 一种递进式nat穿透方法
US11924288B2 (en) * 2020-12-30 2024-03-05 Arris Enterprises Llc Methods and systems for transferring a user session between devices

Family Cites Families (24)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6615357B1 (en) * 1999-01-29 2003-09-02 International Business Machines Corporation System and method for network address translation integration with IP security
US7441270B1 (en) * 2000-07-06 2008-10-21 Intel Corporation Connectivity in the presence of barriers
US7302496B1 (en) * 2002-11-12 2007-11-27 Cisco Technology, Inc. Arrangement for discovering a localized IP address realm between two endpoints
US7899932B2 (en) * 2003-01-15 2011-03-01 Panasonic Corporation Relayed network address translator (NAT) traversal
US8539552B1 (en) * 2003-09-25 2013-09-17 Hewlett-Packard Development Company, L.P. System and method for network based policy enforcement of intelligent-client features
US7643412B1 (en) * 2003-10-30 2010-01-05 Nortel Networks Limited Media proxy able to detect blocking
TWI257217B (en) * 2003-11-10 2006-06-21 Inst Information Industry Method to detect the form of network address translation
CN100399768C (zh) * 2003-12-24 2008-07-02 华为技术有限公司 实现网络地址转换穿越的方法、系统
US7457293B2 (en) * 2004-04-05 2008-11-25 Panasonic Corporation Communication apparatus, method and program for realizing P2P communication
US8089972B2 (en) * 2004-05-03 2012-01-03 Level 3 Communications, Llc Registration redirect server
EP1613024A1 (fr) * 2004-06-29 2006-01-04 Alcatel Alsthom Compagnie Generale D'electricite Méthode et serveur d'appel pour établir un lien de communication bidirectionnel d'égal à égal
US7706401B2 (en) * 2004-08-13 2010-04-27 Verizon Business Global Llc Method and system for providing interdomain traversal in support of packetized voice transmissions
US8838771B2 (en) * 2004-09-27 2014-09-16 Alcatel Lucent Enabling VoIP calls to be initiated when a call server is unavailable
US7543064B2 (en) * 2004-09-30 2009-06-02 Logitech Europe S.A. Multiplayer peer-to-peer connection across firewalls and network address translators using a single local port on the local host
US7483393B2 (en) * 2004-12-07 2009-01-27 Cisco Technology, Inc. Method and apparatus for discovering internet addresses
US8713132B2 (en) * 2005-03-16 2014-04-29 Icontrol Networks, Inc. Device for data routing in networks
US7515549B2 (en) * 2005-06-07 2009-04-07 Cisco Technology, Inc. Managing devices across NAT boundaries
US20070011731A1 (en) * 2005-06-30 2007-01-11 Nokia Corporation Method, system & computer program product for discovering characteristics of middleboxes
US7983254B2 (en) * 2005-07-20 2011-07-19 Verizon Business Global Llc Method and system for securing real-time media streams in support of interdomain traversal
US20070022289A1 (en) * 2005-07-20 2007-01-25 Mci, Inc. Method and system for providing secure credential storage to support interdomain traversal
US8019986B2 (en) * 2005-08-12 2011-09-13 Comcast Cable Holdings, Llc Method and system for booting, provisioning and activating hardware and software clients
US20070264989A1 (en) * 2005-10-03 2007-11-15 Rajesh Palakkal Rendezvous calling systems and methods therefor
US20070153812A1 (en) * 2005-12-29 2007-07-05 John Kemp Dynamic discovery of a network service on a mobile device
US20070253418A1 (en) * 2006-04-27 2007-11-01 D.S.P. Group Ltd. Routing path optimization between sip endpoints

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See references of WO2008022829A1 *

Also Published As

Publication number Publication date
US20100131631A1 (en) 2010-05-27
US9413590B2 (en) 2016-08-09
WO2008022829A1 (fr) 2008-02-28

Similar Documents

Publication Publication Date Title
JP7125788B2 (ja) プロキシを用いてセキュアデバイスとアンセキュアデバイスとの間を通信するシステム及び方法
EP2055082A1 (fr) Procédé de gestion d'une session de transfert sécurisée au travers d'un dispositif de translation d'adresse, serveur et programme d'ordinateur correspondants
FR2922706A1 (fr) Procede de traversee d'equipement de traduction d'adresses pour messages de signalisation sip par utilisation temporaire du protocole de transport tcp
EP1994724A2 (fr) Procede et systeme de caracterisation de noeuds de communication heterogenes
EP3476108B1 (fr) Procédé, programme d'ordinateur et dispositif de fourniture d'une adresse par un dispositif à gérer d'un réseau
EP2210396A1 (fr) Système d'interconnexion entre au moins un appareil de communication et au moins un système d'information distant et procédé d'interconnexion
EP2543165B1 (fr) Pilotage d'un dispositif d'un reseau distant a partir d'un reseau local
EP3619908A1 (fr) Technique d'exécution d'un service dans un réseau local à travers un réseau de communication étendu
EP4449678A1 (fr) Mécanismes de communication avec un service accessible via un réseau de télécommunication prenant en compte la mobilité des services, des utilisateurs et des équipements
EP3506555B1 (fr) Procede de securisation de bout en bout d'une communication interceptable
FR3063858A1 (fr) Procede de communication pour assurer le maintien d'une session applicative entre un terminal et un serveur d'application
FR2928802A1 (fr) Partage de contenu multi supports a partir d'une communication audio-video
EP2504957B1 (fr) Acces a un contenu reference par un serveur de contenu
EP3235217A1 (fr) Procédé d'échanges de données entre deux navigateurs internet, équipement de routage, terminal, programme d'ordinateur et support d'informations corespondants
EP1432213B1 (fr) Plate-forme de médiation et réseau de transport de messages
FR2837045A1 (fr) SYSTEME ET PROCEDE DE GESTION DE TRANSFERT D'INFORMATIONS SUR UN RESEAU CONFORME A UNE NORME DE TRANSMISSION DE DONNEES, NOTAMMENT LA NORME UPnP, MACHINE D'INTERFACAGE ET D'EMULATION ET PROGRAMME D'ORDINATEUR CORRESPONDANTS
FR3021477A1 (fr) Telechargement de contenu et mise a disposition de reseaux de telecommunications etendus en vue d'un tel telechargement.
FR3061385A1 (fr) Dispositif d'acces securise
EP4736371A1 (fr) Procédés de protection d'un équipement et de transmission de données, dispositifs et ensemble électroniques, produits programmes d'ordinateur et supports d'information correspondants
EP3149902A1 (fr) Technique d'obtention d'une politique de routage de requêtes émises par un module logiciel s'exécutant sur un dispositif client
WO2011121236A1 (fr) Procede et dispositif de notification d'un terminal dans un reseau
FR2919140A1 (fr) Procede d'echange de messages entre serveur de donnees de session et services clients
FR2915651A1 (fr) Procede pour assurer la continuite d'un flux d'une pression media entre deux terminaux d'un reseau ims
EP2469768A1 (fr) Procédé d'interfaçage de dispositifs UPnP
EP3360293A1 (fr) Moyens de gestion d'accès à des données

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20090202

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IS IT LI LT LU LV MC MT NL PL PT RO SE SI SK TR

AX Request for extension of the european patent

Extension state: AL BA HR MK RS

RIN1 Information on inventor provided before grant (corrected)

Inventor name: GORGES, DIDIER

Inventor name: BREARD, GAEL

Inventor name: BAILLY, MARC

RIN1 Information on inventor provided before grant (corrected)

Inventor name: BAILLY, MARC

Inventor name: GORGES, DIDIER

Inventor name: BREARD, GAEL

DAX Request for extension of the european patent (deleted)
RAP1 Party data changed (applicant data changed or rights of an application transferred)

Owner name: ORANGE

17Q First examination report despatched

Effective date: 20161201

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20170412