Last Modified: Apr 28, 2025
Affected Product(s):
BIG-IP APM, LTM
Known Affected Versions:
10.2.4, 11.0.0, 11.1.0, 11.2.0, 11.2.1, 11.3.0, 11.4.0, 11.4.1, 11.5.0, 11.5.1, 11.5.1 HF1, 11.5.1 HF2, 11.5.1 HF3, 11.5.1 HF4, 11.5.1 HF5, 11.5.1 HF6, 11.5.1 HF7, 11.5.1 HF8, 11.5.1 HF9, 11.5.1 HF10, 11.5.1 HF11, 11.5.2, 11.5.2 HF1, 11.6.0, 11.6.0 HF1, 11.6.0 HF2, 11.6.0 HF3, 11.6.0 HF4
Fixed In:
12.0.0, 11.6.0 HF5, 11.5.3, 11.4.1 HF9, 10.2.4 HF12
Opened: Jan 29, 2015 Severity: 3-Major Related Article:
K16662
According to RFC6347: 4.1.2.7. Handling Invalid Records: 'Unlike TLS, DTLS is resilient in the face of invalid records (e.g., invalid formatting, length, MAC, etc.). In general, invalid records SHOULD be silently discarded, thus preserving the association; however, an error MAY be logged for diagnostic purposes. Implementations which choose to generate an alert instead, MUST generate fatal level alerts to avoid attacks where the attacker repeatedly probes the implementation to see how it responds to various types of error. Note that if DTLS is run over UDP, then any implementation which does this will be extremely susceptible to denial-of-service (DoS) attacks because UDP forgery is so easy. Thus, this practice is NOT RECOMMENDED for such transports.' In the BIG-IP implementation, DTLS chooses to disconnect the session when it receives invalid record.
DTLS disconnects the session.
DTLS receives a bad record packet.
None.
The system now silently discards all of the invalid records and preserves the association. This is correct behavior.