ES2362993T3 - Un método y disposición para proporcionar seguridad a través de conversión de direcciones de red utilizando tunelado y compensaciones. - Google Patents
Un método y disposición para proporcionar seguridad a través de conversión de direcciones de red utilizando tunelado y compensaciones. Download PDFInfo
- Publication number
- ES2362993T3 ES2362993T3 ES00936931T ES00936931T ES2362993T3 ES 2362993 T3 ES2362993 T3 ES 2362993T3 ES 00936931 T ES00936931 T ES 00936931T ES 00936931 T ES00936931 T ES 00936931T ES 2362993 T3 ES2362993 T3 ES 2362993T3
- Authority
- ES
- Spain
- Prior art keywords
- computer device
- packets
- protocol
- conversions
- network
- 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
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
- H04L12/46—Interconnection of networks
- H04L12/4633—Interconnection of networks using encapsulation techniques, e.g. tunneling
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L61/00—Network arrangements, protocols or services for addressing or naming
- H04L61/09—Mapping addresses
- H04L61/25—Mapping addresses of the same type
- H04L61/2503—Translation of Internet protocol [IP] addresses
- H04L61/256—NAT traversal
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L45/00—Routing or path finding of packets in data switching networks
- H04L45/02—Topology update or discovery
- H04L45/026—Details of "hello" or keep-alive messages
-
- 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
-
- 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
-
- 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
-
- 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/255—Maintenance or indexing of mapping tables
- H04L61/2553—Binding renewal aspects, e.g. using keep-alive messages
-
- 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/2578—NAT traversal without involvement of the NAT server
-
- 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
-
- 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/0272—Virtual private networks
-
- 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/029—Firewall traversal, e.g. tunnelling or, creating pinholes
-
- 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/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
-
- 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/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
- H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/16—Implementing security features at a particular protocol layer
- H04L63/164—Implementing security features at a particular protocol layer at the network layer
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/50—Network services
- H04L67/56—Provisioning of proxy services
- H04L67/568—Storing data temporarily at an intermediate stage, e.g. caching
-
- 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]
- H04L69/165—Combined use of TCP and UDP protocols; selection criteria therefor
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L2101/00—Indexing scheme associated with group H04L61/00
- H04L2101/60—Types of network addresses
- H04L2101/618—Details of network addresses
- H04L2101/663—Transport layer addresses, e.g. aspects of transmission control protocol [TCP] or user datagram protocol [UDP] ports
-
- 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 Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer Security & Cryptography (AREA)
- General Engineering & Computer Science (AREA)
- Computing Systems (AREA)
- Computer Hardware Design (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
- Small-Scale Networks (AREA)
- Burglar Alarm Systems (AREA)
- Exchange Systems With Centralized Control (AREA)
- Computer And Data Communications (AREA)
- Radio Relay Systems (AREA)
Abstract
Procedimiento para la comunicación segura de paquetes entre un primer dispositivo de ordenador (181, INICIADOR) y un segundo dispositivo de ordenador (185, RESPONDEDOR) a través de una red (184) de transmisión de datos basada en conmutación de paquetes que incluye dispositivos de ordenador intermedios (183, 187, 305), donde al menos uno de los citados dispositivos de ordenador mencionados realiza una conversión de direcciones de red y/o una conversión de protocolo, caracterizado porque dicho procedimiento comprende los pasos consistentes en: - determinar qué conversiones de direcciones de red deben tener lugar, caso de haberla, en los paquetes transmitidos entre el primer dispositivo de ordenador y el segundo dispositivo de ordenador, - con el fin de habilitar el traslado de las conversiones de direcciones de red que se hayan determinado, tomar paquetes (301) acordes con un primer protocolo y encapsularlos (302) en paquetes acordes con un segundo protocolo, cuyo segundo protocolo sea capaz de trasladar conversiones de direcciones de red, - transmitir desde un primer dispositivo de ordenador al segundo dispositivo de ordenador los citados paquetes acordes con el segundo protocolo mencionado y - con el fin de invertir la encapsulación (302) que se realizó para posibilitar el traslado de las conversiones de direcciones de red, desencapsular (303) dichos paquetes transmitidos según el citado segundo protocolo para transformarlos en paquetes (304) acordes con el citado primer protocolo.
Description
La invención se refiere en general al campo de las comunicaciones seguras entre ordenadores en redes de transmisión de datos basadas en conmutación de paquetes. Más concretamente, el invento se refiere al campo de la implementación y mantenimiento de conexiones de comunicaciones seguras a través de una Conversión o Transformación de direcciones de red (NAT: Network Adress Translation) o conversión de protocolo.
El Grupo de Trabajo de Ingeniería de Internet (IETF) ha normalizado el conjunto de programas (suite) de protocolo IPSEC (Internet Protocol Security); las normas se conocen bien a través de los Request For Comments o documentos RFC números RFC2401, RFC2402, RFC2406, RFC2407, RFC2408 y RFC2409 que se mencionan en la lista de referencias anexa. Los protocolos IPSEC proporcionan seguridad al Protocolo de Internet o IP especificado en sí mismo en el documento RFC791. IPSEC realiza la autenticación y encriptación a nivel de paquete generando una nueva cabecera IP que añade delante del paquete una Cabecera de Autenticación (AH) o una cabecera de Carga (Payload) de Seguridad de Encapsulación (ESP). El paquete original se autentica criptográficamente y puede ser encriptado opcionalmente. El método usado para autenticar y encriptar opcionalmente un paquete se identifica mediante un valor de índice de parámetros de seguridad (SPI) almacenado en las cabeceras AH y ESP. El documento RFC número RFC2401 especifica un modo de transporte y un modo de entunelación (tunnelling) para paquetes; el presente invento puede aplicarse con independencia de cuál de estos métodos sea el utilizado.
En los últimos años, cada vez más fabricantes y proveedores de servicios de Internet han empezado a desarrollar la conversión de direcciones de red (NAT). Se encuentran referencias a NAT al menos en el documento RFC número RFC1631, así como en los documentos que están identificados en la lista de referencias anexa como Srisuresh98Terminology, SrisureshEgevang98, Srisuresh98Scurity, HoldregeSrisuresh99, TYS99, Rekhter99, LoBorella99 y BorellaLo99. Hay dos formas fundamentales de conversión de direcciones, ilustradas de forma esquemática en Figs. 1a y 1b: el equipo NAT 101 y el puerto NAT 151. El equipo NAT sólo convierte las direcciones IP en un paquete entrante 102 de modo que un paquete saliente 103 tiene una dirección IP distinta. El puerto NAT 151 también toca los números puerto TCP y UDP (Protocolo de Control de Tráfico; Protocolo de Datagrama de Usuario) en un paquete entrante 152, multiplexando varias direcciones IP a una sola dirección IP en un paquete saliente 153 y desmultiplexando correspondientemente una dirección IP simple en diversas direcciones IP para paquetes que viajan en el sentido contrario (no mostrado). Los puertos NAT son especialmente habituales en los entornos domésticos y de pequeñas oficinas. En las Figs. 1a y 1b se muestra, solamente con fines de claridad gráfica, la separación física de las conexiones de entrada y salida para dispositivos NAT; en la práctica hay muchas formas posibles de conectar físicamente una NAT.
La conversión de direcciones de red tiene lugar más frecuentemente en el extremo o borde de las redes locales (es decir, conversión entre múltiples direcciones locales privadas por un lado y unas pocas direcciones públicas encaminables globalmente en el otro). La mayoría de las veces se utiliza un puerto NAT y hay una sola dirección encaminable globalmente. En la Fig. 1b se ilustra de forma esquemática un red local 154. Este tipo de disposiciones se están haciendo extremadamente comunes en los mercados domésticos y pequeñas oficinas. Algunos proveedores de servicios de Internet han empezado también a dar a sus clientes direcciones privadas y a realizar la conversión de direcciones de red de dichas direcciones en sus redes básicas. En general, la conversión de direcciones de red se ha analizado ampliamente y en profundidad, por ejemplo en el grupo de trabajo NAT dentro de Internet Engineering Task Force. Los principios operativos de un dispositivo NAT son ampliamente conocidos, y existen muchas implementaciones de múltiples proveedores disponibles en el mercado, incluidas varias implementaciones con códigos fuentes de acceso gratis. La operación típica de un NAT se puede describir de modo que mapea direcciones IP y combinaciones de puertos para diferentes direcciones IP y combinaciones de puertos. El mapeo se mantendrá constante durante la duración de una conexión de red, pero puede cambiar (despacio) con el tiempo. En la práctica, la funcionalidad de NAT se integra con frecuencia en un cortafuego o un encaminador.
La Fig. 1c ilustra un ejemplo práctico del caso de una comunicación de red en la que un nodo de transmisión 181 está ubicado en una primera red de área local (también conocida como la primera red privada) 182, que tiene un puerto NAT 183 para conectarse a una red general 184 de transmisión de datos basada en conmutación de paquetes de amplia área, como la Internet. Esta última consta de un gran número de nodos interconectados de forma arbitraria. Un nodo receptor 185 se sitúa en una segunda red de área local 186 que está a su vez acoplada a una red de área-ancha a través de un NAT 187. Las denominaciones “nodo transmisor” y “nodo receptor” son algo engañosas, dado que se necesita una comunicación bidireccional para establecer una red de servicios segura. El nodo de transmisión es el que inicia la comunicación. También se utilizan los términos “Iniciador” y “Respondedor” para el nodo transmisor y el nodo receptor, respectivamente.
El propósito de la Fig. 1c es enfatizar el hecho de que los nodos de comunicación no se percatan ni del número o la naturaleza de los dispositivos intermedios a través de los cuales se comunican ni de la naturaleza de las transformaciones que tienen lugar. Además de las NATs, hay otro tipo de dispositivos en la red de Internet que pueden modificar legalmente paquetes durante su transmisión. Un ejemplo típico es el convertidor de protocolo, cuya principal función es convertir el paquete en un protocolo diferente sin perturbar la operación normal. Su uso conlleva problemas muy similares al caso de la NAT. Un ejemplo bastante sencillo pero importante es la conversión entre IPv4 e IPv6, que son diferentes versiones del Protocolo de Internet. Los mencionados convertidores serán extremadamente importantes y comunes en un futuro próximo. Un paquete puede sufrir numerosas conversiones de este tipo a lo largo de su recorrido, y es posible que los puntos finales de las comunicaciones utilicen de hecho un protocolo diferente. Lo mismo que NAT, la conversión de protocolo tiene lugar habitualmente en encaminadores y cortafuegos.
En la comunidad IPSEC se sabe bien que el protocolo IPSEC no funciona adecuadamente en las conversiones de direcciones de red. Este problema se ha analizado en al menos los documentos referidos como HoldregeSrisuresh99 y Rekhter99.
En la solicitud de patente finlandesa número 974665 y la correspondiente solicitud PCT número FI98/701032 (publicada en 15 de Julio de 1999 como WO-A-99/35799) se ha presentado un determinado método para realizar conversión de direcciones IPSEC y un método de autenticación de paquetes que es sensible a las conversiones de direcciones y conversiones de protocolo en ruta del paquete. En dichas solicitudes se ha presentado adicionalmente un dispositivo de red transmisora y un dispositivo de red receptora que son capaces de utilizar las ventajas del método mencionado anteriormente. Sin embargo, en dichas solicitudes de patentes previas permanecen sin resolverse algunos de los problemas relativos al suministro de servicios de seguridad en red sobre conversión de direcciones de red.
La patenten US-A-5 793 763 proporciona un sistema y un método para convertir direcciones locales IP a una única dirección IP global de acuerdo con el bien conocido principio de las redes NAT. Los paquetes que llegan de la red Internet se apantallan mediante un algoritmo de seguridad adaptable.
La publicación WO-A-98/32065 muestra cómo se conecta un dispositivo de seguridad en red entre un cliente protegido y una red. El dispositivo de seguridad en red negocia una clave de sesión con cualquier otro cliente protegido. De este modo, quedan encriptadas todas las comunicaciones entre los dos clientes. El dispositivo de seguridad realiza la conversión de direcciones entre la dirección del cliente y su propia dirección antes de transmitir los paquetes a la red y después de haber recibido los paquetes de la red.
Otras publicaciones del estado de la técnica anterior son: DATA COMMUNICATIONS, MCGRAW HILL, NEW YORK, US, Journal Article, Vol.26, Nr. 16, Noviembre de 97, páginas 55-59, Rodney Thayer: Bulletproof IP with authentication and encryption, IPSec adds a layer of armor to IP”; IEEE, COMPUTER, Vol. 31, Issue 9, Septiembre de 1998, páginas 43-47, Rolph Oppliger: “Security at the Internet Layer”, ISSN: 0018-9162; IETF, Internet Draft, 06.02.98, RG. Moskowitz: “Network Address Translation issues with IPsec”, <URL:http:/www.alternic.org/drafts/drafts-m-n/draft-moskowitz-net66-vpn-00.txt>; IETF, Internet Draft, 22.08.97, RG. Moskowitz: “Network Address Translation issues with IPsec”, <URL:http:/www.alternic.org/drafts-m-n/draftmoskowitz-net66-vpn-nat-00.txt>; e IETF, Internet Draft, 04.98, G. Tsirtis: “AATN Components & Mechanism”, <URL:http:/www.alternic.org/drafts/drafts-t-u/draft-tsirtis-aatn-mech-00.txt>. Estas publicaciones describen diversos aspectos ya conocidos de las NATs y aseguran la transmisión en redes de paquetes de datos.
Es un objetivo de la presente invención presentar un método y los correspondientes dispositivos para proporcionar servicios de seguridad en red sobre conversión de direcciones de red de forma fiable y ventajosa.
Esto se consigue con los métodos definidos por las reivindicaciones independientes 1, 21 y 22 y los aparatos descritos en las reivindicaciones independientes 24 y 25.
La Fig. 1a ilustra el uso conocido de un equipo NAT,
La Fig. 2b ilustra el uso conocido de un puerto NAT,
La Fig. 1c ilustra una conexión de comunicación conocida entre nodos a través de una red de transmisión de datos basada en conmutación de paquetes,
La Fig. 2a ilustra una cierta carga de proveedor ID aplicable dentro del contexto de la invención,
La Fig. 2b. ilustra una cierta carga neta (payload) privada aplicable dentro del contexto de la invención,
La Fig. 2c ilustra una cierta estructura de cabecera combinada aplicable dentro del contexto de la invención,
La Fig. 3 ilustra ciertos pasos del método relativos a la aplicación de la invención,
La Fig. 4 ilustra una transformación de estructuras de cabecera acordes con un aspecto de la invención, y
La Fig. 5 ilustra un diagrama de bloques simplificado de un dispositivo de red utilizado para implementar el método de acuerdo con la invención.
La presente invención combina y amplía algunos de los métodos de conversión de direcciones de red, entunelación sobre UDP, IKE y los mecanismos de extensión IKE, de una forma nueva y con actividad inventiva para producir un método para comunicaciones seguras a través de conversiones de direcciones de red y conversiones de protocolo. El método puede hacerse de forma totalmente automática y transparente para el usuario.
Un punto clave relacionado con la aplicabilidad del invento es que – en la fecha de prioridad de la presente solicitud de patente – en general, sólo TCP (descrito en RFC793) y UDP (descrito en RFC768) funcionan sobre NAT. Esto es debido a que la mayoría de las NATs usadas en la práctica son puertos NATs, y ésta es la forma en que NAT proporciona el máximo de beneficios con respecto a la escasez de direcciones IP encaminables globalmente. La invención no está, sin embargo, limitada al uso de UDP y TCP tal y como se conocen en la fecha de prioridad de esta solicitud de patente: en general puede decirse que la UDP y TCP son ejemplos de protocolos que determinan la información de identificación de conexión (es decir, direccionamiento y numeración de puertos) que es mapeada a otra forma en el proceso de conversión de dirección. Cabe esperar que en el futuro surjan otros tipos de protocolos de comunicación y de transformaciones de dirección.
Los diversos aspectos de la invención se refieren a:
determinar si un equipo distante soporta un cierto método que es típicamente un método de comunicación segura acorde con la invención (el aspecto “métodos soportados”),
determinar qué conversiones de direcciones de red y/o conversiones de protocolo tienen lugar en los paquetes, en caso de haber alguno (el aspecto “conversiones en curso”),
entunelar paquetes dentro de un protocolo cuidadosamente seleccionado, típicamente UDP, para hacerlos recorrer NATs (el aspecto “entunelación seleccionada”),
usar un método de mantenimiento en activación para asegurar que los dispositivos NAT involucrados y otros dispositivos que usan tiempos límite para mapeos, no pierdan el mapeo para los equipos de comunicación (el aspecto “mantenimiento en activación”),
compensar las conversiones que tienen lugar antes verificando el código de autenticación de mensaje para paquetes AH (el aspecto “compensación/autenticación”) y
realizar conversiones de direcciones ya sea en el nodo emisor o en el receptor para compensar los diversos equipos que han sido mapeados a una dirección pública simple (el aspecto “compensación/mapeo”).
Se llama entunelación al proceso de encapsulación de paquetes de datos para transmisión sobre una red lógica distinta. Típicamente, en el caso de protocolo IP, la entunelación implica añadir una nueva cabecera IP delante del paquete inicial, estableciendo apropiadamente el campo de protocolo en la nueva cabecera, y enviando el paquete al destino deseado (extremo del túnel). También se puede realizar la entunelación modificando los campos de la cabecera del paquete inicial o remplazándolo por otra cabecera, siempre que en el proceso se conserve la cantidad de información sobre el paquete inicial suficiente para que al final de túnel se pueda reconstruir dicho paquete de forma suficientemente parecida al paquete inicial que entró en el túnel. La cantidad exacta de información que debe pasar con el paquete depende de los protocolos de red, y la información puede pasar ya sea de modo explícito (como parte del paquete entunelación) o implícito (por el contexto, como por ejemplo determinado por paquetes transmitidos previamente o por un identificador de contexto en el paquete entunelado).
En el estado de la técnica se conoce bien cómo entunelar paquetes sobre una red. Al menos los documentos que se han referenciado como RFC1226, RFC1234, RFC1241, RFC1326, RFC1701, RFC1853, RFC2003, RFC2004, RFC2107, RFC2344, RFC2401, RFC2406, RFC2473 y RFC2529 están relacionados con el tema de la entunelación. Por ejemplo, RFC1234 presenta un método para entunelar marcos IPX sobre UDP. En ese método, los paquetes se entunelan a un puerto fijo UDP y a la dirección IP del desencapsulador.
El protocolo IPSEC mencionado en la descripción de los antecedentes utiliza casi siempre el protocolo IKE o Intercambio de Clave Internet (conocido por los documentos RFC2409, RFC2408 y RFC2407) para autenticar las partes que se comunican entre ellas, derivando un secreto compartido conocido solamente por las partes que se comunican, negociando los métodos de autenticación y encriptación que deben usarse en la comunicación, y acordando un valor del índice de parámetro de seguridad (SPI) así como un conjunto de selectores que serán los usados en la comunicación. El protocolo IKE se conocía previamente como el ISAKMP/Oakley, donde el acrónimo ISAKMP responde a Internet Security Association Key Management Protocol. Además de la ya mencionada negociación normal especificada en la norma IKE, IKE también incluye ciertos mecanismos de extensión. La carga pago de ID del Vendedor, divulgada en el documento de referencia RFC2408, permite a las partes en comunicación determinar si la otra parte soporta un particular mecanismo de extensión privada. El IPSEC DOI (Domain of Interpretation), conocido como RFC2407, reserva ciertos valores numéricos para dichas extensiones privadas.
En la actualidad, la ya conocida carga neta (payload) de datos de identificación de Fabricante o Vendedor se define para que tenga el formato ilustrado en la Fig. 2a, donde la columna de números se corresponde con las posiciones de los bits. El campo de ID 201 del Fabricante es, para los fines de esta invención, la parte más importante de la carga de datos de identificación de Vendedor. A continuación se explica cómo se puede realizar, en el contexto del protocolo IKE, la negociación sobre si un equipo distante soporta un determinado método para proporcionar comunicaciones sobre una red segura. La terminología utilizada aquí está tomada de los documentos IKE.
El protocolo IKE determina la llamada Fase 1 del intercambio mutuo de mensajes entre el Iniciador (es decir, el nodo que primero envía un paquete al otro) y el Respondedor (es decir, el nodo que primero recibe un paquete). La Fig. 3 ilustra un intercambio de los primeros mensajes Fase 1 entre el Iniciador y el Respondedor. De acuerdo con el aspecto de la invención “métodos soportados”, ambos dispositivos incluyen una cierta Carga de identificación (ID) del Fabricante en un determinado mensaje Fase 1 que es preferiblemente su primer mensaje Fase 1. Esta carga indica que soportan el método en cuestión.
En la Fig. 3, 201´ muestra esquemáticamente los campos de ID del Fabricante contenidos en el primer (u otro) mensaje Fase 1 del Iniciador y 201´´ muestra esquemáticamente los campos ID del Fabricante contenidos en el primer (u otro) mensaje Fase 1 del Respondedor. La presencia de un determinado método se indica mediante un campo ID del Fabricante en la carga de ID del Fabricante que consiste básicamente en una identificación de dicho método: preferiblemente será el hash MD5 de una cadena de identificación previamente conocida, por ejemplo “SSH IPSEC NAT Traversal Version 1”, sin ningún cero a la derecha ni nuevas líneas. La generación de hashes MD5 de secuencias arbitrarias de caracteres es una técnica ampliamente conocida en el estado de la técnica, por ejemplo de la publicación RFC1321 mencionado en la lista de referencias.
A continuación se abordará el aspecto de la invención “conversiones en curso”. Además de la Fase 1 mencionada anteriormente, el protocolo IKE determina la llamada Fase 2 del intercambio mutuo de mensajes entre el Iniciador y el Respondedor. De acuerdo con el aspecto de la invención “conversiones en curso” las partes pueden determinar qué conversiones tendrán lugar incluyendo la dirección IP que ven en las cargas privadas de ciertos mensajes de Modo Rápido Fase 2, que son preferiblemente sus primeros mensajes de Modo Rápido Fase 2. Cualquier número no utilizado en el intervalo de números de la carga neta privada puede usarse para designar dicho uso de la carga neta privada (por ejemplo 157, que es un número no utilizado hasta la fecha de prioridad de la presente solicitud de patente).
La carga neta privada usada para desvelar la conversión en curso puede tener por ejemplo el formato ilustrado en la Fig. 2b. El campo 211 contiene un código de tipo que identifica los tipos de direcciones que aparecen en los campos 212 y 213. El campo 212 contiene la dirección del Iniciador tal y como lo ve el nodo que envía el mensaje, y el campo 213 contiene la dirección del Respondedor tal y como la ve el nodo que envía el mensaje. La Fig. 3 muestra el intercambio de los (primeros) mensajes Modo Rápido Fase 2 entre el Iniciador y el Respondedor de modo tal que el mensaje enviado por el primero incluye los campos correspondientes 211´, 212´ y 213´ y el mensaje enviado por el último incluye los campos 211´´, 212´´ y 213´´.
De acuerdo con la práctica habitual, las direcciones del Iniciador y del Respondedor se incluyen en la cabecera del paquete que contiene la carga neta de la Fig. 2b. Las direcciones en las cabeceras son sensibles a las conversiones de direcciones y otros procesos mientras que las direcciones en la carga neta privada no lo son. Cuando se recibe el paquete con la carga neta de la Fig. 2b, las direcciones contenidas en él se comparan con las que se ven en la cabecera. Si son distintas, se produce entonces una conversión de direcciones de red en el paquete. Posteriormente se hará referencia al uso del número de puerto estándar IKE 500 junto con la aplicación de la invención; como un modo adicional de detectar conversiones ocurridas, los números de puerto del paquete recibido pueden ser también comparados con el número de puerto estándar IKE 500 para determinar si se han producido conversiones de puertos.
Un aspecto de cierta importancia a la hora de gestionar las direcciones es que el puerto fuente UDP del paquete puede guardarse para un posterior uso. Generalmente se guardarán con las estructuras de datos para las asociaciones de seguridad Fase 1 ISAKMP, y se utilizarán para establecer el proceso de compensación para las asociaciones de seguridad Fase 2 IPSEC.
Para implementar el aspecto de la invención “conversiones ocurridas” aplicando el método descrito arriba, los equipos deben modificar sus cargas netas de identificación Fase 2: la carga neta ilustrada en la Fig. 2b no es conocida en las normas existentes. Una posibilidad consiste restringir las cargas netas a los tipos ID_IPV4_ADDR e ID_IPV6_ADDR que serían apropiadas para una operación huésped-a-huésped.
A continuación se hará referencia a los aspectos de la invención “entunelación seleccionada”, “compensación/autenticación” y “compensación/mapeo”. De acuerdo con este aspecto de la invención, los paquetes de datos reales pueden entunelarse sobre la misma conexión que se use para establecer las características de seguridad de la conexión de comunicación, por ejemplo la conexión UDP usada para IKE. Esto asegura que los paquetes de datos reales experimenten las mismas conversiones que sufrieron los paquetes IKE cuando se determinó la conversión. Partiendo de que se ha determinado el número de puerto estándar 500 para IKE, esto significaría que todos los paquetes se envían con origen puerto 500 y destino puerto 500, de modo que se necesita un procedimiento para distinguir los paquetes IKE auténticos de los que contienen datos encapsulados. Una posible forma de hacerlo consiste en valerse del hecho de que la cabecera de IK usada por los paquetes IKE auténticos contiene un campo de Cookie del Iniciador: se puede especificar que los Iniciadores que soportan este aspecto de la invención no generan nunca galletas (cookies) con todo ceros en los cuatro primeros bytes. Por tanto se usa el valor cero en esos 4 bytes para reconocer el paquete como un paquete de datos entunelados. De este modo, los paquetes de datos entunelados tendrían cuatro bytes de ceros al principio de la carga neta UDP, mientras que los paquetes IKE auténticos nunca los tendrían.
La Fig. 4 ilustra la encapsulación de paquetes reales IPSEC en UDP para su transmisión. Básicamente, se insertan en el propio paquete una cabecera UDP 403 y una pequeña cabecera intermedia 404 después de la cabecera IP 401 ya en el paquete (con el campo de protocolo copiado en la cabecera intermedia). La cabecera IP 401 se modifica ligeramente dando lugar a una cabecera IP modificada 401´. La carga neta IP 402 permanece inalterada. No se debe malinterpretar la sencilla ilustración del paquete IPSEC sin encapsular a la izquierda: este paquete no es de texto común sino que ha sido procesado según AH o ESP u otro correspondiente protocolo de conversión antes de su encapsulación en UDP.
E en el presente documento y sin carácter limitativo de la generalidad, se supone que la encapsulación de acuerdo con la Fig. 4 la realizan siempre los mismos nodos que realizan el procesamiento IPSEC (ya sea un nodo final o un dispositivo VPN). Debe observarse también que en vez de encapsular los paquetes IPSE en UDP, podrían encapsularse en TCP. Esta opción requeriría probablemente el uso de falsos inicios y terminaciones de sesión de tal modo que el primer paquete tenga el bit SYN y el último paquete tenga bit FIN, tal y como se especifica en el protocolo TCP.
Al encapsular un paquete real de datos o un “datagrama” según la Fig. 4, se altera la cabecera IP original 401 – definida en RFC791 – dando lugar a una cabecera IP modificada 401´ de la siguiente manera:
El campo de Protocolo en la cabecera IP (no mostrado separadamente) se remplaza por el protocolo 17 para UDP de acuerdo con RFC768,
El campo de Longitud Total en la cabecera IP (no mostrado separadamente) se aumenta en el tamaño combinado de las cabeceras UDP e intermedia (16 bytes en total) y
Se vuelve a calcular el campo de Cabecera Verificar-suma en la cabecera IP (no mostrado separadamente) siguiendo las normas dadas en RFC791.
Tal y como se ve en la Fig.4, se insertan una cabecera UDP 403 – según se define en RFC768 – y una cabecera intermedia 404 después de la cabecera IP. La cabecera UDP tiene 8 octetos y la cabecera intermedia también tiene 8 octetos, dando un total de 16 octetos. En la explicación que sigue, se tratan ambas cabeceras como si fueran una sola. El formato más conveniente para la cabecera combinada es el mostrado en la Fig. 2c. Los campos en esta cabecera se fijan de la siguiente manera:
El campo Puerto de Origen 221 se asigna al 500 (el mismo que IKE). Si el paquete va a través de una red NAT, esta puede ser diferente cuando se recibe el paquete.
El campo Puerto de Destino 222 se asigna al número de puerto desde el que el otro extremo parece estar enviando los paquetes. Si el paquete va a través de una red NAT, el receptor puede ver aquí un número de puerto distinto.
El campo Longitud UDP 223 es la longitud de la cabecera UDP más la longitud del campo de datos UDP. En este caso, también se incluye la cabecera intermedia. El valor se calcula en bytes como 16 más la longitud de la carga neta del paquete IP original (sin incluir la cabecera IP original, que se incluye en el campo Longitud de la cabecera IP).
El campo Verificar-suma UDP 224 se fija preferiblemente en 0. El verificar-suma UDP es opcional, y no interesa comprobarlo o calcularlo con este mecanismo de entunelación. Se supone que la integridad de los datos está protegida por una cabecera AH o ESP dentro del paquete entunelado.
El campo Cero obligatorio 255: Este campo debe contener un valor fijo acordado previamente, que es preferiblemente todo ceros. El campo se solapa con los cuatro primeros bytes del campo Cookie del Iniciador en una cabecera IKE auténtica. Un Iniciador que soporte este aspecto de la invención no debe usar una cookie en la que los primeros cuatro bytes sean cero. Estos bytes cero se usan para separar los paquetes entunelados de los paquetes ISAKMP reales. Naturalmente se pueden elegir algún otro valor fijado distinto de “todo ceros”, pero el valor debe fijarse unos valores para este uso particular.
El campo Protocolo 226: El valor de este campo se copia del campo Protocolo ya conocido en la cabecera IP original (no mostrado separadamente en la Fig. 4)
El campo Reservado 227: preferiblemente enviado como todo ceros; ignorado en la recepción.
El emisor inserta esta cabecera en cualquier paquete entunelado a un destino detrás de una NAT. La información sobre si se está usando una NAT se puede almacenar en el gestor de políticas según el criterio de SA (Asociación de la Seguridad). El encapsulado al que se refiere la Fig. 4 se puede ejecutar ya sea como una transformación nueva o como parte de las ya conocidas transformaciones AH y ESP.
La operación de encapsulado utiliza el número de puerto UDP y la dirección IP del equipo distante que se determinaron durante la negociación IKE.
El receptor desencapsula los paquetes de esta encapsulación antes de realizar el procesamiento AH o ESP. La desencapsulación elimina esta cabecera y actualiza los campos de Protocolo, Longitud y Verificar-suma de la cabecera IP. Para esta operación no se necesita ningún dato de configuración (número de puerto, etc.)
La desencapsulación sólo ha de ejecutarse si coinciden todos los siguientes selectores:
La dirección de destino es la dirección de destino de este equipo,
la dirección de origen es la dirección de origen de un equipo con el que este equipo ha acordado usar este túnel,
el campo de Protocolo indica UDP,
el valor del campo de puerto de Destino es 500 y
el valor del campo de puerto de Origen indica el puerto con el que este equipo ha acordado usar esta entunelación. (obsérvese que puede haber muchas direcciones de origen y puertos a los que se aplique esta entunelación; cada uno de ellos se trata con un juego distinto de selectores).
Durante la desencapsulación se puede substituir la dirección de origen del paquete recibido por la dirección de origen real recibida durante la negociación IKE. Esto aplica la compensación para la verificación de AH MAC. En la fase post-tratamiento que sigue se vuelve a cambiar la dirección. Gracias a esta compensación se pueden usar las conversiones estándar AH y ESP sin modificación alguna.
En la Fig. 3 se muestra esquemáticamente como bloque 301 el proceso AH/ESP en el nodo emisor, el bloque 302 muestra esquemáticamente la encapsulación de datagramas a UDP, el bloque 303 muestra esquemáticamente la desencapsulación de datagramas desde UDP y el bloque 304 muestra esquemáticamente el proceso AH/ESP en el nodo receptor.
Después de que el paquete se ha desencapsulado desde AH o EPS se debe aplicar una compensación adicional. Esta desencapsulación adicional debe tratar el hecho de que el paquete saliente atravesó realmente una NAT (ilustrado esquemáticamente en bloque 305 de la Fig. 3) y en consecuencia el paquete de texto común también debe sufrir una transformación similar. El receptor debe ver la dirección del dispositivo NAT como la dirección del equipo en vez de como la dirección interna original. Alternativamente, el emisor del paquete podría haber realizado esta compensación antes de encapsularlo en AH o ESP.
Existen varias alternativas para esta compensación adicional según los diversos casos especiales (la mejor compensación depende de cada aplicación particular):
Asignar un intervalo de direcciones de red para este proceso (es decir, usar el intervalo 169.254.x.x. para el enlace local. – no importan los valores reales, lo que se desea es fundamentalmente una red arbitraria que no esté usando nadie más). Se asigna una dirección de este intervalo para cada combinación <natip, ownip, natport, ownport>, donde natip significa dirección IP de la NAT, ownip la dirección IP propia del dispositivo de tratamiento, natport significa el número de puerto en la NAT y ownport quiere decir el número del puerto del propio equipo del proceso. La dirección distante del paquete se substituye por esta dirección antes de que el paquete sea enviado a las colas de protocolo.
El verificar-suma TCP para equipos internos se debe recalcular, como parte de la compensación, en caso de que hayan cambiado las direcciones del equipo o los números de puerto. Los cálculos de verificar-suma TCP pueden ser incrementales tal y como se conoce de RFC1071. Puede ser necesario aplicar el puerto NAT para el puerto de origen.
Cuando se utilice como VPN entre dos sitios que usen espacios de direcciones privadas incompatibles (posible solapamiento), se debe aplicar la conversión de direcciones para compatibilizar dichas direcciones con las direcciones locales.
Cuando se utilice como VPN entre dos sitios que usen espacios de direcciones privada compatibles (no solapamiento), y se aplica un modo de túnel, puede no ser necesario una compensación adicional.
Puede resultar necesario realizar conversión de direcciones para los contenidos de paquetes de ciertos protocolos, tales como FTP (divulgado por RFC959) o H.323. También se analizan otros temas parecidos en la referencia dada como HoldregeSrisuresh99.
También es posible usar en el servidor direcciones aleatorias para el cliente, y aplicar conversión de direcciones a esta dirección. Esto podría permitir al servidor distinguir entre múltiples clientes situados tras la misma red NAT, y podría evitar la configuración manual del espacio de dirección local.
La operación de compensación puede interactuar o no con la cola TCP/IP en la máquina local para reservar números de puerto UDP.
En general, esta invención no limita el procedimiento usado para compensar en los paquetes internos la NAT que tenga lugar en las cabeceras externas. El procedimiento óptimo para realizar dicha compensación puede encontrase por experimentación entre las alternativas presentadas anteriormente, o podría presentarse otro procedimiento óptimo.
A continuación se hará referencia al aspecto “mantener-activo” del invento, es decir asegurar que las conversiones de direcciones de red realizadas en la red no se modifican después de que se hayan determinado las conversiones que tienen lugar. Los conversores de direcciones de red guardan en memoria caché la información de mapeo de las direcciones, de modo que pueden invertir el mapeo para los paquetes de respuesta. Si se usa TCP, el conversor de direcciones puede mirar en el bit FIN de la cabecera TCP para determinar cuándo puede desaparecer un determinado mapeo. Sin embargo, para UDP no hay indicación explicita de finalización de flujos. Por esta razón, muchas NATs limitan bastante el tiempo de espera de mapeos para UDP (incluso tanto como 30 segundos). Por tanto, se hace necesario forzar el mantenimiento del mapeo.
Una forma posible de asegurar el mantenimiento de los mapeos consiste en enviar paquetes de activación con frecuencia suficiente para que la conversión de direcciones permanezca en la memoria caché. Al calcular la frecuencia necesaria debe tenerse en cuenta que los paquetes pueden perderse en la red, y en consecuencia deberán enviarse muchos paquetes de activación dentro del intervalo más corto en que se haya estimado que la red NAT puede olvidar el mapeo. La frecuencia apropiada depende tanto del período de tiempo en el que el mapeo permanece memorizado en caché como de la probabilidad de pérdida de paquetes en la red; se puede llegar a los valores óptimos de frecuencia para cada situación mediante ensayos en cada una de ellas.
Los paquetes de activación no necesitan contener más información significativa que las cabeceras necesarias que son iguales a las cabeceras de paquetes de datos para asegurar que los paquetes de activación sean gestionados exactamente de la misma manera que los paquetes de datos reales. Un paquete de activación puede contener un indicador que lo identifique como paquete de activación y no como paquete de datos; sin embargo también se puede determinar que todos los paquetes que no contengan una información significativa de carga neta se interpreten como paquetes de activación. En la FIG. 3 se ilustra esquemáticamente en el bloque 306 la transmisión de paquetes de activación y en el bloque 307 se ilustra esquemáticamente la recepción y supresión de los mismos. Debe advertirse que el uso de paquetes de activación no es en absoluto necesaria si los paquetes de datos reales se transmiten con la frecuencia necesaria y/o la conexión se mantiene válida sólo durante un espacio de tiempo tan corto (por ejemplo unos pocos segundos) que haga improbable que un equipo intermedio pueda borrar la información de mapeo de su memoria caché. Sólo es necesario transmitir los paquetes de activación en una única dirección, si bien también se pueden transmitir bidireccionalmente; el inconveniente derivado de la transmisión bidireccional es el aumento de tráfico innecesario en la red. La invención no limita la dirección(es) en que los paquetes de activación (si los hay) son transmitidos.
La Fig. 5 es un diagrama de bloque simplificado de un dispositivo de red 500 que puede actuar como Iniciador o Respondedor de acuerdo con el procedimiento de proporcionar comunicaciones seguras sobre conversiones de direcciones de red según la invención. El interfaz de red 501 conecta físicamente el dispositivo de red 500 a la red. El bloque 502 de gestión de direcciones mantiene bajo control las correctas direcciones de red, número de puerto y otra información de identificación pública esencial tanto del dispositivo de red 500 en sí mismo como de su pareja (no mostrado). El bloque IKE 503 es responsable del proceso de gestión de claves y de otras actividades relacionadas con el intercambio de información secreta. El bloque 504 Encriptación/desencriptación ejecuta la encriptación y la desencriptación de datos una vez que el bloque IKE 503 ha obtenido la clave secreta. El bloque 505 de compensación se usa para compensar las conversiones permisibles en los paquetes transmitidos y/o recibidos de acuerdo con la invención. Cualquiera de los bloques 504 y 505 puede usarse para transmitir, recibir y desechar paquetes de activación. El bloque 506 ensamblador/desensamblador es el intermediador entre los bloques 502 a 505 y el interfaz físico 501 de la red. Todos los bloques operan bajo la supervisión de un bloque de control 507 que también se encarga de encaminar la información entre los otros bloques y el resto del dispositivo de la red, por ejemplo para mostrar la información al usuario a través de una unidad de visualización (no mostrada) y para obtener órdenes del usuario a través de un teclado (no mostrado). Los bloques de la Fig. 5 se implementan preferiblemente como procesos operativos previamente programados de un microprocesador, cuya ejecución práctica es conocida como tal por un experto en la materia. También se pueden usar en la práctica de esta invención otras disposiciones distintas a las mostradas en la Fig. 5.
Aunque este invento se ha expuesto en el contexto de IKE, y entunelación usando puerto IKE, debe entenderse que puede aplicarse a otros casos análogos que usen diferentes métodos de formateado de paquetes, diferentes detalles de negociación, diferente protocolo de intercambio de claves, o diferente protocolo de seguridad. El invento también puede aplicarse a protocolos no IP que tengan las características adecuadas. La invención es igualmente aplicable a ambos protocolos IPv4 e IPv6.
También se pretende que la invención sea aplicable a futuras revisiones de los protocolos IPSEC e IKE.
Del mismo modo se ha de entender que la invención es también aplicable a las conversiones de protocolos, además de a las conversiones de direcciones. Para un experto ha de ser fácil adaptar la presente invención a las conversiones de protocolo a partir de la presente descripción y las explicaciones sobre conversión de protocolo contenidos en solicitudes de patentes presentadas anteriormente por este mismo solicitante.
1. LISTA DE REFERENCIAS BorellaLo99
M. Borella, J. Lo: Realm Specific IP: Protocol Specification, draft-ietf-nat-rsip-protocol-00.txt, Work in Progress, Internet Engineering Task Force, 1999
HoldregeSrisuresh99
M. Holdrege, P. Srisuresh: Protocol Complications with the IP Network Address Translator (NAT), draft-ietf-natprotocol-complications-00.txt, Work in Progress, Internet Engineering Task Force, 1999.
LoBorella99
J. Lo, M. Borella: Real Specif IP: A Framework, draft-ietf-nat-rsip-framework-00.txt, Work in Progress, Internet Engineering Task Force, 1999
Rekhter99
Y. Rekhter: Implications of NATs on the TCP/IP architecture, draft-ietf-arch-implications-00.txt, Internet Engineering Task Force, 1999.
RFC768
J. Postel: User Datagram Protocol, RFC 768, Internet Engineering Task Force, 1980. RFC791
J. Postel: Internet Protocol, RFC 791, Internet Engineering Task Force, 1981 RFC793
J. Postel: Transmission Control Protocol, RFC 793, Internet Engineering Task Force, 1981. RFC959
J. Postel, J.Reynolds: File Transfer Protocol, RFC 959, Internet Engineering Task, 1985. RFC1071
R. Braden, D. Borman, C. Partridge: Computing the Internet checksum, RFC 1071, Internet Engineering Task Force, 1988.
RFC1226
B. Kantor: Internet protocol encapsulation of AX.25 frames, RFC 1226, Internet Engineering Task Force, 1991. RFC1234
D. Provan: Tunneling IPX traffic through IP networks, RFC 1234, Internet Engineering Task Force, 1991. RFC1241
R. Woodburn, D. Mills: Scheme for an Internet encapsulation protocol: Version 1, RFC 1241 Internet Engineering Task Force, 1991.
RFC1321
R. Rivest: The MD5 message-digest algorithm, RFC 1321, Internet Engineering Task Force, 1992. RFC1236
P. Tsuchiya: Mutual Encapsulation Considered Dangerous, RFC 1326, Internet Engineering Task Force, 1992. RFC1631
K. Egevang, P. Francis: The IP Network Address Translator (NAT), RFC 1631, Internet Engineering Task Force, 1994.
RFC1701
S. Hanks, T. Li, D. Farinacci, P. Traina: Generic Routing Encapsulation, RFC 1701, Internet Engineering Task Force, 1994.
RFC1702
S. Hanks, T. Li, D. Farinacci, P. Traina: Generic Routing Encapsulation over IPv4 networks, RFC 1702, Internet Engineering Task Force, 1994.
RFC1853
W. Simpson: IP in IP Tunneling, RFC 1853, Internet Engineering Task Force, 1995. RFC2003
C. Perkins: IP Encapsulation within IP, RFC 2003, Internet Engineering Task Force, 1996. RFC2004
C. Perkins: IP Encapsulation within IP, RFC 2004, Internet Engineering Task Force, 1996. RFC2107
K. Hamzeh: Ascend Tunnel Management Protocol, RFC 2107, Internet Engineering Task Force, 1997. RFC2344
G. Montenegro: Reverse Tunneling for Mobile IP, RFC 2344, Internet Engineering Task Force, 1998. RFC2391
P. Srisuresh, D. Gan: Load Sahring using IP Network Address Translation (LSNAT), RFC 2391, Internet Engineering Task Force, 1998.
RFC2401
S. Kent, R. Atkinson: Security Architecture for the Internet Protocol, RFC 2401, Internet Engineering Task Force, 1998.
RFC2402
S. Kent, R. Atkinson: IP Authentication Header, RFC 2401, Internet Engineering Task Force, 1998. RFC2406
S. Kent, R. Atkinson: IP Encapsulating Security Carga neta, RFC 2406, Internet Engineering Task Force, 1998. RFC2407
D. Piper: The Internet IP Security Domain of Interpretation for ISAKMP, RFC 2407, Internet Engineering Task Force, 1998.
RFC2408
D. Maughan, M. Schertler, M. Schneider, J. Turner: Internet Security Association and Key Management Protocol (ISAKMP), RFC 2408, Internet Engineering Task Force, 1998.
RFC2409
D. Hakins, D. Carrel: The Internet Key Exchange (IKE), RFC 2409, Internet Engineering Task Force, 1998. RFC2473
A. Conta, S. Deering: Generic Packet Tunneling in IPv6 Specification, RFC 2473, Internet Engineering Task Force, 1998.
RFC2529
B. Carpenter, C. Jung: Transmission of IPv6 over IPv4 Domains without Explicit Tunnels, RFC 2529, Internet 5 Engineering Task Force, 1999.
Srisuresh98Terminology
P. Srisuresh: IP Network Address Translator (NAT) Terminology and Considerations, draft-ietf-nat-terminology-01.txt, Work in Progress, Internet Engineering Task Force, 1998. Srisuresh98Security 10 P. Srisuresh: Security Model for Network Address Translator (NAT) Domains, draft-ietf-nat-security-01.txt, Work in
Progress, Internet Engineering Task Force, 1998.
SrisureshEgevang98
P. Srisuresh, K. Egevang: Traditional IP Network Address Translator (Traditional NAT), draft-ietf-nat-traditional-01.txt, Work in Progress, Internet Engineering Task Force, 1998.
W. Teo, S. Yeow, R. Singh: IP Relocation through twice Network Address Translators (RAT), draft-ietf-nat-rnat-00.txt, Work in Progress, Internet Engineering Task Force, 1999.
Claims (24)
- REIVINDICACIONES1. Procedimiento para la comunicación segura de paquetes entre un primer dispositivo de ordenador (181, INICIADOR) y un segundo dispositivo de ordenador (185, RESPONDEDOR) a través de una red (184) de transmisión de datos basada en conmutación de paquetes que incluye dispositivos de ordenador intermedios (183, 187, 305), donde al menos uno de los citados dispositivos de ordenador mencionados realiza una conversión de direcciones de red y/o una conversión de protocolo, caracterizado porque dicho procedimiento comprende los pasos consistentes en: determinar qué conversiones de direcciones de red deben tener lugar, caso de haberla, en los paquetes transmitidos entre el primer dispositivo de ordenador y el segundo dispositivo de ordenador, con el fin de habilitar el traslado de las conversiones de direcciones de red que se hayan determinado, tomar paquetes (301) acordes con un primer protocolo y encapsularlos (302) en paquetes acordes con un segundo protocolo, cuyo segundo protocolo sea capaz de trasladar conversiones de direcciones de red, transmitir desde un primer dispositivo de ordenador al segundo dispositivo de ordenador los citados paquetes acordes con el segundo protocolo mencionado y con el fin de invertir la encapsulación (302) que se realizó para posibilitar el traslado de las conversiones de direcciones de red, desencapsular (303) dichos paquetes transmitidos según el citado segundo protocolo para transformarlos en paquetes (304) acordes con el citado primer protocolo.
- 2. Procedimiento según reivindicación 1, caracterizado porque el paso consistente en tomar paquetes (301) acordes con un primer protocolo y encapsularlos (302) en paquetes acordes con un segundo protocolo, comprende los subpasos consistentes en tomar paquetes acordes con el Protocolo de Internet (401, 402), procesar dichos paquetes de acuerdo con el conjunto de programas (suite) de protocolo IPSEC y encapsular los paquetes procesados en paquetes acordes con el Protocolo de Datagramas de Usuario (401´, 403, 404).
- 3. Procedimiento según reivindicación 1, caracterizado porque el paso consistente en tomar paquetes (301) acordes con un primer protocolo y encapsularlos (302) en paquetes acordes con el segundo protocolo, comprende los subpasos consistentes en tomar paquetes acordes con el Protocolo de Internet, procesar dichos paquetes de acuerdo con el conjunto de programas (suite) de protocolo IPSEC, y encapsular los paquetes procesados en paquetes acordes con el Protocolo de Control de Transmisión.
-
- 4.
- Procedimiento según reivindicación 1, caracterizado porque además comprende el paso de compensar las conversiones de direcciones de red en el citado segundo protocolo realizadas sobre los paquetes que se han transmitido entre el primer dispositivo de ordenador y el segundo dispositivo de ordenador.
-
- 5.
- Procedimiento según reivindicación 1, caracterizado porque adicionalmente comprende el paso de transmitir periódicamente (306, 307) paquetes de activación entre el primer dispositivo de ordenador y el segundo dispositivo de ordenador para asegurar que permanezcan estables las conversiones de direcciones de red que tengan lugar, caso de haberlas, en los paquetes transmitidos entre el primer dispositivo de ordenador y el segundo dispositivo de segundo ordenador.
-
- 6.
- Procedimiento según reivindicación 1, caracterizado porque para establecer condicionalmente una conexión de comunicación segura entre un primer dispositivo de ordenador (181, INICIADOR) y un segundo dispositivo de ordenador (185, RESPONDEDOR) a través de una red de transmisión de datos basada en conmutación de paquetes (184) que incluye dispositivos de ordenador intermedios (183, 187, 305), donde al menos uno de dichos dispositivos de ordenador realiza una conversión de direcciones de red y/o una conversión de protocolo, dicho procedimiento consta de los pasos consistentes en
averiguar (201, 201´) si el segundo dispositivo de ordenador soporta o no un método de comunicación en el que: se determina que ocurran conversiones de direcciones de red, si es que hay alguna, sobre paquetes transmitidos entre el primer dispositivo de ordenador y el segundo dispositivo de ordenador; tomar paquetes conformes con un primer protocolo y encapsularlos de acuerdo con un segundo protocolo, siendo este segundo protocolo capaz de atravesar conversiones de direcciones de red; transmitir los paquetes conformes con dicho segundo protocolo desde el primer dispositivo de ordenador al segundo dispositivo de ordenador; y desencapsular dichos paquetes, transmitidos de acuerdo con dicho segundo protocolo, a paquetes conformes con el citado primer protocolo, como respuesta a un resultado que indique que efectivamente el segundo dispositivo de ordenador soporta dicho método de comunicación, establecer una conexión de comunicación segura entre el primer dispositivo de ordenador y el segundo dispositivo de ordenador en la cual se emplee dicho método de comunicación y como respuesta a un resultado que indique que efectivamente el segundo dispositivo de ordenador no soporta dicho método de comunicación, deshabilitar el uso de dicho método de comunicación entre el primer y segundo dispositivos de ordenador. - 7. Procedimiento según reivindicación 1, caracterizado porque para entunelar paquetes entre un primer dispositivo de ordenador (181, INICIADOR) y un segundo dispositivo de ordenador (185, RESPONDEDOR) a través de una red de transmisión de datos basada en conmutación de paquetes (184) que incluye dispositivos de ordenador intermedios (183, 187, 305), donde al menos uno de los ordenadores mencionados realiza una conversión de direcciones de red y/o una conversión de protocolo, el procedimiento comprende los pasos consistentes en: establecer un modo de entunelación bidireccional entre el primer dispositivo de ordenador y el segundo dispositivo de ordenador mediante el intercambio de paquetes conformes con un protocolo de comunicación segura, tomar paquetes (301) conformes con un primer protocolo y encapsularlos (302) en el primer dispositivo de ordenador en paquetes conformes con un segundo protocolo, siendo dicho segundo protocolo capaz de atravesar conversiones de direcciones de red, transmitir dichos paquetes conformes con dicho segundo protocolo desde el primer dispositivo de ordenador al segundo dispositivo de ordenador, en el segundo dispositivo de ordenador, desencapsular (303) los citados paquetes transmitidos conformes con dicho segundo protocolo a paquetes (304) conformes con el mencionado primer protocolo, obtener información sobre las conversiones de direcciones de red que se han producido sobre los paquetes transmitidos entre el primer dispositivo de ordenador y el segundo dispositivo de ordenador y utilizar la información obtenida anteriormente para modificar el modo de entunelación bidireccional establecido entre el primer dispositivo de ordenador y el segundo dispositivo de ordenador.
- 8. Procedimiento según reivindicación 7, caracterizado porque el paso de obtener información sobre las conversiones de direcciones que se han producido sobre los paquetes transmitidos entre el primer dispositivo de ordenador y el segundo dispositivo de ordenador, comprende los subpasos consistentes en transmitir un paquete entre el primer dispositivo de ordenador y el segundo dispositivo de ordenador, teniendo dicho paquete una parte de cabecera y una parte de carga neta (payload), y comparar una dirección de red transmitida en dicha carga neta con una dirección de red transmitida en dicha cabecera para así averiguar qué cambios ha sufrido la dirección de red transmitida en tal cabecera.
-
- 9.
- Procedimiento según reivindicación 7, caracterizado porque adicionalmente comprende el paso de transmitir periódicamente paquetes de activación (306, 307) entre el primer dispositivo de ordenador y el segundo dispositivo de ordenador para asegurar que permanezcan estables las conversiones de direcciones de red que tengan lugar, caso de haberlas, en los paquetes transmitidos entre el primer dispositivo de ordenador y el segundo dispositivo de ordenador.
-
- 10.
- Procedimiento según reivindicación 7, caracterizado porque el paso de utilizar la mencionada información obtenida para modificar la operación de entunelación de paquetes comprende el subpaso de introducir una conversión de direcciones antes de encapsular (302) los paquetes para así compensar las conversiones de direcciones de red realizadas sobres los paquetes transmitidos entre el primer dispositivo de ordenador y el segundo dispositivo de ordenador.
-
- 11.
- Procedimiento según reivindicación 7, caracterizado porque el paso de utilizar la mencionada información obtenida para modificar la operación de entunelación de paquetes comprende el subpaso de introducir una conversión de direcciones después de desencapsular (303) los paquetes para así compensar las conversiones de direcciones de red realizadas sobres los paquetes transmitidos entre el primer dispositivo de ordenador y el segundo dispositivo de ordenador.
-
- 12.
- Procedimiento según reivindicación 1, caracterizado porque para entunelar paquetes entre un primer dispositivo de ordenador (181, INICIADOR) y un segundo dispositivo de ordenador (185, RESPONDEDOR) a través
de una red de transmisión de datos (184) basada en conmutación de paquetes que incluye dispositivos de ordenador intermedios (183, 187, 305), existiendo en dicha red de transmisión datos un protocolo de seguridad que comprende una conexión de gestión de claves y emplea un formato de paquetes específico para los paquetes de gestión de claves, el procedimiento comprende los siguientes pasos encapsular los paquetes de datos que no son paquetes de gestión de claves en dicho formato de paquetes específico para paquetes de gestión de claves, transmitir desde el primer dispositivo de ordenador al segundo dispositivo de ordenador dichos paquetes encapsulados en el formato especifico de paquetes, discriminar, en el segundo dispositivo de ordenador, los paquetes de datos encapsulados en el formato específico de los auténticos paquetes de gestión de claves y desencapsular los paquetes de datos encapsulados en el formato específico de paquetes. - 13. Procedimiento según reivindicación 12, caracterizado porque el paso de encapsular los paquetes de datos que no son paquetes de gestión de claves comprende los subpasos de encapsular los paquetes de datos que no son paquetes de gestión de claves en un formato de paquete de gestión de claves especificado por el protocolo de Intercambio de Claves en Internet (IKE) que define un determinado campo de Cookie Iniciador e insertar dentro del campo Cookie Iniciador de un paquete de datos encapsulado, un valor que indique que el paquete encapsulado es un paquete de datos y no un paquete de gestión de claves.
- 14. Procedimiento según reivindicación 1, caracterizado porque el procedimiento comprende los pasos de establecer una conexión de gestión de claves entre el primer dispositivo de ordenador y el segundo dispositivo de ordenador, de acuerdo con un protocolo de seguridad; componer un paquete indicador con una parte de cabecera y una parte de carga neta; comunicar dicho paquete indicador dentro de la conexión de gestión de claves; y comparar la parte de cabecera y la parte de carga neta para determinar qué conversiones de dirección, si las hubiera, han sufrido los paquetes transmitidos entre el primer dispositivo de ordenador y el segundo dispositivo de ordenador.
-
- 15.
- Procedimiento según reivindicación 14, caracterizado porque el protocolo de seguridad determina un número de puerto estándar para una conexión de gestión de claves, y además el procedimiento incluye el paso de comparar en el paquete indicador recibido un número de puerto de origen con dicho número de puerto estándar para una conexión de gestión de claves.
-
- 16.
- Procedimiento según reivindicación 1, caracterizado porque reconoce un protocolo de seguridad que determina el proceso modo-transporte de paquetes para transmisión y recepción; y donde se ha determinado una verificación-suma de protocolo de alto-nivel para comprobar la integridad de los paquetes recibidos, y comprendiendo este procedimiento los siguientes pasos
en el primer dispositivo de ordenador, ejecutar el proceso modo-transporte para paquetes que se han de transmitir al segundo dispositivo de ordenador, en el segundo dispositivo de ordenador, ejecutar el proceso modo-transporte para paquetes recibidos del primer dispositivo de ordenador, incluyendo dicho proceso modo-transporta la desencapsulación de los paquetes recibidos y en el segundo dispositivo de ordenador, actualizar la verificación-suma de del protocolo de alto-nivel para compensar los cambios, si los hubiera, provocados por las conversiones de dirección de red. - 17. Procedimiento según reivindicación 16, caracterizado porque el paso de ejecutar en el primer dispositivo de ordenador el proceso modo-transporte para paquetes transmitidos al segundo dispositivo de ordenador toma la forma de proceso modo-transporte determinado por el conjunto de programas de protocolo IPSEC y el paso de ejecutar en el segundo dispositivo de ordenador el proceso modo-transporte para paquetes recibidos desde el primer dispositivo de ordenador toma la forma de proceso modo-transporte determinado por el conjunto de programas de protocolo IPSEC.
- 18. Procedimiento según reivindicación 16, caracterizado además porque comprende los pasos de en el primer dispositivo de ordenador, tras ejecutar el proceso modo-transporte para un paquete que va a transmitirse al segundo dispositivo de ordenador, encapsular el paquete procesado en un paquete acorde con un determinado protocolo, siendo dicho segundo protocolo capaz de atravesar conversiones de dirección de red y en el segundo dispositivo de ordenador, antes de ejecutar el proceso modo-transporte para un paquete recibido desde el primer dispositivo de ordenador, desencapsular el paquete recibido desde el paquete acorde con dicho segundo protocolo y reemplazar un número de direcciones de red en el paquete des-encapsulado por un número correspondiente de direcciones de red tomados del paquete recibido antes de la desencapsulación.
-
- 19.
- Procedimiento según reivindicación 16, caracterizado porque en el paso de actualizar la verificación-suma de protocolo de alto-nivel toma la forma de recalcular la verificación-suma para los paquetes procesados en modo-transporte.
-
- 20.
- Procedimiento según reivindicación 1, caracterizado porque para mantener inalterada la forma de las conversiones de direcciones realizadas por los dispositivos de conversión de direcciones de red sobre los paquetes reales de datos encapsulados y transmitidos con cierta información de dirección, entre un primer dispositivo de ordenador (181, INICIADOR) y un segundo dispositivo de ordenador (185, RESPONDEDOR) a través de una red de transmisión de datos basada en conmutación de paquetes (184), dicho procedimiento incluye el paso de
forzar al menos a uno de los dispositivos de ordenador primero y segundo a transmitir (306) al otro dispositivo de ordenador paquetes de activación con información de dirección idéntica a la de los paquetes de datos reales con una frecuencia lo suficientemente alta como para que los dispositivos de conversión de direcciones de red reutilicen constantemente los mapeos usados por la conversiones de direcciones de red (305) incluso cuando una determinada fracción de los paquetes comunicados entre el primer ordenador y el segundo ordenador se hayan perdido en la red. -
- 21.
- Procedimiento para trasmitir de forma segura paquetes desde un primer dispositivo de ordenador (181, INICIADOR) a un segundo dispositivo de ordenador (185, RESPONDEDOR) a través de una red de transmisión de datos (184) basada en conmutación de paquetes, que incluye dispositivos de ordenador intermedios (183, 187, 305), donde al menos uno de dichos dispositivos de ordenador ejecuta una conversión de direcciones de red y/o una conversión de protocolo, caracterizado por que dicho procedimiento incluye los pasos de:
determinar qué conversiones de direcciones de red, si las hubiera, tienen lugar sobre paquetes transmitidos desde el primer dispositivo de ordenador al segundo dispositivo de ordenador, habilitar las conversiones de direcciones de red, si existen, que se determinó que debían tener lugar, tomando (301) paquetes acordes con un primer protocolo y encapsulándolos (302) en paquetes acordes con un segundo protocolo, siendo dicho segundo protocolo capaz de atravesar conversiones de direcciones de red, y transmitir dichos paquetes acordes con dicho segundo protocolo desde el primer dispositivo de ordenador al segundo dispositivo de ordenador. - 22. Procedimiento para recibir de forma segura paquetes desde un primer dispositivo de ordenador (181, INICIADOR) a un segundo dispositivo de ordenador (185, RESPONDEDOR) a través de una red de transmisión de datos (184) basada en conmutación de paquetes, que incluye dispositivos de ordenador intermedios (183, 187, 305), donde al menos uno de dichos dispositivos de ordenador ejecuta una conversión de direcciones de red y/o una conversión de protocolo, caracterizado por que dicho procedimiento incluye los pasos de: determinar qué conversiones de direcciones de red, si las hubiera, tienen lugar sobre paquetes transmitidos entre el primer dispositivo de ordenador y el segundo dispositivo de ordenador, recibir paquetes acordes con un segundo protocolo enviados desde el primer dispositivo de ordenador al segundo dispositivo de ordenador, siendo dicho segundo protocolo capaz de atravesar conversiones de direcciones de red, y con el fin de invertir una encapsulación (302), que se había realizado para atravesar las conversiones de direcciones de red que se había determinado que tuvieran lugar, desencapsular (303) dichos paquetes transmitidos acordes con el mencionado segundo protocolo en paquetes acordes (304) con un primer protocolo.
-
- 23.
- Procedimiento según cualquiera de las reivindicaciones 1 a 22, que comprende el uso de la carga neta privada de un paquete para revelar las conversiones de direcciones que están teniendo lugar.
-
- 24.
- Aparato para dispositivo de red de transmisión (500) para transmitir paquetes de forma segura a un dispositivo receptor a través de una red de transmisión de datos basada en conmutación de paquetes que incluye
dispositivos intermedios, donde al menos uno de dichos dispositivos realiza una conversión de direcciones de red y/o una conversión de protocolo, caracterizado por que el aparato comprende medios (502, 503, 504, 506, 507) para determinar qué conversiones de direcciones de red, si las hubiera, tienen lugar sobre los paquetes transmitidos al segundo dispositivo de ordenador, y para posibilitar el transcurso5 de las conversiones de direcciones de red que se haya determinado que ocurrieron, tomando paquetes acordes con un primer protocolo y encapsulándolos en paquetes acordes con un segundo protocolo, siendo dicho segundo protocolo capaz de atravesar conversiones de direcciones de red, y un interfaz (501) para transmitir dichos paquetes acordes con el mencionado segundo protocolo entre el dispositivo emisor y el dispositivo receptor.10 25. Aparato para un dispositivo receptor (500) para recibir paquetes de forma segura desde un dispositivo transmisor a través de una red de transmisión de datos basada en conmutación de paquetes que incluye dispositivos intermedios, donde al menos uno de dichos dispositivos realiza una conversión de direcciones de red y/o una conversión de protocolo, caracterizado por que el aparato comprende un interfaz (501) para recibir dichos paquetes acordes con el mencionado segundo protocolo entre el15 dispositivo emisor y el dispositivo receptor, siendo dicho segundo protocolo capaz de atravesar conversiones de direcciones de red, y medios (502, 503, 504, 506, 507) para determinar qué conversiones de direcciones de red, si las hubiera, tienen lugar sobre los paquetes transmitidos entre el dispositivo transmisor y el dispositivo receptor, y para desencapsular dichos paquetes transmitidos acordes con el mencionado segundo protocolo en paquetes acordes20 con un primer protocolo con el fin de invertir la encapsulación (302), que se había realizado para atravesar las conversiones de direcciones de red que se había determinado que tuvieran lugar.
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US333829 | 1994-11-03 | ||
US09/333,829 US6957346B1 (en) | 1999-06-15 | 1999-06-15 | Method and arrangement for providing security through network address translations using tunneling and compensations |
Publications (1)
Publication Number | Publication Date |
---|---|
ES2362993T3 true ES2362993T3 (es) | 2011-07-18 |
Family
ID=23304429
Family Applications (2)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
ES10176040T Expired - Lifetime ES2369132T3 (es) | 1999-06-15 | 2000-06-15 | Mantenimiento de conversión de direcciones para datos de comunicación. |
ES00936931T Expired - Lifetime ES2362993T3 (es) | 1999-06-15 | 2000-06-15 | Un método y disposición para proporcionar seguridad a través de conversión de direcciones de red utilizando tunelado y compensaciones. |
Family Applications Before (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
ES10176040T Expired - Lifetime ES2369132T3 (es) | 1999-06-15 | 2000-06-15 | Mantenimiento de conversión de direcciones para datos de comunicación. |
Country Status (10)
Country | Link |
---|---|
US (13) | US6957346B1 (es) |
EP (2) | EP2254311B1 (es) |
JP (1) | JP3793083B2 (es) |
AT (2) | ATE502468T1 (es) |
AU (1) | AU5225000A (es) |
DE (1) | DE60045737D1 (es) |
DK (2) | DK2254311T3 (es) |
ES (2) | ES2369132T3 (es) |
PT (2) | PT1186146E (es) |
WO (1) | WO2000078008A1 (es) |
Families Citing this family (135)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US7107614B1 (en) | 1999-01-29 | 2006-09-12 | International Business Machines Corporation | System and method for network address translation integration with IP security |
US6957346B1 (en) * | 1999-06-15 | 2005-10-18 | Ssh Communications Security Ltd. | Method and arrangement for providing security through network address translations using tunneling and compensations |
US6629163B1 (en) | 1999-12-29 | 2003-09-30 | Implicit Networks, Inc. | Method and system for demultiplexing a first sequence of packet components to identify specific components wherein subsequent components are processed without re-identifying components |
US7058973B1 (en) * | 2000-03-03 | 2006-06-06 | Symantec Corporation | Network address translation gateway for local area networks using local IP addresses and non-translatable port addresses |
JP3636095B2 (ja) * | 2000-05-23 | 2005-04-06 | インターナショナル・ビジネス・マシーンズ・コーポレーション | Vpn接続のセキュリティ |
US7757272B1 (en) * | 2000-06-14 | 2010-07-13 | Verizon Corporate Services Group, Inc. | Method and apparatus for dynamic mapping |
US9444785B2 (en) * | 2000-06-23 | 2016-09-13 | Cloudshield Technologies, Inc. | Transparent provisioning of network access to an application |
US7797433B2 (en) * | 2000-06-30 | 2010-09-14 | Net2Phone | System, method, and computer program product for resolving addressing in a network including a network address translator |
JP4365998B2 (ja) * | 2000-07-21 | 2009-11-18 | 株式会社日立製作所 | マルチキャスト通信方法および通信装置 |
WO2002052798A2 (en) * | 2000-12-22 | 2002-07-04 | Research In Motion Limited | Wireless router system and method |
FI20010596A0 (fi) * | 2001-03-22 | 2001-03-22 | Ssh Comm Security Oyj | Turvallisuusjärjestelmä tietoliikenneverkkoa varten |
US8121296B2 (en) | 2001-03-28 | 2012-02-21 | Qualcomm Incorporated | Method and apparatus for security in a data processing system |
US9100457B2 (en) | 2001-03-28 | 2015-08-04 | Qualcomm Incorporated | Method and apparatus for transmission framing in a wireless communication system |
US8077679B2 (en) | 2001-03-28 | 2011-12-13 | Qualcomm Incorporated | Method and apparatus for providing protocol options in a wireless communication system |
US20030009561A1 (en) | 2001-06-14 | 2003-01-09 | Sollee Patrick N. | Providing telephony services to terminals behind a firewall and /or network address translator |
US7684317B2 (en) | 2001-06-14 | 2010-03-23 | Nortel Networks Limited | Protecting a network from unauthorized access |
US7068655B2 (en) | 2001-06-14 | 2006-06-27 | Nortel Networks Limited | Network address and/or port translation |
FI20011547A0 (fi) * | 2001-07-13 | 2001-07-13 | Ssh Comm Security Corp | Turvallisuusjärjestelmä ja -menetelmä |
US7054322B2 (en) * | 2001-08-31 | 2006-05-30 | The Boeing Company | Mobile communications network using point-to-point protocol over ethernet |
US7697523B2 (en) * | 2001-10-03 | 2010-04-13 | Qualcomm Incorporated | Method and apparatus for data packet transport in a wireless communication system using an internet protocol |
US6996126B2 (en) * | 2001-10-09 | 2006-02-07 | Motorola, Inc. | Performance improvements for ATM AAL2/5 to IP packet processing |
US7352868B2 (en) | 2001-10-09 | 2008-04-01 | Philip Hawkes | Method and apparatus for security in a data processing system |
US7649829B2 (en) | 2001-10-12 | 2010-01-19 | Qualcomm Incorporated | Method and system for reduction of decoding complexity in a communication system |
US7139263B2 (en) * | 2001-10-19 | 2006-11-21 | Sentito Networks, Inc. | Voice over IP architecture |
US7305700B2 (en) * | 2002-01-08 | 2007-12-04 | Seven Networks, Inc. | Secure transport for mobile communication network |
US7181612B1 (en) * | 2002-01-17 | 2007-02-20 | Cisco Technology, Inc. | Facilitating IPsec communications through devices that employ address translation in a telecommunications network |
FI118170B (fi) * | 2002-01-22 | 2007-07-31 | Netseal Mobility Technologies | Menetelmä ja järjestelmä viestin lähettämiseksi turvallisen yhteyden läpi |
US7500102B2 (en) * | 2002-01-25 | 2009-03-03 | Microsoft Corporation | Method and apparatus for fragmenting and reassembling internet key exchange data packets |
US7558873B1 (en) | 2002-05-08 | 2009-07-07 | Nvidia Corporation | Method for compressed large send |
US7676579B2 (en) * | 2002-05-13 | 2010-03-09 | Sony Computer Entertainment America Inc. | Peer to peer network communication |
US7191331B2 (en) * | 2002-06-13 | 2007-03-13 | Nvidia Corporation | Detection of support for security protocol and address translation integration |
US7143137B2 (en) * | 2002-06-13 | 2006-11-28 | Nvidia Corporation | Method and apparatus for security protocol and address translation integration |
US7120930B2 (en) * | 2002-06-13 | 2006-10-10 | Nvidia Corporation | Method and apparatus for control of security protocol negotiation |
US7437548B1 (en) | 2002-07-11 | 2008-10-14 | Nvidia Corporation | Network level protocol negotiation and operation |
US7370197B2 (en) | 2002-07-12 | 2008-05-06 | Microsoft Corporation | Method and system for authenticating messages |
US7305546B1 (en) * | 2002-08-29 | 2007-12-04 | Sprint Communications Company L.P. | Splicing of TCP/UDP sessions in a firewalled network environment |
DE10244710A1 (de) * | 2002-09-25 | 2004-04-08 | Siemens Ag | Verfahren zur Protokollauswahl für eine Übermittlung von Datennpaketen |
US7346770B2 (en) * | 2002-10-31 | 2008-03-18 | Microsoft Corporation | Method and apparatus for traversing a translation device with a security protocol |
US7599655B2 (en) | 2003-01-02 | 2009-10-06 | Qualcomm Incorporated | Method and apparatus for broadcast services in a communication system |
US7536719B2 (en) | 2003-01-07 | 2009-05-19 | Microsoft Corporation | Method and apparatus for preventing a denial of service attack during key negotiation |
US7386881B2 (en) | 2003-01-21 | 2008-06-10 | Swander Brian D | Method for mapping security associations to clients operating behind a network address translation device |
US7610487B2 (en) * | 2003-03-27 | 2009-10-27 | Microsoft Corporation | Human input security codes |
US8245032B2 (en) * | 2003-03-27 | 2012-08-14 | Avaya Inc. | Method to authenticate packet payloads |
US8261062B2 (en) | 2003-03-27 | 2012-09-04 | Microsoft Corporation | Non-cryptographic addressing |
US7409544B2 (en) * | 2003-03-27 | 2008-08-05 | Microsoft Corporation | Methods and systems for authenticating messages |
US7624264B2 (en) * | 2003-03-27 | 2009-11-24 | Microsoft Corporation | Using time to determine a hash extension |
US7577837B1 (en) * | 2003-04-17 | 2009-08-18 | Cisco Technology, Inc. | Method and apparatus for encrypted unicast group communication |
US7913294B1 (en) | 2003-06-24 | 2011-03-22 | Nvidia Corporation | Network protocol processing for filtering packets |
US7620070B1 (en) | 2003-06-24 | 2009-11-17 | Nvidia Corporation | Packet processing with re-insertion into network interface circuitry |
US8015413B2 (en) * | 2003-07-03 | 2011-09-06 | Koninklijke Philips Electronics N.V. | Secure indirect addressing |
US8098818B2 (en) | 2003-07-07 | 2012-01-17 | Qualcomm Incorporated | Secure registration for a multicast-broadcast-multimedia system (MBMS) |
US8718279B2 (en) | 2003-07-08 | 2014-05-06 | Qualcomm Incorporated | Apparatus and method for a secure broadcast system |
EP1653660A4 (en) * | 2003-08-08 | 2011-12-28 | Keiko Ogawa | COMMUNICATION SYSTEM, COMMUNICATION DEVICE, COMMUNICATION METHOD, AND COMMUNICATION PROGRAM THEREFOR |
US8724803B2 (en) | 2003-09-02 | 2014-05-13 | Qualcomm Incorporated | Method and apparatus for providing authenticated challenges for broadcast-multicast communications in a communication system |
US7734909B1 (en) | 2003-09-29 | 2010-06-08 | Avaya Inc. | Using voice over IP or instant messaging to connect to customer products |
US7441179B2 (en) * | 2003-10-23 | 2008-10-21 | Intel Corporation | Determining a checksum from packet data |
WO2005043848A1 (en) * | 2003-11-03 | 2005-05-12 | Immertec Co., Ltd. | Udp packet communication method and system for private ip terminals |
CN100512278C (zh) * | 2003-11-13 | 2009-07-08 | 中兴通讯股份有限公司 | 一种把ipsec嵌入到ip协议栈的方法 |
US7574603B2 (en) * | 2003-11-14 | 2009-08-11 | Microsoft Corporation | Method of negotiating security parameters and authenticating users interconnected to a network |
KR100597405B1 (ko) * | 2004-05-28 | 2006-07-06 | 삼성전자주식회사 | 소켓 어플리케이션 프로그램을 이용한 데이터 중계 시스템및 데이터 중계 방법 |
US7929689B2 (en) | 2004-06-30 | 2011-04-19 | Microsoft Corporation | Call signs |
US7962623B2 (en) * | 2004-06-30 | 2011-06-14 | Microsoft Corporation | Sustaining session connections |
JP4440056B2 (ja) * | 2004-09-27 | 2010-03-24 | パナソニック株式会社 | 情報処理装置、通信処理装置、情報処理システム、情報処理方法、及び通信処理方法 |
JP4759382B2 (ja) * | 2004-12-21 | 2011-08-31 | 株式会社リコー | 通信機器、通信方法、通信プログラム、及び記録媒体 |
US8250643B2 (en) * | 2005-02-28 | 2012-08-21 | Nec Corporation | Communication device, communication system, communication method, and program |
CN100414929C (zh) * | 2005-03-15 | 2008-08-27 | 华为技术有限公司 | 一种移动互联网协议网络中的报文传送方法 |
US20060221865A1 (en) * | 2005-03-30 | 2006-10-05 | Tellabs Operations, Inc. | Method and system for autonomous link discovery and network management connectivity of remote access devices |
US8936577B2 (en) | 2005-05-02 | 2015-01-20 | Shi Zi Technology, Ltd. | Methods and devices for autoflush syringes |
US8529517B2 (en) * | 2005-05-02 | 2013-09-10 | Shi Zi Technology, Ltd. | Autoflush syringe |
JP2006324783A (ja) * | 2005-05-17 | 2006-11-30 | Nippon Telegr & Teleph Corp <Ntt> | 接続情報交換方法および端末装置 |
CN1870568A (zh) * | 2005-05-23 | 2006-11-29 | 华为技术有限公司 | 实现网络地址转换/防火墙穿越的方法 |
JP4709583B2 (ja) * | 2005-05-31 | 2011-06-22 | 株式会社東芝 | データ送信装置およびデータ送信方法 |
US7706371B1 (en) * | 2005-07-07 | 2010-04-27 | Cisco Technology, Inc. | Domain based routing for managing devices operating behind a network address translator |
US8731542B2 (en) | 2005-08-11 | 2014-05-20 | Seven Networks International Oy | Dynamic adjustment of keep-alive message intervals in a mobile network |
US8250229B2 (en) * | 2005-09-29 | 2012-08-21 | International Business Machines Corporation | Internet protocol security (IPSEC) packet processing for multiple clients sharing a single network address |
US7599365B1 (en) * | 2005-10-12 | 2009-10-06 | 2Wire, Inc. | System and method for detecting a network packet handling device |
JP4489008B2 (ja) * | 2005-11-16 | 2010-06-23 | 株式会社東芝 | 通信装置、通信方法および通信プログラム |
US8381297B2 (en) | 2005-12-13 | 2013-02-19 | Yoggie Security Systems Ltd. | System and method for providing network security to mobile devices |
US20080276302A1 (en) | 2005-12-13 | 2008-11-06 | Yoggie Security Systems Ltd. | System and Method for Providing Data and Device Security Between External and Host Devices |
US8869270B2 (en) | 2008-03-26 | 2014-10-21 | Cupp Computing As | System and method for implementing content and network security inside a chip |
US20070183417A1 (en) * | 2006-02-09 | 2007-08-09 | Maleport Joel J | Data traffic router |
US7962652B2 (en) * | 2006-02-14 | 2011-06-14 | International Business Machines Corporation | Detecting network topology when negotiating IPsec security associations that involve network address translation |
US8086842B2 (en) | 2006-04-21 | 2011-12-27 | Microsoft Corporation | Peer-to-peer contact exchange |
US8543808B2 (en) * | 2006-08-24 | 2013-09-24 | Microsoft Corporation | Trusted intermediary for network data processing |
US20090322874A1 (en) * | 2007-04-23 | 2009-12-31 | Mark Knutson | System and method for remote surveillance |
US8179872B2 (en) | 2007-05-09 | 2012-05-15 | Research In Motion Limited | Wireless router system and method |
US8365272B2 (en) | 2007-05-30 | 2013-01-29 | Yoggie Security Systems Ltd. | System and method for providing network and computer firewall protection with dynamic address isolation to a device |
JP2009111437A (ja) * | 2007-10-26 | 2009-05-21 | Hitachi Ltd | ネットワークシステム |
US8477811B2 (en) | 2008-02-02 | 2013-07-02 | Qualcomm Incorporated | Radio access network (RAN) level keep alive signaling |
US8533465B2 (en) * | 2008-03-05 | 2013-09-10 | The Johns Hopkins University | System and method of encrypting network address for anonymity and preventing data exfiltration |
US8631488B2 (en) | 2008-08-04 | 2014-01-14 | Cupp Computing As | Systems and methods for providing security services during power management mode |
US20100058082A1 (en) * | 2008-08-27 | 2010-03-04 | Lenovo (Singapore) Ple., Ltd. | Maintaining network link during suspend state |
WO2010059864A1 (en) | 2008-11-19 | 2010-05-27 | Yoggie Security Systems Ltd. | Systems and methods for providing real time access monitoring of a removable media device |
CN102239677B (zh) | 2008-12-04 | 2016-05-04 | 诺基亚技术有限公司 | 在用户面位置协议中的专有扩展方法及设备 |
US8750112B2 (en) | 2009-03-16 | 2014-06-10 | Echostar Technologies L.L.C. | Method and node for employing network connections over a connectionless transport layer protocol |
EP2460342B1 (en) * | 2009-07-31 | 2016-09-14 | BT Americas Inc. | Telephonic communications with intelligent protocol switching |
KR101563195B1 (ko) | 2009-08-18 | 2015-10-27 | 삼성전자주식회사 | 호스트 장치 및 슬레이브 장치 제어 방법 |
KR101144912B1 (ko) * | 2010-08-03 | 2012-05-17 | 주식회사 네이블커뮤니케이션즈 | 트래픽 기반 통신 시스템 및 방법 |
US9098279B2 (en) | 2010-09-14 | 2015-08-04 | Google Inc. | Methods and systems for data interchange between a network-connected thermostat and cloud-based management server |
US9046898B2 (en) | 2011-02-24 | 2015-06-02 | Google Inc. | Power-preserving communications architecture with long-polling persistent cloud channel for wireless network-connected thermostat |
TWI469570B (zh) * | 2011-04-26 | 2015-01-11 | Realtek Semiconductor Corp | 具有遠端喚醒機制之的網路系統與遠端喚醒方法 |
US9515986B2 (en) | 2011-05-05 | 2016-12-06 | Telefonaktiebolaget Lm Ericsson (Publ) | Methods providing public reachability and related systems and devices |
US8806033B1 (en) * | 2011-06-30 | 2014-08-12 | Juniper Networks, Inc. | Effective network identity pairing |
US9699274B2 (en) * | 2011-07-25 | 2017-07-04 | Alcatel Lucent | Method and apparatus for reliable session migration |
US9769116B2 (en) * | 2011-09-16 | 2017-09-19 | Wilmerding Communications Llc | Encapsulating traffic while preserving packet characteristics |
TWI484804B (zh) * | 2011-11-09 | 2015-05-11 | Quanta Comp Inc | 網路系統之資料管理方法及其相關系統 |
US8984110B1 (en) * | 2012-02-14 | 2015-03-17 | Sonus Networks, Inc. | Secure media address learning for endpoints behind NAPT devices |
US9008093B2 (en) | 2012-03-12 | 2015-04-14 | Comcast Cable Communications, Llc | Stateless protocol translation |
WO2013163534A1 (en) | 2012-04-27 | 2013-10-31 | President And Fellows Of Harvard College | Management of off-task time in a participatory environment |
CN103428690B (zh) * | 2012-05-23 | 2016-09-07 | 华为技术有限公司 | 无线局域网络的安全建立方法及***、设备 |
US20140003322A1 (en) * | 2012-06-29 | 2014-01-02 | Alcatel-Lucent Usa Inc. | Seamless make-before-break transfer of multicast/broadcast sessions |
US9973501B2 (en) | 2012-10-09 | 2018-05-15 | Cupp Computing As | Transaction security systems and methods |
WO2014066252A1 (en) * | 2012-10-22 | 2014-05-01 | Huawei Technologies Co, Ltd. | Linked identifiers for multiple domains |
US9621685B2 (en) * | 2013-04-21 | 2017-04-11 | Oliver Solutions Ltd. | Architecture for an access network system management protocol control under heterogeneous network management environment |
WO2015006375A1 (en) | 2013-07-08 | 2015-01-15 | Cupp Computing As | Systems and methods for providing digital content marketplace security |
US9661005B2 (en) | 2014-01-09 | 2017-05-23 | International Business Machines Corporation | Security level and status exchange between TCP/UDP client(s) and server(s) for secure transactions |
US9762614B2 (en) | 2014-02-13 | 2017-09-12 | Cupp Computing As | Systems and methods for providing network security using a secure digital device |
US11474767B1 (en) * | 2014-05-28 | 2022-10-18 | Amazon Technologies, Inc. | Print from web services platform to local printer |
US9912649B1 (en) * | 2015-01-05 | 2018-03-06 | Adtran, Inc. | Systems and methods for facilitating communication between an authentication client and an authentication server |
US10142229B2 (en) * | 2015-03-13 | 2018-11-27 | Oracle International Corporation | Concealed datagram-based tunnel for real-time communications |
US20180096938A1 (en) * | 2016-09-30 | 2018-04-05 | Advanced Micro Devices, Inc. | Circuit board with multiple density regions |
US10347825B2 (en) * | 2017-02-17 | 2019-07-09 | International Business Machines Corporation | Selective deposition and nitridization of bottom electrode metal for MRAM applications |
US20190097968A1 (en) * | 2017-09-28 | 2019-03-28 | Unisys Corporation | Scip and ipsec over nat/pat routers |
CN107579932B (zh) * | 2017-10-25 | 2020-06-16 | 北京天融信网络安全技术有限公司 | 一种数据传输方法、设备和存储介质 |
WO2019094119A1 (en) * | 2017-11-13 | 2019-05-16 | Intel Corporation | Multi-domain message routing with e2e tunnel protection |
US11095617B2 (en) | 2017-12-04 | 2021-08-17 | Nicira, Inc. | Scaling gateway to gateway traffic using flow hash |
CN108494549B (zh) * | 2018-02-27 | 2020-10-02 | 北京赛博兴安科技有限公司 | 基于fpga的密钥索引协商装置、***及方法 |
CN109088878A (zh) * | 2018-09-03 | 2018-12-25 | 中新网络信息安全股份有限公司 | 一种抗拒绝云防护***的报文处理方法 |
CN109474628B (zh) * | 2018-12-27 | 2021-06-08 | 奇安信科技集团股份有限公司 | 一种基于双单向网闸的数据传输方法、***、设备和介质 |
US11700241B2 (en) * | 2019-02-27 | 2023-07-11 | Sevitech, Llc | Isolated data processing modules |
CN110519282A (zh) * | 2019-08-30 | 2019-11-29 | 新华三信息安全技术有限公司 | 一种报文处理的方法及装置 |
US11902264B2 (en) * | 2020-06-22 | 2024-02-13 | Vmware, Inc. | Path selection for data packets encrypted based on an IPSEC protocol |
US11792677B2 (en) * | 2021-10-22 | 2023-10-17 | Qualcomm Incorporated | Reflective quality of service for encapsulating security payload packets |
US11863514B2 (en) | 2022-01-14 | 2024-01-02 | Vmware, Inc. | Performance improvement of IPsec traffic using SA-groups and mixed-mode SAs |
US11956213B2 (en) | 2022-05-18 | 2024-04-09 | VMware LLC | Using firewall policies to map data messages to secure tunnels |
Family Cites Families (165)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5870474A (en) * | 1995-12-04 | 1999-02-09 | Scientific-Atlanta, Inc. | Method and apparatus for providing conditional access in connection-oriented, interactive networks with a multiplicity of service providers |
US5185860A (en) * | 1990-05-03 | 1993-02-09 | Hewlett-Packard Company | Automatic discovery of network elements |
US5251205A (en) * | 1990-09-04 | 1993-10-05 | Digital Equipment Corporation | Multiple protocol routing |
GB9100389D0 (en) * | 1991-01-09 | 1991-02-20 | Digital Equipment Corp | Method and apparatus for transparently bridging traffic across wide area networks |
JP2571655B2 (ja) * | 1991-11-27 | 1997-01-16 | インターナショナル・ビジネス・マシーンズ・コーポレイション | プロトコル変換機構、交換ネットワーク及びコンピュータ・システム |
US6026452A (en) * | 1997-02-26 | 2000-02-15 | Pitts; William Michael | Network distributed site cache RAM claimed as up/down stream request/reply channel for storing anticipated data and meta data |
US6157967A (en) * | 1992-12-17 | 2000-12-05 | Tandem Computer Incorporated | Method of data communication flow control in a data processing system using busy/ready commands |
US5838894A (en) * | 1992-12-17 | 1998-11-17 | Tandem Computers Incorporated | Logical, fail-functional, dual central processor units formed from three processor units |
US5964835A (en) * | 1992-12-17 | 1999-10-12 | Tandem Computers Incorporated | Storage access validation to data messages using partial storage address data indexed entries containing permissible address range validation for message source |
US5506847A (en) * | 1993-04-26 | 1996-04-09 | Kabushiki Kaisha Toshiba | ATM-lan system using broadcast channel for transferring link setting and chaining requests |
US5490134A (en) * | 1993-06-29 | 1996-02-06 | Southern California Edison Company | Versatile communications controller |
US5377182A (en) | 1993-08-18 | 1994-12-27 | The United States Of America As Represented By The Administrator Of The National Aeronautics And Space Administration | Non-blocking crossbar permutation engine with constant routing latency |
US5544222A (en) * | 1993-11-12 | 1996-08-06 | Pacific Communication Sciences, Inc. | Cellular digtial packet data mobile data base station |
US5548646A (en) * | 1994-09-15 | 1996-08-20 | Sun Microsystems, Inc. | System for signatureless transmission and reception of data packets between computer networks |
EP0792558A1 (en) * | 1994-11-17 | 1997-09-03 | Nortel Networks Corporation | Intelligent network testing |
US5550984A (en) * | 1994-12-07 | 1996-08-27 | Matsushita Electric Corporation Of America | Security system for preventing unauthorized communications between networks by translating communications received in ip protocol to non-ip protocol to remove address and routing services information |
US5636213A (en) * | 1994-12-28 | 1997-06-03 | Motorola | Method, transceiver, and system for providing wireless communication compatible with 10BASE-T Ethernet |
US5541918A (en) | 1995-01-31 | 1996-07-30 | Fore Systems, Inc. | Method and apparatus for manipulating an ATM cell |
US5572528A (en) | 1995-03-20 | 1996-11-05 | Novell, Inc. | Mobile networking method and apparatus |
US5640446A (en) * | 1995-05-01 | 1997-06-17 | Mci Corporation | System and method of validating special service calls having different signaling protocols |
US5909427A (en) | 1995-07-19 | 1999-06-01 | Fujitsu Network Communications, Inc. | Redundant switch system and method of operation |
WO1997004665A1 (en) | 1995-07-31 | 1997-02-13 | Alta Spinner Australia Pty. Limited | Surface moisture removal from food products |
US5757924A (en) | 1995-09-18 | 1998-05-26 | Digital Secured Networks Techolognies, Inc. | Network security device which performs MAC address translation without affecting the IP address |
US5793763A (en) | 1995-11-03 | 1998-08-11 | Cisco Technology, Inc. | Security system for network address translation systems |
US5815667A (en) * | 1995-11-28 | 1998-09-29 | Ncr Corporation | Circuits and methods for intelligent acknowledgement based flow control in a processing system network |
US8291099B2 (en) * | 1996-01-03 | 2012-10-16 | International Business Machines Corporation | Protocol conversion using facilities and utilities |
US6233623B1 (en) | 1996-01-11 | 2001-05-15 | Cabletron Systems, Inc. | Replicated resource management system for managing resources in a distributed application and maintaining a relativistic view of state |
WO1997026734A1 (en) * | 1996-01-16 | 1997-07-24 | Raptor Systems, Inc. | Transferring encrypted packets over a public network |
JP3464358B2 (ja) | 1996-01-17 | 2003-11-10 | 株式会社東芝 | 通信制御方法、中継装置およびデータパケット処理装置 |
JPH09275414A (ja) | 1996-04-05 | 1997-10-21 | Hitachi Ltd | 通信ネットワークシステム |
US6141319A (en) * | 1996-04-10 | 2000-10-31 | Nec Usa, Inc. | Link based alternative routing scheme for network restoration under failure |
KR100317443B1 (ko) * | 1996-04-24 | 2002-01-16 | 블레이어 에프.모리슨 | 인터넷프로토콜필터 |
US5923654A (en) | 1996-04-25 | 1999-07-13 | Compaq Computer Corp. | Network switch that includes a plurality of shared packet buffers |
US5826023A (en) * | 1996-06-03 | 1998-10-20 | International Business Machines Corporation | Communications tunneling |
JPH1011369A (ja) | 1996-06-27 | 1998-01-16 | Hitachi Ltd | 通信システムおよびホットスタンバイ切替機能を備える情報処理装置 |
JP3224745B2 (ja) * | 1996-07-09 | 2001-11-05 | 株式会社日立製作所 | 高信頼化ネットワークシステム及びサーバ切り替え方法 |
DE19627778A1 (de) | 1996-07-10 | 1998-01-15 | Bayer Ag | Arthropodenrepellierende Mittel |
US5940394A (en) * | 1996-08-08 | 1999-08-17 | At&T Corp | Transferring messages in networks made up of subnetworks with different namespaces |
US6023563A (en) | 1996-08-20 | 2000-02-08 | Shani; Ron | Networking switch having the network presence of a bridge |
US6701361B1 (en) * | 1996-08-22 | 2004-03-02 | Intermec Ip Corp. | Enhanced mobility and address resolution in a wireless premises based network |
US6463477B1 (en) * | 1996-09-27 | 2002-10-08 | Mci Communications Corporation | Detection of presence of multiprotocol encapsulation in a data packet |
US6751221B1 (en) | 1996-10-04 | 2004-06-15 | Kabushiki Kaisha Toshiba | Data transmitting node and network inter-connection node suitable for home network environment |
US6690669B1 (en) * | 1996-11-01 | 2004-02-10 | Hitachi, Ltd. | Communicating method between IPv4 terminal and IPv6 terminal and IPv4-IPv6 converting apparatus |
CA2218218A1 (en) * | 1996-11-08 | 1998-05-08 | At&T Corp. | Promiscuous network monitoring utilizing multicasting within a switch |
US7274662B1 (en) * | 1998-08-04 | 2007-09-25 | At&T Corp. | Method for performing segmented resource reservation |
US6335927B1 (en) * | 1996-11-18 | 2002-01-01 | Mci Communications Corporation | System and method for providing requested quality of service in a hybrid network |
US7145898B1 (en) * | 1996-11-18 | 2006-12-05 | Mci Communications Corporation | System, method and article of manufacture for selecting a gateway of a hybrid communication system architecture |
US6909708B1 (en) * | 1996-11-18 | 2005-06-21 | Mci Communications Corporation | System, method and article of manufacture for a communication system architecture including video conferencing |
US7161937B1 (en) | 1996-12-13 | 2007-01-09 | Intel Corporation | Method and apparatus for routing encoded signals through a network |
US6304546B1 (en) * | 1996-12-19 | 2001-10-16 | Cisco Technology, Inc. | End-to-end bidirectional keep-alive using virtual circuits |
US6201789B1 (en) * | 1996-12-30 | 2001-03-13 | Compaq Computer Corporation | Network switch with dynamic backpressure per port |
US6665733B1 (en) * | 1996-12-30 | 2003-12-16 | Hewlett-Packard Development Company, L.P. | Network communication device including bonded ports for increased bandwidth |
IL130774A0 (en) | 1997-01-03 | 2001-01-28 | Fortress Technologies Inc | Improved network security device |
US6731625B1 (en) * | 1997-02-10 | 2004-05-04 | Mci Communications Corporation | System, method and article of manufacture for a call back architecture in a hybrid network with support for internet telephony |
US6052751A (en) * | 1997-02-14 | 2000-04-18 | Advanced Micro Devices, I Nc. | Method and apparatus for changing the number of access slots into a memory |
US6178505B1 (en) | 1997-03-10 | 2001-01-23 | Internet Dynamics, Inc. | Secure delivery of information in a network |
US7821926B2 (en) | 1997-03-10 | 2010-10-26 | Sonicwall, Inc. | Generalized policy server |
US8914410B2 (en) | 1999-02-16 | 2014-12-16 | Sonicwall, Inc. | Query interface to policy server |
US6408336B1 (en) | 1997-03-10 | 2002-06-18 | David S. Schneider | Distributed administration of access to information |
US6199096B1 (en) * | 1997-03-14 | 2001-03-06 | Efusion, Inc. | Method and apparatus for synchronizing information browsing among multiple systems |
US6212192B1 (en) * | 1997-03-14 | 2001-04-03 | Itxc, Inc. | Method and apparatus for synchronizing information browsing among multiple systems |
JP3430908B2 (ja) | 1997-03-27 | 2003-07-28 | 富士通株式会社 | ネットワーク接続制御システムおよび記憶媒体 |
US6273622B1 (en) | 1997-04-15 | 2001-08-14 | Flash Networks, Ltd. | Data communication protocol for maximizing the performance of IP communication links |
US6212175B1 (en) * | 1997-04-22 | 2001-04-03 | Telxon Corporation | Method to sustain TCP connection |
US6028862A (en) * | 1997-05-08 | 2000-02-22 | 3Com Corporation | Fast path networking |
US6173399B1 (en) * | 1997-06-12 | 2001-01-09 | Vpnet Technologies, Inc. | Apparatus for implementing virtual private networks |
US6098108A (en) | 1997-07-02 | 2000-08-01 | Sitara Networks, Inc. | Distributed directory for enhanced network communication |
US6278697B1 (en) * | 1997-07-29 | 2001-08-21 | Nortel Networks Limited | Method and apparatus for processing multi-protocol communications |
US6111893A (en) * | 1997-07-31 | 2000-08-29 | Cisco Technology, Inc. | Universal protocol conversion |
US6157641A (en) * | 1997-08-22 | 2000-12-05 | Cisco Technology, Inc. | Multiprotocol packet recognition and switching |
US6324161B1 (en) * | 1997-08-27 | 2001-11-27 | Alcatel Usa Sourcing, L.P. | Multiple network configuration with local and remote network redundancy by dual media redirect |
US6006254A (en) | 1997-08-29 | 1999-12-21 | Mitsubishi Electric Information Technology Center America, Inc. | System for the reliable, fast, low-latency communication of object state updates over a computer network by combining lossy and lossless communications |
JP3641112B2 (ja) | 1997-09-05 | 2005-04-20 | 株式会社東芝 | パケット中継装置、移動計算機装置、移動計算機管理装置、パケット中継方法、パケット送信方法及び移動計算機位置登録方法 |
US6084887A (en) * | 1997-09-10 | 2000-07-04 | Alcatel Usa Sourcing. L.P. | Signaling protocol conversion system |
US6172980B1 (en) * | 1997-09-11 | 2001-01-09 | 3Com Corporation | Multiple protocol support |
US6617879B1 (en) * | 1997-09-17 | 2003-09-09 | Sony Corporation | Transparently partitioned communication bus for multi-port bridge for a local area network |
US6816490B1 (en) * | 1997-09-17 | 2004-11-09 | Sony Corporation | Statistical learning technique in a multi-port bridge for a local area network |
US6076168A (en) * | 1997-10-03 | 2000-06-13 | International Business Machines Corporation | Simplified method of configuring internet protocol security tunnels |
US5974453A (en) | 1997-10-08 | 1999-10-26 | Intel Corporation | Method and apparatus for translating a static identifier including a telephone number into a dynamically assigned network address |
US6226680B1 (en) * | 1997-10-14 | 2001-05-01 | Alacritech, Inc. | Intelligent network interface system method for protocol processing |
US6047325A (en) * | 1997-10-24 | 2000-04-04 | Jain; Lalit | Network device for supporting construction of virtual local area networks on arbitrary local and wide area computer networks |
US6198751B1 (en) * | 1997-11-19 | 2001-03-06 | Cabletron Systems, Inc. | Multi-protocol packet translator |
US6711166B1 (en) * | 1997-12-10 | 2004-03-23 | Radvision Ltd. | System and method for packet network trunking |
FR2772533B1 (fr) * | 1997-12-15 | 2001-09-28 | Inst Nat Rech Inf Automat | Dispositif d'interconnexion entre segments de reseaux communiquant selon des protocoles de formats differents, et procede correspondant |
US6178160B1 (en) | 1997-12-23 | 2001-01-23 | Cisco Technology, Inc. | Load balancing of client connections across a network using server based algorithms |
US6339595B1 (en) | 1997-12-23 | 2002-01-15 | Cisco Technology, Inc. | Peer-model support for virtual private networks with potentially overlapping addresses |
FI105753B (fi) | 1997-12-31 | 2000-09-29 | Ssh Comm Security Oy | Pakettien autentisointimenetelmä verkko-osoitemuutosten ja protokollamuunnosten läsnäollessa |
DE19800772C2 (de) * | 1998-01-12 | 2000-04-06 | Ericsson Telefon Ab L M | Verfahren und Vorrichtung zur Verbindung mit einem Paketaustauschnetz |
FR2773656B1 (fr) * | 1998-01-15 | 2000-02-11 | Alsthom Cge Alcatel | Passerelle intelligente entre un point de controle de service, et un reseau de signalisation |
US6535493B1 (en) * | 1998-01-15 | 2003-03-18 | Symbol Technologies, Inc. | Mobile internet communication protocol |
JP2002501251A (ja) * | 1998-01-22 | 2002-01-15 | イナリ、インコーポレイテッド | ユニバーサル・データ交換ゲートウエイのための方法および装置 |
US6079020A (en) * | 1998-01-27 | 2000-06-20 | Vpnet Technologies, Inc. | Method and apparatus for managing a virtual private network |
US6131163A (en) * | 1998-02-17 | 2000-10-10 | Cisco Technology, Inc. | Network gateway mechanism having a protocol stack proxy |
US7032242B1 (en) * | 1998-03-05 | 2006-04-18 | 3Com Corporation | Method and system for distributed network address translation with network security features |
US6055236A (en) * | 1998-03-05 | 2000-04-25 | 3Com Corporation | Method and system for locating network services with distributed network address translation |
US6353614B1 (en) * | 1998-03-05 | 2002-03-05 | 3Com Corporation | Method and protocol for distributed network address translation |
US6415329B1 (en) * | 1998-03-06 | 2002-07-02 | Massachusetts Institute Of Technology | Method and apparatus for improving efficiency of TCP/IP protocol over high delay-bandwidth network |
WO1999050974A1 (en) * | 1998-03-30 | 1999-10-07 | Motorola Inc. | Method for routing data in a communication system |
US6118785A (en) * | 1998-04-07 | 2000-09-12 | 3Com Corporation | Point-to-point protocol with a signaling channel |
US6343083B1 (en) * | 1998-04-09 | 2002-01-29 | Alcatel Usa Sourcing, L.P. | Method and apparatus for supporting a connectionless communication protocol over an ATM network |
US6226751B1 (en) | 1998-04-17 | 2001-05-01 | Vpnet Technologies, Inc. | Method and apparatus for configuring a virtual private network |
US6377571B1 (en) * | 1998-04-23 | 2002-04-23 | 3Com Corporation | Virtual modem for dialout clients in virtual private network |
US6154839A (en) * | 1998-04-23 | 2000-11-28 | Vpnet Technologies, Inc. | Translating packet addresses based upon a user identifier |
US6058431A (en) * | 1998-04-23 | 2000-05-02 | Lucent Technologies Remote Access Business Unit | System and method for network address translation as an external service in the access server of a service provider |
US7100020B1 (en) | 1998-05-08 | 2006-08-29 | Freescale Semiconductor, Inc. | Digital communications processor |
US6324178B1 (en) | 1998-05-26 | 2001-11-27 | 3Com Corporation | Method for efficient data transfers between domains of differing data formats |
US6556540B1 (en) * | 1998-05-29 | 2003-04-29 | Paradyne Corporation | System and method for non-intrusive measurement of service quality in a communications network |
JP3581251B2 (ja) * | 1998-06-16 | 2004-10-27 | 株式会社東芝 | 通信システム、データパケット転送方法、ルータ装置及びパケット中継装置 |
JP3946873B2 (ja) | 1998-06-19 | 2007-07-18 | 株式会社日立製作所 | ディスクアレイ制御装置 |
US6418476B1 (en) * | 1998-06-29 | 2002-07-09 | Nortel Networks, Limited | Method for synchronizing network address translator (NAT) tables using the open shortest path first opaque link state advertisement option protocol |
US6829242B2 (en) * | 1998-06-30 | 2004-12-07 | Cisco Technology, Inc. | Method and apparatus for associating PVC identifiers with domain names of home gateways |
US6377577B1 (en) | 1998-06-30 | 2002-04-23 | Cisco Technology, Inc. | Access control list processing in hardware |
GB9814412D0 (en) * | 1998-07-03 | 1998-09-02 | Northern Telecom Ltd | Communications method and apparatus |
US6360265B1 (en) * | 1998-07-08 | 2002-03-19 | Lucent Technologies Inc. | Arrangement of delivering internet protocol datagrams for multimedia services to the same server |
US6363056B1 (en) * | 1998-07-15 | 2002-03-26 | International Business Machines Corporation | Low overhead continuous monitoring of network performance |
US6519248B1 (en) * | 1998-07-24 | 2003-02-11 | Telefonaktiebolaget Lm Ericsson (Publ) | Packet data network having distributed database |
US6282589B1 (en) | 1998-07-30 | 2001-08-28 | Micron Technology, Inc. | System for sharing data buffers from a buffer pool |
US7206397B1 (en) * | 1998-08-04 | 2007-04-17 | At&T Corp. | Method for allocating network resources |
US6694429B1 (en) * | 1998-08-04 | 2004-02-17 | At&T Corp. | Method for establishing call state information without maintaining state information at gate controllers |
WO2000008812A1 (en) | 1998-08-04 | 2000-02-17 | At & T Corp. | A method for allocating network resources |
US6757290B1 (en) * | 1998-08-04 | 2004-06-29 | At&T Corp. | Method for performing gate coordination on a per-call basis |
US6870845B1 (en) * | 1998-08-04 | 2005-03-22 | At&T Corp. | Method for providing privacy by network address translation |
US6331984B1 (en) * | 1998-08-21 | 2001-12-18 | Nortel Networks Limited | Method for synchronizing network address translator (NAT) tables using the server cache synchronization protocol |
WO2000013391A1 (en) * | 1998-08-26 | 2000-03-09 | Nortel Networks Limited | NON-BROADCAST, MULTIPLE ACCESS INVERSE NEXT HOP RESOLUTION PROTOCOL (InNHRP) |
US6438612B1 (en) * | 1998-09-11 | 2002-08-20 | Ssh Communications Security, Ltd. | Method and arrangement for secure tunneling of data between virtual routers |
US6230191B1 (en) | 1998-10-05 | 2001-05-08 | Alcatel Internetworking (Pe), Inc. | Method and apparatus for regulating the amount of buffer memory requested by a port in a multi-port switching device with shared buffer memory |
US6094437A (en) * | 1998-10-09 | 2000-07-25 | Asc - Advanced Switching Communications | Layer two tunneling protocol (L2TP) merging and management |
US6219706B1 (en) | 1998-10-16 | 2001-04-17 | Cisco Technology, Inc. | Access control for networks |
US6381646B2 (en) * | 1998-11-03 | 2002-04-30 | Cisco Technology, Inc. | Multiple network connections from a single PPP link with partial network address translation |
US6411986B1 (en) * | 1998-11-10 | 2002-06-25 | Netscaler, Inc. | Internet client-server multiplexer |
US6614781B1 (en) * | 1998-11-20 | 2003-09-02 | Level 3 Communications, Inc. | Voice over data telecommunications network architecture |
US6457061B1 (en) * | 1998-11-24 | 2002-09-24 | Pmc-Sierra | Method and apparatus for performing internet network address translation |
US6754831B2 (en) * | 1998-12-01 | 2004-06-22 | Sun Microsystems, Inc. | Authenticated firewall tunneling framework |
US7194554B1 (en) * | 1998-12-08 | 2007-03-20 | Nomadix, Inc. | Systems and methods for providing dynamic network authorization authentication and accounting |
US8266266B2 (en) * | 1998-12-08 | 2012-09-11 | Nomadix, Inc. | Systems and methods for providing dynamic network authorization, authentication and accounting |
US6496505B2 (en) * | 1998-12-11 | 2002-12-17 | Lucent Technologies Inc. | Packet tunneling optimization to wireless devices accessing packet-based wired networks |
US6584122B1 (en) * | 1998-12-18 | 2003-06-24 | Integral Access, Inc. | Method and system for providing voice and data service |
US6327267B1 (en) | 1998-12-21 | 2001-12-04 | Ericssoninc | Systems and methods for routing a message through a signaling network associated with a public switched telephone network (PSTN), including a method for performing global title routing on an internet protocol (IP) address |
US6480891B1 (en) * | 1999-01-04 | 2002-11-12 | 3Com Corporation | Embedded code memory size reduction in asynchronous mode transfer devices |
US6724724B1 (en) * | 1999-01-21 | 2004-04-20 | Cisco Technology, Inc. | System and method for resolving an electronic address |
US6330562B1 (en) * | 1999-01-29 | 2001-12-11 | International Business Machines Corporation | System and method for managing security objects |
US6615357B1 (en) * | 1999-01-29 | 2003-09-02 | International Business Machines Corporation | System and method for network address translation integration with IP security |
FI106593B (fi) | 1999-02-15 | 2001-02-28 | Valtion Teknillinen | Paluuyhteydetön IP-multicast-palvelu |
US6507908B1 (en) | 1999-03-04 | 2003-01-14 | Sun Microsystems, Inc. | Secure communication with mobile hosts |
WO2000054470A1 (en) * | 1999-03-12 | 2000-09-14 | Lextron Systems, Inc. | System for controlling processing of data passing through network gateways between two disparate communications networks |
US6590861B1 (en) * | 1999-03-18 | 2003-07-08 | 3Com Corporation | Combining virtual local area networks and load balancing with fault tolerance in a high performance protocol |
US6512774B1 (en) * | 1999-03-18 | 2003-01-28 | 3Com Corporation | Fail over with multiple network interface cards |
US6757250B1 (en) * | 1999-04-12 | 2004-06-29 | Mindspeed Technologies, Inc. | Methods and apparatus for data communications through packet networks |
US6925076B1 (en) * | 1999-04-13 | 2005-08-02 | 3Com Corporation | Method and apparatus for providing a virtual distributed gatekeeper in an H.323 system |
US6888818B1 (en) * | 1999-04-15 | 2005-05-03 | Share Wave, Inc. | Protocol extension scheme for wireless computer networks |
US6563824B1 (en) | 1999-04-20 | 2003-05-13 | 3Com Corporation | Apparatus and methods for determining the correct workstation within a LAN for a LAN modem to route a packet |
US6785223B1 (en) * | 1999-04-22 | 2004-08-31 | Siemens Information And Communication Networks, Inc. | System and method for restarting of signaling entities in H.323-based realtime communication networks |
US20050038911A1 (en) * | 1999-04-30 | 2005-02-17 | Yoshikuni Watanabe | Cooperative system and method therefor |
US6515997B1 (en) | 1999-05-17 | 2003-02-04 | Ericsson Inc. | Method and system for automatic configuration of a gateway translation function |
US6760343B1 (en) * | 1999-05-20 | 2004-07-06 | Nortel Networks Limited | Method and apparatus for providing a virtual SS7 link in a communications system |
US6393488B1 (en) * | 1999-05-27 | 2002-05-21 | 3Com Corporation | System and method for supporting internet protocol subnets with network address translators |
US6683881B1 (en) * | 1999-05-28 | 2004-01-27 | Ericsson Inc. | Interface between an SS7 gateway and an IP network |
US6965943B1 (en) * | 1999-06-05 | 2005-11-15 | Lucent Technologies Inc. | End-to-end internet control |
US6957346B1 (en) * | 1999-06-15 | 2005-10-18 | Ssh Communications Security Ltd. | Method and arrangement for providing security through network address translations using tunneling and compensations |
US6633540B1 (en) * | 1999-07-02 | 2003-10-14 | Nokia Internet Communications, Inc. | Real-time traffic shaper with keep-alive property for best-effort traffic |
US7155740B2 (en) * | 2000-07-13 | 2006-12-26 | Lucent Technologies Inc. | Method and apparatus for robust NAT interoperation with IPSEC'S IKE and ESP tunnel mode |
US20020042875A1 (en) * | 2000-10-11 | 2002-04-11 | Jayant Shukla | Method and apparatus for end-to-end secure data communication |
US20030009561A1 (en) * | 2001-06-14 | 2003-01-09 | Sollee Patrick N. | Providing telephony services to terminals behind a firewall and /or network address translator |
US7346770B2 (en) | 2002-10-31 | 2008-03-18 | Microsoft Corporation | Method and apparatus for traversing a translation device with a security protocol |
CN101546874B (zh) | 2008-03-24 | 2012-04-04 | 华为技术有限公司 | 一种电连接模块、一种总配线架以及总配线架的割接方法 |
-
1999
- 1999-06-15 US US09/333,829 patent/US6957346B1/en not_active Expired - Lifetime
-
2000
- 2000-06-15 DK DK10176040.3T patent/DK2254311T3/da active
- 2000-06-15 DK DK00936931.5T patent/DK1186146T3/da active
- 2000-06-15 EP EP10176040A patent/EP2254311B1/en not_active Expired - Lifetime
- 2000-06-15 DE DE60045737T patent/DE60045737D1/de not_active Expired - Lifetime
- 2000-06-15 AU AU52250/00A patent/AU5225000A/en not_active Abandoned
- 2000-06-15 AT AT00936931T patent/ATE502468T1/de active
- 2000-06-15 JP JP2001504140A patent/JP3793083B2/ja not_active Expired - Fee Related
- 2000-06-15 AT AT10176040T patent/ATE523030T1/de active
- 2000-06-15 WO PCT/FI2000/000537 patent/WO2000078008A1/en active Application Filing
- 2000-06-15 ES ES10176040T patent/ES2369132T3/es not_active Expired - Lifetime
- 2000-06-15 PT PT00936931T patent/PT1186146E/pt unknown
- 2000-06-15 EP EP00936931A patent/EP1186146B1/en not_active Expired - Lifetime
- 2000-06-15 ES ES00936931T patent/ES2362993T3/es not_active Expired - Lifetime
- 2000-06-15 PT PT10176040T patent/PT2254311E/pt unknown
-
2005
- 2005-05-12 US US11/128,933 patent/US8127348B2/en not_active Expired - Fee Related
-
2010
- 2010-01-08 US US12/684,571 patent/US8365273B2/en not_active Expired - Fee Related
- 2010-08-24 US US12/862,305 patent/US8544079B2/en not_active Expired - Fee Related
-
2011
- 2011-09-08 US US13/228,271 patent/US8245288B2/en not_active Expired - Fee Related
-
2013
- 2013-08-26 US US13/975,492 patent/US8914872B2/en not_active Expired - Fee Related
- 2013-08-26 US US13/975,451 patent/US8973126B2/en not_active Expired - Fee Related
- 2013-08-26 US US13/975,514 patent/US8973127B2/en not_active Expired - Fee Related
- 2013-08-28 US US14/012,074 patent/US8914873B2/en not_active Expired - Fee Related
- 2013-08-28 US US14/012,180 patent/US9071578B2/en not_active Expired - Fee Related
- 2013-08-28 US US14/012,130 patent/US8918858B2/en not_active Expired - Fee Related
-
2015
- 2015-05-21 US US14/719,148 patent/US20150271140A1/en not_active Abandoned
-
2016
- 2016-09-02 US US15/255,253 patent/US9667594B2/en not_active Expired - Fee Related
Also Published As
Similar Documents
Publication | Publication Date | Title |
---|---|---|
ES2362993T3 (es) | Un método y disposición para proporcionar seguridad a través de conversión de direcciones de red utilizando tunelado y compensaciones. | |
CA2315722C (en) | A method for packet authentication in the presence of network address translations and protocol conversions | |
FI116027B (fi) | Menetelmä ja järjestelmä viestien turvallisen lähettämisen varmistamiseksi | |
KR20090061253A (ko) | 인터넷 프로토콜 보안 적용을 위한 유디피 기반의 터널링방법 및 상기 방법을 수행하는 시스템 | |
JP6075871B2 (ja) | ネットワークシステム、通信制御方法、通信制御装置及び通信制御プログラム | |
CN112751816B (zh) | 一种隧道建立方法、装置、设备及计算机可读存储介质 | |
Singh et al. | NAT Traversal Capability and Keep-Alive Functionality with IPSec in IKEv2 Implementation | |
WO2008095540A1 (en) | Ip tunneling optimisation | |
Ye et al. | Interworking between IP security and NAT-PT under IPv4/IPv6 co-existent environments | |
JP2005252464A (ja) | 通信方法、通信端末装置およびゲートウェイ装置 | |
Kim et al. | New mechanisms for end-to-end security using IPSec in NAT-based private networks |