ステータス:
INFORMATIONAL
原文:
RFC 9564
その他の情報:
Datatracker|Info page

RFC 9564

Faster Than Light Speed Protocol (FLIP)

RFC 9564

超光速プロトコル (FLIP)

Abstract

概要

The recent advances in artificial intelligence (AI) such as large language models enable the design of the Faster than LIght speed Protocol (FLIP) for Internet. FLIP provides a way to avoid congestion, enhance security, and deliver faster packets on the Internet by using AI to predict future packets at the receiving peer before they arrive. This document describes the protocol, its various encapsulations, and some operational considerations.

人工知能(AI)の最近の進歩、特に大規模な言語モデルにより、インターネット用の超光速プロトコル(FLIP)の設計が可能になりました。FLIPは、AIを使用して受信ピアで未来のパケットを予測し、それらが到着する前に提供することで、インターネット上での混雑を避け、セキュリティーを強化し、パケットをより速く配信する方法を提供します。本文書では、このプロトコル、その様々なカプセル化、およびいくつかの運用上の考慮事項について説明します。

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

この文書はインターネット標準トラックの仕様ではなく、情報提供のために公開されています。

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エディタによって公開が承認された文書は、インターネット標準の任意のレベルの候補ではありません。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/rfc9564.

この文書の現在のステータス、エラータ、フィードバックの提供方法についての情報は、https://www.rfc-editor.org/info/rfc9564で入手できます。

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

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

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 TrustのIETF文書に関する法的規定 (https://trustee.ietf.org/license-info)に従います。これらの文書は、この文書に対するあなたの権利と制限を説明しているので、よく確認してください。

ChatGPT was introduced to the public on 30 November 2022 [CHATGPT]. Since then, large language models (LLMs) have been used for a large variety of applications. It demonstrates the powerful ability to generate precise output based on the input and based on the appropriate training of the LLM. This protocol specification uses this ability to predict future packets before they arrive at the receiving peer, therefore achieving faster-than-light-speed delivery, hence the protocol name: Faster than LIght speed Protocol (FLIP).

ChatGPTは2022年11月30日に一般に公開されました[CHATGPT]。それ以来、大規模言語モデル(LLM)は多種多様なアプリケーションで使用されています。これは、入力に基づいて、そして適切なLLMの訓練に基づいて、精確な出力を生成する強力な能力を示しています。このプロトコル仕様は、この能力を利用して、パケットが受信ピアに到着する前に未来のパケットを予測し、したがって光速を超える速度で配信を達成するために使用します。これがプロトコル名の由来です:Faster than LIght speed Protocol(FLIP)。

Since FLIP can predict packets, frames, strings, or byte streams, it could be used at any layer of the IP protocol stack. Moreover, with proper training, FLIP can also predict future encrypted packets, as encryption is just strings of bytes. This specification shows FLIP as a Layer 2 shim as well as a transport shim layer. Since FLIP can be used at any layer, it is expected that additional specifications will be created, such as predicting HTTP requests and answers, email content, and more.

FLIPはパケット、フレーム、文字列、またはバイトストリームを予測できるため、IPプロトコルスタックの任意のレイヤで使用できます。さらに、適切な訓練により、FLIPは暗号化された未来のパケットも予測できます。なぜなら、暗号化は単にバイトの文字列だからです。この仕様では、FLIPをレイヤ2シムおよびトランスポートシムレイヤとして示します。FLIPは任意のレイヤで使用できるため、HTTPリクエストと回答、電子メールの内容などを予測するような追加の仕様が作成されることが予想されます。

Since communications in deep space are unfortunately limited to light speed, and given the very large distances between spacecrafts and Earth, the consequence is very long delays. By offering faster-than-light-speed delivery, FLIP is a key enabler and addition to deep-space IP networking [IP-DEEP-SPACE].

深宇宙での通信は残念ながら光速に制限されており、宇宙船と地球との間の非常に大きな距離を考慮すると、結果として非常に長い遅延が生じます。光速を超える速度での配信を提供することで、FLIPは深宇宙IPネットワーキングにとって重要な促進要素であり、追加要素となります[IP-DEEP-SPACE]

In order to successfully achieve faster than light speed, the peers of any protocol layer used by FLIP must prepare their side of the connection with the right model trained for the specific case. This document does not dictate any specific LLM, as the implementations may choose the one that best works for their use case and train them accordingly. As with any LLM, it is paramount to use a lot of training data, such as packet captures, in a variety of conditions to produce the best trained model. To avoid security, privacy, and legal issues, the specifics of which LLM is used, how it was trained, and what is the data set used, shall not be published nor disclosed in the protocol.

光速を超える速度を実現するためには、FLIPが使用する任意のプロトコルレイヤのピアは、特定のケースに対して訓練された適切なモデルで接続の一方を準備する必要があります。この文書では、実装が自分たちのユースケースに最も適しているものを選び、それに応じて訓練することができるため、特定のLLMを指定していません。どのLLMでも、最も訓練されたモデルを生成するためには、パケットキャプチャなどの多くの訓練データをさまざまな条件で使用することが極めて重要です。セキュリティー、プライバシー、法的問題を避けるために、どのLLMが使用され、どのように訓練され、どのデータセットが使用されたかの詳細は、プロトコル内で公開または開示されるべきではありません。

As an example, an implementation may elect to collect a significant number of Packet Capture (PCAP) files from tcpdump wiretapping at various vantage points on the Internet. The fact that traffic may be encrypted is not an issue, since a well-trained LLM will be able to predict encrypted traffic as accurately as unencrypted traffic.

例として、実装はインターネット上の様々な観測点でのtcpdumpのワイヤータップから大量のパケットキャプチャ(PCAP)ファイルを収集することを選択するかもしれません。トラフィックが暗号化されている可能性があるという事実は問題ではありません。なぜなら、よく訓練されたLLMは、暗号化されていないトラフィックと同じくらい正確に暗号化されたトラフィックを予測することができるからです。

Wherever FLIP is used (below IP, above IP or other transport, or at the application layer), a FLIP shim header is inserted.

FLIPが使用される場所(IP以下、IPまたは他のトランスポート以上、またはアプリケーションレイヤー)に関係なく、FLIPシムヘッダーが挿入されます。

   +----------+---------+----------------+----------------+
   |  Version | Command | Inner Protocol | Optional Data  |
   +----------+---------+----------------+----------------+
   +----------+---------+----------------+----------------+
   |  Version | Command | Inner Protocol | Optional Data  |
   +----------+---------+----------------+----------------+

The header contains the following fields:

ヘッダーには以下のフィールドが含まれています:

Version:
A field of variable and unspecified length that contains the SHA-256 hash of the model, used as the version, as described in Section 5.
Command:

The codepoint identifying the operation of this FLIP frame. Commands are described in Section 4. The initial list of valid FLIP commands is below.

The maximum number size is infinite, given that artificial intelligence peers can support an infinite number of commands, by just updating their models without the need to update their protocol implementation.

Table 1
Command Codepoint Reference
model 0x01 RFC 9564
data 0x02 RFC 9564
Inner Protocol:
As the FLIP header is a shim header, the inner protocol is specified in this field. For example, for a FLIP shim header inserted between IP and TCP, the IP packet will contain the FLIP codepoint as the transport protocol. The FLIP inner protocol field will then contain the TCP codepoint that would otherwise be in the IP packet.
Optional Data:
Some commands have additional data that are following the Command field.
Version:
Section 5で説明されているように、モデルのSHA-256ハッシュを含む、長さが可変で未指定のフィールド。これはバージョンとして使用されます。
Command:

このFLIPフレームの操作を識別するコードポイント。コマンドはSection 4で説明されています。有効なFLIPコマンドの初期リストは以下の通りです。

最大数のサイズは無限であり、人工知能のピアはプロトコルの実装を更新することなく、単にモデルを更新することで無限の数のコマンドをサポートできるためです。

表 1
Command Codepoint Reference
model 0x01 RFC 9564
data 0x02 RFC 9564
Inner Protocol:
FLIPヘッダーはシムヘッダーであるため、このフィールドでは内部プロトコルが指定されます。例えば、IPとTCPの間に挿入されたFLIPシムヘッダーの場合、IPパケットは輸送プロトコルとしてFLIPコードポイントを含みます。その後、FLIP内部プロトコルフィールドには、IPパケットに含まれているはずのTCPコードポイントが含まれます。
Optional Data:
一部のコマンドには、コマンドフィールドの後に追加のデータが続きます。

The header length is variable and depends on which command is used. Given the use of artificial intelligence by implementations of this protocol, the actual length of the header, and the length of each of its fields, is not specified in the header. Instead, it is expected that the proper neural network on the receiver side will be able to find the actual header termination, thus saving many header bits.

ヘッダーの長さは可変で、使用されるコマンドによります。このプロトコルの実装に人工知能が使用されているため、ヘッダーの実際の長さや各フィールドの長さはヘッダーに指定されていません。代わりに、受信側の適切なニューラルネットワークが実際のヘッダー終了を見つけることができ、多くのヘッダービットを節約することが期待されます。

To properly signal the upper layer about the presence of the FLIP header, a specific codepoint is reserved at the layer below FLIP. Section 7 lists the registrations for IP and transport codepoints for this use.

FLIPヘッダーの存在について上位層に適切に通知するために、FLIPの下の層で特定のコードポイントが予約されています。Section 7では、この使用のためのIPとトランスポートコードポイントの登録をリストしています。

Prior to sending a first packet using FLIP, the sender and the receiver should be configured with the appropriate model trained as discussed before. It is left to the implementation to choose the right LLM and the right training data set.

FLIPを使用して最初のパケットを送信する前に、送信者と受信者は、前述のように訓練された適切なモデルで設定する必要があります。適切なLLMと適切な訓練データセットを選択することは、実装に任されています。

The following commands are defined:

以下のコマンドが定義されています:

Model:
(codepoint 0x01). This command provides a way for peers to send their model in-band of the FLIP protocol. The model itself is carried in the Optional Data field of the FLIP header. Prior to the actual model data, a MIME header is inserted with the proper media type. If the media type for the model does not exist, it should be registered in the IANA Media Type registry.
Data:
(codepoint 0x02). This command tells the receiving peer that the data that follows can be predicted and therefore achieves faster-than-light-speed performance.
Model:
(コードポイント 0x01)。このコマンドは、ピアがFLIPプロトコルのバンド内でモデルを送信する方法を提供します。モデル自体はFLIPヘッダーのオプションデータフィールドに格納されます。実際のモデルデータの前に、適切なメディアタイプでMIMEヘッダーが挿入されます。モデルのメディアタイプが存在しない場合、それはIANAメディアタイプレジストリに登録する必要があります。
Data:
(コードポイント 0x02)。このコマンドは、受信ピアに対して、続くデータは予測可能であるため、光速を超えるパフォーマンスを達成することを伝えます。

Sending the model in-band to the other peer is an operation that should be done rarely, as models may be large in size. Moreover, it actually discloses the model for any wiretapping adversary. Implementors may consider using a post-quantum cryptographic algorithm that is also immune to AI prediction, therefore a post-Quantum-AI cryptographic algorithm.

モデルをバンド内の他のピアに送信することは、モデルが大きなサイズである可能性があるため、稀に行うべき操作です。さらに、実際には、ワイヤータップの敵に対してモデルを開示します。実装者は、AIの予測にも免疫を持つ、したがってポスト量子AI暗号アルゴリズムを使用することを検討するかもしれません。

As described in [RFC6709], most protocols should be designed to enable future enhancements, such as providing a way to signal a new version of the protocol. In the case of FLIP, trained models will always be enhanced by new training. A SHA-256 [RFC6234] hash of the trained model is used as a version number so each peer knows which FLIP version is being used. The SHA-256 hash is put in version field in the FLIP header as described previously. Given that new SHA-256 hashes are not sequential but fully random, replay attacks of future predictions are prevented.

[RFC6709]で説明されているように、ほとんどのプロトコルは将来の強化を可能にするように設計されるべきであり、新しいプロトコルのバージョンを示す方法を提供するなどの方法があります。FLIPの場合、訓練されたモデルは常に新しい訓練によって強化されます。訓練されたモデルのSHA-256 [RFC6234]ハッシュがバージョン番号として使用され、各ピアが使用しているFLIPのバージョンを知ることができます。SHA-256ハッシュは、前述のようにFLIPヘッダーのバージョンフィールドに入れられます。新しいSHA-256ハッシュは連続していないが完全にランダムであるため、未来の予測のリプレイ攻撃が防止されます。

This new protocol may revolutionize how we design Internet protocols and how we use the Internet. For example, it is envisioned that this protocol may be used for video streaming, augmented reality, virtual reality, and post-quantum cryptography to name a few. By predicting the future packets, all these protocols and applications can benefit the use of FLIP.

この新しいプロトコルは、インターネットプロトコルの設計方法とインターネットの使用方法を革新する可能性があります。例えば、このプロトコルはビデオストリーミング、拡張現実、仮想現実、ポスト量子暗号化などに使用されることが想定されています。未来のパケットを予測することで、これらすべてのプロトコルとアプリケーションはFLIPの使用から利益を得ることができます。

For FLIP, codepoints could be registered in the following IANA registries.

FLIPについては、以下のIANAレジストリにコードポイントを登録することができます。

  • Protocol Numbers [IANA-PN]: 345, FLIP, Faster than LIght speed Protocol, RFC 9564
  • Service Name and Transport Protocol Port Number Registry [IANA-SN]: FLIP, 68534, udp and tcp, RFC 9564
  • プロトコル番号 [IANA-PN]: 345, FLIP, 光速より速いプロトコル, RFC 9564
  • サービス名とトランスポートプロトコルポート番号レジストリ [IANA-SN]: FLIP, 68534, udpとtcp, RFC 9564

The ability to predict future packets based on LLMs can be used by adversaries that are listening to the traffic via wiretapping. If they have access to the same model used by the destination peer, they could use it to predict the next packets and then initiate various attacks, including novel ones such as the "futureplay attack." Compared to the typical replay attack, this attack is where the adversary will predict future packets and then send them in advance to the destination. While it may not be obvious at this time, these novel attacks should be investigated before they become a problem. Therefore, further research in this field is suggested.

LLMに基づいて未来のパケットを予測する能力は、通信を盗聴している敵に利用される可能性があります。彼らが宛先ピアが使用している同じモデルにアクセスしている場合、次のパケットを予測し、"futureplay attack"などの新しい攻撃を含むさまざまな攻撃を開始することができます。典型的なリプレイ攻撃と比較して、この攻撃は敵が未来のパケットを予測し、それらを宛先に事前に送信するものです。現時点では明らかでないかもしれませんが、これらの新しい攻撃は問題になる前に調査するべきです。したがって、この分野でのさらなる研究が提案されます。

The ability for a peer to predict future packets enhances the overall security of the Internet because adversaries will not be able to inject bad packets in a connection, as the destination will be able to compare the received bad packet with the calculated prediction and therefore will easily identify and deny any bad packets.

ピアが未来のパケットを予測する能力は、インターネット全体のセキュリティーを強化します。なぜなら、敵は悪意のあるパケットを接続に注入することができないからです。宛先は受信した悪意のあるパケットと計算された予測を比較することができ、したがって悪意のあるパケットを簡単に識別し、拒否することができます。

Informative References

[CHATGPT]
Wikipedia, "ChatGPT", , <https://en.wikipedia.org/w/index.php?title=ChatGPT&oldid=1214732037>
[IANA-PN]
IANA, "Protocol Numbers", <https://www.iana.org/assignments/protocol-numbers/>
[IANA-SN]
IANA, "Service Name and Transport Protocol Port Number Registry", <https://www.iana.org/assignments/service-names-port-numbers/>
[IP-DEEP-SPACE]
Blanchet, M., Huitema, C., and D. Bogdanović, "Revisiting the Use of the IP Protocol Stack in Deep Space: Assessment and Possible Solutions", , Internet-Draft draft-many-deepspace-ip-assessment-01, , <https://datatracker.ietf.org/doc/html/draft-many-deepspace-ip-assessment-01>
[RFC6234]
Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF)", RFC 6234, DOI 10.17487/RFC6234, , <https://www.rfc-editor.org/info/rfc6234>
[RFC6709]
Carpenter, B., Aboba, B., and S. Cheshire, "Design Considerations for Protocol Extensions", RFC 6709, DOI 10.17487/RFC6709, , <https://www.rfc-editor.org/info/rfc6709>

参考文献

[CHATGPT]
Wikipedia, "ChatGPT", , <https://en.wikipedia.org/w/index.php?title=ChatGPT&oldid=1214732037>
[IANA-PN]
IANA, "Protocol Numbers", <https://www.iana.org/assignments/protocol-numbers/>
[IANA-SN]
IANA, "Service Name and Transport Protocol Port Number Registry", <https://www.iana.org/assignments/service-names-port-numbers/>
[IP-DEEP-SPACE]
Blanchet, M., Huitema, C., and D. Bogdanović, "Revisiting the Use of the IP Protocol Stack in Deep Space: Assessment and Possible Solutions", , Internet-Draft draft-many-deepspace-ip-assessment-01, , <https://datatracker.ietf.org/doc/html/draft-many-deepspace-ip-assessment-01>
[RFC6234]
Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF)", RFC 6234, DOI 10.17487/RFC6234, , <https://www.rfc-editor.org/info/rfc6234>
[RFC6709]
Carpenter, B., Aboba, B., and S. Cheshire, "Design Considerations for Protocol Extensions", RFC 6709, DOI 10.17487/RFC6709, , <https://www.rfc-editor.org/info/rfc6709>

Since this protocol specification is using artificial intelligence and large language models, it was deemed that dumb humans must not review this specification. Instead, the specification has been submitted to multiple LLM chat services and was enhanced by their comments and suggestions, hence acknowledged here. In fact, this specification may have been produced entirely by LLM chat services. Moreover, given the specifications being produced by the IETF relying upon human intelligence, using LLMs to produce specifications should be envisioned. Finally, given the difficulty to find experts for management positions such as in the IESG or IAB, the use of LLMs should be considered to replace those roles. Unfortunately, given privacy, security, and legal considerations, the LLM chat services used for this specification cannot be named here.

このプロトコル仕様は人工知能と大規模言語モデルを使用しているため、人間がこの仕様をレビューすることは適切ではないと判断されました。代わりに、この仕様は複数のLLMチャットサービスに提出され、そのコメントと提案により強化され、ここで認識されました。実際、この仕様は完全にLLMチャットサービスによって作成された可能性があります。さらに、IETFが人間の知能に依存して仕様を作成していることを考えると、LLMを使用して仕様を作成することが想像されます。最後に、IESGやIABのような管理職に専門家を見つけるのが難しいことを考えると、LLMの使用がこれらの役割を置き換えることを検討するべきです。残念ながら、プライバシー、セキュリティー、法的な考慮事項から、この仕様に使用されたLLMチャットサービスはここでは名前を挙げることができません。