WO2014207262A1 - Un método para comunicaciones seguras a través de redes diferentes usando el protocolo socks - Google Patents

Un método para comunicaciones seguras a través de redes diferentes usando el protocolo socks Download PDF

Info

Publication number
WO2014207262A1
WO2014207262A1 PCT/ES2013/070415 ES2013070415W WO2014207262A1 WO 2014207262 A1 WO2014207262 A1 WO 2014207262A1 ES 2013070415 W ES2013070415 W ES 2013070415W WO 2014207262 A1 WO2014207262 A1 WO 2014207262A1
Authority
WO
WIPO (PCT)
Prior art keywords
icmp
socks
protocol
communication
server
Prior art date
Application number
PCT/ES2013/070415
Other languages
English (en)
French (fr)
Inventor
Ronald PABLOS SÁNCHEZ
Original Assignee
Telefonica Digital España, S.L.U.
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 Telefonica Digital España, S.L.U. filed Critical Telefonica Digital España, S.L.U.
Priority to PCT/ES2013/070415 priority Critical patent/WO2014207262A1/es
Publication of WO2014207262A1 publication Critical patent/WO2014207262A1/es

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/64—Hybrid switching systems
    • H04L12/6418—Hybrid transport

Definitions

  • the present invention relates to the field of communications and network protocols and, more particularly, to a method for secure communications over different networks using the SOCKS protocol.
  • SOCKS SOCKet Secure
  • the SOCKS protocol proposes an infrastructure for client-server applications, in both domains of the transmission control protocol (TCP) and the user datagram protocol (UDP), providing a secure model for moving from the internal network to the external network.
  • TCP transmission control protocol
  • UDP user datagram protocol
  • Fig. 1 illustrates a common communication through a SOCKS server.
  • the basic idea on which SOCKS is based is to have a SOCKS server that initiates connections to the external host on behalf of an internal host. Authentication associated with the process offers fairly accurate access to the scrolling process.
  • a SOCKS server can provide the following types of connectivity, to facilitate communications between internal and external hosts: TCP connections initiated by the internal host; TCP connections initiated by the external host; and UDP connections initiated by the internal host.
  • SOCKS servers are used as web proxies, because they can open outward TCP connections on behalf of a client browser.
  • the SOCKS server is not an HTTP proxy, although it can be used as such.
  • SOCKS operates at a lower level than HTTP and provides a raw TCP / UDP relay. In addition, it also allows a connection initiated from an external host, required, for example, for active FTP connections.
  • SOCKS operates at the transport level, many applications can benefit from this fact and use a SOCKS server for application communications.
  • applications such as FTP, HTTP, GOPHER, TELNET, etc.
  • an internal host when it wishes to establish a connection with an external host, it opens a TCP connection with the SOCKS server. Once the TCP connection is successful, an authentication method is negotiated. If the negotiation is successful, the client sends a request for details and the server responds with success or error. Any request such as responses may include encapsulation for integrity and confidentiality purposes depending on the negotiated authentication method. After a satisfactory response, a client can start passing the data to the server socks that will relay them to the destination. Similarly, the data that arrives at the SOCKS server for the client will be sent to that client. If the selected authentication method supports encapsulation for integrity and / or confidentiality purposes, the data is encapsulated using method-dependent encapsulation.
  • Fig. 3 after the negotiation between the client and the SOCKS server, they agree on which UDP ports they will use to communicate with each other.
  • a UDP SOCKS header as illustrated in Fig. 4, must be added to the datagrams between the client and the SOCKS server, basically to indicate the remote destination of the datagrams.
  • the selected authentication method provides encapsulation for purposes of authenticity, integrity and / or confidentiality, the datagram MUST be encapsulated using the appropriate encapsulation.
  • ADDRESS TYPE address type of the following addresses:
  • the X'hh 'syntax is used to indicate the value of the single octet.
  • SOCKS mentioned, defining a new type of secure communication in the SOCKS protocol (apart from TCP and UDP) that will also allow ICMP communications.
  • the present invention exceeds the aforementioned object by providing a method for secure communications over different networks between at least one client device and one server device through a secure proxy server using the SOCKS protocol, wherein said client device and said Server device are connected to different networks.
  • the proposed method comprises a first communication between said client device and said secure proxy server through a transport protocol, such as the UDP protocol, of the group of Internet protocols supported by the SOCKS protocol and a second communication between said secure proxy server with said server device through an ICMP protocol of the Internet protocol group.
  • said second communication comprises sending, via the secure proxy server, of ICMP messages using the ICMP protocol of said group of Internet protocols; and said first communication comprises, in order to allow said second communication, to adapt a transport protocol datagram, adding an ICMP SOCKS header and the ICMP data payload in said transport protocol datagram.
  • the ICMP SOCKS header includes the type of ICMP messages with an identifier and a sequence number.
  • the ICMP messages that have been sent are included in an embodiment of the adapted transport protocol datagram.
  • the identifier and sequence number fields are preferably used to match requests and responses between the client device and the secure proxy server. For example, echo request and echo response messages for IPv4 (RFC 792) and for IPv6 (RFC 4443).
  • the data field of said ICMP SOCKS header includes a response of said ICMP messages sent without including the type, code and checksum fields.
  • the ICMP error message may include part of the ICMP message request.
  • the SOCKS server is responsible for deciding to which final destination the ICMP message is sent, so that in the event of an error, the original ICMP message sent by the SOCKS server can be partly contained in the error response, including the fields Identifier and sequence number. These two fields are then changed to the originals used between the client device to allow comparison of requests with responses.
  • said first communication is made after an authentication process successfully completed between said client device and said secure proxy server, so if the authentication process supports encapsulation, the transport protocol datagram can be encapsulated for purposes of authenticity, integrity and / or confidentiality.
  • Fig. 1 shows a conventional communication through a SOCKS server.
  • Fig. 2 shows an example of a conventional TCP operation executed through a SOCKS server.
  • Fig. 3 shows an example of a conventional UDP operation executed through a SOCKS server.
  • Fig. 4 shows an example of a UDP SOCKS header that is added to the datagrams between a client and the SOCKS server in a UDP operation.
  • Fig. 5 shows the interaction between a client and a SOCKS server for a UDP communication.
  • Fig. 6 shows the proposed interaction between a client and a SOCKS server for an ICMP communication.
  • Fig. 7 shows the proposed ICMP header of the subset of ICMP messages used in the present invention.
  • Fig. 8 shows the proposed ICMP SOCKS header added in the UDP SOCKS header.
  • Fig. 9 shows the header that is returned to the client in the case of an error response.
  • Fig. 10 shows an example of the messages and attributes used in a SOCKS request in accordance with RFC 1928 specification.
  • Fig. 11 shows the ICMP retransmission process, followed by the proposed method according to one embodiment.
  • the present invention is an extension of the SOCKS RFC 1928 protocol that includes a subset of ICMP messages.
  • Fig. 6 shows the proposed interaction between a client device (or client) and a SOCKS server for ICMP communication. It can be seen that the interaction is the same as the UDP case illustrated in Fig. 5. The difference is the ICMP SOCKS header added to the UDP datagram.
  • the message body of the ICMP request is transmitted in a UDP datagram to the SOCKS server, with the ICMP SOCKS header.
  • the SOCKS server will retransmit the ICMP message directly using the ICMP protocol.
  • an ICMP response message body can be encapsulated in a UDP datagram with the corresponding ICMP SOCKS header.
  • the ICMP header of the subset of ICMP messages covered by the present invention is as shown in Fig. 7.
  • the ICMP SOCKS illustrated in Fig. 8 is used in front of the ICMP data payload.
  • the error message will be sent to the client with the header illustrated in the
  • the "Data” field will contain the ICMP error message, except for the first 4 octets (the “Type”, “Code” and “Verification Sum” fields), which are clipped because they are not necessary since the " Type "and” Code "are already included in the header of Fig. 9 and” Verification sum "is not necessary.
  • the IP header and the first 8 octets of the original ICMP data will be those used by the SOCKS server with the server device, changing the "identifier" and the "sequence number" contained in the first 8 octets of the original ICMP data by those originally used by the SOCKS client.
  • the SOCKS server will receive an ICMP request through a UDP datagram with the ICMP SOCKS header and the ICMP data payload.
  • the SOCKS server will form an ICMP datagram with the ICMP SOCKS header information and data payload, and send it to the server device.
  • the SOCKS server When the SOCKS server receives an ICMP response from the server device with the customer transaction information, it will form a UDP datagram with the ICMP SOCKS header and the ICMP payload.
  • Fig. 11 schematically illustrates this process.
  • ICMP ⁇ '04 ' An additional order is proposed: ICMP ⁇ '04 ', which will be used for the ICMP communication set forth in the present invention.
  • management systems can use primitive ICMP to perform diagnostics on hosts located in multiple networks.
  • ICMP access must be controlled depending on which system you want to access a particular network.
  • a SOCKS server that supports the proposed extension, with access to multiple networks can help management systems, providing the required security, as well as primitive ICMPs to perform the necessary diagnostics.
  • application servers must serve multiple separate networks, for example, VPNs. It is difficult to have direct ICMP connectivity with all these networks, from all application servers. However, it is easier to have ICMP connectivity at a central point, the SOCKS server. With the present invention, application servers can easily access ICMP services in remote networks without the need for connectivity Direct ICMP with these remote networks.
  • SOCKS server supports a domain name instead of an explicit IP address
  • SOCKS clients can base all requests on domain names, which is useful in service architectures, on which remote hosts are always identified with names domain instead of IP addresses.
  • the present invention will reduce the time to market and will easily expand the portfolio of new services, since the present invention facilitates new service scenarios that will be difficult to perform otherwise.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Communication Control (AREA)
  • Computer And Data Communications (AREA)

Abstract

Comprendiendo el método: una primera comunicación entre un dispositivo cliente y un servidor proxy seguro a través de un protocolo de transporte del grupo de protocolos de Internet soportado por el protocolo SOCKS y una segunda comunicación entre dicho servidor proxy seguro con un dispositivo servidor a través de un protocolo ICMP del grupo de protocolos de Internet, en el que dicha segunda comunicación comprende un envío, mediante el servidor proxy seguro, de mensajes ICMP que usan el protocolo ICMP de dicho grupo de protocolos de Internet, y dicha primera comunicación comprende, con el fin de permitir dicha segunda comunicación, adaptar un datagrama del protocolo de transporte añadiendo una cabecera ICMP SOCKS y la carga útil de datos ICMP en dicho datagrama del protocolo de transporte y en el que la cabecera ICMP SOCKS incluye el tipo de mensajes ICMP con un identificador y un número de secuencia.

Description

Un método para comunicaciones seguras a través de redes diferentes usando el protocolo SOCKS
Campo de la técnica
La presente invención se refiere al campo de las comunicaciones y los protocolos de red y, más particularmente, a un método para comunicaciones seguras a través de redes diferentes usando el protocolo SOCKS.
Estado de la técnica anterior
SOCKet Secure (SOCKS) es un protocolo que facilita las comunicaciones seguras entre hosts que pertenecen a redes diferentes. Estas redes diferentes usan habitualmente cortafuegos de red, para aislar una estructura de red interna de organizaciones de una red externa, tal como Internet.
Con el fin de lograr la comunicación de aplicaciones entre hosts de las redes internas y externas, el protocolo SOCKS propone una infraestructura para las aplicaciones cliente-servidor, en ambos dominios del protocolo de control de transmisión (TCP) y el protocolo de datagramas de usuario (UDP), proporcionando un modelo seguro para desplazarse desde la red interna a la red externa.
La Fig. 1 ilustra una comunicación común a través de un servidor SOCKS. La idea básica en la que se fundamenta SOCKS es tener un servidor SOCKS que inicia conexiones al host externo en nombre de un host interno. La autenticación asociada al proceso ofrece un acceso bastante preciso para el proceso de desplazamiento.
En la última especificación (RFC 1928) del protocolo SOCKS, un servidor SOCKS puede proporcionar los siguientes tipos de conectividades, para facilitar las comunicaciones entre los hosts internos y los externos: conexiones TCP iniciadas por el host interno; conexiones TCP iniciadas por el host externo; y conexiones UDP iniciadas por el host interno.
Con frecuencia, los servidores SOCKS se usan como proxies de web, debido a que pueden abrir conexiones TCP hacia el exterior en nombre de un explorador del cliente. Sin embargo, debe tenerse en cuenta que el servidor SOCKS no es un proxy HTTP, aunque puede usarse como tal. SOCKS opera en un nivel más bajo que HTTP y proporciona una retransmisión TCP/UDP en bruto. Además, permite también una conexión iniciada desde un host externo, requerida, por ejemplo, para las conexiones activas de FTP.
Como SOCKS opera a nivel de transporte, muchas aplicaciones pueden beneficiarse de este hecho y usar un servidor SOCKS para las comunicaciones de aplicaciones. Por ejemplo, aplicaciones tales como FTP, HTTP, GOPHER, TELNET, etc.
En funcionamiento, cuando un host interno desea establecer una conexión con un host externo, abre una conexión TCP con el servidor SOCKS. Una vez que la conexión TCP tiene éxito, se negocia un método de autenticación. Si la negociación tiene éxito, el cliente envía una solicitud de detalles y el servidor responde con éxito o error. Cualquier solicitud como las respuestas puede incluir encapsulacion con fines de integridad y confidencialidad dependiendo del método de autenticación negociado. Después de una respuesta satisfactoria, un cliente puede empezar a pasar los datos al servidor socks que los retransmitirá al destino. De manera similar, los datos que llegan al servidor SOCKS para el cliente se enviarán a dicho cliente. Si el método de autenticación seleccionado soporta encapsulacion con fines de integridad y/o confidencialidad, los datos se encapsulan usando la encapsulacion dependiente del método.
En el caso de un funcionamiento TCP, Fig. 2, después de la negociación con el servidor SOCKS, la comunicación TCP abierta entre el cliente y el servidor SOCKS se usará para la comunicación con el host remoto, actuando el servidor SOCKS como un proxy TCP transparente.
Por otro lado, en el caso de una comunicación UDP, Fig. 3, después de la negociación entre el cliente y el servidor SOCKS, estos están de acuerdo en qué puertos UDP usarán para comunicarse entre sí. Además, debe añadirse una cabecera UDP SOCKS, como se ilustra en la Fig. 4, a los datagramas entre el cliente y el servidor SOCKS, básicamente para indicar el destino remoto de los datagramas. Por supuesto, y al igual que el resto de los casos, si el método de autenticación seleccionado proporciona encapsulacion con fines de autenticidad, integridad y/o confidencialidad, el datagrama DEBE encapsularse usando la encapsulacion adecuada.
Cuando los campos en la cabecera UDP son:
· RESERVADO Reservado X'0000'
• FRAGMENTACIÓN número DE fragmento actual
• TIPO DE DIRECCIÓN tipo de dirección de las direcciones siguientes:
o Dirección IP V4: X'OT
o NOMBRE DE OMINIO: X'03'
o Dirección IP V6: X'04'
• DIRECCIÓN DE DESTINO dirección de destino deseado o IPv4: 4 octetos
o Nombre de dominio: 1 octeto de longitud + N octetos para la cadena de nombre de dominio
o IPv6: 16 octetos
· PUERTO DE DESTINO puerto de destino deseado
• DATOS datos de usuario
La sintaxis X'hh' se usa para indicar el valor del octeto único.
Mientras que hoy en día un servidor SOCKS versión 5 proporciona servicios de conectividad TCP y UDP con hosts remotos, no proporciona el servicio del protocolo de mensajes de control de Internet (ICMP), sobre todo, el servicio de solicitud/respuesta de eco, que es necesario para muchos escenarios de servicio.
Por lo tanto, es un objeto de la presente invención ampliar el protocolo (RFC
1928) SOCKS mencionado, definiendo un nuevo tipo de comunicación segura en el protocolo SOCKS (aparte de TCP y UDP) que permitirá también comunicaciones ICMP.
Sumario de la invención
La presente invención supera el objeto mencionado anteriormente proporcionando un método para las comunicaciones seguras a través de redes diferentes entre al menos un dispositivo cliente y un dispositivo servidor a través de un servidor proxy seguro usando el protocolo SOCKS, en el que dicho dispositivo cliente y dicho dispositivo servidor están conectados a redes diferentes. El método propuesto comprende una primera comunicación entre dicho dispositivo cliente y dicho servidor proxy seguro a través de un protocolo de transporte, tal como el protocolo UDP, del grupo de protocolos de Internet soportado por el protocolo SOCKS y una segunda comunicación entre dicho servidor proxy seguro con dicho dispositivo servidor a través de un protocolo ICMP del grupo de protocolos de Internet.
En el método, dicha segunda comunicación comprende un envío, mediante el servidor proxy seguro, de mensajes ICMP usando el protocolo ICMP de dicho grupo de protocolos de Internet; y dicha primera comunicación comprende, con el fin de permitir dicha segunda comunicación, adaptar un datagrama del protocolo de transporte, añadiendo una cabecera ICMP SOCKS y la carga útil de datos ICMP en dicho datagrama del protocolo de transporte.
De una manera característica y al contrario de las propuestas conocidas, la cabecera ICMP SOCKS incluye el tipo de mensajes ICMP con un identificador y un número de secuencia. Los mensajes ICMP que se han enviado se incluyen en una realización del datagrama del protocolo de transporte adaptado.
Los campos de identificador y número de secuencia se usan preferentemente para equiparar peticiones y respuestas entre el dispositivo cliente y el servidor proxy seguro. Por ejemplo, los mensajes de solicitud de eco y de respuesta de eco para IPv4 (RFC 792) y para IPv6 (RFC 4443).
De acuerdo con una realización, cuando se produce una respuesta de eco, el campo de datos de dicha cabecera ICMP SOCKS incluye una respuesta de dichos mensajes ICMP enviados sin incluir los campos tipo, código y suma de verificación. Además, el mensaje de error ICMP puede incluir parte de la solicitud del mensaje ICMP.
El servidor SOCKS es el responsable de decidir a qué destino final se envía el mensaje ICMP, para que en el caso de un error, el mensaje ICMP original enviado por el servidor SOCKS pueda ser en parte contenido en la respuesta de error, incluyendo los campos identificador y número de secuencia. A continuación, estos dos campos se cambian a los originales usados entre el dispositivo de cliente para permitir la comparación de las peticiones con las respuestas.
En otra realización, dicha primera comunicación se realiza después de un proceso de autenticación completado de manera exitosa entre dicho dispositivo cliente y dicho servidor proxy seguro, por lo que si el proceso de autenticación soporta encapsulación, el datagrama del protocolo de transporte puede encapsularse con fines de autenticidad, integridad y/o confidencialidad.
Breve descripción de los dibujos
Las anteriores y otras ventajas y características se comprenderán más plenamente a partir de la siguiente descripción detallada de las realizaciones, con referencia a la adjunta, que debe considerarse de una manera ilustrativa y no limitativa, en la que:
La Fig. 1 muestra una comunicación convencional a través de un servidor SOCKS.
La Fig. 2 muestra un ejemplo de un funcionamiento TCP convencional ejecutado a través de un servidor SOCKS.
La Fig. 3 muestra un ejemplo de un funcionamiento UDP convencional ejecutado a través de un servidor SOCKS.
La Fig. 4 muestra un ejemplo de una cabecera UDP SOCKS que se añade a los datagramas entre un cliente y el servidor SOCKS en un funcionamiento UDP.
La Fig. 5 muestra la interacción entre un cliente y un servidor SOCKS para una comunicación UDP.
La Fig. 6 muestra la interacción propuesta entre un cliente y un servidor SOCKS para una comunicación ICMP.
La Fig. 7 muestra la cabecera ICMP propuesta del subconjunto de mensajes ICMP usados en la presente invención.
La Fig. 8 muestra la cabecera ICMP SOCKS propuesta añadida en la cabecera UDP SOCKS.
La Fig. 9 muestra la cabecera que se devuelve al cliente en el caso de una respuesta de error.
La Fig. 10 muestra un ejemplo de los mensajes y atributos usados en una solicitud SOCKS de acuerdo con la especificación RFC 1928.
La Fig. 11 muestra el proceso de retransmisión ICMP, seguido por el método propuesto de acuerdo con una realización.
Descripción detallada de las realizaciones preferidas
La presente invención es una ampliación del protocolo SOCKS RFC 1928 que incluye un subconjunto de los mensajes ICMP.
La Fig. 6 muestra la interacción propuesta entre un dispositivo cliente (o cliente) y un servidor SOCKS para la comunicación ICMP. Puede observarse que la interacción es igual al caso UDP ilustrado en la Fig. 5. La diferencia es la cabecera ICMP SOCKS añadida al datagrama UDP.
Así, con este modelo, se transmite el cuerpo del mensaje de la solicitud ICMP en un datagrama UDP al servidor SOCKS, con la cabecera ICMP SOCKS. Después de eso, el servidor SOCKS retransmitirá el mensaje ICMP usando directamente el protocolo ICMP. Por el contrario, puede encapsularse un cuerpo del mensaje de respuesta ICMP en un datagrama UDP con la cabecera ICMP SOCKS correspondiente.
Preferentemente, la cabecera ICMP del subconjunto de mensajes ICMP cubiertos por la presente invención es como se muestra en la Fig. 7.
Como la comunicación entre el cliente y el servidor SOCKS es a través de UDP, el ICMP SOCKS ilustrado en la Fig. 8 se usa delante de la carga útil de los datos ICMP. En la que:
RESERVADO Reservado X'0000'
• TIPO DE DIRECCIÓN Tipo de dirección de las direcciones siguientes:
o Dirección IP V4: X'OT
o NOMBRE DE DOMINIO: X'03'
o Dirección IP V6: X'04'
• DIRECCIÓN DE DESTINO Dirección de destino deseado
· TIPO Tipo de mensaje ICMP
• CÓDIGO El campo de código depende del tipo de mensaje. Como un subtipo.
• IDENTIFICADOR Para equiparar solicitudes con respuestas
• NÚMERO DE SECUENCIA Para equiparar solicitudes con respuestas · DATOS Carga útil de datos ICMP
Después, en el caso de una respuesta de error, de acuerdo con una realización, el mensaje de error se enviará al cliente con la cabecera ilustrada en la
Fig. 9.
En este caso, el campo "Datos" contendrá el mensaje ICMP de error, excepto los primeros 4 octetos (los campos "Tipo", "Código" y "Suma de verificación"), que se recortan porque no son necesarios ya que el "Tipo" y el "Código" ya están incluidos en la cabecera de la Fig. 9 y la "Suma de verificación" no es necesaria. Y, si la carga útil ICMP debe contener la cabecera IP y los primeros 8 octetos de los datos ICMP originales, la cabecera IP y los primeros 8 octetos de los datos ICMP originales serán los usados por el servidor SOCKS con el dispositivo servidor, cambiando el "identificador" y el "número de secuencia " contenidos en los primeros 8 octetos de los datos ICMP originales por los usados por el cliente SOCKS originalmente.
El servidor SOCKS recibirá una solicitud ICMP a través de un datagrama UDP con la cabecera ICMP SOCKS y la carga útil de los datos ICMP. El servidor SOCKS formará un datagrama ICMP con la información de la cabecera ICMP SOCKS y la carga útil de datos, y lo enviará al dispositivo servidor.
Cuando el servidor SOCKS recibe una respuesta ICMP desde el dispositivo servidor con la información de la transacción del cliente, formará un datagrama UDP con la cabecera ICMP SOCKS y la carga útil ICMP. La Fig. 11 ilustra de manera esquemática este proceso.
La solicitud SOCKS se forma como se ilustra en la Fig. 10 (RFC 1928):
En la que:
VERSIÓN Versión del protocolo: X05'
• ORDEN Orden deseada o CONECTAR X'01 '
o ENLAZAR X'02'
o ASOCIAR UDP X'03'
RESERVADO RESERVADO X'00'
· TIPO DE DIRECCIÓN Tipo de dirección de las direcciones siguientes:
o Dirección IP V4: X'OT
o NOMBRE DE DOMINIO: X'03'
o Dirección IP V6: X'04'
· DIRECCIÓN DE DESTINO Dirección destino deseado
• PUERTO DE DESTINO Puerto de destino deseado en el orden de octeto de red
Se propone una orden adicional: ICMP Χ'04', que se usará para la comunicación ICMP expuesta en la presente invención.
En muchas áreas, como la administración de dispositivos y las comunicaciones máquina a máquina, es imprescindible conocer el estado de un dispositivo remoto, es decir, saber si el dispositivo está o no operativo. Con este fin, se usa ampliamente la solicitud/respuesta de eco ICMP. Con un servidor SOCKS que soporta la ampliación propuesta, muchas aplicaciones sin conectividad IP directa a dispositivos por razones de seguridad, pueden aún realizar operaciones como la "Solicitud de eco ICMP" para descubrir la presencia de un dispositivo.
Además, los sistemas de gestión pueden usar la ICMP primitiva para realizar diagnósticos sobre hosts localizados en múltiples redes. Sin embargo, por razones de seguridad, el acceso ICMP debe controlarse dependiendo de qué sistema quiera acceder a una red determinada. Un servidor SOCKS que soporta la ampliación propuesta, con acceso a múltiples redes puede ayudar a los sistemas de gestión, proporcionando la seguridad requerida, así como las ICMP primitivas para realizar los diagnósticos necesarios.
Además, como muchos servidores de aplicaciones todavía requieren, en algunas circunstancias, la comunicación ICMP con hosts en múltiples redes, un servidor SOCKS con la ampliación ICMP puede dar a estas aplicaciones la funcionalidad necesaria, así como las consideraciones de seguridad requeridas.
En muchas implementaciones, los servidores de aplicaciones deben servir a múltiples redes separadas, por ejemplo, VPNs. Es difícil tener conectividad ICMP directa con todas estas redes, desde todos los servidores de aplicaciones. Sin embargo, es más fácil tener conectividad ICMP en un punto central, el servidor SOCKS. Con la presente invención, los servidores de aplicaciones pueden acceder fácilmente a los servicios ICMP en redes remotas sin necesidad de una conectividad ICMP directa con estas redes remotas.
Como el servidor SOCKS admite un nombre de dominio en lugar de una dirección IP explícita, los clientes SOCKS pueden basar todas las solicitudes en nombres de dominio, que es útil en las arquitecturas de servicio, en las que los hosts remotos se identifican siempre con nombres de dominio en lugar de direcciones IP.
Teniendo en cuenta lo que se dijo anteriormente, la presente invención reducirá el tiempo de salida al mercado y ampliará fácilmente la cartera de nuevos servicios, ya que la presente invención facilita nuevos escenarios de servicio que serán difíciles de realizar de otro modo.
El alcance de la presente invención se define por el conjunto de reivindicaciones adjuntas.

Claims

REIVINDICACIONES
1. Un método para las comunicaciones seguras a través de redes diferentes entre al menos un dispositivo cliente y un dispositivo servidor a través de un servidor proxy seguro que usa el protocolo SOCKS, en el que dicho dispositivo cliente y dicho dispositivo servidor están conectados a redes diferentes, comprendiendo el método:
- una primera comunicación entre dicho dispositivo cliente y dicho servidor proxy seguro a través de un protocolo de transporte del grupo de protocolos de Internet soportado por el protocolo SOCKS; y
- una segunda comunicación entre dicho servidor proxy seguro con dicho dispositivo servidor a través de un protocolo ICMP del grupo de protocolos de Internet, en el que
- dicha segunda comunicación comprende un envío, mediante el servidor proxy seguro, de mensajes ICMP usando el protocolo ICMP de dicho grupo de protocolos de Internet; y
- dicha primera comunicación comprende, con el fin de permitir dicha segunda comunicación, adaptar un datagrama del protocolo de transporte añadiendo una cabecera ICMP SOCKS y la carga útil de datos ICMP en dicho datagrama del protocolo de transporte,
estando el método caracterizado porque comprende incluir en dicha cabecera
ICMP SOCKS el tipo de mensajes ICMP con un identificador y un número de secuencia.
2. Un método de acuerdo con la reivindicación 1 , en el que dichos mensajes ICMP enviados incluyen dicho datagrama del protocolo de transporte adaptado.
3. Un método de acuerdo con la reivindicación 1 , en el que se usan los campos de dicho identificador y dicho número de secuencia para equiparar las solicitudes y las respuestas entre el dispositivo cliente y el servidor proxy seguro.
4. Un método de acuerdo con la reivindicación 3, en el que dichas solicitudes y respuestas equiparadas comprenden una solicitud de eco y una respuesta de eco para los protocolos IPv4 e IPv6.
5. Un método de acuerdo con la reivindicación 4, en el que, en el caso de que se produzca un error en dicha respuesta de eco, un campo de datos de dicha cabecera ICMP SOCKS incluye una respuesta de dichos mensajes ICMP enviados sin incluir los campos tipo, código y suma de verificación.
6. Un método de acuerdo con la reivindicación 1 , en el que dicha primera comunicación se realiza después de un proceso de autenticación completado con éxito entre dicho dispositivo cliente y dicho servidor proxy seguro.
7. Un método de acuerdo con la reivindicación 6, en el que el datagrama del protocolo de transporte se encapsula con fines de autenticidad, integridad y/o confidencialidad.
8. Un método de acuerdo con las reivindicaciones anteriores, en el que dicho protocolo de transporte comprende un protocolo UDP.
PCT/ES2013/070415 2013-06-24 2013-06-24 Un método para comunicaciones seguras a través de redes diferentes usando el protocolo socks WO2014207262A1 (es)

Priority Applications (1)

Application Number Priority Date Filing Date Title
PCT/ES2013/070415 WO2014207262A1 (es) 2013-06-24 2013-06-24 Un método para comunicaciones seguras a través de redes diferentes usando el protocolo socks

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/ES2013/070415 WO2014207262A1 (es) 2013-06-24 2013-06-24 Un método para comunicaciones seguras a través de redes diferentes usando el protocolo socks

Publications (1)

Publication Number Publication Date
WO2014207262A1 true WO2014207262A1 (es) 2014-12-31

Family

ID=52141128

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/ES2013/070415 WO2014207262A1 (es) 2013-06-24 2013-06-24 Un método para comunicaciones seguras a través de redes diferentes usando el protocolo socks

Country Status (1)

Country Link
WO (1) WO2014207262A1 (es)

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2005065038A2 (en) * 2004-01-09 2005-07-21 Npx Technologies Ltd. Detecting relayed communications
WO2005065008A2 (en) * 2003-12-29 2005-07-21 Nokia Inc. System and method for managing a proxy request over a secure network using inherited security attributes
WO2012006595A2 (en) * 2010-07-09 2012-01-12 Nicolas Girard Transparent proxy architecture for multi-path data connections

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2005065008A2 (en) * 2003-12-29 2005-07-21 Nokia Inc. System and method for managing a proxy request over a secure network using inherited security attributes
WO2005065038A2 (en) * 2004-01-09 2005-07-21 Npx Technologies Ltd. Detecting relayed communications
WO2012006595A2 (en) * 2010-07-09 2012-01-12 Nicolas Girard Transparent proxy architecture for multi-path data connections

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
DJAHANDARI K ET AL.: "An MBone proxy for an application gateway firewall.Security and Privacy", PROCEEDINGS, 1997 IEEE SYMPOSIUM ON OAKLAND, 4 May 1997 (1997-05-04), CA , USA, pages 72 - 81 *

Similar Documents

Publication Publication Date Title
EP3342127B1 (en) Network packet flow controller with extended session management
Schulzrinne et al. GIST: general internet signalling transport
JP3793083B2 (ja) トンネリングおよび補償を使用するネットワーク・アドレス翻訳によりセキュリティを与えるための方法および装置
ES2704473T3 (es) Atravesamiento de NAT usando perforación de agujero
Patel et al. Securing L2TP using IPsec
US6839338B1 (en) Method to provide dynamic internet protocol security policy service
ES2336898T3 (es) Metodo y red para asegurar el envio seguro de mensajes.
KR101406556B1 (ko) 호스트 시스템 간 접속 확립 방법
US10298616B2 (en) Apparatus and method of securing network communications
ES2618953T3 (es) Disposición de dispositivo y método para implementar una red de transferencia de datos utilizada en el control remoto de propiedades
ES2319171T3 (es) Metodo y sistema para garantizar el reenvio seguro de mensajes.
KR20050122221A (ko) 사설 네트워크와 로밍 모바일 단말 사이의 통신
EP1159815B1 (en) Method and system for distributed network address translation with network security features
Barré Implementation and assessment of modern host-based multipath solutions.
Melia et al. IEEE 802.21 mobility services framework design (MSFD)
JP2020010326A (ja) ＷｉＦｉ管理フレームを利用したデータ送信方法、データ受信方法及びデータ通信方法
WO2014207262A1 (es) Un método para comunicaciones seguras a través de redes diferentes usando el protocolo socks
Abusafat et al. Roadmap of security threats between IPv4/IPv6
Komu et al. Basic host identity protocol (HIP) extensions for traversal of network address translators
Huston et al. In defence of NATs
Pauly et al. TCP encapsulation of IKE and IPsec packets
Schinazi et al. RFC 9484: Proxying IP in HTTP
Huston Multipath tcp
Keränen et al. RFC 9028: Native NAT Traversal Mode for the Host Identity Protocol
Gundavelli et al. RFC 8803: 0-RTT TCP Convert Protocol

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 13888420

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 13888420

Country of ref document: EP

Kind code of ref document: A1