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 en gran medida a los middleboxes que son sensibles a la imagen de cable del protocolo y que pueden interrumpir o interferir con los mensajes que son válidos pero que el middlebox no reconoce correctamente. Esto es una violación del principio de extremo a extremo . Las causas secundarias incluyen 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 que se implementen nuevos protocolos o extensiones en Internet, o imponer restricciones al diseño de nuevos protocolos; es posible que los nuevos protocolos deban encapsularse en un protocolo ya implementado o imitar la imagen 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 los protocolos de transporte en Internet, y el propio TCP se ha osificado significativamente, lo que dificulta la extensión o modificación del protocolo.
Los métodos recomendados para prevenir la osificación incluyen el cifrado de metadatos del protocolo y la garantía de que se utilicen los puntos de extensión y de que la variabilidad de la imagen de cable se muestre de la forma más completa posible; para remediar la osificación existente se requiere la coordinación entre los participantes del protocolo. QUIC es el primer protocolo de transporte de la IETF que se ha diseñado con propiedades deliberadamente antiosificación.
En 2005, Internet ya se había osificado de forma significativa y ese mismo año también se publicaron análisis del problema; [1] Ammar (2018) sugiere que la osificación fue una 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 afrontó 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]
La Junta de Arquitectura de Internet identificó las consideraciones de diseño en torno a la exposición de la información del 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 por completo 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 dirigen desproporcionadamente hacia el borde de la red. [11] Los operadores de red implementan los middleboxes de manera unilateral para resolver problemas específicos, [12] incluida la optimización del rendimiento, los requisitos de seguridad (por ejemplo, firewalls), la traducción de direcciones de red o la mejora del control de las redes. [13] Estas implementaciones de middleboxes brindan 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, entonces esto se extiende a una gran parte de los intermediarios en Internet. Un middlebox debe tolerar los protocolos ampliamente utilizados tal como se utilizaban en el momento de su implementación, pero es probable que no tolere nuevos protocolos o cambios en los existentes, lo que crea efectivamente un círculo vicioso ya que las nuevas imágenes de cable no pueden lograr una implementación lo suficientemente amplia como para que los middleboxes toleren la nueva imagen de cable en toda Internet. [9] Incluso el hecho de que todos los participantes toleren el protocolo no es garantía de su uso: en ausencia de un mecanismo de negociación o descubrimiento, los puntos finales pueden adoptar por defecto un protocolo que se considere más confiable. [14]
Más allá de los middleboxes, la osificación también puede ser causada por una flexibilidad insuficiente dentro de la implementación del punto final. Los núcleos del sistema operativo son lentos para cambiar e implementar, [14] y los protocolos implementados en hardware también pueden corregir de manera inapropiada los detalles del protocolo. [15] Una interfaz de programación de aplicaciones (API) ampliamente utilizada que hace suposiciones sobre el funcionamiento de los protocolos subyacentes puede obstaculizar la implementación de protocolos que no comparten esas suposiciones. [9]
En 2019, la Junta de Arquitectura de Internet recomendó que las señales implícitas para los observadores se reemplacen con señales deliberadamente destinadas al consumo de esos observadores, y que las señales no destinadas a su consumo no estén disponibles para ellos (por ejemplo, mediante cifrado); y también que los metadatos del protocolo estén protegidos en su integridad para que no puedan ser modificados por los middleboxes. [16] Sin embargo, incluso los metadatos completamente cifrados pueden no evitar por completo la osificación en la red, ya que la imagen de cable de un protocolo aún puede mostrar patrones en los que se puede confiar. [17] Los operadores de red utilizan metadatos para una variedad de propósitos de gestión benignos, [18] y la investigación en Internet también se basa en datos recopilados de los metadatos del protocolo; [19] el diseñador de un protocolo debe equilibrar la resistencia a la osificación frente a 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 destinatario como del remitente, [21] autenticada en la medida que sea 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 un uso activo de los puntos de extensión para evitar que se osifiquen. [26] Reducir el número de puntos de extensión, documentar invariantes en las que los participantes del protocolo pueden confiar en lugar de detalles incidentales en los que no se debe confiar y detectar rápidamente los problemas en los sistemas implementados puede ayudar a garantizar un uso activo. [27] Sin embargo, incluso el uso activo puede ejercitar solo una porción estrecha 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 extensiones realmente 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 en alambre de un protocolo osificado existente; [32] alternativamente, se puede encapsular un nuevo protocolo dentro de un protocolo existente y tolerado. Una desventaja de la encapsulación es que normalmente hay sobrecarga y trabajo redundante (por ejemplo, sumas de comprobación externas que se vuelven redundantes por comprobaciones de integridad internas). [33]
Además de los middleboxes, 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 suficiente esfuerzo y coordinación, la osificación puede revertirse directamente. Un día de bandera , donde los participantes del protocolo realizan cambios en conjunto, 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 una 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 de TCP, y el 6,5% de las rutas encuentran efectos osificantes dañinos de los intermediarios. [39] Las extensiones a TCP se han visto afectadas: el diseño de MPTCP se vio limitado por el comportamiento de middlebox, [3] [40] y la implementación de TCP Fast Open también se ha visto obstaculizada. [41] [38]
El protocolo de transmisión de control de flujo ha sido poco utilizado en Internet debido a la intolerancia de los middleboxes, [9] y también debido a la muy extendida API de sockets BSD que no se ajusta a sus capacidades. [42] En la práctica, TCP y UDP son los únicos protocolos de transporte de Internet utilizables . [43]
El protocolo Transport Layer Security (TLS) ha sufrido una osificación. TLS fue el contexto original para la introducción de puntos de extensión de engrase. TLS 1.3 , tal como se diseñó originalmente, demostró no poder implementarse en Internet: los middleboxes habían osificado el parámetro de versión del protocolo. Esto se descubrió en una etapa avanzada del proceso de diseño del protocolo, durante implementaciones experimentales en navegadores web . Como resultado, la versión 1.3 imita la imagen de la versión 1.2. [44]
QUIC ha sido diseñado específicamente para ser desplegable, evolucionable y tener propiedades antiosificació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 explícitamente especificados, [46] está encapsulado en UDP y sus metadatos de protocolo están encriptados. [45] Aún así, las aplicaciones que usan QUIC deben estar preparadas para recurrir a otros protocolos, ya que UDP está bloqueado por algunos middleboxes. [47]