750  DTLS Performance and Implementation

750.1 Learning Objectives

By the end of this chapter, you will be able to:

  • Benchmark DTLS Performance: Analyze handshake time, latency, memory, and CPU overhead across configurations
  • Optimize Session Management: Implement session resumption and Connection ID for efficient reconnection
  • Configure Replay Protection: Tune sliding window for high-loss networks
  • Apply Best Practices: Design production-ready DTLS deployments for IoT
TipMVU: Minimum Viable Understanding

Core concept: DTLS adds 10-20ms latency per packet but session resumption can reduce handshake overhead by 60%, critical for battery-powered devices.

Why it matters: Without optimization, DTLS handshakes drain battery faster than the actual data transmission.

Key takeaway: Always enable session caching, use Connection ID for mobile devices, and prefer PSK for constrained gateways managing many connections.

750.2 Prerequisites

Before diving into this chapter, you should be familiar with:

750.3 Performance Benchmarking

Test Setup: ESP32 (240 MHz), CoAP request (100 bytes)

Metric UDP (no security) DTLS 1.2 (PSK) DTLS 1.2 (Cert) DTLS 1.3 (PSK)
Handshake Time N/A 450 ms 1200 ms 250 ms
Per-packet Latency 5 ms 15 ms 15 ms 12 ms
Throughput 1200 msg/s 950 msg/s 950 msg/s 1000 msg/s
Memory (RAM) 2 KB 18 KB 45 KB 22 KB
Code Size (Flash) 50 KB 180 KB 250 KB 200 KB
CPU per packet 0.5% 3% 3% 2.5%

Analysis: - Handshake: DTLS 1.3 is 44% faster than DTLS 1.2 - Certificates: 2.5x slower handshake than PSK (but better scalability) - Runtime overhead: DTLS adds 10ms latency (acceptable for most IoT) - Memory: DTLS requires 9x more RAM than unencrypted UDP

Recommendation for IoT: - Resource-constrained (< 32 KB RAM): PSK mode - Enterprise (> 128 KB RAM): Certificate mode - Firmware: Upgrade to DTLS 1.3 when available (faster, more secure)

750.4 Implementation Best Practices

750.4.1 Session Resumption

Problem: DTLS handshake costs 450ms + 10 UDP packets (battery drain)

Solution: Resume previous session

Mermaid diagram

Mermaid diagram
Figure 750.1: DTLS Session Resumption Optimization showing two handshake phases: initial full handshake (3-RTT) where client sends ClientHello, server responds with HelloVerifyRequest for cookie verification, client retransmits ClientHello with cookie, server sends ServerHello with Certificate and assigns SessionID, client completes key exchange and both parties store session state including master secret; later reconnection uses fast session resumption (1-RTT) where client includes previous SessionID in ClientHello, server recognizes cached session and reuses stored master secret avoiding expensive public key cryptography, responds with ServerHello including same SessionID plus ChangeCipherSpec and Finished, client sends ChangeCipherSpec and Finished, both parties immediately ready for encrypted application data; session resumption provides 68% reduction in transmitted data for PSK mode, 100-150ms lower latency compared to full handshake, significant battery life extension for IoT devices making frequent short connections.

Savings: - Handshake time: 450ms -> 200ms - Packets sent: 10 -> 4 - Battery drain: 60% reduction

Implementation:

// mbedTLS example
mbedtls_ssl_conf_session_cache(&conf, &cache,
                               mbedtls_ssl_cache_get,
                               mbedtls_ssl_cache_set);
// Cache sessions for 1 hour
mbedtls_ssl_cache_set_timeout(&cache, 3600);

750.4.2 Connection ID Extension (RFC 9146)

Problem: IoT devices change IP addresses (NAT rebinding, mobile handoff)

Traditional DTLS:

Session tied to: (Client IP, Client Port, Server IP, Server Port)
IP changes -> Session invalidated -> Must re-handshake

Connection ID:

Session tied to: Connection ID (random 4-byte value)
IP changes -> Session persists!

Use case: Mobile sensor moving between Wi-Fi APs

750.4.3 Replay Window Tuning

Default: 64-packet sliding window

Problem: High packet loss (Wi-Fi in motion) -> legitimate packets rejected as “too old”

Solution: Increase window size

// mbedTLS
mbedtls_ssl_conf_dtls_anti_replay(&conf, MBEDTLS_SSL_ANTI_REPLAY_ENABLED);
mbedtls_ssl_conf_dtls_badmac_limit(&conf, 100); // Allow 100 bad MACs before abort

Trade-off: Larger window = more memory, but tolerates more loss.

750.5 Worked Examples

NoteWorked Example: Calculating DTLS Session Memory Requirements for a Gateway

Scenario: You are designing an IoT gateway for a smart factory that needs to maintain simultaneous DTLS connections to 150 sensors. The gateway has 512 KB RAM available for DTLS operations. You need to determine whether to use PSK or certificate-based authentication.

Given: - Number of sensors: 150 - Available RAM: 512 KB - PSK mode memory per session: ~1.5 KB (32-byte PSK + 1 KB session state + 512 bytes crypto context) - Certificate mode memory per session: ~5 KB (2-4 KB certificate storage + 1 KB session state + 512 bytes crypto context) - Session cache overhead: 64 bytes per cached session

Steps:

  1. Calculate memory for PSK mode with all active sessions:

    Active sessions: 150 x 1.5 KB = 225 KB
Session cache: 150 x 64 bytes = 9.6 KB
Total PSK: 225 + 9.6 = 234.6 KB

  2. Calculate memory for certificate mode with all active sessions:

    Active sessions: 150 x 5 KB = 750 KB
Session cache: 150 x 64 bytes = 9.6 KB
Total Certificates: 750 + 9.6 = 759.6 KB

  3. Compare against available RAM (512 KB):

    PSK mode: 234.6 KB < 512 KB (fits with 277 KB headroom)
Certificate mode: 759.6 KB > 512 KB (exceeds by 248 KB)

  4. Calculate maximum concurrent certificate sessions possible:

    Max sessions = (512 KB - overhead) / 5 KB = 100 sessions approx
Need: 150 sessions -> Would require session rotation

Result: Use PSK mode for this deployment. It requires 234.6 KB RAM, leaving 277 KB headroom for other gateway functions. Certificate mode would exceed available memory by 48%.

Key Insight: PSK authentication uses approximately 70% less memory than certificate-based authentication, making it the preferred choice for resource-constrained gateways managing many concurrent connections. The trade-off is reduced scalability and manual key provisioning compared to PKI-based systems.

NoteWorked Example: Analyzing DTLS Handshake Latency Impact on Battery Life

Scenario: A battery-powered environmental sensor sends data to a cloud server every 60 seconds using CoAP over DTLS. The sensor’s battery capacity is 2000 mAh at 3.3V. You need to calculate the battery life difference between full handshake every connection versus using session resumption.

Given: - Reporting interval: 60 seconds (1,440 connections per day) - Full DTLS 1.2 handshake: 6 packets, 450ms total, radio at 25mA during TX/RX - Session resumption: 2 packets, 200ms total - Data transmission: 2 packets, 50ms - Sleep current: 10 uA - Active current (CPU): 15mA for packet processing (100ms per connection) - Battery: 2000 mAh, 3.3V

Steps:

  1. Calculate daily energy for full handshake mode:

    Per connection:
- Handshake radio: 25mA x 450ms = 11.25 mAs
- Data radio: 25mA x 50ms = 1.25 mAs
- CPU active: 15mA x 100ms = 1.5 mAs
Total per connection: 14 mAs

Daily:
- Connections: 1,440 x 14 mAs = 20,160 mAs = 5.6 mAh
- Sleep: 10 uA x 24h = 0.24 mAh
- Total: 5.84 mAh/day

  2. Calculate daily energy with session resumption:

    Per connection:
- Resumption radio: 25mA x 200ms = 5 mAs
- Data radio: 25mA x 50ms = 1.25 mAs
- CPU active: 15mA x 80ms = 1.2 mAs (faster processing)
Total per connection: 7.45 mAs

Daily:
- Connections: 1,440 x 7.45 mAs = 10,728 mAs = 2.98 mAh
- Sleep: 0.24 mAh
- Total: 3.22 mAh/day

  3. Calculate battery life for each mode:

    Full handshake: 2000 mAh / 5.84 mAh/day = 342 days
Session resumption: 2000 mAh / 3.22 mAh/day = 621 days

  4. Calculate improvement:

    Battery life improvement: 621 - 342 = 279 additional days
Percentage improvement: (621 - 342) / 342 x 100 = 82% longer battery life

Result: Enabling session resumption extends battery life from 342 days to 621 days, an 82% improvement (nearly doubling the operational lifetime).

Key Insight: DTLS session resumption provides dramatic battery savings for frequently-connecting IoT devices. The 250ms saved per connection (450ms to 200ms) accumulates to massive energy savings over thousands of daily connections. Always enable session caching on battery-powered devices, and consider using DTLS 1.3 for even faster handshakes.

750.7 Summary

DTLS Fundamentals: - Purpose: TLS security for UDP applications - Use cases: CoAP, VoIP, WebRTC, real-time telemetry - Trade-off: Adds 10-20ms latency for encryption

Security Features: - Encryption: AES-GCM, ChaCha20 - Authentication: PSK (simple) or Certificates (scalable) - Replay protection: Sequence numbers + sliding window - DoS protection: Cookie mechanism

Performance: - DTLS 1.3: 44% faster handshake than 1.2 - Session resumption: 60% battery savings - PSK vs Certs: PSK uses 70% less memory

Best Practices: - Enable session caching for battery-powered devices - Use Connection ID for mobile IoT - Choose PSK for small deployments, certificates for scale - Tune replay window for high-loss networks

DTLS makes real-time, secure IoT applications possible without the latency penalty of TCP.

750.8 What’s Next?

Continue to Transport Fundamentals to explore how transport layer protocols (TCP, UDP, QUIC) form the backbone of IoT communication, building on the security concepts you’ve learned here.