A Negative Acknowledgement Mechanism for Signaling Compression
Extracted elements (23)
For unreliable transport, SigComp never retransmits on the application's behalf upon receiving a NACK; it relies on the application layer's existing retransmission mechanism. This avoids duplicate retransmission logic and keeps the SigComp shim minimal.
The existing SigComp mechanism for signaling state loss (setting state_memory_size to 0) is insufficient because it wipes an entire compartment when only one state is corrupt, and requires a message in the reverse direction that the remote application must authorize. A dedicated NACK mechanism allows fine-grained, per-state error recovery without requiring an application-level message in the reverse direction.
The NACK message reuses the existing SigComp message format (second variant with code_len=0) rather than defining a new message type, so that implementations lacking NACK support will safely discard NACK messages without error, preserving interoperability.
Implementations advertising NACK support (version 0x02) behave identically to version 0x01 implementations in all respects except for the NACK mechanism. Bytecodes sent to a 0x02 endpoint can check the version number and send appropriate feedback back to the compressor.
NACK messages are formatted as syntactically valid SigComp messages (second variant, code_len=0) so they are safely ignored by implementations that do not support the NACK mechanism, ensuring backward compatibility with SigComp version 0x01 nodes.
Any implementation that will send NACK messages upon decompression failure must indicate a SigComp version number of 0x02 in its UDVM, enabling peers to detect NACK support and optimize compression by optimistically referencing unacknowledged state.
For connectionless transport (e.g., UDP), the NACK message must be sent back to the originator at the port and IP address from which the failed message was sent, and must be sent from the IP address and port to which the uninterpretable message was directed.
SigComp implementations that use the NACK mechanism must calculate and store a SHA-1 hash for each SigComp message they send, stored in a way that allows the implementation to locate the compartment associated with that sent message given the hash.
When a NACK is received for a message sent over a reliable transport, the SigComp layer must indicate to the application that an error has occurred, analogous to a TCP connection reset.
When a received SigComp message causes a decompression failure, the recipient must form and send a SigComp NACK message containing the SHA-1 hash of the failed message, the reason code, and any applicable error details.
When an unreliable transport is used, the original failed message must not be retransmitted by the SigComp layer upon receipt of a NACK; instead the next application-initiated transmission will use the adjusted compressor state.
BYTECODES_TOO_LARGE (code 18): Uploaded bytecodes exceed the receiving UDVM's available memory; Error Details contains a 2-byte big-endian value of the receiver's DECOMPRESSION_MEMORY_SIZE.
CYCLES_EXHAUSTED (code 2): Decompression exceeded the allocated cycle budget; Error Details contains a 1-byte unsigned integer representing cycles-per-bit.
FRAMING_ERROR (code 25): An unquoted 0xFF 80..0xFF FE sequence was encountered in a stream transport input. Because a unique SHA-1 hash cannot be determined for framing errors, the 'SHA-1 Hash of failed message' field must be set to all zeros.
ID_NOT_UNIQUE (code 21) and STATE_TOO_SHORT (code 23) include the partial state identifier in Error Details (6-20 bytes). For STATE_TOO_SHORT, implementors must return only the partial state identifier that was requested, not any extended identifier, to prevent attackers from gaining unauthorized state access.
STATE_NOT_FOUND (code 1): A referenced state cannot be found; the Error Details field contains the state identifier (6-20 bytes). This is the most operationally significant error code, typically causing the NACK recipient to stop referencing the indicated state in future messages.
The 'PC of failed instruction' is a 2-byte field encoded in network (big-endian) byte order, containing the UDVM program counter value at the time of failure. If failure occurred before the UDVM began executing any code, this field is set to 0.
The 'SHA-1 Hash of failed message' field is a 20-byte SHA-1 computed over the entire SigComp message from the header byte (0b11111xxx) to end of input, excluding lower-level headers (UDP, IP) and stream delimiters (0xFFFF). For stream protocols, 0xFFxx escape sequences are un-escaped before hashing.
The 'version' field in the NACK message reuses the 'destination' field of the standard SigComp message format. This document defines version 1; implementations advertising NACK support set their UDVM version to 0x02.
This document registers a new value (0x02) in the IANA SigComp_version attribute registry, described as 'SigComp version 2 (NACK support)'.
Forged NACK messages can at worst cause the recipient to re-transmit state or use a less efficient compression scheme or send a message uncompressed; there are no catastrophic security consequences from NACK spoofing.
NACK messages can be triggered by intentionally sending malformed SigComp messages with a spoofed source IP, but since each malformed message produces at most one NACK of comparable size, there is no amplification attack vector.
A SigComp NACK message is formatted as the second variant of a SigComp message with code_len=0 and destination/version=1. It contains: 1-byte Reason Code, 1-byte OPCODE of failed instruction, 2-byte PC of failed instruction (big-endian), 20-byte SHA-1 hash of the failed message, and variable-length Error Details.