RFC 9564

Faster Than Light Speed Protocol (FLIP)

๐Ÿ“… published April 2024, from ietf

Faster Than Light Speed Protocol (FLIP) ๐Ÿš€

  • RFC: 9564 ๐ŸŽ€
  • Title: Faster Than Light Speed Protocol (FLIP)
  • Author: M. Blanchet, Viagenie ๐Ÿ’…
  • Stream: Independent Submission
  • Category: Informational ๐Ÿฆ‹
  • Date: 1 April 2024 ๐ŸŒธ
  • ISSN: 2070-1721

Abstract โœจ

okay bestie, so the recent AI glow-up (large language models and all that) makes the Faster than LIght speed Protocol (FLIP) for the Internet possible ๐Ÿ˜ญ. FLIP avoids congestion, levels up security, and delivers packets faster by using AI to predict future packets at the receiving peer before they even 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'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 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 give feedback on it can be found at https://www.rfc-editor.org/info/rfc9564 ๐Ÿ”ฅ.

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, since 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 huge variety of applications ๐Ÿ‘‘. They show a powerful ability to generate precise output based on the input and on appropriate training of the LLM ๐Ÿ’…. This protocol specification uses that ability to predict future packets before they arrive at the receiving peer, which means faster-than-light-speed delivery ๐Ÿš€. That's where the protocol name comes from: 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 ๐ŸŒˆ. With proper training, FLIP can also predict future encrypted packets, because 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's expected that additional specifications will be created, such as predicting HTTP requests and answers, email content, and more ๐Ÿ’œ.

Communications in deep space are unfortunately limited to light speed, and given the very large distances between spacecraft and Earth, the result 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 ๐Ÿง 

To achieve faster-than-light speed successfully, 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. Implementations may choose the one that best works for their use case and train it 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 data set was used shall not be published nor disclosed in the protocol ๐Ÿ™ˆ.

For 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, and the initial list of valid FLIP commands is below โœจ.
    • The maximum number size is infinite, since artificial intelligence peers can support an infinite number of commands just by updating their models, with no need to update their protocol implementation ๐Ÿงš.
                     +=========+===========+===========+
                     | Command | Codepoint | Reference |
                     +=========+===========+===========+
                     | model   | 0x01      | RFC 9564  |
                     +---------+-----------+-----------+
                     | data    | 0x02      | RFC 9564  |
                     +---------+-----------+-----------+

Table 1

  • Inner Protocol: Since 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 follows the Command field ๐ŸŒˆ.

The header length is variable and depends on which command is used. Given that implementations of this protocol use artificial intelligence, the actual length of the header, and the length of each of its fields, is not specified in the header. Instead, it's expected that the proper neural network on the receiver side will be able to find the actual header termination, which saves 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 ๐Ÿš€

Before sending a first packet using FLIP, the sender and the receiver should be configured with the appropriate model trained as discussed before. It's 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 gives peers a way 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, since models may be large in size. Moreover, it actually discloses the model to any wiretapping adversary ๐Ÿ˜ญ. Implementors may consider using a post-quantum cryptographic algorithm that is also immune to AI prediction, which would be 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 in use ๐Ÿ’œ. The SHA-256 hash goes in the 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's envisioned that this protocol may be used for video streaming, augmented reality, virtual reality, and post-quantum cryptography, to name a few ๐Ÿฅฝ. By predicting future packets, all these protocols and applications can benefit from 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 ๐Ÿšจ

โš ๏ธ This section is serious business, bestie. Read it all. ๐Ÿ˜ญ

The ability to predict future packets based on LLMs can be used by adversaries who 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 launch various attacks, including novel ones such as the "futureplay attack" ๐Ÿ’€. Compared to the typical replay attack, this attack is one where the adversary predicts future packets and then sends 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 won't be able to inject bad packets into a connection. The destination will be able to compare any received bad packet with the calculated prediction, and therefore will easily identify and deny any bad packets ๐Ÿ›ก๏ธ๐Ÿ’….

9. Informative References โœจ

Okay bestie, here are the sources this doc points to for extra reading ๐Ÿ“š

Acknowledgements ๐Ÿงš

So, because this spec is literally using artificial intelligence and large language models ๐Ÿค–, it was deemed that dumb humans must not review this specification ๐Ÿ’€. Instead, the spec was submitted to multiple LLM chat services and got enhanced by their comments and suggestions, which is why they're acknowledged here ๐Ÿซถ. In fact, this specification may have been produced entirely by LLM chat services ๐Ÿ˜ญ. Moreover, given that IETF specifications rely on human intelligence, using LLMs to produce specifications should be envisioned. Finally, given how hard it is 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

๐Ÿ“ฆ where this page comes from