Bug ID 503741: DTLS session should not be closed when it receives a bad record.

Last Modified: Apr 10, 2019

Bug Tracker

Affected Product:  See more info
BIG-IP APM, LTM(all modules)

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 HF10, 11.5.1 HF11, 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.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 AskF5 Article:
K16662

Symptoms

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.

Impact

DTLS disconnects the session.

Conditions

DTLS receives a bad record packet.

Workaround

None.

Fix Information

The system now silently discards all of the invalid records and preserves the association. This is correct behavior.

Behavior Change