DTLS Listeners

DTLS Listeners add TLS-style encryption and authentication to UDP applications without changing the datagram transport model. Clients establish a DTLS 1.2 or DTLS 1.3 session with the Listener's assigned domain and port. Proxylity decrypts authenticated application data and delivers the plaintext payload to your configured Destinations. Responses from your application are encrypted and sent back through the same DTLS session.

When to Use DTLS

Choose a DTLS Listener when your application already supports DTLS or needs encrypted UDP transport while preserving datagram boundaries. Common examples include RADIUS, IoT protocols, real-time telemetry, and custom request-response protocols that cannot use a stream-oriented TLS connection.

DTLS is also the first transport layer on Proxylity's roadmap to WebRTC Data Channels. DTLS Listeners are available today for native DTLS clients; SCTP and WebRTC signaling are separate layers and are not provided by a DTLS Listener.

DTLS, UDP, and WireGuard

Authentication Options

Server Certificate

Every DTLS Listener receives a server certificate and private key managed by Proxylity. The certificate identifies the Listener's assigned endpoint and is returned through the DtlsServerCertificate CloudFormation attribute. Distribute that certificate or its trust anchor according to your client application's trust model.

Change CertRefreshToken when you need CloudFormation to generate a new Listener certificate. Certificate rotation changes the certificate clients see, so coordinate trust updates before rotating production endpoints.

Pre-Shared Keys

For clients that use DTLS-PSK, configure the Psks map. Each map key is the client identity sent during the handshake, and each value is the corresponding base64-encoded key. Store PSK values in AWS Secrets Manager or another protected source rather than committing them to a template.

Cookie Protection

Set RequireCookies to require the DTLS cookie exchange before the Listener performs the full handshake. Cookies help confirm that a client can receive packets at its claimed source address and reduce amplification and resource-exhaustion risk. Enabling cookies adds one round trip to a new session. It is recommended for public endpoints.

Session Resumption and 0-RTT

DTLS 1.3 clients receive an encrypted session ticket after completing a handshake. A client can present that ticket on a later connection to resume the session with fewer handshake messages. Ticket encryption keys are managed per Listener and are not exposed through CloudFormation.

Set AllowEarlyData to "true" to let a resumed DTLS 1.3 client send application data with its first flight. Early data reduces latency, but applications must treat it as replayable even though Proxylity applies a shared anti-replay filter. Enable it only for idempotent operations such as telemetry updates; do not use 0-RTT for one-time commands, financial operations, or other actions that cannot safely be repeated.

EarlyDataWindowSeconds controls both the ticket lifetime and the replay-filter window. It defaults to 3600 seconds and accepts values from 1 through 604800 seconds (seven days). DTLS 1.2 clients do not use session tickets or 0-RTT.

DTLS 1.2 Connection IDs

DTLS 1.2 clients that support Connection IDs (CID) can identify an established session independently of the client's IP address and UDP port. This allows a session to continue across NAT rebinding, source-port changes, and transitions between access networks without performing a new handshake.

CID is particularly valuable for low-power IoT devices. Reusing an established session avoids additional radio time, cryptographic work, and handshake latency after a device wakes, changes networks, or receives a new NAT mapping. Clients that do not negotiate CID continue to use standard DTLS 1.2 sessions identified by their network endpoints.

CID support must be present in the client DTLS implementation and negotiated during the handshake. Basic connectivity tools such as openssl s_client may not negotiate DTLS 1.2 CID.

CloudFormation Configuration

Create a DTLS Listener with Custom::ProxylityUdpGatewayListener and set Protocols to dtls. DTLS cannot be combined with UDP or WireGuard on the same Listener.

RadiusDtlsListener:
  Type: Custom::ProxylityUdpGatewayListener
  Properties:
    ServiceToken: !FindInMap [ProxylityConfig, !Ref "AWS::Region", ServiceToken]
    ApiKey: !FindInMap [ProxylityConfig, Account, ApiKey]
    Name: radius-dtls
    Description: Encrypted RADIUS authentication endpoint
    Protocols:
      - dtls
    RequireCookies: "true"
    AllowEarlyData: "true"
    EarlyDataWindowSeconds: "3600"
    ClientRestrictions:
      Networks:
        - 203.0.113.0/24
    Destinations:
      - Name: radius-auth
        DestinationArn: !GetAtt RadiusAuthFunction.Arn
        Role:
          Arn: !GetAtt ProxylityDestinationRole.Arn

Outputs:
  DtlsEndpoint:
    Value: !Sub "${RadiusDtlsListener.Domain}:${RadiusDtlsListener.Port}"
  DtlsServerCertificate:
    Value: !GetAtt RadiusDtlsListener.DtlsServerCertificate

PSK Configuration

DeviceDtlsListener:
  Type: Custom::ProxylityUdpGatewayListener
  Properties:
    ServiceToken: !FindInMap [ProxylityConfig, !Ref "AWS::Region", ServiceToken]
    ApiKey: !FindInMap [ProxylityConfig, Account, ApiKey]
    Protocols:
      - dtls
    RequireCookies: "true"
    Psks:
      sensor-fleet: !Sub "{{resolve:secretsmanager:${DtlsPskSecret}:SecretString}}"
    ClientRestrictions:
      Networks:
        - 198.51.100.0/24
    Destinations:
      - Name: telemetry
        DestinationArn: !GetAtt TelemetryFunction.Arn
        Role:
          Arn: !GetAtt ProxylityDestinationRole.Arn

Properties

See the Listener CloudFormation Reference for the complete resource definition and return values.

DTLS Listeners created before session-ticket support was enabled must receive a CloudFormation stack update once before they can issue resumption tickets.

Testing a Listener

OpenSSL can verify certificate-based DTLS 1.2 connectivity:

openssl s_client -dtls1_2 -connect YOUR_DOMAIN:YOUR_PORT

A successful handshake displays the Listener certificate and negotiated cipher. Application protocols still need to send valid payloads after the handshake; a completed OpenSSL connection alone does not test your Destination.

Example: Serverless RADIUS

The public serverless RADIUS example can deploy authentication transport using UDP, WireGuard, or DTLS. It demonstrates how the same AWS application backend can accept encrypted RADIUS traffic through a DTLS Listener without operating a RADIUS server host.