DiffServ RFC 2983 and DSCP Metadata Leakage in Encrypted VPN Tunnels

The Silent Side-Channel: How Quality of Service (QoS) Leaks User Privacy

When client applications generate IP traffic, modern operating systems classify network packets using the Differentiated Services Code Point (DSCP), an 8-bit field within the IPv4 Type of Service (ToS) or IPv6 Traffic Class header defined in RFC 2474. Interactive voice communications (VoIP) apply Expedited Forwarding (DSCP EF, binary 101110, decimal 46), high-definition video conferencing streams stamp Assured Forwarding classes (such as AF41, binary 100010, decimal 34), and real-time multiplayer gaming clients mark Low Latency values.

In an ideal zero-trust privacy model, encapsulating packets inside an encrypted tunnel (such as WireGuard, IPsec ESP, or OpenVPN) conceals user communication from eavesdropping entities. The cryptographic payload becomes completely indistinguishable from random white noise.

However, many default tunnel configurations commit an architectural flaw: they blindly copy the inner IP packet's ToS/DSCP byte into the outer IP encapsulation header.

When an eavesdropper, local Wi-Fi observer, or intermediary Internet Service Provider (ISP) inspects the outer packet headers of the encrypted VPN stream, they cannot decrypt the payload. Yet, because the outer DSCP bits mirror the inner markings, the observer gains immediate, high-fidelity classification of the encrypted communication:

• An ISP easily identifies the precise beginning, duration, and cadence of encrypted voice calls.
• Intermediate middleboxes distinguish background file downloads (DSCP CS1 / Best Effort 000000) from interactive terminal SSH sessions (DSCP CS2 / AF11).
• Deep packet inspection engines cross-reference packet sizes, inter-arrival bursts, and explicit DSCP tags to fingerprint application behavior with remarkable statistical confidence.

Vulnerable Tunnel (Uniform Model):
[ Inner Packet: VoIP (DSCP 46 / EF) ] ---> [ Encapsulation ] ---> [ Outer IP (DSCP 46 / EF) ]
                                                                             |
                                                                             v
                                                          ISP observes voice call timings!

Secure Tunnel (RFC 2983 Pipe Model):
[ Inner Packet: VoIP (DSCP 46 / EF) ] ---> [ Encapsulation ] ---> [ Outer IP (DSCP 0 / Best Effort) ]
                                                                             |
                                                                             v
                                                          ISP observes only uniform data stream

RFC 2983 DiffServ Tunnel Models: Uniform vs Pipe Architecture

To address how differentiated services interact with multi-layer encapsulations, the Internet Engineering Task Force published RFC 2983 ("Differentiated Services and Tunnels"). The specification formalizes three distinct tunneling paradigms:

1. The Uniform Model

In the Uniform Model, the network view is contiguous. When entering a tunnel:

• The outer header DSCP is populated directly from the inner header DSCP.
• Intermediate routers across the public Internet schedule and forward the tunnel packet according to this mirrored priority.
• Upon reaching the egress decapsulator, any DSCP modifications made by intermediate networks are copied back into the inner IP header before delivery.

While the Uniform Model preserves end-to-end QoS marking across cooperating transit domains, it is fatal to confidentiality. It treats the intermediate transport network as a trusted extension of the private domain, exposing internal application semantics to untrusted third parties.

2. The Pipe Model

In the Pipe Model, the tunnel is treated as a dedicated transport circuit with its own distinct QoS provisioning:

• Upon encapsulation, the ingress node assigns the outer header DSCP based strictly on the tunnel provider's transport policy, completely ignoring the inner packet's DSCP.
• The outer DSCP is typically fixed to Best Effort (0x00) or a negotiated bulk transport class.
• When intermediate routers manipulate the outer packet, their DSCP alterations affect only transit scheduling.
• Upon egress decapsulation, the outer header is discarded entirely. The inner packet retains its original DSCP value unaltered.

The Pipe Model establishes cryptographic and metadata isolation: intermediate observers see only a uniform, unvarying outer traffic class.

3. The Short-Pipe Model

The Short-Pipe Model functions identically to the Pipe Model across the transit network. The critical distinction occurs at the egress node: packet queuing on the decapsulator's outgoing interface uses the outer transport DSCP rather than the inner packet DSCP before forwarding the restored inner packet into the destination network.

The Danger of the Uniform Model in Commercial VPN Deployments

Commercial consumer VPNs and enterprise remote access gateways routinely encounter hostile transport networks. In these environments, deploying the Uniform Model introduces significant operational liabilities:

When intermediate networks inspect outer DSCP values, they can apply selective throttling or deprioritization to specific traffic profiles without needing to break the underlying cryptographic algorithms.

Decoupling ECN (RFC 6040) from DSCP (RFC 2474) Sanitization

A common configuration mistake when attempting to eliminate DSCP metadata leaks is zeroing the entire IP ToS byte. The 8-bit field is divided into two distinct logical components:

 0   1   2   3   4   5   6   7
+---+---+---+---+---+---+---+---+
|          DSCP         |  ECN  |
+---+---+---+---+---+---+---+---+
  DiffServ Code Point      Explicit Congestion
     (Bits 0 - 5)             (Bits 6 - 7)

1. DSCP (Bits 0-5): Governs packet priority classification. This must be masked (set to 000000) on the outer header to prevent metadata leakage.
2. ECN (Bits 6-7): Governs Explicit Congestion Notification (RFC 3168 and RFC 6040). These bits communicate early congestion warnings between routers and endpoints without dropping packets (00 = Non-ECT, 01 = ECT(1), 10 = ECT(0), 11 = CE - Congestion Experienced).

If a network administrator clears the entire byte (ToS = 0x00), they inadvertently erase ECN capabilities. Active Queue Management (AQM) algorithms (such as CoDel, FQ-CoDel, and CAKE) rely on ECN markings to signal buffers under pressure. Stripping ECN forces intermediate routers to drop packets instead of marking them, inducing latency spikes and throughput degradation.

RFC 6040 dictates precise rules for propagating ECN through IP tunnels:

• When encapsulating, outer ECN bits must reflect inner ECN capability.
• When decapsulating, if the outer header received a Congestion Experienced (11) mark, that mark must be merged into the inner header.

Therefore, an optimal VPN architecture masks DSCP (bits 0-5) while rigorously preserving and propagating ECN (bits 6-7).

Linux Kernel Implementation: XFRM, WireGuard, and Netfilter Mangle

1. Linux IP-XFRM (IPsec) Behavior

In Linux IPsec configurations managed via ip xfrm, the kernel state (struct xfrm_state) defaults to copying inner ToS to outer headers unless explicitly overridden. Administrators can inspect and configure XFRM states using iproute2:

# Check existing XFRM states
ip xfrm state show

# By default, IPsec tunnels may inherit the inner ToS field.
# Setting fixed outer ToS ensures RFC 2983 Pipe Model compliance:
ip xfrm state update src 203.0.113.10 dst 198.51.100.20 \
    proto esp spi 0x1000 reqid 1 mode tunnel \
    tos 0x00

2. WireGuard Kernel Implementation

In the native Linux WireGuard module (drivers/net/wireguard/), packet transmission handles outer UDP headers within send.c:

/* Simplified extract of WireGuard packet header assignment */
static void wg_send_packet(struct wg_device *wg, struct sk_buff *skb)
{
    ...
    /* WireGuard extracts ECN while setting outer DSCP */
    u8 ds = ip_tunnel_ecn_encap(0, ip_hdr(skb), skb);
    ...
}

WireGuard deliberately enforces a secure variant of the Pipe Model by default: the outer UDP packet uses a clean DSCP value of zero while combining the appropriate ECN bits. However, third-party userspace implementations or mobile client wrappers running on non-Linux platforms occasionally override this safety measure by inheriting host socket default flags.

Egress Normalization with eBPF and Nftables

To guarantee complete metadata isolation across all tunnel protocols, engineers can enforce egress normalization at the Linux packet filter layer.

1. Normalization via Nftables

The following nftables rule targets all outbound encapsulated VPN packets (e.g., WireGuard UDP on port 51820) and masks the upper 6 bits of the IPv4 ToS field while preserving the lower 2 bits (ECN):

table inet vpn_sanitizer {
    chain egress_filter {
        type filter hook postrouting priority mangle; policy accept;

        # Mask outer DSCP to 0, preserve bits 6-7 (ECN mask 0x03)
        udp dport 51820 ip dscp set cs0
        udp dport 51820 ip6 dscp set cs0
    }
}

2. Egress Normalization with eBPF (tc-bpf)

For high-throughput edge nodes processing multi-gigabit traffic, an eBPF program attached to the clsact egress hook modifies the packet headers directly in the kernel ring buffer with minimal CPU overhead:

#include <linux/bpf.h>
#include <linux/if_ether.h>
#include <linux/ip.h>
#include <bpf/bpf_helpers.h>

SEC("classifier/egress_dscp")
int sanitize_outer_dscp(struct __sk_buff *skb)
{
    void *data = (void *)(long)skb->data;
    void *data_end = (void *)(long)skb->data_end;
    struct ethhdr *eth = data;

    if ((void *)(eth + 1) > data_end)
        return BPF_OK;

    if (eth->h_proto == __constant_htons(ETH_P_IP)) {
        struct iphdr *iph = (void *)(eth + 1);
        if ((void *)(iph + 1) > data_end)
            return BPF_OK;

        /* Check if packet is UDP targeting VPN tunnel port */
        if (iph->protocol == IPPROTO_UDP) {
            /* Preserve ECN (mask 0x03) while zeroing DSCP (upper 6 bits) */
            __u8 old_tos = iph->tos;
            __u8 new_tos = old_tos & 0x03;

            if (old_tos != new_tos) {
                bpf_l3_csum_replace(skb, offsetof(struct iphdr, check),
                                    old_tos, new_tos, sizeof(new_tos));
                iph->tos = new_tos;
            }
        }
    }
    return BPF_OK;
}

char _license[] SEC("license") = "GPL";

How RiceGuard Enforces the Strict Pipe Model for Zero Metadata Leakage

VPNRice designs its network datapath around comprehensive metadata privacy. Through the RiceGuard protocol, client endpoints and transit gateways enforce strict RFC 2983 Pipe Model isolation:

[ Application Traffic ]
  - Video Conferencing: DSCP AF41 (0x22)
  - Gaming Datagrams:   DSCP CS2  (0x10)
  - Web Browsing:       DSCP CS0  (0x00)
             |
             v
[ RiceGuard Client Ingress Engine ]
  1. Records inner DSCP & ECN states in secure session memory.
  2. Encapsulates inner IP payload inside ChaCha20-Poly1305 ciphertext.
  3. Constructs outer IP/UDP header with DSCP forced to CS0 (0x00).
  4. Applies RFC 6040 ECN derivation to outer bits 6-7.
             |
             v
[ Public Transit Link / ISP ]
  - External appearance: Completely uniform, featureless UDP packet stream.
  - No side-channel classification possible for voice, video, or data.
             |
             v
[ RiceGuard Gateway Decapsulator ]
  1. Validates authentication tag and decrypts payload.
  2. Evaluates outer ECN congestion markers and merges with inner ECN.
  3. Restores original inner DSCP markings for destination network QoS.

1. Uniform Outer Surface: All encrypted packets traveling between client devices and VPNRice nodes present an identical CS0 traffic class. Observers cannot separate high-priority communication from background transfers.
2. Full ECN Integrity: By adhering to RFC 6040, RiceGuard retains low-latency queuing signals, allowing Active Queue Management algorithms to prevent bufferbloat without packet loss.
3. Deterministic Protection: Packet filters and kernel hooks prevent third-party applications from manipulating outer transport characteristics, maintaining consistent privacy guarantees across untrusted networks.

By eliminating QoS metadata leaks through rigorous implementation of RFC 2983, VPNRice protects user behavior patterns against advanced side-channel analysis.