Heuristics and Algorithms to Prioritize Protocol deploYment B. Trammell Internet-Draft Google Switzerland GmbH Intended status: Informational 26 July 2026 Expires: 27 January 2027 Slow Alternate Detection for Happy Eyeballs draft-trammell-happy-sad-01 Abstract This document specifies Slow Alternate Detection (SAD) for Happy Eyeballs, an ICMP-based advisory path signal [RFC8558] for exposing information about path non-selection on-path devices in order to aid debugging and measurement of Happy Eyeballs. About This Document This note is to be removed before publishing as an RFC. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-trammell-happy-sad/. Discussion of this document takes place on the Heuristics and Algorithms to Prioritize Protocol deploYment Working Group mailing list (mailto:happy@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/happy/. Subscribe at https://www.ietf.org/mailman/listinfo/happy/. Source for this draft and an issue tracker can be found at https://github.com/britram/happy-sad. 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 27 January 2027. Trammell Expires 27 January 2027 [Page 1] Internet-Draft Slow Alternate Detection for Happy Eyeba July 2026 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. 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 . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions and Definitions . . . . . . . . . . . . . . . . . 3 3. Message Format (ICMP) . . . . . . . . . . . . . . . . . . . . 3 3.1. Code . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.1.1. Not Selected . . . . . . . . . . . . . . . . . . . . 4 3.2. Hash Algorithm (HAlg) . . . . . . . . . . . . . . . . . . 4 3.3. Approximate Sample Rate . . . . . . . . . . . . . . . . . 5 3.4. 5-tuple fields . . . . . . . . . . . . . . . . . . . . . 6 3.5. Additional Data . . . . . . . . . . . . . . . . . . . . . 7 4. Protocol Behaviors . . . . . . . . . . . . . . . . . . . . . 7 4.1. Not Selected . . . . . . . . . . . . . . . . . . . . . . 7 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 5.1. Message Injection and Spoofing . . . . . . . . . . . . . 8 5.2. Use as a Traffic Direction Primitive . . . . . . . . . . 8 5.3. Reaction to Advisory Signals . . . . . . . . . . . . . . 9 5.4. Interaction with Network Filtering . . . . . . . . . . . 9 6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 9 6.1. Exposure of the Five-Tuple . . . . . . . . . . . . . . . 10 6.2. Linkability of the Hashed DNS Answer . . . . . . . . . . 10 6.3. Limits of Hashing . . . . . . . . . . . . . . . . . . . . 10 6.4. Sampling as a Privacy Control . . . . . . . . . . . . . . 11 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 8.1. Normative References . . . . . . . . . . . . . . . . . . 11 8.2. Informative References . . . . . . . . . . . . . . . . . 12 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 13 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 13 Trammell Expires 27 January 2027 [Page 2] Internet-Draft Slow Alternate Detection for Happy Eyeba July 2026 1. Introduction Happy Eyeballs [I-D.ietf-happy-happyeyeballs-v3] encourages new protocol deployment by reducing the availabity risk associated with attempting to use them. However, in doing so, it masks configuration and deployment failures of these very protocols. There are potential causes of such failures, with potential root causes at the end user terminal, CPE, access network, CDN, DNS configuration, and end server. Given the diffusion of root causes, debugging these errors can be difficult. This document presents Slow Alternate Detection (SAD), an ICMP-based advisory path signal [RFC8558] to devices along the path of a non- selected candidate designed as part of an array of approaches to this problem. It is intended to be used together with complementary monitoring and logging information at each point along the potential failure chain of a non-selected candidate. This design uses hashes of data relevant to a failure to allow the correlation of nonselection events to on path devices and actors who already have access to that data, while allowing only aggregate analysis by other on-path actors. 2. Conventions and Definitions 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. 3. Message Format (ICMP) The message format for SAD is identical for both ICMPv4 and ICMPv6, and is depicted in Figure 1 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 = 44 | Code | HAlg | ASR | NextHdr | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Transport Port | Destination Transport Port | +-------------------------------+-------------------------------+ | Additional Data | | (code-dependent) | ... ... Figure 1: SAD Message Format Trammell Expires 27 January 2027 [Page 3] Internet-Draft Slow Alternate Detection for Happy Eyeba July 2026 The Code, HAlg (Hash Algorithm), ASR (Approximate Sample Rate), Next Header and Source and Destination Transport Port, and Additional Data fields are described in the subsections below. 3.1. Code The ICMP Code for a SAD message takes one of the following values, and specifies the message's semantics as well as the meaning of the Additional Data field. It can take the following values: +=======+==============+===================+ | Code | Description | Additional Data | +=======+==============+===================+ | 0 | Not Selected | hashed DNS Answer | +-------+--------------+-------------------+ | 1-255 | Reserved | not present | +-------+--------------+-------------------+ Table 1 3.1.1. Not Selected Not Selected indicates that is sent to a non-selected candidate by the client, after it has made the decision not to use that candidate. See Section 4.1 for the use of this message. When present, the Additional Data field of a Not Selected contains the DNS Message [RFC1035] associated with the answer that led to the connection attempt, hashed using the selected hash algorithm. 3.2. Hash Algorithm (HAlg) The Hash Algorithm field determines both the length of the Additional Data field and the hash algorithm used to hash it. The following hash algorithms are available: +=======+========+=========================+ | Value | Length | Algorithm | +=======+========+=========================+ | 0 | 0 | Additional Data Omitted | +-------+--------+-------------------------+ | 1 | 256 | SHA256 [RFC6234] | +-------+--------+-------------------------+ | 2-15 | undef | Reserved for Future Use | +-------+--------+-------------------------+ Table 2 Trammell Expires 27 January 2027 [Page 4] Internet-Draft Slow Alternate Detection for Happy Eyeba July 2026 3.3. Approximate Sample Rate A client that reports only a sampled subset of its non-selected candidates (see Section 4.1) uses the Approximate Sample Rate (ASR) field to expose the rate at which it sampled, so that a receiver can estimate the number of non-selection events that a given number of received messages represents. The field takes one of the following values: +=======+===========================+ | Value | Sampling Rate | +=======+===========================+ | 0 | 1 in 1 (unsampled) | +-------+---------------------------+ | 1 | 1 in 2 | +-------+---------------------------+ | 2 | 1 in 5 | +-------+---------------------------+ | 3 | 1 in 10 | +-------+---------------------------+ | 4 | 1 in 20 | +-------+---------------------------+ | 5 | 1 in 50 | +-------+---------------------------+ | 6 | 1 in 100 | +-------+---------------------------+ | 7 | 1 in 200 | +-------+---------------------------+ | 8 | 1 in 500 | +-------+---------------------------+ | 9 | 1 in 1,000 | +-------+---------------------------+ | 10 | 1 in 10,000 | +-------+---------------------------+ | 11 | 1 in 100,000 | +-------+---------------------------+ | 12 | 1 in 1,000,000 | +-------+---------------------------+ | 13 | 1 in 10,000,000 | +-------+---------------------------+ | 14 | Reserved for Future Use | +-------+---------------------------+ | 15 | Sampled, rate undisclosed | +-------+---------------------------+ Table 3 Trammell Expires 27 January 2027 [Page 5] Internet-Draft Slow Alternate Detection for Happy Eyeba July 2026 A client may sample its non-selected candidates at any rate it chooses, and SHOULD set this field to the defined value nearest, in proportional terms, to the rate it actually used. A receiver estimates the number of non-selection events that a set of messages bearing a given value represents by multiplying their count by the N in the value's "1 in N" rate. Because the reported value is the nearest defined rate rather than the exact rate applied, this estimate is approximate, with an error bounded by the spacing between adjacent defined rates; the field is named accordingly. The finer resolution at higher rates and coarser resolution at lower ones reflects the expected use: an individual client sampling for its own reasons operates at the higher rates, where the 1-2-5 spacing keeps the estimation error of any single value small, while the decade steps at the low end serve large-scale reporting deployments aggregating across many clients, for which a coarser rate is sufficient. A value of 0 indicates that the client is not sampling and reports every non-selected candidate; each such message represents exactly one non-selection event. A value of 15 indicates that the client is sampling but does not disclose the rate. A receiver MUST NOT use a message bearing this value to estimate a count of non-selection events, as no unbiased estimate is possible from it; it MAY log or count such messages as individual observations. This value allows a client to treat its sample rate as sensitive, at the cost of the aggregate weighting its messages would otherwise support; see Section 6.4. A client MUST NOT set this field to a value marked Reserved for Future Use. A receiver that encounters a reserved value MUST treat it as it treats the value 15, and MUST NOT use the message for count estimation; a rate defined for a reserved value by a later document is thereby ignored, rather than misinterpreted, by a receiver implementing this document. 3.4. 5-tuple fields The Next Header (or Protocol) field contains the IP protocol (e.g. TCP, UDP) of the non-selected path. The Source and Destination Transport Port fields contain the source and destination port of the non-selected path. While this will not allow NAT transparency of the SAD message, it does allow analysis and correlation across the NAT by the operator thereof. If the candidate transport protocol does not have port numbers, or if the client chooses not to expose them, these fields are set to 0. Trammell Expires 27 January 2027 [Page 6] Internet-Draft Slow Alternate Detection for Happy Eyeba July 2026 3.5. Additional Data The Additional Data contains code-specific additional data. If present, it MUST be hashed with a hash algorithm specified by the Hash Algorithm field. 4. Protocol Behaviors Each of the (currently one) message code(s) associated with the SAD message has an associated protocol behavior, defined below. 4.1. Not Selected A client sends a Not Selected message after it has decided not to use a given candidate identified by the 5-tuple in the Not Selected message. There is no guarantee of the relative timing of the SAD Not Selected message and the transport layer shutdown datagrams associated with this nonselection. The client may send Not Selected messages on only a sampled portion of its non-selected candidates. In this case, the client SHOULD expose the selected sample rate in the Approximate Sample Rate field. As this is an advisory path signal, forwarding elements and servers MUST NOT take any action on the receipt of a Not Selected message beyond logging them for later analysis. In the following cases, the client MUST NOT include the hashed DNS answer in the Not Selected message: * if the DNS Answer message was retrieved from an off-path resolver (e.g., via DoH [RFC8484]), since the answer would be useless to an on-path resolver. * if the connection attempt used Encrypted Client Hello (ECH) [RFC9849] in the TLS handshake, since the answer might not have sufficient entropy to allow the answer hash to adequately protect the server name. 5. Security Considerations As an explicit path signal, SAD exposes information about path non- selection to devices along the path of a non-selected candidate, and does so in an unauthenticated ICMP message carried outside any cryptographic context shared with its receiver. The considerations in this section follow the guidelines in [RFC3552], and assume an attacker that is either on the path between the client and the non- selected candidate, in which case it can observe, delay, drop, or Trammell Expires 27 January 2027 [Page 7] Internet-Draft Slow Alternate Detection for Happy Eyeba July 2026 modify SAD messages at will, or off the path, in which case it can inject SAD messages provided it is able to spoof the source address of a client. Neither capability is addressed by the mechanism described in this document. 5.1. Message Injection and Spoofing ICMP messages carry no source authentication, and SAD adds none. An off-path attacker able to spoof a client's source address can therefore generate Not Selected messages bearing an arbitrary five- tuple and arbitrary contents in the Additional Data field, and a receiver of such a message has no means available to it to distinguish that message from one generated by the client it purports to come from. The consequence of this is corruption of the datasets SAD exists to populate. Since receivers are expected to log these messages for later analysis (see Section 4.1), an attacker can inject apparent non-selection events for candidates that were never offered, or in volumes that misrepresent the rate at which non-selection occurs, and thereby bias aggregate analysis in a direction of its choosing. A partial mitigation follows from the intended use of the signal: since SAD is designed to be correlated with data the receiver already holds, messages for which no corresponding local record exists can be treated as unverified, and analyses that rest on SAD messages alone, without such correlation, should be understood to rest on unauthenticated input. 5.2. Use as a Traffic Direction Primitive The destination address of a SAD message is chosen by the client, since it is by definition the address of a candidate that the client has declined to use, and nothing in this document constrains the set of addresses that a client may treat as a candidate. A compromised client, or code running on an otherwise well-behaved host, can therefore be made to emit Type 44 messages toward an arbitrary victim address. SAD provides no amplification: each message is generated by the client, elicits no response, and is small, so the traffic that can be directed at a victim in this way is bounded above by the traffic the compromised host could direct at that victim in any case. The mechanism therefore adds no new denial-of-service capability, though it may supply traffic of a kind that is less likely than other traffic from the same host to be attributed to that host's compromise. Ordinary ICMP rate limiting at forwarding elements, together with ingress filtering [RFC2827], remains the appropriate response; SAD is not designed to carry a defense of its own. Trammell Expires 27 January 2027 [Page 8] Internet-Draft Slow Alternate Detection for Happy Eyeba July 2026 5.3. Reaction to Advisory Signals Section 4.1 requires that receivers take no action on a Not Selected message beyond logging it for later analysis. This is a design constraint on receivers rather than a property of the protocol: it cannot be enforced by the sender, and its observance cannot be verified by any party. Where it is not observed, the injection capability described above becomes considerably more consequential. A receiver that feeds SAD messages into automated blocklisting, into traffic engineering decisions with immediate effect, or into reconfiguration of server or resolver selection grants an attacker able to spoof a client address a measure of direct influence over that receiver's behavior, at a cost to the attacker of a single forged packet. The restriction to logging is accordingly not merely a matter of layering hygiene in the sense of [RFC8558]; it is the property that keeps a forgeable advisory signal from becoming a control input. 5.4. Interaction with Network Filtering As a newly allocated ICMP type, SAD messages may be discarded by firewalls and middleboxes configured to forward only those ICMP types known to them at the time of their deployment. The pattern of transmission may attract attention independently of the type allocation: messages bearing a fixed-length opaque payload, sent to addresses with which the host has recently had short-lived flows, resemble the traffic patterns of ICMP tunneling and of reconnaissance, and may be treated as such by intrusion detection systems. Delivery of SAD messages should therefore be expected to be unreliable in ways that are neither uniform across paths nor stable over time. This is not harmful to the client, whose operation does not depend on delivery, but it does mean that the absence of SAD messages at a collector cannot be taken as evidence of the absence of the non-selection events they would have reported. 6. Privacy Considerations SAD deliberately places on the wire information about a client's candidate selection that would not otherwise appear there, and does so in a message addressed to a party that, by construction, the client has decided not to communicate with. The considerations in this section use the terminology of [RFC6973]. Trammell Expires 27 January 2027 [Page 9] Internet-Draft Slow Alternate Detection for Happy Eyeba July 2026 6.1. Exposure of the Five-Tuple The exposure of transport ports in the SAD message is a deliberate design decision, taken so that the operator of a NAT along the path can correlate the message with its own translation state. The correlation this enables for the NAT operator is precisely the correlation it enables for every other observer of the message. A client behind a NAT ordinarily has its activity aggregated with that of other clients sharing the same external address; a SAD message restores a per-flow view of that activity to any observer positioned to see it, including the receiving candidate itself. A client for which this exposure is unacceptable can set the port fields to zero, as the definition of those fields permits, at the cost of the correlation they exist to support. 6.2. Linkability of the Hashed DNS Answer The hash carried in the Additional Data field is a deterministic function of the DNS answer, and is therefore stable across every message that reports non-selection of a candidate derived from that answer. An observer that receives more than one such message can link those messages to one another by equality of the field alone, without reversing the hash and without reference to the source address of the messages. That linkage extends across time, across changes of client address and NAT binding, and across devices, since two clients resolving the same name will produce the same hash. The Additional Data field is thus a linkable identifier in the sense of [RFC6973]. It identifies a resolution rather than a user, and for names resolved by very many clients the distinction is a meaningful one; for names resolved by few, it is thin. Section 4.1 requires that the hashed answer be omitted where the client knows the answer was retrieved from an off-path resolver, which addresses the related concern that SAD would otherwise disclose to on-path parties the content of resolutions deliberately routed around them, but it does not bear on the linkability described here, which arises equally for answers obtained on path. 6.3. Limits of Hashing Hashing the Additional Data raises the cost of reading it; it does not make it confidential. DNS answers are drawn from a space that is public, enumerable, and for any given deployment small: an observer that wishes to learn which name a given hash corresponds to can compute the hashes of the names it considers plausible and compare, at a cost that does not scale with the strength of the hash function. Trammell Expires 27 January 2027 [Page 10] Internet-Draft Slow Alternate Detection for Happy Eyeba July 2026 The hashing in this design should accordingly be understood as limiting bulk disclosure to incidental observers, and as providing a correlation handle to parties that already hold the answer, which is the goal stated in Section 1 — and not as withholding the answer from an observer that wants it. This follows from the distribution of the inputs rather than from the choice of algorithm, and registration of stronger algorithms in the Hash Algorithm registry will not change it. A construction that did resist such an attack, such as a keyed hash or a per-client salt, would do so by destroying the cross-party correlation the field exists to provide. 6.4. Sampling as a Privacy Control The Approximate Sample Rate field described in Section 3.3 allows a client to report non-selection for only a portion of its candidates. Sampling bounds the number of linkable observations any observer can collect from a given client over a given interval, and clients weighing the exposure described above may reasonably treat the sample rate as a privacy parameter as well as a measurement one. The rate itself is visible in the message, and a rate that is unusual among the population of clients an observer sees may serve to distinguish those clients from the remainder. Clients selecting a sample rate for privacy reasons are therefore better served by a value that is common among their peers than by one chosen independently. 7. IANA Considerations This document has two actions for IANA: * It requests the allocation of Type 44 in the ICMP Type Numbers registry for Slow Alternative Detection, with this document as reference on publication as an RFC. * It requests the establishment the Slow Alternative Detection ICMP Code Field subregistry initialized with the contents of Section 3.1. 8. References 8.1. Normative References Trammell Expires 27 January 2027 [Page 11] Internet-Draft Slow Alternate Detection for Happy Eyeba July 2026 [I-D.ietf-happy-happyeyeballs-v3] Pauly, T., Schinazi, D., Jaju, N., and K. Ishibashi, "Happy Eyeballs Version 3: Better Connectivity Using Concurrency", Work in Progress, Internet-Draft, draft- ietf-happy-happyeyeballs-v3-04, 1 July 2026, . [RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, November 1987, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF)", RFC 6234, DOI 10.17487/RFC6234, May 2011, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 8.2. Informative References [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827, May 2000, . [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on Security Considerations", BCP 72, RFC 3552, DOI 10.17487/RFC3552, July 2003, . [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., Morris, J., Hansen, M., and R. Smith, "Privacy Considerations for Internet Protocols", RFC 6973, DOI 10.17487/RFC6973, July 2013, . [RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, . Trammell Expires 27 January 2027 [Page 12] Internet-Draft Slow Alternate Detection for Happy Eyeba July 2026 [RFC8558] Hardie, T., Ed., "Transport Protocol Path Signals", RFC 8558, DOI 10.17487/RFC8558, April 2019, . [RFC9849] Rescorla, E., Oku, K., Sullivan, N., and C. A. Wood, "TLS Encrypted Client Hello", RFC 9849, DOI 10.17487/RFC9849, March 2026, . Acknowledgments Thanks to the participants in the discussions on error reporting at the HAPPY WG meetings at IETF 123 in Madrid, IETF 124 in Montreal, and on the mailing list in between, to which this document is an answer. Special thanks to Martin Duke for backronyming the name of this extension, and to Martin Thomson for pointing out interactions with ECH. The Approximate Sample Rate and Security and Privacy Considerations sections were written with the assistance of Claude Opus. Author's Address Brian Trammell Google Switzerland GmbH Email: ietf@trammell.ch Trammell Expires 27 January 2027 [Page 13]