WO2017098171A1 - Procede de controle de messages de recommandation dans un reseau de communication - Google Patents

Procede de controle de messages de recommandation dans un reseau de communication Download PDF

Info

Publication number
WO2017098171A1
WO2017098171A1 PCT/FR2016/053286 FR2016053286W WO2017098171A1 WO 2017098171 A1 WO2017098171 A1 WO 2017098171A1 FR 2016053286 W FR2016053286 W FR 2016053286W WO 2017098171 A1 WO2017098171 A1 WO 2017098171A1
Authority
WO
WIPO (PCT)
Prior art keywords
entity
connectivity request
request
connectivity
endpoint
Prior art date
Application number
PCT/FR2016/053286
Other languages
English (en)
Inventor
Ewa JANCZUKOWICZ
Xavier Marjou
Gaël FROMENTOUX
Original Assignee
Orange
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 Orange filed Critical Orange
Publication of WO2017098171A1 publication Critical patent/WO2017098171A1/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066—Session management
    • H04L65/1069—Session establishment or de-establishment
    • 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/2564—NAT traversal for a higher-layer protocol, e.g. for session initiation protocol [SIP]
    • 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/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
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066—Session management
    • H04L65/1073—Registration or de-registration
    • 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/2514—Translation of Internet protocol [IP] addresses between local and global IP addresses

Definitions

  • the invention lies in the field of telecommunication networks, and more particularly relates to a method of controlling a communication between two web browsers.
  • WebRTC for "Web Real-Time Communication” technology, currently being defined by the W3C (for “World Wide Web Consortium") standardization bodies, IETF (for "Internet Engineering Task Force") and 3GPP (for "3rd Generation Partnership Project”), allows real-time communications between web browsers, or more generally between two endpoints.
  • W3C for "World Wide Web Consortium" standardization bodies
  • IETF for "Internet Engineering Task Force”
  • 3GPP for "3rd Generation Partnership Project”
  • ICE for "Interactive Connectivity Establishment”
  • the connection between endpoints is established by signaling messages exchanged via a web server of a service provider.
  • the ICE protocol offers three distinct connection modes:
  • STUN Session Traversai Utilities
  • NAT Network Address Translation
  • a TURN server is a media relay located between two endpoints, relaying data packets from media streams issued by one endpoint to another endpoint.
  • the ICE protocol thus makes it possible to discover candidate media addresses that can be used to receive a medium.
  • the calling endpoint When establishing the connection between two endpoints, the calling endpoint discovers candidate addresses and then forwards them to the called endpoint via an SDP offer (for "Session" Description Protocol ").
  • the called endpoint upon receipt of the SDP offer, in turn, discovers candidate addresses and communicates them to the calling endpoint via an SDP response.
  • the service provider's web server used to establish the connection between the endpoints does not have visibility into the pair of addresses that will ultimately be retained for the subsequent exchange of media streams.
  • the choice of an address pair associated with the calling and called endpoints is performed by the calling endpoint.
  • the candidate address discovery mechanism suffers from disadvantages. It is particularly likely to give rise to unwanted exposure to third parties of private information (local IP addresses, confidential information relating to a user, etc.). To remedy this, a proposal entitled “New Proposals for IP Address Handling in WebRTC" within the IETF dated 19 April 2015 proposes to statically limit the candidate addresses retrieved by the ICE discovery mechanism. This solution also requires the use of a TURN server and / or the use of a VPN address (for "Virtual Private Network") associated with an endpoint instead of the own IP address of the endpoint. However, in the case where an endpoint is not trusted, the traffic is likely to be diverted to an unauthorized TURN server. Similarly, the VPN address associated with an endpoint may be of a confidential nature and its communication to a third party may not be desired.
  • One of the aims of the invention is to remedy the shortcomings / disadvantages of the state of the art and / or to make improvements thereto.
  • the invention relates to a method for controlling, in a communication network, at least one connectivity request for establishing a real-time exchange web session of at least one media stream. between a calling endpoint and a called endpoint, comprising:
  • the control method thus ensures that the connectivity request is not transmitted to a malicious third party.
  • the method makes it possible, for example, to avoid sending the request to a foreign network or to a TURN server not approved by the communication network operator.
  • the method can also advantageously be used within a local area network (an enterprise network for example) in order to implement restrictions on undesired uses within this network.
  • the method can for example be used to prohibit the use of peer-to-peer communications between equipment of the local network and equipment outside the network.
  • the method notably makes it possible to secure exchanges during a real-time exchange web session (eg WebRTC session) between two endpoints, by ensuring that the information exchanged during the establishment of the session is not known. network entities approved by the communication network operator.
  • a real-time exchange web session eg WebRTC session
  • the method furthermore comprises, when the connectivity request is not verified to be destined for a reputable trusted entity, sending a notification to the calling endpoint, the notification allowing the calling party to obtain identification information relating to the recipient entity of the connectivity request.
  • the control method thus ensures that the connectivity request is not transmitted to a malicious third party without the knowledge of a user of the calling endpoint.
  • the user of the calling endpoint is notably informed of any transmission to a suspicious entity via the received notification.
  • the received notification not only informs a routing of the connectivity request to unauthorized entities, but also allows a user of the calling endpoint to identify such unauthorized entities using the information of identification to which the notification gives access.
  • the notification is sent by means of an ICMP type Internet control message protocol.
  • An ICMP type Internet control message protocol advantageously makes it possible to transmit an HTTP (for "Hyper Text Transfer Protocol") link to the calling endpoint.
  • a user of the calling endpoint can then use for example his browser to open such a link and be offered various information and / or measures relating to the detected routing of the connectivity request to an unauthorized entity.
  • the method furthermore comprises, when the connectivity request, called the initial request, is not verified to be intended for an authorized entity, a inhibiting the sending of subsequent connectivity requests to the destination entity of the initial request.
  • Inhibiting the sending of subsequent connectivity requests to an unauthorized entity can stop the leakage of confidential information to that entity.
  • the method furthermore comprises, when the connectivity request is not verified to be destined for an authorized entity, a substitution in the connectivity request of the public address associated with the calling endpoint by a substitution address.
  • the method allows substituting the public address associated with the endpoint with a substitution address to preserve its anonymity with the unauthorized entity, and more generally with the called endpoint and network entities on a network path between the calling endpoint and the called endpoint.
  • This substitution makes it possible in particular to keep the confidentiality of a VPN address used as a public address by a calling endpoint.
  • the verification that the connectivity request is intended for an authorized entity consists of searching for a membership of the destination address of the connectivity request to a list of addresses of at least one reputed entity of trusted by the communications network operator.
  • the invention also relates to a control system, in a communication network, of at least one connectivity request for establishing a real-time exchange web session of at least one stream. media between a calling endpoint and a called endpoint.
  • the system includes:
  • endpoints each include:
  • a obtaining module arranged to obtain at least one pair of candidate addresses associated with the endpoints
  • a verification module arranged to verify by means of a connectivity request, that the at least one pair of candidate addresses obtained is capable of establishing the session between the endpoints;
  • control entity comprising a verification module, arranged to verify that the connectivity request is intended for a reputable trusted entity approved by a communication network operator.
  • control entity further comprises a sending module, arranged to send a notification to the calling endpoint, the notification enabling the caller to obtain identification information relating to the caller. entity receiving the connectivity request.
  • control system further comprises an address verification entity arranged to provide the control entity with information identifying the recipient entity of the connectivity request, and when the connectivity request, said initial request, is not verified to be to a reputable trusted entity, to control the control entity an inhibition of the sending of subsequent connectivity requests to the destination entity of the initial request.
  • control method according to the first aspect can be transposed directly to the control system according to the second aspect.
  • the invention also relates to a program comprising program code instructions for controlling the execution of the steps of the method described above, when said program is executed on a computer and a computer readable recording medium on which is recorded a computer program comprising program code instructions for performing the steps of the previously described method.
  • FIG. 1 shows a control system of at least one connectivity request according to a particular embodiment
  • FIG. 2 represents a flowchart of the control method, and exchanges between equipment implementing the method, according to a particular embodiment.
  • FIG. 1 represents a system 500 for controlling at least one connectivity request in a first communication network 1 according to a particular embodiment.
  • the system 500 comprises a calling endpoint 10a, a called endpoint 10b and a control entity 20.
  • the system 500 allows the establishment of a session between the calling endpoint 10a and the called endpoint 10b. .
  • the end points 10a-b are for example client applications (e.g. browser) installed on a user terminal (e.g. computer, mobile phone, tablet), or on a device to connect to the Internet.
  • the calling end points 10a and 10b communicate with each other via a TURN server 50 located in a second communication network 2.
  • the endpoints 10a-b each comprise a obtaining module 110 arranged to obtain the less a pair of candidate addresses associated with them, and a verification module 120 arranged to verify by means of a connectivity request, that this at least one pair of candidate addresses obtained is able to establish a web session real-time exchanges of at least one media stream between the endpoints 10a-b.
  • the control entity 20 makes it possible to filter STUN messages exchanged between the end points 10a-b and the TURN server 50.
  • the control entity 20 is located on a network path between the calling endpoint 10a and the entity 50.
  • the controlling entity 20 includes a verification module 210 which is activated when a pair of candidate addresses suitable for the establishment of an exchange web session between the endpoints 10a-ba was obtained by them.
  • the verification module 210 is furthermore arranged to verify that a connectivity request is intended for a reputable trusted entity approved by the operator of the communication network 1.
  • the control entity 20 is a dedicated equipment. In another embodiment, this entity may advantageously be integrated in a network equipment 1 such as a router.
  • the control entity 20 makes it possible in particular to determine whether a STUN message sent to a TURN server leaves the network 1. More generally, the control entity 20 makes it possible to verify that a connectivity request, as well as the traffic transmitted by the point in the session resulting from this connectivity request is sent to an entity approved by the communication network operator 1. As an example, in the embodiment described with reference to FIG. , it is assumed that the server TURN 50 belongs to a communication network 2 not approved by the operator of the communication network 1. The control entity 20 then makes it possible to protect, thanks to a control method which will be described later in relation with FIG. 2, the termination point 10a of a possible diversion of the information transmitted by the latter to the communication network 2.
  • control entity further comprises a sending module 220, arranged to send a notification to the calling endpoint 10a.
  • This notification allows the caller to obtain credentials for the recipient entity of a connectivity request.
  • control system 500 also comprises an address verification entity (not shown in FIG. 1) arranged to provide the control entity 20 with identification information relating to the destination entity. the connectivity request.
  • the address verification entity is further arranged to, when this initial connectivity request is not verified to be to a reputable trusted entity, to control the control entity 20 an inhibition of the sending of requests subsequent connectivity to the destination entity of the initial connectivity request.
  • the system 500 includes a domain name server.
  • the control entity 20 queries the domain name server to determine, for example, whether the destination address of the connectivity request belongs to a trusted domain approved by the communication network operator 1.
  • the system 500 may also be implemented to control the traffic transmitted by the called endpoint 10b, and thus achieve a bidirectional control, flows from the calling endpoint 10a to the endpoint called 10b, and flows from the called endpoint 10b to the calling endpoint 10a.
  • FIG. 2 represents a flowchart of the control method, and exchanges between equipment implementing the method, according to a particular embodiment.
  • six entities intervene: a calling endpoint 10a, a called endpoint 10b, a control entity 20, an IP telephony service provider entity 30, a TURN server 50 and a Address Verification Entity 40.
  • the control entity 20, the address verification entity 40 and the TURN server 50 are trusted entities approved by an operator of a communication network RI.
  • the PI phase corresponds to an exchange of signaling messages for the purpose of establishing a call between the calling end points 10a and 10b. These exchanges are said to be made in a "signaling plan".
  • the PI phase comprises the steps E1 to E4.
  • Phase P2 corresponds to exchanges occurring as soon as the connection between the calling end points 10a and 10b is established.
  • Phase P2 comprises steps E5 to E16. It is assumed that the calling endpoint 10a wishes, for example, to communicate with the called endpoint 10b via a provider of an IP telephony service.
  • the calling endpoint 10a sends a signaling message (eg a Session Initiation Protocol (SIP) session control message including a Session Description Protocol (SDP) offer to the point termination called 10b.
  • SIP Session Initiation Protocol
  • SDP Session Description Protocol
  • This message is intended to establish a WebRTC communication session between the calling endpoint 10a and the called endpoint 10b.
  • the SDP offer contains as example four candidate addresses al, a2, a3 and a4 for joining the calling endpoint 10a.
  • the addresses al, a2, a3 and a4 are (still by way of example) defined for respectively allowing the transport of audio streams via the UDP protocol (for "User Datagram Protocol"), video streams via the UDP protocol, stream audio via TCP (for Transmission Control Protocol), and video streams via TCP.
  • UDP protocol for "User Datagram Protocol”
  • TCP for Transmission Control Protocol
  • a step E2 the SIP session control message is relayed by the entity of the IP telephony service provider to the called endpoint 10b.
  • the called endpoint 10b responds to the SDP offer by sending a signaling message (e.g. SIP response message) comprising an SDP response with candidate addresses to join it.
  • a signaling message e.g. SIP response message
  • the SDP response contains 2 candidate addresses bl and b2.
  • the addresses bl and b2 are (still by way of example) defined respectively to allow the transport of video streams via the TCP protocol and audio streams via the UDP protocol.
  • a step E4 the SIP response message is relayed by the IP telephony service provider entity 30 to the calling endpoint 10a.
  • each endpoint has a complete list of its candidate addresses and those of the endpoint with which it wishes to establish a communication.
  • Each endpoint then associates its candidate addresses with those of the endpoint with which the communication is desired to form homogeneous candidate address pairs from the point of view of the protocol used and the type of stream to which they are intended.
  • the endpoints 10a and 10b obtain two pairs of addresses (al; b2) and (a4; b1) respectively for the transport of audio streams via the UDP protocol and video streams via the TCP protocol.
  • the calling endpoints 10a and 10b implement a so-called connectivity check procedure (or "connectivity check") as defined in RFC 5245.
  • connectivity check procedure or "connectivity check”
  • each endpoint sends a connectivity verification request to the other endpoint, and responds to the verification request it receives from this other endpoint.
  • the verification request is more precisely a STUN request "Binding Request" as defined in the document RFC 5389.
  • STUN request "Binding Request" as defined in the document RFC 5389.
  • steps E5 and E6 respectively correspond to the sending by the called endpoint 10b of a STUN request "Binding Request" to the calling endpoint 10a, and to the sending by the calling endpoint 10a of a STUN request "Binding Request" at the endpoint called 10b.
  • the (al; b2) and (a4; bl) address pairs are assumed to be valid candidate address pairs upon completion of the connectivity verification procedure.
  • the control entity 20 analyzes the STUN request "Binding Request" sent by the calling endpoint 10a to the called endpoint 10b.
  • the analysis of the request is for example carried out using a technique called “Deep Packet Inspection” (or DPI).
  • DPI Deep Packet Inspection
  • the analysis performed by the control entity 20 consists more particularly of a destination address extraction A of the STUN request "Binding Request", then a verification that this destination address A refers to a reputable trusted entity by the operator of the communication network RI.
  • a step E8 to verify that the destination address A refers to a reputable trusted entity approved by the communication operator RI, the control entity 20 interrogates the address verification entity 40 of the operator of the communication network RI.
  • the address verification entity 40 then verifies that the address of the destination entity of the connectivity request does not belong to a list of unauthorized addresses by the operator of the communication network RI (by means of example of a list of unauthorized addresses stored locally, or by querying a remote database) and / or that the destination entity of the connectivity request is not localized for example in a foreign network.
  • the verification entity 40 solicits a domain name repository via, for example, a DNS query (for "Domain Name Server") or a WHOIS request as defined in the RFC 3912 document.
  • address 40 obtains identification information relating to the destination entity of the STUN connectivity request "Binding Request". This information includes the name of the owner of the domain name as well as the country of location of the entity referenced by this domain name.
  • the connectivity request is simply passed to its recipient.
  • the control entity 20 sends during a step E10, a notification to the calling endpoint 10a.
  • the notification more particularly contains an HTTP link allowing the caller to obtain the credentials relating to the recipient entity of the connectivity request and to access different options relating to the current WebRTC session or to other subsequent sessions (these options will be detailed later in connection with the steps El i to El 6).
  • the notification is sent using an Internet Control Message Protocol (ICMP).
  • ICMP Internet Control Message Protocol
  • the user of the calling endpoint is thus informed that his request is directed to an entity not authorized by the operator of the communication network RI (eg a TURN server destination of the connectivity request located in a non-authorized communication network R2 by the operator of the communication network RI).
  • an entity not authorized by the operator of the communication network RI eg a TURN server destination of the connectivity request located in a non-authorized communication network R2 by the operator of the communication network RI.
  • the user of the calling endpoint 10a opens the HTTP link received in step E10.
  • the HTTP link is for example a web service provided by the address verification entity 40.
  • the web service responds to the calling endpoint 10a by transmitting to it various possible actions relating to the identified routing of the connectivity request to the server not authorized by the operator of the communication network RI.
  • the various options offered by the web service are, for example: an inhibition of the sending of subsequent requests for connectivity to the unauthorized server, a substitution in the connectivity request of the public address associated with the calling endpoint 10a by an address substitution, a redirection to a TURN 50 server approved by the operator of the IN communication network, or the possibility of authorizing transmission to the unauthorized TURN server.
  • a step E13 the user of the endpoint 10a communicates the option he has chosen to the address verification entity 40.
  • the address verification entity 40 transmits the option chosen by the user to the control entity 20.
  • control entity 20 stores the chosen option and intercepts the next connectivity requests sent by the calling endpoint 10a in order to redirect them during a step E16 to the TURN 50 server authorized by the operator of the communication network RI.
  • control entity 20 searches for a membership of the destination address of the connectivity request. to a list of addresses of at least one reputable trusted entity approved by the operator of the communication network RI.
  • the invention can easily be adapted to any type of protocol for providing and obtaining candidate addresses.
  • the present embodiment has moreover been described with an implementation of the method for an IP telephony service.
  • the type of service may be a videoconferencing application, messaging application, or any application more generally offering a service linking two endpoints.
  • the invention is implemented by means of software and / or hardware components.
  • the term "module" may correspond in this document to both a software component, a hardware component or a set of hardware and / or software components, capable of implementing a function or a set of functions, as described above for the module concerned.
  • a software component corresponds to one or more computer programs, one or more subroutines of a program, or more generally to any element of a program or software.
  • Such a software component is stored in memory and then loaded and executed by a data processor of a physical entity and is able to access the hardware resources of this physical entity (memories, recording media, communication buses, electronic cards of a physical entity). input / output, user interfaces, etc.).
  • a material component corresponds to any element of a material set (or hardware). It may be a programmable hardware component or not, with or without an integrated processor for running software. This is for example an integrated circuit, a smart card, an electronic card for executing a firmware, etc.
  • the modules 110, 120, 210 and 220 are arranged to implement the previously described control method.
  • These are preferably software modules comprising software instructions for executing those of the steps of the previously described control method, implemented by a control entity and an endpoint.
  • the invention therefore also relates to:
  • a program for a control entity for controlling a connectivity request comprising program code instructions for controlling the execution of the steps of the previously described control method, when said program is executed by said entity;
  • a program for an endpoint comprising program code instructions for controlling the execution of the steps of the previously described control method, when said program is executed by said endpoint;
  • the software modules can be stored in or transmitted by a data carrier.
  • a data carrier This may be a hardware storage medium, for example a CD-ROM, a magnetic diskette or a hard disk, or a transmission medium such as an electrical signal, optical or radio, or a telecommunications network.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Business, Economics & Management (AREA)
  • General Business, Economics & Management (AREA)
  • Multimedia (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

Procédé de contrôle, dans un réseau de communication, d'au moins une requête de connectivité pour l'établissement d'une session web d'échanges en temps réel d'au moins un flux média entre un point de terminaison appelant et un point de terminaison appelé, comprenant : - obtention d'au moins une paire d'adresses candidates associées auxdits points de terminaison; - vérification, au moyen d'une requête de connectivité, que ladite au moins une paire d'adresses candidates obtenue est apte à établir ladite session entre lesdits points de terminaison; - vérification que ladite requête de connectivité est en outre à destination d'une entité réputée de confiance agréée par un opérateur de réseaux de communication. Figure pour l'abrégé: figure

Description

Procédé de contrôle de messages de recommandation dans un réseau de
communication
L'invention se situe dans le domaine des réseaux de télécommunication, et concerne plus particulièrement un procédé de contrôle d'une communication entre deux navigateurs web.
La technologie WebRTC (pour « Web Real-Time Communication »), actuellement en cours de définition au sein des organismes de normalisation W3C (pour « World Wide Web Consortium »), IETF (pour « Internet Engineering Task Force ») et 3GPP (pour « 3rd Génération Partnership Project »), permet des communications en temps réel entre navigateurs web, ou plus généralement entre deux points de terminaison. Afin d'établir une connexion entre deux points de terminaison et permettre un échange de flux média (e.g. flux vidéo, audio, VoIP pour « Voice over Internet Protocol », flux de partage de fichiers) entre ces derniers, la technologie WebRTC utilise le protocole ICE (pour « Interactive Connectivity Establishment »). Selon ce protocole, la connexion entre points de terminaison est établie par des messages de signalisation échangés par l'intermédiaire d'un serveur web d'un fournisseur de service. Le protocole ICE offre trois modes de connexion distincts :
Connexion média directe : ce mode de connexion est possible lorsque les adresses (e.g. adresses IP pour « Internet Protocol ») des points de terminaison sont connues. Les flux média sont alors directement échangées entre points de terminaison ;
- Connexion via un serveur dit STUN (pour « Session Traversai Utilities for
NAT ») : ce mode de connexion est utilisé lorsqu'une technique de translation d'adresses réseau, connu également sous l'acronyme NAT (pour « Network Address Translation »), est mise en œuvre et que les adresses publiques des points de terminaison ne peuvent être obtenues directement. Un serveur STUN est alors utilisé par les points de terminaison pour découvrir leurs adresses publiques. Il est à noter qu'un tel serveur STUN intervient uniquement lors de l'établissement de la communication entre points de terminaison, mais qu'il n'intervient pas par la suite dans les échanges de flux média entre points de terminaison. Un serveur STUN peut en outre être un équipement dédié, ou directement intégré dans, par exemple, un navigateur web ;
Connexion via un serveur TURN (pour « Traversai Using Relays around NAT ») : ce mode de connexion est généralement utilisé lorsqu' aucune connexion directe entre points de terminaison n'est possible pour l'échange de flux média. Un serveur TURN est un relais média localisé entre deux points de terminaison, relayant les paquets de données des flux média émis par un point de terminaison à destination d'un autre point de terminaison.
Le protocole ICE permet ainsi de découvrir des adresses média candidates susceptibles de pouvoir être utilisées pour recevoir un média. Lors de l'établissement de la connexion entre deux points de terminaison, le point de terminaison appelant découvre des adresses candidates, puis les transmet au point de terminaison appelé par l'intermédiaire d'une offre SDP (pour « Session Description Protocol »). Le point de terminaison appelé, à réception de l'offre SDP, découvre à son tour des adresses candidates et les communique au point de terminaison appelant par l'intermédiaire d'une réponse SDP. Le serveur web du fournisseur de service servant à établir la connexion entre les points de terminaison n'a pas de visibilité sur la paire d'adresses qui sera finalement retenue pour l'échange ultérieur de flux média. Le choix d'une paire d'adresses associée aux points de terminaison appelant et appelé est opéré par le point de terminaison appelant. Tel que défini dans le document de l'IETF « Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translater (NAT) Traversai for Offer/Answer Protocols », daté d'avril 2010, lorsque plusieurs couples d'adresses candidates existent, la communication est prioritairement établie avec des adresses candidates permettant une connexion directe entre points de terminaison, puis avec des adresses candidates permettant une connexion ne nécessitant pas de serveur TURN, et en dernier lieu avec des adresses candidates nécessitant un serveur TURN pour la connexion.
Le mécanisme de découverte d'adresses candidates souffre d'inconvénients. Il est en particulier susceptible de donner lieu à une exposition non souhaitée à des tiers d'informations privées (adresses locales IP, informations confidentielles relatives à un utilisateur, etc.). Pour remédier à cela, une proposition intitulée « New proposai for IP address handling in WebRTC » au sein de l'IETF datant du 19 avril 2015, propose de limiter statiquement les adresses candidates récupérées par le mécanisme de découverte ICE. Cette solution impose en outre le recours à un serveur TURN et/ou l'utilisation d'une adresse VPN (pour « Virtual Private Network ») associée à un point de terminaison à la place de l'adresse IP propre du point de terminaison. Or dans le cas où un point de terminaison n'est pas de confiance, le trafic est susceptible d'être détourné vers un serveur TURN non agréé. De même l'adresse VPN associée à un point de terminaison peut revêtir un caractère confidentiel et sa communication à un tiers ne pas être souhaitée.
Un des buts de l'invention est de remédier à des insuffisances/inconvénients de l'état de la technique et/ou d'y apporter des améliorations.
Selon un premier aspect, l'invention concerne un procédé de contrôle, dans un réseau de communication, d'au moins une requête de connectivité pour l'établissement d'une session web d'échanges en temps réel d'au moins un flux média entre un point de terminaison appelant et un point de terminaison appelé, comprenant :
- obtention d'au moins une paire d'adresses candidates associées aux points de terminaison ;
- vérification, au moyen d'une requête de connectivité, que la au moins une paire d'adresses candidates obtenue est apte à établir la session entre les points de terminaison ;
- vérification que la requête de connectivité est en outre à destination d'une entité réputée de confiance agréée par un opérateur de réseaux de communication.
Le procédé de contrôle permet ainsi de s'assurer que la requête de connectivité n'est pas transmise vers un tiers malveillant. Le procédé permet par exemple d'éviter un envoi de la requête vers un réseau étranger ou vers un serveur TURN non agréé par l'opérateur de réseaux de communication.
Le procédé peut également avantageusement être utilisé au sein d'un réseau local (un réseau d'entreprise par exemple) afin de mettre en œuvre des restrictions quant à des usages non souhaités au sein de ce réseau. Le procédé peut par exemple être utilisé pour interdire l'utilisation de communications pair à pair entre des équipements du réseau local et des équipements extérieurs à ce réseau.
Le procédé permet notamment de sécuriser les échanges lors d'une session web d'échanges en temps réel (e.g. session WebRTC) entre deux points de terminaison, en veillant à ce que les informations échangées lors de l'établissement de la session ne soient connues que d'entités du réseau agréées par l'opérateur de réseaux de communication.
Selon une caractéristique particulière, le procédé comprend en outre, lorsque la requête de connectivité n'est pas vérifiée être à destination d'une entité réputée de confiance, un envoi d'une notification à destination du point de terminaison appelant, la notification permettant à l'appelant d'obtenir des informations d'identification relatives à l'entité destinataire de la requête de connectivité.
Le procédé de contrôle permet ainsi de s'assurer que la requête de connectivité n'est pas transmise vers un tiers malveillant à l'insu d'un utilisateur du point de terminaison appelant.
L'utilisateur du point de terminaison appelant est notamment informé de toute transmission vers une entité suspecte par l'intermédiaire de la notification reçue.
En outre la notification reçue permet non seulement d'informer d'un routage de la requête de connectivité vers des entités non agréées, mais permet également à un utilisateur du point de terminaison appelant d'identifier de telles entités non agréées grâce aux informations d'identification auxquelles donne accès la notification.
II est également noté que ces informations ne sont pas directement transmises avec la notification afin de ne pas accroître les quantités de données transmises sur le réseau. Le procédé n'engendre donc qu'un trafic supplémentaire très modéré.
Selon une caractéristique particulière, la notification est envoyée au moyen d'un protocole de message de contrôle Internet de type ICMP.
Un protocole de message de contrôle Internet de type ICMP permet avantageusement de transmettre un lien HTTP (pour « Hyper Text Transfer Protocol ») au point de terminaison appelant.
Un utilisateur du point de terminaison appelant peut alors utiliser par exemple son navigateur pour ouvrir un tel lien et se voir proposer différentes informations et/ou mesures relatives au routage détecté de la requête de connectivité vers une entité non agréée.
Selon une caractéristique particulière, le procédé comprend en outre, lorsque la requête de connectivité, dite requête initiale, n'est pas vérifiée être à destination d'une entité agréée, une inhibition des envois de requêtes ultérieures de connectivité à destination de l'entité destinataire de la requête initiale.
L'inhibition des envois de requêtes ultérieures de connectivité vers d'une entité qui n'est pas agréée permet de faire cesser les fuites d'informations confidentielles vers cette entité.
Selon une caractéristique particulière, le procédé comprend en outre, lorsque la requête de connectivité n'est pas vérifiée être à destination d'une entité agréée, une substitution dans la requête de connectivité, de l'adresse publique associée au point de terminaison appelant par une adresse de substitution.
Le procédé permet en substituant l'adresse publique associée au point de terminaison par une adresse de substitution de préserver son anonymat auprès de l'entité non agréée, et plus généralement auprès du point de terminaison appelé et des entités réseau sur un chemin réseau entre le point de terminaison appelant et le point de terminaison appelé.
Cette substitution permet en particulier de conserver la confidentialité d'une adresse VPN utilisée en tant qu'adresse publique par un point de terminaison appelant.
Selon une caractéristique particulière, la vérification que la requête de connectivité est à destination d'une entité agréée consiste à rechercher une appartenance de l'adresse de destination de la requête de connectivité à une liste d'adresses d'au moins une entité réputée de confiance agréée par l'opérateur de réseaux de communication.
Selon un deuxième aspect, l'invention concerne également un système de contrôle, dans un réseau de communication, d'au moins une requête de connectivité pour l'établissement d'une session web d'échanges en temps réel d'au moins un flux média entre un point de terminaison appelant et un point de terminaison appelé. Le système comprend :
- les points de terminaison appelant et appelé, ces points de terminaison comprenant chacun :
- un module d'obtention, agencé pour obtenir au moins une paire d'adresses candidates associées aux points de terminaison ;
- un module de vérification, agencé pour vérifier au moyen d'une requête de connectivité, que la au moins une paire d'adresses candidates obtenue est apte à établir la session entre les points de terminaison ; et
- une entité de contrôle, comprenant un module de vérification, agencé pour vérifier que la requête de connectivité est à destination d'une entité réputée de confiance agréée par un opérateur de réseaux de communication.
Selon une caractéristique particulière, l'entité de contrôle comprend en outre un module d'envoi, agencé pour envoyer une notification à destination du point de terminaison appelant, la notification permettant à l'appelant d'obtenir des informations d'identification relatives à l'entité destinataire de la requête de connectivité.
Selon une caractéristique particulière, le système de contrôle comprend en outre une entité de vérification d'adresses agencée pour fournir à l'entité de contrôle des informations d'identification relatives à l'entité destinataire de la requête de connectivité, et lorsque la requête de connectivité, dite requête initiale, n'est pas vérifiée être à destination d'une entité réputée de confiance, pour commander à l'entité de contrôle une inhibition des envois de requêtes ultérieures de connectivité à destination de l'entité destinataire de la requête initiale.
Les avantages énoncés pour le procédé de contrôle selon le premier aspect sont transposables directement au système de contrôle selon le deuxième aspect.
Selon un troisième aspect, l'invention concerne également un programme comprenant des instructions de code de programme destinées à commander l'exécution des étapes du procédé précédemment décrit, lorsque ledit programme est exécuté sur ordinateur et un support d'enregistrement lisible par ordinateur sur lequel est enregistré un programme d'ordinateur comprenant des instructions de code de programme pour l'exécution des étapes du procédé précédemment décrit.
L'invention sera mieux comprise à l'aide de la description suivante de modes de réalisation particuliers, en référence aux dessins annexés sur lesquels :
- la figure 1 représente un système de contrôle d'au moins une requête de connectivité selon un mode particulier de réalisation ;
- la figure 2 représente un organigramme du procédé de contrôle, et des échanges entre équipements mettant en œuvre le procédé, selon un mode particulier de réalisation. La figure 1 représente un système 500 de contrôle d'au moins une requête de connectivité dans un premier réseau de communication 1 selon un mode particulier de réalisation. Le système 500 comprend un point de terminaison appelant 10a, un point de terminaison appelé 10b et une entité de contrôle 20. Le système 500 permet notamment l'établissement d'une session entre le point de terminaison appelant 10a et le point de terminaison appelé 10b.
Les points de terminaison lOa-b sont à titre d'exemple des applications clientes (e.g. navigateur) installées sur un terminal utilisateur (e.g. ordinateur, téléphone portable, tablette), ou encore sur un équipement permettant de se connecter à l'Internet. Les points de terminaison appelant 10a et appelé 10b communiquent entre eux par l'intermédiaire d'un serveur TURN 50 localisé dans un deuxième réseau de communication 2. Les points de terminaison lOa-b comprennent chacun un module d'obtention 110 agencé pour obtenir au moins une paire d'adresses candidates qui leur sont associées, ainsi qu'un module de vérification 120 agencé pour vérifier au moyen d'une requête de connectivité, que cette au moins une paire d'adresses candidates obtenue est apte à établir une session web d'échanges en temps réel d'au moins un flux média entre les points de terminaison lOa-b.
L'entité de contrôle 20 permet de filtrer des messages STUN échangés entre les points de terminaison lOa-b et le serveur TURN 50. L'entité de contrôle 20 est localisée sur un chemin réseau entre le point de terminaison appelant 10a et l'entité de contrôle 50. L'entité de contrôle 20 comprend notamment un module de vérification 210 qui est activé lorsqu'une paire d'adresses candidates apte à l'établissement d'une session web d'échange entre les points de terminaison 10a- b a été obtenue par ces derniers. Le module de vérification 210 est par ailleurs agencé pour vérifier qu'une requête de connectivité est à destination d'une entité réputée de confiance agréée par l'opérateur du réseau de communication 1. Dans le mode de réalisation représenté en relation avec la figure 1, l'entité de contrôle 20 est un équipement dédié. Dans un autre mode de réalisation, cette entité peut avantageusement être intégrée dans un équipement du réseau 1 tel qu'un routeur. L'entité de contrôle 20 permet notamment de déterminer si un message STUN émis vers un serveur TURN sort du réseau 1. Plus généralement l'entité de contrôle 20 permet de vérifier qu'une requête de connectivité, ainsi que le trafic émis par le point de terminaison 10a au sein de la session résultant de cette requête de connectivité est à destination d'une entité agrée par l'opérateur de réseau de communication 1. A titre d'exemple, dans le mode de réalisation décrit en relation avec la figure 1, on suppose que le serveur TURN 50 appartient à un réseau de communication 2 non agréé par l'opérateur du réseau de communication 1. L'entité de contrôle 20 permet alors de prémunir, grâce à un procédé de contrôle qui sera ultérieurement décrit en relation avec la figure 2, le point de terminaison 10a d'un détournement éventuel des informations transmises par ce dernier au réseau de communication 2.
Dans un autre mode de réalisation, l'entité de contrôle comprend en outre un module d'envoi 220, agencé pour envoyer une notification à destination du point de terminaison appelant 10a. Cette notification permet à l'appelant d'obtenir des informations d'identification relatives à l'entité destinataire d'une requête de connectivité.
Dans un autre mode de réalisation, le système 500 de contrôle comprend également une entité de vérification d'adresses (non représentée sur la figure 1) agencée pour fournir à l'entité de contrôle 20 des informations d'identification relatives à l'entité destinataire de la requête de connectivité. L'entité de vérification d'adresses est en outre agencée pour, lorsque cette requête de connectivité initiale n'est pas vérifiée être à destination d'une entité réputée de confiance, commander à l'entité de contrôle 20 une inhibition des envois de requêtes ultérieures de connectivité à destination de l'entité destinataire de la requête de connectivité initiale.
Dans un autre mode de réalisation, le système 500 comprend un serveur de nom de domaine. L'entité de contrôle 20 interroge alors le serveur de nom de domaine afin de déterminer par exemple si l'adresse de destination de la requête de connectivité appartient à un domaine de confiance agréé par l'opérateur de réseau de communication 1.
Dans un autre mode de réalisation, le système 500 peut également être mis en œuvre pour contrôler le trafic émis par le point de terminaison appelé 10b, et ainsi réaliser un contrôle bidirectionnel, des flux émis du point de terminaison appelant 10a vers le point de terminaison appelé 10b, et des flux émis du point de terminaison appelé 10b vers le point de terminaison appelant 10a. La figure 2 représente un organigramme du procédé de contrôle, et des échanges entre équipements mettant en œuvre le procédé, selon un mode particulier de réalisation. Dans le mode de réalisation présenté, six entités interviennent : un point de terminaison appelant 10a, un point de terminaison appelé 10b, une entité de contrôle 20, une entité 30 d'un fournisseur de service de téléphonie IP, un serveur TURN 50 et une entité de vérification d'adresses 40. L'entité de contrôle 20, l'entité de vérification d'adresses 40 et le serveur TURN 50 sont des entités de confiance agréées par un opérateur d'un réseau de communication RI.
Deux phases PI et P2 sont par ailleurs décrites. La phase PI correspond à un échange de messages de signalisation ayant pour objet d'établir un appel entre les points de terminaison appelant 10a et appelé 10b. Ces échanges sont dits être faits dans un « plan de signalisation ». La phase PI comprend les étapes El à E4. La phase P2 correspond à des échanges intervenant dès l'établissement de la connexion entre les points de terminaison appelant 10a et appelé 10b. La phase P2 comprend les étapes E5 à E16. On suppose que le point de terminaison appelant 10a souhaite par exemple communiquer avec le point de terminaison appelé 10b via un fournisseur d'un service de téléphonie IP.
Lors d'une étape El, le point de terminaison appelant 10a envoie un message de signalisation (e.g. un message de contrôle de session SIP pour « Session Initiation Protocol ») comprenant une offre SDP (pour « Session Description Protocol ») à destination du point de terminaison appelé 10b. Ce message a pour but d'établir une session de communication WebRTC entre le point de terminaison appelant 10a et le point de terminaison appelé 10b. L'offre SDP contient à titre d'exemple quatre adresses candidates al, a2, a3 et a4 permettant de joindre le point de terminaison appelant 10a. Les adresses al, a2, a3 et a4 sont (toujours à titre d'exemple) définies pour respectivement permettre le transport de flux audio via le protocole UDP (pour « User Datagram Protocol »), de flux vidéo via le protocole UDP, de flux audio via le protocole TCP (pour « Transmission Control Protocol »), et de flux vidéo via le protocole TCP.
Lors d'une étape E2, le message de contrôle de session SIP est relayé par l'entité 30 du fournisseur du service de téléphonie IP auprès du point de terminaison appelé 10b.
Lors d'une étape E3, le point de terminaison appelé 10b répond à l'offre SDP en envoyant un message de signalisation (e.g. message de réponse SIP) comprenant une réponse SDP avec des adresses candidates permettant de le joindre. A titre d'exemple, la réponse SDP contient 2 adresses candidates bl et b2. Les adresses bl et b2 sont (toujours à titre d'exemple) définies pour respectivement permettre le transport de flux vidéo via le protocole TCP et de flux audio via le protocole UDP.
Lors d'une étape E4, le message de réponse SIP est relayé par l'entité 30 du fournisseur du service de téléphonie IP auprès du point de terminaison appelant 10a. A l'issue de l'étape E4, chaque point de terminaison dispose d'une liste complète de ses adresses candidates et de celles du point de terminaison avec lequel il souhaite établir une communication. Chaque point de terminaison associe alors ses adresses candidates à celles du point de terminaison avec lequel la communication est souhaitée pour former des paires d'adresses candidates homogènes du point de vue du protocole utilisé et du type de flux auquel elles se destinent. A titre d'exemple, les points de terminaison 10a et 10b obtiennent deux paires d'adresses (al ; b2) et (a4 ; bl) pour respectivement le transport de flux audio via le protocole UDP et de flux vidéo via le protocole TCP.
Lors des étapes E5 et E6, les point de terminaison appelant 10a et appelé 10b mettent en œuvre une procédure dite de vérification de connectivité (ou « connectivity check » en anglais) telle que définie dans le document RFC 5245. Selon cette procédure de vérification, pour chaque paire d'adresses candidates visant à établir une session entre deux points de terminaison pl et p2, chaque point de terminaison envoie une requête de vérification de connectivité à l'autre point de terminaison, et répond à la requête de vérification qu'il reçoit de cet autre point de terminaison. La requête de vérification est plus précisément une requête STUN « Binding Request » telle que définie dans le document RFC 5389. Afin de ne pas alourdir la figure 2, seules les requêtes STUN de vérification de connectivité intervenant dans la procédure de vérification sont représentées. Les réponses à ces requêtes ne sont pas représentées. Ainsi les étapes E5 et E6 correspondent respectivement à l'envoi par le point de terminaison appelé 10b d'une requête STUN « Binding Request » au point de terminaison appelant 10a, et à l'envoi par le point de terminaison appelant 10a d'une requête STUN « Binding Request » au point de terminaison appelé 10b. Les paires d'adresses (al ; b2) et (a4 ; bl) sont supposées être des paires d'adresses candidates valides à l'issue de la procédure de vérification de connectivité.
Lors d'une étape E7, l'entité de contrôle 20 analyse la requête STUN « Binding Request » émise par le point de terminaison appelant 10a à destination du point de terminaison appelé 10b. L'analyse de la requête est par exemple réalisée à l'aide d'une technique dite « d'inspection des paquets en profondeur » (ou DPI en anglais pour « Deep Packet Inspection »). L'analyse réalisée par l'entité de contrôle 20 consiste plus particulièrement en une extraction de adresse de destination A de la requête STUN « Binding Request », puis en une vérification que cette adresse de destination A fait référence à une entité réputée de confiance agréée par l'opérateur du réseau de communication RI.
Lors d'une étape E8, pour vérifier que l'adresse de destination A fait référence à une entité réputée de confiance agréée par l'opérateur de communication RI, l'entité de contrôle 20 interroge l'entité de vérification d'adresses 40 de l'opérateur du réseau de communication RI. L'entité de vérification d'adresses 40 vérifie alors que l'adresse de l'entité destinataire de la requête de connectivité n'appartient pas à une liste d'adresses non autorisées par l'opérateur du réseau de communication RI (au moyen par exemple d'une liste d'adresses non autorisées mémorisée localement, ou encore par interrogation d'une base de données distante) et/ou que l'entité destinataire de la requête de connectivité n'est pas localisée par exemple dans un réseau étranger. Pour cela, l'entité 40 de vérification sollicite un référentiel de noms de domaine via par exemple une requête DNS (pour « Domain Name Server ») ou encore une requête WHOIS telle que définie dans le document RFC 3912. L'entité de vérification d'adresses 40 obtient des informations d'identification relatives à l'entité destinataire de la requête de connectivité STUN « Binding Request ». Ces informations comprennent notamment le nom du propriétaire du nom de domaine ainsi que le pays de localisation de l'entité référencée par ce nom de domaine.
Si l'adresse de l'entité destinataire de la requête de connectivité n'appartient pas à une liste d'adresses non autorisées par l'opérateur du réseau de communication RI et/ou que l'entité destinataire de la requête de connectivité n'est pas localisée dans un réseau étranger, la requête de connectivité est simplement transmise à son destinataire. Dans le cas contraire, l'entité de contrôle 20 envoie lors d'une étape E10, une notification à destination du point de terminaison appelant 10a. La notification contient plus particulièrement un lien HTTP permettant à l'appelant d'obtenir les informations d'identification relatives à l'entité destinataire de la requête de connectivité et d'accéder à différentes options relatives à la session WebRTC en cours ou à d'autres sessions ultérieures (ces options seront détaillées ultérieurement en relation avec les étapes El i à El 6). La notification est envoyée au moyen d'un protocole de message de contrôle Internet de type ICMP (pour « Internet Control Message Protocol »). L'utilisateur du point de terminaison appelant est ainsi informé que sa requête est orientée vers une entité non agréée par l'opérateur du réseau de communication RI (e.g. un serveur TURN destinataire de la requête de connectivité localisé dans un réseau de communication R2 non agréé par l'opérateur du réseau de communication RI).
Lors d'une étape El i, l'utilisateur du point de terminaison appelant 10a ouvre le lien HTTP reçu à l'étape E10. Le lien HTTP est par exemple un service web fourni par l'entité de vérification d'adresses 40.
Lors d'une étape E12, le service web répond au point de terminaison appelant 10a en lui transmettant différentes actions possibles relatives au routage identifié de la requête de connectivité vers le serveur non agréé par l'opérateur du réseau de communication RI. Les différentes options proposées par le service web sont par exemple : une inhibition des envois de requêtes ultérieures de connectivité à destination du serveur non agréé, une substitution dans la requête de connectivité de l'adresse publique associée au point de terminaison appelant 10a par une adresse de substitution, une redirection vers un serveur TURN 50 agréé par l'opérateur du réseau de communication RI, ou encore la possibilité d' autoriser les émissions vers le serveur TURN non agréé.
Lors d'une étape E13, l'utilisateur du point de terminaison 10a communique l'option qu'il a choisie à l'entité de vérification d'adresses 40. Dans le présent mode de réalisation, on suppose à titre d'exemple que l'utilisateur a choisi de rediriger la requête de connectivité vers le serveur agréé TURN 50. Lors d'une étape E14, l'entité de vérification d'adresses 40 transmet l'option choisie par l'utilisateur à l'entité de contrôle 20.
Lors d'une étape E15, l'entité de contrôle 20 mémorise l'option choisie et intercepte les prochaines requêtes de connectivité émises par le point de terminaison appelant 10a afin de les rediriger lors d'une étape E16 vers le serveur TURN 50 agréé par l'opérateur du réseau de communication RI.
Dans un autre mode de réalisation, lors des étapes E7 et E8, pour déterminer que la requête de connectivité est à destination d'une entité agréée, l'entité de contrôle 20 recherche une appartenance de l'adresse de destination de la requête de connectivité à une liste d'adresses d'au moins une entité réputée de confiance agréée par l'opérateur du réseau de communication RI.
Il n'existe cependant par ailleurs aucune limitation quant au protocole de signalisation mis en œuvre lors de la phase Pl. L'invention peut aisément être adaptée à tout type de protocole permettant de fournir et obtenir des adresses candidates.
Le présent mode de réalisation a par ailleurs été décrit avec une mise en œuvre du procédé pour un service de téléphonie IP. Il n'existe cependant aucune limitation quant au type de service auquel s'applique le procédé. Il peut à titre d'exemple s'agir d'une application de visioconférence, de messagerie, ou encore de toute application offrant plus généralement un service mettant en relation deux points de terminaison. L'invention est mise en œuvre au moyen de composants logiciels et/ou matériels. Dans cette optique, le terme "module" peut correspondre dans ce document aussi bien à un composant logiciel, qu'à un composant matériel ou à un ensemble de composants matériels et/ou logiciels, apte à mettre en œuvre une fonction ou un ensemble de fonctions, selon ce qui est décrit précédemment pour le module concerné.
Un composant logiciel correspond à un ou plusieurs programmes d'ordinateur, un ou plusieurs sous-programmes d'un programme, ou de manière plus générale à tout élément d'un programme ou d'un logiciel. Un tel composant logiciel est stocké en mémoire puis chargé et exécuté par un processeur de données d'une entité physique et est susceptible d'accéder aux ressources matérielles de cette entité physique (mémoires, supports d'enregistrement, bus de communication, cartes électroniques d'entrées/sorties, interfaces utilisateur, etc).
De la même manière, un composant matériel correspond à tout élément d'un ensemble matériel (ou hardware). Il peut s'agir d'un composant matériel programmable ou non, avec ou sans processeur intégré pour l'exécution de logiciel. Il s'agit par exemple d'un circuit intégré, d'une carte à puce, d'une carte électronique pour l'exécution d'un micrologiciel (firmware), etc.
Dans un mode de réalisation particulier, les modules 110, 120, 210 et 220 sont agencés pour mettre en œuvre le procédé de contrôle précédemment décrit. Il s'agit de préférence de modules logiciels comprenant des instructions logicielles pour faire exécuter celles des étapes du procédé de contrôle précédemment décrit, mises en œuvre par une entité de contrôle et par un point de terminaison. L'invention concerne donc aussi :
- un programme pour une entité de contrôle pour contrôler une requête de connectivité, comprenant des instructions de code de programme destinées à commander l'exécution des étapes du procédé de contrôle précédemment décrit, lorsque ledit programme est exécuté par ladite entité ;
- un programme pour un point de terminaison, comprenant des instructions de code de programme destinées à commander l'exécution des étapes du procédé de contrôle précédemment décrit, lorsque ledit programme est exécuté par ledit point de terminaison ;
- un support d'enregistrement lisible par une entité de contrôle sur laquelle est enregistré le programme pour une telle entité.
- un support d'enregistrement lisible par un point de terminaison sur lequel est enregistré le programme pour un tel point de terminaison.
Les modules logiciels peuvent être stockés dans ou transmis par un support de données. Celui-ci peut être un support matériel de stockage, par exemple un CD-ROM, une disquette magnétique ou un disque dur, ou bien un support de transmission tel qu'un signal électrique, optique ou radio, ou un réseau de télécommunication.

Claims

REVENDICATIONS
1. Procédé de contrôle, dans un réseau de communication (1), d'au moins une requête (E5) de connectivité pour l'établissement d'une session web d'échanges en temps réel d'au moins un flux média entre un point de terminaison appelant (10a) et un point de terminaison appelé (10b), comprenant :
- obtention (E3, E4) d'au moins une paire d'adresses candidates associées auxdits points de terminaison ;
- vérification (E6), au moyen d'une requête de connectivité, que ladite au moins une paire d' adresses candidates obtenue est apte à établir ladite session entre lesdits points de terminaison ;
- vérification (E7) que ladite requête de connectivité est en outre à destination d'une entité réputée de confiance agréée par un opérateur de réseaux de communication.
2. Procédé selon la revendication 1, comprenant en outre, lorsque ladite requête de connectivité n'est pas vérifiée être à destination d'une entité réputée de confiance, un envoi (E10) d'une notification à destination dudit point de terminaison appelant, ladite notification permettant à l'appelant d'obtenir des informations d'identification relatives à l'entité destinataire de ladite requête de connectivité.
3. Procédé selon la revendication 2, dans laquelle ladite notification est envoyée au moyen d'un protocole de message de contrôle Internet de type ICMP.
4. Procédé selon la revendication 1, comprenant en outre, lorsque ladite requête de connectivité, dite requête initiale, n'est pas vérifiée être à destination d'une entité agréée, une inhibition des envois de requêtes ultérieures de connectivité à destination de l'entité destinataire de ladite requête initiale.
5. Procédé selon la revendication 1, comprenant en outre, lorsque ladite requête de connectivité n'est pas vérifiée être à destination d'une entité agréée, une substitution dans ladite requête de connectivité, de l'adresse publique associée audit point de terminaison appelant par une adresse de substitution.
6. Procédé selon la revendication 1 , dans lequel la vérification que ladite requête de connectivité est à destination d'une entité agréée consiste à rechercher une appartenance de l'adresse de destination de ladite requête de connectivité à une liste d'adresses d'au moins une entité réputée de confiance agréée par ledit opérateur de réseaux de communication.
7. Système de contrôle, dans un réseau de communication, d' au moins une requête de connectivité pour l'établissement d'une session web d'échanges en temps réel d'au moins un flux média entre un point de terminaison appelant et un point de terminaison appelé, comprenant :
- lesdits points de terminaison appelant et appelé, lesdits points de terminaison comprenant chacun :
- un module d'obtention, agencé pour obtenir au moins une paire d'adresses candidates associées auxdits points de terminaison ;
- un module de vérification, agencé pour vérifier au moyen d'une requête de connectivité, que ladite au moins une paire d'adresses candidates obtenue est apte à établir ladite session entre lesdits points de terminaison ; et
- une entité de contrôle, comprenant un module de vérification, agencé pour vérifier que ladite requête de connectivité est à destination d'une entité réputée de confiance agréée par un opérateur de réseaux de communication.
8. Système de contrôle selon la revendication 7, dans lequel ladite entité de contrôle comprend en outre un module d'envoi, agencé pour envoyer une notification à destination dudit point de terminaison appelant, ladite notification permettant à l'appelant d'obtenir des informations d'identification relatives à l'entité destinataire de ladite requête de connectivité.
9. Système de contrôle selon la revendication 8, comprenant en outre une entité de vérification d'adresses agencée pour fournir à ladite entité de contrôle des informations d'identification relatives à l'entité destinataire de ladite requête de connectivité, et lorsque ladite requête de connectivité, dite requête initiale, n'est pas vérifiée être à destination d'une entité réputée de confiance, pour commander à ladite entité de contrôle une inhibition des envois de requêtes ultérieures de connectivité à destination de l'entité destinataire de ladite requête initiale.
10. Programme d'ordinateur comprenant des instructions de code de programme pour l'exécution des étapes du procédé selon les revendications 1 à 6 lorsque ledit programme est exécuté sur ordinateur.
11. Support d'enregistrement lisible par ordinateur sur lequel est enregistré un programme d'ordinateur comprenant des instructions de code de programme pour l'exécution des étapes du procédé selon les revendications 1 à 6.
PCT/FR2016/053286 2015-12-10 2016-12-08 Procede de controle de messages de recommandation dans un reseau de communication WO2017098171A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR1562147A FR3045254A1 (fr) 2015-12-10 2015-12-10 Procede de controle de messages de recommandation dans un reseau de communication
FR1562147 2015-12-10

Publications (1)

Publication Number Publication Date
WO2017098171A1 true WO2017098171A1 (fr) 2017-06-15

Family

ID=55759713

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/FR2016/053286 WO2017098171A1 (fr) 2015-12-10 2016-12-08 Procede de controle de messages de recommandation dans un reseau de communication

Country Status (2)

Country Link
FR (1) FR3045254A1 (fr)
WO (1) WO2017098171A1 (fr)

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20140150075A1 (en) * 2012-11-27 2014-05-29 Sansay, Inc. Securely establishing ice relay connections
US20140282903A1 (en) * 2013-03-14 2014-09-18 Avaya Inc. MANAGING IDENTITY PROVIDER (IdP) IDENTIFIERS FOR WEB REAL-TIME COMMUNICATIONS (WebRTC) INTERACTIVE FLOWS, AND RELATED METHODS, SYSTEMS, AND COMPUTER-READABLE MEDIA

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20140150075A1 (en) * 2012-11-27 2014-05-29 Sansay, Inc. Securely establishing ice relay connections
US20140282903A1 (en) * 2013-03-14 2014-09-18 Avaya Inc. MANAGING IDENTITY PROVIDER (IdP) IDENTIFIERS FOR WEB REAL-TIME COMMUNICATIONS (WebRTC) INTERACTIVE FLOWS, AND RELATED METHODS, SYSTEMS, AND COMPUTER-READABLE MEDIA

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
ROSENBERG JDROSEN NET J: "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols; rfc5245.txt", INTERACTIVE CONNECTIVITY ESTABLISHMENT (ICE): A PROTOCOL FOR NETWORK ADDRESS TRANSLATOR (NAT) TRAVERSAL FOR OFFER/ANSWER PROTOCOLS; RFC5245.TXT, INTERNET ENGINEERING TASK FORCE, IETF; STANDARD, INTERNET SOCIETY (ISOC) 4, RUE DES FALAISES CH- 1205 GEN, 30 April 2010 (2010-04-30), pages 1 - 117, XP015070785 *

Also Published As

Publication number Publication date
FR3045254A1 (fr) 2017-06-16

Similar Documents

Publication Publication Date Title
JP5735016B2 (ja) ピアツーピアハイブリッド通信のためのシステムおよび方法
EP2585939B1 (fr) Fédérations dynamiques
EP2692089B1 (fr) Mécanisme de redirection entrante sur un proxy inverse
EP2514167B1 (fr) Procede et dispositif de controle
EP2291980B1 (fr) Acces reseau a distance via un reseau visite
EP3503508B1 (fr) Procédé de traitement de requêtes et serveur proxy
EP3087720B1 (fr) Technique de contrôle du routage d'une requête relative a un service
EP2909995A1 (fr) Procédé et système de création d'agent utilisateur sip virtuel par l'utilisation d'un navigateur web webrtc
Keromytis Voice over IP: Risks, threats and vulnerabilities
EP2685694A1 (fr) Procédé d'enregistrement d'au moins une adresse publique dans un réseau IMS et application correspondante
WO2017098171A1 (fr) Procede de controle de messages de recommandation dans un reseau de communication
EP2266279B1 (fr) Partage de contenu multi supports a partir d'une communication audio-video
FR2906951A1 (fr) Dispositif et methode de controle et de securite d'un sous-systeme multimedia.
WO2015145079A1 (fr) Procede de mise en cache d'un contenu dans un reseau de distribution de contenus
WO2011073584A1 (fr) Procede de controle d'acces a un reseau local
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
EP2801178B1 (fr) Procédé dynamique de détermination d'une liste de services dans un réseau sip
WO2013121158A1 (fr) Procédé d'enregistrement d'un serveur d'application et serveur d'application
WO2013093282A1 (fr) Procede de propagation des associations entre adresses de contact et identites privees dans un reseau ip
FR3011418A1 (fr) Technique d'administration a distance d'un dispositif appartenant a un reseau prive
WO2015086460A1 (fr) Procede de gestion d'un identifiant public, systeme, serveur et element de securite correspondant
WO2013153222A1 (fr) Procédé d'appairage d'un élément de sécurité a un terminal de télécommunications et système correspondant

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 16820002

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 16820002

Country of ref document: EP

Kind code of ref document: A1