Datagram Transport Layer Service - DTLS

This week’s post highlights some of the features and implementation specifics regarding the Datagram Transport Layer Service (DTLS) protocol used in Virtual Private Networks with the Cisco AnyConnect^® SSL client. I’ll provide some background as well as some screenshots and supported CLI commands.

Historically, DTLS could be said to be celebrating its 5-year anniversary. As discussed in The Design and Implementation of Datagram TLS and RFC4347 — Datagram Transport Layer Security, the original draft of the Datagram Transport Layer Security document was written in April of 2006. These documents show that the protocol was designed to enable more streamlined transmission (i.e. lower overhead) than using TCP-based TLS or IPSec as well as only requiring one UDP port-to-port channel. Secondly, as one of the authors of both the paper and the RFC stated in IETF 61 NSIS Meeting presentation on DTLS, DTLS is well-suited for applications such as SNMP, SIP, streaming audio/video, and even on-line gaming!

Support for DTLS first arrived in ASA release 8.0(2) some three years ago; however for the IOS this has just recently been added in IOS^® 15.1(2)T. The supported syntax is shown below:

svc dtls

To enable Datagram Transport Layer Security (DTLS) support on the Cisco IOS Secure Socket Layer Virtual Private Network (SSL VPN), use the svc dtls command in WebVPN group policy configuration mode. To disable the configuration, use the no form of this command.

svc dtls

no svc dtls

Syntax Description

This command has no arguments or keywords.

Command Default

DTLS is enabled by default on the Cisco ISR G2 series routers (3900, 2900, 1900, 890, and 880) and is disabled on other routers.

Command Modes

WebVPN group policy configuration (config-webvpn-group)

Command History

Release	Modification
15.1(2)T	This command was introduced.

A Wireshark^® trace below illustrates that in a typical SSL implementation the use of DTLS occurs shortly after the initial TLS handshake is performed. Note that the decoded capture does not explicitly identify the packets as DTLS; consequently, the exchange mechanisms mentioned in both the draft document and RFC are not explicitly shown.

Some implementation details are worth mentioning here and will be expanded upon in future posts:

• DTLS is unsupported on the End-of-Sale VPN Concentrator


• The use of DTLS on an ASA platform requires that Dead Peer Detection be enabled.

As far as the first item, the VPN Concentrator only supported the SSL VPN Client version 1.0. This product was issued before the formulation of the DTLS standard. Another post will focus on the use of the Dead Peer Detection, which in this case is required so that a “fallback” to TCP-based TLS can be used if an unreliable link is detected.