ES2299169T3 - Conectividad sobre cortafuegos de estado. - Google Patents
Conectividad sobre cortafuegos de estado. Download PDFInfo
- Publication number
- ES2299169T3 ES2299169T3 ES06764483T ES06764483T ES2299169T3 ES 2299169 T3 ES2299169 T3 ES 2299169T3 ES 06764483 T ES06764483 T ES 06764483T ES 06764483 T ES06764483 T ES 06764483T ES 2299169 T3 ES2299169 T3 ES 2299169T3
- Authority
- ES
- Spain
- Prior art keywords
- message
- client
- confirmation
- client terminal
- communication
- 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.)
- Active
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/02—Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
- H04L63/0227—Filtering policies
- H04L63/0254—Stateful filtering
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/02—Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
- H04L63/029—Firewall traversal, e.g. tunnelling or, creating pinholes
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
Landscapes
- Engineering & Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- General Engineering & Computer Science (AREA)
- Computing Systems (AREA)
- Computer Hardware Design (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
- Communication Control (AREA)
- Stereo-Broadcasting Methods (AREA)
- Reduction Or Emphasis Of Bandwidth Of Signals (AREA)
- Exchange Systems With Centralized Control (AREA)
- Circuits Of Receivers In General (AREA)
Abstract
Un procedimiento para establecer una conexión TCP entre un primer terminal (100) de cliente y un segundo terminal (102) de cliente estando protegido dicho primer terminal de cliente mediante un primer cortafuegos (108) de estado y estando protegido dicho segundo terminal de cliente mediante un segundo cortafuegos (110) de estado, y comprendiendo ambos terminales de cliente medios para enviar mensajes entre sí a través de un servidor (116) de mensajería, caracterizado porque el procedimiento comprende: acordar establecer una conexión TCP entre los terminales de cliente enviando un mensaje desde el primer terminal de cliente al segundo terminal de cliente a través del servidor de mensajería, comprendiendo dicho mensaje al menos números de puerto de los terminales de cliente que van a utilizarse en dicha conexión; empezar un procedimiento de establecimiento de conexión TCP en ambos terminales de cliente; en respuesta a enviar un primer mensaje de entrada en comunicación del procedimiento de establecimiento de conexión TCP, enviar un mensaje que indica un número de secuencia del primer mensaje de entrada en comunicación desde ambos terminales de cliente al terminal de cliente opuesto a través del servidor de mensajería; cuando los cortafuegos de los terminales de cliente opuestos rechazan el primer mensaje de entrada en comunicación, crear un mensaje de confirmación de recepción de dicho primer mensaje de entrada en comunicación en ambos terminales de cliente utilizando un conector sin procesar, incluyendo el mensaje de confirmación de recepción el número de secuencia recibido como número de confirmación de recepción; y enviar el mensaje de confirmación de recepción basado en el conector sin procesar al terminal de cliente opuesto para una confirmación de recepción adicional según el procedimiento de establecimiento de conexión TCP, completando dicha confirmación de recepción el establecimiento de la conexión TCP.
Description
Conectividad sobre cortafuegos de estado.
La presente invención se refiere a redes de
comunicación, y más en particular a conectividad sobre cortafuegos
de estado.
La seguridad se está convirtiendo en una
cuestión cada vez más importante en redes de comunicación. Por
consiguiente, cada vez más ordenadores se protegen mediante un
cortafuegos. Un cortafuegos controla, por ejemplo, el funcionamiento
de puertos de ordenadores y filtra la información que entra al
ordenador a través de la conexión a Internet. Cuando se utiliza una
denominada inspección de estado en un cortafuegos, el contenido de
cada paquete de datos no se examina sino que en su lugar el
cortafuegos compara ciertas partes clave del paquete de datos con
una base de datos de información de confianza. La información de
salida se supervisa en busca de características definitorias
específicas, y entonces la información entrante se compara con estas
características. Si la comparación da una coincidencia razonable,
se permite que la información cruce el cortafuegos; si no se
rechaza.
Aunque los cortafuegos mejoran la seguridad de
las redes de comunicación, simultáneamente plantean más dificultades
a la hora de establecer conexión directa entre dos ordenadores
principales de usuario final, debido a que en la actualidad con más
frecuencia los ordenadores de ambos usuarios finales están
protegidos mediante un cortafuegos. Por tanto, las partes no pueden
establecer, por ejemplo, una conexión TCP directa entre sí, ya que
esto requeriría normalmente que al menos uno de los ordenadores
principales de las partes no tuviera un cortafuegos, por lo que el
ordenador principal con cortafuegos puede establecer conexiones con
el ordenador principal sin cortafuegos.
Otra solución sería utilizar cortafuegos
compatibles con las aplicaciones, que tiene la desventaja de que la
configuración del cortafuegos se vuelve más complicada debido a que
el cortafuegos necesita ser compatible con todas las posibles
aplicaciones. Otra solución sería utilizar un protocolo de control,
como UPnP (Universal Plug and Play, de enchufe activo universal),
para controlar el funcionamiento tanto de los cortafuegos como de
los ordenadores principales. Sin embargo, un protocolo de control
aumenta también la complejidad de la implementación y
vulnerabilidad a los errores. Además, se requiere normalmente que
ambos ordenadores principales de usuario final y sus cortafuegos
soporten en protocolo de control.
El documento WO02/071717 da a conocer un
procedimiento para atravesar cortafuegos, en el que cada usuario
final se comunica con un servidor proxy y abre un canal TCP. El
proxy, a su vez, comunica a cada parte la dirección de origen y el
puerto TCP de las otras partes. Entonces las partes empiezan a
enviarse paquetes directamente entre sí utilizando la dirección de
origen y el puerto del proxy, mientras que el proxy sólo se utiliza
para mantener el estado del TCP con el fin de suplantar los
cortafuegos. Sin embargo, la solución del documento WO02/071717 no
es muy viable, ya que la mayoría de los operadores de red tienen una
configuración antisuplantación en sus redes, impidiendo el uso del
procedimiento anteriormente descrito. Por consiguiente, existe una
necesidad de un procedimiento alternativo para atravesar
cortafuegos.
El artículo "NUTSS: A
SIP-based approach to UDP and TCP network
connectivity" de g. Saikat et al., Talleres SIGCOMM '04,
30 de agosto a 3 de septiembre de 2004, describe un procedimiento
alternativo para pasar conexiones TCP a través de cortafuegos
NAT.
Ahora se ha inventado un procedimiento y equipo
técnico mejorados que implementan el procedimiento, al que no
afecta ninguna configuración antisuplantación en las redes. Diversos
aspectos de la invención incluyen un procedimiento, un sistema de
comunicación, un terminal de cliente y un programa informático, que
se caracterizan por lo que se menciona en las reivindicaciones
independientes. Diversas realizaciones de la invención se dan a
conocer en las reivindicaciones dependientes.
Según un primer aspecto, un procedimiento según
la reivindicación 1 de la invención se basa en la idea de
establecer una conexión TCP en una disposición de red que comprende
un primer terminal de cliente y un segundo terminal de cliente,
estando protegido dicho primer terminal de cliente por un primer
cortafuegos de estado y estando protegido dicho segundo terminal de
cliente por un segundo cortafuegos de estado. Ambos terminales de
cliente comprenden también medios para enviarse mensajes entre sí a
través de un servidor de mensajería. Inicialmente, los terminales
de cliente acuerdan establecer una conexión TCP entre sí enviando un
mensaje desde el primer terminal de cliente al segundo terminal de
cliente a través de un servidor de mensajería, comprendiendo dicho
mensaje al menos números de puerto de los terminales de cliente que
van a utilizarse en dicha conexión, después de lo cual se inicia un
procedimiento de establecimiento de conexión TCP en ambos
terminales de cliente. En respuesta al envío de un primer mensaje de
entrada en comunicación del procedimiento de establecimiento de la
conexión TCP, ambos terminales de cliente envían un mensaje que
indica un número de secuencia del primer mensaje de entrada en
comunicación al terminal de cliente opuesto a través del servidor de
mensajería. Entonces, en respuesta a los cortafuegos de los
terminales de cliente opuestos que rechazan el primer mensaje de
entrada en comunicación debido a discordancia frente a cualquier
regla de los cortafuegos de estado, un mensaje de confirmación de
recepción a dicho primer mensaje de entrada en comunicación se crea
en ambos terminales de cliente utilizando un conector sin procesar,
incluyendo el mensaje de confirmación de recepción el número de
secuencia recibido como número de confirmación de recepción.
Finalmente, este mensaje de confirmación de recepción basado en el
conector sin procesar se envía al terminal de cliente opuesto para
una confirmación de recepción adicional según el procedimiento de
establecimiento de conexión TCP, completando dicha confirmación de
recepción el establecimiento de la conexión TCP.
Según una realización, el primer mensaje de
entrada en comunicación del procedimiento de establecimiento de
conexión TCP es un paquete TCP SINC, por lo que los cortafuegos de
estado que protegen los terminales de cliente crean una regla que
sólo permite que se pase un paquete TCP SINC_CONF con un número de
confirmación de recepción correspondiente a través de los
cortafuegos en dirección de entrada.
Según una realización, los cortafuegos de estado
que protegen los terminales de cliente reciben el mensaje de
confirmación de recepción basado en el conector sin procesar enviado
por el terminal de cliente opuesto, identifican el mensaje de
confirmación de recepción como un paquete TCP SINC_CONF; y permiten
que el mensaje de confirmación de recepción se pase a través de los
cortafuegos en dirección de entrada en respuesta al número de
confirmación de recepción del mensaje de confirmación de recepción
correspondiente al número de secuencia del paquete TCP SINC.
La disposición según la invención proporciona
ventajas significativas. Al crear los paquetes SINC_CONF con los
conectores sin procesar basados en la información de los mensajes de
MI intermedios, se engaña a los terminales de cliente, así como a
los cortafuegos, para que malinterpreten la situación como que sólo
tienen una conexión de salida unidireccional, aunque se establece
realmente una conexión bidireccional. Además, los clientes están
operando con sus direcciones IP reales, y no se requiere
suplantación, por lo que la disposición no se ve afectada por
ninguna configuración antisuplantación en la red. Además incluso,
debido a que las realizaciones se basan en la condición de estado
de los cortafuegos, los cortafuegos no requieren ninguna
funcionalidad de compatibilidad con las aplicaciones o no necesitan
soportar ningún protocolo de control de cortafuegos, tal como UPnP,
con el fin de soportar las realizaciones. Por tanto, la disposición
simplifica la implementación de los cortafuegos.
Según un segundo aspecto, se proporciona un
sistema de comunicación según la reivindicación 4 para implementar
la disposición anteriormente descrita.
Según un tercer aspecto, se proporciona un
terminal de cliente según la reivindicación 8 de un sistema de
telecomunicación, estando el terminal de cliente protegido por un
cortafuegos de estado, y comprendiendo el terminal de cliente
medios para enviar mensajes a al menos un segundo terminal de
cliente a través de un servidor de mensajería; medios para acordar
establecer una conexión TCP con el segundo terminal de cliente
intercambiando mensajes a través del servidor de mensajería,
comprendiendo al menos uno de dichos mensajes al menos números de
puerto de los terminales de cliente que van a usarse en dicha
conexión; medios para empezar un procedimiento de establecimiento
de conexión TCP enviando un primer mensaje de entrada en
comunicación del procedimiento de la conexión TCP; medios para
enviar un mensaje que indica un número de secuencia del primer
mensaje de entrada en comunicación al segundo terminal de cliente a
través del servidor de mensajería; medios para recibir, a través del
servidor de mensajería, un mensaje que indica un número de secuencia
del primer mensaje de entrada en comunicación enviado por el
segundo terminal de cliente; medios para crear un mensaje de
confirmación de recepción de dicho primer mensaje de entrada en
comunicación enviado por el segundo terminal de cliente utilizando
un conector sin procesar, incluyendo el mensaje de confirmación de
recepción el número de secuencia recibido como número de
confirmación de recepción; medios para enviar el mensaje de
confirmación de recepción basado en el conector sin procesar al
segundo terminal de cliente; medios para recibir un mensaje de
confirmación de recepción basado en el conector sin procesar desde
el segundo terminal de cliente, incluyendo dicho mensaje de
confirmación de recepción el número de secuencia del primer mensaje
de entrada en comunicación enviado al segundo terminal de cliente; y
medios para enviar una confirmación de recepción del mensaje de
confirmación de recepción basado en el conector sin procesar,
completando dicha confirmación de recepción el establecimiento de la
conexión TCP.
Según un cuarto aspecto, se proporciona un
producto de programa informático, según la reivindicación 10,
almacenado en un medio legible por ordenador y ejecutable en un
dispositivo de procesamiento de datos, para implementar los medios
de dicho terminal de cliente.
A continuación, se describirán diversas
realizaciones de la invención con mayor detalle con referencia a los
dibujos adjuntos, en los que
la figura 1 muestra una disposición de red según
una realización de la invención;
la figura 2 muestra un gráfico de señalización
de un procedimiento para establecer una conexión TCP según una
realización de la invención; y
la figura 3 muestra un terminal de cliente según
una realización de la invención en un gráfico de bloques
reducido.
A continuación, la invención se ilustrará
haciendo referencia a servicios de mensajería instantánea (MI) como
marco preferible para la implementación. La invención, sin embargo,
no se limita únicamente a los servicios de MI, sino que puede
aplicarse a otras aplicaciones de comunicación similares, en las que
al menos dos usuarios finales están conectados entre sí a través de
un servicio de directorio centralizado. Otro ejemplo de tal servicio
de mensajería son el servicio de mensajes cortos (SMS) y el servicio
de mensajes multimedia (MMS) soportados por diversas redes de
comunicación móvil.
Los servicios de mensajería instantánea (MI) se
han convertido en uno de los servicios de Internet más populares de
los últimos tiempos. La mensajería instantánea se basa en mensajes
de texto entregados a través de una conexión IP directamente entre
las partes. Un servidor de MI sólo participa para establecer la
conexión entre las partes, pero no está implicado en el proceso de
entrega de los mensajes de MI de ningún modo salvo transmitiéndolos
adicionalmente, por lo que los mensajes pueden entregarse a través
de un servidor de MI con un mínimo retardo, es decir casi en tiempo
real. Una aplicación popular de los servicios de MI es lo que se
conoce como chat, en la que un grupo predeterminado de
usuarios terminales están comunicándose entre sí de modo que un
mensaje de MI enviado por un usuario se entrega a todos los demás
terminales que pertenecen al grupo. Durante el establecimiento de
la conexión, un cliente de MI en cada terminal envía información de
conexión al servidor de MI, incluyendo la información de conexión
una dirección IP del terminal y un número del puerto de terminal
asignado al cliente de MI. El servidor de MI mantiene y entrega la
información de conexión necesaria a cada terminal que participa en
una sesión de MI.
La figura 1 muestra una disposición de red según
una realización preferida, en la que dos clientes, el cliente A
(100) y el cliente B (102), conectados a una red (104) de
comunicaciones desean establecer una conexión (106) directa entre
sí, por ejemplo, para transferencia de archivos u otras operaciones
que requieran un ancho de banda más grande. Ambos clientes están
protegidos por cortafuegos de estado, CF A (108) y CF B (110), y
ambos cortafuegos son compatibles con TCP y UDP. Los cortafuegos CF
A (108) y CF B (110) están configurados normalmente de modo que
permiten sólo conexiones de salida, y ningún puerto de entrada está
abierto. Ambos clientes A y B tienen una conexión (112, 114) a un
servidor de mensajería instantánea (servidor de MI, 116) por lo que
pueden pasarse mensajes cortos entre sí a través del servidor. Sin
embargo, las transferencias de archivos u otras operaciones de
ancho de banda alta no pueden llevarse a cabo a través de la sesión
de MI, ya que crean demasiada carga.
Ahora, el marco de MI proporciona herramientas
útiles para engañar tanto a los cortafuegos CF A como CF B, así como
a los clientes A y B, para que crean que, durante el establecimiento
de una conexión directa entre los clientes A y B, tanto los
clientes A y B como los cortafuegos CF A y CF B están estableciendo
sólo una conexión de salida, aunque en realidad se está
estableciendo una conexión bidireccional. Con este fin, se utiliza
una posibilidad de enviar mensajes de MI directamente entre los
clientes con un retardo muy corto durante el establecimiento de una
conexión directa, procedimiento que se describe más adelante con
mayor detalle.
Otra técnica utilizada en el presente documento
es la denominada de conectores sin procesar. Tal como se conoce
generalmente, un conector puede utilizarse en conexión en red de
ordenadores para formar un extremo de un enlace de comunicación
bidireccional entre dos programas. En una comunicación basada en un
protocolo TCP o UDP, un conector en un determinado ordenador
principal se define normalmente como la combinación de una dirección
IP, un protocolo, y un número de puerto. Cada conector está
vinculado a un puerto dado, lo que permite al protocolo de capa de
transporte identificar a qué aplicación deberían enviarse los datos.
Sin embargo, casi todos los sistemas operativos modernos también
soportan los denominados conectores sin procesar, que permiten que
el emisor defina los campos de encabezamiento de paquete de datos,
incluyendo direcciones IP y números de puerto, por lo que pueden
evitarse determinadas operaciones sobre una capa de transporte, como
la capa TCP. Por consiguiente, los conectores sin procesar permiten
crear un protocolo de conexión en red privado para una tarea
específica.
Un procedimiento, según una realización, para
establecer una conexión TCP directa entre los clientes A y B se
ilustra adicionalmente en un gráfico de señalización de la figura 2.
La operación empieza cuando una primera parte (cliente A) envía un
mensaje (200) de MI a la segunda parte (cliente B) a través del
servidor de MI, indicando el mensaje de MI el deseo de establecer
una conexión TCP directa entre determinados puertos de los
ordenadores principales de cliente. Por consiguiente, el mensaje de
MI es un mensaje basado en texto con formato libre, pero debería
indicar la siguiente idea: "Establezcamos una conexión TCP, mi
puerto X, su puerto Y". La segunda parte (cliente B) confirma
esto enviando un mensaje de MI de formato libre ("Recepción
confirmada", 202) a la primera parte (cliente A) a través del
servidor de MI.
Entonces el cliente A empieza un procedimiento
de establecimiento de conexión TCP normal, en el que el cliente A
inicia en el API de conectores una función de vinculación(),
asociando la dirección IP del cliente A con un conector, y una
función de vinculación(), estableciendo una conexión al conector
especificado. A partir de aquí, la conexión TCP se inicia desde el
puerto X del ordenador principal del cliente A al puerto Y del
ordenador principal del cliente B (204). El cliente B lleva a cabo
las mismas acciones en la dirección opuesta: inicia las funciones
de vinculación() y conexión() en el API de conectores, y entonces
inicia la conexión TCP desde el puerto Y del ordenador principal del
cliente B al puerto X del ordenador principal del cliente A
(206).
Por consiguiente, el primer mensaje (208) de
entrada en comunicación enviado por el cliente A tiene la forma de:
paquete TCP, puerto X de origen, puerto Y de destino, etiquetas
SINC, número SEC I, número CONF 0. Asimismo, el primer mensaje
(210) de entrada en comunicación enviado por el cliente B tiene la
forma de: paquete TCP, puerto Y de origen, puerto X de destino,
etiquetas SINC, número SEC J, número CONF 0. Después de esto el
estado de los conectores de ambos clientes A y B es SINC_ENV
(segmento sincronizado enviado).
Entonces el primer mensaje (208) de entrada en
comunicación enviado por el cliente A se recibe en el cortafuegos CF
A. El cortafuegos CF A examina (212) el paquete y notifica que es un
paquete TCP SINC que va desde el cliente A al cliente B. El
cortafuegos de estado CF A crea una regla para permitir que los
paquetes de retorno con un número CONF de coincidencia atraviesen el
cortafuegos. Asimismo, el primer mensaje (210) de entrada en
comunicación enviado por el cliente B se recibe en el cortafuegos CF
B, que examina (214) el paquete ("un paquete TCP SINC que va desde
el cliente B al cliente A"), y crea una regla para permitir que
los paquetes de retorno con un número CONF de coincidencia
atraviesen el cortafuegos.
Después de enviar el primer mensaje de entrada
en comunicación, el cliente A envía un mensaje (216) de MI al
cliente B a través del servidor MI, mensaje MI que indica que el
segmento sincronizado se envía e incluye un número "I" de
secuencia. De nuevo, el mensaje (216) de MI puede ser de formato
libre, pero debería indicar la siguiente idea: "paquete TCP SINC
enviado, número SEC I". Respectivamente, el cliente B envía un
mensaje (218) de MI al cliente A a través del servidor de MI:
"paquete TCP SINC enviado, número SEC J".
Mientras, el cortafuegos CF A que protege el
ordenador principal del cliente A recibe el primer mensaje (210) de
entrada en comunicación enviado por el cliente B. Sin embargo, las
propiedades del paquete TCP SINC recibido no coinciden con ninguna
regla permitida del cortafuegos CF A de estado, por lo que el
cortafuegos CF A decide rechazar (220) el paquete. De manera
similar, el cortafuegos CF B rechaza (222) el paquete TCP SINC
enviado por el cliente A.
En esta fase, gracias a los mensajes (216, 218)
de MI enviados por los clientes A y B entre sí, ambos clientes
conocen ahora los números de secuencia que espera el cortafuegos del
otro extremo. Esto permite a ambos clientes crear (224, 226)
paquetes SINC_CONF según una entrada en comunicación TCP estándar,
paquetes SINC_CONF que se crean basándose en la información recibida
en los mensajes (216, 218) de MI y paquetes SINC_CONF que coinciden
con las reglas de ambos cortafuegos CF A y CF B. Los paquetes
SINC_CONF se crean con conectores sin procesar, que permiten a los
clientes especificar los datos que van a incluirse en los
paquetes.
Por consiguiente, el cliente A crea un paquete
SINC_CONF que comprende la información: paquete TCP, puerto X de
origen, puerto Y de destino, etiquetas SINC+CONF, número SEC I,
número CONF J; este paquete SINC_CONF se envía (228) al cliente B.
Asimismo, el cliente B crea un paquete SINC_CONF que comprende la
información: paquete TCP, puerto Y de origen, puerto X de destino,
etiquetas SINC+CONF, número SEC J, número CONF I; este paquete
SINC_CONF se envía (230) al cliente A.
Entonces el paquete SINC_CONF enviado (228) por
el cliente A se recibe en el cortafuegos CF A. El cortafuegos CF A
examina (232) el paquete y notifica que es un paquete TCP SINC_CONF
solitario saliendo de la red. El cortafuegos CF A de estado
probablemente no puede crear ninguna regla para devolver paquetes,
ya que en un procedimiento de entrada en comunicación TCP estándar
un paquete SINC_CONF no debería originarse a partir del cliente
protegido, es decir, desde dentro del cortafuegos. Sin embargo, el
cortafuegos está configurado para pasar todas las conexiones de
salida a través, y por tanto el paquete SINC_CONF se reenvía al
cliente B. El paquete SINC_CONF enviado (230) por el cliente B
también se recibe en el cortafuegos CF B, en el que se trata (234)
de manera similar a como se ha descrito anteriormente.
El paquete SINC_CONF enviado (228) por el
cliente A y reenviado por el cortafuegos CF A se recibe en el
cortafuegos CF B, que notifica (236) que se recibe un paquete TCP
desde el cliente A, comprendiendo el paquete las etiquetas
SINC+CONF y teniendo un número CONF J. Este tipo de paquete
SINC_CONF coinciden con la regla de entrada esperada, que
previamente se creó en el cortafuegos CF B (214, "se permitirá que
paquetes de retorno a un paquete SINC con un número CONF coinciden
atraviesen el cortafuegos").
Por consiguiente, el paquete SINC_CONF se
reenvía (238) al cliente B, que responde (240) con un paquete CONF
según el procedimiento de entrada en comunicación TCP estándar, en
el que la función conectar() opera como una entrada en comunicación
a tres bandas: un cliente envía un paquete SINC, recibe un paquete
SINC_CONF y finalmente lo confirma con un paquete CONF. Como el
cliente B recibe ahora un paquete SINC_CONF en respuesta al envío
de un paquete SINC, automáticamente responde con un paquete CONF,
aunque el paquete SINC_CONF no se haya creado según un procedimiento
de entrada en comunicación conectar() normal. De manera similar, el
paquete SINC_CONF enviado (230) por el cliente B y reenviado por el
cortafuegos CF B se recibe en el cortafuegos CF A, que acepta (242)
el paquete y lo reenvía (244) al cliente A, que responde (246) con
un paquete CONF.
En esta fase, ambos clientes A y B han realizado
las acciones necesarias en el procedimiento de entrada en
comunicación TCP estándar, por lo que se ESTABLECE el estado de los
conectores de ambos clientes A y B, es decir se establece una
conexión TCP bidireccional entre los clientes A y B y puede empezar
la transferencia de archivos real. Creando los paquetes SINC_CONF
con los conectores sin procesar basándose en la información de los
mensajes de MI intermedios, se ha engañado tanto a los clientes A y
B como a los cortafuegos CF A y CF B, para malinterpretar la
situación ya que sólo están teniendo una conexión de salida
unidireccional. Es importante observar que los clientes están
operando con sus direcciones IP reales, y no se requiere
suplantación. Por consiguiente, la disposición antes descrita no se
ve afectada por ninguna configuración de antisuplantación en la
red.
Por consiguiente, las realizaciones se basan en
la condición de estado de los cortafuegos, lo que significa que con
el fin de soportar las realizaciones, los cortafuegos no requieren
ninguna funcionalidad de compatibilidad con las aplicaciones o no
necesitan soportar ningún protocolo de control de cortafuegos, tal
como UPnP. Por tanto, las realizaciones simplifican la
implementación del cortafuegos. Los cortafuegos pueden implementarse
como un programa o un dispositivo de hardware, y pueden operarse por
un particular o por un operador de red.
Los terminales A y B de cliente pueden ser
ordenadores basados en PC, conocidos como tal, conectados a
cualquier red de comunicación de datos, o los terminales A y B de
cliente pueden ser terminales inalámbricos, como estaciones móviles
o dispositivos PDA, conectados a cualquier red de comunicación de
datos a través de una red de comunicación móvil. Por consiguiente,
el terminal de cliente comprende, tal como se ilustra en la figura
3, memoria MEM, una interfaz IU de usuario, medios de E/S E/S para
disponer transmisión de datos con otros dispositivos, y una o más
unidades centrales de procesamiento CPU que comprenden al menos un
procesador. La memoria MEM incluye una parte no volátil para
almacenar las aplicaciones que controlan la unidad central de
procesamiento CPU y otros datos que van a almacenarse y una parte
volátil que va a utilizarse para el procesamiento de datos
temporal.
Las acciones de las realizaciones
preferiblemente se automatizan en los terminales de cliente hasta el
punto de que no se necesita intervención del usuario durante el
establecimiento de conexión TCP según las realizaciones. Las etapas
según las realizaciones pueden implementarse en gran medida con
comandos de programa ejecutados en las unidades centrales de
procesamiento CPU del terminal de cliente ilustradas en la figura 3.
Por tanto, dichos medios para llevar a cabo el procedimiento
descrito anteriormente se implementan preferiblemente como código
de software informático. El software informático puede almacenarse
en cualquier medio de memoria, tal como el disco duro de un PC o un
disco CD-ROM, desde el que puede cargarse en la
memoria del terminal de cliente. El software informático puede
cargarse también a través de una red, por ejemplo utilizando una
pila de protocolo TCP/IP. También es posible usar soluciones de
hardware o una combinación de soluciones de hardware y software para
implementar los medios inventivos.
Es obvio que la presente invención no está
limitada únicamente a las realizaciones presentadas anteriormente,
sino que puede modificarse dentro del alcance de las
reivindicaciones adjuntas.
Claims (10)
1. Un procedimiento para establecer una conexión
TCP entre un primer terminal (100) de cliente y un segundo terminal
(102) de cliente estando protegido dicho primer terminal de cliente
mediante un primer cortafuegos (108) de estado y estando protegido
dicho segundo terminal de cliente mediante un segundo cortafuegos
(110) de estado, y comprendiendo ambos terminales de cliente medios
para enviar mensajes entre sí a través de un servidor (116) de
mensajería, caracterizado porque el procedimiento
comprende:
- acordar establecer una conexión TCP entre los terminales de cliente enviando un mensaje desde el primer terminal de cliente al segundo terminal de cliente a través del servidor de mensajería, comprendiendo dicho mensaje al menos números de puerto de los terminales de cliente que van a utilizarse en dicha conexión;
- empezar un procedimiento de establecimiento de conexión TCP en ambos terminales de cliente;
- en respuesta a enviar un primer mensaje de entrada en comunicación del procedimiento de establecimiento de conexión TCP, enviar un mensaje que indica un número de secuencia del primer mensaje de entrada en comunicación desde ambos terminales de cliente al terminal de cliente opuesto a través del servidor de mensajería;
- cuando los cortafuegos de los terminales de cliente opuestos rechazan el primer mensaje de entrada en comunicación, crear un mensaje de confirmación de recepción de dicho primer mensaje de entrada en comunicación en ambos terminales de cliente utilizando un conector sin procesar, incluyendo el mensaje de confirmación de recepción el número de secuencia recibido como número de confirmación de recepción; y
- enviar el mensaje de confirmación de recepción basado en el conector sin procesar al terminal de cliente opuesto para una confirmación de recepción adicional según el procedimiento de establecimiento de conexión TCP, completando dicha confirmación de recepción el establecimiento de la conexión TCP.
2. El procedimiento según la reivindicación 1,
caracterizado porque el primer mensaje de entrada en
comunicación del procedimiento de establecimiento de conexión TCP
es un paquete TCP SINC, por lo que el procedimiento comprende
además:
- crear, en los cortafuegos de estado que protegen los terminales de cliente, una regla que permite que se pase sólo un paquete TCP SINC_CONF con un número de confirmación de recepción correspondiente a través de los cortafuegos en dirección de entrada.
3. El procedimiento según la reivindicación 2,
caracterizado porque el procedimiento comprende además:
- recibir, en los cortafuegos de estado que protegen los terminales de cliente, el mensaje de confirmación de recepción basado en el conector sin procesar enviado por el terminal de cliente opuesto;
- identificar el mensaje de confirmación de recepción como un paquete TCP SINC_CONF; y
- permitir que el mensaje de confirmación de recepción se pase a través de los cortafuegos en dirección de entrada en respuesta al número de confirmación de recepción del mensaje de confirmación de recepción correspondiente al número de secuencia del paquete TCP SINC.
4. Un sistema de comunicación, comprendiendo el
sistema:
- -
- un primer terminal (100) de cliente;
- -
- un segundo terminal (102) de cliente;
- -
- un primer cortafuegos (108) de estado que protege dicho primer terminal de cliente;
- -
- un segundo cortafuegos (110) de estado que protege dicho segundo terminal de cliente;
- -
- un servidor (116) de mensajería dispuesto para entregar mensajes entre terminales;
caracterizado porque, en el sistema de
comunicación:
- los terminales de cliente están dispuestos para acordar establecer una conexión TCP entre sí enviando un mensaje desde el primer terminal de cliente al segundo terminal de cliente a través del servidor de mensajería, comprendiendo dicho mensaje al menos números de puerto de los terminales de cliente que van a utilizarse en dicha conexión;
- ambos terminales de cliente están dispuestos para empezar un procedimiento de establecimiento de conexión TCP enviando un primer mensaje de entrada en comunicación del procedimiento de establecimiento de conexión TCP,
- ambos terminales de cliente están dispuestos para enviar un mensaje que indica un número de secuencia del primer mensaje de entrada en comunicación al terminal de cliente opuesto a través del servidor de mensajería;
- ambos terminales de cliente están dispuestos, cuando los cortafuegos de los terminales de cliente opuestos rechazan el primer mensaje de entrada en comunicación, para crear un mensaje de confirmación de recepción de dicho primer mensaje de entrada en comunicación utilizando un conector sin procesar, incluyendo el mensaje de confirmación de recepción el número de secuencia recibido como número de confirmación de recepción; y
- ambos terminales de cliente están dispuestos para enviar el mensaje de confirmación de recepción basado en el conector sin procesar al terminal de cliente opuesto para una confirmación de recepción adicional según el procedimiento de establecimiento de conexión TCP, completando dicha confirmación de recepción el establecimiento de la conexión TCP.
5. El sistema de comunicación según la
reivindicación 4, caracterizado porque el primer mensaje de
entrada en comunicación del procedimiento de establecimiento de
conexión TCP es un paquete TCP SINC, y
los cortafuegos de estado que protegen los
terminales de cliente están dispuestos para crear una regla que
permite que se pase sólo un paquete TCP SINC_CONF con un número de
confirmación de recepción correspondiente a través de los
cortafuegos en dirección de entrada.
6. El sistema de comunicación según la
reivindicación 5, caracterizado porque los cortafuegos de
estado que protegen los terminales de cliente están dispuestos
para
recibir el mensaje de confirmación de recepción
basado en el conector sin procesar enviado por el terminal de
cliente opuesto;
identificar el mensaje de confirmación de
recepción como un paquete TCP SINC_CONF; y
permitir que se pase el mensaje de confirmación
de recepción a través de los cortafuegos en dirección de entrada en
respuesta al número de confirmación de recepción del mensaje de
confirmación de recepción correspondiente al número de secuencia
del paquete TCP SINC.
7. El sistema de comunicación según una
cualquiera de las reivindicaciones 4 a 6, caracterizado
porque
el servidor de mensajería es un servidor de
mensajería instantánea.
8. Un terminal de cliente de un sistema de
telecomunicaciones, estando protegido el terminal (100) de cliente
mediante un cortafuegos (108) de estado, y comprendiendo el terminal
de cliente medios para enviar mensajes a al menos un segundo
terminal (102) de cliente a través de un servidor (110) de
mensajería, caracterizado porque el terminal de cliente
comprende:
- medios para acordar establecer una conexión TCP con el segundo terminal de cliente intercambiando mensajes a través del servidor de mensajería, comprendiendo al menos uno de dichos mensajes al menos números de puerto de los terminales de cliente que van a utilizarse en dicha conexión;
- medios para empezar un procedimiento de establecimiento de conexión TCP enviando un primer mensaje de entrada en comunicación del procedimiento de establecimiento de conexión TCP;
- medios para enviar un mensaje que indica un número de secuencia del primer mensaje de entrada en comunicación al segundo terminal de cliente a través del servidor de mensajería;
- medios para recibir, a través del servidor de mensajería, un mensaje que indica un número de secuencia del primer mensaje de entrada en comunicación enviado por el segundo terminal de cliente;
- medios para crear un mensaje de confirmación de recepción de dicho primer mensaje de entrada en comunicación enviado por el segundo terminal de cliente usando un conector sin procesar, incluyendo el mensaje de confirmación de recepción el número de secuencia recibido como un número de confirmación de recepción;
- medios para enviar el mensaje de confirmación de recepción basado en el conector sin procesar al segundo terminal de cliente;
- medios para recibir un mensaje de confirmación de recepción basado en el conector sin procesar desde el segundo terminal de cliente, incluyendo dicho mensaje de confirmación de recepción el número de secuencia del primer mensaje de entrada en comunicación enviado al segundo terminal de cliente; y
- medios para enviar una confirmación de recepción al mensaje de confirmación de recepción basado en el conector sin procesar recibido, completando dicha confirmación de recepción el establecimiento de la conexión TCP.
9. El terminal de cliente según la
reivindicación 8, caracterizado porque
dichos medios para enviar mensajes a al menos un
segundo terminal de cliente a través de un servidor de mensajería
comprenden una aplicación de cliente de mensajería instantánea.
10. Un producto de programa informático,
almacenado en un medio legible por ordenador y ejecutable en un
dispositivo de procesamiento de datos, para establecer una conexión
TCP, caracterizado porque el producto de programa
informático comprende:
- una sección de código de programa informático para acordar establecer una conexión TCP desde un primer a un segundo terminal de cliente intercambiando mensajes a través del servidor de mensajería, comprendiendo al menos uno de dichos mensajes al menos números de puerto de los terminales de cliente que van a utilizarse en dicha conexión;
- una sección de código de programa informático para empezar un procedimiento de establecimiento de conexión TCP enviando un primer mensaje de entrada en comunicación del procedimiento de establecimiento de conexión TCP;
- una sección de código de programa informático para enviar un mensaje que indica un número de secuencia del primer mensaje de entrada en comunicación al segundo terminal de cliente a través del servidor de mensajería;
- una sección de código de programa informático para recibir, a través del servidor de mensajería, un mensaje que indica un número de secuencia del primer mensaje de entrada en comunicación enviado por el segundo terminal de cliente;
- una sección de código de programa informático para crear un mensaje de confirmación de recepción de dicho primer mensaje de entrada en comunicación enviado por el segundo terminal de cliente usando un conector sin procesar, incluyendo el mensaje de confirmación de recepción el número de secuencia recibido como un número de confirmación de recepción;
- una sección de código de programa informático para enviar el mensaje de confirmación de recepción basado en el conector sin procesar al segundo terminal de cliente;
- una sección de código de programa informático para recibir un mensaje de confirmación de recepción basado en el conector sin procesar desde el segundo terminal de cliente, incluyendo dicho mensaje de confirmación de recepción el número de secuencia del primer mensaje de entrada en comunicación enviado al segundo terminal de cliente; y
- una sección de código de programa informático para enviar una confirmación de recepción del mensaje de confirmación de recepción basado en el conector sin procesar, completando dicha confirmación de recepción el establecimiento de la conexión TCP.
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FI20055295A FI119303B (fi) | 2005-06-07 | 2005-06-07 | Liitettävyys tilatietoisten palomuurien välillä |
| FI20055295 | 2005-06-07 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| ES2299169T3 true ES2299169T3 (es) | 2008-05-16 |
Family
ID=34778432
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| ES06764483T Active ES2299169T3 (es) | 2005-06-07 | 2006-06-07 | Conectividad sobre cortafuegos de estado. |
Country Status (9)
| Country | Link |
|---|---|
| US (1) | US8332532B2 (es) |
| EP (1) | EP1792468B1 (es) |
| AT (1) | ATE385121T1 (es) |
| DE (1) | DE602006000489T2 (es) |
| DK (1) | DK1792468T3 (es) |
| ES (1) | ES2299169T3 (es) |
| FI (1) | FI119303B (es) |
| NO (1) | NO337990B1 (es) |
| WO (1) | WO2006131600A1 (es) |
Families Citing this family (20)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7899031B2 (en) | 2007-11-20 | 2011-03-01 | Microsoft Corporation | Locally terminating an established connection |
| JP2010200300A (ja) * | 2009-01-28 | 2010-09-09 | Meidensha Corp | Ｔｃｐ通信方式 |
| US20110219113A1 (en) * | 2010-03-02 | 2011-09-08 | Grewal Avininder Pal Singh | Method and system for client assisted stateful handling of packets in a communications network |
| US8776207B2 (en) | 2011-02-16 | 2014-07-08 | Fortinet, Inc. | Load balancing in a network with session information |
| CN102130910B (zh) * | 2011-02-28 | 2015-04-29 | 华为技术有限公司 | Tcp代理插入和卸载方法及业务网关设备 |
| US9998545B2 (en) * | 2011-04-02 | 2018-06-12 | Open Invention Network, Llc | System and method for improved handshake protocol |
| GB201210598D0 (en) | 2012-06-14 | 2012-08-01 | Microsoft Corp | Notification of communication events |
| GB201210600D0 (en) | 2012-06-14 | 2012-08-01 | Microsoft Corp | Call invites |
| GB201210596D0 (en) | 2012-06-14 | 2012-08-01 | Microsoft Corp | Notification of communication events |
| CN103401890B (zh) * | 2012-06-14 | 2017-03-01 | 微软技术许可有限责任公司 | 用于通信事件的通知的装置和方法 |
| GB2504461B (en) | 2012-06-14 | 2014-12-03 | Microsoft Corp | Notification of communication events |
| WO2014077614A1 (en) * | 2012-11-19 | 2014-05-22 | Samsung Sds Co., Ltd. | Anti-malware system, method of processing data in the same, and computing device |
| US9426262B2 (en) | 2014-04-07 | 2016-08-23 | Cisco Technology, Inc. | Transport control protocol sequence number recovery in stateful devices |
| US9825913B2 (en) * | 2014-06-04 | 2017-11-21 | Nicira, Inc. | Use of stateless marking to speed up stateful firewall rule processing |
| GB2531586A (en) | 2014-10-23 | 2016-04-27 | Ibm | Methods and systems for starting computerized system modules |
| US10958625B1 (en) * | 2018-03-06 | 2021-03-23 | F5 Networks, Inc. | Methods for secure access to services behind a firewall and devices thereof |
| US11875172B2 (en) | 2020-09-28 | 2024-01-16 | VMware LLC | Bare metal computer for booting copies of VM images on multiple computing devices using a smart NIC |
| US11995024B2 (en) | 2021-12-22 | 2024-05-28 | VMware LLC | State sharing between smart NICs |
| US11899594B2 (en) | 2022-06-21 | 2024-02-13 | VMware LLC | Maintenance of data message classification cache on smart NIC |
| US11928062B2 (en) | 2022-06-21 | 2024-03-12 | VMware LLC | Accelerating data message classification with smart NICs |
Family Cites Families (8)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6088796A (en) * | 1998-08-06 | 2000-07-11 | Cianfrocca; Francis | Secure middleware and server control system for querying through a network firewall |
| US20050125532A1 (en) * | 2000-05-26 | 2005-06-09 | Gur Kimchi | Traversing firewalls and nats |
| WO2002071717A2 (en) * | 2000-12-14 | 2002-09-12 | Vocaltec Communications Ltd. | Traversing firewalls and nats |
| US7028051B1 (en) | 2000-09-29 | 2006-04-11 | Ugs Corp. | Method of real-time business collaboration |
| US7043644B2 (en) * | 2001-01-31 | 2006-05-09 | Qurio Holdings, Inc. | Facilitating file access from firewall-protected nodes in a peer-to-peer network |
| US7117267B2 (en) | 2001-06-28 | 2006-10-03 | Sun Microsystems, Inc. | System and method for providing tunnel connections between entities in a messaging system |
| US7207061B2 (en) * | 2001-08-31 | 2007-04-17 | International Business Machines Corporation | State machine for accessing a stealth firewall |
| US7620808B2 (en) | 2003-06-19 | 2009-11-17 | Nokia Corporation | Security of a communication system |
-
2005
- 2005-06-07 FI FI20055295A patent/FI119303B/fi not_active IP Right Cessation
-
2006
- 2006-06-07 US US11/663,098 patent/US8332532B2/en not_active Expired - Fee Related
- 2006-06-07 EP EP06764483A patent/EP1792468B1/en not_active Not-in-force
- 2006-06-07 ES ES06764483T patent/ES2299169T3/es active Active
- 2006-06-07 DE DE602006000489T patent/DE602006000489T2/de active Active
- 2006-06-07 WO PCT/FI2006/050238 patent/WO2006131600A1/en active IP Right Grant
- 2006-06-07 AT AT06764483T patent/ATE385121T1/de not_active IP Right Cessation
- 2006-06-07 DK DK06764483T patent/DK1792468T3/da active
-
2007
- 2007-03-15 NO NO20071396A patent/NO337990B1/no not_active IP Right Cessation
Also Published As
| Publication number | Publication date |
|---|---|
| US8332532B2 (en) | 2012-12-11 |
| DE602006000489T2 (de) | 2009-01-22 |
| FI20055295A (fi) | 2006-12-08 |
| DE602006000489D1 (es) | 2008-03-13 |
| EP1792468A1 (en) | 2007-06-06 |
| WO2006131600A1 (en) | 2006-12-14 |
| FI119303B (fi) | 2008-09-30 |
| DK1792468T3 (da) | 2008-05-26 |
| EP1792468B1 (en) | 2008-01-23 |
| ATE385121T1 (de) | 2008-02-15 |
| US20080028097A1 (en) | 2008-01-31 |
| NO337990B1 (no) | 2016-07-18 |
| FI20055295A0 (fi) | 2005-06-07 |
| NO20071396L (no) | 2008-02-26 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| ES2299169T3 (es) | Conectividad sobre cortafuegos de estado. | |
| US10616379B2 (en) | Seamless mobility and session continuity with TCP mobility option | |
| US7831715B2 (en) | Communication system, communication method, and program | |
| KR101263783B1 (ko) | 릴레이 서버를 이용한 데이터 전송 시스템 및 방법 | |
| US6826627B2 (en) | Data transformation architecture | |
| ES2637069T3 (es) | Método y aparato de implementación de proxy de red | |
| US9769289B2 (en) | TCP communication scheme | |
| KR101519520B1 (ko) | 건물들의 원격 제어에 사용되는 데이터 전달 네트워크를 구현하기 위한 디바이스 어레인지먼트 및 방법 | |
| US20090041006A1 (en) | Method and system for providing internet key exchange | |
| JP2007516625A (ja) | パーソナルリモートファイヤウォール | |
| US20110047261A1 (en) | Information communication apparatus, information communication method, and program | |
| US11528326B2 (en) | Method of activating processes applied to a data session | |
| US6757734B1 (en) | Method of communication | |
| CN110784436B (zh) | 用于维持互联网协议安全隧道的方法和设备 | |
| JP2006185194A (ja) | サーバ装置、通信制御方法及びプログラム | |
| JP2010283762A (ja) | 通信経路設定装置、通信経路設定方法、プログラム、及び記憶媒体 | |
| WO2003017586A1 (en) | Device, method and system for enhanced routing in mobile ip networking | |
| CN110351308B (zh) | 一种虚拟专用网络通信方法和虚拟专用网络设备 | |
| Demmer et al. | RFC 7242: Delay-Tolerant Networking TCP Convergence-Layer Protocol | |
| KR101402296B1 (ko) | 패킷 서비스 방법, 시스템 및 게이트웨이 | |
| JP2006352710A (ja) | パケット中継装置及びプログラム | |
| CN104767781A (zh) | 一种tcp代理装置以及方法 | |
| CN114553567B (zh) | 多方安全计算中的网络传输方法、系统、存储介质及计算设备 | |
| CN106685701B (zh) | 断开IPSec VPN连接方法及装置 | |
| KR20060096986A (ko) | 개인 원격 방화벽 |