DISPATCH G. Scalone Internet-Draft Vodafone Intended status: Informational 2 March 2026 Expires: 3 September 2026 Customer-Facing Relay (CFR): Enhancing Source Privacy in Encrypted Transport and CDN Scenarios draft-scalone-cfr-source-privacy-01 Abstract Encrypted Client Hello (ECH) improves destination privacy by encrypting the Server Name Indication in TLS, but the customer source identity-- typically the IP address and network metadata--remains observable to intermediaries such as CDNs, hosting providers, and recursive resolvers. This document introduces the _Customer-Facing Relay (CFR)_, a lightweight, transport-agnostic relay operated by access providers to decouple customer identity from encrypted destinations. By forwarding opaque encrypted payloads (TCP or UDP) without terminating TLS or QUIC, a CFR complements ECH encryption to strengthen source privacy and reduce metadata correlation. 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 3 September 2026. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. Scalone Expires 3 September 2026 [Page 1] Internet-Draft CFR Source Privacy March 2026 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. Customer-Facing Relay (CFR) Concept . . . . . . . . . . . . . 3 4.1. Characteristics . . . . . . . . . . . . . . . . . . . . . 4 4.2. Privacy Model . . . . . . . . . . . . . . . . . . . . . . 4 4.3. Deployment Models . . . . . . . . . . . . . . . . . . . . 4 5. Relationship to Existing Work . . . . . . . . . . . . . . . . 4 6. Design Considerations and Open Questions . . . . . . . . . . 5 6.1. Discovery and Bootstrapping . . . . . . . . . . . . . . . 5 6.2. Performance and Scalability . . . . . . . . . . . . . . . 5 7. Abuse Prevention . . . . . . . . . . . . . . . . . . . . . . 5 8. Interoperability . . . . . . . . . . . . . . . . . . . . . . 5 9. IETF Standardization . . . . . . . . . . . . . . . . . . . . 5 10. Security Considerations . . . . . . . . . . . . . . . . . . . 5 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 12.1. Informative References . . . . . . . . . . . . . . . . . 6 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6 1. Introduction While recent advances such as TLS 1.3 and ECH significantly improve destination privacy, they do not prevent intermediaries from observing the customer source identity. As content delivery infrastructures concentrate traffic, a small number of entities gain disproportionate visibility over user metadata. The Customer-Facing Relay (CFR) architecture introduces a minimalistic relay positioned at the customers network edge to limit correlation. The CFR rewrites addressing metadata while forwarding encrypted traffic without termination, creating two semi-independent visibility domains: one for the access network (source) and one for the CDN or upstream service (destination). The result is improved source privacy and reduced metadata consolidation. Scalone Expires 3 September 2026 [Page 2] Internet-Draft CFR Source Privacy March 2026 This document refines the CFR concept introduced in draft-00, elaborates the privacy model, and outlines potential discovery, deployment, and operational considerations. 2. Terminology *CFR*: _Customer-Facing Relay_, A privacy-enhancing network function positioned at or near the access network. It rewrites source addresses while forwarding encrypted traffic without terminating TLS/ QUIC. *CFS*: _Client-Facing Server_ As defined in ECH (RFC 9460), the endpoint that terminates encrypted handshakes on behalf of origins. A CFR does not act as a CFS. *Upstream Service*: _Upstream Service_ A CDN, hosting provider, or service endpoint that ultimately receives the relayed encrypted traffic. *Opaque Payload*: _Opaque Payload_ Encrypted packets (TLS-over-TCP or QUIC-over-UDP) forwarded without modification. 3. Motivation CDNs and major hosting platforms increasingly act as aggregation points for encrypted traffic. Even with ECH, these entities can link the customer source IP address to thousands of origins they serve. This centralization poses privacy and competition risks: * Correlation risk: Access patterns across different encrypted services can be tied to a single user. * Lack of architectural balance: Encryption protects destinations, but source privacy remains under-addressed. * Cross-service tracking: Consolidated metadata enables pervasive behavioral observation. CFRs seek to break the direct correlation between the customer and the encrypted destination by splitting visibility: * Customer -> CFR -> CDN -> Origin 4. Customer-Facing Relay (CFR) Concept A CFR is a deployable, narrow-function relay implemented by access networks, enterprises, or other operators. Its core behaviors include: Scalone Expires 3 September 2026 [Page 3] Internet-Draft CFR Source Privacy March 2026 4.1. Characteristics * *Transport-agnostic* - Works for both TCP and UDP encrypted traffic, forwarding opaque encrypted packets. * *No TLS/QUIC termination* - Does not terminate or inspect TLS/ QUIC; preserves end-to-end encryption. * *Deployable* - Can be operated by access providers and enterprises. * *Transparent* - Performs no content filtering, categorization, or inspection. * *Discoverable* - May be discovered via DNS-based mechanisms such as DDR or DNR. * *Lightweight operation* - Functions similarly to NAT, NAPT, or tunnel encapsulation, but for privacy purposes. * *Policy-minimal* - Not intended for filtering, shaping, categorization, or interception 4.2. Privacy Model +==========+==============+===================+====================+ | Entity | Knows Source | Knows Destination | Content Visibility | +==========+==============+===================+====================+ | Customer | X | X | X | +----------+--------------+-------------------+--------------------+ | CFR | X | | | +----------+--------------+-------------------+--------------------+ | CDN | | X | | +----------+--------------+-------------------+--------------------+ Table 1 No single entity can link source and destination unless collusion or compromise occurs. 4.3. Deployment Models * *ISP-embedded CFR* - Integrated in broadband or mobile access gateways. * *Enterprise CFR* - For employee source privacy against cloud services. * *Federated CFRs* - CFRs operated by third parties, potentially discoverable via DNS. 5. Relationship to Existing Work * *ECH (RFC9460)* - Protects destination identity; CFR complements it by protecting source identity. Scalone Expires 3 September 2026 [Page 4] Internet-Draft CFR Source Privacy March 2026 * *DPRIVE (DoH/DoT/DoQ)* - Encrypts DNS traffic; CFR addresses the transport-layer metadata. * *PEARG / HRPC* - Explore broader issues of privacy and decentralization in Internet architecture. 6. Design Considerations and Open Questions 6.1. Discovery and Bootstrapping * Use of DDR/DNR to advertise CFR endpoints. * Trust establishment between customer devices and CFR operators. 6.2. Performance and Scalability * Relay overhead and impact on latency. * Stateless versus stateful design parameters. 7. Abuse Prevention * Preventing use as an open relay. * Integration with Privacy Pass or similar token-based systems. 8. Interoperability * Potential chaining of multiple CFRs. * Compatibility with QUIC migration and multipath mechanisms 9. IETF Standardization * Target areas include DISPATCH, MASQUE, PEARG, or future CFR- specific working groups 10. Security Considerations CFRs enhance privacy but introduce new risks: * *Collusion risk* - If the CFR and CDN share data, correlation can be restored. * *Abuse vectors* - Attackers could abuse CFRs for amplification or anonymization unless constrained. * *Operational drift* - CFRs must not evolve into DPI or filtering points; specifications should explicitly prohibit modification or inspection. * *Accountability tension* - Some deployments may need soft attribution mechanisms without compromising anonymity. * *Need for IPv4/IPv6 NAT randomization standards* - CFR deployments rely on sourc address rewriting, but current NAT behaviors, especially for IPv6 prefix translation and IPv4 port allocation, Scalone Expires 3 September 2026 [Page 5] Internet-Draft CFR Source Privacy March 2026 lack standardized, privacy preserving randomization requirements. A future standard should define deterministic entropy floors for address/port selection, avoid stable mappings, and ensure alignment with the CFR privacy model. Further analysis is required to quantify threat models and formal privacy guarantees. 11. IANA Considerations This document makes no IANA requests. 12. References 12.1. Informative References * [RFC9460] Benjamin L. et al., _TLS Encrypted Client Hello_, RFC 9460, 2023. * [RFC9325] Thomson, M., _Recommendations for Secure Use of TLS and DTLS_, RFC 9325, 2022. * [I-D.ietf-add-ddr] _Discovery of Designated Resolvers (DDR)_, Internet-Draft, IETF ADD WG. * [I-D.ietf-add-dnr] _Discovery of Network-designated Resolvers (DNR)_, Internet-Draft, IETF ADD WG. 13. Acknowledgments The author acknowledges the helpful input and discussions from Andrew Campling, Arnaud Taddei, Kevin Smith, Lee Wilman, Tom Newton, and colleagues within Vodafone Group, DINRG, and DISPATCH. Author's Address Gianpaolo Angelo Scalone Vodafone Scalone Expires 3 September 2026 [Page 6]