summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc9564.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc9564.txt')
-rw-r--r--doc/rfc/rfc9564.txt296
1 files changed, 296 insertions, 0 deletions
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,
+ <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", Work in Progress, Internet-Draft,
+ draft-many-deepspace-ip-assessment-01, 4 March 2024,
+ <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, May 2011,
+ <https://www.rfc-editor.org/info/rfc6234>.
+
+ [RFC6709] Carpenter, B., Aboba, B., Ed., and S. Cheshire, "Design
+ Considerations for Protocol Extensions", RFC 6709,
+ DOI 10.17487/RFC6709, September 2012,
+ <https://www.rfc-editor.org/info/rfc6709>.
+
+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