]> Tsinghua University & Zhongguancun Laboratory

Beijing China xuke@tsinghua.edu.cn

Tsinghua University

Beijing China fengxw06@126.com

Tsinghua University

Beijing China yangyx22@mails.tsinghua.edu.cn

Tsinghua University & Zhongguancun Laboratory

Beijing China qli01@tsinghua.edu.cn

Internet Internet Area Working Group ICMP validation off-path attack challenge-confirm IPv4 options ICMP error messages provide feedback used by hosts to manage network communication. Existing validation of the quoted invoking packet is essential, but its resistance to blind off-path forgery depends on the information quoted and the communication state available to the receiver. This document describes a Challenge-Confirm mechanism that supplements existing ICMP validation. After an eligible initial error passes existing checks, the host can mark the associated flow and include an unpredictable token in an IPv4 option of a subsequent packet that would otherwise be transmitted. Receipt of the initial error does not immediately generate a probe or a separate ICMP Echo Request. A later ICMP error can return the token by quoting the invoking packet. The token is computed using a secret local to the validating host. No key is shared with routers or peer hosts, and no per-challenge nonce cache is required. Successful token validation provides evidence of access to a valid token; it does not authenticate a router's identity or the semantics of the reported error. This document specifies bounded triggering, replay limitations, and deployment considerations, including the need to evaluate IPv4 option traversal and quotation. It does not report Internet-wide deployment measurements.

Introduction The Internet Control Message Protocol (ICMP) reports conditions such as an unreachable destination or a packet that cannot be forwarded without fragmentation. These reports can influence transport behavior, Path MTU Discovery, and routing decisions. A forged report can therefore affect communication beyond the processing of an individual packet. Research has demonstrated attacks involving forged fragmentation-related feedback and shared network-stack state , as well as attacks involving ICMP Redirect processing . These examples motivate careful validation; they do not imply that every implementation is vulnerable or that one additional mechanism addresses every attack. Validation of the quoted invoking packet is the first line of defense. A host can check whether the quotation corresponds to local communication and, where available, compare it with transport state or recently transmitted data. The strength of this evidence varies with the protocol, implementation, quotation length, and attacker knowledge. In particular, matching plausible flow identifiers is not always sufficient to establish that the sender of an error observed a transmitted packet. The mechanism in this document adds an unpredictable token to a subsequent packet of an eligible flow. The token is carried in an IPv4 option so that it can be included in the original IPv4 header quoted by a later ICMP error. A router need not implement a challenge protocol: it only performs its normal ICMP quotation behavior. Reliable forwarding and quotation of the option are deployment assumptions, not established properties of all paths. The host computes and verifies the token using a host-local secret, taking inspiration from the avoidance of per-request state in SYN-cookie designs . It retains bounded trigger state, rather than a nonce cache for every challenge. The aim is to improve resistance to blind off-path forgery while making the associated resource costs, availability tradeoffs, and validation limits explicit.

Conventions and Terminology 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 when, and only when, they appear in all capitals, as shown here. These requirements describe an implementation of the proposed mechanism; this document does not require its deployment by all IPv4 hosts.

Validating host:

The host that transmits the original traffic, receives ICMP errors about that traffic, and generates and verifies tokens.

Invoking packet:

The packet whose processing caused an ICMP error. A quotation is the portion of that packet included in the error.

Initial error:

An otherwise eligible ICMP error whose quotation does not carry a Challenge-Confirm option.

Challenge-bearing packet:

A normally scheduled outgoing packet to which the validating host adds a Challenge-Confirm option. It is not a separately generated probe.

Confirmation:

A later ICMP error that quotes a challenge-bearing packet and passes token validation. It remains subject to the ordinary checks for its type and code.

Token (challenge nonce):

The 128-bit value defined in . The term "nonce" is retained for continuity with earlier revisions, but the value is deterministic for a flow within a key epoch and is not guaranteed to be unique per packet.

Flow:

The locally identified communication described in . A socket and a flow are not necessarily interchangeable: one UDP socket can communicate with several destinations.

Existing Validation and Residual Limitations

Existing Checks An implementation first checks the ICMP message and its quotation for validity, associates the quotation with local communication, and applies the relevant protocol-specific checks. Depending on the implementation, these include transport sequence information, randomized ports or identifiers, recent transmission records, and application-specific data. Section 5.2 of recommends that UDP applications validate that an ICMP error corresponds to a datagram actually sent by the application. It notes that this requires context and that the necessary state or APIs are not always available. Section 5.2 of provides a related recommendation for upper-layer validation of ICMPv6 messages, while leaving the particular checks to the upper layer. That recommendation is relevant background; the mechanism specified here is for IPv4 only. For TCP, sequence-number checks can reject errors that do not relate to data in flight, as discussed in Section 4.1 of . Their strength depends on implementation behavior and the information available to an attacker. The minimum IPv4 quotation includes the TCP ports and sequence number, but need not include the acknowledgment number. TCP is not treated as inherently immune to forged ICMP.

Residual Limitations UDP and ICMP Echo traffic can have useful local state. Randomized ports, Echo identifiers, application tokens, and records of recently transmitted packets can all increase the difficulty of forgery. The absence of a connection-oriented transport does not imply the absence of validation state. Nevertheless, that information may be predictable, unavailable for comparison, or absent from the quotation. The IPv4 ICMP format in includes the original IP header and the first 64 bits of its data. For UDP, these eight bytes contain the UDP header and need not expose an application-specific token. Longer quotations can support additional checks. A UDP checksum provides error detection and is not a cryptographic authenticator. This proposal targets cases where existing checks are performed but the available quoted information provides insufficient resistance to blind off-path forgery. For example, an attacker that knows the endpoints and ports may be able to construct a quotation that passes flow association if the remaining checked fields are also known or predictable. That example does not apply when the receiver already verifies additional information that the attacker cannot supply. An implementation MUST NOT use Challenge-Confirm as a reason to omit existing validation. A report that fails those checks is rejected without creating challenge state. Evaluation of this mechanism needs to distinguish a missing implementation of an existing check from a residual limitation after that check is applied.

Scope and Threat Model The attacker considered here can inject ICMP messages and may know flow identifiers, but cannot observe the challenge-bearing packet, obtain a valid token by another channel, or learn the host-local secret. The keyed-hash function is assumed to retain its security properties. Under these assumptions, a valid token provides additional evidence against blind forgery. The mechanism does not authenticate the identity or routing authority of the sender of an ICMP error. An observer of a token can copy it. The token does not cryptographically protect the outer ICMP Type, Code, reported MTU, Redirect gateway, or other error-specific fields. A malicious on-path node or peer that obtains a token is outside the blind-attacker model. Successful validation also does not establish that the initial error was authentic, that two errors came from the same node or path, or that an error condition persisted between them. In this revision, a token is bound to a flow and an accepted key epoch, not to one packet or one error condition. The replay consequences are described in . This revision defines flow identification for IPv4 UDP, TCP, and ICMP Echo Requests. TCP use is optional and supplements its existing protections. Candidate ICMP messages are Destination Unreachable (Type 3), Redirect (Type 5), Time Exceeded (Type 11), and Parameter Problem (Type 12), with handling constrained by and existing code-specific rules. Other ICMP types do not trigger this mechanism. Multicast, broadcast, fragmented quotations, and transport protocols without a defined flow identifier are outside the validation procedure in this revision. The mechanism is a candidate for controlled evaluation on selected traffic and paths. Requiring a confirmation can suppress legitimate error feedback. Implementations therefore need an explicit local enablement policy, resource limits, and a documented failure policy as described in . It is not a drop-in replacement for all existing ICMP processing. Enablement MUST be determined by local policy and communication context, rather than solely by fields supplied in an incoming quotation. If a state change requires confirmation, an unsupported or incomplete quotation MUST NOT authorize that change through a fallback path. This includes an alleged fragment that cannot be validated by this revision.

Challenge-Confirm Mechanism

Overview and Host-Local Secret The secret is local to the validating host. It is not shared with routers or peer hosts. A router neither computes nor verifies the token; it only quotes the invoking packet according to the applicable ICMP specification. The validating host recomputes the token from that quotation and its local key. An eligible initial error can mark a flow, subject to the limits in . The marking does not immediately cause a transmission. The host attempts to add a token when that flow next transmits a packet that would otherwise be sent. A later error containing a valid token is evaluated as a new report. | |<---------- Initial ICMP error -----------| | | | Check quotation and local context | | Mark eligible flow within budget | | Do not act on this error or send a probe | | | |------ Next ordinary packet + token ----->| | (if insertion is possible) | | | | If processing causes a new error: | |<-------- ICMP quoting the token ---------| | | | Validate token and local context | | Apply type-specific checks to NEW error | | No confirmation: no additional evidence | ]]>

Eligible Flows and Local Context Before marking a flow or accepting a token, the implementation MUST associate the quotation with an existing local communication context. It MUST apply the available checks on recent transmissions and transport or application state. Merely locating a listening socket does not establish that a packet was sent to the quoted destination. For UDP and TCP, the flow identifier consists of the source IPv4 address, destination IPv4 address, IP Protocol value, source port, and destination port of the outgoing traffic. For ICMP Echo Requests, it consists of the two IPv4 addresses, IP Protocol value 1, Echo Identifier, and Echo Type and Code (8 and 0). The Echo Sequence Number can be used in ordinary request validation but is not part of the flow identifier used to compute the token. An unconnected UDP socket can serve multiple flows. A pending mark MUST identify the particular destination and selectors; it MUST NOT automatically cause a packet to an unrelated destination to carry a token. Implementations can attach bounded per-destination metadata to existing socket state or use a capacity-limited table. If the required association cannot be made within the configured budget, the error does not create a mark. ICMP Echo can have socket or request state and is not assumed to lack it. A probabilistic structure, if used as a trigger hint, MUST NOT establish the existence of local communication or substitute for exact flow association and token verification. Its capacity, aging, saturation behavior, and possible false triggers MUST be bounded and documented. A received error alone MUST NOT create an otherwise nonexistent communication context.

Token Construction and Key Lifetime The validating host generates an independent 256-bit secret key using a cryptographically secure random source consistent with . Keys MUST be separate for different local network namespaces or other routing/security compartments, and MUST NOT be disclosed to peers. The token is the first 16 octets of HMAC-SHA-256 : All addresses and multi-octet integers are encoded in network byte order. For UDP and TCP, Selector_1 and Selector_2 are the source and destination ports. For Echo Requests, Selector_1 is the Echo Identifier and Selector_2 is the two octets Type followed by Code, namely 0x08 and 0x00. The source and destination are those of the outgoing invoking packet, not those of the outer ICMP message. Flow_ID is exactly 13 octets; no padding or implementation-dependent structures are included. The option format in identifies this construction once its Option Type is assigned. Its Reserved field is not an epoch or version field. The label provides domain separation for the construction; a future incompatible construction requires a separately specified encoding or negotiation and MUST NOT silently reuse this definition. Each deployment MUST configure a finite key epoch duration E > 0 and a finite previous-key grace duration G, where 0 <= G <= E. A fresh, independent key is generated at each epoch transition. The host MAY accept the immediately preceding key until G time units after that transition; no older key is accepted. Expired keys MUST be erased. At most two keys are tried for any report. Key retention deadlines MUST NOT be extended by incoming traffic. A key MUST NOT generate tokens after its epoch ends, and MUST NOT validate tokens after the end of its configured grace interval, even if a scheduled rotation was missed. No epoch number is transmitted. The host verifies against the current key and, during its grace interval, the previous key. Token comparison MUST use a constant-time equality operation. E and G are local parameters, since no other node computes the token. Their values and rationale MUST be documented for an evaluation. A token generated near the start of an epoch can remain acceptable for up to E + G; a small G can reject legitimate delayed errors around rotation. This construction deliberately provides no per-packet uniqueness or single-use property. A new packet with the same Flow_ID during an epoch receives the same token. Addresses or ports reused during an acceptance window can also yield the same token. Existing communication checks and error-specific handling remain necessary; key rotation limits the window but does not remove these effects.

Receiving an Error The following procedure applies to traffic for which the mechanism is enabled. ICMP processing outside that scope follows existing policy.

1. Validate message lengths, checksum, Type and Code, and the structural consistency of the quotation. Require the complete quoted IPv4 header, using its IHL, and sufficient quoted upper-layer bytes to identify the flow. Apply existing protocol-specific validation and establish local communication context. Unsupported traffic and reports that fail these checks do not create a mark.
2. Parse the quoted IPv4 options, subject to their length bounds. If exactly one well-formed Challenge-Confirm option is present, attempt token verification within the configured verification budget. A malformed, duplicate, unsupported, or invalid token option MUST NOT be treated as a token-free initial error. Failure terminates this mechanism's processing of that report without scheduling a challenge.
3. If the token validates under an accepted key, recheck any local context that may have changed and pass the new report to the type-specific handling in . A pending mark is not required for verification. Successful token validation alone MUST NOT update PMTU, route, or application error state.
4. If the quotation contains no Challenge-Confirm option, treat the report as an initial error only if it is eligible and passes existing checks. Subject to , record or coalesce a pending mark for that flow. Do not act on the initial error to make the protected state change. The initial error is discarded and is not saved for later acceptance.

In particular, a later valid token MUST NOT retroactively authenticate the discarded initial error. An invalid token, an expired key, or a spent verification budget supplies no confirmation. Implementations MUST NOT fall back to accepting that same report solely because Challenge-Confirm could not validate it.

Sending the Challenge-Bearing Packet A mark has a finite local lifetime L > 0 and applies only to its associated flow. When that flow next attempts an ordinary transmission before the mark expires, the host checks the insertion conditions and the relevant rate budget. If they allow insertion, it computes the token and adds the option defined in . The mark is consumed by this attempt whether or not insertion succeeds. If no transmission occurs, the mark expires without producing a packet. The mechanism MUST NOT generate a separate probe, change the packet into an Echo Request, or initiate an application retransmission merely because an initial error arrived. The original flow can itself be an Echo Request flow; the distinction is that this mechanism adds no independently generated Echo exchange. Insertion MUST preserve the existing application payload, transport selectors, IP destination, and DF policy. The option is inserted before any End of Option List marker, with valid padding; it updates IHL, Total Length, and the IPv4 header checksum. It MUST fit within the maximum IPv4 header and total lengths and the locally applicable packet-size limit without requiring new local fragmentation solely to carry the option. A packet already fragmented, already containing the option, or otherwise unsuitable for insertion is sent or rejected according to ordinary transmission rules, without forcing insertion. Transports using segmentation offload need equivalent per-wire-packet behavior. If insertion is skipped because of a size, key, or resource limit, the attempt does not obtain a challenge. The original error remains unconfirmed. This revision does not alter the DF policy or define confirmation for fragmented quotations; downstream fragmentation is a limitation discussed in .

Bounded State and Resource Limits The mechanism has no per-challenge nonce cache, but it does have keys, pending marks, and accounting state. Calling the entire implementation stateless would obscure those resources. An implementation MUST impose fixed memory budgets for pending marks and for any additional flow, destination, or rate-accounting entries used by this mechanism. Incoming errors MUST NOT grow those structures without a bound. Only locally established communication can acquire a mark. At capacity, a new mark is declined or an existing mark is evicted according to documented policy; the unconfirmed error is not accepted as a consequence. Repeated initial errors for a pending flow SHOULD be coalesced. They MUST NOT extend that mark's original expiry indefinitely. Per-flow and per-destination limits, together with a global limit, MUST bound the rate of marking and option insertion. A global verification budget MUST also bound processing of reports carrying alleged tokens. Token verification requires at most two HMAC calculations per admitted report. Budget exhaustion produces no confirmation and no new challenge from that report. Limit values and overload behavior are local policy and MUST be specified for a deployment. Accounting itself needs bounded storage; creating an unlimited rate-limit entry for each attacker-supplied tuple would defeat the memory limit. Rate limits can suppress legitimate confirmations, including under attack, and are not a guarantee of availability.

Challenge-Confirm IPv4 Option The proposed option occupies 20 octets. The Option Length follows and includes the Type and Length octets as well as the data. It is not a data-only length.

Option Type:

An 8-bit identifier awaiting IANA assignment. The proposed Copy bit is 0 and Class is 0 (control); the option number remains TBD, as described in .

Option Length:

An 8-bit unsigned integer with value 20. Other lengths are not valid for this definition.

Reserved:

A 16-bit field. The sender MUST set it to zero. A validating host MUST ignore its value when verifying this version of the option. It is not an input to the token computation.

Token:

The 16 octets computed in .

A validating host MUST require exactly one complete occurrence of the option before attempting verification. It MUST bound option parsing by the quoted IHL and by the actual available quotation length, and follow the IPv4 End of Option List and No Operation rules. An invalid length, truncated field, or duplicate occurrence fails this mechanism's validation. The option is in the header of the invoking packet, which is in turn quoted inside the returning ICMP error. It is not an option added to the outer IP header of that error. The general layout is: The ICMP type-specific fields are not universally unused. For example, a Fragmentation Needed message includes the Next-Hop MTU field specified in , while a Redirect includes a gateway address. This mechanism does not redefine either format.

Error-Type-Specific Processing Token validation supplements the ordinary processing of a new error. The baseline requirements of and , applicable updates, and existing transport/application checks continue to apply. A valid token MUST NOT authorize an otherwise invalid Type/Code combination or an otherwise prohibited state change.

Fragmentation Needed For Type 3, Code 4, the host processes the newly received report according to its applicable PMTU validation rules and . It checks the quoted packet, the reported MTU, and their relationship to the affected path and local state. The token does not authenticate the reported MTU. The host MUST evaluate the report against the challenge-bearing packet actually quoted. Adding the option increases that packet's IP length by 20 octets. Consequently, it can encounter an MTU limitation that the earlier ordinary packet did not encounter. A confirmation of that new condition MUST NOT be interpreted as proof that the initial report was correct. The reported Next-Hop MTU describes an IP packet-size limit; it is not adjusted by blindly subtracting 20 from the reported value. Packetization must instead account for the actual headers of packets subsequently sent. Packetization Layer PMTU Discovery and Datagram PLPMTUD provide related approaches based on packetization-layer feedback. This mechanism neither replaces them nor implies that they are available for every application. Withholding an unconfirmed ICMP error can impair conventional PMTUD, particularly when the application does not transmit again.

Other Destination Unreachable Messages For supported codes of Type 3 other than Code 4, existing checks associate the new report with the relevant local communication and interpret the code. In particular, a UDP Port Unreachable (Code 3) remains subject to the socket and application's existing error-delivery and recovery policy. A valid token MUST NOT convert a report normally treated as a soft error into an unconditional connection failure. UDP applications should retain the robustness to transient errors discussed in . One-shot requests may not generate a subsequent packet and therefore may never obtain a confirmation. Deployments need to consider this loss of error feedback when selecting traffic for the mechanism.

Redirect For Type 5, the host MUST retain its ordinary Redirect validation and local policy. Section 3.2.2.2 of describes rejection when the new gateway is not on the connected subnet through which the Redirect arrived or when the source is not the current first-hop gateway for the destination. A valid token MUST NOT bypass those checks or override a local policy that disables Redirect processing. An observer of the token can still forge the outer source address or the advertised gateway. Thus, token validation alone does not establish authority to redirect traffic. In particular, the mechanism provides no new protection against a malicious peer or on-path node that can see the challenge. The new Redirect, if otherwise acceptable, is evaluated on its own contents; a gateway advertised only in the discarded initial error is never installed on the strength of a later token.

Time Exceeded and Parameter Problem For Type 11 and Type 12, the host retains the ordinary code-specific checks and interpretation of the newly quoted packet. A Parameter Problem pointer, for example, is checked against that packet's header, including its options. An error involving the Challenge-Confirm option itself is not evidence that the earlier option-free packet was erroneous and MUST NOT be used to accept the earlier report. Fragment reassembly behavior and quotations of fragments are outside this revision's validation scope. Reports without a usable local flow association do not gain one merely by containing an alleged token.

Failure and Deployment Considerations

Loss, No Further Traffic, and ICMP Rate Limiting There is no timer that retransmits a challenge-bearing packet on behalf of this mechanism. A pending mark expires or is consumed by a transmission attempt. After transmission, the host does not retain a per-challenge waiting record. The absence of a confirmation is inconclusive. The packet may have been delivered successfully, the error condition may have disappeared, either packet may have been lost, or ICMP generation may have been rate-limited. With no later eligible traffic, the process cannot complete. Continuing traffic and a recurring network problem can cause another initial error, but neither retry opportunities nor eventual confirmation are guaranteed. An implementation MUST distinguish its policy for ordinary data transmission from its policy for accepting ICMP errors. Sending later packets without the option does not validate a discarded error. For traffic on which confirmation is required, a missing confirmation MUST NOT be treated as evidence that the initial error was authentic. Ordinary transport and application recovery can continue, with the possibility of persistent loss or delayed error feedback.

Multiple Paths A challenge-bearing packet can take a different path from the packet quoted in the initial error. It may reach its destination successfully, encounter another error, or receive an error from a different node. Only a new report with a valid token and acceptable semantics can be acted on. For example, per-packet load balancing can repeatedly send an ordinary packet over a problematic path and the following challenge-bearing packet over a working path. The host can then fail to confirm a persistent condition indefinitely. Repeating the procedure does not guarantee convergence. The impact depends on packet scheduling, the traffic, and the paths; this document gives no general throughput bound for that case.

Option Traversal and Quotation Existing ICMP quotation rules provide the basis for returning the option in the quoted IPv4 header. However, reliable forwarding and quotation of a new option are deployment assumptions that require evaluation. Routers, firewalls, and other middleboxes can filter, rate-limit, or process packets carrying IPv4 options differently. discusses configurable handling of unrecognized options, including operational filtering behavior. No Internet-wide traversal or quotation measurement is reported here. The mechanism therefore does not claim universal backward compatibility or that intermediate routers are unaffected operationally. Protocol-format compatibility does not establish successful traversal of a particular path. An attacker that can pass initial checks and repeatedly trigger marks can cause ordinary application packets to carry an option that receives different treatment on the path. Such packets may be lost where option-free packets would succeed. Coalescing, expiry, and rate budgets limit triggering, but do not remove this availability risk. Deployment policy should select environments and traffic for which this cost has been evaluated.

Packet Size and Fragmentation The 20-octet option consumes half the maximum IPv4 option space and increases the packet length. Existing options can leave insufficient space. Local MTU limits can prevent insertion, and a downstream MTU can cause a new error even when insertion was locally possible. The checks in preserve ordinary packetization and DF policy. The proposed Copy bit is 0: the option is not copied into every fragment if downstream IPv4 fragmentation occurs. This revision does not validate quotations with a nonzero Fragment Offset or with the More Fragments flag set. It MUST NOT infer a flow or token from an incomplete fragment quotation. Deployments that allow downstream fragmentation must account for the resulting lack of confirmation; changing the Copy bit alone would not provide flow identifiers in non-initial fragments.

NATs, Tunnels, and Local Processing Order Token generation and verification MUST use the same address and selector representation. This typically requires insertion at an appropriate point in the local output path and verification after the existing processing of an incoming ICMP quotation. A NAT may rewrite the invoking packet's addresses or ports and may translate the quoted copy on return. If that processing does not restore a consistent Flow_ID, the token will fail verification. The token excludes mutable fields such as TTL and IPv4 header checksum, but this does not establish general NAT compatibility. An implementation MUST NOT disable Flow_ID binding to accommodate a translation mismatch. It must either arrange a consistent representation using its established local context or treat that configuration as unsupported. For tunnels, this revision applies only when the quoted IP layer is the layer where the token was inserted and the host can recover the corresponding local context. It does not define validation of an outer tunnel error from a token present only in an inner packet. Insertion and verification order, option preservation, translation behavior, and tunnel scope need to be included in deployment evaluation.

Evaluation to Be Reported Evaluation should compare the mechanism against a baseline that already performs applicable quoted-packet checks. Reports should identify which flow fields the attacker knows, which additional information the baseline checks, and whether the quotation includes any application token. Useful measurements include legitimate confirmation success and delay; traversal and quotation of the option; behavior with no subsequent traffic, packet loss, ICMP rate limiting, multiple paths, and translation; option-induced packet-size effects; and normal-traffic impact under repeated triggering. Memory use, cryptographic work, insertion rates, configured E/G/L values, and overload behavior should also be reported. These are evaluation requirements and open deployment questions, not results established by this document.

Security Considerations

Token Guessing and Error Semantics With a suitable HMAC construction and uncompromised key, a blind attacker has negligible success in guessing a 128-bit token for a specified flow within a bounded number of admitted attempts. Verification against up to two accepted keys and the total number of attempts must be considered when evaluating that probability. Token unpredictability does not replace structural checks, local communication checks, or error-specific validation. Possession of a token is a bearer capability within its acceptance context. It does not prove router identity, current path membership, or truth of every field of an error. The limitations in are part of the security model, not exceptions to be bypassed after a match.

Replay and Flow Reuse Key rotation bounds the time for which an observed token can be accepted; it does not prevent replay during that time. The same flow receives the same token within an epoch, and a token is not bound to an individual packet, ICMP Type/Code, or claimed MTU or gateway. An observer can transplant it among plausible quotations for that flow. Legitimate delayed or duplicated errors also need to be handled by ordinary protocol checks. Reusing an address/port tuple or an Echo Identifier during the acceptance window can expose a new communication instance to an old token-bearing report. The host MUST apply available checks on the current communication instance and MUST NOT interpret the token alone as evidence of a recent transmission in that instance. Shorter key lifetimes reduce, but do not eliminate, this issue. A packet-bound or single-use token design would require additional specification and potentially additional state; neither property is claimed here.

Resource Exhaustion and Availability Avoiding a per-challenge nonce cache removes one source of unbounded allocation. It does not eliminate parsing work, HMAC computation, trigger-state pressure, probabilistic false positives, or traffic disruption caused by repeated option insertion. The resource limits in are required parts of the mechanism, and their own accounting structures must be bounded. Receipt of an initial error produces no immediate packet and therefore no immediate challenge reflection. However, adding an option increases the byte count of an ordinary packet and can alter forwarding, generate subsequent errors, or contribute to application retransmissions. This document does not claim zero traffic overhead or immunity to all amplification or denial-of-service effects. Requiring confirmation can suppress legitimate network feedback during attack or failure. Availability and validation policy must be evaluated together. The mechanism provides no guarantee that communication progresses when confirmations are lost or filtered.

Shared Network State Route and PMTU state can be shared across flows. Requiring confirmation for one flow while allowing an unconfirmed report about another flow to change the same protected state can defeat the intended protection. A deployment MUST define its policy at the granularity of the state being protected and cover every ICMP processing path that can make that protected change. The presence of a valid token for one flow does not expand the scope of state that its error is permitted to modify under the ordinary protocol rules.

IANA Considerations This document requests a new entry in the IPv4 "IP Option Numbers" registry, following the applicable allocation procedures described in . The requested layout is:

Copy	Class	Number	Value	Name
0	0	TBD	TBD	Challenge-Confirm

The Option Length is 20 octets, as defined in . The registry reference would be this document. No option number is assigned by this draft, and the TBD value is not usable as an on-wire value. Controlled experiments can use the experimental IPv4 option code points allocated by , subject to the experimental-use guidance in . The code point matching Copy 0 and Class 0 is 30. An experiment using it must document its scope, configuration, and collision avoidance; a host MUST NOT interpret all uses of that shared experimental code point as Challenge-Confirm without the corresponding local experiment configuration. Such use does not allocate code point 30 exclusively to this mechanism or authorize unrestricted deployment.

References Normative References This RFC is an official specification for the Internet community. It incorporates by reference, amends, corrects, and supplements the primary protocol standards documents relating to hosts. [STANDARDS-TRACK] This memo describes a technique for dynamically discovering the maximum transmission unit (MTU) of an arbitrary internet path. It specifies a small change to the way routers generate one type of ICMP message. For a path that passes through a router that has not been so changed, this technique might not discover the correct Path MTU, but it will always choose a Path MTU as accurate as, and in many cases more accurate than, the Path MTU that would be chosen by current practice. [STANDARDS-TRACK] This document describes HMAC, a mechanism for message authentication using cryptographic hash functions. HMAC can be used with any iterative cryptographic hash function, e.g., MD5, SHA-1, in combination with a secret shared key. The cryptographic strength of HMAC depends on the properties of the underlying hash function. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Security systems are built on strong cryptographic algorithms that foil pattern analysis attempts. However, the security of these systems is dependent on generating secret quantities for passwords, cryptographic keys, and similar quantities. The use of pseudo-random processes to generate secret quantities can result in pseudo-security. A sophisticated attacker may find it easier to reproduce the environment that produced the secret quantities and to search the resulting small set of possibilities than to locate the quantities in the whole of the potential number space. Choosing random quantities to foil a resourceful and motivated adversary is surprisingly difficult. This document points out many pitfalls in using poor entropy sources or traditional pseudo-random number generation techniques for generating such quantities. It recommends the use of truly random hardware techniques and shows that the existing hardware on many systems can be used for this purpose. It provides suggestions to ameliorate the problem when a hardware solution is not available, and it gives examples of how large such quantities need to be for some applications. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Federal Information Processing Standard, FIPS RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References This memo provides guidance for the IANA to use in assigning parameters for fields in the IPv4, IPv6, ICMP, UDP and TCP protocol headers. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. When experimenting with or extending protocols, it is often necessary to use some sort of protocol number or constant in order to actually test or experiment with the new function, even when testing in a closed environment. For example, to test a new DHCP option, one needs an option number to identify the new function. This document recommends that when writing IANA Considerations sections, authors should consider assigning a small range of numbers for experimentation purposes that implementers can use when testing protocol extensions or other new features. This document reserves some ranges of numbers for experimentation purposes in specific protocols where the need to support experimentation has been identified. This document describes the format of a set of control messages used in ICMPv6 (Internet Control Message Protocol). ICMPv6 is the Internet Control Message Protocol for Internet Protocol version 6 (IPv6). [STANDARDS-TRACK] When experimenting with or extending protocols, it is often necessary to use some sort of protocol number or constant in order to actually test or experiment with the new function, even when testing in a closed environment. This document reserves some ranges of numbers for experimentation purposes in specific protocols where the need to support experimentation has been identified, and it describes the numbers that have already been reserved by other documents. [STANDARDS-TRACK] This document describes a robust method for Path MTU Discovery (PMTUD) that relies on TCP or some other Packetization Layer to probe an Internet path with progressively larger packets. This method is described as an extension to RFC 1191 and RFC 1981, which specify ICMP-based Path MTU Discovery for IP versions 4 and 6, respectively. [STANDARDS-TRACK] This document describes TCP SYN flooding attacks, which have been well-known to the community for several years. Various countermeasures against these attacks, and the trade-offs of each, are described. This document archives explanations of the attack and common defense techniques for the benefit of TCP implementers and administrators of TCP servers or networks, but does not make any standards-level recommendations. This memo provides information for the Internet community. This document discusses the use of the Internet Control Message Protocol (ICMP) to perform a variety of attacks against the Transmission Control Protocol (TCP). Additionally, this document describes a number of widely implemented modifications to TCP's handling of ICMP error messages that help to mitigate these issues. This document is not an Internet Standards Track specification; it is published for informational purposes. This document provides advice on the filtering of IPv4 packets based on the IPv4 options they contain. Additionally, it discusses the operational and interoperability implications of dropping packets based on the IP options they contain. The User Datagram Protocol (UDP) provides a minimal message-passing transport that has no inherent congestion control mechanisms. This document provides guidelines on the use of UDP for the designers of applications, tunnels, and other protocols that use UDP. Congestion control guidelines are a primary focus, but the document also provides guidance on other topics, including message sizes, reliability, checksums, middlebox traversal, the use of Explicit Congestion Notification (ECN), Differentiated Services Code Points (DSCPs), and ports. Because congestion control is critical to the stable operation of the Internet, applications and other protocols that choose to use UDP as an Internet transport must employ mechanisms to prevent congestion collapse and to establish some degree of fairness with concurrent traffic. They may also need to implement additional mechanisms, depending on how they use UDP. Some guidance is also applicable to the design of other protocols (e.g., protocols layered directly on IP or via IP-based tunnels), especially when these protocols do not themselves provide congestion control. This document obsoletes RFC 5405 and adds guidelines for multicast UDP usage. This document specifies Datagram Packetization Layer Path MTU Discovery (DPLPMTUD). This is a robust method for Path MTU Discovery (PMTUD) for datagram Packetization Layers (PLs). It allows a PL, or a datagram application that uses a PL, to discover whether a network path can support the current size of datagram. This can be used to detect and reduce the message size when a sender encounters a packet black hole. It can also probe a network path to discover whether the maximum packet size can be increased. This provides functionality for datagram transports that is equivalent to the PLPMTUD specification for TCP, specified in RFC 4821, which it updates. It also updates the UDP Usage Guidelines to refer to this method for use with UDP datagrams and updates SCTP. The document provides implementation notes for incorporating Datagram PMTUD into IETF datagram transports or applications that use datagram transports. This specification updates RFC 4960, RFC 4821, RFC 6951, RFC 8085, and RFC 8261.

Changes since -03

• Reframed the mechanism as supplemental validation against blind off-path forgery and clarified its relationship to existing TCP, UDP, and ICMP checks.
• Clarified that the key is host-local and that the initial error does not generate an immediate probe or a separate Echo Request.
• Defined token input encoding, bounded key acceptance, and the lack of per-packet uniqueness and single-use replay protection.
• Specified exact flow association, bounded trigger state, coalescing, expiry, and verification/insertion budgets.
• Distinguished validation of a new error from acceptance of the initial error and retained type-specific handling for PMTU, Redirect, and other errors.
• Corrected the IPv4 Option Length definition, specified a 20-octet layout and proposed Copy/Class bits, and clarified quotation parsing.
• Expanded discussion of packet size, fragmentation, no further traffic, multipath, option filtering, NATs, and tunnels; removed unconditional compatibility and DoS-resistance claims.

Acknowledgments The authors thank the IETF community, particularly participants in the Internet Area Working Group, for feedback on quoted-packet validation, challenge transmission, key handling, and multipath behavior. The discussion has helped clarify the scope and limitations of this proposal.