stringtranslate.com

Protocolo de control de puertos

El Protocolo de control de puertos ( PCP ) es un protocolo de redes informáticas que permite a los hosts de redes IPv4 o IPv6 controlar cómo los paquetes IPv4 o IPv6 entrantes son traducidos y reenviados por un enrutador ascendente que realiza la traducción de direcciones de red (NAT) o el filtrado de paquetes . Al permitir que los hosts creen reglas explícitas de reenvío de puertos , el manejo del tráfico de red se puede configurar fácilmente para que los hosts ubicados detrás de NAT o firewalls sean accesibles desde el resto de Internet (para que también puedan actuar como servidores de red ), lo cual es un requisito para muchas aplicaciones. [1] [2]

Además, las reglas explícitas de reenvío de puertos disponibles a través de PCP permiten a los hosts reducir la cantidad de tráfico generado al eliminar soluciones alternativas en forma de mensajes salientes NAT keepalive , que son necesarios para mantener las conexiones a los servidores y para diversas técnicas transversales de NAT , como la perforación de agujeros TCP . Al mismo tiempo, un menor tráfico generado reduce el consumo de energía , mejorando directamente la duración de la batería de los dispositivos móviles . [1]

PCP se estandarizó en 2013 como sucesor del Protocolo de mapeo de puertos NAT (NAT-PMP), con el que comparte conceptos de protocolo y formatos de paquetes similares. [3] PCP agrega soporte para IPv6 y escenarios NAT adicionales.

En entornos donde se utiliza un IGD UPnP en la red local, se requiere integrar en el IGD una función de interfuncionamiento entre el IGD UPnP y el PCP. La función de interfuncionamiento UPnP IGD-PCP se especifica en RFC6970. [4]

Las opciones de DHCP (IPv4 e IPv6) para configurar hosts con direcciones IP de servidor de Protocolo de control de puertos (PCP) se especifican en RFC7291. [5] El procedimiento a seguir para seleccionar un servidor entre una lista de servidores PCP se analiza en RFC7488. [6]

En entornos donde se implementa NAT64, PCP permite aprender los prefijos IPv6 utilizados por un dispositivo NAT64 controlado por PCP para crear direcciones IPv6 convertidas a IPv4 mediante NAT64 (RFC7225). [7]

Descripción general

Muchas aplicaciones e implementaciones de equipos de red requieren que se pueda acceder a sus ubicaciones de red desde fuera de sus redes locales , siguiendo el modelo originalmente previsto de conectividad IP de extremo a extremo a través de Internet, para que puedan operar como servidores de red y aceptar conexiones de clientes remotos . Un ejemplo de dicho equipo es una cámara IP , que incluye un servidor de red que proporciona vigilancia remota a través de redes IP.

Por lo general, las implementaciones de equipos de red colocan los dispositivos detrás de enrutadores o firewalls que realizan NAT (para permitir compartir una dirección IPv4 , por ejemplo) o filtrado de paquetes (para mejorar la seguridad y protección de la red), lo que termina rompiendo la conectividad de extremo a extremo. y hacer que los equipos y las aplicaciones sean inaccesibles desde el resto de Internet. [1] [3]

El problema

Hacer que el equipo implementado sea accesible, al extender su función de servidor más allá de la red local, requiere una configuración manual del reenvío de puertos en la puerta de enlace de la red (que generalmente es un CPE ) o soluciones alternativas a nivel de aplicación que inicien conexiones desde el equipo implementado a intermediarios adicionales. servidores utilizados para "fusionar" esas conexiones de "perforación de firewall" y conexiones de los clientes reales. Ambos enfoques tienen sus desventajas: la configuración manual de CPE suele ser inconveniente o imposible, mientras que el uso de servidores intermedios adicionales aumenta la complejidad y el costo. [2] [3]

Por ejemplo, un juego de ordenador en línea (que actúa como cliente) requiere comunicación con un servidor de juego para intercambiar datos del juego . Para que un servidor de juegos pueda proporcionar datos a sus clientes, esos clientes deben ser accesibles al servidor. Por lo general, los clientes inician conexiones con el servidor del juego para abrir canales de comunicación. Sin embargo, estas conexiones abiertas pueden quedar inactivas y posteriormente cerrarse mediante puertas de enlace de red, lo que lleva a la necesidad de mantenerlas mediante el uso de una forma de mensajes de mantenimiento de actividad. [3] Los mensajes Keepalive son pequeños mensajes que se envían entre el cliente y el servidor que crean tráfico a través de un canal de comunicación y, por lo tanto, evitan que los servidores de puerta de enlace lo cierren. Por tanto, mantener viva una conexión requiere un intercambio constante de mensajes vacíos entre el cliente y el servidor. Esto aumenta la conversación en la red, desperdicia ancho de banda de la red y ciclos de CPU y disminuye la autonomía de los dispositivos que funcionan con baterías .

Además, algunas aplicaciones de red (por ejemplo, FTP ) requieren la apertura dinámica de múltiples conexiones, lo que implica puertas de enlace a nivel de aplicación (ALG) y, además, aumenta la complejidad. [2] [3]

PCP como solución

PCP permite que los equipos y las aplicaciones creen asignaciones explícitas entre una dirección IP , protocolo y puerto externos , y una dirección IP, protocolo y puerto internos. Con asignaciones tan explícitas implementadas, la comunicación entrante puede llegar a los hosts detrás de un NAT o firewall, lo que expande sus funciones de servidor más allá de los límites de las redes locales o hace uso de varios servicios simplificados y que consumen menos recursos. Las asignaciones creadas son permanentes en la medida en que tienen una vida útil conocida que se puede extender, lo cual es similar a la forma en que el Protocolo de configuración dinámica de host (DHCP) implementa sus concesiones . Al mismo tiempo, PCP permite que las aplicaciones creen asignaciones adicionales dinámicamente según sea necesario, lo que reduce o elimina la necesidad de tener dispositivos NAT y firewalls habilitados para ALG . [1] [3]

Las asignaciones explícitas creadas tienen una vida útil conocida, generalmente de varias horas, sin necesidad de intercambiar mensajes de mantenimiento de actividad a nivel de aplicación entre hosts y servidores con el fin de preservar la asignación. Como resultado, el uso de la red y el consumo de energía se reducen, y ya no es necesario implementar la lógica de mantenimiento de actividad a nivel de aplicación en el lado del cliente y del servidor. La respuesta de mapeo PCP proporciona a la aplicación parámetros asociados visibles externamente (dirección IP, protocolo y puerto) que luego pueden anunciarse a otros clientes de manera específica de la aplicación para que se puedan establecer conexiones entrantes. Además, PCP puede informar a las aplicaciones cuando se cambia la dirección IP externa mientras ya se ha establecido una asignación. [1] [3]

PCP puede manejar varios tipos de NAT, brindando soporte para NAT64 , NAT66 y NAT44 ; También se admite la inclusión de PCP en dispositivos de firewall IPv4 e IPv6. PCP está diseñado para usarse tanto en puntos de agregación a gran escala (por ejemplo, como parte de NAT de nivel de operador ) como dentro de dispositivos de nivel de consumidor menos costosos . Se admiten tanto mapeos a largo plazo (para una cámara IP o un sensor de temperatura que actúa como servidor, por ejemplo) como a corto plazo (mientras se juega un juego de computadora en línea, por ejemplo). [1] [2] [3]

PCP admite protocolos de capa de transporte que utilizan números de puerto de 16 bits (por ejemplo, TCP , UDP , protocolo de transmisión de control de flujo (SCTP) o protocolo de control de congestión de datagramas (DCCP). Protocolos que no utilizan números de puerto (por ejemplo, protocolo de reserva de recursos) . (RSVP), Encapsulating Security Payload (ESP), ICMP o ICMPv6 ) son compatibles con las funciones de firewall IPv4, firewall IPv6 y NPTv6 (traducción de prefijo IPv6), pero no pueden ser compatibles con más de un cliente por dirección IP externa en el caso de NAT. [ 3]

La especificación PCP no define un mecanismo para tratar con redes multitarjeta (que tienen múltiples puertas de enlace de red o rutas predeterminadas ). No obstante, es posible implementar PCP en dichas redes utilizando un mecanismo de coordinación como conntrackd . Sin embargo, si las diferentes redes tienen cada una su propia dirección IP externa, una asignación PCP determinada solo puede usar una u otra porque el protocolo requiere que se proporcione una dirección IP externa específica al cliente. Si esa red dejara de estar disponible, la asignación de PCP tendría que actualizarse para utilizar una dirección IP externa de la otra red. [3]

La especificación PCP no define un mecanismo para informar a las computadoras remotas sobre la dirección IP, el protocolo y el puerto para la conexión entrante. RFC6887 establece que PCP no proporciona ninguna función de encuentro y esto debe hacerse de una manera específica de la aplicación, como usar servidores de servicios de nombres externos.

Historia

PCP se estandarizó en 2013 como sucesor del Protocolo de mapeo de puertos NAT ( NAT-PMP ), compartiendo conceptos de protocolo y formatos de paquetes similares con él. Como una de las diferencias de diseño, NAT-PMP está prácticamente limitado a la implementación en dispositivos de consumo, mientras que PCP está diseñado para admitir también equipos de nivel de operador . [3] : 50, 87  Desde 2005, NAT-PMP se ha implementado en varios productos Apple . [8] : 1 

PCP se relaciona con el Protocolo de dispositivo de puerta de enlace de Internet (UPnP IGD), que se estandarizó en 2001 como parte de la especificación UPnP . Si bien el IGD UPnP es complejo y está diseñado para configuración manual, PCP está diseñado para simplicidad y uso automatizado dentro de aplicaciones de software. La especificación NAT-PMP contiene una lista de los problemas con UPnP IGD que provocaron la creación de NAT-PMP y, posteriormente, su sucesor PCP. [8] : 26–32 

uso de PCP

Seguridad

Excluyendo a los atacantes capaces de alterar los paquetes de red intercambiados mientras se crea un mapeo PCP explícito (paquetes que contienen la negociación necesaria para establecer un mapeo explícito, que se intercambia entre hosts y dispositivos NAT o firewalls habilitados para PCP), PCP se considera seguro como siempre que las asignaciones explícitas creadas no excedan el dominio de las asignaciones implícitas. En otras palabras, las asignaciones implícitas se crean como resultado de la forma en que los dispositivos NAT y los firewalls manejan las conexiones salientes regulares de los clientes, lo que significa que PCP es seguro siempre que no se introduzcan nuevas posibilidades de asignación a través del mecanismo de asignación explícito. [3]

Desde el punto de vista de la seguridad , una característica importante de PCP es la opción de solicitud de asignación de THIRD_PARTY . Cuando se usa, esta opción significa que la dirección IP especificada adicionalmente como parte de la solicitud de mapeo debe usarse como la dirección interna para el mapeo explícito creado, en lugar de seguir el comportamiento predeterminado de usar la dirección IP de origen del paquete de solicitud de mapeo real para ese objetivo. Dichas solicitudes de mapeo pueden terminar con un dispositivo NAT habilitado para PCP o un firewall que otorgue privilegios de mapeo explícito superiores a los permitidos por los mapeos implícitos debido a reglas desconocidas impuestas en otros lugares para la dirección IP especificada, permitiendo de esa manera que un atacante robe algo de tráfico o realice un ataque de denegación de servicio (DoS). [3]

Además, los mecanismos de seguridad PCP explícitos están disponibles como extensiones del protocolo PCP, proporcionando mecanismos de control de acceso y autenticación mediante el uso de un canal de señalización en banda autenticado y protegido por integridad , que se basa en el Protocolo de autenticación extensible (EAP) para realizar la autenticación entre dispositivos. involucrados en una sesión de negociación del PCP. Dichos dispositivos NAT o firewalls habilitados para PCP aún pueden aceptar solicitudes de mapeo no autenticadas; al mismo tiempo, se siguen aplicando todas las restricciones de mapeo explícitas descritas anteriormente. [1] [3] [11]

Internos

Internamente, PCP funciona intercambiando mensajes de control entre hosts y dispositivos NAT o firewalls habilitados para PCP (denominados servidores), utilizando el Protocolo de datagramas de usuario (UDP) como protocolo subyacente. Esta comunicación consiste en solicitudes de mapeo de puertos creadas por los hosts que dan como resultado respuestas una vez enviadas y procesadas por los servidores. Siguiendo la naturaleza de falta de confiabilidad de UDP, lo que significa que los datagramas UDP se pueden perder, duplicar o reordenar, después de enviar una solicitud no hay garantía de una respuesta de ningún tipo, por lo que las solicitudes del host también se denominan "sugerencias". Además de las respuestas directas, los servidores también generan notificaciones gratuitas, por ejemplo, notificaciones de unidifusión para informar a los hosts sobre cambios en la dirección IP externa. [1] [3]

Los mensajes intercambiados no contienen medios para determinar a qué transacción pertenecen ni qué etapa de una "sesión" representan. Un diseño tan simplificado se basa en que todos los mensajes sean autodescriptivos y completos, sin que se requiera contexto adicional para que cada mensaje se procese exitosamente. Los servidores pueden decidir ignorar silenciosamente las solicitudes del host, en caso de que no puedan procesarlas en ese momento; en tales casos, los hosts deben retransmitir la solicitud. Además, los hosts pueden decidir con seguridad ignorar silenciosamente cualquier respuesta de mapeo no deseada. [3]

Con el fin de crear solicitudes PCP, la dirección IP del servidor se configura manualmente en el host, se encuentra como parte del contrato de arrendamiento DHCP del host o se establece en la puerta de enlace predeterminada configurada del host . Los mensajes de solicitud de host se envían desde cualquier puerto UDP de origen en un cliente al puerto UDP 5351 del servidor que escucha; Las notificaciones no solicitadas del servidor de multidifusión (como anuncios de reinicio del servidor) se envían desde el puerto UDP 5351 del servidor al puerto UDP 5350 en los hosts que escuchan. [3]

La longitud máxima de la carga útil UDP para todos los mensajes PCP es de 1100 octetos . Cada mensaje PCP consta de un encabezado de solicitud o respuesta que contiene un código de operación que determina la operación asociada, cualquier información relevante específica del código de operación (como qué puertos se asignarán) y cero o más opciones (como la opción THIRD_PARTY descrita anteriormente). . Los códigos de resultado se devuelven como parte de las respuestas del servidor; Cada código de resultado tiene una vida útil asociada, que indica a los hosts cuándo se pueden reintentar o se deben repetir ciertas operaciones. Por ejemplo, la duración de los resultados puede especificar cuánto tiempo se espera que persista una condición de falla o cuánto durará la asignación creada. [3]

Ver también

Referencias

  1. ^ abcdefgh Dan Wing (diciembre de 2011). "Protocolo de control portuario". La revista del protocolo de Internet . Sistemas Cisco . Consultado el 31 de enero de 2014 .
  2. ^ abcd "Descripción general del protocolo de control de puertos (Junos OS 13.3)". Redes de enebro . 14 de agosto de 2013 . Consultado el 31 de enero de 2014 .
  3. ^ abcdefghijklmnopqrs D. Ala; S. Cheshire; el señor Boucadair; R. Penno; P. Selkirk (abril de 2013). Ala, D. (ed.). "RFC 6887: Protocolo de control de puertos (PCP)". Grupo de trabajo de ingeniería de Internet (IETF). doi : 10.17487/RFC6887 . Consultado el 5 de junio de 2023 . {{cite journal}}: Citar diario requiere |journal=( ayuda )
  4. ^ Boucadair, M.; Penno, R.; Wing, D. (julio de 2013). "Dispositivo de puerta de enlace de Internet Universal Plug and Play (UPnP): función de interfuncionamiento del protocolo de control de puertos (IGD-PCP IWF)". doi : 10.17487/rfc6970 . {{cite journal}}: Citar diario requiere |journal=( ayuda )
  5. ^ Boucadair, M.; Penno, R.; Wing, D. (julio de 2014). "Opciones de DHCP para el protocolo de control de puertos (PCP)". doi : 10.17487/rfc7291 . {{cite journal}}: Citar diario requiere |journal=( ayuda )
  6. ^ Boucadair, M.; Penno, R.; Ala, D.; Patil, P.; Reddy, T. (marzo de 2015). "Selección del servidor del Protocolo de control de puertos (PCP)". doi : 10.17487/rfc7488 . {{cite journal}}: Citar diario requiere |journal=( ayuda )
  7. ^ Boucadair, M. (mayo de 2014). "Descubrimiento de prefijos NAT64 IPv6 mediante el protocolo de control de puertos (PCP)". doi : 10.17487/rfc7225 . {{cite journal}}: Citar diario requiere |journal=( ayuda )
  8. ^ ab S. Cheshire; M. Krochmal (abril de 2013). "RFC 6886: Protocolo de mapeo de puertos NAT (NAT-PMP)". Grupo de trabajo de ingeniería de Internet (IETF). doi : 10.17487/RFC6886 . Consultado el 8 de agosto de 2014 . {{cite journal}}: Citar diario requiere |journal=( ayuda )
  9. ^ https://developer.apple.com/documentation/dnssd/kdnsserviceerr_natportmappingunsupported/
  10. ^ https://datatracker.ietf.org/doc/html/draft-ietf-pcp-dslite-00
  11. ^ M. Cullen; S. Hartman; D. Zhang; T. Reddy (septiembre de 2015). "RFC 7652: Mecanismo de autenticación del Protocolo de control de puertos (PCP)". Grupo de trabajo de ingeniería de Internet (IETF). doi : 10.17487/RFC7652 . Consultado el 29 de abril de 2016 . {{cite journal}}: Citar diario requiere |journal=( ayuda )

enlaces externos