Cisco Systems

gmccollu@cisco.com

Network Time Protocols This document proposes a modern, secure, and extensible time synchronization protocol designed to operate over the QUIC transport protocol. Known as TSQ (Time Synchronization over QUIC), this protocol aims to address the limitations of traditional NTP by leveraging QUIC's encryption, widespread UDP/443 acceptance, and multiplexed stream capabilities. TSQ is designed for contemporary deployment environments, including enterprise networks, cloud-native systems, containers, and mobile devices, where traditional UDP-based NTP struggles with security, scalability, or operational reliability. This specification is published as an Experimental RFC. See for details.

Time synchronization is foundational to modern computing. It underpins authentication systems, log correlation, distributed transactions, and more. NTP, the current standard, was designed in a different era and brings challenges related to security, deployment compatibility, and extensibility. TSQ is proposed as a new protocol built directly on top of QUIC, leveraging its modern transport features to provide secure, authenticated, and operationally-friendly time synchronization.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

TSQ: Time Synchronization over QUIC protocol.

QUIC: A secure, multiplexed transport protocol over UDP.

TLV: Type-Length-Value, a flexible message format.

Precision Mode: An OPTIONAL TSQ feature for low-jitter synchronization.

RTT: Round-trip time.

NTP: Network Time Protocol. A widely deployed protocol for synchronizing clocks over IP networks, formally specified in . TSQ inherits its timestamp format from NTP but differs in transport, security, and extensibility.

TSQ is intended to: Provide secure and authenticated time synchronization Support modern deployment scenarios Operate in environments where UDP/123 is blocked Be extensible and future-proof Scale for enterprise and cloud TSQ is not intended to: Replace NTP in ultra-precise or constrained devices Replace public NTP infrastructure without optimization

TSQ uses QUIC as its transport protocol, establishing secure connections for the exchange of time synchronization messages. TSQ supports two transport modes: QUIC streams and QUIC datagrams. Both modes carry the same TLV-formatted message content, but differ in reliability, latency, and use cases. Stream Mode: Uses QUIC’s reliable, ordered streams. This mode ensures delivery and supports features like message signatures, making it suitable for authenticated and auditable time synchronization exchanges. Datagram Mode: Uses QUIC DATAGRAM frames for lower-latency, unordered delivery. This mode is suitable for fast, opportunistic synchronization but offers no retransmission or delivery guarantees. Applications requiring integrity validation SHOULD use Stream Mode. A typical TSQ exchange (in either mode) consists of the following steps: Client opens a QUIC connection to the TSQ server (typically using UDP/443) and negotiates the TSQ protocol via ALPN. Client sends a TSQ Request with a nonce and a transmit timestamp (T1). To support stateless server deployments and ensure robustness against replay attacks, clients MUST generate nonces that are cryptographically secure, unpredictable, and sufficiently long to avoid collisions. Server replies with a TSQ Response containing the echoed nonce, the current server time, and two timestamps: the time the request was received (T2) and the time the response was sent (T3). Client locally records its own receive time (T4), computes the round-trip time (RTT), and derives the clock offset for synchronization.

TSQ uses QUIC for transport, leveraging its handshake for mutual authentication and encryption. Clients MUST negotiate the TSQ protocol using the ALPN identifier "tsq" during the QUIC handshake. Short-lived or resumed QUIC connections MAY be used to optimize performance.

Each TSQ exchange consists of a request and response over a QUIC stream. Clients and servers MUST capture the following timestamps:

T1 (Client Transmit Time): The moment the client sends the TSQ Request.

T2 (Server Receive Time): The moment the server receives the TSQ Request.

T3 (Server Transmit Time): The moment the server sends the TSQ Response.

T4 (Client Receive Time): The moment the client receives the TSQ Response.

These timestamps enable the client to calculate round-trip time (RTT) and clock offset. T1 and T4 are recorded by the client and are not transmitted. T2 and T3 are included in the TSQ Response message payload. | | | | ------ TSQ Request (T1, Nonce) -------> | | | | <--- TSQ Response (T2, T3, Nonce) ----- | | | | (Records T4, computes offset & RTT) | ]]>

TSQ uses a Type-Length-Value (TLV) format to encode fields within TSQ Request and Response messages. Each TLV is self-contained and designed for easy extensibility. The structure is as follows: All multi-byte fields within the Value are encoded in network byte order (big-endian). TSQ messages consist of a sequence of TLVs (Type-Length-Value elements). This format is consistent across both stream-based and Datagram modes. In Datagram Mode, all TLVs MUST still appear in a well-defined order, beginning with the Nonce (Type 1). Since QUIC DATAGRAM frames do not provide ordering or framing guarantees, implementations MUST treat the entire datagram payload as a single TSQ message. Partial or fragmented TLVs MUST NOT be used. All TLVs follow a consistent format: a one-byte Type, a one-byte Length, and a variable-length Value. TLVs MUST be processed sequentially, and unknown TLV types MUST be ignored unless policy dictates otherwise. The Signature Block TLV, if present, MUST appear last. TSQ Request Message TLVs:

Nonce (Type 1): 16 bytes. A cryptographically secure random value generated by the client. Used to associate responses and ensure freshness. Copied back verbatim in the response.

Transmit Timestamp (Type 2): 8 bytes. The time at which the client sends the request. Encoded as a 64-bit unsigned fixed-point NTP timestamp.

TSQ Response Message TLVs:

Nonce (Type 1): 16 bytes. Echoed from the request to associate response with request.

Server Time (Type 3): 8 bytes. The server's wall-clock time when generating the response, in NTP format.

Receive Timestamp (Type 4): 8 bytes. The server's local time when the request was received, in NTP format.

Send Timestamp (Type 5): 8 bytes. The server's local time when the response was sent, in NTP format.

Optional TLVs are used to extend TSQ without altering the core format. These TLVs MUST follow standard TLV structure and be included after the required fields in the message. Each is defined as follows:

Precision Mode Request (Type 250): 0 bytes. Included by the client to request Precision Mode behavior.

Precision Mode Acknowledgment (Type 250): 0 bytes. Echoed by the server to confirm support.

Time Source Info (Type 251): Variable length. Optionally included by the server in the TSQ Response to indicate the current stratum and synchronization source. The format is as follows: Clients MAY use this TLV to assess time accuracy or for logging/auditing. Servers MAY omit this field, and clients MUST tolerate its absence.

Signature Capability (Type 252): 0 bytes. Included by the client to indicate that the response MUST include a Signature Block (Type 255). If this TLV is present in a TSQ Request and the server does not include a valid Signature Block in the corresponding TSQ Response, the client MUST treat the response as unauthenticated and discard it. This TLV enables policy-driven enforcement of signed exchanges.

Metadata (Type 253): Variable length. Encoded as a series of UTF-8 key-value pairs. Each key and value is prefixed with a single-byte length. Example: [0x04] "site" [0x07] "us-east". MAY be repeated for multiple annotations. Clients MUST ignore unknown keys. Example encoding: 04 73 69 74 65 07 75 73 2d 65 61 73 74 ]]>

Padding (Type 254): Zero or more bytes. Used to align total message size for symmetry and minimize timing bias. The value MUST consist of zero-value bytes. This TLV MAY appear multiple times and MAY be placed anywhere in the message except before required fields.

Signature Block (Type 255): MUST be the final TLV in the message. Contains a digital signature over all prior TLVs in their exact byte order. The value contains the following fields: Field descriptions: Algorithm ID (1 byte): Indicates the signature algorithm in use. See below. Key ID (4 bytes): An identifier for the signing key (e.g., for key rotation). Signature Length (2 bytes): Total number of signature bytes to follow. Signature Bytes: The raw signature output from the selected algorithm. Signatures MAY use (Ed25519) or (HMAC-SHA256), depending on deployment policy.

All timestamps use the NTP format, a 64-bit unsigned fixed-point representation: the upper 32 bits represent seconds since the NTP epoch (January 1, 1900), and the lower 32 bits represent fractional seconds. This format ensures sub-microsecond resolution and compatibility with existing time protocols.

The following table summarizes the currently defined TSQ TLV types: Type Name Direction Required Description 1NonceRequest and ResponseYesIdentifies exchange and prevents replay 2Transmit TimestampRequestYesTime client sent request (T1) 3Server TimeResponseYesCurrent wall time at server 4Receive TimestampResponseYesTime server received request (T2) 5Send TimestampResponseYesTime server sent response (T3) 6–249Reserved–NoReserved for future extension 250Precision Mode Req/AckRequest and ResponseNoNegotiate symmetric message sizing 251Time Source InfoResponseNoStratum and source metadata 252Signature CapabilityRequestNoClient requests signed response 253MetadataRequest and ResponseNoDeployment annotations (e.g., site ID) 254PaddingRequest and ResponseNoZero-filled padding for alignment 255Signature BlockResponseConditionalCryptographic signature of message TLV Type values 6 through 249 are reserved for future use and MUST NOT be assigned without IETF review. All TLV types not listed here are reserved. Future extensions MUST use unique type values and follow the TLV format rules defined in this section. Implementations MUST ignore unknown TLV types unless explicitly required by policy.

Precision Mode is an OPTIONAL feature of TSQ designed to reduce timing variance introduced by serialization delay and queuing asymmetries. It ensures that TSQ Request and Response messages are of equal size to enable low-jitter, symmetric round-trip time measurement. Negotiation: Precision Mode is negotiated using TLV Type 250. The client includes a zero-length Precision Mode Request TLV (Type 250) in the TSQ Request to indicate support for Precision Mode. If the server also supports Precision Mode, it MUST include a zero-length Precision Mode Acknowledgment TLV (Type 250) in the TSQ Response. If the server does not support Precision Mode, it MUST omit this TLV. Clients MUST interpret the absence of the acknowledgment TLV as lack of support and MAY either proceed without Precision Mode or fail the exchange, based on local policy. Fixed-Length Packet Symmetry: When Precision Mode is successfully negotiated, both endpoints MUST ensure that the total byte length of the TSQ Request and Response messages are identical. To do so, implementations MUST include a Padding TLV (Type 254) to pad the message as needed. Padding MUST consist entirely of zero-value bytes and MUST appear after all other TLVs except the Signature Block. If used with the Signature Block TLV, Padding MUST appear immediately before it. Interoperability: Clients that require Precision Mode for accurate clock synchronization SHOULD implement a fallback behavior if the server does not acknowledge support. The use of a dual-role TLV (Type 250) avoids the need for separate type registration and keeps the negotiation mechanism simple. This TLV MAY be extended in the future to include payload data for enhanced negotiation, though current implementations MUST treat the TLV as zero-length.

In addition to stream-based transport, TSQ optionally supports transmission over QUIC Datagrams for low-latency, unreliable synchronization exchanges. This is referred to as Datagram Mode. Operational Flow: In Datagram Mode, the TSQ Request and Response are each encoded as a single TLV-encoded message and transmitted in a single QUIC DATAGRAM frame. This eliminates the need for a stream-based handshake, reducing round-trip latency. There is no flow control or retransmission of TSQ messages when sent this way. Message Format: The message format is identical to stream-based TSQ: a sequence of TLVs beginning with a Nonce (Type 1) and including Server Time (Type 2), Receive/Send Timestamps, and optionally Padding, Metadata, and Signature TLVs. The same message structure applies; only the transport differs. Negotiation: Datagram Mode is implicitly negotiated via ALPN and application profile. If both client and server support it, the client MAY send the first TSQ Request as a DATAGRAM. If the server replies using a DATAGRAM, the mode is established. If the server does not support DATAGRAM frames, it will not acknowledge or will fall back to a stream-based response. Clients MUST be prepared to retry using stream-based transport. Trade-Offs: Datagram Mode offers reduced latency and avoids head-of-line blocking, but provides no delivery guarantees. This makes it suitable for approximate or opportunistic synchronization, but not for authenticated, auditable timestamps. Applications that require signature validation, retransmission, or ordering SHOULD use stream-based mode.

TSQ implementations MUST validate all TLV structures. Malformed messages SHOULD result in connection termination or silent discard. Clients MUST handle missing or invalid nonce echoes and timestamp anomalies. Timestamp anomalies include any condition where the computed round-trip time (RTT) or clock offset is implausible or mathematically invalid. This includes, but is not limited to: RTT calculation results in a negative or zero duration. Offset calculation exceeds deployment-defined thresholds (e.g., 24 hours). Timestamps appear non-monotonic (e.g., T3 earlier than T2). Receive time (T4) is earlier than transmit time (T1). When encountering such anomalies, clients SHOULD discard the result, log a warning or error for diagnostic purposes, and MAY retry the exchange with a different server or after a short delay. Implementations MAY apply sanity checks or rate limits to prevent excessive retries in unstable environments. Deployments requiring strict synchronization SHOULD implement anomaly detection thresholds that align with operational tolerances (e.g., tolerable drift or jitter). No synchronization adjustment MUST be applied unless all four timestamps (T1–T4) are consistent and validated.

TSQ leverages QUIC's security model to ensure confidentiality, integrity, and replay protection. All TSQ messages are encapsulated within encrypted QUIC streams or datagrams, depending on mode. TSQ relies on the Application-Layer Protocol Negotiation (ALPN) extension in QUIC to distinguish TSQ traffic from other application protocols. Implementations MUST verify that the negotiated ALPN value is exactly "tsq". Clients MUST reject any QUIC connection where the negotiated ALPN does not exactly match "tsq". Failure to enforce ALPN validation could result in downgrade attacks where the connection is interpreted as TSQ despite not meeting protocol security requirements. The QUIC handshake provides mutual authentication if certificates are validated. In TSQ, this ensures both the client and server are communicating with authenticated endpoints. Replay protection is achieved via QUIC's transport guarantees. However, implementations MUST validate echoed nonces and timestamp monotonicity to guard against application-level replay attacks. TSQ supports a negotiation mechanism for clients that require signed responses. This is achieved using the Signature Capability TLV (Type 252), which signals that the client requires a digitally signed TSQ Response. Servers that receive this TLV MUST include a valid Signature Block TLV (Type 255) in the response or fail the request. If no Signature Block is present in the response, the client MUST treat the exchange as unauthenticated and discard it. This mechanism ensures deterministic policy enforcement for deployments requiring auditability. TSQ supports optional digital signatures to support auditability or long-term integrity. Signatures MAY be generated using Ed25519 or HMAC-SHA256 and included in the Signature Block TLV (Type 255). For security implications specific to Datagram Mode, see . The Time Source Info TLV (Type 251) provides optional metadata about the server’s synchronization source and quality. While useful for transparency and diagnostics, clients MUST treat this TLV as advisory. It MUST NOT be used as a substitute for cryptographic integrity or freshness validation. Implementers SHOULD validate time quality using signatures, replay protection, and out-of-band policy when accuracy is critical. Privacy-conscious deployments SHOULD minimize identifying metadata in TSQ messages and MAY use ephemeral QUIC connections to reduce correlation risk. Servers MAY also implement rate-limiting to mitigate client fingerprinting or denial-of-service vectors.

QUIC Datagram mode provides reduced latency and eliminates head-of-line blocking, but introduces several important security trade-offs compared to stream-based TSQ exchanges. Unreliability: QUIC Datagram frames are not retransmitted or acknowledged. Messages may be lost, reordered, or duplicated. Spoofing Risk: Since datagrams are stateless and unidirectional, responses can be spoofed by an on-path attacker unless validated using digital signatures. No Built-In Integrity: QUIC Datagram mode lacks framing guarantees. Without the Signature Block TLV, clients have no cryptographic assurance of authenticity or freshness. As a result, clients that operate in Datagram Mode SHOULD treat responses as advisory unless they include a valid Signature Block. Implementations that require auditability, integrity guarantees, or traceability SHOULD prefer stream-based TSQ exchanges. Where Datagram Mode is used, deployments MAY enforce signature usage via the Signature Capability TLV and validate all incoming messages against known server credentials.

TSQ supports optional message-level signatures for deployments that require auditability or long-term verifiability beyond QUIC's ephemeral session security. This mechanism is distinct from QUIC's built-in authentication and confidentiality, and SHOULD only be enabled when such properties are required. When enabled, the TSQ Response MUST include a TLV extension of type 255 (0xFF), known as the Signature Block. Signature Algorithm ID (1 byte) Key ID (4 bytes) Signature Length (2 bytes) Signature Bytes Supported signature algorithms:

0x01: Ed25519 using the standard Curve25519 curve

0x02: HMAC-SHA256 (requires shared secret)

The data to be signed MUST include (in order): The echoed Nonce (Type 1) Transmit Timestamp (Type 2) Receive Timestamp (T2, Type 4) Send Timestamp (T3, Type 5) Optional TLVs (e.g., Metadata, Time Source Info), if present Keys are provisioned out-of-band and identified by the Key ID. TSQ does not define a key distribution mechanism; implementers MAY use mechanisms such as DNSSEC, enrollment protocols, or manual configuration. Use of signatures SHOULD be negotiated via a policy or deployment profile. Clients that require signatures but do not receive them MUST treat the response as unauthenticated. Signatures mitigate threats such as long-term forgery, post-session repudiation, and auditing in compliance-sensitive deployments. They do not replace or extend QUIC's real-time transport security and SHOULD NOT be used as a substitute for encrypted transport. The presence of the Signature Capability TLV (Type 252) in the TSQ Request mandates the inclusion of a valid Signature Block TLV in the response. Failure to comply MUST result in rejection of the response by the client. This provides a lightweight, in-band method to enforce signature requirements on a per-request basis.

TSQ is designed to operate efficiently in large-scale, heterogeneous environments. It is suitable for use in enterprise, cloud-native, and mobile scenarios where traditional NTP may encounter limitations due to UDP/123 filtering, firewall traversal, or security posture. QUIC’s stream multiplexing and NAT rebinding support allow TSQ to serve mobile clients that frequently change IP addresses or network paths. Use of QUIC on UDP/443 also enables easier traversal through firewalls and middleboxes. TSQ connections are intended to be short-lived by default, allowing high churn rates with minimal state retention. However, QUIC session resumption MAY be used to optimize recurring exchanges with known servers. Implementations MAY operate in a stateless mode by avoiding long-lived session tracking and relying on QUIC’s address validation tokens to prevent abuse. Stateless designs are especially beneficial for high-volume deployments such as cloud-based time services. TSQ is not intended to replace the global NTP stratum hierarchy or public time pool infrastructure directly. However, it MAY be used in conjunction with such infrastructure, particularly where UDP-based protocols are not viable or additional metadata, security, or auditability is required. Servers MAY include a Time Source Info TLV in responses to expose stratum or reference source. This is particularly useful in hierarchical deployments or enterprise deployments with multiple upstream sources. However, TSQ does not impose or rely on a strict time hierarchy, and clients MUST treat this information as advisory. TSQ supports an optional stateless design by allowing servers to construct responses solely based on information included in the client request, without maintaining per-client session state. Specifically, the client's request includes a cryptographically secure nonce, and all timestamps necessary for round-trip time (RTT) calculation are echoed or generated in the response. If signature-based integrity protection is used, the server can sign the response using a long-lived private key without needing to store session-specific metadata. This enables large-scale deployments where the server handles a high volume of clients without incurring memory or tracking overhead per connection. However, implementations MUST ensure that nonce uniqueness and freshness are sufficient to prevent replay attacks and ambiguity in response validation. In particular, clients MUST generate cryptographically strong nonces using a secure random number generator. Nonces MUST be unpredictable and collision-resistant, as servers may operate in a stateless mode and rely solely on the nonce for response association. The default 16-byte nonce length is RECOMMENDED to ensure sufficient entropy for all deployment sizes. Reuse or predictability of nonces can lead to forged or replayed responses, especially in datagram mode.

This document is published as an Experimental RFC to evaluate the viability and security of time synchronization over the QUIC transport protocol. The goals of this experiment are to: Demonstrate successful time synchronization in varied environments (e.g., cloud, mobile, IoT) where traditional NTP/NTS protocols face limitations. Validate interoperability between independent TSQ implementations across QUIC versions and TLS stacks. Evaluate the robustness of TSQ’s security model, including replay prevention, signature validation, and support for stateless operation. Assess the practicality of TSQ’s Precision Mode and Datagram Mode in real-world deployments. Implementers are encouraged to produce and test against at least one reference implementation that supports both Stream and Datagram modes, and to validate fallback behaviors (e.g., unsupported Precision Mode or missing Signature Block) to ensure graceful interoperability across partial implementations. Feedback from implementers and operators will help determine whether TSQ is suitable for progression to the Standards Track, and whether refinements to the protocol, message formats, or security properties are necessary.

This document requests IANA to register the following value in the "TLS Application-Layer Protocol Negotiation (ALPN) Protocol IDs" registry: TSQ uses the ALPN identifier "tsq" to negotiate protocol support during the TLS handshake . Protocol Identification Sequence Reference tsq 0x03 74 73 71 ("tsq") This document Per , this identifier is used during the TLS handshake to indicate TSQ support.

Special thanks to Joe Clarke for insightful comments and review during early iterations of this document. Thanks also to participants in the NTP and QUIC IETF Working Groups whose discussions and documents shaped many of the ideas in this work.

Orange County Chapter Microsoft Google University of Waterloo

The following table compares traditional time synchronization approaches to TSQ: Feature NTP NTS TSQ Transport UDP UDP+TLS QUIC (UDP/443) Encryption No Yes Always Extensibility Low Medium High Mobile Support No No Yes Precision Mode No No Yes TSQ and Roughtime serve complementary purposes. While Roughtime provides cryptographic attestation of coarse-grained time and bootstraps trust in untrusted environments, TSQ is designed for ongoing synchronization with higher precision, session continuity, and transport-layer security. TSQ may follow Roughtime during startup or cold boot scenarios.