osificación del protocolo

La osificación de protocolos es la pérdida de flexibilidad, extensibilidad y capacidad de evolución de los protocolos de red . Esto se debe principalmente a los dispositivos intermedios , que son sensibles a la representación gráfica del protocolo y pueden interrumpir o interferir con mensajes válidos que, sin embargo, no reconocen correctamente. Esto constituye una violación del principio de extremo a extremo . Entre las causas secundarias se incluye la inflexibilidad en las implementaciones de protocolos en los puntos finales.

La osificación es un problema importante en el diseño y la implementación de protocolos de Internet , ya que puede impedir la implementación de nuevos protocolos o extensiones, o imponer restricciones al diseño de nuevos protocolos. Estos pueden verse obligados a encapsularse en un protocolo ya implementado o a imitar la estructura de otro protocolo. Debido a la osificación, el Protocolo de Control de Transmisión (TCP) y el Protocolo de Datagramas de Usuario (UDP) son las únicas opciones prácticas para protocolos de transporte en Internet, y el propio TCP se ha osificado considerablemente, lo que dificulta su extensión o modificación.

Entre los métodos recomendados para prevenir la osificación se incluyen el cifrado de los metadatos del protocolo y garantizar que se utilicen los puntos de extensión y se muestre la variabilidad de la imagen del cable en la mayor medida posible; remediar la osificación existente requiere coordinación entre los participantes del protocolo. QUIC es el primer protocolo de transporte del IETF diseñado con propiedades específicas para evitar la osificación.

En 2005, Internet ya presentaba una osificación significativa , y ese mismo año se publicaron análisis sobre el problema; ^{[ 1 ]} Ammar (2018) sugiere que la osificación fue consecuencia de que Internet alcanzara una escala global y se convirtiera en la principal red de comunicación. ^{[ 2 ]}

Multipath TCP fue la primera extensión de un protocolo central de Internet que abordó profundamente la osificación del protocolo durante su diseño. ^{[ 3 ]}

El IETF creó el grupo de trabajo de Servicios de Transporte (taps) en 2014. ^{[ 4 ]} Tiene el mandato de mitigar la osificación en la capa del protocolo de transporte . ^{[ 5 ]}

QUIC es el primer protocolo de transporte IETF que minimiza deliberadamente su imagen de cable para evitar la osificación. ^{[ 6 ]}

El Consejo de Arquitectura de Internet identificó las consideraciones de diseño en torno a la exposición de información de protocolo a los elementos de la red como un "campo en desarrollo" en 2023. ^{[ 7 ]}

La causa principal de la osificación de protocolos es la interferencia de los middleboxes , ^{[ 8 ]} invalidando el principio de extremo a extremo . ^{[ 9 ]} Los middleboxes pueden bloquear completamente protocolos desconocidos o extensiones no reconocidas de protocolos conocidos, interferir con la negociación de extensiones o características, o realizar modificaciones más invasivas de los metadatos del protocolo. ^{[ 10 ]} No todas las modificaciones de los middleboxes son necesariamente osificantes; de las que son potencialmente dañinas, se concentran desproporcionadamente en el borde de la red . ^{[ 11 ]} Los operadores de red implementan middleboxes unilateralmente para resolver problemas específicos, ^{[ 12 ]} incluyendo la optimización del rendimiento, los requisitos de seguridad (por ejemplo, cortafuegos), la traducción de direcciones de red o la mejora del control de las redes. ^{[ 13 ]} Estas implementaciones de middleboxes proporcionan una utilidad localizada a corto plazo, pero degradan la capacidad de evolución global a largo plazo de Internet en una manifestación de la tragedia de los comunes . ^{[ 12 ]}

Los cambios en un protocolo deben ser tolerados por todos los intermediarios en la ruta; si se desea una amplia implementación del cambio en Internet, esto se extiende a una gran parte de los intermediarios en Internet. Un dispositivo intermedio debe tolerar los protocolos ampliamente utilizados tal como se utilizaban en el momento de su implementación, pero es probable que no tolere protocolos nuevos o cambios en los existentes, lo que crea un círculo vicioso , ya que las nuevas imágenes de red no pueden lograr una implementación lo suficientemente amplia como para que los dispositivos intermedios toleren la nueva imagen de red en toda Internet. ^{[ 9 ]} Incluso que todos los participantes toleren el protocolo no garantiza su uso: en ausencia de un mecanismo de negociación o descubrimiento, los puntos finales pueden optar por un protocolo que se considere más fiable. ^{[ 14 ]}

Más allá de los dispositivos intermedios, la osificación también puede deberse a una flexibilidad insuficiente en la implementación del punto final. Los núcleos de los sistemas operativos son lentos para cambiar e implementarse, ^{[ 14 ]} y los protocolos implementados en hardware también pueden fijar detalles de protocolo de forma inadecuada. ^{[ 15 ]} Una interfaz de programación de aplicaciones (API) ampliamente utilizada que asume ciertas características del funcionamiento de los protocolos subyacentes puede dificultar la implementación de protocolos que no comparten esas mismas suposiciones. ^{[ 9 ]}

El Consejo de Arquitectura de Internet recomendó en 2019 que las señales implícitas a los observadores se reemplazaran con señales deliberadamente destinadas al consumo de esos observadores, y que las señales no destinadas a su consumo no estuvieran disponibles para ellos (por ejemplo, mediante cifrado); y también que los metadatos del protocolo estuvieran protegidos en cuanto a su integridad para que no pudieran ser modificados por cajas intermedias. ^{[ 16 ]} Sin embargo, incluso los metadatos totalmente cifrados pueden no prevenir por completo la osificación en la red, ya que la imagen de cableado de un protocolo aún puede mostrar patrones en los que se llega a confiar. ^{[ 17 ]} Los operadores de red utilizan metadatos para una variedad de propósitos de gestión benignos, ^{[ 18 ]} y la investigación de Internet también se informa a partir de datos recopilados de los metadatos del protocolo; ^{[ 19 ]} el diseñador de un protocolo debe equilibrar la resistencia a la osificación con la observabilidad para necesidades operativas o de investigación. ^{[ 17 ]} Arkko et al. (2023) proporciona más orientación sobre estas consideraciones: la divulgación de información por parte de un protocolo a la red debe ser intencional, ^{[ 20 ]} realizada con el acuerdo tanto del receptor como del remitente, ^{[ 21 ]} autenticada en la medida posible y necesaria, ^{[ 22 ]} actuada solo en la medida de su confiabilidad, ^{[ 23 ]} y minimizada y proporcionada a un número mínimo de entidades. ^{[ 24 ] [ 25 ]}

Se requiere el uso activo de los puntos de extensión para evitar su osificación. ^{[ 26 ]} Reducir el número de puntos de extensión, documentar las invariantes en las que los participantes del protocolo pueden confiar en lugar de detalles incidentales en los que no se debe confiar, y la detección rápida de problemas en los sistemas implementados pueden ayudar a garantizar el uso activo. ^{[ 27 ]} Sin embargo, incluso el uso activo puede ejercer solo una porción reducida del protocolo y la osificación aún puede ocurrir en las partes que permanecen invariantes en la práctica a pesar de la variabilidad teórica. ^{[ 28 ] [ 29 ]} "Engrasar" un punto de extensión, donde algunas implementaciones indican soporte para extensiones inexistentes, puede garantizar que se toleren las extensiones existentes pero no reconocidas (cf. ingeniería del caos ). ^{[ 30 ]} Los encabezados HTTP son un ejemplo de un punto de extensión que ha evitado con éxito una osificación significativa, ya que los participantes generalmente ignorarán los encabezados no reconocidos. ^{[ 31 ]}

Se puede diseñar un nuevo protocolo para imitar la imagen de cableado de un protocolo existente y osificado; ^{[ 32 ]} alternativamente, se puede encapsular un nuevo protocolo dentro de un protocolo existente y tolerado. Una desventaja de la encapsulación es que suele haber sobrecarga y trabajo redundante (por ejemplo, las sumas de verificación externas se vuelven redundantes debido a las comprobaciones de integridad internas). ^{[ 33 ]}

Además de los dispositivos intermedios, también se pueden resistir otras fuentes de osificación. La implementación de protocolos en el espacio de usuario puede conducir a una evolución más rápida. Si el nuevo protocolo está encapsulado en UDP, entonces es posible la implementación en el espacio de usuario. ^{[ 34 ] [ 35 ]} Cuando el soporte para los protocolos es incierto, los participantes pueden probar simultáneamente protocolos alternativos, a costa de aumentar la cantidad de datos enviados. ^{[ 36 ]}

Con el esfuerzo y la coordinación suficientes, la osificación puede revertirse directamente. Un día de implementación , en el que los participantes del protocolo realizan cambios de forma conjunta, puede romper el círculo vicioso y establecer un uso activo. Este enfoque se utilizó para implementar EDNS , que anteriormente no había sido tolerado por los servidores. ^{[ 37 ]}

El Protocolo de Control de Transmisión ha sufrido de osificación. ^{[ 38 ]} Una medición encontró que un tercio de las rutas a través de Internet encuentran al menos un intermediario que modifica los metadatos TCP, y el 6,5 % de las rutas encuentran efectos de osificación perjudiciales de los intermediarios. ^{[ 39 ]} Las extensiones de TCP se han visto afectadas: el diseño de MPTCP se vio limitado por el comportamiento de la caja intermedia, ^{[ 3 ] [ 40 ]} y el despliegue de TCP Fast Open también se ha visto obstaculizado. ^{[ 41 ] [ 38 ]}

El protocolo de transmisión de control de flujo (TCP ) se ha implementado poco en Internet debido a la intolerancia de los dispositivos intermedios ^{[ 9 ]} y también debido a que la API de sockets BSD, muy extendida , no se ajusta a sus capacidades ^{[ 42 ]} . En la práctica, TCP y UDP son los únicos protocolos de transporte de Internet utilizables ^{[ 43 ]} .

Transport Layer Security (TLS) se ha estancado. TLS fue el contexto original para la introducción de los puntos de extensión de greasing. TLS 1.3 , tal como se diseñó originalmente, resultó imposible de implementar en Internet: los dispositivos intermedios habían estancado el parámetro de versión del protocolo. Esto se descubrió tarde en el proceso de diseño del protocolo, durante las implementaciones experimentales de los navegadores web . Como resultado, la versión 1.3 imita la imagen de red de la versión 1.2. ^{[ 44 ]}

QUIC ha sido diseñado específicamente para ser desplegable, evolutivo y tener propiedades anti-osificación; ^{[ 45 ]} es el primer protocolo de transporte IETF que minimiza deliberadamente su imagen de cable para estos fines. ^{[ 6 ]} Está engrasado, ^{[ 30 ]} tiene invariantes de protocolo especificadas explícitamente, ^{[ 46 ]} está encapsulado en UDP y sus metadatos de protocolo están cifrados. ^{[ 45 ]} Aun así, las aplicaciones que usan QUIC deben estar preparadas para recurrir a otros protocolos, ya que UDP es bloqueado por algunos dispositivos intermedios. ^{[ 47 ]}

• Compatibilidad con versiones anteriores
• Problema de acción colectiva
• Estándar de facto
• Compatibilidad con versiones futuras
• Interoperabilidad
• Ley de Hyrum
• Efecto de red
• Principio de robustez
• Dependencia del proveedor

• Trammell, Brian; Kuehlewind, Mirja (abril de 2019). La imagen de cable de un protocolo de red . IETF . doi : 10.17487/RFC8546 . RFC 8546 .
• Hardie, Ted, ed. (abril de 2019). Señales de ruta de protocolo de transporte . IETF . doi : 10.17487/RFC8558 . RFC 8558 .
• Thomson, Martín (mayo de 2021). Propiedades independientes de la versión de QUIC . IETF . doi : 10.17487/RFC8999 . RFC 8999 .
• Fairhurst, Gorry; Perkins, Colin (julio de 2021). Consideraciones sobre la confidencialidad de las cabeceras de transporte, las operaciones de red y la evolución de los protocolos de transporte de Internet . IETF . doi : 10.17487/RFC9065 . RFC 9065 .
• Thomson, Martin; Pauly, Tommy (diciembre de 2021). Viabilidad a largo plazo de los mecanismos de extensión de protocolo . IETF . doi : 10.17487/RFC9170 . RFC 9170 .
• Kühlewind, Mirja; Trammell, Brian (septiembre de 2022). Aplicabilidad del protocolo de transporte QUIC . IETF . doi : 10.17487/RFC9308 . RFC 9308 .
• Arkko, Jari; Hardie, Ted; Pauly, Tommy; Kühlewind, Mirja (julio de 2023). Consideraciones sobre la aplicación: colaboración en red mediante señales de ruta . IETF . doi : 10.17487/RFC9419 . RFC 9419 .
• Honda, Michio; Nishida, Yoshifumi; Raiciu, Costin; Greenhalgh, Adam; Handley, Mark ; Tokuda, Hideyuki (2011). ¿Sigue siendo posible extender TCP? . Conferencia ACM SIGCOMM 2011 sobre medición de Internet. doi : 10.1145/2068816.2068834 .
• Raiciu, Costin; Paasch, Christoph; Barre, Sebastien; Ford, Alan; Honda, Michio; Duchene, Fabien; Bonaventure, Olivier; Handley, Mark (2012). ¿Qué tan difícil puede ser? Diseño e implementación de un TCP multipath desplegable . 9.º Simposio USENIX sobre diseño e implementación de sistemas en red (NSDI 12).
• Hesmans, Benjamin; Duchene, Fabien; Paasch, Christoph; Detal, Gregory; Bonaventure, Olivier (2013). ¿ Son las extensiones TCP a prueba de middlebox? . HotMiddlebox '13. CiteSeerX 10.1.1.679.6364 . doi : 10.1145/2535828.2535830 . 
• Corbet, Jonathan (8 de diciembre de 2015). "Descargas de suma de verificación y osificación de protocolos" . LWN.net .
• Corbet, Jonathan (20 de junio de 2016). "Protocolos de nivel de transporte en el espacio de usuario" . LWN.net .
• McQuistin, Stephen; Perkins, Colin; Fayed, Marwan (julio de 2016). Implementación de servicios de transporte en tiempo real sobre una red osificada . Taller de investigación de redes aplicadas de 2016. doi : 10.1145/2959424.2959443 . hdl : 1893/26111 .
• Papastergiou, Giorgos; Fairhurst, Gorry; Ros, David; Brunstrom, Anna; Grinnemo, Karl-Johan; Hurtig, Per; Khademi, Naeem; Tüxen, Michael; Welzl, Michael; Damjanovic, Dragana; Mangiante, Simone (2017). "Desosilenciando la capa de transporte de Internet: una revisión y perspectivas futuras". IEEE Communications Surveys & Tutorials . 19 : 619–639 . doi : 10.1109/COMST.2016.2626780 . hdl : 2164/8317 . S2CID 1846371 . 
• Sullivan, Nick (26 de diciembre de 2017). "Por qué TLS 1.3 aún no está en los navegadores" . El blog de Cloudflare . Recuperado el 14 de marzo de 2020 .
• Ammar, Mostafa (enero de 2018). "Ex Uno Pluria: El ciclo de infraestructura de servicios, la osificación y la fragmentación de Internet". ACM SIGCOMM Comput. Commun. Rev. doi : 10.1145/3211852.3211861 . S2CID 12169344 . 
• Corbet, Jonathan (29 de enero de 2018). "QUIC como solución a la osificación de protocolos" . LWN.net .
• Edeline, Korian; Donnet, Benoit (2019). Una investigación ascendente de la osificación de la capa de transporte . Conferencia de medición y análisis de tráfico de red de 2019 (TMA). doi : 10.23919/TMA.2019.8784690 .
• Rybczyńska, Marta (13 de marzo de 2020). "Una mirada RÁPIDA a HTTP/3" . LWN.net .

• Trammell, Brian; Kuehlewind, Mirja, eds. (octubre de 2015). Informe del taller del IAB sobre la evolución de la pila en una Internet de caja intermedia (SEMI) . IETF . doi : 10.17487/RFC7663 . RFC 7663 .