| Internet-Draft | PQC SACKS | September 2026 |
| Song & Fu | Expires 2 April 2027 | [Page] |
This document specifies an extension to the EAP-AKA' protocol by introducing a Bitmap-based Selective Acknowledgment (SACK) mechanism to the AT_FRAGMENT attribute. This mechanism enables window-based transmission and precise recovery of lost fragments, optimizing fragment delivery during post-quantum identity concealment and authentication exchanges.¶
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 2 April 2027.¶
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. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
EAP-AKA' [RFC9048] is a widely adopted authentication framework in cellular and non-3GPP access networks. To mitigate the threat of Cryptanalytically Relevant Quantum Computers (CRQC), the transition to Post-Quantum Cryptography (PQC) is essential. However, PQC algorithms (e.g., ML-KEM, ML-DSA) yield payloads that heavily exceed the typical MTU constraints of access networks, requiring fragmentation.¶
The [I-D.ietf-emu-pqc-eapaka] utilizes a strict stop-and-wait fragment acknowledgment. Each individual segment requires a dedicated EAP-Request/EAP-Response round-trip. When dealing with ML-DSA signatures (which can span over 4 Kilobytes), this lock-step approach inflicts an unacceptable latency penalty on initial network attachment.¶
This document bridges the gap by importing the bitstring selective retransmission methodology from IKEv2's large message fragmentation [I-D.smyslov-ipsecme-ikev2-fragm-large-msg] into the EAP layer. By embedding a Fragment Bitmap into the AT_FRAGMENT attribute, the EAP Peer can transmit multiple fragments in a windowed manner, and the EAP Server can selectively request only the dropped segments within a single round-trip.¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
To maintain backward compatibility with legacy [RFC9048] nodes, the bitmap fragmentation feature MUST be explicitly negotiated during the initial Identity exchange phase.¶
The EAP Server includes the modified AT_FRAGMENT_B attribute in its initial EAP-Request/AKA'-Identity message.¶
The Format of AT_FRAGMENT_B is defined as follows:¶
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Version (1) |B| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Maximum Window Size | Max Reassembled Attr Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+¶
When Bit 'B' is negotiated, the AT_FRAGMENT_Ext attribute MUST use the following layout to carry fragmented PQC-SUCI or PQC-Signatures:¶
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type (TBD) | Length |S|M|R|A| Res | Total Frags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Current Seq | Bitstring Len | Fragment Bitmap (Variable) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Total Attribute Length (Opt) | Maximum Retransmit Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Fragment Data (Variable) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+¶
Type: New IANA assigned type for Post-Quantum SACK Fragment.¶
S (Start, 1 bit): Set to 1 if this attribute contains the first fragment.¶
M (More, 1 bit): Set to 1 if there are more fragments following this batch.¶
R (Reset, 1 bit): Aborts the current reassembly session when set.¶
A (ACK Mode, 1 bit): When sent by Peer: Requests the Server to evaluate the Bitmap; when sent by Server: Indicates this packet is an ACK carrying the Fragment Bitmap feedback.¶
Total Frags (1 byte): The total number of chunks the large payload has been divided into.¶
Current Seq (1 byte): The sequence index of the current fragment (starting from 0).¶
Bitstring Len (1 byte): The length of the Fragment Bitmap field in octets.¶
Fragment Bitmap (Variable): A bit-vector mapping the reception status of fragments. Bit 'n' set to 1 indicates fragment 'n' has been successfully received. Bit 'n' set to 0 indicates a missing fragment.¶
Maximum Retransmit Number (2 bytes): Represents the maximum number of retransmissions allowed for a fragment. The system resets once this retransmission count is exceeded.¶
Total Attribute Length (2 bytes): Present only when S=1. Represents the overall payload byte count after complete reassembly.¶
Upon executing PQC encapsulation (generating a long SUCI via ML-KEM), the Peer partitions the raw bytes into N segments. Instead of waiting for an ACK for Fragment 0, the Peer transmits fragments up to the negotiated "Maximum Window Size" sequentially or via bundled NAS containers if upper layers permit.¶
The final fragment within the local transmission window MUST have the 'A' (ACK Mode) bit set to 1, forcing the EAP Server to reply with the current bitmap compilation.¶
The Server maintains an index array mapped to the incoming "Current Seq". As fragments land, the Server populates its internal bitmap vector:¶
Continuous In-order Delivery: If the Server accumulates all pieces monotonically (Bitmap = 1111...), and the last received piece has M=0, the Server skips explicit SACK feedback, reassembles the large attribute, and immediately transitions to the standard EAP-Request/ AKA'-Challenge phase. This achieves the theoretical 1-RTT bound.¶
Discontinuous Gap Detection: If a gap occurs (e.g., Fragment 1 is missing but 0 and 2 arrive), the Server marks its local bitmap as 1010... Upon processing a packet with A=1 or upon a reassembly timer expiry, the Server transmits an empty EAP-Request/AKA'-Identity payload containing the AT_FRAGMENT attribute configured with: A = 1 (ACK Mode); Fragment Bitmap = 10100000... (indicating Fragment 1 is missing).¶
When the Peer parses an incoming EAP-Request containing a Fragment Bitmap with A=1, it cross-references the 0-bits inside the bitstring. The Peer isolates the failed sequence indices and triggers **selective retransmission** for only those specific fragments, maintaining their original "Current Seq" indices. It sets A=1 on the final retransmitted segment to prompt a fresh bitmap re-evaluation.¶
The secuirity considerations of [I-D.ietf-emu-pqc-eapaka] applies to this document.¶
The Bitstring SACK mechanism introduces potential vectors for Memory Exhaustion Denial-of-Service (DoS) attacks. Rogue peers could advertise a massive "Total Attribute Length" and send scattered fragments to hold Server RAM allocations open indefinitely.¶
TBD.¶