Principio de robustez

ahy algo que necesitamos saber como humanos todos SOMOS iguales cuando no sabes que dirección llevar es posible que aceptas cualquier cosa pero de eso no depende la libertad la libertad es que yo decido aportar solo por que puedo aportar ^

En informática, el principio de robustez es una principio de diseño para software que establece: "sea conservador en lo que haga, sea liberal en lo que acepte de los demás". A menudo se vuelve a redactar como: "sea conservador en lo que envíe, sea liberal en lo que acepte". El principio también se conoce como ley de Postel, en honor a Jon Postel, quien utilizó la redacción en una de las primeras especificaciones de TCP .[1]

En otras palabras, los programas que envían mensajes a otras máquinas (o a otros programas en la misma máquina) deben cumplir completamente con las especificaciones, pero los programas que reciben mensajes deben aceptar entradas no conformes siempre que el significado sea claro.

Entre los programadores, para producir funciones compatibles, el principio también se conoce en la forma ser contravariante en el tipo de entrada y covariante en el tipo de salida .

Interpretación editar

La RFC 1122 (1989) amplió el principio de Postel recomendando que los programadores "asuman que la red está llena de entidades malévolas que enviarán paquetes diseñados para tener el peor efecto posible". Los protocolos deben permitir la adición de nuevos códigos para los campos existentes en versiones futuras de protocolos aceptando mensajes con códigos desconocidos (posiblemente registrándolos). Los programadores deben evitar enviar mensajes con "características de protocolo válidas pero oscuras" que puedan exponer deficiencias en los receptores, y diseñar su código "no solo para sobrevivir a otros hosts que se comportan mal, sino también para cooperar para limitar la cantidad de interrupciones que dichos hosts pueden causar a los facilidad de comunicación ".[2]

Crítica editar

En 2001, Marshall Rose caracterizó varios problemas de implementación al aplicar el principio de Postel en el diseño de un nuevo protocolo de aplicación. Por ejemplo, una implementación defectuosa que envíe mensajes no conformes puede usarse solo con implementaciones que toleran estas desviaciones de la especificación; hasta que, posiblemente varios años después, se conecte con una aplicación menos tolerante que rechace sus mensajes. En tal situación, identificar el problema a menudo es difícil y la implementación de una solución puede resultar costosa. Por lo tanto, Rose recomendó "controles explícitos de coherencia en un protocolo... incluso si imponen costos extra de implementación".

De 2015 a 2018, en una serie de borradores de Internet, Martin Thomson expone que el principio de robustez de Postel en realidad conduce a una "falta" de robustez, incluida la seguridad[3]

Un defecto puede consolidarse como un estándar de facto. Se requiere cualquier implementación del protocolo para replicar el comportamiento aberrante, o no es interoperable. Esto es tanto una consecuencia de la aplicación del principio de robustez como un producto de una renuencia natural a evitar condiciones de error fatales. Asegurar la interoperabilidad en este entorno a menudo se conoce como el objetivo de ser "compatible de error por error".

En 2018, un documento sobre tecnologías de mejora de la privacidad de Florentin Rochet y Olivier Pereira mostró cómo explotar el principio de robustez de Postel dentro del protocolo de enrutamiento Tor para comprometer el anonimato de los servicios onion y los clientes de Tor.[4]

Véase también editar

Referencias editar

  1. Transmission Control Protocol, doi:10.17487/RFC0761, RFC 761 .
  2. Wilde, Erik (2012). Wilde's WWW: Technical Foundations of the World Wide Web. Springer‑Verlag. p. 26. ISBN 978-3-642-95855-7. doi:10.1007/978-3-642-95855-7. 
  3. The Harmful Consequences of the Robustness Principle .
  4. Rochet, Florentin; Pereira, Olivier (2018). «Dropping on the Edge: Flexibility and Traffic Confirmation in Onion Routing Protocols». Proceedings of the Privacy Enhancing Technologies Symposium (De Gruyter Open) (2): 27-46. ISSN 2299-0984. 

Enlaces externos editar