Skip to main content

8. Security Considerations

The security considerations for UDP and SCTP are provided in the referenced RFCs.

8.1. Probing Frequency Control​

To avoid excessive load, the interval between individual probe packets MUST be at least one RTT, and the interval between rounds of probing is determined by the PMTU_RAISE_TIMER.

8.2. Probe Packet Confirmation Protection​

The PL sender needs to ensure that the method used to confirm reception of probe packets is able to protect from off-path attackers injecting packets into the path. This protection is provided in IETF-defined protocols (e.g., TCP, SCTP) using a randomly initialized sequence number. Section 5.1 of [BCP145] provides a description of one way to do this when using UDP.

8.3. PTB Message Validation​

There are cases where Packet Too Big (PTB) messages are not delivered due to policy, configuration, or equipment design (see Section 1.1). This method therefore does not rely upon reception of PTB messages but is able to utilize them when they are received by a sender.

PTB Message Attack Protection​

PTB messages could be used to cause a node to inappropriately reduce the PLPMTU. A node supporting DPLPMTUD MUST appropriately validate the payload of PTB messages to ensure these are received in response to datagrams actually sent by the PL layer (i.e., correspond to an error condition experienced for a datagram actually sent, see Section 4.6.1).

On-Path Attack Mitigation​

An on-path attacker able to create PTB messages could forge PTB messages that include a valid quoted IP packet. Such an attack could be used to reduce the PLPMTU. An on-path device could similarly force a reduction in the PLPMTU by implementing a policy to drop packets larger than a configured size.

Mitigation Methods:

  1. Baseline Protection: Ensure that a PL sender never reduces the PLPMTU below the base size solely in response to reception of a PTB message. This is achieved by first entering the BASE state when such a message is received.

  2. Probe Validation: Designed to not require processing of PTB messages; a PL sender can suspend processing of PTB messages (e.g., in a robustness mode after detecting that subsequent probing actually confirms that a size larger than the PTB_SIZE is supported by the path).

8.4. Denial of Service Protection​

Processing Overhead Limitation​

Parsing the quoted packet inside a PTB message can introduce additional per-packet processing at the PL sender. This processing SHOULD be limited to avoid a denial-of-service attack when arbitrary headers are present. Rate-limiting processing could result in the PL not receiving PTB messages; however, the DPLPMTUD method is robust to such loss.

ICMP Message Processing​

Successful processing of an ICMP message can trigger a probe when the reported PTB size is valid, but this does not directly update the PLPMTU for a path. This prevents messages that attempt to black-hole data by indicating a size larger than supported by the path.

8.5. Path Information Instability​

Information about a path can be unstable. This could be a result of forwarding across multiple paths with different actual PMTUs or a single path presenting a varying PMTU.

Mitigation: The design of a DPLPMTUD implementation SHOULD consider how to mitigate the effects of varying path information. One possible mitigation is to provide robustness (see Section 5.4) in the method to avoid oscillation in the MPS.

8.6. Padding Data Security​

The DPLPMTUD method can introduce padding data to inflate the length of the datagram to the total size required for a probe packet. The total size of a probe packet includes all headers and padding added to the payload data being sent (e.g., including security-related fields such as AEAD tags and TLS record layer padding). The value of the padding data does not affect the DPLPMTUD search algorithm and therefore needs to be set in a way consistent with the policy of the PL.

Encryption Protection Requirements​

If the PL is able to use a cryptographic confidentiality or data-integrity mechanism, the design ought to avoid adding anything to DPLPMTUD probe packets (e.g., padding) that is not also protected by these cryptographic mechanisms.

8.7. Security Best Practices Summary​

  1. Validate All PTB Messages: Validate the origin and content of PTB messages before use
  2. Limit Processing Rate: Prevent resource exhaustion from PTB message processing
  3. Protect Probe Confirmation: Use identifiers that are difficult to guess
  4. Encrypt Padding Data: Ensure all data in probe packets is protected by encryption
  5. Monitor Path Stability: Detect and respond to unusual changes in path information
  6. Implement Rate Limiting: Control the frequency of sending probe packets

These security considerations ensure that DPLPMTUD can operate safely and reliably, even in the presence of malicious attackers.

Last updated on