DTLS Listeners - Proxylity UDP Gateway

DTLS Listeners provide a managed edge gateway for UDP applications, bringing the convenience and scale of traditional HTTP API Gateways to datagram protocols. Clients establish a DTLS 1.2 or DTLS 1.3 session directly with the Listener's assigned domain and port. Proxylity terminates the session at the edge, decrypts the authenticated application data, and seamlessly routes the plaintext payloads into your event-driven cloud architecture (like AWS Lambda, SQS, or AppSync)—all without you needing to provision or maintain always-on server infrastructure. Responses from your backend are then re-encrypted and sent back through the same DTLS session.

The Architecture & Security Model

When designing with Proxylity, it's important to choose the listener that matches your security and operational requirements:

Edge Termination (DTLS Listener)

This model operates exactly like a standard web CDN or API Gateway (e.g., Cloudflare or AWS API Gateway) terminating HTTPS. The DTLS Listener manages the server certificates, handshakes, and decryption at the edge.

Value: Maximum operational convenience. It allows you to build purely serverless, event-driven UDP applications without running a fleet of listener nodes.

Trade-off: Because the gateway terminates the connection to route the event, the payload is visible in memory at the edge before being passed to your configured integrations.

End-to-End Encryption (Plain UDP Listener)

If your security posture requires strict end-to-end encryption (e-to-e) where payloads remain completely opaque to intermediaries, do not use the managed DTLS Listener.

Value: Complete data privacy. Proxylity acts strictly as a transport network.

How to use it: Provision a Plain UDP Listener instead. Your client will send encrypted DTLS packets through the gateway, and you will handle the DTLS termination and certificate management directly within your own application environment.

When to Use a Managed DTLS Listener

Choose a managed DTLS Listener when operational convenience and serverless scale outweigh the need for strict end-to-end payload opacity, and your clients natively support DTLS.

Common examples include RADIUS authentication, real-time IoT telemetry, and custom request-response protocols that cannot use a stream-oriented TLS connection, but benefit from being routed directly into serverless compute.

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.