Customers using a routing-engine based redirect service for unpaid subscribers may encounter issues with web traffic for these subscribers.

This service is designed to redirect all web traffic to a captive portal for unpaid subscribers. While the redirection should function correctly for all standard HTTP pages, there is a known limitation with social networks like Facebook and Instagram, which use the QUIC (Quick UDP Internet Connections) protocol. Traffic from these sites cannot be redirected to the captive portal.

Customers may observe that the CPCDD Daemon, an RE application used for handling redirect and rewrite functionalities, only processes HTTP traffic. This daemon, which has been enhanced to support new functionalities, operates as a UDP daemon listening on a fixed port (e.g., 34000). CPCDD is responsible for managing HTTP traffic redirection and rewriting. It is important to note that CPCDD does not perform any redirection for QUIC or HTTPS traffic.

Diagnostics:

• CPCDD traces reveal that only HTTP traffic is being processed.
• PCAP analysis indicates that the redirection functionality works exclusively for HTTP traffic.
• Using the command show services captive-portal-content-delivery statistics interface, we can confirm that the daemon is receiving and processing data as expected for the HTTP protocol.

show services captive-portal-content-delivery statistics interface <si interface> 

set services captive-portal-content-delivery traceoptions file size 100m 

set services captive-portal-content-delivery traceoptions file files 10 

set services captive-portal-content-delivery traceoptions flag all 

​

Overview of HTTP/3 and QUIC: HTTP/3 is the upcoming third major version of the HTTP protocol, which utilizes QUIC instead of TCP. QUIC is a new transport protocol based on UDP, designed to offer improved performance.

Key Differences and Advantages:

• Efficiency: Traditional HTTPS with TLS 1.2 requires 1 RTT (Round-Trip Time) for the TCP handshake and an additional 2 RTTs for the TLS handshake. In contrast, HTTP/3 with QUIC combines the TLS handshake with the QUIC handshake, requiring only 1 RTT. Moreover, if two endpoints have previously established a connection, they can use cached data to set up a 0-RTT connection, further reducing latency.
• Address Independence: QUIC is designed to be address-independent. Instead of using an address/port tuple, a QUIC endpoint uses a connection ID to match packets to connections. This allows a QUIC endpoint to change its address or port without closing the connection.
• Encryption: QUIC encrypts data at the packet level, ensuring confidentiality and integrity. Both the packet header and payload are encrypted independently, which enhances security.

Limitation with MX Captive Portal Redirection: Since the CPCD daemon does not understand the QUIC protocol, the MX series routers do not support QUIC for captive portal redirection. This limitation arises because the encryption in QUIC prevents the CPCD daemon from processing or redirecting the traffic.