Aether: A Next-Generation L4 Transport

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶

This Internet-Draft will expire on 28 January 2027.¶

Copyright Notice

Copyright (c) 2026 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. Wire Format

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ver |  Type   |H|E|R|         Stream ID                       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           Offset (32 bits)                     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           Length (32 bits)                     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|              Connection ID (32 bits, short header)             |
|         or Destination Connection ID (long header)             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

3. Handshake

Client                                  Server
  |                                       |
  |--- Initial (ClientHello) ------------>|
  |                                       |
  |<-- Initial (ServerHello) -------------|
  |                                       |
  |--- Handshake (ClientFinished) ------->|  Client can now send Data
  |                                       |
  |<-- Handshake (ServerFinished) --------|  Server can now send Data
  |                                       |
  |<======= Data (Encrypted) ===========>|

shared_secret = Kyber768.Decapsulate(kem_ciphertext)
                || X25519.DH(client_ephemeral, server_classical_pk)

transcript = ClientHello || ServerHello

session_key = HKDF-Expand(
    HKDF-Extract("AETHER-v0", shared_secret),
    transcript,
    256 bits
)

client_tx_key = HKDF-Expand(session_key, "client-tx", key_len)
server_tx_key = HKDF-Expand(session_key, "server-tx", key_len)

4. Streams

Each stream identified by 18-bit Stream ID (0..262143). Stream ID 0 reserved for control. Client opens streams with EVEN IDs; server with ODD IDs. Streams are independent: loss in one stream does not block others.¶

Stream lifecycle: IDLE -> (StreamOpen) -> OPEN -> (StreamClose FIN) -> HALF-CLOSED -> (StreamClose ACK) -> CLOSED.¶

Flow control operates at two levels: Connection-level (total in-flight data) and Stream-level (in-flight data per stream). Initial windows: Stream = 1 MiB, Connection = 16 MiB. Each Data packet carries an Offset (byte position). Receivers send Ack frames with received offset ranges. Unacknowledged packets are retransmitted with exponential back-off up to MAX_RETRANSMISSIONS (10).¶

5. Multi-Path

Connections are identified by Connection ID, not IP address. This enables path migration:¶

1. Client detects a new network interface (e.g., 5G after Wi-Fi).¶
2. Client sends PathChallenge from new IP to server.¶
3. Server responds with PathResponse, confirming the new path belongs to the same connection.¶
4. Server begins sending data on both paths.¶
5. Client may duplicate data on both paths for reliability.¶

Each path has a unique Path ID (Extension Type 0x04). Packets from different paths are multiplexed onto common streams; the receiver reassembles by Offset. When one path is lost, data automatically flows through remaining paths without connection interruption.¶

6. Congestion Control

The default congestion control algorithm is Aether-CC, a hybrid of BBRv3 [BBR] and NewReno [RFC6582], optimized for high-latency satellite links, variable-bandwidth mobile networks, and noisy channels (distinguishing loss from congestion).¶

Bandwidth estimation: delivery_rate = bytes_acked / time_delta; max_bw = max(max_bw, delivery_rate). RTT estimation: min_rtt = min(min_rtt, latest_rtt) over 10-second window. Congestion window: cwnd = max_bw * min_rtt * gain (gain: 1.25 during probing, 0.75 during drain).¶

Loss classification: loss with low RTT and rising delivery_rate indicates congestion; loss with high RTT and stable delivery_rate indicates channel noise (window not reduced). Pluggable algorithms: "aether-cc" (default), "bbrv3", "cubic", "none" (testing).¶

7. Security Considerations

Aether has no plaintext mode. All packets are encrypted: Initial packets with AEAD key derived from initial salt, Handshake packets with AEAD keys derived from shared_secret, Data packets with AEAD session_key.¶

The handshake uses Kyber-768 [FIPS203] as primary KEM with X25519 [RFC7748] as classical fallback, providing post-quantum resistance as long as at least one algorithm remains secure.¶

Metadata protection: Connection ID in short header is a 32-bit truncated value; Padding extension (0x03) allows random bytes for packet size obfuscation; Multipath data streams complicate passive traffic analysis.¶

Each connection generates ephemeral keys. Compromise of an identity key does not reveal past sessions (Perfect Forward Secrecy).¶

8. Identity Layer

Aether introduces cryptographic identity at the transport layer. Each node has an Ed25519 [RFC8032] key pair. Identity is: identity = SHA-256("AETHER-ID-" || Ed25519_public_key). During handshake, the node proves key ownership by signing the transcript.¶

Advantages: DNS/CA/PKI independent (self-sovereign identity), IP mobility (IP changes do not affect identity), decentralized (no central registry required), W3C DID compatible (identity representable as a DID).¶

9. Connection Close

Graceful close: Sender -> Close (NO_ERROR), Receiver -> Close (NO_ERROR). Keys destroyed after 3x PTO.¶

10. Discovery

Local discovery (LAN): Multicast group 224.0.0.251:9000 (IPv4), ff02::fb:9000 (IPv6). Periodic announcements every 30 seconds. Announcement format: Initial packet with type "Announce" in extensions.¶

Global discovery (WAN): Kademlia-based DHT (as in libp2p). DHT key = peer identity. DHT value = set of (IP, port, Connection ID) tuples. Enables peer location by identity without a centralized server.¶

11. Constants

12. Comparison with Existing Protocols

* HTTP-tied. ** Requires separate TLS/DTLS layer.¶

13. IANA Considerations

This document requires no IANA actions. Future revisions may request a well-known port assignment for port 9000.¶

14. Reference Implementation

A reference implementation of Aether Protocol v0.1 is available in the Rust programming language at https://github.com/nikaafo/aether-protocol.¶

Components:¶

• aether-core: Protocol library (framing, handshake, crypto, multipath, congestion control, identity, discovery).¶
• aether-sdk: Enterprise SDK (identity vault, monitoring, SLA).¶
• aether-gateway: L4 proxy for Aether-to-TCP bridging.¶
• demo: Example application.¶

License: MIT OR Apache-2.0.¶

Author's Address