Robustness principle: Difference between revisions

Revision as of 09:29, 13 September 2018

Latest revision as of 00:18, 30 May 2025

(42 intermediate revisions by 32 users not shown)

Line 1:

In{{Short [[computing]], the '''robustness principle''' is a designdescription|Design guideline for software:}}

In [[computing]], the '''robustness principle''' is a design guideline for software that states: "be conservative in what you do, be liberal in what you accept from others". It is often reworded as: "be conservative in what you send, be liberal in what you accept". The principle is also known as '''Postel's law''', after [[Jon Postel]], who wroteused the wording in an early specification of [[Transmission Control Protocol|TCP]]:.<ref>{{cite IETF |title=Transmission Control Protocol |rfc=761 |editor1-last=Postel |editor1-first=Jon |editor1-link=Jon Postel |yeardate=January 1980 |month=January |publisher=[[Internet Engineering Task Force|IETF]] |accessdateaccess-date=June 9, 2014}}</ref>

:''Be conservative in what you do, be liberal in what you accept from others'' (often reworded as "Be conservative in what you send, be liberal in what you accept").

The principle is also known as '''Postel's law''', after [[Jon Postel]], who wrote in an early specification of [[Transmission Control Protocol|TCP]]:<ref>{{cite IETF |title=Transmission Control Protocol |rfc=761 |editor1-last=Postel |editor1-first=Jon |editor1-link=Jon Postel |year=1980 |month=January |publisher=[[Internet Engineering Task Force|IETF]] |accessdate=June 9, 2014}}</ref>

:TCP implementations should follow a general principle of robustness: be conservative in what you do, be liberal in what you accept from others.

In other words, programs that send messages to other machines (or to other programs on the same machine) should conform completely to the specifications, but programs that receive messages should accept non-conformant input as long as the meaning is clear.

Among programmers, to produce [[Liskov substitution principle|compatible functions]], the principle is popularized{{Cn|date=Marchalso 2016}}known in the form: be [[Covariance and contravariancecontravariant (computer scienceprogramming)|be contravariant]] in the input type and [[covariant (programming)|covariant]] in the output type]].

== Interpretation ==

The principle was first written down by Jon Postel in the 1979 [[IPv4]] specification.<ref>{{Cite book |last1=Council |first1=National Research |url=https://books.google.com/books?id=lm2C8PJY-NYC&pg=PA39 |title=The Internet's Coming of Age |last2=Sciences |first2=Division on Engineering and Physical |last3=Applications |first3=Commission on Physical Sciences, Mathematics, and |last4=Board |first4=Computer Science and Telecommunications |last5=Infrastructure |first5=Committee on the Internet in the Evolving Information |date=2001-01-22 |publisher=National Academies Press |isbn=978-0-309-17205-9 |language=en}}</ref> RFC 1122 (1989) expanded on Postel's principle by recommending that programmers "assume that the network is filled with malevolent entities that will send in packets designed to have the worst possible effect".<ref>{{cite IETF |title=Requirements for Internet Hosts: Communication Layers |rfc=1122 |editor1-last=Braden |editor1-first=R. |editor1-link=Bob Braden |yeardate=October 1989 |month=October |publisher=[[Internet Engineering Task Force|IETF]] |accessdateaccess-date=June 9, 2014}}</ref> Protocols should allow for the addition of new codes for existing fields in future versions of protocols by accepting messages with unknown codes (possibly logging them). Programmers should avoid sending messages with "legal but obscure protocol features" that might expose deficiencies in receivers, and design their code "not just to survive other misbehaving hosts, but also to cooperate to limit the amount of disruption such hosts can cause to the shared communication facility".<ref name="Wilde2012">{{cite book |last=Wilde |first=Erik |title=Wilde's WWW: Technical Foundations of the World Wide Web |url=https://booksarchive.google.comorg/books?id=w7mrCAAAQBAJ&pg=PA26details/springer_10.1007-978-3-642-95855-7 |date=2012 |orig-year=1999 |publisher=Springer‑Verlag |doi=10.1007/978-3-642-95855-7 |isbn=978-3-642-95855-7| page=[https://archive.org/details/springer_10.1007-978-3-642-95855-7/page/n48 26]|s2cid=19897299 }}</ref>

== Criticism ==

In 2001, [[Marshall Rose]] characterized several deployment problems when applying Postel's principle in the design of a new application protocol.<ref>{{cite IETF |title=On the Design of Application Protocols |rfc=3117 |last=Rose |first=M. |authorlinkauthor-link=Marshall Rose |yeardate=November 2001 |month=November |publisher=[[Internet Engineering Task Force|IETF]] |accessdateaccess-date=June 9, 2014}}</ref> For example, a defective implementation that sends non-conforming messages might be used only with implementations that tolerate those deviations from the specification until, possibly several years later, it is connected with a less tolerant application that rejects its messages. In such a situation, identifying the problem is often difficult, and deploying a solution can be costly. Rose therefore recommended "explicit consistency checks in a protocol&nbsp;... even if they impose implementation overhead".

In 2018, a paper on [[privacy-enhancing technologies]] by Florentin Rochet and Olivier Pereira showed how to exploit Postel's robustness principle inside the [[Tor (anonymity network)|Tor]] [[Onion routing|routing protocol]] to compromise the anonymity of onion services and Tor clients.<ref>{{cite journal | url = https://petsymposium.org/2018/files/papers/issue2/popets-2018-0011.pdf | title = Dropping on the Edge: Flexibility and Traffic Confirmation in Onion Routing Protocols | authorsfirst1 = Florentin | last1 = Rochet and| first2= Olivier | last2 = Pereira | journal = Proceedings of the Privacy Enhancing Technologies Symposium | issn = 2299-0984 | publisher = De Gruyter Open | year = 2018 | volume = 2018 | issue = 2 | pages = 27–46 | doi = 10.1515/popets-2018-0011 }}</ref>

In 2023, Martin Thomson and David Schinazi argued that Postel's robustness principle actually leads to a ''lack'' of robustness, including security:{{Ref RFC|9413}}{{Quote|A flaw can become entrenched as a de facto standard. Any implementation of the protocol is required to replicate the aberrant behavior, or it is not interoperable. This is both a consequence of tolerating the unexpected and a product of a natural reluctance to avoid fatal error conditions. Ensuring interoperability in this environment is often referred to as aiming to be "[[bug-for-bug compatible]]".}}

In a 2017 [[Internet-Draft]], Martin Thomson argues that Postel's robustness principle actually leads to a ''lack'' of robustness, including security.<ref>{{cite IETF |title=The Harmful Consequences of Postel's Maxim |last=Thomson |first=Martin |year=2017 |month=October |url=https://tools.ietf.org/html/draft-thomson-postel-was-wrong-02 |publisher=[[Internet Engineering Task Force|IETF]] |accessdate=January 15, 2018}}</ref>

== See also ==

In 2018, a paper on [[privacy-enhancing technologies]] by Florentin Rochet and Olivier Pereira showed how to exploit Postel's robustness principle inside the [[Tor (anonymity network)|Tor]] [[Onion routing|routing protocol]] to compromise the anonymity of onion services and Tor clients.<ref>{{cite journal | url = https://petsymposium.org/2018/files/papers/issue2/popets-2018-0011.pdf | title = Dropping on the Edge: Flexibility and Traffic Confirmation in Onion Routing Protocols | authors = Florentin Rochet and Olivier Pereira | journal = Proceedings of the Privacy Enhancing Technologies Symposium | issn = 2299-0984 | publisher = De Gruyter Open | year = 2018 | issue = 2 | pages = 27–46 }}</ref>

{{Portal|Internet}}

* [[Normalization of deviance]]

* [[Open–closed principle]]

* [[Protocol ossification]]

* [[Static discipline]]

* [[Unix philosophy]]

== References ==

{{reflist|30em}}

== External links ==

* [httphttps://ironick.typepad.com/ironick/2005/05/my_history_of_t.html History of the principle(Internet) Robustness Principle] (Nick Gall, May 2005)

* [httphttps://www.postel.org/ien/txt/ien111.txt#line=1483 Internet Protocol], page 22; J. Postel, [[Internet Experiment Note|IEN]] 111, August 1979.

* [https://tools.ietf.org/html/draft-thomson-postel-was-wrong-00 The Harmful Consequences of Postel's Maxim]

[[Category:Computer architecture statements]]