Minimizar el riesgo de osificación, un deber de todos
En la década de 1990, los ingenieros de software intentaban adaptarse a la aterradora idea de que los años dejaran de empezar por «19». Esto se conocería como «efecto 2000» y es uno de los casos más conocidos de osificación: presuponer que algo no va a cambiar solo porque nunca lo ha hecho (o lleva mucho tiempo sin hacerlo).
Aunque el efecto 2000 es un ejemplo poco útil porque el cambio se podía prever con facilidad, estos riesgos también son inherentes a las funciones que ofrecemos como proveedor de infraestructuras de Internet. Dado que ofrecemos a nuestros clientes acceso de bajo nivel a los protocolos de Internet, desde un punto de vista colectivo debemos intentar no perjudicar el futuro de la Red de manera involuntaria. Analicemos en detalle nuestro papel en esto.
La evolución permite que Internet tenga éxito
Internet tiene una solidez notable. Los protocolos de conexión de red diseñados en las décadas de 1970, 1980 y 1990 continúan siendo útiles porque se concibieron pensando en su posterior evolución. Sus diseñadores previeron que en el futuro habría cambios e incluyeron a propósito métodos con los que agregar nuevas funciones al protocolo y cambiar aspectos de este, todo ello sin que Internet se viniera abajo.
Este aspecto es esencial, porque es imposible que todos los internautas se actualicen al mismo tiempo: debe ser posible introducir el cambio de forma gradual y que ello no afecte a las comunicaciones en las que una sola parte entiende el cambio. En condiciones normales, esto se realiza a través de mecanismos de extensibilidad y de control de versiones. La capacidad de evolucionar ha hecho posible introducir IPv6 —aunque con lentitud— como forma de respuesta al agotamiento de las direcciones IPv4. IPv6 permite la introducción de nuevas versiones de TLS para mejorar la seguridad de la Web y de otras aplicaciones; además, posibilitó que el protocolo HTTP/2 mejorara las prestaciones con vistas a Internet y que se introdujeran nuevas funciones a través de encabezados, métodos y códigos de estado.
La osificación impide la evolución de Internet
La osificación se produce cada vez que las aplicaciones, los dispositivos de red y demás componentes de Internet restringen el uso del control de versiones de los protocolos y de mecanismos de extensibilidad de estos; es decir, las «juntas» de los protocolos que aportan flexibilidad se van «oxidando» y pierden la movilidad. Esto suele ocurrir cuando un implementador o un usuario del protocolo da por sentado que este no se va a modificar.
Por ejemplo, si una instancia del firewall de aplicaciones web (WAF) denegara una petición que tuviera un encabezado cuyo valor incluyera una cadena del tipo «target=value», esto dificultaría que los navegadores incorporaran nuevos encabezados. ¿Te parece poco probable? Pues te equivocas: ya ha ocurrido.
TLS 1.3 es otra de las víctimas de la osificación: exige que la cadena de versión del encabezado del protocolo esté definida con el valor correspondiente a TLS 1.2 porque algunos servidores no contemplaron que habría un versión superior. Esta «intolerancia a las versiones» genera complejidades y riesgos al desplegar protocolos nuevos.
La osificación complica la introducción de nuevas funciones en el protocolo. Al final, es necesario reemplazar cualquier protocolo con exceso de osificación. Es lo que le está pasando a TCP: ha habido tantos dispositivos de red tratando de «contribuir» al rendimiento de la conexión TCP mediante ideas preconcebidas sobre su funcionamiento (es decir, los denominados «aceleradores de WAN») que se tiene que adoptar un nuevo enfoque: QUIC. Estas «útiles» cajas perjudicaban con frecuencia el rendimiento y la fiabilidad, porque no había comunicación entre sus diseñadores y quienes trataban de introducir cambios u optimizar conexiones a partir de los puntos de conexión.
Gestión de los riesgos de osificación con Fastly
Fastly expone detalles de nivel bajo del protocolo al código de nuestros clientes en VCL y Compute@Edge. Se trata de una elección de diseño: exponer estos datos te permite diseñar sistemas con mayores capacidades a partir de Fastly. No obstante, pedimos a nuestros clientes que eviten tomar decisiones que a la larga pueden osificar estos protocolos de manera involuntaria, al igual que hacemos nosotros a nivel interno.
En concreto, las ideas preconcebidas sobre el comportamiento que tienen los clientes o sobre el aspecto que tiene el tráfico «normal» conllevan el riesgo de osificación. Aunque las presunciones funcionen a corto plazo, es posible que los cambios del futuro (p. ej., por parte de los navegadores) las invaliden y que esto, a su vez, provoque errores impredecibles en tu aplicación.
Los riesgos de osificación suelen aparecer cuando se diseñan clasificadores de clientes y WAF que alteran el funcionamiento de tu sitio web a partir de parámetros específicos del protocolo. Si utilizas nuestro WAF o nuestros mecanismos integrados de detección de dispositivos (p. ej., client.class.*, client.platform.*, y client.display.* en VCL), nosotros nos encargaremos de gestionar la mayoría de los riesgos de osificación. Sin embargo, si diseñas estas capacidades por tu cuenta, podrías contribuir sin quererlo a la osificación de Internet.
Para ser más exactos, el riesgo de osificación puede aumentar si rechazas peticiones en función de metadatos de nivel bajo de protocolo como la versión de HTTP, encabezados de peticiones HTTP e información sobre la conexión TLS, TCP y QUIC. Ese riesgo crece todavía más si no hay un canal de comentarios eficaz: al no poder comunicarse contigo en caso de restricción, las personas afectadas tienden a solventar el problema, solución que podría acabar integrándose en Internet de forma permanente.
Por suerte, es posible diseñar este tipo de funciones y productos con responsabilidad siguiendo estos procedimientos:
Hacer pruebas continuas con una amplia gama de versiones preliminares de navegadores y otros clientes HTTP para detectar problemas de interoperabilidad de forma precoz.
Verificar con regularidad si en las colas de errores de los navegadores aparecen menciones de tu producto.
Asegurarte de que tu producto tenga una identificación clara en el protocolo de modo que sea fácilmente localizable.
Habilitar un contacto para que los desarrolladores de navegadores y otros clientes se puedan comunicar contigo (p. ej., canal de soporte técnico, cola de errores o dirección de correo electrónico «ad hoc»).
Hacer un seguimiento del desarrollo de los protocolos pertinentes en busca de cambios que podrían invalidar tus presunciones. Te recomendamos que empieces este seguimiento en cualquiera de estos grupos de trabajo del IETF: HTTP Working Group o TLS Working Group. Además, tienes a tu disposición una lista dinamizadora de HTTP, donde se debaten problemas de osificación de ese protocolo y se da visibilidad a alertas y notificaciones relacionadas.
La lucha contra la osificación exige la colaboración de todas las partes interesadas de Internet. Aunque siempre habrá sitios web y programas que usen los puntos de extensión de los protocolos de forma indebida, minimizarlos ayuda a garantizar que Internet siga evolucionando y respondiendo a los desafíos del futuro con agilidad.
