aboutsummaryrefslogtreecommitdiffstats
path: root/lib/sasl/info
diff options
context:
space:
mode:
authorIngela Anderton Andin <[email protected]>2017-08-10 17:05:42 +0200
committerIngela Anderton Andin <[email protected]>2017-08-14 10:59:55 +0200
commit6bd79e8f543da4777ba872a0edeaae8a9a90d5a8 (patch)
tree1262f7f23b91637e0f4c69eaf5a5680044925621 /lib/sasl/info
parent6b293df5e86e85b255d3ccf55f83bd847867679f (diff)
downloadotp-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 'lib/sasl/info')
0 files changed, 0 insertions, 0 deletions