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 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 cable 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 cifrar los metadatos del protocolo y garantizar que se ejerciten los puntos de extensión y que la variabilidad de la imagen del cable se muestre de la manera más completa 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 antiosificación deliberadas.
En 2005 se había producido una osificación significativa en Internet , y ese 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 enfrentó 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 del IETF que minimiza deliberadamente su imagen de cable para evitar la osificación. [6]
La Junta de Arquitectura de Internet identificó consideraciones de diseño en torno a la exposición de información de protocolo a elementos de red como un "campo en desarrollo" en 2023. [7]
La causa principal de la osificación del protocolo es la interferencia de la caja intermedia , [8] que invalida 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 funciones, o realizar modificaciones más invasivas de los metadatos del protocolo. [10] No todas las modificaciones del cuadro intermedio son necesariamente osificantes; de aquellos que son potencialmente dañinos, se encuentran desproporcionadamente hacia el borde de la red. [11] Los operadores de red implementan unilateralmente middleboxes para resolver problemas específicos, [12] incluida 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] Estos despliegues intermedios 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 bienes comunes . [12]
Todos los intermediarios en el camino deben tolerar los cambios en un protocolo; Si se desea una amplia implementación del cambio en Internet, entonces esto se extenderá a una gran parte de los intermediarios en Internet. Un middlebox debe tolerar protocolos ampliamente utilizados tal como se estaban usando en el momento de su implementación, pero es probable que no tolere nuevos protocolos o cambios en los existentes, creando efectivamente un círculo vicioso ya que las nuevas imágenes de cables no pueden lograr un despliegue lo suficientemente amplio como para hacer Los middleboxes toleran la nueva imagen de cable en todo Internet. [9] Incluso que todos los participantes toleren el protocolo no es garantía de uso: en ausencia de un mecanismo de negociación o descubrimiento, los puntos finales pueden utilizar de forma predeterminada un protocolo que se considere más confiable. [14]
Más allá de los middleboxes, la osificación también puede deberse a una flexibilidad insuficiente en la implementación del punto final. Los núcleos del sistema operativo tardan en cambiarse e implementarse, [14] y los protocolos implementados en el hardware también pueden corregir de manera inapropiada los detalles del protocolo. [15] Una 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]
La Junta de Arquitectura de Internet recomendó en 2019 que las señales implícitas enviadas a los observadores deberían ser reemplazadas por señales deliberadamente destinadas al consumo de esos observadores, y que las señales no destinadas a su consumo no deberían estar disponibles para ellos (por ejemplo, mediante cifrado); y también que los metadatos del protocolo deben estar 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 metadatos de 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 mediante un protocolo a la red debe ser intencional, [20] realizarse con el acuerdo tanto del destinatario como del remitente, [21] autenticada en la medida posible y necesaria, [22] sólo se actúa sobre él en el grado de su confiabilidad, [23] y se minimiza y se proporciona a un número mínimo de entidades. [24] [25]
Se requiere el uso activo de los puntos de extensión para que no se osifiquen. [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 un uso activo. [27] Sin embargo, incluso el uso activo puede ejercer 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 del cable 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 trabajo sobrecargado y redundante (por ejemplo, sumas de comprobación externas que se vuelven redundantes debido a comprobaciones de integridad internas). [33]
Además de las cajas intermedias, 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 se puede revertir directamente. Un día de la bandera , en el que los participantes del protocolo realizan cambios de forma concertada, 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 TCP, y el 6,5% de las rutas encuentran efectos osificantes dañinos de los intermediarios. [39] Las extensiones de TCP se han visto afectadas: el diseño de MPTCP se vio limitado por el comportamiento del middlebox, [3] [40] y la implementación de TCP Fast Open también se vio obstaculizada. [41] [38]
El protocolo de transmisión Stream Control se ha implementado poco 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 adapta bien a sus capacidades. [42] En la práctica, TCP y UDP son los únicos protocolos de transporte de Internet utilizables . [43]
La seguridad de la capa de transporte (TLS) ha experimentado 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, resultó imposible de implementar en Internet: los middleboxes habían osificado el parámetro de versión del protocolo. Esto se descubrió al final del proceso de diseño del protocolo, durante implementaciones experimentales de navegadores web . Como resultado, la versión 1.3 imita la imagen de cable 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 del 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] Aún así, las aplicaciones que utilizan QUIC deben estar preparadas para recurrir a otros protocolos, ya que algunos middleboxes bloquean UDP. [47]