DTLS Listeners - Proxylity UDP Gateway

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 Feature UDP Listener DTLS Listener WireGuard Listener Transport Plain UDP DTLS 1.2 or DTLS 1.3 WireGuard tunnel Encryption Application responsibility TLS-style authenticated encryption WireGuard authenticated encryption Client authentication Client Restrictions Certificate handshake or configured PSK identity Registered peer key or open-peer policy Payload delivered to Destinations UDP payload Decrypted application data WireGuard payload; optionally decapsulated Typical fit Simple or already-encrypted protocols Applications with native DTLS support VPN clients and IP tunneling 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 PropertyDescriptionDefault ProtocolsSet to a single value, dtls.Required RequireCookiesRequires a DTLS cookie exchange before the full handshake.false PsksMap of client identity to base64-encoded pre-shared key.Empty map AllowEarlyDataAccepts 0-RTT application data on resumed DTLS 1.3 sessions.false EarlyDataWindowSecondsSession-ticket lifetime and 0-RTT replay window, from 1 through 604800 seconds.3600 CertRefreshTokenChanging the value generates a new server certificate.Not set ClientRestrictionsNetworks and domains allowed to reach the Listener.Traffic blocked when omitted DestinationsAWS resources that receive decrypted application data.Empty list 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.