From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc9564.txt | 296 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 296 insertions(+) create mode 100644 doc/rfc/rfc9564.txt (limited to 'doc/rfc/rfc9564.txt') diff --git a/doc/rfc/rfc9564.txt b/doc/rfc/rfc9564.txt new file mode 100644 index 0000000..5d87d6e --- /dev/null +++ b/doc/rfc/rfc9564.txt @@ -0,0 +1,296 @@ + + + + +Independent Submission M. Blanchet +Request for Comments: 9564 Viagenie +Category: Informational 1 April 2024 +ISSN: 2070-1721 + + + Faster Than Light Speed Protocol (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. + +Status of This Memo + + 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. + + 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. + +Copyright Notice + + 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. + +Table of Contents + + 1. Introduction + 2. Protocol Peer Preparation + 3. FLIP Header + 4. Protocol Operation + 5. Versioning + 6. Future Work + 7. IANA Considerations + 8. Security Considerations + 9. Informative References + Acknowledgements + Author's Address + +1. Introduction + + 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). + + 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. + + 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]. + +2. Protocol Peer Preparation + + 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. + + 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. + +3. FLIP Header + + Wherever FLIP is used (below IP, above IP or other transport, or at + the application layer), a FLIP shim header is inserted. + + +----------+---------+----------------+----------------+ + | 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. + + +=========+===========+===========+ + | Command | Codepoint | Reference | + +=========+===========+===========+ + | model | 0x01 | RFC 9564 | + +---------+-----------+-----------+ + | data | 0x02 | RFC 9564 | + +---------+-----------+-----------+ + + Table 1 + + 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. + + 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. + +4. Protocol Operation + + 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. + + 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. + + 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. + +5. Versioning + + 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. + +6. Future Work + + 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. + +7. IANA Considerations + + For FLIP, codepoints could be registered in the following IANA + registries. + + * 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 + +8. Security Considerations + + 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. + + 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. + +9. Informative References + + [CHATGPT] Wikipedia, "ChatGPT", 20 March 2024, + . + + [IANA-PN] IANA, "Protocol Numbers", + . + + [IANA-SN] IANA, "Service Name and Transport Protocol Port Number + Registry", . + + [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", Work in Progress, Internet-Draft, + draft-many-deepspace-ip-assessment-01, 4 March 2024, + . + + [RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms + (SHA and SHA-based HMAC and HKDF)", RFC 6234, + DOI 10.17487/RFC6234, May 2011, + . + + [RFC6709] Carpenter, B., Aboba, B., Ed., and S. Cheshire, "Design + Considerations for Protocol Extensions", RFC 6709, + DOI 10.17487/RFC6709, September 2012, + . + +Acknowledgements + + 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. + +Author's Address + + Marc Blanchet + Viagenie + Email: marc.blanchet@viagenie.ca -- cgit v1.2.3