ES2760905T3 - Un protocolo de red agile para comunicaciones seguras con disponibilidad asegurada de sistema - Google Patents

Un protocolo de red agile para comunicaciones seguras con disponibilidad asegurada de sistema Download PDF

Info

Publication number
ES2760905T3
ES2760905T3 ES16165347T ES16165347T ES2760905T3 ES 2760905 T3 ES2760905 T3 ES 2760905T3 ES 16165347 T ES16165347 T ES 16165347T ES 16165347 T ES16165347 T ES 16165347T ES 2760905 T3 ES2760905 T3 ES 2760905T3
Authority
ES
Spain
Prior art keywords
node
tarp
address
packet
addresses
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
ES16165347T
Other languages
English (en)
Inventor
Edmund Colby Munger
Vincent Sabio
Robert Short
Virgil Gligor
Douglas Schmidt
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.)
Virnetx Inc
Original Assignee
Virnetx Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Virnetx Inc filed Critical Virnetx Inc
Anticipated expiration legal-status Critical
Application granted granted Critical
Publication of ES2760905T3 publication Critical patent/ES2760905T3/es
Expired - Lifetime legal-status Critical Current

Links

Classifications

    • 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/2539—Hiding addresses; Keeping addresses anonymous
    • 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/20—Hop count for routing purposes, e.g. TTL
    • 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/24—Multipath
    • 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/30—Managing network names, e.g. use of aliases or nicknames
    • 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
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/50—Address allocation
    • H04L61/5076—Update or notification mechanisms, e.g. DynDNS
    • 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/5092—Address allocation by self-assignment, e.g. picking addresses at random and testing if they are already in use
    • 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/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/0407—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the identity of one or more communicating identities is hidden
    • 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/0407—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the identity of one or more communicating identities is hidden
    • H04L63/0421—Anonymous communication, i.e. the party's identifiers are hidden from the other party or parties, e.g. using an anonymizer
    • 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/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
    • H04L63/0435—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 wherein the sending and receiving network entities apply symmetric encryption, i.e. same key used for encryption and decryption
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/14—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
    • H04L63/1441—Countermeasures against malicious traffic
    • 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/14—Multichannel or multilink protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/06—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols the encryption apparatus using shift registers or memories for block-wise or stream coding, e.g. DES systems or RC4; Hash functions; Pseudorandom sequence generators
    • H04L9/065—Encryption by serially and continuously modifying data stream elements, e.g. stream cipher systems, RC4, SEAL or A5/3
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M3/00—Automatic or semi-automatic exchanges
    • H04M3/42—Systems providing special services or facilities to subscribers
    • H04M3/42008—Systems for anonymous communication between parties, e.g. by use of disposal contact identifiers
    • 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/604—Address structures or formats
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/14—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
    • H04L63/1441—Countermeasures against malicious traffic
    • H04L63/1491—Countermeasures against malicious traffic using deception as countermeasure, e.g. honeypots, honeynets, decoys or entrapment

Abstract

Un método para un primer nodo (801) para establecer una sesión con un segundo nodo (811), el método se realiza en el primer nodo (801), en el que el método comprende: enviar, desde una primera dirección para el primer nodo (801) a una primera dirección para el segundo nodo (811), una solicitud (821) para iniciar la sesión; y recibir, en la primera dirección para el primer nodo (801) desde la primera dirección para el segundo nodo (811), un primer mensaje (822) de confirmación, caracterizado porque: el primer mensaje de confirmación incluye un bloqueo de transmisión que el primer nodo (801) se utiliza para comunicarse con el segundo nodo (811) durante la sesión, en el que el bloque de salto de transmisión comprende: un bloque de direcciones IP; y un algoritmo y una semilla de aleatorización para seleccionar, del bloque de direcciones IP, una dirección de origen y una dirección de destino para utilizar en la transmisión del siguiente mensaje; y además caracterizado porque el método comprende, además: durante la sesión, comunicarse con el segundo nodo (811) utilizando una segunda dirección para el primer nodo (801) y una segunda dirección para el segundo nodo (811), en el que las segundas direcciones son especificadas por el bloque de salto de transmisión.

Description

DESCRIPCIÓN
Un protocolo de red agile para comunicaciones seguras con disponibilidad asegurada de sistema
Antecedentes de la invención
Se han propuesto e implementado una tremenda variedad de métodos para proporcionar seguridad y anonimato para las comunicaciones a través de Internet. La variedad proviene, en parte, de las diferentes necesidades de los diferentes usuarios de Internet. En la figura 1 se ilustra un marco heurístico básico para ayudar a discutir estas diferentes técnicas de seguridad. Dos terminales, un terminal 100 de origen y un terminal 110 de destino están en comunicación a través de Internet. Se desea que las comunicaciones sean seguras, es decir, inmunes a las escuchas. Por ejemplo, el terminal 100 puede transmitir información secreta al terminal 110 a través de Internet 107. Además, puede desear evitar que un espía descubra que el terminal 100 está en comunicación con el terminal 110. Por ejemplo, si el terminal 100 es un usuario y un terminal 110 aloja un sitio web, el usuario de la terminal 100 puede no querer que nadie en las redes intermedias sepa qué sitios web está “visitando”. El anonimato sería, por lo tanto, un problema, por ejemplo, para las empresas que desean mantener en privado sus intereses de investigación de mercado y, por lo tanto, preferirían evitar que personas externas sepan qué sitios web u otros recursos de Internet están “visitando”. Estos dos problemas de seguridad pueden denominarse seguridad de datos y anonimato, respectivamente.
La seguridad de los datos generalmente se aborda utilizando alguna forma de cifrado de datos. Se conoce una clave de cifrado 48 en los terminales 100 y 110 de origen y de destino. Las claves pueden ser privadas y públicas en los terminales 100 y 110 de origen y destino, respectivamente, o pueden ser claves simétricas (ambas partes utilizan la misma clave) cifrar y descifrar). Muchos métodos de cifrado son conocidos y utilizables en este contexto.
Para ocultar el tráfico de un administrador local o ISP, un usuario puede emplear un servidor proxy local para comunicarse a través de un canal cifrado con un proxy externo, de modo que el administrador local o ISP solo vea el tráfico cifrado. Los servidores proxy evitan que los servidores de destino determinen las identidades de los clientes de origen. Este sistema emplea un servidor intermedio interpuesto entre el cliente y el servidor de destino. El servidor de destino solo ve la dirección de Protocolo de Internet (IP) del servidor proxy y no el cliente de origen. El servidor de destino solo ve la dirección del proxy externo. Este esquema se basa en un servidor proxy externo de confianza. Además, los esquemas de proxy son vulnerables a los métodos de análisis de tráfico para determinar las identidades de los transmisores y receptores. Otra limitación importante de los servidores proxy es que el servidor conoce las identidades de las partes llamantes y llamadas. En muchos casos, un terminal de origen, como el terminal A, preferiría mantener su identidad oculta del proxy, por ejemplo, si el servidor proxy es proporcionado por un proveedor de servicios de Internet (ISP).
Para vencer el análisis del tráfico, un esquema llamado mezclas de Chaum emplea un servidor proxy que transmite y recibe mensajes de longitud fija, incluidos mensajes ficticios. Múltiples terminales de origen están conectadas a través de una mezcla (un servidor) a múltiples servidores de destino. Es difícil saber cuál de los terminales de origen se está comunicando con cuál de los servidores de destino conectados, y los mensajes ficticios confunden los esfuerzos de los espías para detectar pares de comunicación mediante el análisis del tráfico. Un inconveniente es que existe el riesgo de que el servidor mixto se vea comprometido. Una forma de lidiar con este riesgo es difundir la confianza entre múltiples mezclas. Si una mezcla se ve comprometida, las identidades de los terminales de origen y destino pueden permanecer ocultas. Esta estrategia requiere una serie de mezclas alternativas para que los servidores intermedios interpuestos entre los terminales de origen y destino no sean determinables, salvo comprometer más de una mezcla. La estrategia envuelve el mensaje con múltiples capas de direcciones cifradas. La primera mezcla en una secuencia puede descifrar solo la capa externa del mensaje para revelar la siguiente mezcla de destino en secuencia. La segunda mezcla puede descifrar el mensaje para revelar la próxima mezcla y así sucesivamente. El servidor de destino recibe el mensaje y, opcionalmente, una carga útil cifrada de múltiples capas que contienen información de retorno para enviar datos de la misma manera. La única forma de vencer ese esquema de mezcla es coludir entre mezclas. Si todos los paquetes son de longitud fija y se entremezclan con paquetes ficticios, no hay forma de hacer ningún tipo de análisis de tráfico.
Aún otra técnica de anonimato, llamada 'multitudes', protege la identidad del terminal de origen de los proxies intermedios al proporcionar que los terminales de origen pertenecen a grupos de proxies llamados multitudes. Los proxies de la multitud se interponen entre terminales de origen y destino. Cada proxy a través del cual se envía el mensaje es elegido aleatoriamente por un proxy en dirección de la red. Cada proxy intermedio puede enviar el mensaje a otro proxy elegido al azar en la “multitud” o al destino. Por lo tanto, incluso los miembros de la multitud no pueden determinar si un proxy anterior es el creador del mensaje o si simplemente se pasó desde otro proxy.
El protocolo IP anónimo ZKS (Zero-Knowledge Systems) permite a los usuarios seleccionar hasta cinco seudónimos diferentes, mientras que el software de escritorio cifra el tráfico saliente y lo envuelve en paquetes del Protocolo de Datagramas de Usuario (UDP). El primer servidor en un sistema de 2+- saltos obtiene los paquetes UDP, elimina una capa de cifrado para agregar otra, luego envía el tráfico al siguiente servidor, que elimina otra capa de cifrado y agrega una nueva. El usuario puede controlar el número de saltos. En el servidor final, el tráfico se descifra con una dirección IP no rastreable. La técnica se llama enrutamiento de cebolla. Este método puede ser derrotado utilizando análisis de tráfico. Por un simple ejemplo, las ráfagas de paquetes de un usuario durante los períodos de poca actividad pueden revelar las identidades del remitente y el receptor.
Los cortafuegos intentan proteger las LAN del acceso no autorizado y la explotación hostil o el daño a los ordenadores conectadas a la LAN. Los cortafuegos proporcionan un servidor a través del cual debe pasar todo el acceso a la LAN. Los cortafuegos son sistemas centralizados que requieren una sobrecarga administrativa para mantenerse. Pueden verse comprometidos por aplicaciones de máquinas virtuales (“applets”). Infunden una falsa sensación de seguridad que conduce a violaciones de seguridad, por ejemplo, por parte de los usuarios que envían información confidencial a servidores fuera del cortafuegos o alientan el uso de módems para evadir la seguridad del cortafuegos. Los cortafuegos no son útiles para sistemas distribuidos como viajeros de negocios, extranets, equipos pequeños, etc.
El documento WO 98/31107 se refiere al denominado “enrutamiento de réplica” que dirige automáticamente los ordenadores de cliente que solicitan un servicio a una réplica del servidor para ese servicio. Un applet de cliente construye y envía una solicitud de enrutamiento de réplica a un enrutador de réplica. El enrutador de réplica calcula una lista de direcciones IP de destino posibles y envía un mensaje de respuesta que incluye la lista y los valores métricos de rendimiento correspondientes a cada elemento de la lista. El applet del cliente envía solicitudes de servicio a un número fijo de réplicas de servidor que tienen las mejores métricas de rendimiento.
Resumen de la invención
De acuerdo con la invención, se proporciona: un método para que un primer nodo establezca una sesión con un segundo nodo, como se describe en la reivindicación 1; un primer nodo según la reivindicación 11; un método para que un segundo nodo establezca una sesión con un primer nodo, como se describe en la reivindicación 12; un segundo nodo como se mencionó en la reivindicación 14.
Un mecanismo seguro para comunicarse a través de Internet, que incluye un protocolo denominado Protocolo de Enrutamiento Agile en Túnel (TARP), utiliza un formato único de cifrado de dos capas y enrutadores TARP especiales. Los enrutadores TARP tienen una función similar a los enrutadores IP normales. Cada enrutador TARP tiene una o más direcciones IP y utiliza el protocolo IP normal para enviar mensajes de paquetes IP (“paquetes” o “datagramas”). Los paquetes IP intercambiados entre terminales TARP a través de enrutadores TARP son en realidad paquetes cifrados cuya verdadera dirección de destino está oculta, excepto a los enrutadores y servidores TARP. El encabezado IP normal o “claro” o “externo” adjunto a los paquetes de TARP IP contiene solo la dirección de un enrutador de próximo salto o servidor de destino. Es decir, en lugar de indicar un destino final en el campo de destino del encabezado IP, el encabezado IP del paquete TARP siempre apunta al siguiente salto en una serie de saltos de enrutador TARP, o al destino final. Esto significa que no hay una indicación explícita de un paquete TARP interceptado del verdadero destino del paquete TARP ya que el destino siempre podría ser el enrutador TARP del siguiente salto, así como el destino final.
El verdadero destino de cada paquete TARP está oculto detrás de una capa de cifrado generada utilizando una clave de enlace. La clave de enlace es la clave de cifrado utilizada para la comunicación cifrada entre los saltos que intervienen entre un terminal TARP de origen y un terminal TARP de destino. Cada enrutador TARP puede eliminar la capa externa de cifrado para revelar el enrutador de destino para cada paquete TARP. Para identificar la clave de enlace necesaria para descifrar la capa externa de cifrado de un paquete TARP, un TARP receptor o un terminal de enrutamiento puede identificar el terminal remitente por los números IP del remitente/receptor en el encabezado IP de texto sin formato.
Una vez que se elimina la capa externa de cifrado, el enrutador TARP determina el destino final. Cada paquete 140 TARP se somete a un número mínimo de saltos para ayudar a frustrar el análisis del tráfico. Los saltos se pueden elegir al azar o por un valor fijo. Como resultado, cada paquete TARP puede realizar viajes aleatorios entre varios enrutadores geográficamente dispares antes de llegar a su destino. Es muy probable que cada viaje sea diferente para cada paquete que compone un mensaje dado porque cada viaje se determina aleatoriamente de forma independiente. Esta característica se llama enrutamiento agile. El hecho de que diferentes paquetes tomen diferentes rutas proporciona distintas ventajas al dificultar que un intruso obtenga todos los paquetes que forman un mensaje completo de múltiples paquetes. Las ventajas asociadas tienen que ver con la capa interna de cifrado que se analiza a continuación. El enrutamiento agile se combina con otra característica que promueve este propósito; Una función que garantiza que cualquier mensaje se divida en varios paquetes.
La dirección IP de un enrutador TARP puede no permanecer constante; una característica llamada IP Agility. Cada enrutador TARP, independientemente o bajo la dirección de otro terminal o enrutador TARP, puede cambiar su dirección IP. También se define un identificador o dirección independiente e inmutable. Esta dirección, llamada dirección TARP, es conocida solo por los enrutadores y terminales TARP y puede estar correlacionada en cualquier momento por un enrutador TARP o un terminal TARP utilizando una tabla de búsqueda (LUT). Cuando un enrutador o terminal TARP cambia su dirección IP, actualiza los otros enrutadores y terminales TARP que a su vez actualizan sus respectivos LUT.
La carga útil del mensaje está oculta detrás de una capa interna de cifrado en el paquete TARP que solo puede desbloquearse utilizando una clave de sesión. La clave de sesión no está disponible para ninguno de los enrutadores TARP que intervienen. La clave de sesión se utiliza para descifrar las cargas útiles de los paquetes TARP que permiten reconstruir el flujo de datos.
La comunicación puede hacerse privada utilizando el enlace y las claves de sesión, que a su vez pueden compartirse y usarse de acuerdo con cualquier método deseado. Por ejemplo, se pueden utilizar claves públicas/privadas o claves simétricas.
Para transmitir un flujo de datos, un terminal de origen TARP construye una serie de paquetes TARP a partir de una serie de paquetes IP generados por un proceso de capa de red (IP). (Tenga en cuenta que los términos “capa de red”, “capa de enlace de datos”, “capa de aplicación”, etc., utilizados en esta especificación corresponden a la terminología de red de Interconexión de Sistemas Abiertos (OSI)). Las cargas útiles de estos paquetes se ensamblan en un bloque y bloque de cadena cifrado utilizando la clave de sesión. Esto supone, por supuesto, que todos los paquetes IP están destinados al mismo terminal TARP. El bloque se intercala y el bloque cifrado intercalado se divide en una serie de cargas útiles, una para cada paquete TARP que se generará. Los encabezados TARP especiales IPt se agregan a cada carga útil utilizando los encabezados IP de los paquetes de flujo de datos. Los encabezados TARP pueden ser idénticos a los encabezados IP normales o personalizados de alguna manera. Deben contener una fórmula o datos para desintercalar los datos en el terminal TARP de destino, un parámetro de tiempo de vida (TTL) para indicar el número de saltos aún por ejecutar, un identificador de tipo de datos que indica si la carga útil contiene, por ejemplo, datos TCP o UDP, la dirección TARP del remitente, la dirección TARP de destino y un indicador de si el paquete contiene datos reales o simulado o una fórmula para filtrar datos simulados si los datos simulados se extienden de alguna manera a través de los datos de carga útil TARP.
Tenga en cuenta que, aunque el cifrado de bloque de cadena se trata aquí con referencia a la clave de sesión, se puede utilizar cualquier método de cifrado. Preferiblemente, como en el cifrado de bloque de cadena, se debe utilizar un método que dificulte el descifrado no autorizado sin un resultado completo del proceso de cifrado. Por lo tanto, al separar el bloque cifrado entre múltiples paquetes y dificultar que un intruso obtenga acceso a todos esos paquetes, el contenido de las comunicaciones proporciona una capa adicional de seguridad.
Se pueden agregar datos simulados o falsos a un flujo para ayudar a frustrar el análisis de tráfico al reducir la carga de red de pico a promedio. Puede ser deseable proporcionar al proceso TARP la capacidad de responder a la hora del día u otros criterios para generar más datos simulados durante períodos de poco tráfico para que las ráfagas de comunicación en un punto de Internet no puedan vincularse a las ráfagas de comunicación en otro punto para revelar los extremos de comunicación.
Los datos ficticios también ayudan a dividir los datos en un mayor número de paquetes de tamaño discreto, lo que permite aumentar el tamaño de la ventana intercalada mientras se mantiene un tamaño razonable para cada paquete. (El tamaño del paquete puede ser un único tamaño estándar o puede seleccionarse de un rango fijo de tamaños). Una razón principal para desear que cada mensaje se divida en múltiples paquetes es evidente si se usa un esquema de cifrado de bloque de cadena para formar la primera capa de cifrado antes de intercalar. Se puede aplicar un cifrado de bloque único a la porción, o la totalidad, de un mensaje, y esa porción o la totalidad se intercalan en varios paquetes separados. Teniendo en cuenta el enrutamiento IP Agile de los paquetes y la dificultad concomitante de reconstruir una secuencia completa de paquetes para formar un único elemento de mensaje cifrado en bloque, los paquetes simulados pueden aumentar significativamente la dificultad de reconstruir un flujo de datos completo.
El esquema anterior puede implementarse completamente mediante procesos que operan entre la capa de enlace de datos y la capa de red de cada servidor o terminal que participa en el sistema TARP. Debido a que el sistema de cifrado descrito anteriormente es insertable entre el enlace de datos y las capas de red, los procesos involucrados en el soporte de la comunicación cifrada pueden ser completamente transparentes para los procesos en la capa de IP (red) y superior. Los procesos TARP también pueden ser completamente transparentes a los procesos de la capa de enlace de datos. Por lo tanto, la inserción de la pila TARP no afecta a las operaciones en la capa de red o por encima de ella, o por debajo de la capa de enlace de datos. Esto proporciona seguridad adicional a todos los procesos en o por encima de la capa de red, ya que la dificultad de penetración no autorizada de la capa de red (por ejemplo, por un hacker) aumenta sustancialmente. Incluso los servidores recientemente desarrollados que se ejecutan en la capa de sesión dejan todos los procesos por debajo de la capa de sesión vulnerables al ataque. Tenga en cuenta que, en esta arquitectura, la seguridad se distribuye. Es decir, los ordenadores portátiles utilizados por los ejecutivos en el camino, por ejemplo, pueden comunicarse a través de Internet sin comprometer la seguridad.
Los cambios de dirección IP realizados por los terminales y enrutadores TARP se pueden hacer a intervalos regulares, a intervalos aleatorios o al detectar “ataques”. La variación de las direcciones IP dificulta el análisis del tráfico que podría revelar qué ordenadores se están comunicando, y también proporciona un grado de inmunidad contra los ataques. El nivel de inmunidad frente al ataque es aproximadamente proporcional a la velocidad a la que cambia la dirección IP del host.
Como se mencionó, las direcciones IP pueden cambiarse en respuesta a los ataques. Un ataque puede ser revelado, por ejemplo, por una serie regular de mensajes que indican que se está probando un enrutador de alguna manera. Al detectar un ataque, el proceso de la capa t A r P puede responder a este evento cambiando su dirección IP. Además, puede crear un subproceso que mantenga la dirección IP original y continúe interactuando con el atacante de alguna manera.
Los paquetes simulados pueden ser generados por cada terminal TARP sobre una base determinada por un algoritmo. Por ejemplo, el algoritmo puede ser aleatorio y requiere la generación de un paquete de manera aleatoria cuando el terminal está inactivo. Alternativamente, el algoritmo puede responder a la hora del día o la detección de tráfico bajo para generar más paquetes simulados durante tiempos de tráfico bajo. Tenga en cuenta que los paquetes se generan preferiblemente en grupos, en lugar de uno por uno, y los grupos se dimensionan para simular mensajes reales. Además, para que los paquetes simulados se puedan insertar en las secuencias de mensajes TARP normales, el bucle de fondo puede tener un bloqueo que hace que sea más probable insertar paquetes simulados cuando se recibe una secuencia de mensajes. Alternativamente, si se recibe una gran cantidad de paquetes simulados junto con los paquetes TARP normales, el algoritmo puede aumentar la tasa de caída de paquetes simulados en lugar de reenviarlos. El resultado de descartar y generar paquetes simulados de esta manera es hacer que el tamaño aparente del mensaje entrante sea diferente del tamaño aparente del mensaje saliente para ayudar a frustrar el análisis del tráfico.
En varias otras realizaciones de la invención, se puede construir una versión escalable del sistema en la que se preasignan una pluralidad de direcciones IP a cada par de nodos comunicantes en la red. Cada par de nodos acuerda un algoritmo para “saltar” entre direcciones IP (tanto de envío como de recepción), de modo que un espía vea pares de direcciones IP aparentemente aleatorios (origen y destino) para los paquetes transmitidos entre el par. Las direcciones IP superpuestas o “reutilizables” pueden asignarse a diferentes usuarios en la misma subred, ya que cada nodo simplemente verifica que un paquete particular incluye un par de origen/destino válido del algoritmo acordado. Los pares de origen/destino preferiblemente no se reutilizan entre dos nodos durante una sesión de extremo a extremo, aunque los tamaños de bloque de IP limitados o las sesiones largas pueden requerirlo.
Breve descripción de los dibujos
La figura 1 es una ilustración de comunicaciones seguras a través de Internet según una realización de la técnica anterior.
La figura 2 es una ilustración de comunicaciones seguras a través de Internet de acuerdo con una realización de la invención.
La figura 3a es una ilustración de un proceso de formación de un paquete IP tunelizado de acuerdo con una realización de la invención.
La figura 3b es una ilustración de un proceso de formación de un paquete IP tunelizado de acuerdo con otra realización de la invención.
La figura 4 es una ilustración de una ubicación de capa OSI de procesos que pueden usarse para implementar la invención.
La figura 5 es un diagrama de flujo que ilustra un proceso para enrutar un paquete tunelizado de acuerdo con una realización de la invención.
La figura 6 es un diagrama de flujo que ilustra un proceso para formar un paquete tunelizado de acuerdo con una realización de la invención.
La figura 7 es un diagrama de flujo que ilustra un proceso para recibir un paquete tunelizado de acuerdo con una realización de la invención.
La figura 8 muestra cómo se establece y sincroniza una sesión segura entre un cliente y un enrutador TARP.
La figura 9 muestra un esquema de salto de dirección IP entre un ordenador cliente y un enrutador TARP utilizando tablas de transmisión y recepción en cada ordenador.
La figura 10 muestra la redundancia del enlace físico entre tres proveedores de servicios de Internet (ISP) y un ordenador de cliente.
La figura 11 muestra cómo se pueden incorporar múltiples paquetes IP en una única “trama”, como una trama de Ethernet, y además muestra el uso de un campo discriminador para camuflar receptores de paquetes verdaderos.
La figura 12A muestra un sistema que emplea direcciones de hardware con salto, direcciones IP con salto y campos discriminadores con salto.
La figura 12B muestra varios enfoques diferentes para saltar direcciones de hardware, direcciones IP y campos discriminadores en combinación.
La figura 13 muestra una técnica para restablecer automáticamente la sincronización entre el remitente y el receptor mediante el uso de un valor de sincronización parcialmente público.
La figura 14 muestra un esquema de “punto de control” para recuperar la sincronización entre un remitente y un receptor.
La figura 15 muestra detalles adicionales del esquema de punto de control de la figura 14.
La figura 16 muestra cómo dos direcciones pueden descomponerse en una pluralidad de segmentos para compararlos con vectores de presencia.
Descripción detallada de las realizaciones
Con referencia a la figura 2, un mecanismo seguro para comunicarse a través de Internet emplea una serie de enrutadores o servidores especiales, llamados enrutadores 122-127 TARP que son similares a los enrutadores 128­ 132 IP normales en el que cada uno tiene una o más direcciones IP y utiliza el protocolo IP normal para envíe mensajes de paquetes IP de aspecto normal, llamados paquetes 140 TARp . Los paquetes 140 TARP son idénticos a los mensajes de paquetes IP normales que son enrutados por los enrutadores IP 128-132 normales porque cada paquete 140 TARP contiene una dirección de destino como en un paquete IP normal. Sin embargo, en lugar de indicar un destino final en el campo de destino del encabezado IP, el encabezado 140 IP del paquete TARP siempre apunta al siguiente salto en una serie de saltos de enrutador TARP, o el destino final, el terminal 110 TARP. Porque el encabezado del paquete TARP contiene solo el destino del próximo salto, no hay una indicación explícita de un paquete TARP interceptado del verdadero destino del paquete 140 TARP ya que el destino siempre podría ser el enrutador TARP del siguiente salto, así como el destino final, terminal 110 TARP.
El verdadero destino de cada paquete TARP está oculto detrás de una capa externa de cifrado generada utilizando una clave 146 de enlace. La clave 146 de enlace es la clave de cifrado utilizada para la comunicación cifrada entre los extremos (terminales TARP o enrutadores TARP) de un solo enlace en la cadena de saltos que conectan el terminal 100 TARP de origen y el terminal 110 TARP de destino. Cada enrutador 122-127 TARP, que utiliza la clave 146 de enlace la utiliza para comunicarse con el salto anterior en una cadena, puede utilizar la clave de enlace para revelar el verdadero destino de un paquete TARP. Para identificar la clave de enlace necesaria para descifrar la capa externa de cifrado de un paquete TARP, un TARP receptor o un terminal de enrutamiento puede identificar el terminal remitente (que puede indicar la clave de enlace utilizada) por el campo remitente del encabezado IP transparente. Alternativamente, esta identidad puede estar oculta detrás de otra capa de cifrado en los bits disponibles en el encabezado IP transparente. Cada enrutador TARP, al recibir un mensaje TARP, determina si el mensaje es un mensaje TARP mediante el uso de datos de autenticación en el paquete TARP. Esto podría registrarse en bytes disponibles en el encabezado IP del paquete TARP. Alternativamente, los paquetes TARP podrían autenticarse intentando descifrar utilizando la clave 146 de enlace y determinando si los resultados son los esperados. El primero puede tener ventajas computacionales porque no implica un proceso de descifrado.
Una vez que la capa externa de descifrado se completa con un enrutador 122-127 TARP, el enrutador TARP determina el destino final. El sistema está diseñado preferiblemente para hacer que cada paquete 140 TARP experimente un número mínimo de saltos para ayudar a frustrar el análisis del tráfico. El contador de tiempo de vida en el encabezado IP del mensaje TARP se puede utilizar para indicar una serie de saltos de enrutador TARP que aún no se han completado. Cada enrutador TARP entonces disminuirá el contador y determinará si debe reenviar el paquete 140 TARP a otro enrutador 122-127 TARP o al terminal 110 TARP de destino. Si el tiempo de vida del contador es cero o inferior a cero después de la disminución, por un ejemplo de uso, el enrutador TARP que recibe el paquete 140 TARP puede reenviar el paquete 140 TARP al terminal 110 TARP de destino. Si el contador de tiempo de vida es superior a cero después de disminuir, para un ejemplo de uso, el enrutador TARP que recibe el paquete 140 TARP puede reenviar el paquete 140 TARP a un enrutador 122-127 TARP que el terminal TARP actual elige al azar. Como resultado, cada paquete 140 TARP se enruta a través de un número mínimo de saltos de enrutadores 122-127 TARP que se eligen al azar.
Por lo tanto, cada paquete TARP, independientemente de los factores tradicionales que determinan el tráfico en Internet, realiza viajes aleatorios entre varios enrutadores geográficamente dispares antes de llegar a su destino y es muy probable que cada viaje sea diferente para cada paquete que compone un mensaje dado porque cada viaje se determina de forma aleatoria independientemente como se describió anteriormente. Esta característica se llama enrutamiento Agile. Por razones que se aclararán en breve, el hecho de que diferentes paquetes tomen diferentes rutas proporciona distintas ventajas al dificultar que un intruso obtenga todos los paquetes que forman un mensaje completo de múltiples paquetes. El enrutamiento Agile se combina con otra función que promueve este propósito, una función que garantiza que cualquier mensaje se divida en múltiples paquetes.
Un enrutador TARP recibe un paquete TARP cuando una dirección IP utilizada por el enrutador TARP coincide con la dirección IP en el encabezado IP del paquete TARP IPc. Sin embargo, la dirección IP de un enrutador TARP puede no permanecer constante. Para evitar y gestionar ataques, cada enrutador TARP, independientemente o bajo la dirección de otro terminal o enrutador TARP, puede cambiar su dirección IP. También se define un identificador o dirección independiente e inmutable. Esta dirección, llamada dirección TARP, es conocida solo por los enrutadores y terminales TARP y puede estar correlacionada en cualquier momento por un enrutador TARP o un terminal TARP utilizando una tabla de búsqueda (LUT). Cuando un enrutador o terminal TARP cambia su dirección IP, actualiza los otros enrutadores y terminales TARP que a su vez actualizan sus respectivos LUT. En realidad, cada vez que un enrutador TARP busca la dirección de un destino en el encabezado cifrado, debe convertir una dirección TARP en una dirección IP real utilizando su LUT.
Si bien cada enrutador TARP que recibe un paquete TARP tiene la capacidad de determinar el destino final del paquete, la carga útil del mensaje está incorporada detrás de una capa interna de cifrado en el paquete TARP que solo puede desbloquearse utilizando una clave de sesión. La clave de sesión no está disponible para ninguno de los enrutadores 122-127 TARP que intervienen entre los terminales TARP de origen 100 y destino 110. La clave de sesión se utiliza para descifrar las cargas útiles de los paquetes 140 TARP permitiendo que se reconstruya un mensaje completo.
En una realización, la comunicación puede hacerse privada utilizando el enlace y las teclas de sesión, que a su vez pueden compartirse y usarse de acuerdo con cualquier método deseado. Por ejemplo, una clave pública o claves simétricas pueden comunicarse entre enlaces o extremos de sesión utilizando un método de clave pública. Cualquiera de una variedad de otros mecanismos para asegurar los datos para garantizar que solo los ordenadores autorizadas puedan tener acceso a la información privada en los paquetes 140 TARP se pueden utilizar como se desee.
En referencia a la figura 3a, para construir una serie de paquetes TARP, un flujo 300 de datos de paquetes IP 207a, 207b, 207c, etc., tales series de paquetes formados por un proceso de capa de red (IP), se dividen en una serie de segmentos de tamaño pequeño. En el presente ejemplo, los segmentos 1-9 de igual tamaño se definen y se utilizan para construir un conjunto de paquetes de datos intercalados A, B y C. Aquí se supone que el número de paquetes intercalados A, B y C formados es tres y que el número de paquetes IP 207a-207c utilizados para formar los tres paquetes intercalados A, B y C es exactamente tres. Por supuesto, el número de paquetes IP distribuidos en un grupo de paquetes intercalados puede ser cualquier número conveniente como puede ser el número de paquetes intercalados sobre los cuales se distribuye el flujo de datos entrantes. El último, el número de paquetes intercalados sobre los cuales se extiende el flujo de datos, se denomina ventana intercalada.
Para crear un paquete, el software de transmisión intercala los paquetes 207a IP normales et. seq. para formar un nuevo conjunto de datos 320 de carga útil intercalados. Estos datos 320 de carga útil se cifran utilizando una clave de sesión para formar un conjunto de datos 330 de carga útil cifrados con clave de sesión, cada uno de los cuales, A, B y C, formarán la carga útil de un paquete de TARP. Usando los datos de encabezado IP, a partir de los paquetes 207a-207c originales, nuevos encabezados TARP IPt . Se forman los encabezados TARP IPt pueden ser idénticos a los encabezados IP normales o personalizados de alguna manera. En una realización preferida, los encabezados TARP IPt son encabezados IP con datos agregados que proporcionan la siguiente información requerida para el enrutamiento y la reconstrucción de mensajes, algunos de cuyos datos están normalmente, o pueden ser, contenidos en encabezados IP normales:
1. Un número de secuencia de ventana: un identificador que indica dónde pertenece el paquete en la secuencia del mensaje original.
2. Un número de secuencia de intercalación: un identificador que indica la secuencia de intercalación utilizada para formar el paquete, de modo que el paquete se pueda desintercalar junto con otros paquetes en la ventana de intercalación.
3. Un dato de tiempo de vida (TTL): indica el número de saltos de enrutador TARP que se ejecutarán antes de que el paquete llegue a su destino. Tenga en cuenta que el parámetro TTL puede proporcionar un dato para ser utilizado en una fórmula probabilística para determinar si enrutar el paquete al destino o a otro salto.
4. Identificador del tipo de datos: indica si la carga útil contiene, por ejemplo, datos TCP o UDP.
5. Dirección del remitente: indica la dirección del remitente en la red TARP.
6. Dirección de destino: indica la dirección del terminal de destino en la red TARP.
7. Simulado/Real - un indicador de si el paquete contiene datos de mensajes reales o datos falsos simulado o una combinación.
Obviamente, los paquetes que entran en una sola ventana de intercalación deben incluir solo paquetes con un destino común. Por lo tanto, se supone en el ejemplo representado que los encabezados IP de los paquetes 207a-207c IP contienen todos la misma dirección de destino o al menos serán recibidos por el mismo terminal para que puedan ser desintercalados. Tenga en cuenta que se pueden agregar paquetes o datos ficticios o simulados para formar una ventana de intercalación más grande de lo que sería requerido por el tamaño de un mensaje dado. Se pueden agregar datos simulados o falsos a una secuencia para ayudar a frustrar el análisis de tráfico al nivelar la carga en la red. Por lo tanto, puede ser deseable proporcionar al proceso TARP la capacidad de responder a la hora del día u otros criterios para generar más datos simulados durante los períodos de poco tráfico para que las ráfagas de comunicación en un punto de Internet no puedan vincularse a las ráfagas de comunicación en otro punto para revelar los extremos de comunicación.
Los datos ficticios también ayudan a dividir los datos en un mayor número de paquetes de tamaño discreto que permite aumentar el tamaño de la ventana intercalada mientras se mantiene un tamaño razonable para cada paquete. (El tamaño del paquete puede ser un único tamaño estándar o puede seleccionarse de un rango fijo de tamaños). Una razón principal para desear que cada mensaje se divida en múltiples paquetes es evidente si se usa un esquema de cifrado de bloque de cadena para formar la primera capa de cifrado antes de intercalar. Se puede aplicar un cifrado de bloque único a la porción, o la totalidad, de un mensaje, y esa porción o la totalidad se intercalan en varios paquetes separados.
En referencia a la figura 3b, en un modo alternativo de construcción de paquetes TARP, se acumula una serie de paquetes IP para formar una ventana de intercalación predefinida. Las cargas útiles de los paquetes se utilizan para construir un único bloque 520 para el cifrado de bloques en cadena utilizando la clave de sesión. Se presume que las cargas útiles utilizadas para formar el bloque están destinadas al mismo terminal. El tamaño del bloque puede coincidir con la ventana de intercalación como se representa en la realización de ejemplo de la figura 3b. Después del cifrado, el bloque cifrado se divide en cargas útiles y segmentos separados que se entrelazan como en la realización de la figura 3a. Los paquetes intercalados resultantes A, B y C se empaquetan luego como paquetes TARP con encabezados TARP como en el Ejemplo de la figura 3a. El proceso restante es como se muestra y se analiza con referencia a la figura 3a.
Una vez que se forman los paquetes 340 TARP, cada paquete 340 TARP completo, incluido el encabezado TARP IPt , se cifra utilizando la clave de enlace para la comunicación con el enrutador TARP de primer salto. El enrutador TARP del primer salto se elige al azar. Se agrega un encabezado IP no cifrado final IPc a cada paquete 340 TARP cifrado para formar un paquete 360 IP normal que se puede transmitir a un enrutador TARP. Tenga en cuenta que el proceso de construcción del paquete 360 TARP no tiene que hacerse en etapas como se describe. La descripción anterior es solo una heurística útil para describir el producto final, es decir, el paquete TARP.
Tenga en cuenta que, el encabezado TARP IPt podría ser una configuración de encabezado completamente personalizada sin similitud con un encabezado IP normal, excepto que contiene la información identificada anteriormente. Esto es así ya que este encabezado es interpretado solo por los enrutadores TARP.
El esquema anterior puede implementarse completamente mediante procesos que operan entre la capa de enlace de datos y la capa de red de cada servidor o terminal que participa en el sistema TARP. Con referencia a la figura 4, un transceptor 405 TARP puede ser un terminal 100 de origen, un terminal 110 de destino o un enrutador 122-127 TARP. En cada Transceptor 405 TARP, se genera un proceso de transmisión para recibir paquetes normales de la capa de Red (IP) y generar paquetes TARP para la comunicación a través de la red. Se genera un proceso de recepción para recibir paquetes IP normales que contienen paquetes TARP y se generan a partir de estos paquetes IP normales que se “pasan” a la capa de red (IP). Tenga en cuenta que cuando el Transceptor 405 TARP es un enrutador, los paquetes 140 TARP recibidos no se procesan en un flujo de paquetes IP 415 porque solo necesitan autenticarse como paquetes TARP adecuados y luego pasar a otro enrutador TARP o un terminal 110 TARP de destino. El proceso intermedio, una “Capa TARP” 420, podría combinarse con la capa 430 de enlace de datos o la capa 410 de red. En cualquier caso, intervendría entre la capa 430 de enlace de datos para que el proceso recibiera paquetes IP regulares que contengan paquetes TARP integrados y “entregar” una serie de paquetes IP reensamblados a la capa 410 de red. Como ejemplo de combinación de la capa 420 de TARP con la capa 430 de enlace de datos, un programa puede aumentar los procesos normales que ejecutan una tarjeta de comunicaciones, por ejemplo , una tarjeta ethernet. Alternativamente, los procesos de la capa TARP pueden formar parte de un módulo cargable dinámicamente que se carga y ejecuta para soportar las comunicaciones entre la red y las capas de enlace de datos.
Como el sistema de cifrado descrito anteriormente puede insertarse entre el enlace de datos y las capas de red, los procesos involucrados en el soporte de la comunicación cifrada pueden ser completamente transparentes para los procesos en la capa de IP (red) y superior. Los procesos TARP también pueden ser completamente transparentes a los procesos de la capa de enlace de datos. Por lo tanto, ninguna operación en o sobre la capa de red, o en o debajo de la capa de enlace de datos, se ve afectada por la inserción de la pila TARP. Esto proporciona seguridad adicional a todos los procesos en o por encima de la capa de red, ya que la dificultad de penetración no autorizada de la capa de red (por ejemplo, por un hacker) aumenta sustancialmente. Incluso los servidores recientemente desarrollados que se ejecutan en la capa de sesión dejan todos los procesos por debajo de la capa de sesión vulnerables al ataque.
Tenga en cuenta que, en esta arquitectura, la seguridad se distribuye. Es decir, los ordenadores portátiles utilizadas por los ejecutivos en el camino, por ejemplo, pueden comunicarse a través de Internet sin comprometer la seguridad.
Tenga en cuenta que los cambios de dirección IP realizados por los terminales y enrutadores TARP se pueden realizar a intervalos regulares, a intervalos aleatorios o al detectar “ataques”. La variación de las direcciones IP dificulta el análisis de tráfico que podría revelar qué ordenadores se están comunicando, y también proporciona un grado de inmunidad contra ataques. El nivel de inmunidad contra ataques es aproximadamente proporcional a la velocidad a la que cambia la dirección IP del host.
Como se mencionó, las direcciones IP pueden cambiarse en respuesta a los ataques. Un ataque puede ser revelado, por ejemplo, por una serie regular de mensajes indica que se está probando un enrutador de alguna manera. Al detectar un ataque, el proceso de la capa TARP puede responder a este evento cambiando su dirección IP. Para lograr esto, el proceso TARP construirá un mensaje con formato TARP, al estilo de los datagramas del Protocolo de Mensajes de Control de Internet (ICMP) como ejemplo; Este mensaje contendrá la dirección TARP de la máquina, su dirección IP anterior y su nueva dirección IP. La capa TARP transmitirá este paquete a al menos un enrutador TARP conocido; luego, al recibir y validar el mensaje, el enrutador TARP actualizará su LUT con la nueva dirección IP para la dirección TARP indicada. El enrutador TARp formateará un mensaje similar y lo transmitirá a los otros enrutadores TARP para que puedan actualizar sus LUT. Dado que se espera que el número total de enrutadores TARP en cualquier subred sea relativamente pequeño, este proceso de actualización de las LUT debe ser relativamente rápido. Sin embargo, puede que no funcione tan bien cuando hay un número relativamente grande de enrutadores TARp y/o un número relativamente grande de clientes; Esto ha motivado un refinamiento de esta arquitectura para proporcionar escalabilidad; Este refinamiento ha llevado a una segunda realización, que se discute a continuación.
Al detectar un ataque, el proceso TARP también puede crear un subproceso que mantiene la dirección IP original y continúa interactuando con el atacante. Este último puede proporcionar una oportunidad para rastrear al atacante o estudiar los métodos del atacante (llamado “pecera”, basándose en la analogía de un pez pequeño en una pecera que “piensa” que está en el océano pero que en realidad está bajo observación cautiva). Una historia de la comunicación entre el atacante y la dirección IP abandonada (pecera) puede ser grabada o transmitida para análisis humano o sintetizada para responder de alguna manera.
Como se mencionó anteriormente, se pueden agregar datos o paquetes falsos o simulados a los flujos de datos salientes por los terminales o enrutadores TARP. Además de facilitar la distribución de datos en un número mayor de paquetes separados, estos paquetes simulados también pueden ayudar a nivelar la carga en partes inactivas de Internet para frustrar los esfuerzos de análisis de tráfico.
Los paquetes simulados pueden ser generados por cada terminal 100, 110 TARP o por cada enrutador 122-127, de alguna manera determinada por un algoritmo. Por ejemplo, el algoritmo puede ser aleatorio y requiere la generación de un paquete de manera aleatoria cuando el terminal está inactivo. Alternativamente, el algoritmo puede responder a la hora del día o la detección de tráfico bajo para generar más paquetes simulados durante tiempos de tráfico bajo. Tenga en cuenta que los paquetes se generan preferiblemente en grupos, en lugar de uno por uno, y los grupos se dimensionan para simular mensajes reales. Además, para que los paquetes simulados se puedan insertar en los flujos de mensajes TARP normales, el bucle de fondo puede tener un bloqueo que hace que sea más probable insertar paquetes simulados cuando se recibe una secuencia de mensajes. Es decir, cuando se reciben una serie de mensajes, se puede aumentar la tasa de generación de paquetes simulado. Alternativamente, si se recibe una gran cantidad de paquetes simulados junto con los paquetes TARP normales, el algoritmo puede aumentar la tasa de caída de paquetes simulados en lugar de reenviarlos. El resultado de descartar y generar paquetes simulados de esta manera es hacer que el tamaño aparente del mensaje entrante sea diferente del tamaño aparente del mensaje saliente para ayudar a frustrar el análisis del tráfico. La velocidad de recepción de paquetes, simulado o de otro modo, puede indicarse a los procesos de caída y generación de paquetes simulados a través de contadores de paquetes simulados perecederos y regulares. (Un contador perecedero es aquel que restablece o disminuye su valor en respuesta al tiempo, de modo que contiene un valor alto cuando se incrementa en sucesión rápida y un valor pequeño cuando se incrementa lentamente o un pequeño número de veces en sucesión rápida). Tenga en cuenta que ese terminal 110 TARP de destino puede generar paquetes simulados iguales en número y tamaño a los paquetes TARP recibidos para hacer que parezca que se trata simplemente de paquetes de enrutamiento y, por lo tanto, no es el terminal de destino.
En referencia a la figura 5, los siguientes pasos particulares pueden emplearse en el método descrito anteriormente para enrutar paquetes TARP.
• S0. Se realiza una operación de bucle de fondo que aplica un algoritmo que determina la generación de paquetes IP simulado. El bucle se interrumpe cuando se recibe un paquete TARP cifrado.
• S2. El paquete TARP puede probarse de alguna manera para autenticar el paquete antes de intentar descifrarlo utilizando la clave de enlace. Es decir, el enrutador puede determinar que el paquete es un paquete TARP auténtico al realizar una operación seleccionad a en algunos datos incluidos con el encabezado IP no cifrado adjunto al paquete TARP cifrado contenido en la carga útil. Esto permite evitar descifrar los paquetes que no son auténticos paquetes TARP.
• S3. El paquete TARP se descifra para exponer la dirección TARP de destino y una indicación de si el paquete es un paquete simulado o parte de un mensaje real.
• S4. Si el paquete es un paquete simulado, el contador simulado perecedero se incrementa.
• S5. Según el algoritmo de generación/caída simulado y el valor del contador simulado perecedero, si el paquete es un paquete simulado, el enrutador puede optar por tirarlo. Si el paquete recibido es un paquete simulado y se determina que debe desecharse (S6), el control vuelve al paso S0.
• S7. El parámetro TTL del encabezado TARP se reduce y se determina si el parámetro TTL es mayor que cero. • S8. Si el parámetro TTL es mayor que cero, se elige aleatoriamente una dirección TARP de una lista de direcciones TARP mantenidas por el enrutador y la clave de enlace y la dirección IP correspondiente a esa dirección TARP memorizada para crear un nuevo paquete IP que contenga el paquete TARP .
• S9. Si el parámetro TTL es cero o menos, la clave de enlace y la dirección IP correspondiente a la dirección TARP del destino se memorizan para su uso en la creación del nuevo paquete IP que contiene el paquete TARP.
• S10. El paquete TARP se cifra utilizando la clave de enlace memorizada.
• S11. Se agrega un encabezado IP al paquete que contiene la dirección IP almacenada, el paquete TARP cifrado envuelto con un encabezado IP y el paquete completado se transmite al siguiente salto o destino.
Con referencia a la figura 6, los siguientes pasos particulares pueden emplearse en el método descrito anteriormente para generar paquetes TARP.
• S20. Una operación de bucle de fondo aplica un algoritmo que determina la generación de paquetes IP simulado. El bucle se interrumpe cuando se recibe una transmisión de datos que contiene paquetes IP para su transmisión. • S21. Los paquetes IP recibidos se agrupan en un conjunto que consiste en mensajes con una dirección IP de destino constante. El conjunto se desglosa para coincidir con el tamaño máximo de una ventana de intercalación. El conjunto se cifra y se intercala en un conjunto de cargas útiles destinadas a convertirse en paquetes TARP.
• S22. La dirección TARP correspondiente a la dirección IP se determina a partir de una tabla de búsqueda y se almacena para generar el encabezado TARP. Se genera un recuento TTL inicial y se almacena en el encabezado. El recuento TTL puede ser aleatorio con valores mínimos y máximos o puede ser fijo o determinado por algún otro parámetro.
• S23. Los números de secuencia de ventana y los números de secuencia de intercalación se registran en los encabezados TARP de cada paquete.
• S24. Se elige aleatoriamente una dirección de enrutador TARP para cada paquete TARP y la dirección IP correspondiente se almacena para su uso en el encabezado IP transparente. La clave de enlace correspondiente a este enrutador se identifica y se utiliza para cifrar paquetes TARP que contienen encabezados TARP y datos cifrados e intercalados.
• S25. Se genera un encabezado IP no cifrado con la dirección IP real del enrutador del primer salto y se agrega a cada uno de los paquetes TARP cifrados y los paquetes resultantes.
En referencia a la figura 7, los siguientes pasos particulares pueden emplearse en el método descrito anteriormente para recibir paquetes TARP.
• S40. Se realiza una operación de bucle de fondo que aplica un algoritmo que determina la generación de paquetes IP simulado. El bucle se interrumpe cuando se recibe un paquete TARP cifrado.
• S42. El paquete TARP puede probarse para autenticar el paquete antes de intentar descifrarlo utilizando la clave de enlace.
• S43. El paquete TARP se descifra con la clave de enlace apropiada para exponer la dirección TARP de destino y una indicación de si el paquete es un paquete simulado o parte de un mensaje real.
• S44. Si el paquete es un paquete simulado, el contador simulado perecedero se incrementa.
• S45. Según el algoritmo de generación/caída simulado y el valor del contador simulado perecedero, si el paquete es un paquete simulado, el receptor puede optar por tirarlo.
• S46. Los paquetes TARP se almacenan en caché hasta que se reciben todos los paquetes que forman una ventana intercalada.
• S47. Una vez que se reciben todos los paquetes de una ventana de intercalación, los paquetes se desintercalan.
• S48. El bloque de paquetes combinados que define la ventana de intercalación se descifra utilizando la clave de sesión.
• S49. El bloque descifrado se divide utilizando los datos de secuencia de la ventana y los IPt encabezados se convierten en encabezados IPc normales. Los números de secuencia de la ventana están integrados en los encabezados IPC.
• S50. Los paquetes se entregan a los procesos de la capa IP.
Mejoras de escalabilidad
La característica de agilidad IP descrita anteriormente se basa en la capacidad de transmitir cambios de dirección IP a todos los enrutadores TARP. Las realizaciones que incluyen esta característica se denominarán realizaciones “boutique” debido a limitaciones potenciales en la ampliación de estas características para una red grande, como Internet. (Sin embargo, las realizaciones “boutique” serían robustas para su uso en redes más pequeñas, como pequeñas redes privadas virtuales, por ejemplo). Un problema con las realizaciones de boutique es que, si los cambios de dirección IP se producen con frecuencia, el tráfico de mensajes requerido para actualizar todos los enrutadores lo suficientemente rápido crea una carga seria en Internet cuando el enrutador TARP y/o la población de clientes aumenta. La carga de ancho de banda agregada a las redes, por ejemplo, en paquetes ICMP, que se utilizaría para actualizar todos los enrutadores TARP podría abrumar a Internet para una implementación a gran escala que se acercara a la escala de Internet. En otras palabras, la escalabilidad del sistema boutique es limitada.
Se puede construir un sistema que intercambie algunas de las características de las realizaciones anteriores para proporcionar los beneficios de la agilidad de IP sin la carga adicional de mensajes. Esto se logra mediante el salto de direcciones IP de acuerdo con algoritmos compartidos que gobiernan las direcciones IP utilizadas entre enlaces que participan en sesiones de comunicaciones entre nodos, como los nodos TARP. (Tenga en cuenta que la técnica de salto de IP también es aplicable a la realización de boutique.) La característica de agilidad de IP discutida con respecto al sistema de boutique se puede modificar para que se descentralice bajo este régimen escalable y se rija por el algoritmo compartido descrito anteriormente. Otras características del sistema boutique se pueden combinar con este nuevo tipo de agilidad IP.
La nueva realización tiene la ventaja de proporcionar agilidad IP gobernada por un algoritmo local y un conjunto de direcciones IP intercambiadas por cada par de nodos comunicantes. Esta gobernanza local es independiente de la sesión, ya que puede gobernar las comunicaciones entre un par de nodos, independientemente de la sesión o los puntos de extremo que se transfieren entre el par de nodos que se comunican directamente.
En las realizaciones escalables, se asignan bloques de direcciones IP a cada nodo en la red. (Esta escalabilidad aumentará en el futuro, cuando las direcciones del Protocolo de Internet se aumenten a campos de 128 bits, aumentando enormemente el número de nodos claramente direccionables). Por lo tanto, cada nodo puede utilizar cualquiera de las direcciones IP asignadas a ese nodo para comunicarse con otros nodos en la red. De hecho, cada par de nodos de comunicación puede utilizar una pluralidad de direcciones IP de origen y direcciones IP de destino para comunicarse entre sí.
Cada par de nodos comunicantes en una cadena que participa en cualquier sesión almacena dos bloques de direcciones IP, llamados “netblocks”, y un algoritmo y semilla de aleatorización para seleccionar, de cada bloque de red, el siguiente par de direcciones IP de origen/destino que será utilizado para transmitir el siguiente mensaje. En otras palabras, el algoritmo gobierna la selección secuencial de pares de direcciones IP, una dirección IP del remitente y un receptor, de cada netblock. La combinación de algoritmo, semilla y netblock (bloque de dirección IP) se denominará “bloque de salto”. Un enrutador emite bloques de transmisión y recepción por separado para sus clientes. La dirección de envío y la dirección de recepción del encabezado IP de cada paquete saliente enviado por el cliente se completan con las direcciones IP de envío y recepción generadas por el algoritmo. El algoritmo es “sincronizado” (indexado) por un contador para que cada vez que se use un par, el algoritmo genere un nuevo par de transmisión para el siguiente paquete que se enviará.
El bloque de salto de recepción del enrutador es idéntico al bloque de salto de transmisión del cliente. El enrutador utiliza el bloque de salto de recepción para predecir cuál será el par de direcciones IP de envío y recepción para el próximo paquete esperado de ese cliente. Dado que los paquetes pueden recibirse fuera de orden, el enrutador no puede predecir con certeza qué par de direcciones IP estará en el siguiente paquete secuencial. Para tener en cuenta este problema, el enrutador genera un rango de predicciones que abarcan el número de posibles direcciones de envío/recepción de paquetes transmitidos, de los cuales el siguiente paquete recibido podría avanzar. Por lo tanto, si existe una probabilidad muy pequeña de que un paquete determinado llegue al enrutador antes de los 5 paquetes transmitidos por el cliente antes del paquete dado, entonces el enrutador puede generar una serie de 6 pares de direcciones IP de envío/recepción (o “salto” ventana “) para comparar con el siguiente paquete recibido. Cuando se recibe un paquete, se marca en la ventana de salto como tal, de modo que se descarte un segundo paquete con el mismo par de direcciones IP. Si un paquete fuera de secuencia no llega dentro de un período de tiempo de espera predeterminado, se puede solicitar su retransmisión o simplemente descartarlo de la tabla de recepción, dependiendo del protocolo en uso para esa sesión de comunicaciones, o posiblemente por convención.
Cuando el enrutador recibe el paquete del cliente, compara las direcciones IP de envío y recepción del paquete con los próximos N pares de direcciones IP de envío y recepción previstos y rechaza el paquete si no es miembro de este conjunto. Los paquetes recibidos que no tienen las direcciones IP de origen/destino pronosticadas que caen en la ventana son rechazados, frustrando así a posibles hackers. (Con el número de combinaciones posibles, incluso una ventana bastante grande sería difícil de encontrar al azar). Si es miembro de este conjunto, el enrutador acepta el paquete y lo procesa aún más. Esta estrategia de salto de IP basada en enlaces, denominada “ IHOP”, es un elemento de red independiente y no necesariamente va acompañado de elementos del sistema de boutique descrito anteriormente. Si la característica de agilidad de enrutamiento descrita en relación con la realización boutique se combina con esta estrategia de salto de IP basada en enlaces, el siguiente paso del enrutador sería descifrar el encabezado TARP para determinar el enrutador TARP de destino para el paquete y determinar cuál debería ser el próximo salto para el paquete. El enrutador TARP reenviaría el paquete a un enrutador TARP aleatorio o al enrutador TARP de destino con el cual el enrutador TARP de origen tiene establecida una comunicación de salto de IP basada en enlaces.
La figura 8 muestra cómo un ordenador de cliente 801 y un enrutador 811 TARP pueden establecer una sesión segura. Cuando el cliente 801 busca establecer una sesión IHOP con el enrutador 811 TARP, el cliente 801 envía el paquete 821 de solicitud de “sincronización segura” (“SSYN”) al enrutador 811 TARP. Este paquete 821 SYN contiene la credencial de autenticación 801 del cliente, y puede ser enviado al enrutador 811 en un formato cifrado. Los números IP de origen y destino en el paquete 821 son la dirección IP fija actual 801 del cliente y una dirección IP fija “conocida” para el enrutador 811. (Por razones de seguridad, puede ser deseable rechazar cualquier paquete desde fuera del local red destinada a la dirección IP fija conocida del enrutador). Al recibir y validar el paquete 821 SSYN 801 del cliente, el enrutador 811 responde enviando una “confirmación de sincronización segura” (“SSYN ACK”) 822 cifrado al cliente 801. Este SSYN ACK 822 contendrá los bloques de salto de transmisión y recepción que utilizará el cliente 801 cuando se comunique con el enrutador 811 TARP. El cliente 801 reconocerá el paquete de respuesta 811 del enrutador TARP 822 generando un paquete 823 SSYN ACK ACK cifrado que se enviará desde la dirección IP fija 801 del cliente y hasta la dirección IP fija conocida del enrutador 811 TARP. El cliente 801 generará simultáneamente un paquete SSYN ACK ACK; este paquete SSYN ACK, denominado paquete 824 de iniciación de sesión segura (SSI), se enviará con el primer par IP {remitente, receptor} en la tabla 921 de transmisión del cliente (FIG. 9), como se especifica en el bloque de salto de transmisión proporcionado por el enrutador 811 TARP en el paquete SSYN ACK 822. El enrutador 811 TARP responderá al paquete SSI 824 con un paquete SSI ACK 825, que se enviará con el primer par IP {remitente, receptor} en la tabla 923 de transmisión del enrutador TARP. Una vez que estos paquetes se han intercambiado con éxito, se establece la sesión de comunicaciones seguras, y todas las comunicaciones seguras adicionales entre el cliente 801 y el enrutador 811 TARP se llevarán a cabo a través de esta sesión segura, siempre que se mantenga la sincronización. Si se pierde la sincronización, entonces el cliente 801 y el enrutador 802 TARP pueden restablecer la sesión segura mediante el procedimiento descrito en la Figura 8 y descrito anteriormente.
Mientras la sesión segura está activa, tanto el cliente 901 como el enrutador 911 TARP (figura 9) mantendrán sus respectivas tablas 921, 923 de transmisión y recibirán las tablas 922, 924, según lo dispuesto por el enrutador TARP durante la sincronización 822 de sesión. Es importante que la secuencia de pares de IP en la tabla 921 de transmisión del cliente sea idéntica a la de la tabla 924 de recepción del enrutador TARP; de manera similar, la secuencia de pares de IP en la tabla 922 de recepción del cliente debe ser idéntica a la de la tabla 923 de transmisión del enrutador. Esto es necesario para mantener la sincronización de la sesión. El cliente 901 necesita mantener solo una tabla 921 de transmisión y una tabla 922 de recepción durante el curso de la sesión segura. Cada paquete secuencial enviado por el cliente 901 empleará el siguiente par de direcciones IP {enviar, recibir} en la tabla de transmisión, independientemente de la sesión TCP o UDP. El enrutador 911 TARP esperará que cada paquete que llegue desde el cliente 901 lleve el siguiente par de direcciones IP que se muestra en su tabla de recepción.
Como los paquetes pueden llegar fuera de orden, sin embargo, el enrutador 911 puede mantener un búfer “de anticipación” en su tabla de recepción, y marcará los pares de IP recibidos previamente como inválidos para futuros paquetes; cualquier paquete futuro que contenga un par de IP que esté en el búfer de anticipación, pero esté marcado como recibido previamente será descartado. Las comunicaciones del enrutador 911 TARP al cliente 901 se mantienen de manera idéntica; en particular, el enrutador 911 seleccionará el siguiente par de direcciones IP de su tabla 923 de transmisión cuando construya un paquete para enviar al cliente 901, y el cliente 901 mantendrá un búfer de anticipación de los pares de IP esperados en los paquetes que está recibiendo. Cada enrutador TARP mantendrá pares separados de tablas de transmisión y recepción para cada cliente que esté actualmente en una sesión segura con o a través de ese enrutador TARP.
Mientras que los clientes reciben sus bloques de salto del primer servidor que los conecta a Internet, los enrutadores intercambian bloques de salto. Cuando un enrutador establece un régimen de comunicación de salto de IP basado en enlaces con otro enrutador, cada enrutador del par intercambia su bloque de salto de transmisión. El bloque de salto de transmisión de cada enrutador se convierte en el bloque de salto de recepción del otro enrutador. La comunicación entre enrutadores se rige como se describe en el ejemplo de un cliente que envía un paquete al primer enrutador.
Aunque la estrategia anterior funciona bien en el entorno de IP, muchas redes locales que están conectadas a Internet son sistemas ethernet. En ethernet, las direcciones IP de los dispositivos de destino deben traducirse a direcciones de hardware y viceversa, utilizando procesos conocidos (“protocolo de resolución de direcciones” y “protocolo de resolución de direcciones inversas”). Sin embargo, si se emplea la estrategia de salto de IP basada en enlaces, el proceso de correlación se volvería explosivo y oneroso. Se puede emplear una alternativa a la estrategia de salto de IP basada en enlaces dentro de una red ethernet. La solución es proporcionar que el nodo que conecta Internet a Ethernet (llámelo el nodo de borde) use el régimen de comunicación de salto de IP basado en enlaces para comunicarse con nodos fuera de la LAN de Ethernet. Dentro de la LAN Ethernet, cada nodo TARP tendría una única dirección IP que se abordaría de la manera convencional. En lugar de comparar los pares de direcciones IP {remitente, receptor} para autenticar un paquete, el nodo TARP intra-LAN usaría uno de los campos de extensión de encabezado IP para hacerlo. Por lo tanto, el nodo de borde utiliza un algoritmo compartido por el nodo TARP intra-LAN para generar un símbolo que se almacena en el campo libre en el encabezado IP, y el nodo TARP intra-LAN genera un rango de símbolos basado en su predicción de siguiente paquete esperado que se recibirá de esa dirección IP de origen particular. El paquete se rechaza si no cae dentro del conjunto de símbolos predichos (por ejemplo, valores numéricos) o se acepta si lo hace. Las comunicaciones desde el nodo TARP intra-LAN al nodo límite se realizan de la misma manera, aunque el algoritmo será necesariamente diferente por razones de seguridad. Por lo tanto, cada uno de los nodos comunicantes generará tablas de transmisión y recepción de manera similar a la de la Figura 9; la tabla de transmisión de los nodos TARP intra-LAN será idéntica a la tabla de recepción del nodo TARP, y la tabla de recepción del nodo TARP intra-LAN será idéntica a la tabla de transmisión del nodo fronterizo.
El algoritmo utilizado para el salto de dirección IP puede ser cualquier algoritmo deseado. Por ejemplo, el algoritmo puede ser un generador de números pseudoaleatorio dado que genera números del rango que cubre las direcciones IP permitidas con una semilla dada. Alternativamente, los participantes de la sesión pueden asumir un cierto tipo de algoritmo y especificar simplemente un parámetro para aplicar el algoritmo. Por ejemplo, el algoritmo supuesto podría ser un generador de números pseudoaleatorio particular y los participantes de la sesión podrían simplemente intercambiar valores semilla.
Tenga en cuenta que no existe una distinción física permanente entre los nodos terminales de origen y destino. Cualquiera de los dispositivos en cualquier punto final puede iniciar una sincronización del par. Tenga en cuenta también que la solicitud de autenticación/sincronización (y confirmación) y el intercambio de bloques de salto pueden ser atendidos por un solo mensaje, por lo que puede que no sea necesario intercambiar mensajes separados.
Como otra extensión de la arquitectura establecida, un cliente puede utilizar múltiples rutas físicas para proporcionar redundancia de enlace y frustrar aún más los intentos de denegación de servicio y monitoreo de tráfico. Como se muestra en la Figura 10, por ejemplo, el cliente 1001 puede establecer tres sesiones simultáneas con cada uno de los tres enrutadores TARP proporcionados por diferentes ISP 1011, 1012, 1013. Como ejemplo, el cliente 1001 puede utilizar tres líneas 1021, 1022, 1023 telefónicas diferentes para conectarse a los ISP, o dos líneas telefónicas y un módem de cable, etc. En este esquema, los paquetes transmitidos se enviarán de manera aleatoria entre las diferentes rutas físicas. Esta arquitectura proporciona un alto grado de redundancia de comunicaciones, con inmunidad mejorada contra ataques de denegación de servicio y monitoreo de tráfico.
Extensiones adicionales
A continuación, se describen diversas extensiones de las técnicas, sistemas y métodos descritos anteriormente. Como se describió anteriormente, la seguridad de las comunicaciones que se producen entre ordenadores en una red informática (como Internet, Ethernet u otras) se puede mejorar utilizando direcciones de Protocolo de Internet (IP) de origen y destino aparentemente aleatorias para los paquetes de datos transmitidos a través de la red. Esta característica evita que los espías determinen qué ordenadores de la red se comunican entre sí, al tiempo que permite que los dos ordenadores que se comunican reconozcan fácilmente si un paquete de datos recibido es legítimo o no. En una realización de los sistemas descritos anteriormente, se usa un campo de extensión de encabezado IP para autenticar los paquetes entrantes en una Ethernet.
Varias extensiones de las técnicas descritas anteriormente divulgadas en el presente documento incluyen: (1) uso de hardware saltado o direcciones “MAC” en una red de tipo difusión; (2) una técnica de auto-sincronización que permite que una computadora recupere automáticamente la sincronización con un remitente; (3) algoritmos de sincronización que permiten transmitir y recibir ordenadores para restablecer rápidamente la sincronización en caso de pérdida de paquetes u otros eventos; y (4) un mecanismo de rechazo rápido de paquetes para rechazar paquetes no válidos. Cualquiera o todas estas extensiones se pueden combinar con las características descritas anteriormente de varias maneras.
A. Salto de dirección de hardware
Las técnicas de comunicación basadas en el protocolo de Internet en una LAN, o en cualquier medio físico dedicado, típicamente incorporan los paquetes IP en paquetes de nivel inferior, a menudo denominados “tramas”. Como se muestra en la figura 11, por ejemplo, una primera trama 1150 Ethernet comprende un encabezado 1101 de trama y dos paquetes IP integrados iP1 e IP2, mientras que una segunda trama 1160 Ethernet comprende un encabezado 1104 de trama diferente y un único paquete IP IP3. Cada encabezado de trama generalmente incluye una dirección 1101A de hardware de origen y una dirección 1101B de hardware de destino; otros campos bien conocidos en encabezados de trama se omiten de la figura 11 para mayor claridad. Dos nodos de hardware que se comunican a través de un canal de comunicación física insertan las direcciones de hardware de origen y destino apropiadas para indicar qué nodos en el canal o red deberían recibir la trama.
Puede ser posible que un oyente nefasto adquiera información sobre el contenido de una trama y/o sus comunicantes al examinar las tramas en una red local en lugar de (o además de) los paquetes IP en sí. Esto es especialmente cierto en los medios de difusión, como Ethernet, donde es necesario insertar en el encabezado del marco la dirección de hardware de la máquina que generó el marco y la dirección de hardware de la máquina a la que se envía el marco. Todos los nodos en la red pueden potencialmente “ver” todos los paquetes transmitidos a través de la red. Esto puede ser un problema para las comunicaciones seguras, especialmente en los casos en que los comunicantes no desean que ningún tercero pueda identificar quién participa en el intercambio de información. Una forma de abordar este problema es llevar el esquema de salto de dirección a la capa de hardware. De acuerdo con diversas realizaciones de la invención, las direcciones de hardware se “saltan” de una manera similar a la utilizada para cambiar las direcciones IP, de modo que un oyente no puede determinar qué nodo de hardware generó un mensaje particular ni qué nodo es el receptor previsto.
La figura 12A muestra un sistema en el que las direcciones de hardware de Control de acceso al medio (“MAC”) se “saltan” para aumentar la seguridad en una red como una Ethernet. Si bien la descripción se refiere al caso ejemplar de un entorno Ethernet, los principios inventivos son igualmente aplicables a otros tipos de medios de comunicación. En el caso de Ethernet, la dirección MAC del remitente y el receptor se insertan en la trama de Ethernet y pueden ser observados por cualquier persona en la LAN que esté dentro del rango de transmisión para esa trama. Para comunicaciones seguras, es deseable generar tramas con direcciones MAC que no sean atribuibles a ningún remitente o receptor específico.
Como se muestra en la figura 12A, dos nodos 1201 y 1202 de ordenador se comunican a través de un canal de comunicación como un Ethernet. Cada nodo ejecuta uno o más programas 1203 y 1218 de aplicación que se comunican transmitiendo paquetes a través del software 1204 y 1217 de comunicación, respectivamente. Ejemplos de programas de aplicación incluyen videoconferencia, correo electrónico, programas de procesamiento de texto, telefonía y similares. El software 1204 y 1217 de comunicación puede comprender, por ejemplo, una arquitectura en capas OSI o “pila” que estandariza varios servicios proporcionados en diferentes niveles de funcionalidad.
Los niveles más bajos de software 1204 y 1217 de comunicación se comunican con los componentes 1206 y 1214 de hardware respectivamente, cada uno de los cuales puede incluir uno o más registros 1207 y 1215 que permiten que el hardware se reconfigure o controle de acuerdo con varios protocolos de comunicación. Los componentes de hardware (una tarjeta de interfaz de red Ethernet, por ejemplo) se comunican entre sí a través del medio de comunicación. Cada componente de hardware suele tener previamente asignada una dirección de hardware fija o un número MAC que identifica el componente de hardware a otros nodos en la red. Uno o más controladores de interfaz controlan el funcionamiento de cada tarjeta y, por ejemplo, se pueden configurar para aceptar o rechazar paquetes de ciertas direcciones de hardware. Como se describirá con más detalle a continuación, varias realizaciones de los principios inventivos proporcionan “saltar” diferentes direcciones utilizando uno o más algoritmos y una o más ventanas móviles que rastrean un rango de direcciones válidas para validar los paquetes recibidos. Los paquetes transmitidos de acuerdo con uno o más de los principios inventivos generalmente se denominarán paquetes “seguros” o “comunicaciones seguras” para diferenciarlos de los paquetes de datos ordinarios que se transmiten no cifrados utilizando direcciones ordinarias relacionadas con la máquina.
Un método sencillo de generar direcciones MAC no atribuibles es una extensión del esquema de salto de IP. En este escenario, dos máquinas en la misma LAN que desean comunicarse de manera segura intercambian generadores y semillas de números aleatorios, y crean secuencias de direcciones MAC cuasialeatorias para el salto sincronizado. Los problemas de implementación y sincronización son similares a los del salto de IP.
Este enfoque, sin embargo, corre el riesgo de utilizar direcciones MAC que están actualmente activas en la LAN, lo que, a su vez, podría interrumpir las comunicaciones para esas máquinas. Dado que una dirección MAC Ethernet tiene actualmente 48 bits de longitud, la posibilidad de mal uso aleatorio de una dirección MAC activa es en realidad bastante pequeña. Sin embargo, si esa cifra se multiplica por una gran cantidad de nodos (como se encontraría en una LAN extensa), por una gran cantidad de cuadros (como podría ser el caso con paquetes de voz o transmisión de video), y por una gran cantidad de Redes Privadas Virtuales (VPN) concurrentes, entonces la posibilidad de que la dirección MAC de una máquina no segura pueda usarse en un marco de salto de dirección puede volverse no trivial. En resumen, cualquier esquema que corra incluso un pequeño riesgo de interrumpir las comunicaciones para otras máquinas en la LAN seguramente recibirá resistencia de los posibles administradores del sistema. Sin embargo, es técnicamente factible y puede implementarse sin riesgo en una LAN en la que hay un pequeño número de máquinas, o si todas las máquinas en la LAN están involucradas en comunicaciones con salto de m Ac .
El salto de la dirección MAC sincronizada puede generar una sobrecarga en el curso del establecimiento de la sesión, especialmente si hay múltiples sesiones o múltiples nodos involucrados en las comunicaciones. Un método más simple de aleatorizar direcciones MAC es permitir que cada nodo reciba y procese cada trama incidente en la red. Por lo general, cada controlador de interfaz de red verificará la dirección MAC de destino en el encabezado de cada trama incidente para ver si coincide con la dirección MAC de esa máquina; Si no hay coincidencia, la trama se descarta. Sin embargo, en una realización, estas comprobaciones pueden deshabilitarse, y cada paquete incidente se pasa a la pila TARP para su procesamiento. Esto se denominará modo “promiscuo”, ya que se procesa cada trama incidente. El modo promiscuo permite al remitente utilizar direcciones m Ac completamente aleatorias y no sincronizadas, ya que la máquina de destino está garantizada para procesar la trama. La decisión sobre si el paquete realmente estaba destinado a esa máquina es manejado por la pila TARP, que verifica las direcciones IP de origen y destino para encontrar una coincidencia en sus tablas de sincronización IP. Si no se encuentra ninguna coincidencia, el paquete se descarta; si hay una coincidencia, el paquete se desenvuelve, se evalúa el encabezado interno y si el encabezado interno indica que el paquete está destinado a esa máquina, el paquete se reenvía a la pila IP; de lo contrario, se descarta.
Una desventaja del salto de direcciones MAC puramente aleatorio es su impacto en la sobrecarga de procesamiento; es decir, dado que cada trama incidente debe procesarse, la CPU de la máquina se activa con mucha más frecuencia que si el controlador de interfaz de red discrimina y rechaza los paquetes unilateralmente. Un enfoque de compromiso es seleccionar una sola dirección MAC fija o un pequeño número de direcciones MAC (por ejemplo, una para cada red privada virtual en una Ethernet) para utilizar en las comunicaciones con salto MAC, independientemente del receptor real para el que se envía el mensaje destinado a. En este modo, el controlador de interfaz de red puede verificar cada trama incidente con una (o algunas) direcciones MAC preestablecidas, liberando así a la CPU de la tarea de discriminación de paquetes de capa física. Este esquema no revela ninguna información útil a un intruso en la LAN; en particular, cada paquete seguro ya puede identificarse por un tipo de paquete único en el encabezado externo. Sin embargo, dado que todas las máquinas involucradas en comunicaciones seguras estarían utilizando la misma dirección MAC, o estarían seleccionando de un pequeño grupo de direcciones MAC predeterminadas, la asociación entre una máquina específica y una dirección Ma C específica se rompe efectivamente.
En este esquema, la CPU se activará más a menudo de lo que lo haría en comunicaciones no seguras (o en saltos de direcciones MAC sincronizadas), ya que el controlador de interfaz de red no siempre puede discriminar unilateralmente entre paquetes seguros destinados a esa máquina y paquetes seguros de otras VPN. Sin embargo, el tráfico no seguro se elimina fácilmente en la interfaz de red, lo que reduce la cantidad de procesamiento requerido por la CPU. Existen condiciones límite en las que estas declaraciones no se cumplirían, por supuesto, por ejemplo, si todo el tráfico en la LAN es tráfico seguro, entonces la CPU estaría activada en el mismo grado que en el caso de salto de dirección puramente aleatorio; alternativamente, si cada VPN en la LAN usa una dirección MAC diferente, entonces la interfaz de red puede discriminar perfectamente las tramas seguras destinadas a la máquina local de aquellas que constituyen otras VPN. Estas son compensaciones de ingeniería que podrían manejarse mejor al proporcionar opciones administrativas para los usuarios al instalar el software y/o establecer VPN.
Sin embargo, incluso en este escenario, sigue existiendo un ligero riesgo de seleccionar direcciones MAC que están siendo utilizadas por uno o más nodos en la LAN. Una solución a este problema es asignar formalmente una dirección o un rango de direcciones para utilizar en comunicaciones con salto de MAC. Esto normalmente se realiza a través de una autoridad de registro de números asignada; por ejemplo, en el caso de Ethernet, el Instituto de Ingenieros Eléctricos y Electrónicos (IEEE) asigna rangos de direcciones MAC a los proveedores. Un rango de direcciones asignado formalmente garantizaría que las tramas seguras no entren en conflicto con ninguna máquina configurada correctamente y que funcione correctamente en la LAN.
Ahora se hará referencia a las Figs. 12A y 12B para describir las muchas combinaciones y características que siguen los principios inventivos. Como se explicó anteriormente, se supone que dos nodos 1201 y 1202 de ordenador se comunican a través de una red o medio de comunicación como un Ethernet. Un protocolo de comunicación en cada nodo (1204 y 1217, respectivamente) contiene un elemento 1205 y 1216 modificado que realiza ciertas funciones que se desvían de los protocolos de comunicación estándar. En particular, el nodo 1201 de ordenador implementa un primer algoritmo 1208X de “salto” que selecciona direcciones IP de origen y destino aparentemente aleatorias (y, en una realización, campos discriminadores de encabezado de IP aparentemente aleatorios) para transmitir cada paquete al otro nodo de ordenador. Por ejemplo, el nodo 1201 mantiene una tabla 1208 de transmisión que contiene tripletes de origen (S), destino (D) y campos discriminadores (DS) que se insertan en los encabezados de paquetes IP salientes. La tabla se genera mediante el uso de un algoritmo apropiado (por ejemplo, un generador de números aleatorios que se siembra con una semilla apropiada) que el nodo 1202 receptor conoce. A medida que se forma cada nuevo paquete IP, la siguiente entrada secuencial sale de la tabla 1208 de transmisión del remitente se usa para llenar el campo de origen de IP, destino de IP y extensión de encabezado de IP (por ejemplo, campo discriminador). Se apreciará que la tabla de transmisión no necesita ser creada de antemano, sino que podría crearse sobre la marcha ejecutando el algoritmo cuando se forma cada paquete.
En el nodo 1202 receptor, se mantiene el mismo algoritmo 1222X de salto de IP y se usa para generar una tabla 1222 de recepción que enumera tripletes válidos de dirección IP de origen, dirección IP de destino y campo discriminador. Esto se muestra en virtud de que las primeras cinco entradas de la tabla 1208 de transmisión coinciden con las segundas cinco entradas de la tabla 1222 de recepción. (Las tablas pueden estar ligeramente desplazadas en cualquier momento particular debido a paquetes perdidos, paquetes mal ordenados o retrasos en la transmisión). Además, el nodo 1202 mantiene una ventana de recepción W3 que representa una lista de campos de origen, destino de IP y discriminador de IP válidos que se aceptarán cuando se reciban como parte de un paquete de IP entrante. A medida que se reciben los paquetes, la ventana W3 se desliza hacia abajo en la lista de entradas válidas, de modo que las posibles entradas válidas cambian con el tiempo. Se aceptarán dos paquetes que lleguen fuera de orden pero que coincidan con las entradas dentro de la ventana W3; los que caigan fuera de la ventana W3 serán rechazados como inválidos. La longitud de la ventana W3 se puede ajustar según sea necesario para reflejar los retrasos de la red u otros factores.
El nodo 1202 mantiene una tabla 1221 de transmisión similar para crear paquetes IP y tramas destinadas al nodo 1201 utilizando un algoritmo 1221X de salto potencialmente diferente, y el nodo 1201 mantiene una tabla 1209 de recepción coincidente utilizando el mismo algoritmo 1209X. A medida que el nodo 1202 transmite paquetes al nodo 1201 utilizando campos de fuente IP, destino IP y/o discriminador aparentemente aleatorios, el nodo 1201 hace coincidir los valores de los paquetes entrantes con los que caen dentro de la ventana W1 mantenida en su tabla de recepción. En efecto, la tabla 1208 de transmisión del nodo 1201 está sincronizada (es decir, las entradas se seleccionan en el mismo orden) para recibir la tabla 1222 del nodo 1202 de recepción. De manera similar, la tabla 1221 de transmisión del nodo 1202 está sincronizada para recibir la tabla 1209 del nodo 1201. Se apreciará que, aunque se muestra un algoritmo común para los campos fuente, destino y discriminador en la figura 12A (usando, por ejemplo, una semilla diferente para cada uno de los tres campos), un algoritmo completamente diferente podría de hecho usarse para establecer valores para cada uno de estos campos. También se apreciará que uno o dos de los campos se pueden “saltar” en lugar de los tres como se ilustra.
De acuerdo con otro aspecto de la invención, se saltan direcciones de hardware o “MAC” en lugar de o además de las direcciones IP y/o el campo discriminador para mejorar la seguridad en un área local o red de tipo difusión. Con ese fin, el nodo 1201 mantiene además una tabla 1210 de transmisión utilizando un algoritmo 1210X de transmisión para generar direcciones de hardware de origen y destino que se insertan en encabezados de trama (por ejemplo, campos 1101A y 1101B en la figura 11) que se sincronizan con una tabla 1224 de recepción correspondiente en el nodo 1202. Del mismo modo, el nodo 1202 mantiene una tabla 1223 de transmisión diferente que contiene las direcciones de hardware de origen y destino que se sincroniza con una tabla 1211 de recepción correspondiente en el nodo 1201. De esta manera, las tramas de hardware salientes parecen originarse y llegar a completamente nodos aleatorios en la red, a pesar de que cada receptor puede determinar si un paquete determinado está destinado o no. Se apreciará que la función de salto de hardware se puede implementar en un nivel diferente en el protocolo de comunicaciones que la función de salto de IP (por ejemplo, en un controlador de tarjeta o en una tarjeta de hardware para mejorar el rendimiento).
La figura 12B muestra tres realizaciones o modos diferentes que pueden emplearse utilizando los principios mencionados anteriormente. En un primer modo denominado modo “promiscuo”, todos los nodos de la red utilizan una dirección de hardware común (por ejemplo, una dirección fija para el origen y otra para el destino) o una dirección de hardware completamente aleatoria, de modo que un paquete particular no se puede atribuir a ningún nodo. Cada nodo debe aceptar inicialmente todos los paquetes que contienen la dirección de hardware común (o aleatoria) e inspeccionar las direcciones IP o el campo discriminador para determinar si el paquete está destinado a ese nodo. A este respecto, las direcciones IP o el campo discriminador o ambos pueden variarse de acuerdo con un algoritmo como se describió anteriormente. Como se explicó anteriormente, esto puede aumentar la sobrecarga de cada nodo ya que se trata de un procesamiento adicional para determinar si un paquete dado tiene direcciones de hardware de origen y destino válidas.
En un segundo modo denominado modo “promiscuo por VPN”, se usa un pequeño conjunto de direcciones de hardware fijas, con una dirección de hardware de origen/destino fija utilizada para todos los nodos que se comunican a través de una red privada virtual. Por ejemplo, si hay seis nodos en una Ethernet, y la red se dividirá en dos redes virtuales privadas de modo que los nodos en una VPN puedan comunicarse solo con los otros dos nodos en su propia VPN, entonces dos conjuntos de direcciones de hardware podría usarse: un conjunto para la primera VPN y un segundo conjunto para la segunda VPN. Esto reduciría la cantidad de sobrecarga involucrada en la verificación de tramas válidas, ya que solo los paquetes que llegan desde la VPN designada necesitarían ser verificados. Las direcciones IP y uno o más campos discriminadores aún podrían saltarse como antes para una comunicación segura dentro de la VPN. Por supuesto, esta solución compromete el anonimato de las VPN (es decir, un extraño puede decir fácilmente qué tráfico pertenece a qué VPN, aunque no puede correlacionarlo con una máquina/persona específica). También requiere el uso de un campo discriminador para mitigar la vulnerabilidad a ciertos tipos de ataques DoS. (Por ejemplo, sin el campo discriminador, un atacante en la LAN podría transmitir tramas que contengan las direcciones MAC que usa la VPN; rechazar esas tramas podría generar una sobrecarga de procesamiento excesiva. El campo discriminador proporcionaría un medio de baja sobrecarga para rechazar los paquetes falsos).
En un tercer modo denominado modo de “salto de hardware”, las direcciones de hardware varían como se ilustra en la figura 12A, de modo que las direcciones de origen y destino de hardware se cambian constantemente para proporcionar un direccionamiento no atribuible. Por supuesto, las variaciones en estas realizaciones son posibles, y la invención no pretende estar limitada en ningún aspecto por estos ejemplos ilustrativos.
B. Ampliar el espacio de direcciones
El salto de direcciones proporciona seguridad y privacidad. Sin embargo, el nivel de protección está limitado por el número de direcciones en los bloques que se saltan. Un bloque de salto denota un campo o campos modulados en forma de paquete con el fin de proporcionar una VPN. Por ejemplo, si dos nodos se comunican con el salto de direcciones iP utilizando bloques de salto de 4 direcciones (2 bits) cada uno, habría 16 combinaciones posibles de pares de direcciones. Una ventana de tamaño 16 daría como resultado que la mayoría de los pares de direcciones sean aceptados como válidos la mayor parte del tiempo. Esta limitación se puede superar mediante el uso de un campo discriminador además de o en lugar de los campos de dirección saltados. El campo discriminador se saltaría exactamente de la misma manera que los campos de dirección y se usaría para determinar si un paquete debe ser procesado por un receptor.
Suponga que dos clientes, cada uno con bloques de salto de cuatro bits, desearían el mismo nivel de protección brindado a los clientes que se comunican mediante salto de IP entre dos bloques A (24 bits de dirección elegibles para salto). Un campo discriminador de 20 bits, utilizado junto con los 4 bits de dirección elegibles para saltar en el campo de dirección IP, proporciona este nivel de protección. Un campo discriminador de 24 bits proporcionaría un nivel de protección similar si los campos de dirección no se saltaran o ignoraran. El uso de un campo discriminador ofrece las siguientes ventajas: (1) se puede proporcionar un nivel arbitrariamente alto de protección, y (2) el salto de direcciones es innecesario para proporcionar protección. Esto puede ser importante en entornos donde el salto de direcciones causaría problemas de enrutamiento.
C. Técnicas de sincronización
En general, se supone que una vez que un nodo remitente y un nodo receptor hayan intercambiado algoritmos y semillas (o información similar suficiente para generar tablas de origen y destino cuasialeatorias), la comunicación posterior entre los dos nodos se realizará sin problemas. Sin embargo, de manera realista, dos nodos pueden perder la sincronización debido a demoras o interrupciones de la red u otros problemas. En consecuencia, es deseable proporcionar medios para restablecer la sincronización entre nodos en una red que ha perdido la sincronización.
Una técnica posible es exigir que cada nodo proporcione una confirmación tras la recepción exitosa de cada paquete y, si no se recibe confirmación dentro de un cierto período de tiempo, volver a enviar el paquete no acreditado. Sin embargo, este enfoque aumenta los costes generales y puede ser prohibitivo en entornos de alto rendimiento, como la transmisión de video o audio, por ejemplo.
Un enfoque diferente es emplear una técnica de sincronización automática a la que se hará referencia en este documento como “auto-sincronización”. En este enfoque, la información de sincronización se incrusta en cada paquete, lo que permite al receptor volver a sincronizarse al recibir un solo paquete si determina que ha perdido la sincronización con el remitente. (Si las comunicaciones ya están en progreso, y el receptor determina que todavía está sincronizado con el remitente, entonces no hay necesidad de volver a sincronizar). Un receptor podría detectar que no estaba sincronizado, por ejemplo, empleando un temporizador “hombre muerto” que expira después de un cierto período de tiempo, en el que el temporizador se restablece con cada paquete válido. Una marca de tiempo podría agregarse al campo de sincronización pública (ver más abajo) para evitar ataques de reintento de paquetes.
En una realización, se agrega un “campo de sincronización” al encabezado de cada paquete enviado por el remitente. Este campo de sincronización podría aparecer no cifrado o como parte de una parte cifrada del paquete. Suponiendo que un remitente y un receptor hayan seleccionado un generador de números aleatorios (RNG) y un valor inicial, esta combinación de RNG e inicial puede usarse para generar una secuencia de números aleatorios (RNS). El RNS se usa para generar una secuencia de pares de IP de origen/destino (y, si se desea, campos discriminadores y direcciones de origen y destino de hardware), como se describió anteriormente. Sin embargo, no es necesario generar la secuencia completa (o los primeros valores N-1) para generar el enésimo número aleatorio en la secuencia; si se conoce el índice de secuencia N, el valor aleatorio correspondiente a ese índice puede generarse directamente (ver más abajo). Se podrían utilizar diferentes RNG (y semillas) con diferentes períodos fundamentales para generar las secuencias de IP de origen y destino, pero los conceptos básicos seguirían siendo válidos. En aras de la simplicidad, la siguiente discusión supondrá que los pares de direcciones de origen y destino IP (solo) se saltan utilizando un único mecanismo de secuencia RNG.
De acuerdo con una característica de “auto-sincronización”, un campo de sincronización en cada encabezado de paquete proporciona un índice (es decir, un número de secuencia) en el RNS que se está utilizando para generar pares de IP. Al conectar este índice en el RNG que se está utilizando para generar el RNS, se obtiene un valor de número aleatorio específico, que a su vez produce un par de IP específico. Es decir, se puede generar un par de IP directamente a partir del conocimiento del RNG, la semilla y el número de índice; no es necesario, en este esquema, generar la secuencia completa de números aleatorios que preceden al valor de secuencia asociado con el número de índice proporcionado.
Como los comunicantes presumiblemente han intercambiado previamente RNG y semillas, la única información nueva que debe proporcionarse para generar un par de IP es el número de secuencia. Si el remitente proporciona este número en el encabezado del paquete, entonces el receptor solo necesita enchufar este número en el RNG para generar un par de IP, y así verificar que el par de IP que aparece en el encabezado del paquete sea válido. En este esquema, si el remitente y el receptor pierden la sincronización, el receptor puede volver a sincronizarse inmediatamente al recibir un solo paquete simplemente comparando el par IP en el encabezado del paquete con el par IP generado a partir del número de índice. Por lo tanto, las comunicaciones sincronizadas se pueden reanudar al recibir un solo paquete, lo que hace que este esquema sea ideal para las comunicaciones de multidifusión. Llevado al extremo, podría obviar la necesidad de tablas de sincronización por completo; es decir, el remitente y el receptor podrían simplemente confiar en el número de índice en el campo de sincronización para validar el par de IP en cada paquete y, por lo tanto, eliminar las tablas por completo.
El esquema antes mencionado puede tener algunos problemas de seguridad inherentes asociados a él, a saber, la colocación del campo de sincronización. Si el campo se coloca en el encabezado externo, un intruso podría observar los valores del campo y su relación con la secuencia de IP. Esto podría comprometer el algoritmo que se utiliza para generar la secuencia de direcciones IP, lo que comprometería la seguridad de las comunicaciones. Sin embargo, si el valor se coloca en el encabezado interno, entonces el remitente debe descifrar el encabezado interno antes de poder extraer el valor de sincronización y validar el par de IP; esto abre el receptor a ciertos tipos de ataques de denegación de servicio (DoS), como la reproducción de paquetes. Es decir, si el receptor debe descifrar un paquete antes de que pueda validar el par de IP, entonces podría verse obligado a gastar una cantidad significativa de procesamiento en el descifrado si un atacante simplemente retransmite paquetes previamente válidos. Otras metodologías de ataque son posibles en este escenario.
Un posible compromiso entre la seguridad del algoritmo y la velocidad de procesamiento es dividir el valor de sincronización entre un encabezado interno (cifrado) y externo (no cifrada). Es decir, si el valor de sincronización es lo suficientemente largo, podría dividirse en una parte que cambia rápidamente y que se puede ver en claro, y una parte fija (o que cambia muy lentamente) que debe protegerse. La parte que se puede ver no cifrada se denominará parte de “sincronización pública” y la parte que debe protegerse se denominará parte de “sincronización privada”.
Se necesitan ambas partes, la sincronización pública y la sincronización privada, para generar el valor de sincronización completo. Sin embargo, la parte privada se puede seleccionar de modo que sea fija o cambie solo ocasionalmente. Por lo tanto, el receptor puede almacenar el valor de sincronización privada, evitando así la necesidad de descifrar el encabezado para recuperarlo. Si el remitente y el receptor han acordado previamente la frecuencia con la que cambiará la parte privada de la sincronización, entonces el receptor puede descifrar selectivamente un solo encabezado para extraer la nueva sincronización privada si la brecha de comunicación que ha llevado a la sincronización perdida excedió la vida útil de la sincronización privada anterior. Esto no debería representar una cantidad pesada de descifrado y, por lo tanto, no debería abrir el receptor al ataque de denegación de servicio simplemente en función de la necesidad de descifrar ocasionalmente un solo encabezado.
Una implementación de esto es utilizar una función de hashing con un mapeo uno a uno para generar las porciones de sincronización privadas y públicas a partir del valor de sincronización. Esta implementación se muestra en la figura 13, donde (por ejemplo) un primer ISP 1302 es el remitente y un segundo ISP 1303 es el receptor. (Otras alternativas son posibles a partir de la figura 13.) Un paquete transmitido comprende un encabezado 1305 público o “externo” que no está cifrado, y un encabezado 1306 privado o “ interno” que está cifrado usando, por ejemplo, una clave de enlace. El encabezado 1305 externo incluye una porción de sincronización pública mientras que el encabezado interno 1306 contiene la porción de sincronización privada. Un nodo receptor descifra el encabezado interno utilizando una función 1307 de descifrado para extraer la parte de sincronización privada. Este paso es necesario solo si la vida útil de la sincronización privada almacenada en el búfer ha expirado. (Si la sincronización privada actualmente almacenada en el búfer sigue siendo válida, simplemente se extrae de la memoria y se “agrega” (que podría ser un hash inverso) a la sincronización pública, como se muestra en el paso 1308.) Las partes de sincronización pública y descifrada privada se combinan en la función 1308 para generar la sincronización combinada 1309. La sincronización combinada (1309) se alimenta al RNG (1310) y se compara con el par de direcciones IP (1311) para validar o rechazar el paquete.
Una consideración importante en esta arquitectura es el concepto de “futuro” y “pasado” en lo que respecta a los valores de sincronización pública. Aunque los valores de sincronización, en sí mismos, deben ser aleatorios para evitar ataques de suplantación de identidad, puede ser importante que el receptor pueda identificar rápidamente un valor de sincronización que ya se haya enviado, incluso si el paquete que contiene ese valor de sincronización nunca fue realmente recibido por el receptor. Una solución es introducir un número de marca de tiempo o secuencia en la parte de sincronización pública, que podría extraerse, verificarse y descartarse rápidamente, validando así la parte de sincronización pública.
En una realización, los paquetes se pueden verificar comparando el par de IP de origen/destino generado por el campo de sincronización con el par que aparece en el encabezado del paquete. Si (1) coinciden, (2) la marca de tiempo es válida y (3) el temporizador de hombre muerto ha expirado, se produce una resincronización; de lo contrario, el paquete es rechazado. Si hay suficiente potencia de procesamiento disponible, el temporizador de hombre muerto y las tablas de sincronización se pueden evitar por completo, y el receptor simplemente volvería a sincronizar (por ejemplo, validar) en cada paquete.
El esquema anterior puede requerir matemática de enteros grandes (por ejemplo, 160 bits), lo que puede afectar su implementación. Sin estos registros de enteros grandes, el rendimiento del procesamiento se vería afectado, lo que podría afectar la seguridad desde el punto de vista de la denegación de servicio. Sin embargo, a medida que las funciones de procesamiento matemático de enteros grandes se vuelvan más frecuentes, los costes de implementar dicha función se reducirán.
D. Otros esquemas de sincronización
Como se explicó anteriormente, si se pierden W o más paquetes consecutivos entre un transmisor y un receptor en una VPN (donde W es el tamaño de la ventana), la ventana del receptor no se habrá actualizado y el transmisor estará transmitiendo paquetes que no están en la ventana del receptor. El transmisor y el receptor no recuperarán la sincronización hasta que quizás los pares aleatorios en la ventana se repitan por casualidad. Por lo tanto, es necesario mantener un remitente y un receptor sincronizados siempre que sea posible y restablecer la sincronización siempre que se pierda.
Se puede utilizar un esquema de “punto de control” para recuperar la sincronización entre un remitente y un receptor que se ha quedado sin sincronización. En este esquema, se utiliza un mensaje de punto de control que comprende un par de direcciones IP aleatorias para comunicar información de sincronización. En una realización, se usan dos mensajes para comunicar información de sincronización entre un remitente y un receptor:
1. SYNC_REQ es un mensaje utilizado por el remitente para indicar que desea sincronizar; y
2. SYNC_ACK es un mensaje utilizado por el receptor para informar al transmisor que se ha sincronizado.
De acuerdo con una variación de este enfoque, tanto el transmisor como el receptor mantienen tres puntos de control (ver FIG. 14):
1. En el transmisor, ckpt_o (“punto de control antiguo”) es el par IP que se utilizó para reenviar el último paquete SYNC_REQ al receptor. En el receptor, ckpt_o (“punto de control antiguo”) es el par de IP que recibe paquetes SYNC_REQ repetidos del transmisor.
2. En el transmisor, ckpt_n (“punto de control nuevo”) es el par de IP que se utilizará para enviar el siguiente paquete SYNC_REQ al receptor. En el receptor, ckpt_n (“punto de control nuevo”) es el par de IP que recibe un nuevo paquete SYNC_REQ del transmisor y que hace que la ventana del receptor se vuelva a alinear, ckpt_o se establezca en ckpt_n, se genere un nuevo ckpt_n y se generará un nuevo ckpt_r.
3. En el transmisor, ckpt_r es el par de IP que se utilizará para enviar el siguiente paquete SYNC_ACK al receptor. En el receptor, ckpt_r es el par de IP que recibe un nuevo paquete SYNC_ACK del transmisor y que genera un nuevo ckpt_n. Dado que SYNC_ACK se transmite desde el ISP del receptor al ISP del transmisor, el remitente ckpt_r se refiere a la ckpt_r del receptor y el receptor ckpt_r se refiere a la ckpt_r del transmisor (véase la figura 14).
Cuando un transmisor inicia la sincronización, el par de IP que usará para transmitir el siguiente paquete de datos se establece en un valor predeterminado y cuando un receptor recibe por primera vez un SYNC_REQ, la ventana del receptor se actualiza para centrarse en el próximo par de IP del transmisor. Este es el mecanismo principal para la sincronización del punto de control.
La sincronización puede iniciarse mediante un contador de paquetes (por ejemplo, después de cada N paquetes transmitidos, iniciar una sincronización) o mediante un temporizador (cada S segundos, iniciar una sincronización) o una combinación de ambos. Ver FIG. 15. Desde la perspectiva del transmisor, esta técnica funciona de la siguiente manera: (1) Cada transmisor transmite periódicamente un mensaje de “solicitud de sincronización” al receptor para asegurarse de que esté sincronizado. (2) Si el receptor todavía está sincronizado, envía un mensaje de “confirmación de sincronización”. (Si esto funciona, no es necesaria ninguna otra acción). (3) Si no se ha recibido una “confirmación de sincronización” dentro de un período de tiempo, el transmisor retransmite la solicitud de sincronización nuevamente. Si el transmisor alcanza el siguiente punto de control sin recibir una respuesta de “confirmación de sincronización”, la sincronización se interrumpe y el transmisor debe dejar de transmitir. El transmisor continuará enviando sync_reqs hasta que reciba un sync_ack, momento en el cual se restablecerá la transmisión.
Desde la perspectiva del receptor, el esquema funciona de la siguiente manera: (1) cuando recibe una solicitud de “solicitud de sincronización” del transmisor, avanza su ventana a la siguiente posición de punto de control (incluso omitiendo pares si es necesario), y envía un mensaje “sync ack” al transmisor. Si la sincronización nunca se perdió, entonces el “avance” realmente avanza al siguiente par de direcciones disponibles en la tabla (es decir, avance normal).
Si un intruso intercepta los mensajes de “solicitud de sincronización” e intenta interferir con la comunicación enviando mensajes nuevos, se ignorará si se ha establecido la sincronización o realmente ayudará a restablecer la sincronización.
Una ventana se vuelve a alinear cada vez que se produce una resincronización. Esta realineación implica actualizar la ventana del receptor para abarcar los pares de direcciones utilizados por el paquete transmitido inmediatamente después de la transmisión del paquete SYNC_REQ. Normalmente, el transmisor y el receptor están sincronizados entre sí. Sin embargo, cuando ocurren eventos de red, la ventana del receptor puede tener que avanzar muchos pasos durante la resincronización. En este caso, es deseable avanzar la ventana sin tener que pasar secuencialmente por los números aleatorios que intervienen. (Esta característica también es deseable para el enfoque de sincronización automática discutido anteriormente).
E. Generador de números aleatorios con capacidad de avance
Un método atractivo para generar direcciones saltadas aleatoriamente es utilizar generadores de números aleatorios idénticos en el transmisor y el receptor y avanzarlos a medida que se transmiten y reciben paquetes. Hay muchos algoritmos de generación de números aleatorios que podrían usarse. Cada uno tiene fortalezas y debilidades para las aplicaciones de salto de direcciones.
Los generadores de números aleatorios congruenciales lineales (LCR) son generadores de números aleatorios rápidos, simples y bien caracterizados que se pueden hacer para saltar adelante n pasos de manera eficiente. Un LCR genera números aleatorios X1, X2, X3... Xk comenzando con la semilla X0 utilizando una recurrencia
Xi=(aXi-1 b) mod c, (1)
donde a, b y c definen un LCR particular. Otra expresión para Xi,
Xi=((ai(X0+b)-b)/(a-1)) mod c (2)
habilita la capacidad de avance. El factor a' puede crecer mucho incluso para personas modestas si no se libera. Por lo tanto, algunas propiedades especiales de la operación de módulo se pueden utilizar para controlar el tamaño y el tiempo de procesamiento requerido para calcular (2). (2) se puede reescribir como:
Xi=(ai(X0(a-1)+b)-b)/(a-1) mod c. (3)
Se puede demostrar que:
(ai(X0(a-1)+b)-b)/(a-1) mod c =
((ai mod((a-1)c)(Xo(a-1)+b)-b)/(a-1)) mod c (4).
(Xo(a-1)+b) se puede almacenar como (Xo(a-1)+b) mod c, b como b mod c y calcular a' mod ((a-1)c) (esto requiere pasos 0(log(i))).
Una implementación práctica de este algoritmo saltaría una distancia fija, n, entre sincronizaciones; Esto equivale a sincronizar cada n paquetes. La ventana comenzaría n pares de IP desde el inicio de la ventana anterior. Usando Xj*2, el número aleatorio en el j-ésimo punto de control, como Xo y n como i, un nodo puede almacenar an mode(a-1) c) una vez por LCR y establece
Xj+1w=Xn(j+1)=((an mod((a-1)c) (Xjw(a-1)+b)-b)/(a-1))mod c, (5) para generar el número aleatorio para el j+1ra sincronización. Utilizando esta construcción, un nodo podría saltar una distancia arbitraria (pero fija) entre sincronizaciones en una cantidad de tiempo constante (independiente de n). Los generadores de números pseudoaleatorios, en general, y los LCR, en particular, eventualmente repetirán sus ciclos. Esta repetición puede presentar vulnerabilidad en el esquema de salto de IP. Un adversario simplemente tendría que esperar una repetición para predecir secuencias futuras. Una forma de hacer frente a esta vulnerabilidad es crear un generador de números aleatorios con un ciclo largo conocido. Una secuencia aleatoria puede ser reemplazada por un nuevo generador de números aleatorios antes de que se repita. Los LCR se pueden construir con ciclos largos conocidos. Esto no es cierto actualmente para muchos generadores de números aleatorios.
Los generadores de números aleatorios pueden ser criptográficamente inseguros. Un adversario puede derivar los parámetros RNG al examinar la salida o parte de la salida. Esto es cierto para los LCG. Esta vulnerabilidad puede mitigarse incorporando un cifrador, diseñado para codificar la salida como parte del generador de números aleatorios. El generador de números aleatorios evita que un adversario realice un ataque, por ejemplo, un ataque de texto sin formato conocido, contra el cifrador.
F. Ejemplo de generador de números aleatorios
Considere un RNG donde a = 31, b=4 y c=15. Para este caso, la ecuación (1) se convierte en:
Xi=(31 Xi-1 4)mod 15. (6)
Si uno establece Xü=1, la ecuación (6) producirá la secuencia 1, 5, 9, 13, 2, 6, 10, 14, 3, 7, 11, 0, 4, 8, 12. Esto secuencia se repetirá indefinidamente. Para un salto por delante de 3 números en esta secuencia a”= 313= 29791, c*(a-1) = 15*30 = 450 y an mod ((a-1) c) = 313 mod (15*30) = 29791mod(450) = 91. La ecuación (5) se convierte en:
((91 Xi30+4)-4)/30)mod 15 (7).
La Tabla 1 muestra los cálculos de salto hacia adelante de (7). Los cálculos comienzan en 5 y saltan 3.
Tabla 1
Figure imgf000021_0001
G. Filtro de paquetes rápido
Las VPN de salto de dirección deben determinar rápidamente si un paquete tiene un encabezado válido y, por lo tanto, requiere un procesamiento adicional o si tiene un encabezado no válido (un paquete hostil) y debe rechazarse de inmediato. Dichas determinaciones rápidas se denominarán “filtrado rápido de paquetes”. Esta capacidad protege la VPN de los ataques de un adversario que transmite paquetes hostiles en el receptor a una velocidad alta con la esperanza de saturar el procesador del receptor (un llamado ataque de “denegación de servicio”). El filtrado rápido de paquetes es una característica importante para implementar VPN en medios compartidos como Ethernet.
Suponiendo que todos los participantes en una VPN compartan un bloque de direcciones “A” no asignado, una posibilidad es utilizar un bloque experimental “A” que nunca se asignará a ninguna máquina que no sea salto de direcciones en el medio compartido. Los bloques “A” tienen una dirección de 24 bits que se puede saltar en lugar de los 8 bits en los bloques “C”. En este caso, un bloque de salto será el bloque “A”. El uso del bloque experimental “A” es una opción probable en un Ethernet porque:
1. Las direcciones no tienen validez fuera de Ethernet y no serán enrutadas a un destino externo válido por una puerta de enlace.
2. Hay 224 (~16 millones) direcciones que se pueden saltar dentro de cada bloque “A”. Esto produce >280 billones de pares de direcciones posibles, por lo que es muy poco probable que un adversario adivine una dirección válida. También proporciona una probabilidad aceptablemente baja de colisión entre VPN separadas (todas las VPN en un medio compartido generan independientemente pares de direcciones aleatorias del mismo bloque “A”).
3. Los paquetes no serán recibidos por alguien en Ethernet que no esté en una VPN (a menos que la máquina esté en modo promiscuo) minimizando el impacto en los ordenadores que no son VPN.
El ejemplo de Ethernet se usará para describir una implementación del filtrado rápido de paquetes. El algoritmo ideal examinaría rápidamente un encabezado de paquete, determinaría si el paquete es hostil y rechazaría cualquier paquete hostil o determinaría qué par de IP activo coincide con el encabezado del paquete. El problema es un problema clásico de memoria asociativa. Se han desarrollado una variedad de técnicas para resolver este problema (hashing, árbol binario, etc.). Cada uno de estos enfoques tiene sus fortalezas y debilidades. Por ejemplo, se puede hacer que las tablas hash funcionen bastante rápido en un sentido estadístico, pero en ocasiones pueden degenerar en un algoritmo mucho más lento. Esta lentitud puede persistir por un período de tiempo. Dado que existe la necesidad de descartar paquetes hostiles rápidamente en todo momento, el hash sería inaceptable.
H. Algoritmo de vector de presencia
Un vector de presencia es un vector de bits de longitud 2n que puede indexarse con n números de bits (cada uno de los cuales varía de 0 a 2n-1). Se puede indicar la presencia de k n números de bit (no necesariamente únicos), estableciendo los bits en el vector de presencia indexados por cada número a 1. De lo contrario, los bits en el vector de presencia son 0. Un número bits n de, x, es uno de los k números si y solo si el xésimo bit del vector de presencia es I. Se puede implementar un filtro de paquetes rápido indexando el vector de presencia y buscando un 1, que se denominará “prueba”.
Por ejemplo, supongamos que uno quisiera representar el número 135 utilizando un vector de presencia. Se establecería el bit 135 del vector. En consecuencia, se podría determinar rápidamente si una dirección de 135 era válida al revisar un solo bit: el bit 135. Los vectores de presencia podrían crearse de antemano correspondientes a las entradas de la tabla para las direcciones IP. En efecto, las direcciones entrantes se pueden utilizar como índices en un vector largo, lo que hace que las comparaciones sean muy rápidas. A medida que cada RNG genera una nueva dirección, el vector de presencia se actualiza para reflejar la información. A medida que se mueve la ventana, el vector de presencia se actualiza a cero direcciones que ya no son válidas.
Existe una compensación entre la eficiencia de la prueba y la cantidad de memoria requerida para almacenar los vectores de presencia. Por ejemplo, si uno usara los 48 bits de direcciones de salto como índice, el vector de presencia tendría que ser de 35 terabytes. Claramente, esto es demasiado grande para fines prácticos. En cambio, los 48 bits se pueden dividir en varios campos más pequeños. Por ejemplo, uno podría subdividir los 48 bits en cuatro campos de 12 bits (ver Figura 16). Esto reduce el requisito de almacenamiento a 2048 bytes a expensas de tener que procesar ocasionalmente un paquete hostil. En efecto, en lugar de un vector de presencia larga, las porciones de dirección descompuestas deben coincidir con los cuatro vectores de presencia más cortos antes de que se permita el procesamiento adicional. (Si la primera parte de la porción de dirección no coincide con el primer vector de presencia, no hay necesidad de verificar los tres vectores de presencia restantes).
Un vector presencia tendrá un 1 en el yésimo bit si y sólo si una o más direcciones con un campo correspondiente de y están activos. Una dirección está activa solo si cada vector de presencia indexado por el subcampo apropiado de la dirección es 1.
Considere una ventana de 32 direcciones activas y 3 puntos de control. Un paquete hostil será rechazado por la indexación de un vector de presencia más del 99% de las veces. Un paquete hostil será rechazado por la indexación de los 4 vectores de presencia más del 99.9999995% de las veces. En promedio, los paquetes hostiles serán rechazados en menos de 1.02 operaciones de índice de vector de presencia.
El pequeño porcentaje de paquetes hostiles que pasan el filtro de paquetes rápido se rechazará cuando no se encuentren pares coincidentes en la ventana activa o sean puntos de control activos. Los paquetes hostiles que coinciden casualmente con un encabezado serán rechazados cuando el software VPN intente descifrar el encabezado. Sin embargo, estos casos serán extremadamente raros. Hay muchas otras formas en que este método se puede configurar para arbitrar las compensaciones de espacio/velocidad.

Claims (14)

REIVINDICACIONES
1. Un método para un primer nodo (801) para establecer una sesión con un segundo nodo (811), el método se realiza en el primer nodo (801), en el que el método comprende:
enviar, desde una primera dirección para el primer nodo (801) a una primera dirección para el segundo nodo (811), una solicitud (821) para iniciar la sesión; y
recibir, en la primera dirección para el primer nodo (801) desde la primera dirección para el segundo nodo (811), un primer mensaje (822) de confirmación,
caracterizado porque:
el primer mensaje de confirmación incluye un bloqueo de transmisión que el primer nodo (801) se utiliza para comunicarse con el segundo nodo (811) durante la sesión, en el que el bloque de salto de transmisión comprende: un bloque de direcciones IP; y un algoritmo y una semilla de aleatorización para seleccionar, del bloque de direcciones IP, una dirección de origen y una dirección de destino para utilizar en la transmisión del siguiente mensaje;
y además caracterizado porque el método comprende, además:
durante la sesión, comunicarse con el segundo nodo (811) utilizando una segunda dirección para el primer nodo (801) y una segunda dirección para el segundo nodo (811), en el que las segundas direcciones son especificadas por el bloque de salto de transmisión.
2. El método de la reivindicación 1, en el que el segundo nodo (811) es un enrutador.
3. El método de la reivindicación 1 o la reivindicación 2, en el que el primer nodo (801) es un ordenador de cliente.
4. El método de la reivindicación 1 o la reivindicación 2, en el que el primer nodo (801) es un enrutador.
5. El método de cualquiera de las reivindicaciones anteriores, en el que el método comprende además enviar un segundo mensaje (823) de confirmación desde la primera dirección para el primer nodo (801) a la primera dirección para el segundo nodo (811).
6. El método de la reivindicación 5, que comprende además enviar, desde una tercera dirección para el primer nodo (801) a una tercera dirección para el segundo nodo (811), un tercer mensaje (824) de confirmación para la sesión.
7. El método de cualquiera de las reivindicaciones anteriores, en el que el primer mensaje (822) de confirmación incluye además un bloque de salto de recepción que el primer nodo (801) debe utilizar para comunicarse con el segundo nodo (811) durante la sesión, en el que el bloque de salto de recepción comprende:
un segundo bloque de direcciones IP; y
un algoritmo y una semilla de aleatorización para seleccionar, del segundo bloque de direcciones IP, una dirección de origen y una dirección de destino para utilizar en la recepción del siguiente mensaje.
8. El método de la reivindicación 1, en el que la solicitud para iniciar la sesión incluye una credencial de autenticación para el primer nodo (801).
9. El método de la reivindicación 1, que comprende además recibir el primer mensaje de confirmación del segundo nodo (811) cuando el segundo nodo valida la solicitud para iniciar la sesión.
10. El método de cualquiera de las reivindicaciones anteriores, en el que la sesión es una sesión segura.
11. Un primer nodo configurado para realizar el método de cualquiera de las reivindicaciones anteriores.
12. Un método para un segundo nodo (811) para establecer una sesión con un primer nodo (801), el método se realiza en el segundo nodo (811), en el que el método comprende:
recibir, en una primera dirección para el segundo nodo (811) desde una primera dirección para el primer nodo (801), una solicitud (821) para iniciar la sesión; y
enviar, desde la primera dirección para el segundo nodo (811) a la primera dirección para el primer nodo (801), un primer mensaje (822) de confirmación,
caracterizado porque:
el primer mensaje de confirmación incluye un bloqueo de salto de transmisión que el primer nodo (801) se utiliza para comunicarse con el segundo nodo (811) durante la sesión, en el que el bloque de salto de transmisión comprende: un bloque de direcciones IP; y un algoritmo y una semilla de aleatorización para seleccionar, del bloque de direcciones IP, una dirección de origen y una dirección de destino para utilizar en la transmisión del siguiente mensaje;
y además caracterizado porque el método comprende, además:
durante la sesión, comunicarse con el primer nodo (801) utilizando una segunda dirección para el primer nodo (801) y una segunda dirección para el segundo nodo (811), en el que las segundas direcciones son especificadas por el bloque de salto de transmisión.
13. El método de la reivindicación 12, en el que el primer mensaje (822) de confirmación incluye además un bloque de salto de recepción que el primer nodo (801) debe utilizar para comunicarse con el segundo nodo (811) durante la sesión, en el que el bloque de salto de recepción comprende:
un segundo bloque de direcciones IP; y
un algoritmo y una semilla de aleatorización para seleccionar, del segundo bloque de direcciones IP, una dirección de origen y
una dirección de destino para utilizar en la recepción del siguiente mensaje.
14. Un segundo nodo configurado para realizar el método de la reivindicación 12 o la reivindicación 13.
ES16165347T 1998-10-30 1999-10-29 Un protocolo de red agile para comunicaciones seguras con disponibilidad asegurada de sistema Expired - Lifetime ES2760905T3 (es)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US10626198P 1998-10-30 1998-10-30
US13770499P 1999-06-07 1999-06-07

Publications (1)

Publication Number Publication Date
ES2760905T3 true ES2760905T3 (es) 2020-05-18

Family

ID=26803485

Family Applications (1)

Application Number Title Priority Date Filing Date
ES16165347T Expired - Lifetime ES2760905T3 (es) 1998-10-30 1999-10-29 Un protocolo de red agile para comunicaciones seguras con disponibilidad asegurada de sistema

Country Status (9)

Country Link
US (10) US7010604B1 (es)
EP (4) EP3086533B1 (es)
JP (7) JP4451566B2 (es)
AT (2) ATE441275T1 (es)
AU (2) AU765914B2 (es)
CA (3) CA2349519C (es)
DE (2) DE69943057D1 (es)
ES (1) ES2760905T3 (es)
WO (2) WO2000027090A2 (es)

Families Citing this family (299)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6665702B1 (en) 1998-07-15 2003-12-16 Radware Ltd. Load balancing
US6502135B1 (en) * 1998-10-30 2002-12-31 Science Applications International Corporation Agile network protocol for secure communications with assured system availability
US10511573B2 (en) 1998-10-30 2019-12-17 Virnetx, Inc. Agile network protocol for secure communications using secure domain names
US7010604B1 (en) 1998-10-30 2006-03-07 Science Applications International Corporation Agile network protocol for secure communications with assured system availability
US6826616B2 (en) * 1998-10-30 2004-11-30 Science Applications International Corp. Method for establishing secure communication link between computers of virtual private network
US7418504B2 (en) 1998-10-30 2008-08-26 Virnetx, Inc. Agile network protocol for secure communications using secure domain names
WO2001008066A1 (en) * 1999-07-26 2001-02-01 Iprivacy Llc Electronic purchase of goods over a communication network including physical delivery while securing private and personal information
WO2001013916A1 (fr) * 1999-08-20 2001-03-01 Sagami Chemical Research Center Medicaments inhibant la mort cellulaire
US6980658B1 (en) * 1999-09-30 2005-12-27 Qualcomm Incorporated Method and apparatus for encrypting transmissions in a communication system
US8676896B1 (en) * 1999-12-10 2014-03-18 At&T Intellectual Property Ii, L.P. Network-based service for secure electronic mail delivery on an internet protocol network
AU2774901A (en) * 2000-01-06 2001-07-16 L90, Inc. Method and apparatus for selecting and delivering internet based advertising
US8335994B2 (en) * 2000-02-25 2012-12-18 Salmon Alagnak Llc Method and apparatus for providing content to a computing device
WO2001099379A1 (en) * 2000-06-19 2001-12-27 Martin Gilbert Secure communications method
US7111163B1 (en) 2000-07-10 2006-09-19 Alterwan, Inc. Wide area network using internet with quality of service
US8087064B1 (en) * 2000-08-31 2011-12-27 Verizon Communications Inc. Security extensions using at least a portion of layer 2 information or bits in the place of layer 2 information
KR100392206B1 (ko) * 2000-11-10 2003-07-22 (주)인터미디어 인터넷 통신방법
US20020080888A1 (en) * 2000-12-22 2002-06-27 Li Shu Message splitting and spatially diversified message routing for increasing transmission assurance and data security over distributed networks
US7739497B1 (en) * 2001-03-21 2010-06-15 Verizon Corporate Services Group Inc. Method and apparatus for anonymous IP datagram exchange using dynamic network address translation
US20020161904A1 (en) * 2001-04-30 2002-10-31 Xerox Corporation External access to protected device on private network
JP4727860B2 (ja) * 2001-08-03 2011-07-20 富士通株式会社 無線操作装置、およびプログラム
US7171683B2 (en) * 2001-08-30 2007-01-30 Riverhead Networks Inc. Protecting against distributed denial of service attacks
US20030046532A1 (en) * 2001-08-31 2003-03-06 Matthew Gast System and method for accelerating cryptographically secured transactions
US20030069981A1 (en) * 2001-10-09 2003-04-10 Koninklijke Philips Electronics N.V. IP hopping for secure data transfer
US8868715B2 (en) * 2001-10-15 2014-10-21 Volli Polymer Gmbh Llc Report generation and visualization systems and methods and their use in testing frameworks for determining suitability of a network for target applications
US8543681B2 (en) * 2001-10-15 2013-09-24 Volli Polymer Gmbh Llc Network topology discovery systems and methods
US7171493B2 (en) 2001-12-19 2007-01-30 The Charles Stark Draper Laboratory Camouflage of network traffic to resist attack
US8087083B1 (en) * 2002-01-04 2011-12-27 Verizon Laboratories Inc. Systems and methods for detecting a network sniffer
US7114005B2 (en) * 2002-02-05 2006-09-26 Cisco Technology, Inc. Address hopping of packet-based communications
US7865715B2 (en) * 2002-02-28 2011-01-04 Hewlett-Packard Development Company, L.P. Increasing peer privacy
US7624437B1 (en) * 2002-04-02 2009-11-24 Cisco Technology, Inc. Methods and apparatus for user authentication and interactive unit authentication
US7140041B2 (en) * 2002-04-11 2006-11-21 International Business Machines Corporation Detecting dissemination of malicious programs
KR100878764B1 (ko) * 2002-07-06 2009-01-14 삼성전자주식회사 사용자의 익명성보장을 위한 무선 랜 시스템 및 사용자의익명성 보장방법
US7246231B2 (en) * 2002-10-31 2007-07-17 Ntt Docomo, Inc. Location privacy through IP address space scrambling
JP3941709B2 (ja) * 2003-02-19 2007-07-04 ブラザー工業株式会社 ネットワーク印刷システム、Ｗｅｂサーバ、印刷装置、及びプログラム。
US7926104B1 (en) * 2003-04-16 2011-04-12 Verizon Corporate Services Group Inc. Methods and systems for network attack detection and prevention through redirection
US8218542B2 (en) * 2003-04-25 2012-07-10 Koninklijke Philips Electronics N.V. Overhead reduction and address protection in communication stack
ES2524914T3 (es) * 2003-04-25 2014-12-15 Koninklijke Philips N.V. Reducción de sobrecarga y protección de direcciones en una pila de comunicación
US7305705B2 (en) * 2003-06-30 2007-12-04 Microsoft Corporation Reducing network configuration complexity with transparent virtual private networks
US7693103B2 (en) * 2004-09-09 2010-04-06 Sony Corporation System and method for automatically performing a channel selection procedure in a wireless network
GB2412038B (en) * 2004-03-10 2006-04-19 Toshiba Res Europ Ltd Packet format
US8782405B2 (en) * 2004-03-18 2014-07-15 International Business Machines Corporation Providing transaction-level security
US7552476B2 (en) * 2004-06-25 2009-06-23 Canon Kabushiki Kaisha Security against replay attacks of messages
CN100345428C (zh) * 2004-07-26 2007-10-24 南京邮电学院 无线自组织网络中的多包分离方法
US7747774B2 (en) * 2004-08-23 2010-06-29 At&T Intellectual Property I, L.P. Methods, systems and computer program products for obscuring traffic in a distributed system
CN100413283C (zh) * 2004-09-21 2008-08-20 北京锐安科技有限公司 基于连接对的流量均衡处理方法与装置
US7624447B1 (en) 2005-09-08 2009-11-24 Cisco Technology, Inc. Using threshold lists for worm detection
US8688856B2 (en) * 2006-01-24 2014-04-01 Novell, Inc. Techniques for managing a network delivery path of content via a key
US20080005558A1 (en) * 2006-06-29 2008-01-03 Battelle Memorial Institute Methods and apparatuses for authentication and validation of computer-processable communications
US8059009B2 (en) * 2006-09-15 2011-11-15 Itron, Inc. Uplink routing without routing table
US8745185B1 (en) * 2006-10-12 2014-06-03 Timothy J. Salo Method and apparatus for providing semantically aware network services
EP2127204A2 (en) * 2006-12-08 2009-12-02 Unisys Corporation Securing multicast data
CA2571891C (en) * 2006-12-21 2015-11-24 Bce Inc. Device authentication and secure channel management for peer-to-peer initiated communications
US8156557B2 (en) * 2007-01-04 2012-04-10 Cisco Technology, Inc. Protection against reflection distributed denial of service attacks
US8464334B1 (en) * 2007-04-18 2013-06-11 Tara Chand Singhal Systems and methods for computer network defense II
US20080281966A1 (en) * 2007-05-07 2008-11-13 International Business Machines Corporation Method and system of network communication privacy between network devices
JP5040472B2 (ja) * 2007-06-28 2012-10-03 富士通株式会社 表示制御装置、表示制御プログラム及び方法
US8370937B2 (en) * 2007-12-03 2013-02-05 Cisco Technology, Inc. Handling of DDoS attacks from NAT or proxy devices
US8195949B2 (en) * 2008-02-29 2012-06-05 Red Hat, Inc. Mechanism for generating message sequence order numbers
US8812858B2 (en) * 2008-02-29 2014-08-19 Red Hat, Inc. Broadcast stenography of data communications
US8401192B2 (en) * 2008-02-29 2013-03-19 Red Hat, Inc. Mechanism for securely ordered message exchange
US20100175122A1 (en) * 2009-01-08 2010-07-08 Verizon Corporate Resources Group Llc System and method for preventing header spoofing
US9042549B2 (en) 2009-03-30 2015-05-26 Qualcomm Incorporated Apparatus and method for address privacy protection in receiver oriented channels
US8379845B2 (en) * 2009-06-19 2013-02-19 Texas Instruments Incorporated Multilayer encryption of a transport stream data and modification of a transport header
US20100333188A1 (en) * 2009-06-29 2010-12-30 Politowicz Timothy J Method for protecting networks against hostile attack
US8782434B1 (en) 2010-07-15 2014-07-15 The Research Foundation For The State University Of New York System and method for validating program execution at run-time
EP2456242A1 (en) * 2010-11-23 2012-05-23 Alcatel Lucent Communication involving a network and a terminal
US9225538B2 (en) * 2011-09-01 2015-12-29 Microsoft Technology Licensing, Llc Stateless application notifications
US9100324B2 (en) 2011-10-18 2015-08-04 Secure Crossing Research & Development, Inc. Network protocol analyzer apparatus and method
US8898795B2 (en) 2012-02-09 2014-11-25 Harris Corporation Bridge for communicating with a dynamic computer network
US8819818B2 (en) 2012-02-09 2014-08-26 Harris Corporation Dynamic computer network with variable identity parameters
US8935780B2 (en) 2012-02-09 2015-01-13 Harris Corporation Mission management for dynamic computer networks
US8812689B2 (en) * 2012-02-17 2014-08-19 The Boeing Company System and method for rotating a gateway address
US9154458B2 (en) * 2012-05-01 2015-10-06 Harris Corporation Systems and methods for implementing moving target technology in legacy hardware
US9075992B2 (en) * 2012-05-01 2015-07-07 Harris Corporation Systems and methods for identifying, deterring and/or delaying attacks to a network using shadow networking techniques
US8966626B2 (en) 2012-05-01 2015-02-24 Harris Corporation Router for communicating data in a dynamic computer network
US9130907B2 (en) 2012-05-01 2015-09-08 Harris Corporation Switch for communicating data in a dynamic computer network
US8959573B2 (en) 2012-05-01 2015-02-17 Harris Corporation Noise, encryption, and decoys for communications in a dynamic computer network
US8935786B2 (en) 2012-05-01 2015-01-13 Harris Corporation Systems and methods for dynamically changing network states
US8898782B2 (en) 2012-05-01 2014-11-25 Harris Corporation Systems and methods for spontaneously configuring a computer network
US9122873B2 (en) 2012-09-14 2015-09-01 The Research Foundation For The State University Of New York Continuous run-time validation of program execution: a practical approach
US9069782B2 (en) 2012-10-01 2015-06-30 The Research Foundation For The State University Of New York System and method for security and privacy aware virtual machine checkpointing
US9113347B2 (en) 2012-12-05 2015-08-18 At&T Intellectual Property I, Lp Backhaul link for distributed antenna system
US10009065B2 (en) 2012-12-05 2018-06-26 At&T Intellectual Property I, L.P. Backhaul link for distributed antenna system
US9525524B2 (en) 2013-05-31 2016-12-20 At&T Intellectual Property I, L.P. Remote distributed antenna system
US9999038B2 (en) 2013-05-31 2018-06-12 At&T Intellectual Property I, L.P. Remote distributed antenna system
KR101538762B1 (ko) * 2013-06-12 2015-07-24 서정환 캡슐화 프로토콜을 이용하여 클라이언트의 ｉｐ 주소를 서버로 전송하는 중계 시스템 및 방법
US9203798B2 (en) 2013-07-18 2015-12-01 Empire Technology Development Llc Time based IP address hopping
US9503324B2 (en) 2013-11-05 2016-11-22 Harris Corporation Systems and methods for enterprise mission management of a computer network
US8897697B1 (en) 2013-11-06 2014-11-25 At&T Intellectual Property I, Lp Millimeter-wave surface-wave communications
US10454783B2 (en) 2014-02-05 2019-10-22 Apple Inc. Accessory management system using environment model
US10177933B2 (en) 2014-02-05 2019-01-08 Apple Inc. Controller networks for an accessory management system
US9338183B2 (en) 2013-11-18 2016-05-10 Harris Corporation Session hopping
US9264496B2 (en) 2013-11-18 2016-02-16 Harris Corporation Session hopping
US10122708B2 (en) 2013-11-21 2018-11-06 Harris Corporation Systems and methods for deployment of mission plans using access control technologies
CN105940644B (zh) * 2013-12-02 2019-11-12 阿卡麦科技公司 在保持端对端数据安全的同时具有分发优化的虚拟专用网络(vpn)即服务
US9813343B2 (en) 2013-12-03 2017-11-07 Akamai Technologies, Inc. Virtual private network (VPN)-as-a-service with load-balanced tunnel endpoints
US9209902B2 (en) 2013-12-10 2015-12-08 At&T Intellectual Property I, L.P. Quasi-optical coupler
US9462001B2 (en) * 2014-01-15 2016-10-04 Cisco Technology, Inc. Computer network access control
US9641430B2 (en) * 2014-01-22 2017-05-02 Cisco Technology, Inc. Verifying data plane paths based on a validated secure control plane
US10044609B2 (en) * 2014-02-04 2018-08-07 Fastly, Inc. Communication path selection for content delivery
EP3313050B1 (en) 2014-02-05 2019-01-23 Apple Inc. Uniform communication protocols for communication between controllers and accessories
US20150236752A1 (en) * 2014-02-20 2015-08-20 Raytheon Bbn Technologies Corp. Method for selection of unique next-time-interval internet protocol address and port
GB2512746B (en) 2014-02-25 2015-03-11 Cambridge Silicon Radio Ltd Thwarting traffic analysis
GB2515853B (en) 2014-02-25 2015-08-19 Cambridge Silicon Radio Ltd Latency mitigation
US11301492B1 (en) * 2014-03-20 2022-04-12 Amazon Technologies, Inc. Network address range storage and retrieval
JP6313646B2 (ja) 2014-04-24 2018-04-18 日立オートモティブシステムズ株式会社 外界認識装置
WO2015184382A2 (en) * 2014-05-30 2015-12-03 Apple Inc. Controller networks for an accessory management system
TWI576755B (zh) * 2014-05-30 2017-04-01 蘋果公司 可在一第一控制器器件中執行之方法，控制器器件，電腦可讀儲存媒體
JP2015233173A (ja) * 2014-06-09 2015-12-24 Ｎｅｃエンジニアリング株式会社 通信システム、通信装置及び通信方法
US9424064B2 (en) * 2014-08-01 2016-08-23 Raytheon Bbn Technologies Corp. Adaptor implementation for internet protocol address and port hopping
US9692101B2 (en) 2014-08-26 2017-06-27 At&T Intellectual Property I, L.P. Guided wave couplers for coupling electromagnetic waves between a waveguide surface and a surface of a wire
US9768833B2 (en) 2014-09-15 2017-09-19 At&T Intellectual Property I, L.P. Method and apparatus for sensing a condition in a transmission medium of electromagnetic waves
US10063280B2 (en) 2014-09-17 2018-08-28 At&T Intellectual Property I, L.P. Monitoring and mitigating conditions in a communication network
US9628854B2 (en) 2014-09-29 2017-04-18 At&T Intellectual Property I, L.P. Method and apparatus for distributing content in a communication network
US9615269B2 (en) 2014-10-02 2017-04-04 At&T Intellectual Property I, L.P. Method and apparatus that provides fault tolerance in a communication network
US9685992B2 (en) 2014-10-03 2017-06-20 At&T Intellectual Property I, L.P. Circuit panel network and methods thereof
US9503189B2 (en) 2014-10-10 2016-11-22 At&T Intellectual Property I, L.P. Method and apparatus for arranging communication sessions in a communication system
US9973299B2 (en) 2014-10-14 2018-05-15 At&T Intellectual Property I, L.P. Method and apparatus for adjusting a mode of communication in a communication network
US9762289B2 (en) 2014-10-14 2017-09-12 At&T Intellectual Property I, L.P. Method and apparatus for transmitting or receiving signals in a transportation system
US9769020B2 (en) 2014-10-21 2017-09-19 At&T Intellectual Property I, L.P. Method and apparatus for responding to events affecting communications in a communication network
US9653770B2 (en) 2014-10-21 2017-05-16 At&T Intellectual Property I, L.P. Guided wave coupler, coupling module and methods for use therewith
JP2016082521A (ja) * 2014-10-21 2016-05-16 富士通株式会社 情報処理装置、及び、情報処理方法
US9577306B2 (en) 2014-10-21 2017-02-21 At&T Intellectual Property I, L.P. Guided-wave transmission device and methods for use therewith
US9520945B2 (en) 2014-10-21 2016-12-13 At&T Intellectual Property I, L.P. Apparatus for providing communication services and methods thereof
US9564947B2 (en) 2014-10-21 2017-02-07 At&T Intellectual Property I, L.P. Guided-wave transmission device with diversity and methods for use therewith
US9312919B1 (en) 2014-10-21 2016-04-12 At&T Intellectual Property I, Lp Transmission device with impairment compensation and methods for use therewith
US9627768B2 (en) 2014-10-21 2017-04-18 At&T Intellectual Property I, L.P. Guided-wave transmission device with non-fundamental mode propagation and methods for use therewith
US9780834B2 (en) 2014-10-21 2017-10-03 At&T Intellectual Property I, L.P. Method and apparatus for transmitting electromagnetic waves
US20160285834A1 (en) * 2014-11-10 2016-09-29 Qualcomm Incorporated Techniques for encrypting fields of a frame header for wi-fi privacy
US10243784B2 (en) 2014-11-20 2019-03-26 At&T Intellectual Property I, L.P. System for generating topology information and methods thereof
US9997819B2 (en) 2015-06-09 2018-06-12 At&T Intellectual Property I, L.P. Transmission medium and method for facilitating propagation of electromagnetic waves via a core
US9654173B2 (en) 2014-11-20 2017-05-16 At&T Intellectual Property I, L.P. Apparatus for powering a communication device and methods thereof
US10340573B2 (en) 2016-10-26 2019-07-02 At&T Intellectual Property I, L.P. Launcher with cylindrical coupling device and methods for use therewith
US9680670B2 (en) 2014-11-20 2017-06-13 At&T Intellectual Property I, L.P. Transmission device with channel equalization and control and methods for use therewith
US9954287B2 (en) 2014-11-20 2018-04-24 At&T Intellectual Property I, L.P. Apparatus for converting wireless signals and electromagnetic waves and methods thereof
US9742462B2 (en) 2014-12-04 2017-08-22 At&T Intellectual Property I, L.P. Transmission medium and communication interfaces and methods for use therewith
US9544006B2 (en) 2014-11-20 2017-01-10 At&T Intellectual Property I, L.P. Transmission device with mode division multiplexing and methods for use therewith
US10009067B2 (en) 2014-12-04 2018-06-26 At&T Intellectual Property I, L.P. Method and apparatus for configuring a communication interface
US9800327B2 (en) 2014-11-20 2017-10-24 At&T Intellectual Property I, L.P. Apparatus for controlling operations of a communication device and methods thereof
US9461706B1 (en) 2015-07-31 2016-10-04 At&T Intellectual Property I, Lp Method and apparatus for exchanging communication signals
EP3038313A1 (de) * 2014-12-23 2016-06-29 Siemens Aktiengesellschaft Verfahren zur Übertragung von Daten in einem Automatisierungssystem mit einer verbesserten Absicherung der Daten gegen unberechtigtes Ausspähen, elektronisches Gerät zur Ausführung des Verfahrens und Automatisierungssystem mit zumindest einem derartigen Gerät
US10333696B2 (en) 2015-01-12 2019-06-25 X-Prime, Inc. Systems and methods for implementing an efficient, scalable homomorphic transformation of encrypted data with minimal data expansion and improved processing efficiency
US10144036B2 (en) 2015-01-30 2018-12-04 At&T Intellectual Property I, L.P. Method and apparatus for mitigating interference affecting a propagation of electromagnetic waves guided by a transmission medium
US10206170B2 (en) 2015-02-05 2019-02-12 Apple Inc. Dynamic connection path detection and selection for wireless controllers and accessories
US9973516B2 (en) * 2015-02-13 2018-05-15 International Business Machines Corporation Traffic shape obfuscation when using an encrypted network connection
US9876570B2 (en) 2015-02-20 2018-01-23 At&T Intellectual Property I, Lp Guided-wave transmission device with non-fundamental mode propagation and methods for use therewith
US9749013B2 (en) 2015-03-17 2017-08-29 At&T Intellectual Property I, L.P. Method and apparatus for reducing attenuation of electromagnetic waves guided by a transmission medium
US9705561B2 (en) 2015-04-24 2017-07-11 At&T Intellectual Property I, L.P. Directional coupling device and methods for use therewith
US10224981B2 (en) 2015-04-24 2019-03-05 At&T Intellectual Property I, Lp Passive electrical coupling device and methods for use therewith
US9948354B2 (en) 2015-04-28 2018-04-17 At&T Intellectual Property I, L.P. Magnetic coupling device with reflective plate and methods for use therewith
US9793954B2 (en) 2015-04-28 2017-10-17 At&T Intellectual Property I, L.P. Magnetic coupling device and methods for use therewith
US9490869B1 (en) 2015-05-14 2016-11-08 At&T Intellectual Property I, L.P. Transmission medium having multiple cores and methods for use therewith
US9871282B2 (en) 2015-05-14 2018-01-16 At&T Intellectual Property I, L.P. At least one transmission medium having a dielectric surface that is covered at least in part by a second dielectric
US9748626B2 (en) 2015-05-14 2017-08-29 At&T Intellectual Property I, L.P. Plurality of cables having different cross-sectional shapes which are bundled together to form a transmission medium
US10650940B2 (en) 2015-05-15 2020-05-12 At&T Intellectual Property I, L.P. Transmission medium having a conductive material and methods for use therewith
US10679767B2 (en) 2015-05-15 2020-06-09 At&T Intellectual Property I, L.P. Transmission medium having a conductive material and methods for use therewith
US9917341B2 (en) 2015-05-27 2018-03-13 At&T Intellectual Property I, L.P. Apparatus and method for launching electromagnetic waves and for modifying radial dimensions of the propagating electromagnetic waves
US9912381B2 (en) 2015-06-03 2018-03-06 At&T Intellectual Property I, Lp Network termination and methods for use therewith
US10103801B2 (en) 2015-06-03 2018-10-16 At&T Intellectual Property I, L.P. Host node device and methods for use therewith
US10348391B2 (en) 2015-06-03 2019-07-09 At&T Intellectual Property I, L.P. Client node device with frequency conversion and methods for use therewith
US10812174B2 (en) 2015-06-03 2020-10-20 At&T Intellectual Property I, L.P. Client node device and methods for use therewith
US9866309B2 (en) 2015-06-03 2018-01-09 At&T Intellectual Property I, Lp Host node device and methods for use therewith
US10154493B2 (en) 2015-06-03 2018-12-11 At&T Intellectual Property I, L.P. Network termination and methods for use therewith
US9913139B2 (en) 2015-06-09 2018-03-06 At&T Intellectual Property I, L.P. Signal fingerprinting for authentication of communicating devices
US10142086B2 (en) 2015-06-11 2018-11-27 At&T Intellectual Property I, L.P. Repeater and methods for use therewith
US9608692B2 (en) 2015-06-11 2017-03-28 At&T Intellectual Property I, L.P. Repeater and methods for use therewith
US9820146B2 (en) 2015-06-12 2017-11-14 At&T Intellectual Property I, L.P. Method and apparatus for authentication and identity management of communicating devices
US9667317B2 (en) 2015-06-15 2017-05-30 At&T Intellectual Property I, L.P. Method and apparatus for providing security using network traffic adjustments
US9509415B1 (en) 2015-06-25 2016-11-29 At&T Intellectual Property I, L.P. Methods and apparatus for inducing a fundamental wave mode on a transmission medium
US9640850B2 (en) 2015-06-25 2017-05-02 At&T Intellectual Property I, L.P. Methods and apparatus for inducing a non-fundamental wave mode on a transmission medium
US9865911B2 (en) 2015-06-25 2018-01-09 At&T Intellectual Property I, L.P. Waveguide system for slot radiating first electromagnetic waves that are combined into a non-fundamental wave mode second electromagnetic wave on a transmission medium
US10148016B2 (en) 2015-07-14 2018-12-04 At&T Intellectual Property I, L.P. Apparatus and methods for communicating utilizing an antenna array
US10044409B2 (en) 2015-07-14 2018-08-07 At&T Intellectual Property I, L.P. Transmission medium and methods for use therewith
US9836957B2 (en) 2015-07-14 2017-12-05 At&T Intellectual Property I, L.P. Method and apparatus for communicating with premises equipment
US10341142B2 (en) 2015-07-14 2019-07-02 At&T Intellectual Property I, L.P. Apparatus and methods for generating non-interfering electromagnetic waves on an uninsulated conductor
US9882257B2 (en) 2015-07-14 2018-01-30 At&T Intellectual Property I, L.P. Method and apparatus for launching a wave mode that mitigates interference
US9628116B2 (en) 2015-07-14 2017-04-18 At&T Intellectual Property I, L.P. Apparatus and methods for transmitting wireless signals
US9853342B2 (en) 2015-07-14 2017-12-26 At&T Intellectual Property I, L.P. Dielectric transmission medium connector and methods for use therewith
US10320586B2 (en) 2015-07-14 2019-06-11 At&T Intellectual Property I, L.P. Apparatus and methods for generating non-interfering electromagnetic waves on an insulated transmission medium
US10170840B2 (en) 2015-07-14 2019-01-01 At&T Intellectual Property I, L.P. Apparatus and methods for sending or receiving electromagnetic signals
US10205655B2 (en) 2015-07-14 2019-02-12 At&T Intellectual Property I, L.P. Apparatus and methods for communicating utilizing an antenna array and multiple communication paths
US9847566B2 (en) 2015-07-14 2017-12-19 At&T Intellectual Property I, L.P. Method and apparatus for adjusting a field of a signal to mitigate interference
US10033107B2 (en) 2015-07-14 2018-07-24 At&T Intellectual Property I, L.P. Method and apparatus for coupling an antenna to a device
US10033108B2 (en) 2015-07-14 2018-07-24 At&T Intellectual Property I, L.P. Apparatus and methods for generating an electromagnetic wave having a wave mode that mitigates interference
US9722318B2 (en) 2015-07-14 2017-08-01 At&T Intellectual Property I, L.P. Method and apparatus for coupling an antenna to a device
US9608740B2 (en) 2015-07-15 2017-03-28 At&T Intellectual Property I, L.P. Method and apparatus for launching a wave mode that mitigates interference
US10090606B2 (en) 2015-07-15 2018-10-02 At&T Intellectual Property I, L.P. Antenna system with dielectric array and methods for use therewith
US9793951B2 (en) 2015-07-15 2017-10-17 At&T Intellectual Property I, L.P. Method and apparatus for launching a wave mode that mitigates interference
US9871283B2 (en) 2015-07-23 2018-01-16 At&T Intellectual Property I, Lp Transmission medium having a dielectric core comprised of plural members connected by a ball and socket configuration
US9948333B2 (en) 2015-07-23 2018-04-17 At&T Intellectual Property I, L.P. Method and apparatus for wireless communications to mitigate interference
US9912027B2 (en) 2015-07-23 2018-03-06 At&T Intellectual Property I, L.P. Method and apparatus for exchanging communication signals
US9749053B2 (en) 2015-07-23 2017-08-29 At&T Intellectual Property I, L.P. Node device, repeater and methods for use therewith
US10784670B2 (en) 2015-07-23 2020-09-22 At&T Intellectual Property I, L.P. Antenna support for aligning an antenna
US10020587B2 (en) 2015-07-31 2018-07-10 At&T Intellectual Property I, L.P. Radial antenna and methods for use therewith
US9735833B2 (en) 2015-07-31 2017-08-15 At&T Intellectual Property I, L.P. Method and apparatus for communications management in a neighborhood network
US9967173B2 (en) 2015-07-31 2018-05-08 At&T Intellectual Property I, L.P. Method and apparatus for authentication and identity management of communicating devices
JP6480291B2 (ja) * 2015-08-28 2019-03-06 株式会社日立製作所 通信装置、送信装置及び受信装置
US9904535B2 (en) 2015-09-14 2018-02-27 At&T Intellectual Property I, L.P. Method and apparatus for distributing software
US9705571B2 (en) 2015-09-16 2017-07-11 At&T Intellectual Property I, L.P. Method and apparatus for use with a radio distributed antenna system
US10009063B2 (en) 2015-09-16 2018-06-26 At&T Intellectual Property I, L.P. Method and apparatus for use with a radio distributed antenna system having an out-of-band reference signal
US10009901B2 (en) 2015-09-16 2018-06-26 At&T Intellectual Property I, L.P. Method, apparatus, and computer-readable storage medium for managing utilization of wireless resources between base stations
US10136434B2 (en) 2015-09-16 2018-11-20 At&T Intellectual Property I, L.P. Method and apparatus for use with a radio distributed antenna system having an ultra-wideband control channel
US10079661B2 (en) 2015-09-16 2018-09-18 At&T Intellectual Property I, L.P. Method and apparatus for use with a radio distributed antenna system having a clock reference
US10051629B2 (en) 2015-09-16 2018-08-14 At&T Intellectual Property I, L.P. Method and apparatus for use with a radio distributed antenna system having an in-band reference signal
US9769128B2 (en) 2015-09-28 2017-09-19 At&T Intellectual Property I, L.P. Method and apparatus for encryption of communications over a network
US9729197B2 (en) 2015-10-01 2017-08-08 At&T Intellectual Property I, L.P. Method and apparatus for communicating network management traffic over a network
US10074890B2 (en) 2015-10-02 2018-09-11 At&T Intellectual Property I, L.P. Communication device and antenna with integrated light assembly
US9876264B2 (en) 2015-10-02 2018-01-23 At&T Intellectual Property I, Lp Communication system, guided wave switch and methods for use therewith
US9882277B2 (en) 2015-10-02 2018-01-30 At&T Intellectual Property I, Lp Communication device and antenna assembly with actuated gimbal mount
US10665942B2 (en) 2015-10-16 2020-05-26 At&T Intellectual Property I, L.P. Method and apparatus for adjusting wireless communications
US10051483B2 (en) 2015-10-16 2018-08-14 At&T Intellectual Property I, L.P. Method and apparatus for directing wireless signals
US10355367B2 (en) 2015-10-16 2019-07-16 At&T Intellectual Property I, L.P. Antenna structure for exchanging wireless signals
US10084754B2 (en) 2015-12-11 2018-09-25 Microsoft Technology Licensing, Llc Virtual private network aggregation
US10044626B2 (en) 2015-12-24 2018-08-07 Intel Corporation Reliable out-of order end-to-end protocol with robust window state overflow management and a multi-node system using same
US9912419B1 (en) 2016-08-24 2018-03-06 At&T Intellectual Property I, L.P. Method and apparatus for managing a fault in a distributed antenna system
US9860075B1 (en) 2016-08-26 2018-01-02 At&T Intellectual Property I, L.P. Method and communication node for broadband distribution
US10291311B2 (en) 2016-09-09 2019-05-14 At&T Intellectual Property I, L.P. Method and apparatus for mitigating a fault in a distributed antenna system
US11032819B2 (en) 2016-09-15 2021-06-08 At&T Intellectual Property I, L.P. Method and apparatus for use with a radio distributed antenna system having a control channel reference signal
US10340600B2 (en) 2016-10-18 2019-07-02 At&T Intellectual Property I, L.P. Apparatus and methods for launching guided waves via plural waveguide systems
US10135147B2 (en) 2016-10-18 2018-11-20 At&T Intellectual Property I, L.P. Apparatus and methods for launching guided waves via an antenna
US10135146B2 (en) 2016-10-18 2018-11-20 At&T Intellectual Property I, L.P. Apparatus and methods for launching guided waves via circuits
US10374316B2 (en) 2016-10-21 2019-08-06 At&T Intellectual Property I, L.P. System and dielectric antenna with non-uniform dielectric
US9991580B2 (en) 2016-10-21 2018-06-05 At&T Intellectual Property I, L.P. Launcher and coupling system for guided wave mode cancellation
US10811767B2 (en) 2016-10-21 2020-10-20 At&T Intellectual Property I, L.P. System and dielectric antenna with convex dielectric radome
US9876605B1 (en) 2016-10-21 2018-01-23 At&T Intellectual Property I, L.P. Launcher and coupling system to support desired guided wave mode
US10312567B2 (en) 2016-10-26 2019-06-04 At&T Intellectual Property I, L.P. Launcher with planar strip antenna and methods for use therewith
US10224634B2 (en) 2016-11-03 2019-03-05 At&T Intellectual Property I, L.P. Methods and apparatus for adjusting an operational characteristic of an antenna
US10291334B2 (en) 2016-11-03 2019-05-14 At&T Intellectual Property I, L.P. System for detecting a fault in a communication system
US10225025B2 (en) 2016-11-03 2019-03-05 At&T Intellectual Property I, L.P. Method and apparatus for detecting a fault in a communication system
US10498044B2 (en) 2016-11-03 2019-12-03 At&T Intellectual Property I, L.P. Apparatus for configuring a surface of an antenna
US10340601B2 (en) 2016-11-23 2019-07-02 At&T Intellectual Property I, L.P. Multi-antenna system and methods for use therewith
US10535928B2 (en) 2016-11-23 2020-01-14 At&T Intellectual Property I, L.P. Antenna system and methods for use therewith
US10090594B2 (en) 2016-11-23 2018-10-02 At&T Intellectual Property I, L.P. Antenna system having structural configurations for assembly
US10178445B2 (en) 2016-11-23 2019-01-08 At&T Intellectual Property I, L.P. Methods, devices, and systems for load balancing between a plurality of waveguides
US10340603B2 (en) 2016-11-23 2019-07-02 At&T Intellectual Property I, L.P. Antenna system having shielded structural configurations for assembly
US10305190B2 (en) 2016-12-01 2019-05-28 At&T Intellectual Property I, L.P. Reflecting dielectric antenna system and methods for use therewith
US10361489B2 (en) 2016-12-01 2019-07-23 At&T Intellectual Property I, L.P. Dielectric dish antenna system and methods for use therewith
US10637149B2 (en) 2016-12-06 2020-04-28 At&T Intellectual Property I, L.P. Injection molded dielectric antenna and methods for use therewith
US10382976B2 (en) 2016-12-06 2019-08-13 At&T Intellectual Property I, L.P. Method and apparatus for managing wireless communications based on communication paths and network device positions
US10819035B2 (en) 2016-12-06 2020-10-27 At&T Intellectual Property I, L.P. Launcher with helical antenna and methods for use therewith
US10135145B2 (en) 2016-12-06 2018-11-20 At&T Intellectual Property I, L.P. Apparatus and methods for generating an electromagnetic wave along a transmission medium
US10694379B2 (en) 2016-12-06 2020-06-23 At&T Intellectual Property I, L.P. Waveguide system with device-based authentication and methods for use therewith
US10727599B2 (en) 2016-12-06 2020-07-28 At&T Intellectual Property I, L.P. Launcher with slot antenna and methods for use therewith
US10439675B2 (en) 2016-12-06 2019-10-08 At&T Intellectual Property I, L.P. Method and apparatus for repeating guided wave communication signals
US10020844B2 (en) 2016-12-06 2018-07-10 T&T Intellectual Property I, L.P. Method and apparatus for broadcast communication via guided waves
US9927517B1 (en) 2016-12-06 2018-03-27 At&T Intellectual Property I, L.P. Apparatus and methods for sensing rainfall
US10755542B2 (en) 2016-12-06 2020-08-25 At&T Intellectual Property I, L.P. Method and apparatus for surveillance via guided wave communication
US10326494B2 (en) 2016-12-06 2019-06-18 At&T Intellectual Property I, L.P. Apparatus for measurement de-embedding and methods for use therewith
US10446936B2 (en) 2016-12-07 2019-10-15 At&T Intellectual Property I, L.P. Multi-feed dielectric antenna system and methods for use therewith
US10027397B2 (en) 2016-12-07 2018-07-17 At&T Intellectual Property I, L.P. Distributed antenna system and methods for use therewith
US10168695B2 (en) 2016-12-07 2019-01-01 At&T Intellectual Property I, L.P. Method and apparatus for controlling an unmanned aircraft
US10139820B2 (en) 2016-12-07 2018-11-27 At&T Intellectual Property I, L.P. Method and apparatus for deploying equipment of a communication system
US9893795B1 (en) 2016-12-07 2018-02-13 At&T Intellectual Property I, Lp Method and repeater for broadband distribution
US10389029B2 (en) 2016-12-07 2019-08-20 At&T Intellectual Property I, L.P. Multi-feed dielectric antenna system with core selection and methods for use therewith
US10359749B2 (en) 2016-12-07 2019-07-23 At&T Intellectual Property I, L.P. Method and apparatus for utilities management via guided wave communication
US10547348B2 (en) 2016-12-07 2020-01-28 At&T Intellectual Property I, L.P. Method and apparatus for switching transmission mediums in a communication system
US10243270B2 (en) 2016-12-07 2019-03-26 At&T Intellectual Property I, L.P. Beam adaptive multi-feed dielectric antenna system and methods for use therewith
US10777873B2 (en) 2016-12-08 2020-09-15 At&T Intellectual Property I, L.P. Method and apparatus for mounting network devices
US10601494B2 (en) 2016-12-08 2020-03-24 At&T Intellectual Property I, L.P. Dual-band communication device and method for use therewith
US9998870B1 (en) 2016-12-08 2018-06-12 At&T Intellectual Property I, L.P. Method and apparatus for proximity sensing
US10389037B2 (en) 2016-12-08 2019-08-20 At&T Intellectual Property I, L.P. Apparatus and methods for selecting sections of an antenna array and use therewith
US10069535B2 (en) 2016-12-08 2018-09-04 At&T Intellectual Property I, L.P. Apparatus and methods for launching electromagnetic waves having a certain electric field structure
US10326689B2 (en) 2016-12-08 2019-06-18 At&T Intellectual Property I, L.P. Method and system for providing alternative communication paths
US10916969B2 (en) 2016-12-08 2021-02-09 At&T Intellectual Property I, L.P. Method and apparatus for providing power using an inductive coupling
US10938108B2 (en) 2016-12-08 2021-03-02 At&T Intellectual Property I, L.P. Frequency selective multi-feed dielectric antenna system and methods for use therewith
US9911020B1 (en) 2016-12-08 2018-03-06 At&T Intellectual Property I, L.P. Method and apparatus for tracking via a radio frequency identification device
US10530505B2 (en) 2016-12-08 2020-01-07 At&T Intellectual Property I, L.P. Apparatus and methods for launching electromagnetic waves along a transmission medium
US10411356B2 (en) 2016-12-08 2019-09-10 At&T Intellectual Property I, L.P. Apparatus and methods for selectively targeting communication devices with an antenna array
US10103422B2 (en) 2016-12-08 2018-10-16 At&T Intellectual Property I, L.P. Method and apparatus for mounting network devices
US10264586B2 (en) 2016-12-09 2019-04-16 At&T Mobility Ii Llc Cloud-based packet controller and methods for use therewith
US9838896B1 (en) 2016-12-09 2017-12-05 At&T Intellectual Property I, L.P. Method and apparatus for assessing network coverage
US10340983B2 (en) 2016-12-09 2019-07-02 At&T Intellectual Property I, L.P. Method and apparatus for surveying remote sites via guided wave communications
JP6593354B2 (ja) * 2017-01-16 2019-10-23 株式会社デンソー 衝突回避装置
US9973940B1 (en) 2017-02-27 2018-05-15 At&T Intellectual Property I, L.P. Apparatus and methods for dynamic impedance matching of a guided wave launcher
US10298293B2 (en) 2017-03-13 2019-05-21 At&T Intellectual Property I, L.P. Apparatus of communication utilizing wireless network devices
US11172016B2 (en) 2017-03-30 2021-11-09 Intel Corporation Device, method and system to enforce concurrency limits of a target node within a network fabric
US10496508B2 (en) 2017-06-02 2019-12-03 Apple Inc. Accessory communication control
FR3072238B1 (fr) * 2017-10-10 2019-09-27 Commissariat A L'energie Atomique Et Aux Energies Alternatives Dispositif et procede de transmission de donnees
RU2666306C1 (ru) * 2017-12-27 2018-09-06 федеральное государственное автономное образовательное учреждение высшего образования "Санкт-Петербургский политехнический университет Петра Великого" (ФГАОУ ВО "СПбПУ") Способ управления связностью одноранговой межмашинной сети передачи данных
DE102018203949A1 (de) * 2018-03-15 2019-09-19 Bayerische Motoren Werke Aktiengesellschaft Verfahren und Vorrichtungen zum Senden und Identifizieren von Funkkennungen
GB201807835D0 (en) 2018-05-15 2018-06-27 Nchain Holdings Ltd Computer-implemented system and method
US10595073B2 (en) 2018-06-03 2020-03-17 Apple Inc. Techniques for authorizing controller devices
US11805009B2 (en) 2018-06-03 2023-10-31 Apple Inc. Configuring accessory network connections
AU2019301150A1 (en) 2018-07-10 2020-12-24 Listat Ltd. Decentralized cybersecure privacy network for cloud communication and global e-commerce
US10841078B2 (en) 2018-07-26 2020-11-17 International Business Machines Corporation Encryption key block generation with barrier descriptors
US11777913B2 (en) * 2018-12-04 2023-10-03 Journey.ai Generating reports from information within a zero-knowledge data management network
JP7218003B2 (ja) 2019-01-31 2023-02-06 コネクトフリー株式会社 データ送信方法、通信処理方法、装置、および通信処理プログラム
US11683298B2 (en) * 2019-02-27 2023-06-20 Kobil Gmbh Secure messaging
US11570100B2 (en) * 2019-04-25 2023-01-31 Advanced New Technologies Co., Ltd. Data processing method, apparatus, medium and device
US11263333B2 (en) 2019-04-25 2022-03-01 International Business Machines Corporation Multi-subject device access authorization
EP3942398A4 (en) 2019-05-23 2023-04-05 Hewlett Packard Enterprise Development LP SYSTEM AND METHOD FOR FACILITATING DATA REQUEST MANAGEMENT IN A NETWORK INTERFACE (NIC) CONTROLLER
US20210037045A1 (en) * 2019-07-31 2021-02-04 Abb Schweiz Ag System and method for cyber-secure communications
US11223956B2 (en) * 2019-09-27 2022-01-11 Apple Inc. Dynamic data sequence puncturing
CN111291078B (zh) * 2020-01-17 2021-02-02 武汉思普崚技术有限公司 一种域名匹配检测方法及装置
CN113542197A (zh) 2020-04-17 2021-10-22 西安西电捷通无线网络通信股份有限公司 一种节点间保密通信方法及网络节点
US10972436B1 (en) * 2020-10-24 2021-04-06 360 It, Uab System and method for session affinity in proxy media routing
WO2022101087A1 (en) * 2020-11-12 2022-05-19 Telefonaktiebolaget Lm Ericsson (Publ) Obscured device identity in wireless transmissions
CN112615866B (zh) * 2020-12-22 2022-07-05 南京易安联网络技术有限公司 Tcp连接的预认证方法、装置和系统
CN117354078B (zh) * 2023-12-06 2024-02-09 深圳市千岩科技有限公司 智能家电群控控制与响应方法及其装置、设备、介质

Family Cites Families (321)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US2895502A (en) * 1955-10-20 1959-07-21 Manning Maxwell & Moore Inc Automatic process control system
US4405829A (en) 1977-12-14 1983-09-20 Massachusetts Institute Of Technology Cryptographic communications system and method
DE3463261D1 (en) 1983-12-28 1987-05-27 Sigma Tau Ind Farmaceuti Salts of l-carnitine and alkanoyl l-carnitines and process for preparing same
US4761334A (en) 1984-09-21 1988-08-02 Kabushiki Kaisha Toshiba Magnetic recording medium
US4677434A (en) * 1984-10-17 1987-06-30 Lotus Information Network Corp. Access control system for transmitting data from a central station to a plurality of receiving stations and method therefor
US4885778A (en) 1984-11-30 1989-12-05 Weiss Kenneth P Method and apparatus for synchronizing generation of separate, free running, time dependent equipment
JPS62195949A (ja) * 1986-02-24 1987-08-29 Nec Corp パケツト転送方法
JPS62214744A (ja) * 1986-03-17 1987-09-21 Hitachi Ltd パケツト伝送方式
JPS62268225A (ja) * 1986-05-16 1987-11-20 Yanmar Diesel Engine Co Ltd デ−タ伝送システム
EP0287720B1 (en) 1987-04-22 1992-01-08 International Business Machines Corporation Management of cryptographic keys
US4933846A (en) 1987-04-24 1990-06-12 Network Systems Corporation Network communications adapter with dual interleaved memory banks servicing multiple processors
US4988990A (en) * 1989-05-09 1991-01-29 Rosemount Inc. Dual master implied token communication system
US5007051A (en) 1987-09-30 1991-04-09 Hewlett-Packard Company Link layer protocol and apparatus for data communication
US4920484A (en) * 1988-10-05 1990-04-24 Yale University Multiprocessor/memory interconnection network wherein messages sent through the network to the same memory are combined
US4952930A (en) 1988-11-18 1990-08-28 International Business Machines Corp. Multipath hierarchical network
US5048087A (en) 1989-02-03 1991-09-10 Racal Data Communications Inc. Key management for encrypted packet based networks
US5412730A (en) 1989-10-06 1995-05-02 Telequip Corporation Encrypted data transmission system employing means for randomly altering the encryption keys
NL9000424A (nl) * 1990-02-22 1991-09-16 Philips Nv Overdrachtsysteem voor gedigitaliseerde televisiebeelden.
US5204961A (en) 1990-06-25 1993-04-20 Digital Equipment Corporation Computer network operating with multilevel hierarchical security with selectable common trust realms and corresponding security protocols
US5070528A (en) 1990-06-29 1991-12-03 Digital Equipment Corporation Generic encryption technique for communication networks
JP2870163B2 (ja) 1990-09-07 1999-03-10 松下電器産業株式会社 認証機能付き鍵配送方式
US5367643A (en) 1991-02-06 1994-11-22 International Business Machines Corporation Generic high bandwidth adapter having data packet memory configured in three level hierarchy for temporary storage of variable length data packets
JPH04363941A (ja) * 1991-02-18 1992-12-16 Nippon Telegr & Teleph Corp <Ntt> 非同期転送モード通信における盗聴防止方法
US5654695A (en) * 1991-02-22 1997-08-05 International Business Machines Corporation Multi-function network
JPH04117826U (ja) 1991-04-05 1992-10-21 沖電気工業株式会社 トレー搬送装置
DE4119573A1 (de) * 1991-06-14 1992-12-17 Standard Elektrik Lorenz Ag Verfahren zur ermittlung einer temporaeren nummer (tmsi) in einer teilnehmerdatenbank fuer einen teilnehmer
US5164988A (en) 1991-10-31 1992-11-17 International Business Machines Corporation Method to establish and enforce a network cryptographic security policy in a public key cryptosystem
US5286047A (en) * 1991-11-21 1994-02-15 Kho Dick T Retainer for a suitcase wheel assembly
US5455861A (en) 1991-12-09 1995-10-03 At&T Corp. Secure telecommunications
US5243749A (en) * 1992-01-24 1993-09-14 Shultz William E Transmission pump removal tool
US5276735A (en) * 1992-04-17 1994-01-04 Secure Computing Corporation Data enclave and trusted path system
GB9209027D0 (en) 1992-04-25 1992-06-17 British Aerospace Multi purpose digital signal regenerative processing apparatus
US5329821A (en) * 1992-05-08 1994-07-19 Nusonics, Inc. Autoranging sonic flowmeter
US5311593A (en) * 1992-05-13 1994-05-10 Chipcom Corporation Security system for a network concentrator
US5303302A (en) 1992-06-18 1994-04-12 Digital Equipment Corporation Network packet receiver with buffer logic for reassembling interleaved data packets
US5349642A (en) * 1992-11-03 1994-09-20 Novell, Inc. Method and apparatus for authentication of client server communication
JP3232711B2 (ja) 1992-11-10 2001-11-26 松下電器産業株式会社 ルータ中継装置
US5329521A (en) * 1992-11-12 1994-07-12 Walsh Jeffrey R Method and apparatus for redundant local area network systems
US5341426A (en) * 1992-12-15 1994-08-23 Motorola, Inc. Cryptographic key management apparatus and method
US5444782A (en) 1993-03-09 1995-08-22 Uunet Technologies, Inc. Computer network encryption/decryption device
JPH06266670A (ja) 1993-03-11 1994-09-22 Fujitsu Ltd 暗号化仮想端末初期化装置
WO1994028486A1 (en) * 1993-05-21 1994-12-08 Candle Distributed Solutions, Inc. Method of selecting a server object to service a client object request within a network environment
JP3746785B2 (ja) * 1993-07-28 2006-02-15 ３コム コーポレイション 多重ネットワーク・アドレスを備えたネットワーク・ステーション
US5559883A (en) * 1993-08-19 1996-09-24 Chipcom Corporation Method and apparatus for secure data packet bus communication
US5689641A (en) 1993-10-01 1997-11-18 Vicor, Inc. Multimedia collaboration system arrangement for routing compressed AV signal through a participant site without decompressing the AV signal
US5581479A (en) 1993-10-15 1996-12-03 Image Telecommunications Corp. Information service control point, which uses different types of storage devices, which retrieves information as blocks of data, and which uses a trunk processor for transmitting information
US5420926A (en) 1994-01-05 1995-05-30 At&T Corp. Anonymous credit card transactions
US5787172A (en) * 1994-02-24 1998-07-28 The Merdan Group, Inc. Apparatus and method for establishing a cryptographic link between elements of a system
JP3186917B2 (ja) * 1994-03-25 2001-07-11 株式会社日立製作所 ローカルエリアネットワーク及びその送信順位自動決定方法
JPH07297817A (ja) 1994-04-27 1995-11-10 Sekisui Chem Co Ltd データ伝送方式
US5473692A (en) * 1994-09-07 1995-12-05 Intel Corporation Roving software license for a hardware agent
US5511122A (en) * 1994-06-03 1996-04-23 The United States Of America As Represented By The Secretary Of The Navy Intermediate network authentication
US5530758A (en) 1994-06-03 1996-06-25 Motorola, Inc. Operational methods for a secure node in a computer network
EP0765560A1 (en) * 1994-06-08 1997-04-02 Hughes Aircraft Company Apparatus and method for hybrid network access
US5416842A (en) 1994-06-10 1995-05-16 Sun Microsystems, Inc. Method and apparatus for key-management scheme for use with internet protocols at site firewalls
US5588060A (en) 1994-06-10 1996-12-24 Sun Microsystems, Inc. Method and apparatus for a key-management scheme for internet protocols
US5682480A (en) 1994-08-15 1997-10-28 Hitachi, Ltd. Parallel computer system for performing barrier synchronization by transferring the synchronization packet through a path which bypasses the packet buffer in response to an interrupt
US5548646A (en) * 1994-09-15 1996-08-20 Sun Microsystems, Inc. System for signatureless transmission and reception of data packets between computer networks
US5561669A (en) 1994-10-26 1996-10-01 Cisco Systems, Inc. Computer network switching system with expandable number of ports
US5623601A (en) 1994-11-18 1997-04-22 Milkway Networks Corporation Apparatus and method for providing a secure gateway for communication and data exchanges between networks
US5629984A (en) 1995-03-10 1997-05-13 Sun Microsystems, Inc. System and method for data security
US5802320A (en) 1995-05-18 1998-09-01 Sun Microsystems, Inc. System for packet filtering of data packets at a computer network interface
JPH0918473A (ja) 1995-06-29 1997-01-17 Mitsubishi Electric Corp データ伝送装置
JP3196999B2 (ja) * 1995-06-30 2001-08-06 日本電信電話株式会社 Ａｔｍ通信網および加入者交換機
JPH0934816A (ja) 1995-07-21 1997-02-07 Toshiba Corp 大規模ｉｐネットワーク
EP0852088B1 (de) * 1995-09-22 2000-12-27 Siemens Aktiengesellschaft Verfahren und schaltungsanordnung zur verarbeitung von nutzdaten
JP2988569B2 (ja) * 1995-09-25 1999-12-13 ノーリツ鋼機株式会社 フィルム収納体回収装置
US6108704A (en) 1995-09-25 2000-08-22 Netspeak Corporation Point-to-point internet protocol
US5689566A (en) 1995-10-24 1997-11-18 Nguyen; Minhtam C. Network with secure communications sessions
US5793763A (en) * 1995-11-03 1998-08-11 Cisco Technology, Inc. Security system for network address translation systems
US5764906A (en) * 1995-11-07 1998-06-09 Netword Llc Universal electronic resource denotation, request and delivery system
US5771239A (en) * 1995-11-17 1998-06-23 General Instrument Corporation Of Delaware Method and apparatus for modifying a transport packet stream to provide concatenated synchronization bytes at interleaver output
JP3688830B2 (ja) * 1995-11-30 2005-08-31 株式会社東芝 パケット転送方法及びパケット処理装置
US6571338B1 (en) * 1995-12-20 2003-05-27 Sun Microsystems Inc. Maintaining packet security in a computer network
US5812670A (en) 1995-12-28 1998-09-22 Micali; Silvio Traceable anonymous transactions
US5838794A (en) * 1996-01-11 1998-11-17 Teledyne Electronic Technologies Method and apparatus for inter-round mixing in iterated block substitution systems
US6055518A (en) 1996-02-01 2000-04-25 At&T Corporation Secure auction systems
US5781550A (en) 1996-02-02 1998-07-14 Digital Equipment Corporation Transparent and secure network gateway
US5898830A (en) 1996-10-17 1999-04-27 Network Engineering Software Firewall providing enhanced network security and user transparency
US5918018A (en) * 1996-02-09 1999-06-29 Secure Computing Corporation System and method for achieving network separation
US5740375A (en) * 1996-02-15 1998-04-14 Bay Networks, Inc. Forwarding internetwork packets by replacing the destination address
US5845091A (en) * 1996-02-15 1998-12-01 Bay Networks, Inc. Forwarding of internetwork packets to a destination network via a selected one of a plurality of paths
JPH09266475A (ja) 1996-03-28 1997-10-07 Hitachi Ltd アドレス情報管理装置およびネットワークシステム
JPH09270803A (ja) 1996-04-02 1997-10-14 Furukawa Electric Co Ltd:The 仮想ネットワーク構築方法
JP3268546B2 (ja) 1996-04-05 2002-03-25 日本電信電話株式会社 アドレス解決処理方法
DE59610895D1 (de) 1996-04-17 2004-02-19 Siemens Ag Steuerungseinrichtung im Intelligenten Netz
US5790548A (en) * 1996-04-18 1998-08-04 Bell Atlantic Network Services, Inc. Universal access multimedia data network
US6225993B1 (en) 1996-04-22 2001-05-01 Sun Microsystems, Inc. Video on demand applet method and apparatus for inclusion of motion video in multimedia documents
US5940393A (en) 1996-05-28 1999-08-17 Sprint Communications Co. L.P. Telecommunications system with a connection processing system
US5918013A (en) * 1996-06-03 1999-06-29 Webtv Networks, Inc. Method of transcoding documents in a network environment using a proxy server
US5889863A (en) 1996-06-17 1999-03-30 Verifone, Inc. System, method and article of manufacture for remote virtual point of sale processing utilizing a multichannel, extensible, flexible architecture
US6178409B1 (en) * 1996-06-17 2001-01-23 Verifone, Inc. System, method and article of manufacture for multiple-entry point virtual point of sale architecture
US5842040A (en) 1996-06-18 1998-11-24 Storage Technology Corporation Policy caching method and apparatus for use in a communication device based on contents of one data unit in a subset of related data units
US5822434A (en) 1996-06-19 1998-10-13 Sun Microsystems, Inc. Scheme to allow two computers on a network to upgrade from a non-secured to a secured session
US6058250A (en) 1996-06-19 2000-05-02 At&T Corp Bifurcated transaction system in which nonsensitive information is exchanged using a public network connection and sensitive information is exchanged after automatically configuring a private network connection
US6147976A (en) * 1996-06-24 2000-11-14 Cabletron Systems, Inc. Fast network layer packet filter
US5870610A (en) * 1996-06-28 1999-02-09 Siemens Business Communication Systems, Inc. Autoconfigurable method and system having automated downloading
US5867650A (en) * 1996-07-10 1999-02-02 Microsoft Corporation Out-of-band data transmission
US6754212B1 (en) 1996-07-12 2004-06-22 Hitachi, Ltd. Repeater and network system utililzing the same
JP3587633B2 (ja) 1996-10-18 2004-11-10 株式会社日立製作所 ネットワーク通信方法および装置
JPH1032610A (ja) 1996-07-12 1998-02-03 Nec Corp 移動データ通信における仮想私設網の構成方法
US6111883A (en) 1996-07-12 2000-08-29 Hitachi, Ltd. Repeater and network system utilizing the same
US5805820A (en) 1996-07-15 1998-09-08 At&T Corp. Method and apparatus for restricting access to private information in domain name systems by redirecting query requests
WO1998003923A1 (en) * 1996-07-21 1998-01-29 Ernestine, Llc World wide web bar code access system
US5757925A (en) * 1996-07-23 1998-05-26 Faybishenko; Yaroslav Secure platform independent cross-platform remote execution computer system and method
US5918019A (en) * 1996-07-29 1999-06-29 Cisco Technology, Inc. Virtual dial-up protocol for network communication
US5774660A (en) * 1996-08-05 1998-06-30 Resonate, Inc. World-wide-web server with delayed resource-binding for resource-based load balancing on a distributed resource multi-node network
JPH1070531A (ja) * 1996-08-26 1998-03-10 Brother Ind Ltd データ通信システムおよび受信装置
US6016504A (en) 1996-08-28 2000-01-18 Infospace.Com, Inc. Method and system for tracking the purchase of a product and services over the Internet
JP3662080B2 (ja) 1996-08-29 2005-06-22 Ｋｄｄｉ株式会社 ファイアウォール動的制御方法
US5884270A (en) 1996-09-06 1999-03-16 Walker Asset Management Limited Partnership Method and system for facilitating an employment search incorporating user-controlled anonymous communications
GB2337386B (en) 1996-09-09 2001-04-04 Dennis J Dupray Location of a mobile station
US5892903A (en) 1996-09-12 1999-04-06 Internet Security Systems, Inc. Method and apparatus for detecting and identifying security vulnerabilities in an open network computer communication system
US6003084A (en) 1996-09-13 1999-12-14 Secure Computing Corporation Secure network proxy for connecting entities
JP3537018B2 (ja) * 1996-09-17 2004-06-14 株式会社日立製作所 データ伝送方法および情報システム
GB2317792B (en) 1996-09-18 2001-03-28 Secure Computing Corp Virtual private network on application gateway
US5864535A (en) * 1996-09-18 1999-01-26 International Business Machines Corporation Network server having dynamic load balancing of messages in both inbound and outbound directions
US5950195A (en) 1996-09-18 1999-09-07 Secure Computing Corporation Generalized security policy management system and method
EP0836306B1 (en) * 1996-10-10 2012-07-04 Hewlett-Packard Company (a Delaware Corporation) System providing for multiple virtual circuits between two network entities
US6101543A (en) 1996-10-25 2000-08-08 Digital Equipment Corporation Pseudo network adapter for frame capture, encapsulation and encryption
US5960204A (en) 1996-10-28 1999-09-28 J.D. Edwards World Source Company System and method for installing applications on a computer on an as needed basis
JPH10145354A (ja) * 1996-11-14 1998-05-29 Nippon Telegr & Teleph Corp <Ntt> 機能遠隔変更方法
US6499108B1 (en) 1996-11-19 2002-12-24 R. Brent Johnson Secure electronic mail system
US6546003B1 (en) 1996-11-21 2003-04-08 Verizon Services Corp. Telecommunications system
US5796942A (en) 1996-11-21 1998-08-18 Computer Associates International, Inc. Method and apparatus for automated network-wide surveillance and security breach intervention
KR100474259B1 (ko) 1996-11-26 2005-06-20 볼보 컨스트럭션 이키프먼트 홀딩 스웨덴 에이비 건설기계의작업장치용실린더를위한유압장치
JP4190599B2 (ja) 1996-11-27 2008-12-03 ソニー株式会社 情報伝送装置及び情報伝送方法並びに情報受信装置及び情報受信方法
JP3433413B2 (ja) * 1996-12-04 2003-08-04 富士ゼロックス株式会社 ユーザ認証装置および方法
US6012088A (en) 1996-12-10 2000-01-04 International Business Machines Corporation Automatic configuration for internet access device
US6011579A (en) 1996-12-10 2000-01-04 Motorola, Inc. Apparatus, method and system for wireline audio and video conferencing and telephony, with network interactivity
US5915087A (en) 1996-12-12 1999-06-22 Secure Computing Corporation Transparent security proxy for unreliable message exchange protocols
US6032118A (en) 1996-12-19 2000-02-29 Northern Telecom Limited Virtual private network service provider for asynchronous transfer mode network
US6182141B1 (en) 1996-12-20 2001-01-30 Intel Corporation Transparent proxy server
US5864666A (en) * 1996-12-23 1999-01-26 International Business Machines Corporation Web-based administration of IP tunneling on internet firewalls
US6052718A (en) * 1997-01-07 2000-04-18 Sightpath, Inc Replica routing
US5805801A (en) 1997-01-09 1998-09-08 International Business Machines Corporation System and method for detecting and preventing security
US5905859A (en) 1997-01-09 1999-05-18 International Business Machines Corporation Managed network device security method and apparatus
US6061346A (en) * 1997-01-17 2000-05-09 Telefonaktiebolaget Lm Ericsson (Publ) Secure access method, and associated apparatus, for accessing a private IP network
US6324267B1 (en) 1997-01-17 2001-11-27 Scientific-Atlanta, Inc. Two-tiered authorization and authentication for a cable data delivery system
US5961593A (en) 1997-01-22 1999-10-05 Lucent Technologies, Inc. System and method for providing anonymous personalized browsing by a proxy system in a network
US6055575A (en) 1997-01-28 2000-04-25 Ascend Communications, Inc. Virtual private network system and method
JP3603524B2 (ja) 1997-02-05 2004-12-22 株式会社日立製作所 ネットワーキング方法
TW360829B (en) * 1997-02-10 1999-06-11 Siemens Ag Auditory active communication-subscriber, communication-method and communication system with auditory active communication-subscriber
JP3514279B2 (ja) 1997-02-21 2004-03-31 日本電信電話株式会社 相手選択型アドレス解決方法及びその装置
US6178505B1 (en) 1997-03-10 2001-01-23 Internet Dynamics, Inc. Secure delivery of information in a network
US6105027A (en) 1997-03-10 2000-08-15 Internet Dynamics, Inc. Techniques for eliminating redundant access checking by access filters
US6408336B1 (en) 1997-03-10 2002-06-18 David S. Schneider Distributed administration of access to information
FR2761843B1 (fr) 1997-03-12 2002-05-03 Mannesmann Ag Procede d'exploitation de reseaux virtuels prives dans un reseau commun de commutation de paquets de donnees et dispositif pour la mise en oeuvre de ce procede
CA2283964C (en) 1997-03-12 2008-05-06 Nomadix, Llc Nomadic translator or router
US5946313A (en) * 1997-03-20 1999-08-31 Northern Telecom Limited Mechanism for multiplexing ATM AAL5 virtual circuits over ethernet
US6182072B1 (en) 1997-03-26 2001-01-30 Webtv Networks, Inc. Method and apparatus for generating a tour of world wide web sites
JPH10268762A (ja) * 1997-03-27 1998-10-09 Hitachi Software Eng Co Ltd 暗号鍵配送方法
US5996016A (en) * 1997-04-15 1999-11-30 International Business Machines Corporation Reinitiation of bind calls for IP applications concurrently executing with alternate address
JP3258593B2 (ja) * 1997-04-16 2002-02-18 日本電信電話株式会社 パケット処理方法および装置
US5884038A (en) 1997-05-02 1999-03-16 Whowhere? Inc. Method for providing an Internet protocol address with a domain name server
US5805803A (en) * 1997-05-13 1998-09-08 Digital Equipment Corporation Secure web tunnel
JPH1173398A (ja) 1997-06-03 1999-03-16 Toshiba Corp 分散ネットワークコンピューティングシステム、同システムに用いられる情報交換装置、同システムに用いられるセキュリティ機能を有する情報交換方法、この方法を格納したコンピュータ読取り可能な記憶媒体
TW338865B (en) 1997-06-03 1998-08-21 Philips Eloctronics N V Authentication system
US6226748B1 (en) * 1997-06-12 2001-05-01 Vpnet Technologies, Inc. Architecture for virtual private networks
US6173399B1 (en) * 1997-06-12 2001-01-09 Vpnet Technologies, Inc. Apparatus for implementing virtual private networks
SE9702385L (sv) 1997-06-23 1998-12-24 Ericsson Telefon Ab L M Förfarande och anordning i ett datanät
US6119234A (en) 1997-06-27 2000-09-12 Sun Microsystems, Inc. Method and apparatus for client-host communication over a computer network
US5870744A (en) 1997-06-30 1999-02-09 Intel Corporation Virtual people networking
JP3233071B2 (ja) * 1997-07-02 2001-11-26 日本電気株式会社 マネージャ・エージェント間同期装置及びマネージャ・エージェント間同期方法並びにマネージャ・エージェント間同期制御プログラムを記録した記録媒体
US6151628A (en) 1997-07-03 2000-11-21 3Com Corporation Network access methods, including direct wireless to internet access
US6012100A (en) 1997-07-14 2000-01-04 Freegate Corporation System and method of configuring a remotely managed secure network interface
DE69841210D1 (de) 1997-07-24 2009-11-12 Axway Inc E-Mail Firewall
JP3565686B2 (ja) 1997-08-01 2004-09-15 東京エレクトロンデバイス株式会社 コンピュータの記憶装置及び変換システム
US6092200A (en) * 1997-08-01 2000-07-18 Novell, Inc. Method and apparatus for providing a virtual private network
US20020002675A1 (en) * 1997-08-06 2002-01-03 Ronald Roscoe Bush Secure encryption of data packets for transmission over unsecured networks
US6560634B1 (en) 1997-08-15 2003-05-06 Verisign, Inc. Method of determining unavailability of an internet domain name
JPH1168735A (ja) * 1997-08-20 1999-03-09 Oki Data:Kk 通信データの保護方法と送信機および受信機
US6061796A (en) 1997-08-26 2000-05-09 V-One Corporation Multi-access virtual private network
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
WO1999014931A2 (en) 1997-09-16 1999-03-25 Transnexus, Llc Internet telephony call routing engine
US7225249B1 (en) 1997-09-26 2007-05-29 Mci, Llc Integrated systems for providing communications network management services and interactive generating invoice documents
US6470386B1 (en) * 1997-09-26 2002-10-22 Worldcom, Inc. Integrated proxy interface for web based telecommunications management tools
US6246670B1 (en) * 1997-10-16 2001-06-12 Telefonaktiebolaget L M Ericsson (Publ) Method and apparatus for preventing misrouting of data in a radio communication system
US6023764A (en) 1997-10-20 2000-02-08 International Business Machines Corporation Method and apparatus for providing security certificate management for Java Applets
US5974454A (en) 1997-11-14 1999-10-26 Microsoft Corporation Method and system for installing and updating program module components
US6167449A (en) 1997-11-19 2000-12-26 Apple Computer, Inc. System and method for identifying and locating services on multiple heterogeneous networks using a query by type
US6016512A (en) * 1997-11-20 2000-01-18 Telcordia Technologies, Inc. Enhanced domain name service using a most frequently used domain names table and a validity code table
US6070245A (en) 1997-11-25 2000-05-30 International Business Machines Corporation Application interface method and system for encryption control
US6023510A (en) 1997-12-24 2000-02-08 Philips Electronics North America Corporation Method of secure anonymous query by electronic messages transported via a public network and method of response
FI105753B (fi) 1997-12-31 2000-09-29 Ssh Comm Security Oy Pakettien autentisointimenetelmä verkko-osoitemuutosten ja protokollamuunnosten läsnäollessa
US6157957A (en) 1998-01-22 2000-12-05 Cisco Technology, Inc. Clock synchronization system and method using a continuous conversion function for a communication network
US6079020A (en) 1998-01-27 2000-06-20 Vpnet Technologies, Inc. Method and apparatus for managing a virtual private network
US6148342A (en) 1998-01-27 2000-11-14 Ho; Andrew P. Secure database management system for confidential records using separately encrypted identifier and access request
US6119171A (en) 1998-01-29 2000-09-12 Ip Dynamics, Inc. Domain name routing
US6205448B1 (en) 1998-01-30 2001-03-20 3Com Corporation Method and apparatus of synchronizing two computer systems supporting multiple synchronization techniques
US6065049A (en) 1998-02-04 2000-05-16 3Com Corporation Method and system for resolving addresses for network host interfaces from a cable modem
CA2228687A1 (en) 1998-02-04 1999-08-04 Brett Howard Secured virtual private networks
GB2334181B (en) 1998-02-06 2003-02-19 Nec Technologies Over-the-air re-programming of radio transceivers
US6175622B1 (en) 1998-02-10 2001-01-16 Northern Telecom Limited Virtual private network for a telephone network
US6006272A (en) * 1998-02-23 1999-12-21 Lucent Technologies Inc. Method for network address translation
US6353614B1 (en) 1998-03-05 2002-03-05 3Com Corporation Method and protocol for distributed network address translation
US6055236A (en) 1998-03-05 2000-04-25 3Com Corporation Method and system for locating network services with distributed network address translation
US6055574A (en) * 1998-03-10 2000-04-25 Unisys Corporation Method of providing a service through a server with a virtual single network address
JPH11261704A (ja) 1998-03-12 1999-09-24 Fujitsu Ltd 仮想ネットワークの接続方法およびゲートウェイ交換機
US6061736A (en) * 1998-03-13 2000-05-09 3Com Corporation Routing over similar paths
US6738814B1 (en) 1998-03-18 2004-05-18 Cisco Technology, Inc. Method for blocking denial of service and address spoofing attacks on a private network
US6175867B1 (en) * 1998-03-23 2001-01-16 Mci World Com, Inc. System and method for managing networks addressed via common network addresses
US6262987B1 (en) * 1998-03-26 2001-07-17 Compaq Computer Corp System and method for reducing latencies while translating internet host name-address bindings
US6233618B1 (en) * 1998-03-31 2001-05-15 Content Advisor, Inc. Access control of networked data
US6345361B1 (en) 1998-04-06 2002-02-05 Microsoft Corporation Directional set operations for permission based security in a computer system
US6366912B1 (en) 1998-04-06 2002-04-02 Microsoft Corporation Network security zones
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
US6073175A (en) 1998-04-27 2000-06-06 International Business Machines Corporation Method for supporting different service levels in a network using web page content information
US6449272B1 (en) 1998-05-08 2002-09-10 Lucent Technologies Inc. Multi-hop point-to-point protocol
US6496491B2 (en) 1998-05-08 2002-12-17 Lucent Technologies Inc. Mobile point-to-point protocol
US6801509B1 (en) 1998-05-08 2004-10-05 Lucent Technologies Inc. Mobile point-to-point protocol
US6813777B1 (en) 1998-05-26 2004-11-02 Rockwell Collins Transaction dispatcher for a passenger entertainment system, method and article of manufacture
US6189102B1 (en) 1998-05-27 2001-02-13 3Com Corporation Method for authentication of network devices in a data-over cable system
US6590588B2 (en) 1998-05-29 2003-07-08 Palm, Inc. Wireless, radio-frequency communications using a handheld computer
US6314463B1 (en) 1998-05-29 2001-11-06 Webspective Software, Inc. Method and system for measuring queue length and delay
US6557037B1 (en) 1998-05-29 2003-04-29 Sun Microsystems System and method for easing communications between devices connected respectively to public networks such as the internet and to private networks by facilitating resolution of human-readable addresses
US6308274B1 (en) * 1998-06-12 2001-10-23 Microsoft Corporation Least privilege via restricted tokens
US6182227B1 (en) 1998-06-22 2001-01-30 International Business Machines Corporation Lightweight authentication system and method for validating a server access request
US6256671B1 (en) * 1998-06-24 2001-07-03 Nortel Networks Limited Method and apparatus for providing network access control using a domain name system
US6829242B2 (en) 1998-06-30 2004-12-07 Cisco Technology, Inc. Method and apparatus for associating PVC identifiers with domain names of home gateways
US6263445B1 (en) * 1998-06-30 2001-07-17 Emc Corporation Method and apparatus for authenticating connections to a storage system coupled to a network
US6269099B1 (en) 1998-07-01 2001-07-31 3Com Corporation Protocol and method for peer network device discovery
US6202081B1 (en) * 1998-07-21 2001-03-13 3Com Corporation Method and protocol for synchronized transfer-window based firewall traversal
US6223287B1 (en) 1998-07-24 2001-04-24 International Business Machines Corporation Method for establishing a secured communication channel over the internet
US6751729B1 (en) 1998-07-24 2004-06-15 Spatial Adventures, Inc. Automated operation and security system for virtual private networks
US6760766B1 (en) * 1998-08-21 2004-07-06 Per Sahlqvist Data transmission method and device
US6421732B1 (en) 1998-08-27 2002-07-16 Ip Dynamics, Inc. Ipnet gateway
US6717949B1 (en) * 1998-08-31 2004-04-06 International Business Machines Corporation System and method for IP network address translation using selective masquerade
US6430610B1 (en) * 1998-09-02 2002-08-06 Steeleye Technology, Inc. TCP/IP address protection mechanism in a clustered server environment
WO2000014938A2 (en) 1998-09-09 2000-03-16 Sun Microsystems, Inc. Method and apparatus for transparently processing dns traffic
US6286047B1 (en) 1998-09-10 2001-09-04 Hewlett-Packard Company Method and system for automatic discovery of network services
US6434600B2 (en) 1998-09-15 2002-08-13 Microsoft Corporation Methods and systems for securely delivering electronic mail to hosts having dynamic IP addresses
JP2002525753A (ja) 1998-09-22 2002-08-13 サイエンス アプリケーションズ インターナショナル コーポレイション ユーザーが設定する動的共同環境
US6199112B1 (en) * 1998-09-23 2001-03-06 Crossroads Systems, Inc. System and method for resolving fibre channel device addresses on a network using the device's fully qualified domain name
DE19845331A1 (de) 1998-10-01 2000-04-06 Siemens Ag Verfahren und Vorrichtung zur Verkehrswegebestimmung in einem Kommunikations- oder Datennetz oder einem Netz aus Kommunikations- und Datennetz
US6243749B1 (en) 1998-10-08 2001-06-05 Cisco Technology, Inc. Dynamic network address updating
US6487663B1 (en) 1998-10-19 2002-11-26 Realnetworks, Inc. System and method for regulating the transmission of media data
US6502135B1 (en) * 1998-10-30 2002-12-31 Science Applications International Corporation Agile network protocol for secure communications with assured system availability
US7418504B2 (en) 1998-10-30 2008-08-26 Virnetx, Inc. Agile network protocol for secure communications using secure domain names
US6826616B2 (en) 1998-10-30 2004-11-30 Science Applications International Corp. Method for establishing secure communication link between computers of virtual private network
US7010604B1 (en) * 1998-10-30 2006-03-07 Science Applications International Corporation Agile network protocol for secure communications with assured system availability
US6430176B1 (en) 1998-11-06 2002-08-06 Nortel Networks Limited Multimedia channel management through PSTN signaling
US6168409B1 (en) * 1998-11-13 2001-01-02 Rosaldo Fare Apparatus for making two component fibers or continuous filaments using flexible tube inserts
US6006259A (en) 1998-11-20 1999-12-21 Network Alchemy, Inc. Method and apparatus for an internet protocol (IP) network clustering system
US6430155B1 (en) * 1998-11-30 2002-08-06 Cisco Technology, Inc. Congestion avoidance on communications networks
US6332158B1 (en) 1998-12-03 2001-12-18 Chris Risley Domain name system lookup allowing intelligent correction of searches and presentation of auxiliary information
US6930998B1 (en) 1998-12-07 2005-08-16 Nortel Networks Limited Hybrid TDM and ATM voice switching central office and method of completing inter-office calls using same
US6367009B1 (en) 1998-12-17 2002-04-02 International Business Machines Corporation Extending SSL to a multi-tier environment using delegation of authentication and authority
US6490290B1 (en) 1998-12-30 2002-12-03 Cisco Technology, Inc. Default internet traffic and transparent passthrough
US6298383B1 (en) 1999-01-04 2001-10-02 Cisco Technology, Inc. Integration of authentication authorization and accounting service and proxy service
US6243754B1 (en) * 1999-01-08 2001-06-05 International Business Machines Corporation Dynamic selection of network providers
US7307990B2 (en) 1999-01-19 2007-12-11 Cisco Technology, Inc. Shared communications network employing virtual-private-network identifiers
US6425003B1 (en) * 1999-01-22 2002-07-23 Cisco Technology, Inc. Method and apparatus for DNS resolution
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
US7028182B1 (en) 1999-02-19 2006-04-11 Nexsys Electronics, Inc. Secure network system and method for transfer of medical information
US6937597B1 (en) * 1999-02-26 2005-08-30 Lucent Technologies Inc. Signaling method for internet telephony
US6581166B1 (en) * 1999-03-02 2003-06-17 The Foxboro Company Network fault detection and recovery
US6081900A (en) 1999-03-16 2000-06-27 Novell, Inc. Secure intranet access
US7167904B1 (en) * 1999-03-19 2007-01-23 Network Solutions, Llc Unified web-based interface-to multiple registrar systems
US7461334B1 (en) 1999-03-19 2008-12-02 Network Solutions, Llc Apparatus and method for web forwarding
US6338082B1 (en) * 1999-03-22 2002-01-08 Eric Schneider Method, product, and apparatus for requesting a network resource
JP3170491B2 (ja) 1999-03-29 2001-05-28 松下電送システム株式会社 画像通信装置及びサーバ装置並びに能力交換方法
US7249377B1 (en) 1999-03-31 2007-07-24 International Business Machines Corporation Method for client delegation of security to a proxy
US6591306B1 (en) 1999-04-01 2003-07-08 Nec Corporation IP network access for portable devices
US6757740B1 (en) * 1999-05-03 2004-06-29 Digital Envoy, Inc. Systems and methods for determining collecting and using geographic locations of internet users
US6687823B1 (en) 1999-05-05 2004-02-03 Sun Microsystems, Inc. Cryptographic authorization with prioritized and weighted authentication
US6564261B1 (en) 1999-05-10 2003-05-13 Telefonaktiebolaget Lm Ericsson (Publ) Distributed system to intelligently establish sessions between anonymous users over various networks
CA2372662A1 (en) 1999-05-17 2000-11-23 Invicta Networks, Inc. Method of communications and communication network intrusion protection methods and intrusion attempt detection system
US7275113B1 (en) 1999-05-27 2007-09-25 3 Com Corporation Dynamic network address configuration system and method
US6636505B1 (en) 1999-05-28 2003-10-21 3Com Corporation Method for service provisioning a broadband modem
US6179102B1 (en) * 1999-06-17 2001-01-30 Twyna Weber Travel organizer
US20010049741A1 (en) 1999-06-18 2001-12-06 Bryan D. Skene Method and system for balancing load distribution on a wide area network
US6959184B1 (en) 1999-06-30 2005-10-25 Lucent Technologies Inc. Method for determining the security status of transmissions in a telecommunications network
US6549516B1 (en) * 1999-07-02 2003-04-15 Cisco Technology, Inc. Sending instructions from a service manager to forwarding agents on a need to know basis
US7065784B2 (en) 1999-07-26 2006-06-20 Microsoft Corporation Systems and methods for integrating access control with a namespace
US6453034B1 (en) 1999-07-29 2002-09-17 Mci Worldcom, Inc. Method of and system for extending internet telephony over virtual private network direct access lines
US7100195B1 (en) 1999-07-30 2006-08-29 Accenture Llp Managing user information on an e-commerce system
US6449657B2 (en) 1999-08-06 2002-09-10 Namezero.Com, Inc. Internet hosting system
US6496867B1 (en) 1999-08-27 2002-12-17 3Com Corporation System and method to negotiate private network addresses for initiating tunneling associations through private and/or public networks
US6687746B1 (en) * 1999-08-30 2004-02-03 Ideaflood, Inc. System apparatus and method for hosting and assigning domain names on a wide area network
US7072964B1 (en) * 1999-08-31 2006-07-04 Science Applications International Corporation System and method for interconnecting multiple virtual private networks
US6606660B1 (en) 1999-08-31 2003-08-12 Accenture Llp Stream-based communication in a communication services patterns environment
JP2003508955A (ja) 1999-08-31 2003-03-04 サイエンス アプリケーションズ インターナショナル コーポレイション 複数の仮想専用ネットワークを相互接続するシステムおよび方法
US6298341B1 (en) 1999-09-22 2001-10-02 Raredomains.Com, Llc System and method for generating domain names and for facilitating registration and transfer of the same
US6834271B1 (en) 1999-09-24 2004-12-21 Kryptosima Apparatus for and method of secure ATM debit card and credit card payment transactions via the internet
US6693878B1 (en) 1999-10-15 2004-02-17 Cisco Technology, Inc. Technique and apparatus for using node ID as virtual private network (VPN) identifiers
US7039713B1 (en) * 1999-11-09 2006-05-02 Microsoft Corporation System and method of user authentication for network communication through a policy agent
US6643701B1 (en) 1999-11-17 2003-11-04 Sun Microsystems, Inc. Method and apparatus for providing secure communication with a relay in a network
SE517217C2 (sv) 1999-12-29 2002-05-07 Ericsson Telefon Ab L M Metod och system för kommunikation mellan olika nätverk
US7103770B2 (en) 2000-01-27 2006-09-05 Web Data Solutions, Inc. Point-to-point data streaming using a mediator node for administration and security
US7188175B1 (en) * 2000-04-06 2007-03-06 Web.Com, Inc. Method and system for communicating between clients in a computer network
US6978364B1 (en) 2000-04-12 2005-12-20 Microsoft Corporation VPN enrollment protocol gateway
US7076651B2 (en) * 2000-05-01 2006-07-11 Safenet, Inc. System and method for highly secure data communications
US7197563B2 (en) * 2001-05-31 2007-03-27 Invicta Networks, Inc. Systems and methods for distributed network protection
US6353514B1 (en) * 2000-06-19 2002-03-05 Imation Corp. Two-sided compliant tape guide
US6333272B1 (en) 2000-10-06 2001-12-25 Lam Research Corporation Gas distribution apparatus for semiconductor processing
US6714970B1 (en) * 2000-10-26 2004-03-30 International Business Machines Corporation Protecting open world wide web sites from known malicious users by diverting requests from malicious users to alias addresses for the protected sites
EP1337931A4 (en) 2000-11-01 2005-05-11 Snapnames Com Inc DOMAIN NAME ACQUISITION AND MANAGEMENT SYSTEM AND METHOD
US20030005132A1 (en) 2001-05-16 2003-01-02 Nortel Networks Limited Distributed service creation and distribution
JP4209688B2 (ja) * 2001-05-24 2009-01-14 セレリティ・インコーポレーテッド 決定された比率のプロセス流体を供給する方法および装置
JP4010830B2 (ja) 2002-03-05 2007-11-21 富士通株式会社 通信装置およびネットワークシステム
US6986036B2 (en) 2002-03-20 2006-01-10 Microsoft Corporation System and method for protecting privacy and anonymity of parties of network communications
US7209559B2 (en) 2002-04-29 2007-04-24 The Boeing Company Method and apparatus for securely distributing large digital video/data files with optimum security
US20040199608A1 (en) 2003-04-04 2004-10-07 Rechterman Barbara J. Method for gathering domain name registration information from a registrant via a Registrar's web site
US20040199620A1 (en) 2003-04-04 2004-10-07 Tim Ruiz Method for transfering a registered domain name from a first registrar to a second registrar
US20040199520A1 (en) 2003-04-04 2004-10-07 Parsons Advanced Holdings, Inc. Method for checking the availability of a domain name
US20040199493A1 (en) 2003-04-04 2004-10-07 Tim Ruiz Method for registering a stream of domain names received via a registrar's web site
JP4224492B2 (ja) * 2003-06-09 2009-02-12 シーケーディ株式会社 圧力制御システム及び流量制御システム
US7584500B2 (en) 2003-11-19 2009-09-01 Hughes Network Systems, Llc Pre-fetching secure content using proxy architecture
TW200527870A (en) 2004-01-14 2005-08-16 Nec Corp Encrypted communication method, encrypted communication system, node device and program
US7502923B2 (en) 2004-09-16 2009-03-10 Nokia Corporation Systems and methods for secured domain name system use based on pre-existing trust
US7797413B2 (en) 2004-10-29 2010-09-14 The Go Daddy Group, Inc. Digital identity registration
US20070266141A1 (en) 2005-04-19 2007-11-15 Norton Michael A Processing taxonomic extensions on the world wide web to implement an integrity-rich intelligence apparatus
WO2007106826A2 (en) * 2006-03-13 2007-09-20 Markmonitor Inc. Domain name ownership validation
US7852861B2 (en) 2006-12-14 2010-12-14 Array Networks, Inc. Dynamic system and method for virtual private network (VPN) application level content routing using dual-proxy method
US8646067B2 (en) 2008-01-26 2014-02-04 Citrix Systems, Inc. Policy driven fine grain URL encoding mechanism for SSL VPN clientless access
US8090877B2 (en) 2008-01-26 2012-01-03 Citrix Systems, Inc. Systems and methods for fine grain policy driven cookie proxying
CN105450674B (zh) 2008-01-26 2019-05-10 思杰系统有限公司 用于配置和细粒度策略驱动web内容检测和重写的系统和方法
US20090199258A1 (en) 2008-02-05 2009-08-06 Yu-Hsiung Deng Method of setting mapping between channel number and program number

Also Published As

Publication number Publication date
AU765914B2 (en) 2003-10-02
EP3086533B1 (en) 2019-09-11
US20110191582A1 (en) 2011-08-04
CA2349520C (en) 2011-05-17
US7133930B2 (en) 2006-11-07
US20130067222A1 (en) 2013-03-14
JP2011223574A (ja) 2011-11-04
ATE492973T1 (de) 2011-01-15
WO2000027090A9 (en) 2001-07-05
WO2000027086A2 (en) 2000-05-11
CA2723504C (en) 2014-04-29
DE69943057D1 (de) 2011-02-03
JP2010063126A (ja) 2010-03-18
JP2002529779A (ja) 2002-09-10
WO2000027086A3 (en) 2000-10-05
EP1125419B1 (en) 2009-08-26
US20130091354A1 (en) 2013-04-11
JP2014090493A (ja) 2014-05-15
EP2290904B1 (en) 2016-04-20
EP3086533A1 (en) 2016-10-26
US8874771B2 (en) 2014-10-28
EP1125419A2 (en) 2001-08-22
EP1125414B1 (en) 2010-12-22
CA2349520A1 (en) 2000-05-11
ATE441275T1 (de) 2009-09-15
US20130219174A1 (en) 2013-08-22
JP2011193477A (ja) 2011-09-29
JP5685326B2 (ja) 2015-03-18
CA2349519C (en) 2011-08-09
US20110307693A1 (en) 2011-12-15
AU1455300A (en) 2000-05-22
CA2723504A1 (en) 2000-05-11
CA2349519A1 (en) 2000-05-11
DE69941338D1 (de) 2009-10-08
US20110238993A1 (en) 2011-09-29
WO2000027090A3 (en) 2000-10-12
JP2002529965A (ja) 2002-09-10
AU761388B2 (en) 2003-06-05
US9479426B2 (en) 2016-10-25
JP2014090494A (ja) 2014-05-15
US20080034201A1 (en) 2008-02-07
US7010604B1 (en) 2006-03-07
US20040003116A1 (en) 2004-01-01
US20060123134A1 (en) 2006-06-08
AU1600300A (en) 2000-05-22
EP1125414A2 (en) 2001-08-22
JP5198617B2 (ja) 2013-05-15
JP4451566B2 (ja) 2010-04-14
JP4824108B2 (ja) 2011-11-30
WO2000027090A2 (en) 2000-05-11
US7996539B2 (en) 2011-08-09
EP2290904A1 (en) 2011-03-02

Similar Documents

Publication Publication Date Title
ES2760905T3 (es) Un protocolo de red agile para comunicaciones seguras con disponibilidad asegurada de sistema
US6907473B2 (en) Agile network protocol for secure communications with assured system availability
US20180115529A1 (en) Agile protocol for secure communications with assured system availability