RFC 8774 - The Quantum Bug 日本語訳

原文URL : https://www.rfc-editor.org/rfc/rfc8774.html
タイトル : RFC 8774 - 量子バグ
翻訳編集 : 自動生成

[要約] RFC 8774は、量子コンピュータにおけるバグの特性と対策についての情報を提供するものです。その目的は、量子コンピュータのセキュリティと信頼性を向上させるためのガイドラインを提供することです。

Independent Submission                                          M. Welzl
Request for Comments: 8774                            University of Oslo
Category: Informational                                     1 April 2020
ISSN: 2070-1721

The Quantum Bug

量子バグ

Abstract

概要

The age of quantum networking is upon us, and with it comes "entanglement": a procedure in which a state (i.e., a bit) can be transferred instantly, with no measurable delay between peers. This will lead to a perceived round-trip time of zero seconds on some Internet paths, a capability which was not predicted and so not included as a possibility in many protocol specifications. Worse than the millennium bug, this unexpected value is bound to cause serious Internet failures unless the specifications are fixed in time.

量子ネットワーキングの時代が到来し、それに伴って「エンタングルメント」が生じます。ピア間で測定可能な遅延なしに、状態（つまり、ビット）を即座に転送できる手順です。これにより、一部のインターネットパスで認識される往復時間が0秒になります。これは、予測されていなかったため、多くのプロトコル仕様に含まれていない可能性がある機能です。ミレニアムバグよりも悪い、この予期しない値は、仕様が時間内に修正されない限り、深刻なインターネット障害を引き起こす可能性があります。

Status of This Memo

本文書の状態

This document is not an Internet Standards Track specification; it is published for informational purposes.

このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。

This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not candidates for any level of Internet Standard; see Section 2 of RFC 7841.

これは、他のRFCストリームとは無関係に、RFCシリーズへの貢献です。 RFCエディターは、このドキュメントを独自の裁量で公開することを選択し、実装または展開に対するその価値については何も述べていません。 RFC Editorによって公開が承認されたドキュメントは、どのレベルのインターネット標準の候補にもなりません。 RFC 7841のセクション2をご覧ください。

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8774.

このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8774で入手できます。

著作権表示

著作権（c）2020 IETFトラストおよびドキュメントの作成者として識別された人物。全著作権所有。

This document 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 of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.

この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（https://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。

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

1. はじめに

[RFC6921] discusses faster-than-light communication, where packets arrive before they are sent. While it is amusing to entertain the possibility of time travel, we have to accept the cold facts: time travel will never work (or it would already have been used). Quantum networking, however, is an entirely different matter -- 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.

[RFC6921]は、パケットが送信される前に到着する、光よりも速い通信について説明しています。タイムトラベルの可能性を楽しませるのは楽しいですが、私たちは冷たい事実を受け入れなければなりません：タイムトラベルは決して機能しません（またはすでに使用されていました）。ただし、量子ネットワーキングはまったく別の問題です。商用製品はすでに利用可能であり、量子ネットワークは間違いなく、今後5〜10年以内に世界中で普及しているインターネットリンク層テクノロジーになるでしょう。

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 is 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 that there are blazing fast quantum computers involved on both ends, the processing time will be well below anything measurable; hence, even the round-trip time (RTT) will be zero in these scenarios.

量子リピーターに実装されたエンタングルメントの助けを借りて、量子ネットワークはこれまでになく速く情報を転送できます。状態は遅延なしで瞬時に長距離を伝送できます。これはとてもかっこいいので、テレポーテーションとも呼ばれます（一部では誤解されています）。送信側と受信側の間のパスが完全に量子化されている場合、測定された一方向遅延（OWD）はゼロになります。さらに、両端に非常に高速な量子コンピュータが含まれていると仮定すると、処理時間は測定可能なものよりはるかに短くなります。したがって、これらのシナリオでは、往復時間（RTT）もゼロになります。

In today's Internet, only very few protocols are prepared for such "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; we coin the term "Quantum Bug" for such failures. In the following section, we will discuss some examples of Quantum Bugs.

今日のインターネットでは、このような「0-RTT」の状況に対応できるプロトコルはごくわずかしか用意されていません（たとえば、「TCP Fast Open」（TFO）を使用したTCP [RFC7413]、TLS 1.3 [RFC8446]、QUIC [QUIC-TRANS]）。他の多くは興味深い方法で失敗します。私たちは、そのような失敗を「量子バグ」という言葉で名付けました。次のセクションでは、量子バグのいくつかの例について説明します。

2. Protocols and Protocol Mechanisms That Will Fail

2. 失敗するプロトコルとプロトコルメカニズム

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 provide some guidance to those who hunt for the Quantum Bug, by discussing examples of specification mistakes that will need to be fixed.

RTTがゼロの場合に失敗するプロトコルとプロトコルメカニズムの数は多すぎるため、ここでは報告できません。私たちは本当にインターネットのメルトダウンに近いものに向かっています。修正が必要な仕様の間違いの例を説明することによって、Quantum Bugを探す人にいくつかのガイダンスを提供できます。

2.1. LEDBAT

The Low Extra Delay Background Transfer (LEDBAT) congestion control mechanism [RFC6817] is a very interesting failure case: designed to "get out of the way" of other traffic; it will end 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).

低余分遅延バックグラウンド転送（LEDBAT）輻輳制御メカニズム[RFC6817]は、非常に興味深い障害ケースです。他のトラフィックの「邪魔にならない」ように設計されています。できるだけ早く送信されます。具体的には、[RFC6817]のセクション2.4.2で説明されているアルゴリズムが遅延サンプルを取得すると、すべて0になる基本遅延とすべて0になる現在の遅延のリストを更新します。差としてキューイング遅延を計算します現在の遅延とベース遅延（結果は0）の間であり、キューイング遅延が事前定義されたパラメーター値TARGET（100ミリ秒以下）に達するまで、輻輳ウィンドウ（cwnd）を増やし続けます。

A TARGET value of 100 milliseconds will never be reached, because the queuing delay does not grow when the sender increases its cwnd; this means that LEDBAT would endlessly increase its cwnd, limited only by the number of bits that are used to represent cwnd. However, given that TARGET=0 is also allowed, this parameter choice may seem to be a way out. Always staying at the target means that the sender would maintain its initial cwnd, which should be set to 2. This may seem like a small number, but remember that cwnd is the number of bytes that can be transmitted per RTT (which is 0). Thus, irrespective of the TARGET value, the sender will send data as fast as it can.

送信者がcwndを増やしてもキューイング遅延は大きくならないため、100ミリ秒のTARGET値には決して到達しません。これは、LEDBATがそのcwndを無限に増加させることを意味し、cwndを表すために使用されるビット数によってのみ制限されます。ただし、TARGET = 0も許可されている場合、このパラメーターの選択は回避策のように思えるかもしれません。常にターゲットに留まるということは、送信者が初期のcwndを維持することを意味します。これは2に設定する必要があります。これは小さな数値のように見えるかもしれませんが、cwndはRTTごとに送信できるバイト数（0）であることに注意してください。したがって、TARGET値に関係なく、送信側はデータをできるだけ速く送信します。

2.2. Multipath TCP (MPTCP)

2.2. マルチパスTCP（MPTCP）

The coupled congestion control mechanism proposed for MPTCP in [RFC6356] requires calculating a value called "alpha". Equation 2 in [RFC6356] contains 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.

[RFC6356]でMPTCP用に提案された結合輻輳制御メカニズムは、「アルファ」と呼ばれる値を計算する必要があります。 [RFC6356]の式2には、「cwnd_i」と呼ばれる値をRTTの2乗で割った項と、この値をRTTで割った別の項が含まれています。十分に言った。

2.3. RTP Circuit Breakers

2.3. RTPサーキットブレーカー

The RTP Circuit Breakers [RFC8083] require calculation of a well-known equation which yields the throughput of a TCP connection:

RTPサーキットブレーカー[RFC8083]では、TCP接続のスループットを生成するよく知られた方程式の計算が必要です。

                             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 will discuss in Section 3, t_RTO is lower-bounded with 1 second; therefore, it saves us from a division by zero. However, there is also a simplified version of this equation:

ここで、TrはRTT、t_RTOはTCPの再送信タイムアウトです（他の変数を気にする必要はありません）。セクション3で説明するように、t_RTOの下限は1秒です。したがって、ゼロによる除算から私たちを救います。ただし、この方程式の簡略版もあります。

             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." Due to this simplification, many multimedia applications will crash.

残念ながら、[RFC8083]は次のように述べています。「精度の低下は小さく、完全な方程式より計算がはるかに簡単なので、この簡略化されたスループット方程式を使用することをお勧めします。」この単純化により、多くのマルチメディアアプリケーションがクラッシュします。

3. What can be done?

3. 何ができますか？

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

恐れる必要はありません。他のすべてが失敗しても、TCPは引き続き機能します。その再送信タイムアウトは1秒の下限です[RFC6298]。さらに、そのcwndは最大保存可能数まで増加する可能性がありますが、データ送信はレシーバーウィンドウ（rwnd）によって制限されます。これは、フロー制御がTCPの失敗を防ぐことを意味します。

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].

このことから、RTTから計算された値の下限（そしてもちろん、RTTで除算しないこと）とフロー制御の使用という2つの単純なルールを学ぶことができます。すべてのRTTベースの計算を修正し、どこにでもフロー制御を導入することにより、仕様を更新する必要があります。たとえば、UDPは、たとえばUDPオプション[UDP-OPT]として、受信側ウィンドウで拡張する必要があります。

4. Conclusion

4. 結論

We are in trouble, and there is 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 are too slow, we will still be able to use TCP to access the specifications. With DNS over TCP [RFC7766], name resolution to find the server containing the specifications should also work.

私たちは問題を抱えており、解決策は1つだけです。「0-RTT」の誤りを含むすべてのRFCの包括的なリストを作成し（[RFC2626]をガイドラインとして）、すべてのコードを更新します。これは速く起こる必要があり、時計が刻々と過ぎています。幸い、速度が遅すぎても、TCPを使用して仕様にアクセスできます。 DNS over TCP [RFC7766]では、仕様を含むサーバーを見つける名前解決も機能するはずです。

5. IANA Considerations

5. IANAに関する考慮事項

This document has no IANA actions.

このドキュメントにはIANAアクションはありません。

6. Security Considerations

6. セキュリティに関する考慮事項

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 do not currently have it, such as UDP or ICMP. IPv6 will not save us.

フロー制御は0-RTTパスで使用する必要があります。そうしないと、攻撃者は瞬時にサービス拒否（DoS）攻撃で送信者をデータで完全に圧倒できます。フロー制御は、UDPやICMPなど、現在それが存在しないプロトコルに追加する必要があります。 IPv6は私たちを救いません。

7. References

7. 参考文献

7.1. Normative References

7.1. 引用文献

[RFC2626] Nesser II, P., "The Internet and the Millennium Problem (Year 2000)", RFC 2626, DOI 10.17487/RFC2626, June 1999, <https://www.rfc-editor.org/info/rfc2626>.

[RFC2626] Nesser II、P。、「インターネットとミレニアム問題（2000年）」、RFC 2626、DOI 10.17487 / RFC2626、1999年6月、<https://www.rfc-editor.org/info/rfc2626> 。

[RFC6921] Hinden, R., "Design Considerations for Faster-Than-Light (FTL) Communication", RFC 6921, DOI 10.17487/RFC6921, April 2013, <https://www.rfc-editor.org/info/rfc6921>.

[RFC6921] Hinden、R。、「Fast-Than-Light（FTL）Communicationに関する設計上の考慮事項」、RFC 6921、DOI 10.17487 / RFC6921、2013年4月、<https://www.rfc-editor.org/info/rfc6921 >。

7.2. Informative References

7.2. 参考引用

[QUIC-TRANS] Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed and Secure Transport", Work in Progress, Internet-Draft, draft-ietf-quic-transport-27, 21 February 2020, <https://tools.ietf.org/html/draft-ietf-quic-transport-27>.

[QUIC-TRANS] Iyengar、J。およびM. Thomson、「QUIC：UDPベースの多重化された安全なトランスポート」、進行中の作業、インターネットドラフト、draft-ietf-quic-transport-27、2020年2月21日、< https://tools.ietf.org/html/draft-ietf-quic-transport-27>。

[RFC6298] Paxson, V., Allman, M., Chu, J., and M. Sargent, "Computing TCP's Retransmission Timer", RFC 6298, DOI 10.17487/RFC6298, June 2011, <https://www.rfc-editor.org/info/rfc6298>.

[RFC6298] Paxson、V.、Allman、M.、Chu、J。、およびM. Sargent、「Computing TCP's Retransmission Timer」、RFC 6298、DOI 10.17487 / RFC6298、2011年6月、<https：//www.rfc- editor.org/info/rfc6298>。

[RFC6356] Raiciu, C., Handley, M., and D. Wischik, "Coupled Congestion Control for Multipath Transport Protocols", RFC 6356, DOI 10.17487/RFC6356, October 2011, <https://www.rfc-editor.org/info/rfc6356>.

[RFC6356] Raiciu、C.、Handley、M。、およびD. Wischik、「マルチパストランスポートプロトコルの結合された輻輳制御」、RFC 6356、DOI 10.17487 / RFC6356、2011年10月、<https：//www.rfc-editor。 org / info / rfc6356>。

[RFC6817] Shalunov, S., Hazel, G., Iyengar, J., and M. Kuehlewind, "Low Extra Delay Background Transport (LEDBAT)", RFC 6817, DOI 10.17487/RFC6817, December 2012, <https://www.rfc-editor.org/info/rfc6817>.

[RFC6817] Shalunov、S.、Hazel、G.、Iyengar、J。、およびM. Kuehlewind、「Low Extra Delay Background Transport（LEDBAT）」、RFC 6817、DOI 10.17487 / RFC6817、2012年12月、<https：// www.rfc-editor.org/info/rfc6817>。

[RFC7413] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP Fast Open", RFC 7413, DOI 10.17487/RFC7413, December 2014, <https://www.rfc-editor.org/info/rfc7413>.

[RFC7413] Cheng、Y.、Chu、J.、Radhakrishnan、S。、およびA. Jain、「TCP Fast Open」、RFC 7413、DOI 10.17487 / RFC7413、2014年12月、<https：//www.rfc-editor .org / info / rfc7413>。

[RFC7766] Dickinson, J., Dickinson, S., Bellis, R., Mankin, A., and D. Wessels, "DNS Transport over TCP - Implementation Requirements", RFC 7766, DOI 10.17487/RFC7766, March 2016, <https://www.rfc-editor.org/info/rfc7766>.

[RFC7766] Dickinson、J.、Dickinson、S.、Bellis、R.、Mankin、A。、およびD. Wessels、「DNS Transport over TCP-実装要件」、RFC 7766、DOI 10.17487 / RFC7766、2016年3月、< https://www.rfc-editor.org/info/rfc7766>。

[RFC8083] Perkins, C. and V. Singh, "Multimedia Congestion Control: Circuit Breakers for Unicast RTP Sessions", RFC 8083, DOI 10.17487/RFC8083, March 2017, <https://www.rfc-editor.org/info/rfc8083>.

[RFC8083] Perkins、C。およびV. Singh、「Multimedia Congestion Control：Circuit Breakers for Unicast RTP Sessions」、RFC 8083、DOI 10.17487 / RFC8083、2017年3月、<https://www.rfc-editor.org/info / rfc8083>。

[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, <https://www.rfc-editor.org/info/rfc8446>.

[RFC8446] Rescorla、E。、「The Transport Layer Security（TLS）Protocol Version 1.3」、RFC 8446、DOI 10.17487 / RFC8446、2018年8月、<https://www.rfc-editor.org/info/rfc8446>。

[UDP-OPT] Touch, J., "Transport Options for UDP", Work in Progress, Internet-Draft, draft-ietf-tsvwg-udp-options-08, 12 September 2019, <https://tools.ietf.org/html/draft-ietf-tsvwg-udp-options-08>.

[UDP-OPT] Touch、J。、「UDPのトランスポートオプション」、Work in Progress、Internet-Draft、draft-ietf-tsvwg-udp-options-08、2019年9月12日、<https：//tools.ietf。 org / html / draft-ietf-tsvwg-udp-options-08>。

Author's Address

著者のアドレス

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

マイケルウェルズル大学オスロ私書箱1080ブリンデンN-0316オスロノルウェー

   Phone: +47 22 85 24 20
   Email: michawe@ifi.uio.no