DTLS Session Establishment
The DTLS protocol is based on the TLS protocol. TLS is the most widely deployed protocol for securing network traffic. It defines four record protocols:
■ The handshake protocol: Used to negotiate security parameters and authenticate
■ The change cipher spec protocol: Triggers to enable the encryption that has been negotiated by the handshake protocol
■ The application data protocol: Used to transport actual data that has been encrypted
■ The alert protocol: Notifies if something went wrong (such as an invalid certificate)
Figure 4-8 CAPWAP Discovery Response Packet
TLS must run over a reliable transport channel—typically Transport Control Protocol (TCP). Therefore, it cannot secure unreliable datagram traffic such as User Datagram Protocol (UDP), which is exactly where DTLS kicks in. The basic design philosophy of DTLS is to construct "TLS over datagram." CAPWAP uses all those functions from DTLS/TLS.
Therefore, right after the optional discovery request/response sequence, the first step is establishing a secure CAPWAP connection in the same manner as in a normal DTLS session. Figure 4-9 shows the complete DTLS handshake.
Step 1. ClientHello: The client (in the CAPWAP scenario, it’s the AP) is sending in the client hello a list from all its supported cryptographic algorithms as well a random value that is used later to calculate the key material used for the CAPWAP encryption.
Step 2. HelloVerifyRequest/ClientHello (with cookie): Upon receiving the client hello, a stateless cookie exchange happens to prevent denial of service (DoS) attacks (required because it runs over UDP).
Step 3. ServerHello/Certificate: The server (in the CAPWAP scenario, it is the WLC) selects the cryptographic algorithm from the provided list and replies together with its certificate and a random value to the client (AP).
Step 4. Certificate/ClientKeyExchange/ChangeCipherSpec: Upon cipher suite negotiation and certificate validation, the client (AP) sends the ClientKeyExchange followed by the ChangeCipherSpec record protocol. ChangeCipherSpec notifies the other party that all subsequent records will be encrypted by the just-negotiated ciphers and key material.
Step 5. Server-ChangeCipherSpec: The server responds with a ChangeCipherSpec, which means that from now on, records sent in both directions are encrypted. The DTLS session is now fully established.
Figure 4-9 DTLS Session Establishment
Example 4-1 shows debug dtls trace enable on the controller, from which you can see the progress on the DTLS-handshake. The relevant parts to match the DTLS session flow in Figure 4-9 are highlighted in the debug output.
Example 4-1 DTLS Debugs Taken on a Controller
Example 4-1 DTLS Debugs Taken on a Controller
Example 4-1 DTLS Debugs Taken on a Controller
Example 4-1 DTLS Debugs Taken on a Controller
Example 4-1 DTLS Debugs Taken on a Controller
