Wednesday, May 25, 2005

My history of the (Internet) Robustness Principle. [In making what I thought was a small update to my copy of a quotation of the Robustness Principle, I quickly fell down the rat hole of documenting as many versions of it as I could find. Here are the fruits of my labor. Full text of the RFCs can be viewed at the RFC Sourcebook. See also my earlier post regarding the Robustness Principle. I am posting this in monospace font in homage to the RFC style. (Besides, I'm too lazy to reformat.) I have to use the small font to make the margins fit. If you find it difficult to read, just cut and paste into your favorite editor (Notepad, Word, Emacs). -- NLG] The Internet Robustness Principle: "Be liberal in what you accept, and conservative in what you send." Attributed to Jon Postel. See the Postel Center In Memoriam web page: http://www.postel.org/postel.html According to the Postel Center, the principle originated in RFC 760 "DOD STANDARD INTERNET PROTOCOL" (1980) using different wording: 3.2. Discussion The implementation of a protocol must be robust. Each implementation must expect to interoperate with others created by different individuals. While the goal of this specification is to be explicit about the protocol there is the possibility of differing interpretations. In general, an implementation should be conservative in its sending behavior, and liberal in its receiving behavior. That is, it should be careful to send well-formed datagrams, but should accept any datagram that it can interpret (e.g., not object to technical errors where the meaning is still clear). This may be the first RFC containing the principle, but two prior "Internet" specs contain the principle as well: IEN 111 "Internet Protocol" (August 1979) and IEN 123 " DOD STANDARD INTERNET PROTOCOL" (December 1979). The context and wording are identical, so the text is not quoted again. It next appears in RFC 761 "DOD STANDARD TRANSMISSION CONTROL PROTOCOL" (1980), this time with the designation of "Robustness Principle": 2.10. Robustness Principle TCP implementations should follow a general principle of robustness: be conservative in what you do, be liberal in what you accept from others. Notice the switch from "sending behavior" to simply "do" and the switch from "receiving behavior" to "accept". It also [next?] appears in RFC 791 "Internet Protocol" (1981), which obsoleted RFC 760: 3.2 Discussion The implementation of a protocol must be robust. Each implementation must expect to interoperate with others created by different individuals. While the goal of this specification is to be explicit about the protocol there is the possibility of differing interpretations. In general, an implementation <> be conservative in its sending behavior, and liberal in its receiving behavior. That is, it <> be careful to send well-formed datagrams, but <> accept any datagram that it can interpret (e.g., not object to technical errors where the meaning is still clear). Notice the change from "should" to "must". It also [next?] appears in RFC 793 "Transmission Control Protocol" (1981). The context and wording are identical, so the text is not quoted again. It also [next?] appears in RFC 1122 "Requirements for Internet Hosts -- Communication Layers" (1989) 1.2.2 Robustness Principle At every layer of the protocols, there is a general rule whose application can lead to enormous benefits in robustness and interoperability [IP:1]: "Be liberal in what you accept, and conservative in what you send" Software should be written to deal with every conceivable error, no matter how unlikely; sooner or later a packet will come in with that particular combination of errors and attributes, and unless the software is prepared, chaos can ensue. In general, it is best to assume that the network is filled with malevolent entities that will send in packets designed to have the worst possible effect. This assumption will lead to suitable protective design, although the most serious problems in the Internet have been caused by unenvisaged mechanisms triggered by low-probability events; mere human malice would never have taken so devious a course! Adaptability to change must be designed into all levels of Internet host software. As a simple example, consider a protocol specification that contains an enumeration of values for a particular header field -- e.g., a type field, a port number, or an error code; this enumeration must be assumed to be incomplete. Thus, if a protocol specification defines four possible error codes, the software must not break when a fifth code shows up. An undefined code might be logged (see below), but it must not cause a failure. The second part of the principle is almost as important: software on other hosts may contain deficiencies that make it unwise to exploit legal but obscure protocol features. It is unwise to stray far from the obvious and simple, lest untoward effects result elsewhere. A corollary of this is "watch out for misbehaving hosts"; host software should be prepared, 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. While it is clear that the quoted text is quoting Jon Postel, it is not clear whose interpretation of that text follows in the remainder of section 1.2.2. The author of the RFC is Robert (Bob) Braden. Who worked at ISI with Jon Postel and authored other RFCs with hime (e.g., RFC 1009). Note that RFC 1122 is the RFC referenced by the Postel Center In Memoriam page. What I like about the RFC 1122 version of the Robustness Principle is that it clarifies a common misconception about the Robustness Principle, which is that it makes receiving systems vulnerable to attack. On the contrary, the principle as interpreted in RFC 1122 advises: "In gerneral, it is best to assume that the network is filled with malevolent entities that will send in packets designed to have the worst possible effect. This assumption will lead to suitable protective design..." Notice also that this version says that it applies at "every layer of the protocols"--including the application layer. The last [latest?] formulation of the Robustness Principle is in RFC 1958 "Architectural Principles of the Internet" (1996): 3.9 Be strict when sending and tolerant when receiving. Implementations must follow specifications precisely when sending to the network, and tolerate faulty input from the network. When in doubt, discard faulty input silently, without returning an error message unless this is required by the specification. I personally think this is a poor version of the principle and leads to much of the misunderstanding about it. It seems to advise a passive approach to "tolerance" and "liberal acceptance". The Robustness Principle obviously also applies to life. Tim Berners-Lee has made this part of his religious beliefs, see: http://www.w3.org/People/Berners-Lee/UU.html and http://www.w3.org/DesignIssues/Principles.html. 6:06:37 AM