FR2898751A1 - Dispositif de controle pour la centralisation forcee de trafics selectionnes dans un noeud d'un reseau ip - Google Patents

Dispositif de controle pour la centralisation forcee de trafics selectionnes dans un noeud d'un reseau ip Download PDF

Info

Publication number
FR2898751A1
FR2898751A1 FR0650949A FR0650949A FR2898751A1 FR 2898751 A1 FR2898751 A1 FR 2898751A1 FR 0650949 A FR0650949 A FR 0650949A FR 0650949 A FR0650949 A FR 0650949A FR 2898751 A1 FR2898751 A1 FR 2898751A1
Authority
FR
France
Prior art keywords
address
native
message
terminal
node
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
FR0650949A
Other languages
English (en)
Other versions
FR2898751B1 (fr
Inventor
Alexander Toth
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.)
Alcatel Lucent SAS
Original Assignee
Alcatel 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 Alcatel SA filed Critical Alcatel SA
Priority to FR0650949A priority Critical patent/FR2898751B1/fr
Priority to AT07104512T priority patent/ATE524001T1/de
Priority to EP07104512A priority patent/EP1838070B1/fr
Publication of FR2898751A1 publication Critical patent/FR2898751A1/fr
Application granted granted Critical
Publication of FR2898751B1 publication Critical patent/FR2898751B1/fr
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W8/00Network data management
    • H04W8/02Processing of mobility data, e.g. registration information at HLR [Home Location Register] or VLR [Visitor Location Register]; Transfer of mobility data, e.g. between HLR, VLR or external networks
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/10Network architectures or network communication protocols for network security for controlling access to devices or network resources
    • H04L63/101Access control lists [ACL]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W12/00Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/08Access security
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W8/00Network data management
    • H04W8/02Processing of mobility data, e.g. registration information at HLR [Home Location Register] or VLR [Visitor Location Register]; Transfer of mobility data, e.g. between HLR, VLR or external networks
    • H04W8/08Mobility data transfer
    • H04W8/082Mobility data transfer for traffic bypassing of mobility servers, e.g. location registers, home PLMNs or home agents
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W80/00Wireless network protocols or protocol adaptations to wireless operation
    • H04W80/04Network layer protocols, e.g. mobile IP [Internet Protocol]

Abstract

Un dispositif (D) est dédié au contrôle de trafic au sein d'un noeud natif (R1) constituant au sein d'un réseau de communications à protocole Internet (IP) un agent natif pour au moins un premier terminal mobile (TM) disposant d'une première adresse IP et momentanément rattaché à un sous-réseau étranger (S3). Ce dispositif (D) comprend des moyens de contrôle (MC) chargés, en cas de réception par le noeud natif (R1) d'un premier message associé à une première adresse IP source du premier terminal mobile (TM) et à une seconde adresse IP de destination d'un second terminal (TC) et requérant l'établissement d'un trafic décentralisé entre ces premier (TM) et second (TC) terminaux, de vérifier si la première adresse IP correspond à une adresse IP d'une liste d'adresses IP choisies, et en cas de correspondance, i) d'interdire au noeud natif (R1) de transmettre le premier message reçu à la seconde adresse IP de destination, ii) de générer un message de réponse signalant l'incapacité du second terminal (TC) à satisfaire au premier message et associé à une adresse IP de destination égale à la première adresse IP, et iii) d'ordonner au noeud natif (R1) de transmettre le message de réponse à la première adresse IP.

Description

2898751 DISPOSITIF DE CONTRâLE POUR LA CENTRALISATION FORCÉE DE TRAFICS
SÉLECTIONNÉS DANS UN NOEUD D'UN RÉSEAU IP L'invention concerne les réseaux de communication à protocole Internet (IP), et plus précisément le contrôle de certains trafics au sein de tels réseaux IP. On entend ici par réseau IP une fédération de sous-réseaux locaux raccordés les uns aux autres au moyen d'équipements formant 10 des noeuds, comme par exemple des routeurs. Comme le sait l'homme de l'art, chaque terminal de communication, qui peut se raccorder à un réseau IP et qui supporte une mobilité de type Mobile IP , dispose d'une adresse IP native (ou home address ) qui correspond au préfixe du sous-réseau natif (ou home subnet ) auquel il est 15 habituellement rattaché (au sens logique du terme). Chaque sous-réseau natif dispose d'au moins un noeud dit natif, comme par exemple un routeur, qui constitue un agent natif (ou home agent ) pour chaque terminal qui se trouve nativement enregistré chez lui. II est rappelé qu'un agent natif est un noeud vers lequel sont 20 initialement routés tous les paquets de données (ou datagrammes) qui sont destinés à un terminal qui est nativement enregistré chez lui, et qui est chargé de router ces paquets vers ce terminal, qu'il soit connecté à son sous-réseau natif ou bien à un sous-réseau distant ou étranger (ou foreign subnet ). Par conséquent, en condition normale de fonctionnement tous les 25 trafics IP qui sont destinés à un terminal disposant d'une adresse IP native passent obligatoirement par le noeud natif qui constitue son agent natif. Du fait de cette centralisation des trafics au niveau d'un noeud natif, il est donc possible, lorsque cela s'avère nécessaire, d'y observer les trafics qui sont associés à une adresse IP source sélectionnée et/ou à une adresse IP de 30 destination sélectionnée. Cependant, certains messages spécifiques, comme par exemple ceux dits HoTl (pour Home Test Init ) définis dans les spécifications RFC 2 2898751 3775 de l'IETF, peuvent permettre à un terminal mobile qui est rattaché à un sous-réseau étranger de passer d'un mode de transmission centralisée (c'est-à-dire passant par son noeud natif) à un mode de transmission décentralisée (c'est-à-dire évitant son noeud natif). Dans ce cas, il est très difficile, voire s impossible, d'observer les trafics qu'échange ce terminal mobile avec un autre terminal. L'invention a donc pour but de remédier à cet inconvénient. Elle propose à cet effet un dispositif destiné à contrôler les trafics parvenant dans un noeud natif constituant, au sein d'un réseau IP, l'agent io natif d'au moins un premier terminal de communication mobile disposant d'une première adresse IP et momentanément rattaché à un sous-réseau étranger. Ce dispositif de contrôle se caractérise par le fait qu'il comprend des moyens de contrôle chargés, chaque fois que leur noeud natif reçoit un 15 premier message associé à une première adresse IP source du premier terminal mobile et à une seconde adresse IP de destination d'un second terminal de communication et requérant l'établissement d'un trafic décentralisé entre les premier et second terminaux, de vérifier si la première adresse IP correspond à une adresse IP d'une liste d'adresses IP choisies, et, 20 en cas de correspondance, i) d'interdire à leur noeud natif de transmettre le premier message reçu à la seconde adresse IP de destination, ii) de générer un message de réponse signalant l'incapacité du second terminal à satisfaire au premier message et associé à une adresse IP de destination égale à la première adresse IP, et iii) d'ordonner à leur noeud natif de transmettre ce 25 message de réponse à la première adresse IP. Le dispositif selon l'invention peut comporter d'autres caractéristiques qui peuvent être prises séparément ou en combinaison, et notamment : - ses moyens de contrôle peuvent être chargés d'associer à certains au moins des messages de réponse une adresse IP source égale à la 30 seconde adresse IP du second terminal de communication ; ses moyens de contrôle peuvent être chargés de contrôler des premiers messages de type dit HoTI (Home Test Init) ; ses moyens de contrôle peuvent être chargés de générer des messages 3 2898751 de réponse de type message d'erreur ICMP (pour Internet Control Message Protocol ). Par exemple, les messages d'erreur ICMP peuvent comporter ce que l'on appelle un code 1 de problème de paramètre ; il peut comprendre des moyens de mémorisation chargés de stocker la 5 liste d'adresses IP choisie ; ses moyens de contrôle peuvent être chargés d'accéder à des moyens de mémorisation qui sont implantés dans leur noeud natif et dans lesquels est stockée la liste d'adresses IP choisie ; - la liste d'adresses IP choisie peut par exemple être transmise par une io application distante (c'est-à-dire externe au noeud natif). L'invention propose également un noeud, comme par exemple un routeur d'accès d'un réseau IP, équipé d'un dispositif de contrôle du type de celui présenté ci-avant. D'autres caractéristiques et avantages de l'invention apparaîtront à 15 l'examen de la description détaillée ci-après, et des dessins annexés, sur lesquels : - la figure 1 illustre de façon schématique et fonctionnelle une partie d'un réseau IP équipé de routeurs d'accès munis chacun d'un exemple de réalisation d'un dispositif de contrôle selon l'invention, et 20 - la figure 2 illustre de façon schématique les messages échangés entre des premier et second terminaux et un routeur d'accès natif en cas de détection d'une correspondance avec une liste d'adresses IP (flèche F5) et en l'absence de correspondance avec une liste d'adresses IP (flèches F3 et F4). 25 L'invention a pour objet d'empêcher des terminaux mobiles, dont les adresses IP font partie d'une liste d'adresses IP choisie et qui sont momentanément rattachés à des sous-réseaux étrangers, de passer dans un mode de transmission décentralisée dans lequel les trafics qu'ils échangent ne sont plus observables au niveau de noeuds natifs d'un réseau IP. 30 On considère dans ce qui suit, à titre d'exemple illustratif et non limitatif, que le réseau IP est de type IPv6. Mais, l'invention n'est pas limitée à ce type de réseau IP. Elle concerne en effet tous les réseaux IP et notamment 4 2898751 ceux de type IPv4. Comme cela est schématiquement illustré sur la figure 1, un réseau IP peut être considéré comme une fédération de sous-réseaux locaux Sk (ici k = 1 à 3, mais il peut prendre n'importe quelle valeur supérieure ou égale 5 à 2), raccordés les uns aux autres par des routeurs. Chaque sous-réseau Sk comprend des noeuds Rj, tels que des routeurs, dont l'un au moins peut définir un agent natif (ou home agent ) pour au moins un terminal de communication mobile TM. Par exemple, le sous-réseau S1 constitue le sous-réseau natif (ou home subnet ) pour le terminal de communication mobile TM. On entend ici par sous-réseau natif le sous-réseau auquel est habituellement rattaché (de façon logique) un terminal mobile TM, c'est-à-dire celui auprès duquel il est enregistré et dispose d'une adresse IP native (ou home address ) qui correspond à son préfixe.
Chaque terminal mobile TM est associé (rattaché) à un noeud natif (par exemple un routeur) Rj (ici j = 1 à 3) de son sous-réseau natif Sk, qui constitue son agent natif (ou home agent ). L'adresse IP native d'un terminal mobile TM est ainsi enregistrée auprès d'un noeud natif Rj (ici R1). D'une manière générale, le noeud natif (routeur) RI stocke toutes les éventuelles informations de position (et localisation) du terminal mobile TM qui lui est associé, c'est-à-dire les données de mobilité qui le concernent, et sert de lieu de transit des paquets de données (ou datagrammes) qui doivent lui être transmis, qu'il soit connecté à son sous-réseau natif (par exemple SI dans le cas du terminal mobile TM) ou à un sous-réseau distant ou étranger (ou foreign subnet ) (par exemple S2 ou S3 dans le cas du terminal mobile TM). Par conséquent, en condition normale de fonctionnement tous les trafics IP qui sont destinés au terminal mobile TM passent obligatoirement par le noeud natif RI qui constitue son agent natif.
Tout type de terminal de communication mobile (ou portable ou encore cellulaire) est concerné par l'invention, dès lors qu'il est équipé de manière à accéder à un réseau IP et qu'il dispose d'une adresse IP native (ou home address) et d'une ou plusieurs adresses IP complémentaires (ou 5 2898751 care-of addresses dans le cas d'une mobilité de type Mobile IP ). Par conséquent les terminaux mobiles peuvent être par exemple des téléphones mobiles (ou cellulaires), des assistants personnels numériques (ou PDA) communicants, ou des ordinateurs portables (ou laptops ), l'important étant 5 qu'ils disposent d'une adresse IP native, d'au moins une adresse IP complémentaire (ou care-of address) et supportant une mobilité, par exemple de type Mobile IP. De tels terminaux mobiles (ou portables) sont généralement appelés noeuds mobiles (ou mobile nodes ). On considère dans ce qui suit, à titre d'exemple illustratif et non 10 limitatif, que le (premier) terminal mobile TM est un téléphone mobile (supportant une mobilité, par exemple de type Mobile IP). L'invention propose d'implanter dans (ou de coupler à) certains au moins des noeuds Rj du réseau IP, qui constituent des agents natifs, un dispositif de contrôle D. Dans l'exemple illustré sur la figure 1, seul le noeud 15 RI est équipé d'un dispositif de contrôle D car il constitue l'agent natif du terminal mobile TM. Cela n'empêche pas que d'autres noeuds (non représentés) de l'un au moins des sous-réseaux Sk soit équipé d'un dispositif de contrôle D. Chaque dispositif de contrôle D comprend au moins un module de 20 contrôle MC chargé de contrôler tous les flux (ou trafics) qui parviennent au niveau de son noeud natif Rj, afin de détecter (par exemple au moyen d'un mécanisme appelé ACL (pour Access Control List )) ceux qui comprennent des messages d'un type choisi, appelés ici premiers messages . On entend ici par premier message un message de données qui, 25 d'une part, est associé à une première adresse IP source d'un premier terminal mobile TM (qui l'a émis) et à une seconde adresse IP de destination d'un second terminal TC (qui en est le destinataire), et d'autre part, requiert l'établissement d'un trafic décentralisé entre ces premier et second terminaux. On considère dans ce qui suit, à titre d'exemple illustratif et non 30 limitatif, que le (second) terminal TC est un ordinateur fixe disposant d'une seconde adresse IP et rattaché au sous-réseau S2. II est important de noter que l'invention ne concerne que des premiers terminaux mobiles TM qui se trouvent momentanément rattachés à un sous- 6 2898751 réseau étranger distant de leur sous-réseau natif. Dans l'exemple illustré sur la figure 1, le premier terminal mobile TM est momentanément rattaché au sous-réseau étranger S3. Le second terminal TC est ici considéré comme le correspondant du 5 premier terminal mobile TM. Par conséquent, il peut être assimilé à sa seconde adresse IP. Par ailleurs, on entend ici par trafic décentralisé un trafic de type bout-en-bout (ou end-to-end ) établi entre les terminaux TM et TC, sans passer par le noeud natif R1 qui constitue l'agent natif de TM. io A titre d'exemple illustratif et non limitatif, un premier message peut être du type dit HoTl ( Home Test Init ). Ce type de message est notamment défini au chapitre 5.2.5 des spécifications RFC 3775 de l'IETF. Il fait partie de et débute la procédure qui permet d'établir une communication avec un correspondant (ici TC) sans passer par l'agent natif (ici R1) d'un 15 terminal mobile TM. Chaque fois que le module de contrôle MC détecte l'arrivée d'un premier message dans son noeud natif RI, il vérifie si la première adresse IP, qui est associée à ce premier message, correspond à une adresse contenue dans une liste d'adresses IP choisies.
20 Cette liste contient des adresses IP de terminaux Ti qui doivent faire localement l'objet d'une surveillance ou d'un contrôle, éventuellement juridique mais pas nécessairement. Elle est de préférence stockée dans des moyens de mémorisation MM qui font partie intégrante du dispositif D (comme illustré sur la figure 1) ou bien qui sont implantés dans le noeud natif 25 R1 qui contient le dispositif D (mais externe à celui-ci). Ces moyens de mémorisation MM se présentent par exemple sous la forme d'une mémoire ou d'une base de données. La liste est par exemple transmise à un noeud natif Rj au moyen d'une application spécifique AP qui est par exemple implantée dans un 30 serveur d'applications SA connecté, par exemple, au sousréseau SI (comme dans l'exemple de la figure 1). Cela permet notamment de pouvoir la mettre à jour quand on le souhaite. Une fois reçue par un noeud natif Rj, la liste est ensuite stockée dans 7 2898751 les moyens de mémorisation MM prévus à cet effet, éventuellement à la place de l'ancienne liste. Les listes varient préférentiellement d'un noeud natif à l'autre. La vérification d'adresse porte de préférence sur l'adresse IP native s du premier terminal mobile TM, qui constitue la première adresse IP source contenue dans le premier message. Mais, elle pourrait également porter sur l'adresse IP complémentaire (ou care-of address) du premier terminal mobile TM qui est habituellement également contenue dans le premier message. Par conséquent, une liste ne comporte préférentiellement que des lo adresses IP natives. Le noeud natif dispose des adresses IP natives de tous les terminaux mobiles qui lui sont rattachés et des adresses IP complémentaires (ou care-of addresses) qui leurs correspondent. Par conséquent, lorsque la liste ne comprend que des adresses IP natives et que la détection porte sur les 15 adresses IP complémentaires ou bien sur les adresses IP natives et que le premier message ne comporte que l'adresse IP complémentaire du premier terminal mobile TM, le module de contrôle MC peut être agencé de manière à déterminer auprès du noeud natif auquel il est associé l'adresse IP native qui correspond à la première adresse IP complémentaire contenue dans un 20 premier message reçu. Il peut alors vérifier si cette adresse IP native fait partie de la liste. Cela permet notamment l'écriture d'ACLs avec les adresses IP complémentaires (qui sont les adresses source des premiers messages). En effet l'adresse IP native est contenue dans le contenu du paquet et non dans le champ adresse source ou adresse de destination d'un premier 25 message. Si la première adresse IP associée à un premier message détecté ne correspond pas à l'une des adresses de la liste stockée dans les moyens de mémorisation MM, le module de contrôle MC autorise son noeud natif Rj (par exemple R1 si l'émetteur du premier message est TM) à router ce premier 30 message vers le second terminal (par exemple TC) qui est désigné par la seconde adresse IP de destination à laquelle il est associé. Le premier terminal mobile TM peut alors passer dans un mode de transmission décentralisée dans lequel les données qu'il échange avec son correspondant 8 2898751 (ici TC) ne passent plus par son agent natif R1. Il peut alors communiquer en mode bout-en-bout avec le second terminal TC. II est important de noter que lorsque le second terminal TC est mobile et momentanément rattaché à un sous-réseau étranger (par exemple S1 ou 5 S3), son utilisateur peut également souhaiter passer en mode de transmission décentralisée, afin que les données qu'il échange avec son correspondant TM ne passent plus par son propre agent natif R2. Le terminal TC doit alors procéder comme s'il était un premier terminal mobile et générer à destination du terminal correspondant (ici TM) un premier message qui est alors traité par lo le noeud natif qui constitue son agent natif, comme indiqué ci-avant pour TM. En revanche, si la première adresse IP associée à un premier message détecté correspond à l'une des adresses de la liste stockée dans les moyens de mémorisation MM, le module de contrôle MC interdit à son noeud natif Rj (par exemple R1 si l'émetteur du premier message est) TM de 15 transmettre le premier message reçu à la seconde adresse IP de destination qui lui est associée. Le noeud natif Rj extrait alors le premier message afin d'empêcher sa transmission vers le second terminal TC. Puis (ou sensiblement simultanément), le module de contrôle MC génère un message de réponse destiné à signaler au premier terminal mobile 20 TM, source du premier message reçu, l'incapacité du second terminal TC, destinataire dudit premier message, à satisfaire (ou répondre) audit premier message. Il associe donc à ce message de réponse au moins une adresse IP de destination qui est identique à la première adresse IP associée au premier message. Puis, le module de contrôle MC ordonne à son noeud natif Rj (ici 25 R1) de transmettre (router) ce message de réponse à la première adresse IP, c'est-à-dire au premier terminal mobile TM, source du premier message reçu. De préférence, le module de contrôle MC associe également au message de réponse la seconde adresse IP qui était associée au premier message reçu, en tant qu'adresse IP source. Ainsi, le noeud natif Rj (ici R1), 30 qui émet le message de réponse, se fait passer pour le second terminal TC, destinataire du premier message. A titre d'exemple illustratif et non limitatif, un message de réponse peut être un message d'erreur de type ICMP (pour Internet Control 9 2898751 Message Protocol ). Plus précisément, le message d'erreur qui est généré par le module de contrôle MC peut comporter un code 1 de problème de paramètre (ou parameter problem, Code 1 ). Ce type de message d'erreur ICMP est notamment défini au chapitre 11.3.5 des spécifications RFC 3775 s de l'IETF. Il est destiné à expliquer en fonctionnement normal que le correspondant TC ne supporte pas ce que le premier terminal mobile TM demande. Dans le cadre de l'invention ce message d'erreur est destiné à signaler que le correspondant TC ne supporte pas une communication décentralisée et donc que la communication avec le premier terminal mobile io TM doit continuer à se faire via l'agent natif RI de ce dernier. Il est rappelé que le protocole ICMP est destiné à faire remonter les erreurs ou les diagnostics entre des équipements en communication. A réception d'un message de réponse (par exemple de type message d'erreur ICMP), le premier terminal mobile TM est alors persuadé que le 15 second terminal TC est dans l'incapacité de fonctionner en mode de transmission décentralisée, si bien que son utilisateur doit soit interrompre l'envoi de paquets de données à destination du second terminal TC pour que leur contenu ne puisse pas être analysé ou contrôlé au niveau du noeud natif R1 du premier terminal mobile TM, soit continuer à transmettre des paquets 20 de données à destination du second terminal TC, en mode de transmission centralisée, tout en sachant que leur contenu risque d'être analysé ou contrôlé au niveau du noeud natif RI du premier terminal mobile TM. On se réfère maintenant à la figure 2 pour résumer les différents messages qui sont échangés entre un premier terminal mobile TM, un second 25 terminal TC et un noeud natif RI constituant l'agent natif du premier terminal mobile TM, dans le cadre de l'invention. Dans une phase préliminaire (flèche F1), une liste d'adresses IP choisie est transmise au noeud natif RI par exemple par une application AP tournant dans un serveur d'applications SA connecté au réseau IP (ici au 30 sous-réseau S1, à titre d'exemple). Cette liste est stockée dans des moyens de mémorisation MM du dispositif D (ou bien du noeud natif RI). Puis, le premier terminal mobile TM (par exemple de type téléphone mobile), rattaché à un sous-réseau étranger (ici S3), transmet un premier l0 2898751 message à destination du second terminal TC (par exemple de type ordinateur fixe). Ce premier message étant associé à la première adresse IP du premier terminal mobile TM, il est donc routé vers son agent natif (flèche F2), c'est-à-dire le noeud natif R1 (ici un routeur du sous-réseau S1, à titre s d'exemple). Lorsque ce premier message parvient dans le noeud natif R1, le dispositif de contrôle D, qui lui est associé, le détecte grâce à son module de contrôle MC. Ce dernier accède alors aux moyens de mémorisation MM afin de vérifier si la première adresse IP qui est associée au premier message lo correspond à l'une des adresses de la liste qu'ils stockent. Si ce n'est pas le cas, le module de contrôle MC autorise le noeud natif R1 à router le premier message vers le second terminal TC (désigné par la seconde adresse IP de destination à laquelle il est associé). Le noeud natif R1 transmet alors le premier message à destination du second terminal TC 15 (flèche F3). Le premier terminal mobile TM peut alors passer en mode de transmission décentralisée, c'est-à-dire sans passer par son noeud natif R1 si le second terminal TC l'accepte (flèche F4). En revanche, si la première adresse IP, associée au premier message détecté, correspond à l'une des adresses de la liste, le module de 20 contrôle MC interdit au noeud natif R1 de transmettre le premier message au second terminal TC (désigné par la seconde adresse IP de destination à laquelle il est associé). Le noeud natif R1 extrait alors le premier message afin de le supprimer. Puis (ou sensiblement simultanément), le module de contrôle MC génère un message de réponse, signalant l'incapacité du second terminal 25 TC à satisfaire (ou répondre) au premier message et associé à la première adresse IP du premier terminal mobile TM, et ordonne au noeud natif R1 de le transmettre au (ou router vers le) premier terminal mobile TM (ce qui est matérialisé par la flèche F5). Le trafic entre les premier TM et second TC terminaux ne peut alors se faire que via le noeud natif R1, où il peut alors faire 30 l'objet d'un contrôle ou d'une analyse (flèches F6 et F7). Le dispositif de contrôle D selon l'invention, et notamment son module de contrôle MC et ses éventuels moyens de mémorisation MM, peuvent être réalisés sous la forme de circuits électroniques, de modules Il 2898751 logiciels (ou informatiques), ou d'une combinaison de circuits et de logiciels. On notera que le dispositif de contrôle D selon l'invention peut être éventuellement chargé d'effectuer l'enregistrement ou l'écoute des données qu'échangent les terminaux dont les adresses IP font partie (ou 5 correspondent) à la liste d'adresses IP qui le concerne. L'invention ne se limite pas aux modes de réalisation de dispositif de contrôle D et de noeud décrits ci-avant, seulement à titre d'exemple, mais elle englobe toutes les variantes que pourra envisager l'homme de l'art dans le cadre des revendications ci-après. io 12

Claims (9)

REVENDICATIONS
1. Dispositif (D) de contrôle de trafic pour un noeud natif (Rj) constituant au sein d'un réseau de communications à protocole Internet (IP) un agent natif pour au moins un premier terminal de communication mobile (TM) disposant d'une première adresse IP et momentanément rattaché à un sous-réseau (S3) dit étranger, caractérisé en ce qu'il comprend des moyens de contrôle (MC) agencés, en cas de réception par ledit noeud natif (RI) d'un premier message associé à une première adresse IP source dudit premier lo terminal mobile (TM) et à une seconde adresse IP de destination d'un second terminal (TC) et requérant l'établissement d'un trafic décentralisé entre ces premier (TM) et second (TC) terminaux, pour vérifier si ladite première adresse IP correspond à une adresse IP d'une liste d'adresses IP choisies, et en cas de correspondance, i) pour interdire audit noeud natif (R1) de 15 transmettre ledit premier message reçu à ladite seconde adresse IP de destination, ii) pour générer un message de réponse signalant l'incapacité dudit second terminal (TC) à satisfaire audit premier message et associé à une adresse IP de destination égale à ladite première adresse IP, et iii) pour ordonner audit noeud natif (R1) de transmettre ledit message de réponse à 20 ladite première adresse IP.
2. Dispositif selon la revendication 1, caractérisé en ce que lesdits moyens de contrôle (MC) sont agencés pour associer à certains au moins des messages de réponse une adresse IP source égale à ladite seconde adresse IP du second terminal de communication (TC). 25
3. Dispositif selon l'une des revendications 1 et 2, caractérisé en ce que lesdits moyens de contrôle (MC) sont agencés pour contrôler des premiers messages de type dit HoTI.
4. Dispositif selon l'une des revendications 1 à 3, caractérisé en ce que lesdits moyens de contrôle (MC) sont agencés pour générer des messages 30 de réponse de type message d'erreur ICMP.
5. Dispositif selon la revendication 4, caractérisé en ce que lesdits moyens de contrôle (MC) sont agencés pour générer des messages d'erreur ICMP comportant un code 1 de problème de paramètre. 13 2898751
6. Dispositif selon l'une des revendications 1 à 5, caractérisé en ce qu'il comprend des moyens de mémorisation (MM) propres à stocker ladite liste d'adresses IP choisie.
7. Dispositif selon l'une des revendications 1 à 5, caractérisé en ce 5 lesdits moyens de contrôle (MC) sont agencés pour accéder à des moyens de mémorisation implantés dans ledit noeud (R1) et propres à stocker ladite liste d'adresses IP choisie.
8. Dispositif selon l'une des revendications 6 et 7, caractérisé en ce que ladite liste d'adresses IP choisie est transmise par une application 10 distante (AP).
9. Noeud (Rj) pour un réseau de communications à protocole Internet (IP), caractérisé en ce qu'il comprend un dispositif de contrôle (D) selon l'une des revendications précédentes.
FR0650949A 2006-03-20 2006-03-20 Dispositif de controle pour la centralisation forcee de trafics selectionnes dans un noeud d'un reseau ip Expired - Fee Related FR2898751B1 (fr)

Priority Applications (3)

Application Number Priority Date Filing Date Title
FR0650949A FR2898751B1 (fr) 2006-03-20 2006-03-20 Dispositif de controle pour la centralisation forcee de trafics selectionnes dans un noeud d'un reseau ip
AT07104512T ATE524001T1 (de) 2006-03-20 2007-03-20 Überwachungsvorrichtung zur zentralisierung von ausgewähltem verkehr in einem knoten eines ip- netzes
EP07104512A EP1838070B1 (fr) 2006-03-20 2007-03-20 Dispositif de contrôle pour la centralisation forcée de trafics sélectionnés dans un n?ud d'un réseau IP

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
FR0650949A FR2898751B1 (fr) 2006-03-20 2006-03-20 Dispositif de controle pour la centralisation forcee de trafics selectionnes dans un noeud d'un reseau ip

Publications (2)

Publication Number Publication Date
FR2898751A1 true FR2898751A1 (fr) 2007-09-21
FR2898751B1 FR2898751B1 (fr) 2008-05-02

Family

ID=36968645

Family Applications (1)

Application Number Title Priority Date Filing Date
FR0650949A Expired - Fee Related FR2898751B1 (fr) 2006-03-20 2006-03-20 Dispositif de controle pour la centralisation forcee de trafics selectionnes dans un noeud d'un reseau ip

Country Status (3)

Country Link
EP (1) EP1838070B1 (fr)
AT (1) ATE524001T1 (fr)
FR (1) FR2898751B1 (fr)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2009152844A1 (fr) * 2008-06-16 2009-12-23 Nokia Siemens Networks Oy Optimisation sélective de route
CN101599967B (zh) * 2009-06-29 2012-08-15 杭州华三通信技术有限公司 基于802.1x认证系统的权限控制方法及系统

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20010053694A1 (en) * 2000-01-31 2001-12-20 Fujitsu Limited Network system with dynamic service profile updating functions
US20040095913A1 (en) * 2002-11-20 2004-05-20 Nokia, Inc. Routing optimization proxy in IP networks
US20060018291A1 (en) * 2004-07-23 2006-01-26 Cisco Technology, Inc. Methods and apparatus for achieving route optimization and location privacy in an IPV6 network

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20010053694A1 (en) * 2000-01-31 2001-12-20 Fujitsu Limited Network system with dynamic service profile updating functions
US20040095913A1 (en) * 2002-11-20 2004-05-20 Nokia, Inc. Routing optimization proxy in IP networks
US20060018291A1 (en) * 2004-07-23 2006-01-26 Cisco Technology, Inc. Methods and apparatus for achieving route optimization and location privacy in an IPV6 network

Also Published As

Publication number Publication date
ATE524001T1 (de) 2011-09-15
FR2898751B1 (fr) 2008-05-02
EP1838070B1 (fr) 2011-09-07
EP1838070A1 (fr) 2007-09-26

Similar Documents

Publication Publication Date Title
EP1966970B1 (fr) Appareil de gestion de reseau de mobiles et appareil de gestion d'information de mobiles pour gerer les demandes d'acces
Kafle et al. An ID/locator split architecture for future networks
US8601127B2 (en) Method for selective service updates for communication networks
WO2021002261A1 (fr) Dispositif de détection d'anomalie et procédé de détection d'anomalie
US7539159B2 (en) Maintaining reachability of a mobile node
Wood et al. A bundle of problems
US20100272107A1 (en) Technique for address resolution in a data transmission network
EP2469787B1 (fr) Procédé et dispositif pour prévenir des attaques de réseau
US8726068B2 (en) Intra-realm AAA fallback mechanism
KR20000076717A (ko) QoS 세션 설정 방법 및 이동 IP 환경
FR2888078A1 (fr) Procede de transfert d'une communication impliquant un noeud mobile en situation de macro-mobilite au sein d'un reseau de communication ip a routage hierarchique
JP2008542892A (ja) 動的ipアドレスがファイヤウォールの背後に存在する装置上のウェブ・サーバにアクセスするためのシステム及び方法
US20090161604A1 (en) Method, system, and device of packet routing for localized mobility management network
Huston Architectural approaches to multi-homing for IPv6
Kivinen et al. Design of the IKEv2 mobility and multihoming (MOBIKE) protocol
EP4052447B1 (fr) Découverte d'un noeud mandataire collaboratif dans un réseau de communication 3gpp
FR2898751A1 (fr) Dispositif de controle pour la centralisation forcee de trafics selectionnes dans un noeud d'un reseau ip
EP1791319B1 (fr) Procédé de transfert d'une communication au sein d'un réseau de communication à routage hiérarchique
WO2001063877A1 (fr) Procede de gestion de mobilite dans un reseau de telecommunications, et serveur de mobilite pour la mise en oeuvre du procede
CN111064670B (zh) 一种获取下一跳路由信息的方法和装置
Li Future internet services based on LIPS technology
JP2006025341A (ja) Vlanの近隣探索代理方式および方法、並びにルータ装置
WO2023186875A1 (fr) Configuration d'orientation de trafic
Rao et al. Detecting Inactive Neighbors over OSPF Demand Circuits (DC)
KR100693562B1 (ko) 무선 인터넷 시스템에서의 노드간 패킷 통신 방법

Legal Events

Date Code Title Description
GC Lien (pledge) constituted

Effective date: 20140717

RG Lien (pledge) cancelled

Effective date: 20141016

ST Notification of lapse

Effective date: 20151130