Enhancing ICMP Error Message Validation Using a Challenge-Confirm Mechanism

3.1. 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 [RFC8085] 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 [RFC4443] 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 [RFC5927]. 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.¶

3.2. 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 [RFC792] 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.¶

5.1. 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 Section 5.6. 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.¶

Validating host                         Router or destination
      |                                          |
      |----------- Ordinary packet ------------->|
      |<---------- 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  |

5.2. 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.¶

5.3. Token Construction and Key Lifetime

The validating host generates an independent 256-bit secret key using a cryptographically secure random source consistent with [RFC4086]. 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 [RFC2104] [RFC6234]:¶

Token = first_16_octets(HMAC-SHA-256(K, Label || Flow_ID))

Label = ASCII("ICMP-CC-IPv4-v1")    ; no terminating NUL

Flow_ID = Source_Address          ; 4 octets
       || Destination_Address     ; 4 octets
       || Protocol                ; 1 octet
       || Selector_1              ; 2 octets
       || Selector_2              ; 2 octets

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 Section 6 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.¶

5.4. 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 Section 7. 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 Section 5.6, 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.¶

5.5. 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 Section 6. 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 Section 8.4.¶

5.6. 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.¶

7.1. Fragmentation Needed

For Type 3, Code 4, the host processes the newly received report according to its applicable PMTU validation rules and [RFC1191]. 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 [RFC4821] and Datagram PLPMTUD [RFC8899] 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.¶

7.2. 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 [RFC8085].¶

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.¶

7.3. Redirect

For Type 5, the host MUST retain its ordinary Redirect validation and local policy. Section 3.2.2.2 of [RFC1122] 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.¶

7.4. 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.¶

8.1. 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.¶

8.2. 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.¶

8.3. 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. [RFC7126] 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.¶

8.4. 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 Section 5.5 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.¶

8.5. 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.¶

8.6. 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.¶

9.1. 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 Section 4 are part of the security model, not exceptions to be bypassed after a match.¶

9.2. 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.¶

9.3. 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 Section 5.6 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.¶

9.4. 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.¶

11.1. Normative References

[RFC791]

Postel, J., "Internet Protocol", STD 5, RFC 791, DOI 10.17487/RFC791, September 1981, <https://www.rfc-editor.org/rfc/rfc791>.

[RFC792]

Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, DOI 10.17487/RFC792, September 1981, <https://www.rfc-editor.org/rfc/rfc792>.

[RFC1122]

Braden, R., Ed., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, DOI 10.17487/RFC1122, October 1989, <https://www.rfc-editor.org/rfc/rfc1122>.

[RFC1191]

Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, DOI 10.17487/RFC1191, November 1990, <https://www.rfc-editor.org/rfc/rfc1191>.

[RFC2104]

Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, DOI 10.17487/RFC2104, February 1997, <https://www.rfc-editor.org/rfc/rfc2104>.

[RFC2119]

Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/rfc/rfc2119>.

[RFC4086]

Eastlake 3rd, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, DOI 10.17487/RFC4086, June 2005, <https://www.rfc-editor.org/rfc/rfc4086>.

[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, <https://www.rfc-editor.org/rfc/rfc6234>.

[RFC8174]

Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

11.2. Informative References

[CCS2020IPID]

Feng, X., Fu, C., Li, Q., Sun, K., and K. Xu, "Off-path TCP exploits of the mixed IPID assignment", ACM SIGSAC Conference on Computer and Communications Security CCS, 2020.

[NDSS2022MTU]

Feng, X., Li, Q., Sun, K., Xu, K., Liu, B., Zheng, X., Yang, Q., Duan, H., and Z. Qian, "PMTUD is not Panacea: Revisiting IP Fragmentation Attacks against TCP", Network and Distributed System Security Symposium NDSS, 2022.

[RFC2780]

Bradner, S. and V. Paxson, "IANA Allocation Guidelines For Values In the Internet Protocol and Related Headers", BCP 37, RFC 2780, DOI 10.17487/RFC2780, March 2000, <https://www.rfc-editor.org/rfc/rfc2780>.

[RFC3692]

Narten, T., "Assigning Experimental and Testing Numbers Considered Useful", BCP 82, RFC 3692, DOI 10.17487/RFC3692, January 2004, <https://www.rfc-editor.org/rfc/rfc3692>.

[RFC4443]

Conta, A., Deering, S., and M. Gupta, Ed., "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", STD 89, RFC 4443, DOI 10.17487/RFC4443, March 2006, <https://www.rfc-editor.org/rfc/rfc4443>.

[RFC4727]

Fenner, B., "Experimental Values In IPv4, IPv6, ICMPv4, ICMPv6, UDP, and TCP Headers", RFC 4727, DOI 10.17487/RFC4727, November 2006, <https://www.rfc-editor.org/rfc/rfc4727>.

[RFC4821]

Mathis, M. and J. Heffner, "Packetization Layer Path MTU Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007, <https://www.rfc-editor.org/rfc/rfc4821>.

[RFC4987]

Eddy, W., "TCP SYN Flooding Attacks and Common Mitigations", RFC 4987, DOI 10.17487/RFC4987, August 2007, <https://www.rfc-editor.org/rfc/rfc4987>.

[RFC5927]

Gont, F., "ICMP Attacks against TCP", RFC 5927, DOI 10.17487/RFC5927, July 2010, <https://www.rfc-editor.org/rfc/rfc5927>.

[RFC7126]

Gont, F., Atkinson, R., and C. Pignataro, "Recommendations on Filtering of IPv4 Packets Containing IPv4 Options", BCP 186, RFC 7126, DOI 10.17487/RFC7126, February 2014, <https://www.rfc-editor.org/rfc/rfc7126>.

[RFC8085]

Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, March 2017, <https://www.rfc-editor.org/rfc/rfc8085>.

[RFC8899]

Fairhurst, G., Jones, T., Tüxen, M., Rüngeler, I., and T. Völker, "Packetization Layer Path MTU Discovery for Datagram Transports", RFC 8899, DOI 10.17487/RFC8899, September 2020, <https://www.rfc-editor.org/rfc/rfc8899>.

[SP2023MITM]

Feng, X., Li, Q., Sun, K., Yang, Y., and K. Xu, "Man-in-the-middle attacks without rogue AP: When WPAs meet ICMP redirects", IEEE Symposium on Security and Privacy SP, 2023.

[USENIXSECURITY2023ICMP]

Feng, X., Li, Q., Sun, K., Qian, Z., Fu, C., Zhao, G., Kuang, X., and K. Xu, "Off-Path Network Traffic Manipulation via Revitalized ICMP Redirect Attacks", USENIX Security Symposium Security, 2023.