RFC 8774

The Quantum Bug

📅 published April 2020, from ietf

RFC 8774: The Quantum Bug 🎀

okay bestie, here's the deets on this one 💖

  • Author: Michael Welzl, University of Oslo 🎓
  • Stream: Independent Submission
  • Category: Informational
  • Date: 1 April 2020 📅
  • ISSN: 2070-1721
  • Obsoletes or updates: there's no Obsoletes or Updates line on this one 🙅‍♀️

Abstract

okay so the age of quantum networking is literally here 🌈 and with it comes "entanglement" ✨: a procedure where a state (aka a bit) can be transferred instantly, with no measurable delay between peers. this means some Internet paths could show a perceived round-trip time of zero seconds 😳. nobody predicted that, so a lot of protocol specs never included it as a possibility. worse than the millennium bug 💀, this unexpected value is bound to cause serious Internet failures unless the specs get fixed in time!!

Status of This Memo

this doc is not an Internet Standards Track spec, it's published for informational purposes 📝

this is a contribution to the RFC Series, independently of any other RFC stream. the RFC Editor chose to publish it at their discretion and makes no statement about its value for implementation or deployment. documents approved for publication by the RFC Editor aren't candidates for any level of Internet Standard, see Section 2 of RFC 7841 🙃

info about the current status of this doc, any errata, and how to give feedback is at https://www.rfc-editor.org/info/rfc8774 🔗

Copyright (c) 2020 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) in effect on the date of publication. please review those carefully, because they describe your rights and restrictions with respect to this doc 📜

Table of Contents 🗂️

  • 1. Introduction
  • 2. Protocols and Protocol Mechanisms That Will Fail
    • 2.1. LEDBAT
    • 2.2. Multipath TCP (MPTCP)
    • 2.3. RTP Circuit Breakers
  • 3. What can be done?
  • 4. Conclusion
  • 5. IANA Considerations
  • 6. Security Considerations
  • 7. References
    • 7.1. Normative References
    • 7.2. Informative References
  • Author's Address

1. Introduction 🦋

okay so [RFC6921] talks about faster-than-light communication, where packets arrive before they're sent. it's a fun thing to entertain, time travel is giving main character energy ⏳, but we have to accept the cold facts: time travel will never work (or it would already have been used). quantum networking, though, is a totally different story. commercial products are already available, and quantum networks will without a doubt become the prevalent Internet link-layer technology across the globe within the next five to ten years 🌍

with the help of entanglement, implemented in quantum repeaters, quantum networks can transfer information faster than ever before. a state can be transmitted over a long distance instantly, with no delay. this is so cool that it's also called (and, by some, mistaken for) teleportation 🧚. if a path between a sender and a receiver is fully quantum-ized, the measured one-way delay (OWD) will be zero. what's more, assuming there are blazing fast quantum computers involved on both ends, the processing time will be well below anything measurable. so even the round-trip time (RTT) will be zero in these scenarios 🤯

in today's Internet, only a very few protocols are prepared for these "0-RTT" situations (e.g., TCP with "TCP Fast Open" (TFO) [RFC7413], TLS 1.3 [RFC8446], and QUIC [QUIC-TRANS]). many others will fail in interesting ways, so we coined the term "Quantum Bug" for those failures 🐛. in the next section we'll go through some examples of Quantum Bugs 🔍

2. Protocols and Protocol Mechanisms That Will Fail 💀

the number of protocols and protocol mechanisms that will fail in the face of a zero RTT is too large to report here. we are truly heading towards something close to an Internet meltdown 😭. we can only offer some guidance to those hunting for the Quantum Bug, by discussing examples of specification mistakes that will need fixing 🛠️

2.1. LEDBAT

the Low Extra Delay Background Transfer (LEDBAT) congestion control mechanism [RFC6817] is a very interesting failure case. it's designed to "get out of the way" of other traffic, but it ends up sending as fast as possible 🏃‍♀️💨. specifically, when the algorithm described in Section 2.4.2 of [RFC6817] obtains a delay sample, it updates a list of base delays that will all become 0, and current delays that will also all become 0. it calculates a queuing delay as the difference between the current delay and the base delay (resulting in 0), and keeps increasing the Congestion Window (cwnd) until the queuing delay reaches a predefined parameter value TARGET (100 milliseconds or less).

a TARGET value of 100 milliseconds will never be reached, because the queuing delay doesn't grow when the sender increases its cwnd. this means LEDBAT would endlessly increase its cwnd, limited only by the number of bits used to represent cwnd 😵. however, since TARGET=0 is also allowed, this parameter choice might seem like a way out 🙏. staying at the target would mean the sender keeps its initial cwnd, which should be set to 2. that might sound like a small number, but remember that cwnd is the number of bytes that can be transmitted per RTT (which is 0) 🫠. so irrespective of the TARGET value, the sender will send data as fast as it can.

2.2. Multipath TCP (MPTCP)

the coupled congestion control mechanism proposed for MPTCP in [RFC6356] requires calculating a value called "alpha". Equation 2 in [RFC6356] has a term where a value called "cwnd_i" is divided by the square of the RTT, and another term where this value is divided by the RTT. enough said 💅

2.3. RTP Circuit Breakers

the RTP Circuit Breakers [RFC8083] require calculating a well-known equation that yields the throughput of a TCP connection 🧮:

                             s
   X = -------------------------------------------------------------
     Tr*sqrt(2*b*p/3)+(t_RTO * (3*sqrt(3*b*p/8) * p * (1+32*p*p)))

where Tr is the RTT and t_RTO is the retransmission timeout of TCP (we don't need to care about the other variables). as we'll discuss in Section 3, t_RTO is lower-bounded with 1 second, so it saves us from a division by zero 🙌. however, there's also a simplified version of this equation:

          s
   X = ----------------
       Tr*sqrt(2*b*p/3)

unfortunately, [RFC8083] states: "It is RECOMMENDED that this simplified throughput equation be used since the reduction in accuracy is small, and it is much simpler to calculate than the full equation." because of this simplification, many multimedia applications will crash 💥

3. What can be done? 🤔

fear not 🫶: when everything else fails, TCP will still work. its retransmission timeout is lower-bounded by 1 second [RFC6298]. also, while its cwnd may grow up to the maximum storable number, data transmission is limited by the Receiver Window (rwnd). this means flow control will save TCP from failing 🛟

from this we can learn two simple rules: lower-bound any values calculated from the RTT (and, obviously, do not divide by the RTT), and use flow control. specifications will need to be updated by fixing all RTT-based calculations and introducing flow control everywhere. for example, UDP will have to be extended with a receiver window, e.g., as a UDP option [UDP-OPT] 🧁

4. Conclusion 👑

we are in trouble, and there's only one way out: develop a comprehensive list of all RFCs containing "0-RTT" mistakes (taking [RFC2626] as a guideline), and update all code. this needs to happen fast, the clock is ticking ⏰. luckily, if we're too slow, we can still use TCP to access the specifications. with DNS over TCP [RFC7766], name resolution to find the server containing the specifications should also work 🧚‍♀️

5. IANA Considerations 📋

this document has no IANA actions ✨

6. Security Considerations 🚨

flow control must be used on 0-RTT paths, or else an attacker can completely overwhelm a sender with data in a denial-of-service (DoS) attack within an instant. flow control will need to be added to protocols that don't currently have it, such as UDP or ICMP. IPv6 will not save us. 😱

7. References 📚

7.1. Normative References

7.2. Informative References

Author's Address 📮

Michael Welzl
University of Oslo
PO Box 1080 Blindern
N-0316 Oslo
Norway

Phone: +47 22 85 24 20
Email: michawe@ifi.uio.no
📦 where this page comes from