Datagram Transport Layer Security (DTLS)

.

Introduction

The DTLS protocol ([RFC 6347]) is based on TLS protocol to provide similar security for the network traffic transported on datagram transport protocols (e.g. UDP). Usually the real time applications like media streaming and internet telephony are delay sensitive for the transported data so they use datagram transport to carry their data. DTLS  runs on UDP to secure the data in a transparent way (inserted between the application layer and transport layer). DTLS runs in application space without any kernel modifications. The DTLS preserves the in-order delivery of data which is not provided by the datagram transport. Current version of DTLS is 1.2

Why DTLS and NOT TLS for Datagram Transport

The answer is simply because using datagram transport like UDP means the packets could be lost or reordered and TLS cannot handle this (this is handled by TCP when it is used). So we take the TLS and add minimal changes to fix the unreliability problem and we call the result DTLS.

WhyDTLSMore specifically, the problems that are in TLS if datagram transport are used:

  • In TLS there is what is called integrity check which depends on the sequence number. For example record N is lost –> then the integrity check on record N+1 will fail because the wrong sequence number. The sequence numbers are implicit in the records. The record could also reach but in a wrong order. For example record N+1 reached before the record N.
  • The record could reach many times (replayed).
  • The TLS handshake will break if the handshake messages are lost.
  • Handshake message size is big (many kilobytes): as we know in UDP, datagrams are limited to 1500 bytes.

So the goal is changing TLS to solve the above problems and then we get DTLS. Briefly DTLS solves the problems by:

  • Banning the stream ciphers to make the records independent (don’t have the same cryptographic context – cipher key).
  • Adding explicit sequence numbers in the records.
  • Using retransmission timer for packet loss handling.
  • Handshake message fragmentation –> Each DTLS handshake message must contain fragment offset and fragment length.
  • Maintaining a bitmap window of received records so if a record is previously received it will be discarded.

The client automatically generates self-signed certificates for each peer. This means there is no certificate chain verification. The certificates themselves cannot be used to authenticate the peer because they are self-signed. So the DTLS provides encryption and integrity, but let the authentication to be done by the application.

Library Support For DTLS 1.2

Botan, GnuTLS, MatrixSSL, OpenSSL, wolfSSL


Advertisements

WebSocket as a Transport for SIP

.

Here I just want to write a few words that summarize the RFC 7118:

globe

  • The WebSocket protocol enables message exchange between clients and servers on top of a persistent TCP connection

  • The connection is optionally secured with TLS

  • The WebSocket handshake is based on HTTP and uses the HTTP GET method with an Upgrade request → HTTP 101 response on success .

  • During the connection handshake, the client and server agree on the application-level protocol on top of Websocket transport (Websocket subprotocol) -In this document it is SIP

  • Websocket messages can be sent in either UTF-8 text frames or binary frames. SIP allows both. UTF-8 is recommended for Javascript and WebSocket API

  • Each SIP message must be carried in a single WebSocket message and the WebSocket message contains only one SIP message → simplifies the SIP message parsing – no need for message boundaries (Content-Length header)

  • “ws” is used for plain websocket connections and “wss” for secure Websocket connections. These are for “via” transport parameter and SIP URI transport parameter

  • The SIP WebSocket server may decide not to add the parameter “received” in the top via header. The Client must accept the responses without this parameter

  • The SIP webSocket client is not manadated to implement support of UDP and TCP.

  • “SIP+D2W” DNS NAPTR service value for plain Websocket connections and “SIPS+D2W” for secure websocket connections.

  • The authentication can be on SIP level or Web level (token/cookie is used) – Appendix A

  • Using GRUU is valuable here (must be implemented on the client and server)

  • The Contact URI provided by SIP UAs is not used for routing requests to those UAs.

  • When SIP WebSocket server behaves as edge outbound proxy (Outbound + Path support), the proxy performs loose routing and remains in the path.


More Information