RFC 9225

Software Defects Considered Harmful

📅 published April 2022, from ietf

RFC 9225: Software Defects Considered Harmful 🐛✨ Okay bestie, this one is an Informational doc from the Independent Submission stream 💅 It was written by J. Snijders (Fastly), C. Morrow (Google), and R. van Mook (Asteroid), dated 1 April 2022, with ISSN 2070-1721. It doesn't obsolete or update any other RFCs, since none are listed in its header 🦋

Abstract 🌸

Okay so this doc is basically a giant reminder to stop putting software defects into network protocol implementations (and software in general) 😭 Defects are one of the biggest cost drivers in the networking industry, so this doc is here to spell out the best current practice on that. Main character energy. 💜

Status of This Memo 📜

This one is not an Internet Standards Track spec. It's just published for info, no cap 🧚

It's a contribution to the RFC Series, independent of any other RFC stream. The RFC Editor picked to publish it at their discretion, and they make zero statements about how useful it is for implementation or deployment 🙈 Docs the RFC Editor approves aren't candidates for any level of Internet Standard. See Section 2 of RFC 7841 for the deets.

Want the current status, any errata, or a way to give feedback? Check https://www.rfc-editor.org/info/rfc9225 ✨

Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved. 💖

This doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info), as they stand on the publication date. Please read these carefully, bestie, because they explain your rights and restrictions with respect to this doc 📚

Table of Contents 🗺️

   1.  Introduction
   2.  Requirements Language
   3.  Examples of High-Impact Software Defects
   4.  Best Current Practises
   5.  Security Considerations
   6.  IANA Considerations
   7.  References
     7.1.  Normative References
     7.2.  Informative References
   Appendix A.  Future Research
   Acknowledgements
   Authors' Addresses

1. Introduction 🦋

Software defects (informally known as "bugs") have caused innumerable system degradations and failures over the years, and they're both the cause and the effect 😭 Bugs are errors, flaws, or faults in a computer program that make it produce an incorrect or unexpected result.

(Please note: unexpected results caused by bugs are NOT a valid substitute for high-quality random number generators, though high-quality random number generators are generally not considered to be bugs. 🙈)

Okay, so to cut the number of degradations down going forward, implementers MUST NOT introduce bugs when writing software 💅 This doc explains why bugs are considered harmful and proposes a set of recommendations.

2. Requirements Language 📖

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this doc are to be read as described in BCP 14 [RFC2119] [RFC8174]. They only count when they're written in all capitals, as shown here 🎀

3. Examples of High-Impact Software Defects 💀

Let's start with a legendary one. In June 1996, the European Space Agency [ARIANE] launched an unmanned rocket that cost several billion dollars to develop, and it went [KABOOM] 40 seconds after takeoff 🚀 A software exception happened during a data conversion from a 64-bit floating point value to a 16-bit signed integer. The float being converted was bigger than a 16-bit signed integer could hold. The vehicle probably wouldn't have fallen apart if that defect hadn't been written into the software. Iconic, but make it cautionary 😭

Next, physically hard-to-reach systems are no joke either. The [NASA] Deep Impact spacecraft [DEEPIMPACT] got rendered inoperable because of a fault in its fault-protection software, which kicked off endless computer reboots 💀 Mission control couldn't recover the system because no engineers were available on-site. The commute was deemed infeasible because there weren't any reasonably priced commercial transport options in that region of the solar system 🧚

In 1983, the Soviet Union's Early Warning Satellite System [Serpukhov] announced it had detected a possible missile launch coming from the US. Thankfully, a human operator recognised this as a likely system failure 🙏 A retrospective analysis later suggested the software had misclassified reflections from cloud cover as missile launch blooms. With this bug, the software could have triggered a cascading sequence of events that might have led to the start of a planetary-scale war 😭 Seemingly innocuous software defects can have outsized impact, and sometimes it pays off to simply do nothing and wait. 🫶

The US Department of Commerce's National Institute of Standards and Technology [NIST] commissioned a study to better understand how common software defects are and what they cost society. The study estimated that about 0.6 percent of the gross domestic product is squandered on programming bugs. Each person works roughly one hour a week to pay off this debt (an hour that could've been spent in leisure), on top of any time spent dealing with the direct consequences of buggy software 💅

The universal deployment of IP networks on Avian Carriers [RFC1149] is facing a multi-decade delay. After operators discovered that birds are not real (now [confirmed] by the US Government), work began to first understand the many [quirks] of the drones' firmware before going any further with wider-scale deployment 🐦 No clear timelines exist at this point in time. Bestie, the birds are NOT the problem here, it's the firmware 😭

For more examples, check out the RISKS Digest [RISKS]. It documents a multitude of defects in technological infrastructure and their risk to society. Fair warning: unsupervised study of the Digest archive may induce a sense of panic. 🙈

4. Best Current Practises 🌈

  1. Authors MUST NOT implement bugs. 🙅‍♀️
  2. If bugs are introduced in code, they MUST be clearly documented. 📝
  3. When implementing specifications that are broken by design, it is RECOMMENDED to aggregate multiple smaller bugs into one larger bug. This will be easier to document. Instead of a lot of hard-to-track inconsequential bugs, there will be only a few easy-to-recognise significant bugs. 🧹
  4. The aphorism "It's not a bug, it's a feature" is considered rude. 💅
  5. Assume all external input is the result of (a series of) bugs. (Especially in machine-to-machine applications such as implementations of network protocols.) 🤖
  6. In fact, assume all internal inputs also are the result of bugs. 🫠

5. Security Considerations 🔐

With the production of fewer bugs, there will necessarily be fewer security impacts. To improve the collective security posture, a thorough review of ALL existing software to find any remaining bugs is RECOMMENDED. 🛡️

As it's assumed that bugs are evenly distributed through all software, it's safe to consider any piece of software bug free once a certain number of bugs have been found. 🧠

Some philosophers argue in defense of an obviously wrong contrary view: that bugs introduce a certain amount of unpredictable variance in behaviour, which in turn could serve to increase security. Such heretics might even go one step further and celebrate the existence of bugs, shielding issues from public scrutiny 🙀 However, it [ostensibly] is in society's best interest to fully disclose any and all bugs as soon as they are discovered. Full stop. 🚨

6. IANA Considerations 📋

IANA is assumed to operate flawlessly. 👑

7. References 📚

7.1. Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

7.2. Informative References

   [ARIANE]   Arnold, D. N., "The Explosion of the Ariane 5", August
              2000, <https://www-users.cse.umn.edu/~arnold/disasters/
              ariane.html>.

   [confirmed]
              US Consumer Product Safety Commission (@USCPSC), "Birds
              are real.", Twitter, 5 January 2022,
              <https://twitter.com/USCPSC/status/1478794691634155523>.

   [DEEPIMPACT]
              Wallace, M., "Subject: Re: [tz] Deep Impact: wrong time
              zone?", message to the tz@iana.org mailing list, 23
              September 2013, <https://mm.icann.org/pipermail/
              tz/2013-September/020357.html>.

   [incomplete]
              Raatikainen, P., "Gödel's Incompleteness Theorems",
              Stanford Encyclopedia of Philosophy, November 2013,
              <https://plato.stanford.edu/entries/goedel-
              incompleteness/>.

   [IRTF]     IRTF, "Internet Research Task Force",
              <https://www.irtf.org/>.

   [KABOOM]   Jure, V. A., "Kapow! Zap! Splat! How comics make sound on
              the page", The Conversation, 10 June 2021,
              <https://theconversation.com/kapow-zap-splat-how-comics-
              make-sound-on-the-page-160455>.

   [NASA]     NASA, "NASA's Deep Space Comet Hunter Mission Comes to an
              End", September 2013,
              <https://www.nasa.gov/mission_pages/deepimpact/media/
              deepimpact20130920.html>.

   [NIST]     NIST, "Software Errors Cost U.S. Economy $59.5 Billion
              Annually", Wayback Machine archive, June 2002,
              <https://web.archive.org/web/20090610052743/
              http://www.nist.gov/public_affairs/releases/n02-10.htm>.

   [ostensibly]
              Swire, P., "A Model for When Disclosure Helps Security:
              What Is Different About Computer and Network Security?", 3
              Journal on Telecommunications and High Technology Law 163,
              August 2004, <http://dx.doi.org/10.2139/ssrn.531782>.

   [quirks]   Stockton, N., "What's Up With That: Birds Bob Their Heads
              When They Walk", WIRED, January 2015,
              <https://www.wired.com/2015/01/whats-birds-bob-heads-
              walk/>.

   [RFC1149]  Waitzman, D., "Standard for the transmission of IP
              datagrams on avian carriers", RFC 1149,
              DOI 10.17487/RFC1149, April 1990,
              <https://www.rfc-editor.org/info/rfc1149>.

   [RISKS]    ACM Committee on Computers and Public Policy, "The RISKS
              Digest", <https://catless.ncl.ac.uk/Risks/>.

   [Serpukhov]
              Long, T., "Sept. 26, 1983: The Man Who Saved the World by
              Doing ... Nothing", WIRED, September 2007,
              <https://www.wired.com/2007/09/dayintech-0926-2/>.

Appendix A. Future Research 🔮

okay so this whole document kinda begs the question: what are software defects, truly? 🫠 do bugs happen for a purpose? is what we call a bug a sign of a bigger issue in the natural world?? do mistakes happen in other domains too? are they evidence of a superior software architect? 💀

an interdisciplinary approach to understanding mistakes might be an area of further study for the [IRTF]. it may very well turn out that mistakes are provably detrimental in all domains; however, the authors do not feel qualified to make any statements in this regard 🙈 once people are made aware of the above thesis, research-oriented interest groups could perhaps take on the task of disproving Goedel's incompleteness theorem [incomplete], and in doing so, put an end to all bugs. the main character energy of this paragraph is unmatched 👑✨

Acknowledgements 🫶

the authors wish to thank Bert Hubert, Peter van Dijk, and Saku Ytti for pointing out the many errors Job introduced during the preparation of this document 😭 the real MVPs 🌸

Authors' Addresses 💌

Job Snijders 🧚

Job Snijders
Fastly
Amsterdam
Netherlands
Email: job@fastly.com

Chris Morrow 🦋

Chris Morrow
Google
Reston, Virginia
United States of America
Email: morrowc@ops-netman.net

Remco van Mook 🍓

Remco van Mook
Asteroid
Deventer
Netherlands
Email: remco@asteroidhq.com
📦 where this page comes from