Home / Cisco R&S / Introduction to DTLS/TLS tunnels

Introduction to DTLS/TLS tunnels

DTLS is a protocol built on TLS that is proficient of securing the datagram transport. DTLS is compatible for securing applications and services that are delay-sensitive tunnelling applications such as VPNs, and applications that incline to run out of file descriptors or socket buffers.

DTLS support that delivers security for remote connections and hastens efficiency for multiple applications and services. Merging secure access control and optimization for numerous protocols and application categories onto a specific platform reduces risk and combines infrastructure while certifying Quality of Service (QoS), mainly for delay-sensitive amenities such as voice traffic.

Note: TLS uses TCP, and DTLS uses UDP, so all the classic differences apply. UDP communications exist as streams of packets with no ordering, delivery reliability, or flow control. Applications that use datagram protocols need to make sure they can handle these concerns internally.

DTLS additional types are abstractly ingresses from TCP flung over a normal TLS (the one important oversight is the lack of admit messages). The protocol is further kind with esteems to changes, and does not comprise a confirmed transmission (but DTLS is believed to be active in frameworks where this would not actually make sense anyway).
Fig 1.1- TLS Tunnel Protocol Sequences

The domain of application of DTLS is really different from that of TLS. It is meant to be applied to data streaming applications where losses are less significant than latency, e.g. VoIP or live video feeds. For a given application, either TLS makes much more sense than DTLS, or the opposite; best practice is to choose the suitable protocol.

How it works?
  • SSL Tunnel is the TCP tunnel that is first created to the Firewall
  • When it is entirely established, the client will then try to exchange a UDP DTLS Tunnel
  • During DTLS conciliation, traffic will be transmitted over TLS tunnel
  • When the DTLS Tunnel is fully recognised, all data now transfers to the DTLS tunnel and the SSL tunnel is only used for infrequent control channel traffic
  • In case of catastrophes in creating DTLS Tunnel, traffic will remain passing over TLS tunnel
  • After creating DTLS, in the event of catastrophe in DTLS Tunnel, traffic will have authorised over TLS tunnel till DTLS tunnel is restored 

How Data is Forwarded?
  • For every packet there is a percentage in AnyConnect client code which takes whether to direct the packet over TLS or DTLS
  • If the DTLS tunnel is known, the code will pick to progressing the packet over DTLS and lead encryption
  • If the DTLS is inflexible, the code will pick to advancing the packet over TLS and lead encryption
  • The main fact is the efficiency of DTLS tunnel 
  • Since DTLS is built on UDP, it is unpredictable and there is no flow control to agree its efficiency
  • For getting Firewall with strong DTLS and TLS, it will response base on the receipt tunnel, i.e. if packets acknowledged over TLS, the reply will be over TLS even if DTLS is strong.
What about Idle timeout?

When a DTLS Tunnel is functioning, that is the only tunnel where idle timeout stuffs, since very slight control channel traffic permits over the SSL Tunnel, it is roughly eternally idle so it is relieved while there is a functional DTLS Tunnel. If somewhat occurred to UDP and the DTLS Tunnel was dragged down, then idle timeout would affect to the SSL Tunnel