Now Available: DTLS Listeners

UDP is an excellent transport for applications that value low latency, independent messages, and resilience to intermittent networks. But plain UDP does not provide confidentiality, integrity, or peer authentication. Applications have traditionally had to implement those protections themselves, deploy a VPN, or operate a server that terminates a secure transport.

Today, DTLS Listeners are generally available in Proxylity UDP Gateway. A DTLS Listener accepts encrypted datagrams from DTLS 1.2 and DTLS 1.3 clients, authenticates the session, and delivers the decrypted application payload to AWS services through the same Destinations used by plain UDP and WireGuard Listeners. Responses from your application are encrypted and returned through the established session.

TLS Security, Datagram Semantics

TLS was designed around a reliable byte stream such as TCP. UDP behaves differently: packets can be lost, reordered, or duplicated, and every datagram is independently meaningful. Datagram Transport Layer Security (DTLS) adapts the TLS security model to those conditions while preserving UDP's message-oriented transport.

That makes DTLS a natural fit for protocols that already use UDP and need transport security without becoming a TCP application. RADIUS, real-time telemetry, IoT messaging, and purpose-built device protocols can keep their datagram behavior while gaining authenticated encryption.

What a DTLS Listener Provides

• DTLS 1.2 and DTLS 1.3 support for compatibility with established and emerging clients
• A managed server certificate associated with the Listener endpoint
• Optional pre-shared keys for devices and applications that use DTLS-PSK
• Optional cookie enforcement to reduce amplification and resource-exhaustion risk
• DTLS 1.2 Connection IDs for clients that need sessions to survive NAT rebinding, source-port changes, and network transitions
• DTLS 1.3 session resumption with optional 0-RTT early data for replay-safe operations
• Plaintext delivery to Destinations, allowing existing Lambda, SQS, Kinesis, DynamoDB, and other integrations to process application data without handling DTLS
• Encrypted responses through the established client session

The result follows the same division of responsibility as the rest of UDP Gateway: clients speak the network protocol, AWS services implement the application, and Proxylity manages the internet-facing transport.

For low-power IoT devices, DTLS 1.2 Connection IDs can be as important as encryption itself. A negotiated CID lets an established session continue when a device wakes with a different NAT mapping, changes UDP source ports, or moves between access networks. Avoiding a fresh handshake saves radio time, cryptographic work, and latency. CID requires support in the client DTLS implementation; clients without it continue to use standard endpoint-bound DTLS sessions.

Configured as Infrastructure as Code

DTLS uses the existing Custom::ProxylityUdpGatewayListener CloudFormation resource. Set Protocols to dtls, attach the same Destinations you already use, and optionally enable cookies or configure PSK identities.

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

CloudFormation returns the assigned domain, port, and PEM-encoded server certificate. This keeps endpoint provisioning, client trust distribution, access restrictions, and application routing in the same deployment workflow.

A Practical Example: Serverless RADIUS

RADIUS is a useful example of why DTLS matters. The protocol is widely deployed over UDP, but transporting it across the public internet requires additional protection. WireGuard is an excellent option when the network gateway can run a tunnel client. DTLS provides another path for equipment or software with native DTLS support, without requiring a separate VPN.

Our public serverless RADIUS example includes UDP, WireGuard, and DTLS as selectable transport options. The application and AWS Destinations stay the same; the Listener determines how traffic is protected before the RADIUS payload reaches them.

The First WebRTC Milestone

Yesterday we published our roadmap to browser applications. Browsers cannot open arbitrary UDP sockets, but WebRTC Data Channels use a stack built on UDP, DTLS, and SCTP. DTLS availability completes the first transport milestone on that roadmap.

This release does not turn a DTLS Listener into a WebRTC endpoint by itself. WebRTC still requires signaling, ICE connectivity, and SCTP for Data Channels. Those are distinct layers. Shipping DTLS first gives native clients an immediately useful secure transport while establishing the foundation for what comes next.

Getting Started

DTLS Listeners are available now to UDP Gateway customers. See the DTLS Listener documentation for authentication options, CloudFormation examples, certificate retrieval, and an OpenSSL connectivity check. The complete property definitions are in the Listener CloudFormation reference.