diff options
author | Ingela Anderton Andin <[email protected]> | 2017-08-10 17:05:42 +0200 |
---|---|---|
committer | Ingela Anderton Andin <[email protected]> | 2017-08-14 10:59:55 +0200 |
commit | 6bd79e8f543da4777ba872a0edeaae8a9a90d5a8 (patch) | |
tree | 1262f7f23b91637e0f4c69eaf5a5680044925621 /erts/test | |
parent | 6b293df5e86e85b255d3ccf55f83bd847867679f (diff) | |
download | otp-6bd79e8f543da4777ba872a0edeaae8a9a90d5a8.tar.gz otp-6bd79e8f543da4777ba872a0edeaae8a9a90d5a8.tar.bz2 otp-6bd79e8f543da4777ba872a0edeaae8a9a90d5a8.zip |
dtls: Customize alert handling for DTLS over UDP
From RFC 6347:
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.
Diffstat (limited to 'erts/test')
0 files changed, 0 insertions, 0 deletions