Caja intermedia

Cuadro intermediario en la ruta de datos entre un host de origen y un host de destino

Un middlebox es un dispositivo de red informática que transforma, inspecciona, filtra y manipula el tráfico para fines distintos al reenvío de paquetes . ^[1] Algunos ejemplos de middleboxes son los cortafuegos , los traductores de direcciones de red (NAT), los equilibradores de carga y los dispositivos de inspección profunda de paquetes (DPI). ^[2]

El término middlebox fue acuñado en 1999 por la profesora de informática de la UCLA Lixia Zhang . ^{[1] [3]}

Uso

Los middleboxes se implementan ampliamente tanto en redes públicas como privadas. El hardware de middlebox dedicado se implementa ampliamente en redes empresariales para mejorar la seguridad y el rendimiento de la red; sin embargo, incluso los enrutadores de redes domésticas a menudo tienen firewall integrado, NAT u otra funcionalidad de middlebox. ^[4] Un estudio de 2017 contabilizó más de 1000 implementaciones en sistemas autónomos , en ambas direcciones de flujos de tráfico y en una amplia gama de redes, incluidos operadores móviles y redes de centros de datos. ^[2]

Ejemplos

Los siguientes son ejemplos de middleboxes comúnmente implementados:

• Los firewalls filtran el tráfico basándose en un conjunto de reglas de seguridad predefinidas por un administrador de red. Los firewalls IP rechazan paquetes "basándose únicamente en campos en los encabezados de IP y de transporte (por ejemplo, no permitir el tráfico entrante a ciertos números de puerto , no permitir ningún tráfico a ciertas subredes , etc.)" ^[1]. Otros tipos de firewalls pueden utilizar conjuntos de reglas más complejos, incluidos aquellos que inspeccionan el tráfico en la capa de sesión o de aplicación. ^[5]
• Los sistemas de detección de intrusiones (IDS) monitorean el tráfico y recopilan datos para su análisis fuera de línea en busca de anomalías de seguridad. A diferencia de los firewalls, los IDS no filtran paquetes en tiempo real, ya que son capaces de realizar inspecciones más complejas y deben decidir si aceptan o rechazan cada paquete a medida que llega. ^[6]
• Los traductores de direcciones de red (NAT) reemplazan las direcciones IP de origen y/o destino de los paquetes que los atraviesan. Normalmente, los NAT se implementan para permitir que varios hosts finales compartan una única dirección IP : a los hosts "detrás" del NAT se les asigna una dirección IP privada y sus paquetes destinados a Internet público atraviesan un NAT, que reemplaza su dirección privada interna por una dirección pública compartida. ^[7] Estos son ampliamente utilizados por los proveedores de redes celulares para administrar recursos escasos. ^[8]
• Los optimizadores de WAN mejoran el consumo de ancho de banda y la latencia percibida entre los puntos finales. Los optimizadores de WAN, que suelen implementarse en grandes empresas, se instalan cerca de los puntos finales de envío y recepción de la comunicación; luego, los dispositivos se coordinan para almacenar en caché y comprimir el tráfico que atraviesa Internet. ^[9]
• Los balanceadores de carga proporcionan un punto de entrada a un servicio, pero reenvían los flujos de tráfico a uno o más hosts que realmente brindan el servicio.
• Las redes celulares utilizan middleboxes para garantizar que los escasos recursos de red se utilicen de manera eficiente, así como para proteger los dispositivos clientes.

Críticas y desafíos

Los middleboxes han generado desafíos técnicos para el desarrollo de aplicaciones y han provocado "desprecio" y "consternación" en la comunidad de arquitectura de red ^[10] por violar el principio de extremo a extremo del diseño de sistemas informáticos. ^[11]

Interferencia de la aplicación

Algunos middleboxes interfieren con la funcionalidad de la aplicación, restringiendo o impidiendo que las aplicaciones del host final funcionen correctamente.

En particular, los traductores de direcciones de red (NAT) presentan un desafío en el sentido de que los dispositivos NAT dividen el tráfico destinado a una dirección IP pública entre varios receptores. Cuando las conexiones entre un host en Internet y un host detrás del NAT son iniciadas por el host detrás del NAT, el NAT aprende que el tráfico para esa conexión pertenece al host local. Por lo tanto, cuando el tráfico que viene de Internet está destinado a la dirección pública (compartida) en un puerto particular , el NAT puede dirigir el tráfico al host apropiado. Sin embargo, las conexiones iniciadas por un host en Internet no presentan al NAT ninguna oportunidad de "aprender" a qué host interno pertenece la conexión. Además, el propio host interno puede incluso no conocer su propia dirección IP pública para anunciar a los clientes potenciales a qué dirección conectarse. Para resolver este problema, se han propuesto varios protocolos nuevos. ^{[12] [13] [14]}

Además, debido a que las implementaciones de middlebox por parte de operadores celulares como AT&T y T-Mobile son opacas, los desarrolladores de aplicaciones a menudo "desconocen las políticas de middlebox que aplican los operadores", mientras que los operadores carecen de un conocimiento completo sobre el comportamiento y los requisitos de las aplicaciones. Por ejemplo, un operador estableció un " valor de tiempo de espera agresivo para reciclar rápidamente los recursos mantenidos por conexiones TCP inactivas en el firewall, lo que inesperadamente causó interrupciones frecuentes en conexiones de larga duración y ocasionalmente inactivas mantenidas por aplicaciones como el correo electrónico basado en push y la mensajería instantánea ". ^[8]

Otros desafíos comunes de aplicaciones inducidos por middlebox incluyen servidores proxy web que ofrecen contenido "obsoleto" o desactualizado, ^[15] y firewalls que rechazan el tráfico en los puertos deseados. ^[16]

Extensibilidad y diseño de Internet

Una crítica a los middleboxes es que pueden limitar la elección de protocolos de transporte, lo que limita los diseños de aplicaciones o servicios. Los middleboxes pueden filtrar o descartar el tráfico que no se ajusta a los comportamientos esperados, por lo que se pueden filtrar protocolos o extensiones de protocolo nuevos o poco comunes. ^[17] En concreto, debido a que los middleboxes hacen que los hosts en dominios de direcciones privadas no puedan "pasar identificadores que permitan a otros hosts comunicarse con ellos", han obstaculizado la difusión de protocolos más nuevos como el Protocolo de inicio de sesión (SIP) así como varios sistemas peer-to-peer. ^{[10] [18]} Esta reducción progresiva de la flexibilidad se ha descrito como osificación del protocolo . ^{[19] [20]}

Por el contrario, algunos middleboxes pueden ayudar en la implementación de protocolos al proporcionar una traducción entre protocolos nuevos y antiguos. Por ejemplo, IPv6 se puede implementar en puntos finales públicos, como balanceadores de carga , servidores proxy u otras formas de NAT, con el tráfico de backend enrutado a través de IPv4 o IPv6 .

Véase también

• Conectividad de extremo a extremo
• Establecimiento de conectividad interactiva (ICE)
• Utilidades de recorrido de sesión para NAT (STUN)
• Travesía mediante NAT de retransmisión (TURN)
• Conmutador multicapa

Referencias

1. Brian Carpenter (2002). "Middleboxes: Taxonomía y problemas". Ietf Datatracker . doi :10.17487/RFC3234. RFC  3234 .
2. Shan Huang; Steve Uhlig; Félix Cuadrado (2017). "Middleboxes en Internet: una perspectiva HTTP". Conferencia sobre medición y análisis del tráfico de red (TMA) de 2017. págs. 1–9. doi :10.23919/TMA.2017.8002906. ISBN 978-3-901882-95-1.S2CID34925433  .​
3. Kromhout, Wileen Wong (2 de febrero de 2012), "Lixia Zhang nombrada titular de la Cátedra Jonathan B. Postel en Ciencias de la Computación de la UCLA", UCLA Newsroom , archivado desde el original el 25 de abril de 2019 , consultado el 14 de junio de 2015
4. Ido Dubrawsky y Wes Noonan. "Enrutadores de banda ancha y firewalls". CISCO Press . Consultado el 15 de julio de 2012 .
5. Magalhaes, Ricky. "La diferencia entre los firewalls de capa de aplicación y de sesión" . Consultado el 17 de julio de 2012 .
6. "Entendiendo los sistemas de detección de intrusiones" . Consultado el 17 de julio de 2012 .
7. K. Egevang y P. Francis (2001). "El traductor de direcciones de red IP (NAT)". Ietf Datatracker . doi :10.17487/RFC3022. RFC 1631 . 
8. Zhaoguang Wang, Zhiyun Qian, Qiang Xu, Z. Morley Mao , Ming Zhang (agosto de 2011). "Una historia no contada de los middleboxes en redes celulares" (PDF) . ACM SIGCOMM Computer Communication Review . 41 (4). Association for Computing Machinery: 374–385. doi :10.1145/2043164.2018479.{{cite journal}}: CS1 maint: varios nombres: lista de autores ( enlace )
9. Poe, Robert. "¿Qué es la optimización de WAN y cómo puede ayudarle?" . Consultado el 17 de julio de 2012 .
10. Michael Walfish, Jeremy Stribling, Maxwell Krohn, Hari Balakrishnan, Robert Morris y Scott Shenker (2004). "Middleboxes Ya No Se Considera Dañino" (PDF) . 6.º Simposio sobre Diseño e Implementación de Sistemas Operativos . USENIX Association: 215–230.{{cite journal}}: CS1 maint: varios nombres: lista de autores ( enlace )
11. Walfish; et al. (2004). "Middleboxes ya no se considera perjudicial" (PDF) . OSDI . Consultado el 17 de julio de 2012 .
12. J. Rosenberg; et al. (2008). "Utilidades de recorrido de sesión para NAT (STUN)". Ietf Datatracker . doi : 10.17487/RFC5389 . RFC 5389. S2CID  6777753 . 
13. "NAT-PMP". Ietf Datatracker . Consultado el 17 de julio de 2012 .
14. "Grupo de trabajo sobre protocolo de control de puertos" . Consultado el 17 de julio de 2012 .
15. "Base de conocimientos de BlueCoat: el proxy muestra contenido obsoleto" . Consultado el 17 de julio de 2012 .
16. "Uso de FaceTime y iMessage detrás de un firewall" . Consultado el 17 de julio de 2012 .
17. Honda; et al. (2011). "¿Todavía es posible ampliar TCP?" (PDF) . Conferencia de medición de Internet .
18. Bryan Ford; Pyda Srisuresh; Dan Kegel (2005). "Comunicación punto a punto a través de traductores de direcciones de red" (PDF) . Conferencia técnica anual de USENIX de 2005. Asociación USENIX: 179–192. arXiv : cs/0603074 . Código Bibliográfico :2006cs.......3074F.
19. Papastergiou, Giorgos; Fairhurst, Gorry; Ros, David; Brunstrom, Anna; Grinnemo, Karl-Johan; Hurtig, Per; Khademi, Naeem; Tuxen, Michael; Welzl, Michael; Damjanovic, Dragana; Mangiante, Simone (2017). "Desosificación de la capa de transporte de Internet: una encuesta y perspectivas futuras". IEEE Communications Surveys & Tutorials . 19 (1): 619–639. doi :10.1109/COMST.2016.2626780. hdl : 2164/8317 . ISSN  1553-877X. S2CID  1846371. Archivado (PDF) desde el original el 22 de septiembre de 2021.
20. Corbet, Jonathan (29 de enero de 2018). "QUIC como solución a la osificación del protocolo". lwn.net . Consultado el 14 de marzo de 2020 .