ES2384377T3 - Método y adaptación para impedir el uso ilegítimo de direcciones IP - Google Patents

Método y adaptación para impedir el uso ilegítimo de direcciones IP Download PDF

Info

Publication number
ES2384377T3
ES2384377T3 ES02783924T ES02783924T ES2384377T3 ES 2384377 T3 ES2384377 T3 ES 2384377T3 ES 02783924 T ES02783924 T ES 02783924T ES 02783924 T ES02783924 T ES 02783924T ES 2384377 T3 ES2384377 T3 ES 2384377T3
Authority
ES
Spain
Prior art keywords
subscriber
address
dhcp
filter
message
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.)
Expired - Lifetime
Application number
ES02783924T
Other languages
English (en)
Inventor
Peter Nesz
Thomas Johansson
Michael Juhl
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.)
Telefonaktiebolaget LM Ericsson AB
Original Assignee
Telefonaktiebolaget LM Ericsson AB
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 Telefonaktiebolaget LM Ericsson AB filed Critical Telefonaktiebolaget LM Ericsson AB
Application granted granted Critical
Publication of ES2384377T3 publication Critical patent/ES2384377T3/es
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/02—Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
    • H04L63/0227—Filtering policies
    • H04L63/0236—Filtering by address, protocol, port number or service, e.g. IP-address or URL
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/50—Address allocation
    • H04L61/5007—Internet protocol [IP] addresses
    • H04L61/5014—Internet protocol [IP] addresses using dynamic host configuration protocol [DHCP] or bootstrap protocol [BOOTP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/14—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
    • H04L63/1441—Countermeasures against malicious traffic
    • H04L63/1466—Active attacks involving interception, injection, modification, spoofing of data unit addresses, e.g. hijacking, packet injection or TCP sequence number attacks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H04L69/161—Implementation details of TCP/IP or UDP/IP stack architecture; Specification of modified or new header fields
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]

Landscapes

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

Abstract

Un método para uso en una red IP, la red que incluye un nodo conmutador (5), al menos un servidor DHCP (4, 4a, 4b) y al menos un abonado (6) que está asociado con el nodo, el método incluye los siguientes pasos: - crear una lista (L1) de los de confianza de los servidores DHCP; - transmitir por el abonado (6) un mensaje de petición DHCP (M3) para una dirección IP; - recibir un mensaje de respuesta (M4), el cual transporta una dirección IP de abonado asignada (IP1); - analizar (510, 808, (8)) el mensaje de respuesta para ser un mensaje DHCP y que tiene una dirección fuente (IP4) de uno de los servidores DHCP de confianza (4); - actualizar (513, 812, (10)) un filtro (9, TAB1) dinámicamente en el nodo (5), el filtro que almacena una identificación (MAC1, P1, VLAN1) del abonado (6) y la dirección IP de abonado asignada (IP1); - transmitir una trama (FR1) desde el abonado (6) usando una dirección IP fuente (IPX); - comparar en el filtro (9, TAB1) dicha dirección IP fuente con la dirección IP de abonado almacenada (IP1); - descartar dicha trama cuando dicha dirección IP fuente (IPX) difiere de la dirección IP de abonado almacenada (IP1).

Description

Metodo y adaptaci6n para impedir el uso ilegftimo de direcciones IP
Campo teenieo de la inveneian
La presente invenci6n se refiere a un metodo y un dispositivo en una red IP, los cuales contrarrestan el uso ilegftimo 5 de direcciones IP.
Deseripeian de la teeniea relaeionada
Los abonados en una red IP pueden usar direcciones IP que no son adquiridas en una forma legftima. El abonado puede usar la direcci6n IP de alguien o una direcci6n IP actualmente no en uso. El abonado, que puede ser por ejemplo una empresa, esta conectado a una isla de banda ancha, y usa la direcci6n IP para identificarse a sf mismo
10 en la red. Si el abonado tiene intenciones de abusar hace un llamamiento para utilizar tal direcci6n IP ilegftima. El seguimiento de abusos esta basado a saber en la direcci6n IP y el abusador se beneficiarfa de la direcci6n ilegftima, dado que al abusador le serfa mas diffcil de hacer el seguimiento en una investigaci6n.
En la solicitud de patente internacional W098/26550 se revela un sistema para asignaci6n y uso de direcciones IP en una red con sistemas de abonado. Cada sistema de abonado esta conectado a un servidor DHCP a traves de un 15 m6dem por cable. El servidor DHCP cede direcciones IP a los sistemas de abonados y trabaja en combinaci6n con un agente de repetici6n DHCP seguro y un agente de repetici6n IP seguro. Cuando un sistema de abonado envfa un mensaje de petici6n DHCP, el agente de repetici6n DHCP anade un identificador de confianza al mensaje y lo transmite al servidor DHCP. El identificador de confianza, el cual esta asociado con el sistema de abonado de petici6n, se usa por el servidor DHCP para impedir al sistema de abonado acceder a cesiones de direcciones IP de
20 otros sistemas de abonado. El servidor DHCP tambien cuenta el numero de cesiones de direcciones IP por identificador de confianza y lo restringe a un numero predeterminado. El sistema requiere un servidor DHCP no estandar y sistema de abonado.
La US 6.061.798 revela un cortafuegos para aislar los elementos de red de una red accesible publicamente. Todo acceso a elementos de red protegidos debe ir a traves del cortafuegos, que funciona en un ordenador aut6nomo. Un
25 agente intermediario, asignado especfficamente a una petici6n entrante, verifica la autoridad de la petici6n de acceder a un elemento de red indicado en la petici6n. Una vez verificado, el agente intermediario completa la conexi6n a la red protegida en nombre de la fuente de la petici6n entrante.
Es conocido en la tecnica impedir el mal uso de las direcciones IP mediante un filtro en un conmutador, el cual esta conectado a un abonado. Unas tramas de datos de abonado se filtran por direcciones ilegftimas. El filtro se monta y
30 se actualiza por un operador de red.
Un conmutador de filtrado de direcciones IP de fuente dinamica, que implementa un Agente de Repetici6n DHCP, se revela en la US 2002/0023160 A1.
Resumen de la inveneian
La presente invenci6n trata con el problema mencionado anteriormente de c6mo restringir el uso de direcciones IP 35 asignadas en una red IP a las legftimas.
0tro problema es c6mo impedir a un abonado usar de por sf direcciones IP legftimas, las cuales ha obtenido el abonado en una forma ilegftima.
Aun un problema es c6mo impedir al abonado hacer un gran numero de intentos para usar ilegftimamente direcciones IP.
40 Aun otro problema es que un operador tiene que montar y actualizar un filtro para direcciones asignadas estaticamente.
El problema se resuelve mediante un dispositivo de filtro IP con identificaciones de abonado y direcciones IP correspondientes. Las tramas de datos de los abonados tienen que tener la direcci6n IP fuente correcta para pasar el dispositivo de filtro. El filtro IP es actualizado sucesivamente segun se usan nuevas direcciones IP de abonado. En
45 caso de direcciones IP que se asignan por servidores DHCP (Protocolo de Configuraci6n Central Dinamica), solamente se permiten servidores de confianza para asignar direcciones IP de abonado a los abonados.
El filtro IP es actualizado dinamicamente de la siguiente manera. Un abonado requiere una direcci6n IP. Una respuesta de direcci6n con una direcci6n IP asignada desde un servidor DHCP es analizada tanto para ser unas tramas DHCP como para venir desde uno de los servidores DHCP de confianza, cuyos servidores se senalan en 50 una lista. La direcci6n IP asignada y su tiempo de cesi6n se almacenan en el filtro IP junto con una identificaci6n del abonado. Cuando el tiempo de cesi6n se acaba la identificaci6n del abonado y la direcci6n IP son eliminadas del filtro. Nuevos abonados son almacenados sucesivamente. El trafico desde uno de los abonados tiene que tener la direcci6n IP asignada a los abonados como direcci6n fuente para pasar el filtro. Los intentos de un abonado para
usar direcciones IP ilegftimas son contados y a un numero predeterminado de intentos se genera una advertencia. Un prop6sito con la invenci6n es restringir el uso de direcciones IP a las legftimas. 0tro prop6sito es impedir a un abonado usar de por sf direcciones IP legftimas las cuales, el abonado haya obtenido
en una manera ilegftima.
Todavfa un prop6sito es c6mo impedir al abonado hacer un gran numero de intentos para usar ilegftimamente direcciones IP. Aun otro prop6sito es que las limitaciones de direcciones IP mencionadas funcionaran automaticamente en un
entorno con direcciones IP asignadas dinamicamente. La invenci6n tiene la ventaja de que solamente los servidores DHCP de confianza pueden asignar direcciones IP. 0tra ventaja es que un abonado puede usar solamente direcciones IP legftimas obtenidas de una forma legftima. Una ventaja adicional es que es posible impedir intentos repetidos para obtener direcciones IP. Aun otra ventaja es que un abonado, que pretende emplear mal la red, no puede hacer el seguimiento mas diffcil
usando una direcci6n IP obtenida ilegftimamente.
Tambien, son ventajas que un operador no necesita montar y actualizar un filtro, un proceso automatizado no esta afectado por errores humanos y la gesti6n del sistema es barata. La invenci6n se describira ahora mas estrechamente con la ayuda de las realizaciones en conexi6n con los dibujos
adjuntos.
Breve deseripeian de los dibujos
La Figura 1 muestra una vista sobre una red IP;
La Figura 2 muestra un esquema de bloques sobre un conmutador;
La Figura 3 muestra una tabla en el conmutador;
La Figura 4 muestra un esquema de bloques sobre una trama IP;
La Figura 5 muestra un diagrama de flujo para procedimientos en el conmutador;
La Figura 6 muestra un esquema de bloques sobre una lista;
La Figura 7 muestra un esquema de bloques sobre un contador; y
La Figura 8 muestra un diagrama de flujo para procedimientos alternativos en el conmutador. Deseripeian detallada La Figura 1 muestra una vista sobre una red IP simple 1. La red 1 incluye una red central 2 la cual esta conectada a un proveedor de servicios 3, servidores DHCP 4, 4a y 4b y a un conmutador 5 a traves de un puerto PN de enlace ascendente. El conmutador a su vez incluye un motor conmutador 8, el cual esta conectado a una base de datos 7 y un dispositivo de filtro IP 9. El dispositivo de filtro esta conectado a los puertos ffsicos del conmutador P1, P2, P3 para abonados. Un dispositivo de abonado 6 esta conectado a la red central 2 a traves del filtro IP 9 en el conmutador 5. El dispositivo de abonado 6 tiene de manera convencional una direcci6n MAC MAC1 y esta conectado al puerto ffsico P1 del conmutador y a una LAN virtual LAN1 en ese puerto. Tambien, un abonado 6A con una direcci6n MAC MAC2 esta conectado al puerto con la identificaci6n P2 en una LAN VLAN2 virtual y el conmutador tambien tiene un puerto P3 adicional.
La asignaci6n de direcciones dinamica convencional funciona en resumen de la siguiente manera. Un abonado en una red IP convencional con asignaci6n de direcciones dinamica quiere tener una direcci6n IP, por la cual ha pagado. El entonces transmite una petici6n DHCP (Protocolo de Configuraci6n Dinamica de Servidor). Un servidor DHCP senala la petici6n y responde con una direcci6n IP y un intervalo de tiempo de cesi6n para la direcci6n. El abonado ahora puede comunicar con otros abonados o un proveedor de servicios a traves de la red. Un abonado con intenciones de abusar puede adquirir una direcci6n IP de una manera ilegftima, lo cual hace mas diffcil rastrearle en la red. El abonado puede por ejemplo obtener la direcci6n de un servidor DHCP fraudulento o puede el mismo escribir una direcci6n que pertenece a alguien mas o que no esta actualmente en uso. El abonado puede tambien comportarse de otras maneras inaceptables., por ejemplo requerir y obtener un gran numero de direcciones IP y por ello hacer diffcil para otros abonados obtener una direcci6n.
En resumen el conmutador 5 funciona de la siguiente manera. Para impedir el mal uso de direcciones IP asignadas
el conmutador inventivo 5 esta equipado con el filtro 5 para protecci6n de suplantaci6n de identidad de direcciones IP, que puede ser habilitado o deshabilitado por LAN virtual. El conmutador 5 tambien tiene una lista L1 sobre los de confianza de los servidores DHCP, en la realizaci6n los servidores 4, 4a y 4b. El conmutador esta configurado de forma que, cuando la protecci6n de suplantaci6n de identidades habilitada, todas las direcciones IP son bloqueadas en el puerto del conmutador de los abonados. El unico trafico permitido es el trafico DHCP a los servidores DHCP de confianza, las transmisiones DHCP y los envfos de ARP (Protocolo de Resoluci6n de Direcciones). Cuando el abonado 6 necesita una direcci6n IP transmite una petici6n DHCP. Los servidores DHCP 4, 4a, 4b leen la petici6n y responden con una trama, que indica una direcci6n IP de abonado asignada IP1 y un intervalo de tiempo de cesi6n T1 para esta direcci6n. La trama tambien tiene una direcci6n IP fuente que define el servidor DHCP respectivo. El conmutador 5 comprueba a traves de esta direcci6n IP fuente si la trama es enviada por los servidores DHCP de confianza 4, 4a, 4b en la lista. Tambien comprueba que realmente es una trama DHCP la que es recibida. El conmutador 5 tiene almacenada en la base de datos 7 la direcci6n MAC MAC1 del abonado 6, una identificaci6n de su puerto ffsico P1 y su LAN virtual VLAN1. El conmutador ahora configura dinamicamente el filtro 9, el cual incluye por abonado los siguientes valores: La direcci6n MAC de abonado MAC1, la identificaci6n del puerto del abonado P1, la LAN virtual del abonado VLAN1, la direcci6n IP de abonado recibida IP1 y el intervalo de tiempo de cesi6n T1 para la direcci6n IP. Cuando el abonado 6 envfa un mensaje el conmutador compara la direcci6n IP fuente de abonado en las tramas transmitidas con la direcci6n IP de abonado asignada IP1 en el filtro 9 en la identificaci6n del puerto del abonado P1 y la LAN virtual VLAN1. Con direcci6n IP correcta las tramas pasan el filtro, de otro modo las tramas se descartan. Cuando el intervalo de tiempo de cesi6n T1 se agota la identificaci6n de abonado y la direcci6n IP de abonado asignada IP1 es eliminada del filtro (9). Mas detalles de los procesos brevemente descritos anteriormente seran dados en conexi6n con la figura 5.
De una manera correspondiente como anteriormente el filtro IP 9 se configurara dinamicamente con valores de abonado para el abonado 6A: La identificaci6n de puerto P2, la LAN virtual VLAN2, una direcci6n IP de abonado asignada IP2, y un intervalo de tiempo de cesi6n correspondiente T2.
Las direcciones IP asignadas estaticamente pueden en una alternativa ser escritas directamente en el filtro IP 9. En otra alternativa los servidores DHCP tienen la direcci6n IP asignada estaticamente para un abonado. Esta ultima hace una petici6n DHCP convencional para su direcci6n IP estatica. El servidor DHCP senala la direcci6n MAC del abonado en la petici6n y siempre asigna la direcci6n IP asignada estaticamente del abonado. Las direcciones IP asignadas estaticamente del primer tipo pueden ser usadas por ejemplo cuando aplicaciones en un ordenador no pueden utilizar peticiones DHCP para una direcci6n IP.
En la figura 2 el conmutador es mostrado en algo mas de detalle. El filtro IP 9 esta conectado a los puertos del conmutador P1, P2 y P3 y a la base de datos 7. Esta tambien conectado al motor del conmutador 8 y a un clasificador 10. En la base de datos 7 esta almacenada la direcci6n MAC de abonado MAC1, su identificaci6n de puerto P1 y la identidad de LAN virtual VLAN1. El filtro IP 9 tiene una lista sobre los servidores DHCP de confianza y tambien una tabla de abonado, cuya lista y tabla seran descritas en conexi6n con la figura 3. El clasificador 10 comprueba si tramas de datos transmitidas vienen de o a un abonado y si el mensaje DHCP es un mensaje DHCPACK o algun otro mensaje DHCP. Que operaciones, en mas detalle, la parte del conmutador respectiva 7, 8, 9 y 10 se realizan cuando el abonado 6 hace peticiones DHCP o intercambia mensajes con la red 2 y los proveedores de servicio 3 seran descritas en conexi6n con la figura 5.
Anteriormente fue mencionado que el filtro 9 fue configurado con valores de abonado. Los valores se almacenan en una tabla de filtro TAB1, la cual se muestra en la figura 3. En un campo 31 los diferentes abonados 6, 6A son almacenados con sus direcciones MAC respectivas MAC1 y MAC2. Un campo 32 da el numero de puerto de abonado P1 respectivo P2 y un campo 33 da las identidades VLAN1 respectiva VLAN2 para las LAN virtuales del abonado. En un campo 34 las direcciones IP de abonado IP1 respectiva IP2 son escritas y en un campo 35 los intervalos de tiempo de cesi6n de la direcci6n T1 respectivo T2 son escritos. En la figura 6 se muestra una lista L1 que tiene campos 61, 62, 63 para los servidores DHCP de confianza respectivos 4, 4a y 4b con sus direcciones IP IP4, IP4a e IP4b.
La comunicaci6n en la red 1 se realiza de acuerdo con la Pila de Siete Capas TCP/IP. En la figura 4 se muestra una trama Ethernet FR1 de acuerdo con el estandar IEEE802.1q. La trama tiene un campo D1 para una direcci6n MAC de destino y un campo S1 siguiente para una direcci6n MAC fuente. Tambien tiene un campo TY2 que indica que la VLAN esta en uso. Un campo VL1 senala que LAN virtual esta afectada por una etiqueta de LAN virtual. En el ejemplo presente esta etiqueta es la identidad LAN virtual, ejemplificada por las identidades VLAN1 y VLAN2. La trama incluye un campo TY1 para definir un tipo de trama Ethernet. Un campo EPL1 contiene la carga util Ethernet que incluye una cabecera IP IPH con direcciones IP fuente y destino, el intervalo de tiempo de cesi6n y el mensaje que va a ser transmitido.
La Figura 5 es un diagrama de flujo que describe una realizaci6n de diferentes tareas que el conmutador 5 realiza. En un bloque 501 el conmutador recibe una trama entrante y esta tarea se indica mediante (1) en el bloque. En un bloque 502 se realiza una tarea (2), incluyendo la comprobaci6n de d6nde viene la trama. El conmutador tiene tanto los puertos de abonado P1, P2 y P3 como el puerto de red PN, y se comprueba en que tipo de puerto se recibe la trama.
En una alternativa 503 la trama entrante viene en uno de los puertos de abonado P1, P2 y P3. En un bloque 504 entonces se realiza una tarea (3), incluyendo una comprobaci6n de si la trama es un mensaje DHCP. Esto se comprueba comprobando los numeros de puerto fuente y destino en el mensaje en el mensaje UDP, dado que el sistema esta restringido de manera que s6lo los mensajes DHCP pueden usar el puerto 67 y 68. Si la comprobaci6n del mensaje DHCP falla implica que alguien esta usando los puertos 67 y 68 y el mensaje se descarta. Si la trama se encuentra que es un mensaje DHCP, de acuerdo con una alternativa S11, la trama es aceptada por un bloque 505. Este bloque realiza una tarea (6), la cual incluye que la trama se reenvfe y en este caso reenviada a la red central 2. Si la trama no es un mensaje DHCP, de acuerdo con una alternativa N01, se realiza una tarea (4) en un bloque 506. La tarea (4) incluye una comprobaci6n de si es valida la informaci6n fuente de la trama. Se comprueba que la direcci6n MAC fuente de la capa 2, la direcci6n IP de la capa 3, el intervalo de tiempo de cesi6n y en casos reales la identificaci6n de la LAN virtual son todos validos en el puerto real. En la presente realizaci6n en otras palabras se comprueba en la tabla TAB1 que la direcci6n MAC MAC1, la direcci6n IP IP1, el intervalo de tiempo de cesi6n T1 y la identificaci6n LAN VLAN1 son validas en el puerto P1. En una alternativa N02 la tarea de comprobaci6n (4) muestra que la informaci6n de la fuente no es valida y en un bloque 507 se realiza una tarea (5) la cual implica que se descarta la trama. En una alternativa S12 para el bloque 506 la informaci6n de la fuente es valida y la trama es aceptada en el bloque 505 realizando la tarea (6).
El bloque 502 tiene la tarea (2) por la cual puede en una alternativa 508 detectar que la trama viene de la red central 2 en el puerto PN. En un bloque 509 se realiza una tarea (7), la cual incluye la comprobaci6n de si la trama es un mensaje DHCP. En una alternativa N03, cuando la trama no es un mensaje DHCP, la trama es aceptada en el bloque 505, el cual realiza la tarea (6). En una alternativa S13, cuando la trama es un mensaje DHCP, se comprueba la trama en un bloque 510 realizando una tarea (8). Esta tarea incluye una pregunta de si el mensaje DHCP se origina desde un servidor DHCP valido, es decir es un servidor que esta almacenado en la lista L1. En una alternativa N04 el servidor no es valido y la trama es descartada en un bloque 511 realizando la tarea (5). En otra alternativa S14 el servidor es valido y se realiza una comprobaci6n en un bloque 512 realizando una tarea (9). La comprobaci6n incluye una pregunta de si la trama es un mensaje de reconocimiento DHCP. En una alternativa N05, cuando la trama no es un mensaje de reconocimiento, la trama es aceptada en el bloque 505. En una alternativa contraria S15 la trama es un mensaje de reconocimiento. Entonces se maneja en un bloque 513 realizando una tarea (10). Esta tarea incluye que la direcci6n IP de la capa 3 y el intervalo de tiempo de cesi6n sean anadidos en la base de datos 7. Entonces la informaci6n sobre la direcci6n MAC fuente de la capa 2, la direcci6n IP de la capa 3, la identificaci6n del puerto, el intervalo de tiempo de cesi6n y la identificaci6n de LAN virtual para el abonado se insertan en la tabla TAB1. La trama entonces se acepta, tarea (6) en el bloque 505.
En la figura 2 se indican que partes del conmutador 5 realizan las diferentes tareas. El filtro IP 9 realiza la tarea (1) de recibir una trama entrante, la tarea (4) que afecta a la informaci6n de la fuente de la trama, la tarea (5) que maneja el descarte de tramas, la tarea (6) que acepta una trama, la tarea (8) que maneja la pregunta del servidor DHCP valido y la tarea (10) de insertar valores en la tabla del filtro TAB1. El clasificador 10 realiza la tarea (2) de comprobar de d6nde vienen las tramas, la tarea (3) de comprobar si una trama es un mensaje DHCP de un abonado, la tarea (7) de comprobar si una trama es un mensaje DHCP de la red central y la tarea (9) de si una trama es un mensaje de reconocimiento.
En conexi6n con la figura 1 fueron brevemente descritos los procesos cuando el abonado 6 obtiene la direcci6n IP IP1 y despues envfa un mensaje. Primero el proceso de obtener la direcci6n sera mas estrechamente descrito en conexi6n con la figura 5.
El abonado 6 envfa un mensaje de descubrimiento DHCP M1 el cual es recibido por el conmutador 5 de acuerdo con el bloque 501, tarea (1). En el bloque 502, tarea (2), el origen del mensaje M1 es comprobado y de acuerdo con la alternativa 503 se decide el puerto P1. De acuerdo con el bloque 504, tarea (3) y la alternativa S11, el mensaje M1 es un mensaje DHCP que es aceptado en el bloque 505, tarea (6) y es reenviado a la red central 2.
Uno o mas de los servidores DHCP 4, 4a, 4b devuelve cada uno un mensaje de oferta DHCP M2 con una direcci6n IP ofrecida. De acuerdo con el bloque 501, tarea (1), el mensaje M2 es recibido y en el bloque 502, tarea (2), se comprueba su origen. El puerto PN se decide de acuerdo con la alternativa 508 y en el bloque 509, tarea (7), y la alternativa S13 se senala que el mensaje M2 es un mensaje DHCP. De acuerdo con el bloque 510, tarea (8) y la alternativa S14, el servidor DHCP 4 es valido. En el bloque 512, tarea (9) y la alternativa N05, el mensaje M2 se senala que no sea un mensaje de reconocimiento DHCP y en el bloque 505, tarea (6), el mensaje de oferta DHCP M2 es reenviado al abonado 6.
El abonado 6 ahora selecciona una de las direcciones IP ofrecidas, en la realizaci6n la direcci6n IP1 del servidor 4. El abonado solicita la direcci6n IP1 mediante una petici6n DHCP M3 la cual es recibida por el conmutador 5 de acuerdo con el bloque 501, tarea (1). En el bloque 502, tarea (2), se comprueba el origen del mensaje M3 y de acuerdo con la alternativa 503 se decide el puerto P1. De acuerdo con el bloque 504, tarea (3) y la alternativa S11, el mensaje M3 es un mensaje DHCP que es aceptado en el bloque 505, tarea (6) y es reenviado a la red central 2.
El seleccionado de los servidores DHCP, servidor 4, devuelve un mensaje de reconocimiento DHCP M4, confirmando la direcci6n IP ofrecida IP1. De acuerdo con el bloque 501, tarea (1), se recibe el mensaje M4 y en el bloque 502, tarea (2) se comprueba su origen. El puerto PN se decide de acuerdo con la alternativa 508 y en el
bloque 509, tarea (7), y la alternativa S13 se senala que el mensaje M4 es un mensaje DHCP. De acuerdo con el bloque 510, tarea (8) y la alternativa S14, el servidor DHCP 4 que ha enviado el mensaje M4 es valido. En el bloque 512, tarea (9) y la alternativa S15, el mensaje M4 se senala que es un mensaje de reconocimiento DHCP (DHCPACK). Entonces se maneja en el bloque 513, tarea (10) por el cual la informaci6n sobre la direcci6n MAC fuente de la capa 2 de abonado MAC1, la direcci6n IP de la capa 3 IP1 recibida, la identificaci6n de puerto P1, la identificaci6n de LAN virtual VLAN1 y el intervalo de tiempo de cesi6n T1 son insertados en la tabla TAB1. El mensaje M4 es por ello aceptado y en el bloque 505, tarea (6), el mensaje de reconocimiento DHCP M4 es reenviado al abonado 6. El abonado ahora tiene una direcci6n IP valida.
Se deberfa senalar que un abonado, por ejemplo el abonado 6, puede usar legftimamente mas de una direcci6n IP. El abonado hace un acuerdo con un operador y obtiene de esta manera legftima suscripciones adicionales para direcciones IP. El numero de direcciones IP legftimas se senala en la base de datos 7. Las direcciones IP en sf mismas son obtenidas de los servidores de confianza de la misma manera que la direcci6n IP1 y son senaladas en la tabla del filtro TAB1.
El abonado 6 ahora quiere utilizar un servicio del proveedor de servicios 3 y envfa un mensaje M5 en la figura 1. De acuerdo con el bloque 501, tarea (1), el conmutador 5 recibe el mensaje M5. En el bloque 502, tarea (2), se comprueba de d6nde viene el mensaje M5. En la alternativa 503 viene en el puerto de abonado P1. En el bloque 504, tarea (3), se comprueba si el mensaje M5 es un mensaje DHCP. Como no es asf, de acuerdo con la alternativa N01, se comprueba en la tabla TAB1, de acuerdo con el bloque 506, tarea (4), que la direcci6n MAC fuente de la capa 2 MAC1, la direcci6n IP de la capa 3 IP1, el intervalo de tiempo de cesi6n T1 y la identificaci6n de LAN virtual VLAN1 son todas validas en el puerto real P1. En la alternativa S12 la informaci6n es valida y el mensaje M5 es aceptado en el bloque 505, tarea (6). El mensaje es ahora reenviado al proveedor de servicios 3.
Si el abonado intenta enviar una trama como la trama FR1 en la figura 4 como un mensaje y usa una direcci6n IP invalida IPX en la cabecera IP IPH, esto se revela en la comprobaci6n en la tabla TAB1. De acuerdo con la alternativa N02, la trama FR1 entonces es descartada en el bloque 507, tarea (5). Se mencion6 anteriormente que un problema es c6mo impedir a los abonados, 6 y 6A, hacer un gran numero de tales intentos, para usar ilegftimamente direcciones IP. Este problema se resuelve incluyendo un contador en la tarea (5) en el filtro IP 9. En la figura 7 se muestra un esquema de bloques sobre tal contador C1. El contador tiene los campos 71, 72, 73 en los cuales estan escritos los puertos de abonado respectivos P1, P2 y P3 y el numero correspondiente n de intentos falsos, es decir intentos con direcciones IP invalidas. Tambien tiene un elemento de comparaci6n 79 en el cual esta escrito un numero N de intentos falsos permitidos. En el ejemplo el abonado 6 en el puerto P1 ha hecho un falso intento. Cuando la trama con la direcci6n invalida es descartada, se envfa un mensaje F1 al contador C1, campo 71 para el puerto P1. En este campo se fija n=1, el cual se compara con N=10, no provocando ninguna acci6n. El abonado 6A en el puerto P2 ha hecho n=11 falsos intentos. Como este numero excede el numero permitido N=10 se genera un mensaje de advertencia W1.
En la figura 8 se muestra un diagrama de flujo para una realizaci6n alternativa de los procedimientos en el conmutador 5. En un bloque 801 el conmutador recibe una trama entrante y esta tarea es, como anteriormente, indicada por (1) en el bloque. En un bloque 802 se realiza una tarea (7b), incluyendo la comprobaci6n de si la trama es una trama DHCP. Si no lo es de acuerdo con una alternativa N06, la tarea (4) se realiza en un bloque 803. Esta tarea incluye la comprobaci6n de si la informaci6n de la fuente de la trama es valida y se realiza con la ayuda de la tabla TAB1 en el filtro 9. Si la informaci6n de la fuente de la trama es invalida, de acuerdo con una alternativa N07, la trama es descartada en un bloque 804 realizando la tarea (5). Si en su lugar la informaci6n de la fuente de la trama es valida, de acuerdo con una alternativa S17, la trama es aceptada por la tarea (6) realizada en un bloque
805. Si se encuentra en el bloque 802 que la trama entrante es una trama DHCP, la alternativa S16, la tarea (7b) incluye la comprobaci6n de que tipo de puerto proviene la trama. En una alternativa 806 la trama DHCP viene en uno de los puertos de abonado P1, P2, P3 y es entonces aceptada en el bloque 805. En una alternativa 807 la trama DHCP en su lugar viene sobre el puerto PN de enlace ascendente. Entonces se comprueba en un bloque 808 por la tarea (8), la lista L1, si la trama DHCP se origina desde un servidor DHCP valido. En una alternativa N08 el servidor no es valido y la trama es descartada en un bloque 809, que realiza la tarea (5). En una alternativa S18 el servidor se encuentra que es valido y se realiza una comprobaci6n por la tarea (9) en un bloque 810. La comprobaci6n incluye la pregunta de si la trama es un mensaje de reconocimiento DHCP. Si no lo es de acuerdo con una alternativa N09, la trama es aceptada en un bloque 811, que realiza la tarea (6). En una alternativa contraria S19 la trama es una trama de reconocimiento DHCP y entonces se maneja en un bloque 812, que realiza la tarea (10). Esta tarea incluye que la direcci6n IP de la capa 3 y el intervalo de tiempo de cesi6n sean anadidos en la base de datos 7. Entonces la informaci6n sobre la direcci6n MAC fuente de la capa 2, la direcci6n IP de la capa 3, la identificaci6n del puerto, el intervalo de tiempo de cesi6n y la identificaci6n LAN virtual para el abonado se inserten en la tabla TAB1. La trama entonces es aceptada, tarea (6) en el bloque 811.
El proceso cuando el abonado 6 obtiene una direcci6n IP sera descrito muy brevemente en conexi6n con la figura 8. En la fase de descubrimiento el mensaje de descubrimiento M1 es recibido en el bloque 801 y se encuentra que es un mensaje DHCP en el bloque 802. De acuerdo con la alternativa 806 se encuentra que viene del abonado y el mensaje M1 es aceptado en el bloque 805. El mensaje de oferta DHCP M2 de los servidores DHCP se recibe en el bloque 801, encuentra que es un mensaje DHCP en el bloque 802 y encuentra que es un mensaje de respuesta de acuerdo con la alternativa 807. El servidor DHCP es uno valido de acuerdo con el bloque 808, el mensaje M2 no es mensaje de reconocimiento, bloque 810 y es aceptado en el bloque 811 y reenviado al abonado 6. Este ultimo selecciona la direcci6n IP1 y la solicita mediante el mensaje M3, el cual es recibido en el bloque 801. En el bloque 802 es senalado como un mensaje DHCP el cual viene del abonado, alternativa 806, y es aceptado en el bloque
805. El servidor obtiene el mensaje M3 y devuelve el mensaje de reconocimiento M4. En el bloque 801 se recibe el
5 mensaje M4, se encuentra que es un mensaje DHCP en el bloque 802 y que es un mensaje de respuesta, alternativa 807. La fuente del mensaje es valida, bloque 808, y el mensaje M4 se encuentra que es un mensaje de reconocimiento, bloque 810 alternativa S19. En el bloque 812 la direcci6n IP1 y su intervalo de tiempo de cesi6n T1 son anadidos en la base de datos 7 y se rellena la tabla TAB1 en el filtro IP 9. El mensaje M4 es aceptado, bloque 811, y el abonado 6 obtiene la direcci6n y su intervalo de tiempo de cesi6n T1. El abonado 6 tiene una direcci6n IP
10 valida.
Cuando el abonado 6 envfa el mensaje M5 al proveedor de servicios 3, se recibe el mensaje en el bloque 801 y se encuentra que no es un mensaje DHCP, bloque 802 alternativa N06. La informaci6n de la fuente de la trama entonces se comprueba en el bloque 803 con la ayuda de la tabla TAB1 en el filtro 9. Si es valida, alternativa S17, el mensaje M5 es aceptado y se envfa al destinatario.

Claims (8)

  1. REIVINDICACIONES
    1. Un metodo para uso en una red IP, la red que incluye un nodo conmutador (5), al menos un servidor DHCP (4, 4a, 4b) y al menos un abonado (6) que esta asociado con el nodo, el metodo incluye los siguientes pasos: -crear una lista (L1) de los de confianza de los servidores DHCP; 5 -transmitir por el abonado (6) un mensaje de petici6n DHCP (M3) para una direcci6n IP;
    -recibir un mensaje de respuesta (M4), el cual transporta una direcci6n IP de abonado asignada (IP1); -analizar (510, 808, (8)) el mensaje de respuesta para ser un mensaje DHCP y que tiene una direcci6n fuente (IP4) de uno de los servidores DHCP de confianza (4);
    -
    actualizar (513, 812, (10)) un filtro (9, TAB1) dinamicamente en el nodo (5), el filtro que almacena una 10 identificaci6n (MAC1, P1, VLAN1) del abonado (6) y la direcci6n IP de abonado asignada (IP1); -transmitir una trama (FR1) desde el abonado (6) usando una direcci6n IP fuente (IPX);
    -
    comparar en el filtro (9, TAB1) dicha direcci6n IP fuente con la direcci6n IP de abonado almacenada (IP1); -descartar dicha trama cuando dicha direcci6n IP fuente (IPX) difiere de la direcci6n IP de abonado almacenada (IP1).
    15 2. Un metodo para uso en una red IP de acuerdo con la reivindicaci6n 1, el metodo que incluye almacenar en el filtro (9, TAB1) una direcci6n MAC de abonado (MAC1), un numero de puerto ffsico de abonado (P1), una LAN virtual (VLAN1) y un intervalo de tiempo de cesi6n (T1) para la direcci6n IP de abonado asignada (IP1).
  2. 3. Un metodo para uso en una red IP de acuerdo con la reivindicaci6n 1, la direcci6n IP de abonado que se asigna estaticamente y maneja por los servidores DHCP (4, 4a, 4b).
    20 4. Un metodo para uso en una red IP de acuerdo con la reivindicaci6n 2, el metodo que incluye eliminar la identificaci6n de abonado (MAC1, P1, VLAN1) y la direcci6n IP de abonado asignada correspondiente (IP1) del filtro (9, TAB1) cuando el intervalo de tiempo de cesi6n (T1) se agota.
  3. 5. Un metodo para uso en una red IP de acuerdo con la reivindicaci6n 1, 2, 3 o 4, el metodo que incluye: -contar un numero de intentos (n) del abonado (6A) para usar una direcci6n IP ilegftima; 25 -comparar (9, C1) el numero (n) de los intentos con un numero umbral (N);
    -
    enviar una senal de advertencia (W1) cuando el numero de intentos (n=11) excede unos criterios umbral (N=10).
  4. 6. Un dispositivo para uso en una red IP, el dispositivo (5) que incluye:
    -
    al menos un puerto (P1, P2, P3) para un abonado (6, 6A);
    30 -un puerto (PN) de enlace ascendente para servidores DHCP en la red (1); y
    -
    un dispositivo de filtro (9) que tiene una lista (L1) sobre los de confianza de los servidores DHCP (4, 4a, 4b), el dispositivo de filtro (9) que esta asociado con los puertos (P1, P2, P3; PN),
    en el que
    -
    el dispositivo (5) esta dispuesto para recibir un mensaje de petici6n de direcci6n IP de abonado (M3) en el 35 puerto de abonado (P1), analizar que sea un mensaje DHCP y transmitirlo en el puerto (PN) de enlace ascendente;
    -
    el dispositivo (5) esta dispuesto para recibir un mensaje de respuesta (M4) en el puerto (PN) de enlace ascendente, analizar que sea un mensaje DHCP y tener una direcci6n IP fuente (IP4) de uno de los servidores DHCP de confianza en la lista (L1);
    40 -el dispositivo (5) esta dispuesto para actualizar dinamicamente el filtro (9, TAB1) con una identificaci6n del abonado (6) y una direcci6n IP de abonado asignada correspondiente (IP1) en el mensaje de respuesta (M4);
    -
    el dispositivo esta dispuesto para recibir una trama (FR1) con una direcci6n IP fuente (IPX) en el puerto de abonado (P2);
    -
    el dispositivo esta dispuesto para comparar en el filtro (9, TAB1) dicha direcci6n IP fuente (IPX) con la direcci6n 45 IP de abonado almacenada (IP1); y -el dispositivo esta dispuesto para descartar dicha trama (FR1) cuando dicha direcci6n IP fuente (IPX) difiere de la direcci6n IP de abonado almacenada (IP1).
  5. 7. Un dispositivo para uso en una red IP de acuerdo con la reivindicaci6n 6, el dispositivo que esta dispuesto para almacenar en el filtro (9, TAB1) una direcci6n MAC de abonado (MAC1), un numero de puerto ffsico de abonado
    5 (P1), una identidad LAN virtual de abonado (VLAN1) y un intervalo de tiempo de cesi6n (T1) para la direcci6n IP de abonado asignada (IP1).
  6. 8.
    Un dispositivo para uso en una red IP de acuerdo con la reivindicaci6n 6, la direcci6n IP de abonado que es una direcci6n asignada estaticamente la cual se maneja por los servidores DHCP (4, 4a, 4b).
  7. 9.
    Un dispositivo para uso en una red IP de acuerdo con la reivindicaci6n 7, el dispositivo (5) que esta dispuesto
    10 para eliminar la identificaci6n de abonado (MAC1, P1, VLAN1) y la direcci6n IP de abonado asignada correspondiente (IP1) del filtro (9, TAB1) cuando el intervalo de tiempo de cesi6n (T1) se agota.
  8. 10. Un dispositivo para uso en una red IP de acuerdo con la reivindicaci6n 6, 7, 8 o 9, el filtro (9) que tiene un contador (C1) que se dispone a contar un numero (n) de tramas descartadas (FR1) en el puerto de abonado (P2), comparar (9, C1) el numero (n) de las tramas descartadas con un numero umbral (N) y enviar una senal de
    15 advertencia (W1) cuando el numero de tramas descartadas (n=11) excede un criterio umbral (N=10).
ES02783924T 2002-11-06 2002-11-06 Método y adaptación para impedir el uso ilegítimo de direcciones IP Expired - Lifetime ES2384377T3 (es)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/SE2002/002021 WO2004042999A1 (en) 2002-11-06 2002-11-06 Method and arrangement for preventing illegitimate use of ip addresses

Publications (1)

Publication Number Publication Date
ES2384377T3 true ES2384377T3 (es) 2012-07-04

Family

ID=32310983

Family Applications (2)

Application Number Title Priority Date Filing Date
ES02783924T Expired - Lifetime ES2384377T3 (es) 2002-11-06 2002-11-06 Método y adaptación para impedir el uso ilegítimo de direcciones IP
ES12162215T Expired - Lifetime ES2433272T3 (es) 2002-11-06 2002-11-06 Un método y un dispositivo en una red IP

Family Applications After (1)

Application Number Title Priority Date Filing Date
ES12162215T Expired - Lifetime ES2433272T3 (es) 2002-11-06 2002-11-06 Un método y un dispositivo en una red IP

Country Status (8)

Country Link
US (2) US7996537B2 (es)
EP (3) EP2472823B1 (es)
CN (1) CN100490377C (es)
AT (1) ATE552692T1 (es)
AU (1) AU2002347725A1 (es)
DK (1) DK2472823T3 (es)
ES (2) ES2384377T3 (es)
WO (1) WO2004042999A1 (es)

Families Citing this family (53)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
USRE47253E1 (en) * 2002-11-06 2019-02-19 Telefonaktiebolaget Lm Ericsson (Publ) Method and arrangement for preventing illegitimate use of IP addresses
US7577735B1 (en) 2002-11-27 2009-08-18 Cisco Technology, Inc. Transparent mode
CN1277373C (zh) * 2003-05-07 2006-09-27 华为技术有限公司 网络通信系统中用户位置信息的传递方法
US7516487B1 (en) * 2003-05-21 2009-04-07 Foundry Networks, Inc. System and method for source IP anti-spoofing security
US7562390B1 (en) * 2003-05-21 2009-07-14 Foundry Networks, Inc. System and method for ARP anti-spoofing security
US20040255154A1 (en) * 2003-06-11 2004-12-16 Foundry Networks, Inc. Multiple tiered network security system, method and apparatus
US7876772B2 (en) 2003-08-01 2011-01-25 Foundry Networks, Llc System, method and apparatus for providing multiple access modes in a data communications network
US7735114B2 (en) * 2003-09-04 2010-06-08 Foundry Networks, Inc. Multiple tiered network security system, method and apparatus using dynamic user policy assignment
US7774833B1 (en) * 2003-09-23 2010-08-10 Foundry Networks, Inc. System and method for protecting CPU against remote access attacks
US8528071B1 (en) 2003-12-05 2013-09-03 Foundry Networks, Llc System and method for flexible authentication in a data communications network
DE502004008199D1 (de) * 2004-01-23 2008-11-20 Siemens Ag Verfahren zur Zuordnung einer IP-Adresse zu einem Gerät
US20050262218A1 (en) * 2004-04-30 2005-11-24 Cox Gabriel C System and method for DHCP-based assignment of IP addresses to servers based on geographic identifiers
EP1792465A1 (en) * 2004-09-20 2007-06-06 Matsushita Electric Industrial Co., Ltd. Return routability optimisation
FR2881592A1 (fr) * 2005-02-02 2006-08-04 France Telecom Procede et dispositif de detection d'usurpations d'adresse dans un reseau informatique
US7756976B2 (en) * 2005-03-18 2010-07-13 Hewlett-Packard Development Company, L.P. Systems and methods for denying rogue DHCP services
US20060225128A1 (en) * 2005-04-04 2006-10-05 Nokia Corporation Measures for enhancing security in communication systems
CN100442706C (zh) * 2005-04-19 2008-12-10 华为技术有限公司 一种使维护节点标识与媒体访问控制地址对应的方法
GB2425681A (en) 2005-04-27 2006-11-01 3Com Corporaton Access control by Dynamic Host Configuration Protocol snooping
JP4161981B2 (ja) * 2005-05-31 2008-10-08 ブラザー工業株式会社 通信装置、及び、プログラム
EP1739929B1 (en) * 2005-06-29 2012-05-30 Alcatel Lucent Method to forward downstream message and network unit realizing said method
US7778250B2 (en) * 2005-08-11 2010-08-17 Ericsson Ab Method and apparatus for securing a layer II bridging switch/switch for subscriber aggregation
CN101022472B (zh) * 2006-02-13 2010-06-09 中兴通讯股份有限公司 一种对消息接口异常的预防保护方法
CN1835514B (zh) * 2006-03-31 2010-05-12 北京润汇科技有限公司 Dhcp+客户端模式的宽带接入的管理方法
CN101083670B (zh) * 2006-06-02 2010-09-29 鸿富锦精密工业（深圳）有限公司 地址分配系统及方法
JP4825724B2 (ja) * 2006-06-09 2011-11-30 株式会社リコー ネットワーク機器
US8331266B2 (en) * 2006-06-14 2012-12-11 Nokia Siemens Networks Oy LAN topology detection and assignment of addresses
CN101098290B (zh) * 2006-06-29 2011-04-06 中兴通讯股份有限公司 一种在an上实现ip地址防欺骗的装置及其方法
CN101471966B (zh) * 2006-07-06 2011-07-20 华为技术有限公司 一种防止ip地址泄露的系统和设备
US8625456B1 (en) * 2006-09-21 2014-01-07 World Wide Packets, Inc. Withholding a data packet from a switch port despite its destination address
EP2074747B1 (en) 2006-09-28 2015-08-05 PacketFront Network Products AB Method for automatically providing a customer equipment with the correct service
US20080089323A1 (en) * 2006-10-13 2008-04-17 At&T Knowledge Ventures, L.P. System and method for assigning virtual local area networks
CN101641933A (zh) * 2006-12-22 2010-02-03 艾利森电话股份有限公司 电子欺骗的防止
CN100563149C (zh) * 2007-04-25 2009-11-25 华为技术有限公司 一种dhcp监听方法及其装置
CN100586106C (zh) * 2007-05-22 2010-01-27 华为技术有限公司 报文处理方法、系统和设备
JP5164450B2 (ja) * 2007-06-28 2013-03-21 キヤノン株式会社 通信装置及びその制御方法とプログラム
CN101115063B (zh) * 2007-08-30 2011-11-30 中兴通讯股份有限公司 宽带接入设备中防止mac地址/ip地址欺骗的方法
US20090086639A1 (en) * 2007-09-27 2009-04-02 Verizon Services Corp. Testing dynamically addressed network devices
JP5104426B2 (ja) * 2008-03-13 2012-12-19 パナソニック株式会社 画像表示装置
EP2579509A1 (en) * 2010-06-07 2013-04-10 Huawei Technologies Co., Ltd. Method, device and system for service configuration
JP5385872B2 (ja) 2010-07-27 2014-01-08 パナソニック株式会社 通信制御装置、通信システム及びプログラム
CN101984693A (zh) * 2010-11-16 2011-03-09 中兴通讯股份有限公司 终端接入局域网的监控方法和监控装置
CN106388888B (zh) 2011-04-15 2019-12-27 心脏缝合有限公司 用于缝合解剖学瓣的缝合装置和方法
WO2013134810A1 (en) * 2012-03-12 2013-09-19 Zeptoip Pty Ltd A network device and a method for networking
US8855117B2 (en) * 2012-08-08 2014-10-07 Cisco Technology, Inc. Scalable media access control protocol synchronization techniques for fabric extender based emulated switch deployments
US8869275B2 (en) * 2012-11-28 2014-10-21 Verisign, Inc. Systems and methods to detect and respond to distributed denial of service (DDoS) attacks
WO2016009562A1 (ja) * 2014-07-18 2016-01-21 三菱電機株式会社 Ｉｐアドレス配布システム、スイッチ装置、およびｉｐアドレス配布方法
WO2016148676A1 (en) 2015-03-13 2016-09-22 Hewlett Packard Enterprise Development Lp Determine anomalous behavior based on dynamic device configuration address range
CN107046585A (zh) * 2017-03-30 2017-08-15 百富计算机技术（深圳）有限公司 Dhcp服务器选择方法和装置
CN109391586A (zh) * 2017-08-04 2019-02-26 深圳市中兴微电子技术有限公司 一种防止静态ip非法上网的装置及方法、onu设备和pon系统
WO2019113728A1 (zh) * 2017-12-11 2019-06-20 华为技术有限公司 一种网络及网络管理方法
US12489731B1 (en) * 2018-02-21 2025-12-02 F5, Inc. Methods for enforcing firewall and security policies based on subscriber identification and devices thereof
US11831420B2 (en) 2019-11-18 2023-11-28 F5, Inc. Network application firewall
US20230412594A1 (en) * 2022-06-20 2023-12-21 Micro Focus Llc Tying addresses to authentication processes

Family Cites Families (18)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0520709A3 (en) 1991-06-28 1994-08-24 Digital Equipment Corp A method for providing a security facility for remote systems management
US5826014A (en) 1996-02-06 1998-10-20 Network Engineering Software Firewall system for protecting network elements connected to a public network
US5884024A (en) 1996-12-09 1999-03-16 Sun Microsystems, Inc. Secure DHCP server
CN1243366A (zh) * 1998-07-29 2000-02-02 蒋林涛 产品防伪通信信息系统
US6374295B2 (en) * 1998-10-29 2002-04-16 Nortel Networks Limited Active server management
US7188180B2 (en) * 1998-10-30 2007-03-06 Vimetx, Inc. Method for establishing secure communication link between computers of virtual private network
US6427170B1 (en) * 1998-12-08 2002-07-30 Cisco Technology, Inc. Integrated IP address management
US6393484B1 (en) * 1999-04-12 2002-05-21 International Business Machines Corp. System and method for controlled access to shared-medium public and semi-public internet protocol (IP) networks
US7281036B1 (en) * 1999-04-19 2007-10-09 Cisco Technology, Inc. Method and apparatus for automatic network address assignment
US7079499B1 (en) * 1999-09-08 2006-07-18 Nortel Networks Limited Internet protocol mobility architecture framework
FI110975B (fi) * 1999-12-22 2003-04-30 Nokia Corp Huijaamisen estäminen tietoliikennejärjestelmissä
US7065578B2 (en) 2000-03-20 2006-06-20 At&T Corp. Service selection in a shared access network using policy routing
US20020065919A1 (en) * 2000-11-30 2002-05-30 Taylor Ian Lance Peer-to-peer caching network for user data
US7127524B1 (en) * 2000-12-29 2006-10-24 Vernier Networks, Inc. System and method for providing access to a network with selective network address translation
US7139818B1 (en) * 2001-10-04 2006-11-21 Cisco Technology, Inc. Techniques for dynamic host configuration without direct communications between client and server
US7191331B2 (en) * 2002-06-13 2007-03-13 Nvidia Corporation Detection of support for security protocol and address translation integration
US7139828B2 (en) * 2002-08-30 2006-11-21 Ip Dynamics, Inc. Accessing an entity inside a private network
US7412515B2 (en) * 2002-09-26 2008-08-12 Lockheed Martin Corporation Method and apparatus for dynamic assignment of network protocol addresses

Also Published As

Publication number Publication date
US20060155853A1 (en) 2006-07-13
ES2433272T3 (es) 2013-12-10
CN1695341A (zh) 2005-11-09
EP2472823B1 (en) 2013-09-18
EP1559237B1 (en) 2012-04-04
EP2472823A1 (en) 2012-07-04
EP1559237A1 (en) 2005-08-03
US7996537B2 (en) 2011-08-09
ATE552692T1 (de) 2012-04-15
CN100490377C (zh) 2009-05-20
USRE45445E1 (en) 2015-03-31
EP2472824A1 (en) 2012-07-04
EP2472824B1 (en) 2013-09-18
WO2004042999A1 (en) 2004-05-21
DK2472823T3 (da) 2013-12-16
AU2002347725A1 (en) 2004-06-07

Similar Documents

Publication Publication Date Title
ES2433272T3 (es) Un método y un dispositivo en una red IP
CN101199166B (zh) 接入节点、接入点、接入服务器、连接到业务提供网络的方法
EP1779589B1 (en) Arrangement for tracking ip address usage based on authenticated link identifier
US6047325A (en) Network device for supporting construction of virtual local area networks on arbitrary local and wide area computer networks
Ullrich et al. {IPv6} security: Attacks and countermeasures in a nutshell
US8209529B2 (en) Authentication system, network line concentrator, authentication method and authentication program
US20170237769A1 (en) Packet transfer method and packet transfer apparatus
Data The defense against arp spoofing attack using semi-static arp cache table
CN111654485B (zh) 一种客户端的认证方法以及设备
JPWO2015174100A1 (ja) パケット転送装置、パケット転送システム及びパケット転送方法
US7613179B2 (en) Technique for tracing source addresses of packets
US20050237946A1 (en) Suppression of router advertisement
Bagnulo et al. SAVI: The IETF standard in address validation
US20180097776A1 (en) Network protection entity and method for protecting a communication network against fraud messages
USRE47253E1 (en) Method and arrangement for preventing illegitimate use of IP addresses
Gont IPv6 Security for IPv4 Engineers
Bagnulo Braun et al. SAVI: The IETF Standard in Address Validation
Wong et al. Protecting Network Infrastructure–A New Approach
Liu Network Working Group F. Gont Internet-Draft SI6 Networks/UTN-FRH Intended status: Informational R. Bonica Expires: April 25, 2014 Juniper Networks