ES2369132T3 - Mantenimiento de conversión de direcciones para datos de comunicación. - Google Patents

Mantenimiento de conversión de direcciones para datos de comunicación. Download PDF

Info

Publication number
ES2369132T3
ES2369132T3 ES10176040T ES10176040T ES2369132T3 ES 2369132 T3 ES2369132 T3 ES 2369132T3 ES 10176040 T ES10176040 T ES 10176040T ES 10176040 T ES10176040 T ES 10176040T ES 2369132 T3 ES2369132 T3 ES 2369132T3
Authority
ES
Spain
Prior art keywords
package
address conversion
active maintenance
address
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
Application number
ES10176040T
Other languages
English (en)
Inventor
Tero Kivinen
Tatu Ylonen
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
SSH Communications Security Oy
Original Assignee
SSH Communications Security Oy
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Family has litigation
First worldwide family litigation filed litigation Critical https://patents.darts-ip.com/?family=23304429&utm_source=google_patent&utm_medium=platform_link&utm_campaign=public_patent_search&patent=ES2369132(T3) "Global patent litigation dataset” by Darts-ip is licensed under a Creative Commons Attribution 4.0 International License.
Application filed by SSH Communications Security Oy filed Critical SSH Communications Security Oy
Application granted granted Critical
Publication of ES2369132T3 publication Critical patent/ES2369132T3/es
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • 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]

Abstract

Procedimiento para mantener la comunicación de datagramas en un sistema de comunicación en el que la conversión de dirección es proporcionada por un conversor (305) de dirección de red para comunicación de datagramas entre un primer dispositivo y un segundo dispositivo, caracterizado por mantener una conversión de dirección de red determinada para comunicación de datagramas entre el primer dispositivo y el segundo dispositivo enviando (306) desde el primer dispositivo o el segundo dispositivo por lo menos un paquete de mantenimiento en activo antes de la finalización del intervalo de retardo de la conversión de dirección de red determinada.

Description

Mantenimiento de conversión de direcciones para datos de comunicación.
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 del establecimiento y mantenimiento de conexiones de comunicaciones seguras a través de una Conversión o Transformación de direcciones de red o conversión de protocolo.
El Grupo de Trabajo de Ingeniería de Internet (IETF) ha normalizado el conjunto de programas 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 modos sea el utilizado.
En los últimos años, cada vez más vendedores 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 anfitrión NAT 101 y el puerto NAT 151. El anfitrión NAT 101 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 también toca los números puerto de TCP y de 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 sola dirección IP 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 de NAT; en la práctica hay muchas formas posibles de conectar físicamente una NAT.
La conversión de direcciones tiene lugar más frecuentemente en el borde de una red local (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 de NAT dentro del Grupo de Trabajo de Ingeniería de Internet. Los principios operativos de un dispositivo de NAT son ampliamente conocidos, y existen muchas implementaciones de múltiples vendedores disponibles en el mercado, incluidas varias implementaciones con códigos fuentes de acceso gratis. La operación típica de una NAT se puede describir de modo que pone en correspondencia direcciones IP y combinaciones de puertos con diferentes direcciones IP y combinaciones de puertos. La puesta en correspondencia 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 transmisor 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 está situado en una segunda red de área local 186 que está a su vez acoplada a una red de área-ancha a través de una NAT 187. Las denominaciones “nodo transmisor” y “nodo receptor” son algo engañosas, dado que se necesita una comunicación bidireccional para establecer servicios de seguridad de la red. El nodo transmisor 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 ni de 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 NAT, hay otro tipo de dispositivos en la red de Internet que pueden modificar legalmente paquetes durante su transmisión. Un ejemplo típico es un 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 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 patente 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.
El proyecto de Internet del Grupo de Trabajo de Redes “Terminología de Referencia para Prestaciones de Cortafuegos” (‘Bench-marking Terminology for Firewall Performance’) de Mayo de 1999 por D. Newman, XPO150161991SSN, sección 3.10 “Mantenimiento de Conexión” describe el uso de “mantenero en activación” datos para mantener una conexión a través de un cortafuego en algunas implementaciones de TCP y otros protocolos de conexión orientada durante el período en el que no se han intercambiado datos de usuario.
Es un objetivo de la presente invención presentar un método y un aparato para proporcionar servicios de seguridad de red a una red sobre conversión de direcciones de red de forma fiable y ventajosa.
El método de acuerdo con la invención está definido en las reivindicaciones independientes 1 y 2 y los dispositivos acordes con la invención están definidos en la reivindicaciones independientes 8 y 9. Aspectos más detallados del invento están definidos en las reivindicaciones dependientes.
La Fig. 1a ilustra el uso conocido de un anfitrión 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 basada en conmutación de paquetes,
La Fig. 2a ilustra una cierta carga neta de ID de Vendedor aplicable dentro del contexto de la invención,
La Fig. 2b. ilustra una cierta carga neta 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 carácter inventivo 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 NAT usadas en la práctica son puertos NAT, y ésta es la forma en que la 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 hecha corresponder 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 anfitrión 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 alguna (el aspecto “conversiones en curso”),
− entunelar paquetes dentro de un protocolo cuidadosamente seleccionado, típicamente UDP, para hacerlos recorrer la NAT (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 anfitriones que han sido hechos corresponder a una sola dirección pública (el aspecto “compensación/puesta en correspondencia”).
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ándolos por otra cabecera, siempre que en el proceso se conserve la cantidad de información sobre el paquete original 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 ser hecha pasar con el paquete depende de los protocolos de red, y la información puede ser hecha pasar ya sea de modo explícito (como parte del paquete entunelado) 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 de Intercambio de Clave Internet o IKE (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 neta 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 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 Vendedor es, para los fines de esta invención, la parte más importante de la carga neta de ID 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 seguras sobre una red. La terminología utilizada aquí está tomada de los documentos INE.
El protocolo IKE determina la llamada Fase 1 del intercambio mutuo de mensajes entre el Iniciador (es decir, el nodo que envía en primer lugar un paquete al otro) y el Respondedor (es decir, el nodo que recibe en primer lugar un paquete). La Fig. 3 ilustra un intercambio de los primeros mensajes de 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 neta de ID del Vendedor en un cierto mensaje de la Fase 1 que es preferiblemente su primer mensaje de Fase 1. Esta carga neta indica que soportan el método en cuestión. En la Fig. 3 los campos de ID del Vendedor contenidos dentro del primer mensaje de la Fase 1 (u otro distinto) del Iniciador están esquemáticamente mostrados como se ha mostrado esquemáticamente como 201´ y los otros campos de ID del Vendedor contenidos dentro del primer mensaje de la Fase 1 (u otro distinto) del Respondedor están esquemáticamente mostrados como 201´´. La presencia de un determinado método se indica mediante el campo de ID del Vendedor en la Carga neta de ID del Vendedor es básicamente una identificación de ese método: ventajosamente el hash MD5 de una cadena de identificación previamente conocida, por ejemplo “SSH IPSEC NAT Transversal Version 1”, sin ningún cero posterior 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 las direcciones IP que ven en las cargas netas privadas de ciertos mensajes de Modo Rápido de Fase 2, que son preferiblemente sus primeros mensajes de Modo Rápido de 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 las conversiones 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 de 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. En la cabecera son sensibles a las conversiones de direcciones y otros procesos mientras que 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ían con las estructuras de datos para las asociaciones de seguridad Fase 1 ISAKMP, y se utilizarían para establecer el proceso de compensación para las asociaciones de seguridad Fase 2 IPSEC.
Para usar el método descrito anteriormente para implementar el aspecto de la invención de “conversiones ocurridas”, los anfitriones 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 en restringir las cargas netas a los tipos ID_IPV4_ADDR e ID_IPV6_ADDR que serían apropiadas para una operación anfitrión a anfitrión.
A continuación se hará referencia a los aspectos de la invención “entunelación seleccionada”, “compensación/autenticación” y “compensación/puesta en correspondencia”. 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 método 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 “cookies” con todo ceros en sus cuatro primeros bytes. Por tanto se usa el valor cero en los cuatro bytes correspondientes para reconocer el paquete como un paquete de datos entunelados. De este modo, los paquetes de datos entunelados tendrían cuatro bytes 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 protocolo de conversión correspondiente antes de su encapsulación en UDP.
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 el 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 NAT, éste 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 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 calcularlo o comprobarlo 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 real. 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 auténticos. Naturalmente se puede elegir algún otro valor fijado distinto de “todo ceros”, pero el valor debe fijarse 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 anfitrión 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 anfitrión,
•
la dirección de origen es la dirección de origen de un anfitrión con el que este anfitrión ha acordado usar esta entunelación,
•
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 anfitrión 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 sustituir la dirección de origen del paquete recibido por la dirección de origen auténtica 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 procesamiento 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 procesamiento AH/ESP en el nodo receptor.
Después de que el paquete se haya 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 el 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 anfitrión en vez de como la dirección interna original. Alternativamente, el emisor del paquete podría haber realizado esta compensación antes de encapsularlo dentro de 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 procesamiento (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 procesamiento. La dirección distante del paquete se substituye por esta dirección antes de que el paquete sea enviado a las pilas 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 anfitrión o los números de puerto. Los cálculos de verificar-suma TCP pueden ser incrementales tal y como se conoce a partir 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 necesaria 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 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 pila TCP/IP en la máquina local para reservar números de puerto UDP.
En general, esta invención no limita el método usado para compensar en los paquetes internos la NAT que tenga lugar en la cabecera externa. 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 puesta en correspondencia de las direcciones, de modo que pueden invertir la puesta en correspondencia 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 una determinada puesta en correspondencia. Sin embargo, para UDP no hay indicación explicita de finalización de flujos. Por esta razón, muchas NAT limitan bastante el tiempo de espera de puestas en correspondencia para UDP (incluso tanto como 30 segundos). Por tanto, se hace necesario forzar el mantenimiento de la puesta en correspondencia.
Una forma posible de asegurar el mantenimiento de las puestas en correspondencia 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 mantenimiento en activo dentro del intervalo más corto en que se haya estimado que las NAT pueden olvidar la puesta en correspondencia. La frecuencia apropiada depende tanto del período de tiempo en el que la puesta en correspondencia permanece memorizada 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 mantenimiento en activo 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 mantenimiento en activo sean gestionados exactamente de la misma manera que los paquetes de datos reales. Un paquete de mantenimiento en activo puede contener un indicador que lo identifique como paquete de mantenimiento en activo 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 mantenimiento en activo. En la FIG. 3 se ilustra esquemáticamente en el bloque 306 la transmisión de paquetes de mantenimiento en activo 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 mantenimiento en activo no es en absoluto necesario 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 puesta en correspondencia de su memoria caché. Sólo es necesario transmitir los paquetes de mantenimiento en activo 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 o direcciones en que los paquetes de mantenimiento en activo (si los hay) son transmitidos.
La Fig. 5 es un diagrama de bloques 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. La 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 mostrada). 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 transformaciones 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 mantenimiento en activo. El bloque 506 ensamblador/desensamblador es el que interviene entre los bloques 502 a 505 y la interfaz física 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 procedimientos 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.
Incluso aunque la presente invención 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. La invención 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 contenidas 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. Rivet: 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 1
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 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
P. Srisuresh: Security Model for Network Address Translator (NAT) Domains, draft-ietf-nat-security-01.txt, Work in 5 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.
TYS99
10 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 (15)

  1. REIVINDICACIONES
    1.
    Procedimiento para mantener la comunicación de datagramas en un sistema de comunicación en el que la conversión de dirección es proporcionada por un conversor (305) de dirección de red para comunicación de datagramas entre un primer dispositivo y un segundo dispositivo, caracterizado por mantener una conversión de dirección de red determinada para comunicación de datagramas entre el primer dispositivo y el segundo dispositivo enviando (306) desde el primer dispositivo o el segundo dispositivo por lo menos un paquete de mantenimiento en activo antes de la finalización del intervalo de retardo de la conversión de dirección de red determinada.
  2. 2.
    Procedimiento para proporcionar conversiones de direcciones por un conversor (305) de dirección de red, que comprende determinar una conversión de dirección para comunicación de datagramas entre un primer dispositivo y un segundo dispositivo; caracterizado por recibir al menos un paquete de conservación en activo desde el primer dispositivo y/o el segundo dispositivo antes de la finalización del intervalo de retardo de la conversión de dirección determinada para la comunicación de datagramas; y en respuesta a la recepción de al menos un paquete de mantenimiento en activo, mantener la conversión de dirección de red determinada para la comunicación de datagramas entre el primer dispositivo y el segundo dispositivo.
  3. 3.
    Un procedimiento según la reivindicación 1 ó 2, en el que al menos un paquete de mantenimiento en activo comprende una cabecera que es igual a las cabeceras de los datagramas.
  4. 4.
    Un procedimiento según cualquier reivindicación precedente, en el que al menos un paquete de mantenimiento en activo contiene un indicador que lo identifica como un paquete de mantenimiento en activo.
  5. 5.
    Un procedimiento según cualquier reivindicación precedente, en el que un paquete es interpretado como un paquete de mantenimiento en activo si no contiene ninguna carga neta significativa.
  6. 6.
    Un procedimiento según la reivindicación 1 o cualquier reivindicación dependiente de la reivindicación 1, que comprende la determinación de un período de tiempo más corto para la finalización del intervalo de retardo, y basado en la determinación, enviando al menos el paquete de mantenimiento en activo lo bastante frecuentemente para mantener la conversión de dirección determinada en el conversor (305) de dirección de red.
  7. 7.
    Un procedimiento según la reivindicación 1 o las reivindicaciones dependientes de la reivindicación 1, que comprende tener en cuenta la posibilidad de pérdida de paquete para determinar la frecuencia de envío de al menos el paquete de mantenimiento en activo.
  8. 8.
    Un dispositivo (500) para comunicación de datagramas en un sistema de comunicación en el que el la conversión de dirección es proporcionada por un conversor (305) de dirección de red para comunicación de datagramas entre el dispositivo y un segundo dispositivo, caracterizado por medios (504 o 505) para mantener una conversión de dirección de red determinada para la comunicación de datagramas entre el dispositivo y el segundo dispositivo provocando el envío de al menos un paquete de mantenimiento en activo antes de la finalización del intervalo de retardo de la conversión de direcciones de red determinada.
  9. 9.
    Un dispositivo para conversiones de direcciones de red (305), que comprende medios para determinar una conversión de dirección para comunicación de datagramas entre un primer dispositivo y un segundo dispositivo; caracterizado por medios para mantener la conversión de dirección de red determinada para la comunicación de datagramas entre el primer dispositivo y el segundo dispositivo en respuesta a la recepción de al menos un paquete de mantenimiento en activo desde el primer dispositivo y/o el segundo dispositivo antes de la finalización del intervalo de retardo de la conversión de dirección determinada para la comunicación de datagramas.
  10. 10.
    Un dispositivo según la reivindicación 8 ó 9, en el que al menos un paquete de mantenimiento en activo comprende una cabecera que es igual a las cabeceras de los datagramas.
  11. 11.
    Un dispositivo según cualquiera de las reivindicaciones 8 a 10, en el que al menos un paquete de mantenimiento en activo contiene un identificador que lo identifica como un paquete de mantenimiento en activo.
  12. 12.
    Un dispositivo según cualquiera de las reivindicaciones 8 a 11, en el que el dispositivo está configurado para interpretar un paquete como un paquete de mantenimiento en activo si el paquete no contiene ninguna carga neta significativa.
  13. 13.
    Un dispositivo (500) según la reivindicación 8 o cualquier reivindicación dependiente de la reivindicación 8, en el que los medios para mantenimiento están configurados para provocar el envío de al menos un paquete de mantenimiento en activo lo bastante frecuentemente para mantener la conversión de dirección determinada.
  14. 14.
    Un dispositivo (500) según la reivindicación 8 o cualquier reivindicación dependiente de la reivindicación 8, en el que los medios para mantenimiento están configurados para tener en cuenta la posibilidad de la pérdida de un paquete en la determinación de la frecuencia de envío.
  15. 15.
    Un programa de ordenador que comprende medios de código de programa adaptados para realizar cualquiera de las etapas de cualquiera de las reivindicaciones 1 a 7 cuando el programa se ejecutado en un procesador.
ES10176040T 1999-06-15 2000-06-15 Mantenimiento de conversión de direcciones para datos de comunicación. Expired - Lifetime ES2369132T3 (es)

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
ES2369132T3 true ES2369132T3 (es) 2011-11-25

Family

ID=23304429

Family Applications (2)

Application Number Title Priority Date Filing Date
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.
ES10176040T Expired - Lifetime ES2369132T3 (es) 1999-06-15 2000-06-15 Mantenimiento de conversión de direcciones para datos de comunicación.

Family Applications Before (1)

Application Number Title Priority Date Filing Date
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.

Country Status (10)

Country Link
US (13) US6957346B1 (es)
EP (2) EP1186146B1 (es)
JP (1) JP3793083B2 (es)
AT (2) ATE502468T1 (es)
AU (1) AU5225000A (es)
DE (1) DE60045737D1 (es)
DK (2) DK2254311T3 (es)
ES (2) ES2362993T3 (es)
PT (2) PT1186146E (es)
WO (1) WO2000078008A1 (es)

Families Citing this family (135)

* Cited by examiner, † Cited by third party
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 インターナショナル・ビジネス・マシーンズ・コーポレーション Ｖｐｎ接続のセキュリティ
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
WO2002003217A1 (en) * 2000-06-30 2002-01-10 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 株式会社日立製作所 マルチキャスト通信方法および通信装置
CA2725700C (en) 2000-12-22 2015-11-24 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
US8077679B2 (en) 2001-03-28 2011-12-13 Qualcomm Incorporated Method and apparatus for providing protocol options in a wireless communication system
US9100457B2 (en) 2001-03-28 2015-08-04 Qualcomm Incorporated Method and apparatus for transmission framing in a wireless communication system
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
US20030009561A1 (en) * 2001-06-14 2003-01-09 Sollee Patrick N. Providing telephony services to terminals behind a firewall and /or network address translator
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
AU2003209194A1 (en) * 2002-01-08 2003-07-24 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
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
US7191331B2 (en) * 2002-06-13 2007-03-13 Nvidia Corporation Detection of support for security protocol and address translation integration
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
US7624264B2 (en) * 2003-03-27 2009-11-24 Microsoft Corporation Using time to determine a hash extension
US7409544B2 (en) * 2003-03-27 2008-08-05 Microsoft Corporation Methods and systems for authenticating messages
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
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
KR20060028482A (ko) * 2003-07-03 2006-03-29 코닌클리케 필립스 일렉트로닉스 엔.브이. 보안 간접 어드레싱
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
CN1833403B (zh) * 2003-08-08 2011-05-25 小川惠子 通信系统、通信装置、通信方法
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
AU2003277691A1 (en) * 2003-11-03 2005-05-19 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 삼성전자주식회사 소켓 어플리케이션 프로그램을 이용한 데이터 중계 시스템및 데이터 중계 방법
US7962623B2 (en) * 2004-06-30 2011-06-14 Microsoft Corporation Sustaining session connections
US7929689B2 (en) 2004-06-30 2011-04-19 Microsoft Corporation Call signs
JP4440056B2 (ja) * 2004-09-27 2010-03-24 パナソニック株式会社 情報処理装置、通信処理装置、情報処理システム、情報処理方法、及び通信処理方法
JP4759382B2 (ja) * 2004-12-21 2011-08-31 株式会社リコー 通信機器、通信方法、通信プログラム、及び記録媒体
CN101129035A (zh) * 2005-02-28 2008-02-20 日本电气株式会社 通信装置、通信系统、通信方法以及程序
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
US8529517B2 (en) * 2005-05-02 2013-09-10 Shi Zi Technology, Ltd. Autoflush syringe
US8936577B2 (en) 2005-05-02 2015-01-20 Shi Zi Technology, Ltd. Methods and devices for autoflush syringes
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
WO2009005879A2 (en) * 2007-04-23 2009-01-08 Law Enforcement Support Agency 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
US8789202B2 (en) 2008-11-19 2014-07-22 Cupp Computing As Systems and methods for providing real time access monitoring of a removable media device
CA2745485C (en) 2008-12-04 2018-07-17 Nokia Corporation Proprietary extensions in user plane location protocols
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
SG10201404164WA (en) * 2009-07-31 2014-10-30 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
EP2898627A1 (en) * 2012-10-22 2015-07-29 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
US11157976B2 (en) 2013-07-08 2021-10-26 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
WO2015123611A2 (en) 2014-02-13 2015-08-20 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)

* Cited by examiner, † Cited by third party
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
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
US5574849A (en) * 1992-12-17 1996-11-12 Tandem Computers Incorporated Synchronized data transmission between elements of a processing system
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
WO1996016515A1 (en) * 1994-11-17 1996-05-30 Northern Telecom Limited 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
US5996019A (en) 1995-07-19 1999-11-30 Fujitsu Network Communications, Inc. Network link access scheduling using a plurality of prioritized lists containing queue identifiers
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
AU707905B2 (en) * 1996-04-24 1999-07-22 Nortel Networks Corporation Internet protocol filter
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
US7274662B1 (en) * 1998-08-04 2007-09-25 At&T Corp. Method for performing segmented resource reservation
CA2218218A1 (en) * 1996-11-08 1998-05-08 At&T Corp. Promiscuous network monitoring utilizing multicasting within a switch
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
US6335927B1 (en) * 1996-11-18 2002-01-01 Mci Communications Corporation System and method for providing requested quality of service in a hybrid network
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
EP0951767A2 (en) 1997-01-03 1999-10-27 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
US6408336B1 (en) 1997-03-10 2002-06-18 David S. Schneider Distributed administration of access to information
US8914410B2 (en) 1999-02-16 2014-12-16 Sonicwall, Inc. Query interface to policy server
US7821926B2 (en) 1997-03-10 2010-10-26 Sonicwall, Inc. Generalized policy server
US6212192B1 (en) * 1997-03-14 2001-04-03 Itxc, Inc. Method and apparatus for synchronizing information browsing among multiple systems
US6199096B1 (en) * 1997-03-14 2001-03-06 Efusion, 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
AU2331099A (en) * 1998-01-22 1999-08-09 Intelogis, Inc. Method and apparatus for universal data exchange gateway
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
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
US6377571B1 (en) * 1998-04-23 2002-04-23 3Com Corporation Virtual modem for dialout clients in virtual private network
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
US6377577B1 (en) 1998-06-30 2002-04-23 Cisco Technology, Inc. Access control list processing in hardware
US6829242B2 (en) * 1998-06-30 2004-12-07 Cisco Technology, Inc. Method and apparatus for associating PVC identifiers with domain names of home gateways
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
US6870845B1 (en) * 1998-08-04 2005-03-22 At&T Corp. Method for providing privacy by network address translation
US6324279B1 (en) 1998-08-04 2001-11-27 At&T Corp. Method for exchanging signaling messages in two phases
US6757290B1 (en) * 1998-08-04 2004-06-29 At&T Corp. Method for performing gate coordination on a per-call basis
US6694429B1 (en) * 1998-08-04 2004-02-17 At&T Corp. Method for establishing call state information without maintaining state information at gate controllers
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
EP1108320A1 (en) * 1998-08-26 2001-06-20 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
US6512774B1 (en) * 1999-03-18 2003-01-28 3Com Corporation Fail over with multiple network interface cards
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
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 华为技术有限公司 一种电连接模块、一种总配线架以及总配线架的割接方法

Also Published As

Publication number Publication date
DE60045737D1 (de) 2011-04-28
US8914873B2 (en) 2014-12-16
ES2362993T3 (es) 2011-07-18
US20110320623A1 (en) 2011-12-29
US20140007219A1 (en) 2014-01-02
EP1186146A1 (en) 2002-03-13
US8918858B2 (en) 2014-12-23
DK2254311T3 (da) 2011-10-03
EP1186146B1 (en) 2011-03-16
PT1186146E (pt) 2011-06-07
US20130346556A1 (en) 2013-12-26
US8973126B2 (en) 2015-03-03
US8365273B2 (en) 2013-01-29
US8973127B2 (en) 2015-03-03
AU5225000A (en) 2001-01-02
US20130346555A1 (en) 2013-12-26
US20160373406A1 (en) 2016-12-22
US8914872B2 (en) 2014-12-16
US9071578B2 (en) 2015-06-30
US8245288B2 (en) 2012-08-14
US9667594B2 (en) 2017-05-30
US20130347122A1 (en) 2013-12-26
US8544079B2 (en) 2013-09-24
US20100138560A1 (en) 2010-06-03
EP2254311A1 (en) 2010-11-24
US20150271140A1 (en) 2015-09-24
EP2254311B1 (en) 2011-08-31
US20100318682A1 (en) 2010-12-16
US8127348B2 (en) 2012-02-28
ATE523030T1 (de) 2011-09-15
WO2000078008A1 (en) 2000-12-21
PT2254311E (pt) 2011-09-29
JP2003502913A (ja) 2003-01-21
US20130339524A1 (en) 2013-12-19
US20140033296A1 (en) 2014-01-30
JP3793083B2 (ja) 2006-07-05
US20060256815A1 (en) 2006-11-16
ATE502468T1 (de) 2011-04-15
DK1186146T3 (da) 2011-07-04
US6957346B1 (en) 2005-10-18

Similar Documents

Publication Publication Date Title
ES2369132T3 (es) Mantenimiento de conversión de direcciones para datos de comunicación.
CA2315722C (en) A method for packet authentication in the presence of network address translations and protocol conversions
US20020042875A1 (en) Method and apparatus for end-to-end secure data communication
US20040143758A1 (en) Method for mapping security associations to clients operating behind a network address translation device
FI116027B (fi) Menetelmä ja järjestelmä viestien turvallisen lähettämisen varmistamiseksi
KR100479261B1 (ko) 네트워크 주소 변환 상에서의 데이터 전송 방법 및 장치
CN109981820B (zh) 一种报文转发方法及装置
Ahmad et al. IPSec over heterogeneous IPv4 and IPv6 networks: issues and implementation
KR20090061253A (ko) 인터넷 프로토콜 보안 적용을 위한 유디피 기반의 터널링방법 및 상기 방법을 수행하는 시스템
CN112751816B (zh) 一种隧道建立方法、装置、设备及计算机可读存储介质
Kim et al. New mechanisms for end-to-end security using IPSec in NAT-based private networks
JP2006033350A (ja) 代理セキュアルータ装置及びプログラム
Ye et al. Interworking between IP security and NAT-PT under IPv4/IPv6 co-existent environments
JP2005252464A (ja) 通信方法、通信端末装置およびゲートウェイ装置