RFC 9769
NTP Interleaved Modes
RFC 9769: NTP Interleaved Modes 🦋
okay so bestie, this is RFC 9769, called NTP Interleaved Modes 💖 It's a Standards Track doc from May 2025 (ISSN 2070-1721), written by M. Lichvar at Red Hat and A. Malhotra at Boston University. It updates RFC 5905 🎀 and the title block doesn't list anything it obsoletes.
Abstract ✨
this doc specifies interleaved modes for the Network Time Protocol (NTP) 🕰️ the new modes make time sync more accurate by letting you use more accurate transmit timestamps, the ones that only exist after the NTP messages get sent 🤯 it's giving precision, and it's meant for environments where high accuracy is critical 💅 it also updates RFC 5905 by defining these new operational modes 🌸
Status of This Memo
this is an Internet Standards Track document 🔥
it's a product of the Internet Engineering Task Force (IETF) and it represents the consensus of the IETF community 🫶 it got public review and was approved for publication by the Internet Engineering Steering Group (IESG) ✅ for more on Internet Standards, check Section 2 of RFC 7841 📚
current status, errata, and how to give feedback live at https://www.rfc-editor.org/info/rfc9769 🧚
Copyright Notice
Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved. 💜
this doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) as they stand on the publication date 📜 please actually read them, they explain your rights and restrictions for this doc, no skipping 🙈 code components pulled out of this document must include Revised BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, as the Revised BSD License describes 🍓
Table of Contents
1. Introduction
1.1. Requirements Language
2. Interleaved Client/Server Mode
3. Interleaved Symmetric Mode
4. Interleaved Broadcast Mode
5. Impact of Implementation Errors
6. Security Considerations
7. IANA Considerations
8. References
8.1. Normative References
8.2. Informative References
Acknowledgements
Authors' Addresses1. Introduction 🎀
okay so RFC 5905 [RFC5905] covers how NTPv4 works in client/server mode, symmetric mode, and broadcast mode ⏰ the transmit and receive timestamps are two of the four timestamps in every NTPv4 packet used for time sync 💅
for super accurate and stable sync, the transmit and receive timestamps should be captured close to the start of the actual transmission and the end of the reception, respectively 🎯 if the timestamping is asymmetric, the offset NTP measures ends up with an error 😭
there are four spots where a timestamp of an NTP packet can get captured, with a software NTP implementation running on a general-purpose operating system:
- User space (software)
- Network device driver or kernel (software)
- Data link layer (hardware - MAC chip)
- Physical layer (hardware - PHY chip)
software timestamps captured in user space, inside the NTP implementation itself, are the least accurate 💀 they don't account for delays from system calls used to send and receive packets, processing and queuing delays in the system, network device drivers, and hardware 🙃 hardware timestamps captured at the physical layer are the most accurate 👑
a transmit timestamp captured in the driver or hardware is more accurate than the user-space one, BUT the NTP implementation only gets it after the packet has been sent with a system call 😤 it also can't go inside the packet itself unless the driver or hardware supports NTP and can modify the packet before or during the actual transmission 🫠
the protocol in RFC 5905 [RFC5905] doesn't define any way for a server to give its clients and peers a more accurate transmit timestamp that's only known after the transmission 🥺 a packet that strictly follows RFC 5905 [RFC5905], meaning it has a transmit timestamp matching the packet itself, is said to be in the basic mode 🦋
there are different ways you could swap timestamps that are known after transmission 🤔 the server could answer each request with two packets, and the second one would hold the transmit timestamp for the first 💌 BUT that setup would enable a traffic amplification attack, or it would use packets with asymmetric lengths, and that asymmetry would mess up the network delay and make the measured offset wrong 💀
this doc describes an interleaved client/server mode, an interleaved symmetric mode, and an interleaved broadcast mode 🌈 in all of them, the server sends a packet containing the transmit timestamp for the previous packet that went out to the client or peer ⏪ that timestamp can be captured in any software or hardware component involved in sending the packet 🔥 both servers and clients/peers are required to keep some state specific to the interleaved mode 🧠
an NTPv4 implementation that supports the interleaved client/server and interleaved broadcast modes interoperates with NTPv4 implementations that don't have this capability ✨ a peer using the interleaved symmetric mode does NOT fully interoperate with a peer that doesn't support it 😬 the mode needs to be configured specifically for each symmetric association 🎀
the interleaved modes don't change the NTP packet header format and don't use new extension fields 🙌 the negotiation is implicit ✨ the protocol gets extended with new values that can be assigned to the origin and transmit timestamps 💜 servers and peers check the origin timestamp to detect requests that follow the interleaved mode 🔍 a response can only be valid in one mode 🚫 if a client or peer that doesn't support interleaved mode gets a response that follows it, that response gets rejected as bogus 🗑️
an explicit negotiation would need a new extension field 🙃 RFC 5905 [RFC5905] doesn't say how servers should handle requests with an unknown extension field 🤷♀️ the original use of extension fields was authentication with Autokey [RFC5906], which can't be negotiated 🔐 some existing implementations don't respond to requests with unknown extension fields 😭 that behavior would stop clients from reliably detecting support for the interleaved mode 💔
requests and responses can't always be formed in the interleaved mode, and it can't be used exclusively 🙅♀️ servers, clients, and peers that support the interleaved mode need to also support the basic mode 🫶
this doc assumes you're already familiar with RFC 5905 [RFC5905] 📖
1.1. Requirements Language 💅
okay the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here 🎀 lowercase ones are just regular words, bestie 🦋
2. Interleaved Client/Server Mode 🦋
okay so the interleaved client/server mode is basically the cooler cousin of the basic client/server mode 💅 the two are almost identical, and the only real difference is what goes into the origin and transmit timestamp fields 🎀
the origin timestamp is like a little cookie 🍪 it helps you tell that a packet is actually replying to the last packet you sent the other way. it's a copy of one of the timestamps from the packet being answered, or zero if it's not a reply at all. servers following [RFC5905] just ignore the origin timestamp in client requests 🙈 and a server response without a matching origin timestamp is considered bogus. ngl that's harsh 💀
in basic mode, a client request has an origin timestamp that matches the transmit timestamp from the last valid server response. if it's the very first request of the association, the origin timestamp is zero 🌸 a server response in basic mode has an origin timestamp equal to the transmit timestamp from the client request. the transmit timestamp in the response lines up with when that response was actually sent ✨
in interleaved mode, it gets more fun 🧚 a client request has an origin timestamp equal to the receive timestamp from the last valid server response. the server response then has an origin timestamp equal to the receive timestamp from the client request. and the transmit timestamp in that response lines up with the transmission of the previous response, the one whose receive timestamp matched the origin timestamp in the request. the server is literally time-traveling its replies, and it's giving main character energy 👑
a server that supports interleaved mode has to save pairs of local receive and transmit timestamps 💜 but it SHOULD discard old timestamps so it doesn't hoard memory. one way is a fixed-length queue that drops the oldest timestamps as new ones get saved 🍓 the server MAY keep the timestamps separated by IP address, but it SHOULD NOT separate them by port number. that's so clients who switch ports between requests still work, as recommended in [RFC9109] 🦋
the server MAY also restrict interleaved mode to specific IP addresses and/or authenticated clients 🔐
now here's a rule that's lowkey iconic 🔥 both servers and clients that support interleaved mode MUST NOT send a packet whose transmit timestamp equals its receive timestamp. this is how you reliably tell whether a received packet is really following interleaved mode. one way to make sure of that is to bump the transmit timestamp up by 1 unit (about 1/4 of a nanosecond) if the two are equal. or you can just generate a brand new timestamp ✨
the transmit and receive timestamps in server responses also need to be unique 💅 otherwise two different clients could send requests with the same origin timestamp, and the server would reply in interleaved mode with the wrong transmit timestamp, which is a total disaster 💀 so if the timestamps aren't guaranteed to keep increasing, the server SHOULD check that the new transmit and receive timestamps aren't already saved as a receive timestamp from an earlier request (from the same IP address, if it separates timestamps by address). if they are, it generates a new one so no wrong interleaved response shows up later 🫶
now the server's gatekeeping 🚪 when it gets a request from a client, it MUST NOT respond in interleaved mode unless both of these are true:
- The request does not have a receive timestamp equal to the transmit timestamp.
- The origin timestamp from the request matches the local receive timestamp of a previous request that the server has saved (for the IP address, if it separates timestamps by addresses).
if it does respond in interleaved mode, the response MUST contain the transmit timestamp of the response that had the receive timestamp matching the origin timestamp from the request 🎀 after that, the server can drop those timestamps. and a receive timestamp MUST NOT be used again to detect an interleaved request, because no double-dipping allowed 🙅♀️
if those conditions aren't met (so the request isn't detected as interleaved), the server MUST NOT respond in interleaved mode. if it does respond, that response MUST be in basic mode 🌈 either way, the server SHOULD save the new receive and transmit timestamps so it can answer the client's next request in interleaved mode 🍓
the first request from a client is always basic, and so is the server's response. it has a zero origin timestamp and a zero receive timestamp. only once the client gets a valid response from the server can it send an interleaved request 🌸
the protocol is also honestly so resilient 🥹 if a client request or server response gets lost, the client reuses the same origin timestamp in its next request. the server can still reply in interleaved mode if it has the timestamps for that origin timestamp. if it already answered that timestamp in interleaved mode, or it had to drop the timestamps for some other reason, it replies in basic mode and saves fresh timestamps. those fresh ones let the server send an interleaved reply to the request after that 💖 the client SHOULD limit how many interleaved requests it sends between server responses, so the server doesn't end up processing super old timestamps when a bunch of requests in a row get lost 🙈
here's an example of a client/server exchange in interleaved mode, shown in Figure 1 ✨ packets in basic mode are marked B and packets in interleaved mode are marked I. the timestamps t1~, t3~, and t11~ point to the same transmissions as t1, t3, and t11, but they might be less accurate. the first exchange is basic, and the second one is interleaved. for the third exchange, the client's request is interleaved but the server's response is basic, because the server didn't have the pair of timestamps t6 and t7 (maybe they were dropped to make room for other clients using interleaved mode) 🦋
t2 t3 t6 t7 t10 t11
Server -----+----+----------------+----+----------------+----+-----
/ \ / \ / \
/ \ / \ / \
Client --+----------+----------+----------+----------+----------+--
t1 t4 t5 t8 t9 t12
Mode B B I I I B
+----+ +----+ +----+ +----+ +----+ +----+
Origin | 0 | | t1~| | t2 | | t4 | | t6 | | t5 |
Rx | 0 | | t2 | | t4 | | t6 | | t8 | |t10 |
Tx | t1~| | t3~| | t1 | | t3 | | t5 | |t11~|
+----+ +----+ +----+ +----+ +----+ +----+Figure 1: Packet Timestamps in Interleaved Client/Server Mode
when the client gets a response from the server, it runs the tests from [RFC5905] 🔍 two of those tests get a glow-up for interleaved mode:
- The duplicate packet check compares both receive and transmit timestamps. that way it doesn't accidentally drop a valid interleaved response that follows a basic response carrying the same transmit timestamp 🙌
- The bogus packet check compares the origin timestamp against both the transmit and receive timestamps from the request. if the origin timestamp matches the transmit timestamp, the response is basic. if it matches the receive timestamp, the response is interleaved ✨
the client SHOULD NOT update its NTP state when it gets an invalid response. that way it keeps the timestamps it'll need to finish a measurement once the next interleaved response shows up 🫶
if a packet passes the tests and is interleaved, the client can compute the offset and delay with the formulas from [RFC5905], using one of two sets of timestamps 🧮 the first set is RECOMMENDED for clients that filter measurements based on delay. the matching timestamps from Figure 1 are in parentheses:
T1: local transmit timestamp of the previous request (t1)T2: remote receive timestamp from the previous response (t2)T3: remote transmit timestamp from the latest response (t3)T4: local receive timestamp of the previous response (t4)
the second set gives a more accurate reading of the current offset 🎯 but the delay is way more sensitive to a frequency error between the server and client, because the gap between T1 and T4 is much longer:
T1: local transmit timestamp of the latest request (t5)T2: remote receive timestamp from the latest response (t6)T3: remote transmit timestamp from the latest response (t3)T4: local receive timestamp of the previous response (t4)
clients MAY filter measurements based on mode 💅 the maximum number of dropped measurements in basic mode SHOULD be limited for cases where the server doesn't support interleaved mode, or can't respond in it. clients that filter by delay will implicitly prefer interleaved measurements over basic ones, since those have a shorter delay thanks to a more accurate transmit timestamp (T3) 😭✨
last but not least, the server MAY limit how much it saves of the receive and transmit timestamps to requests with an interleaved-specific origin timestamp. that way it doesn't waste resources on clients using basic mode 🌷 the tradeoff is that the server's first interleaved response to a client gets delayed by one exchange 🐢
a check for a non-zero origin timestamp works with NTP clients that always set it to zero 🙃 from the server's point of view, those clients start a brand new association with every request 🔄
finally, to avoid searching the saved receive timestamps for non-zero origin timestamps from basic-mode requests, the server can use the low-order bits of its receive and transmit timestamps (below the clock's precision) as a flag. that flag says whether a timestamp is one of the server's receive timestamps 🚩 if the server gets a request with a non-zero origin timestamp that doesn't have that flag, the request isn't interleaved, so there's no need to search or save anything new. big brain energy 🧠💖
3. Interleaved Symmetric Mode ✨
okay so the interleaved symmetric mode is basically the same vibe as the interleaved client/server mode 💅 A packet here has a transmit timestamp that matches the packet it sent to its peer before, and an origin timestamp that's just the receive timestamp from the last packet it got from that peer. Iconic, right? 🦋
Now, for synchronization to work in both directions of a symmetric association, both peers need to support the interleaved mode 🫶 So, lowkey, it SHOULD be disabled by default and only turned on with an option in the configuration of the active side of the association 🎀
Here's the tricky part 😭 If a peer's transmissions don't alternate with its peer's (like if they use different polling intervals) and one or more earlier packets got lost, that peer could match transmit timestamps with the wrong packets. So the use of the interleaved mode in symmetric associations needs some extra restrictions 🙈
Peers that have an association need to count the valid packets they receive between their own transmissions, so they can figure out which mode a packet should be formed in 🧚 A valid packet here is one that passed all the NTP tests for duplicate, replayed, bogus, and unauthenticated packets 💖 Other received packets can still update the NTP state to help (re)initialize the association, but they do not change how the mode gets selected 🌸
Okay, the rules! A Peer A MUST NOT send a Peer B a packet in the interleaved mode unless all of the following conditions are met:
- Peer A has an active association with Peer B that was specified with the option enabling the interleaved mode, OR Peer A received at least one valid packet in the interleaved mode from Peer B.
- Peer A did not send a packet to Peer B since the time that it received the last valid packet from Peer B.
- The previous packet that Peer A sent to Peer B was the only response to a packet received from Peer B.
Why these? Condition 1 is there for compatibility with implementations that don't support the interleaved mode, or aren't configured for it 🍓 And the other two stop a missing response from making the remote transmit timestamp (T2) and local receive timestamp (T3) mismatch, which would give a huge error in the measured offset and delay 😭💀
Here's an example of packets exchanged in a symmetric association, shown in Figure 2 🌈 Peer A's minimum polling interval is twice as long as Peer B's maximum polling interval. The first packet from each peer is in the basic mode. The second and third packets from Peer A are in the interleaved mode. The second packet from Peer B is interleaved, but the later ones are basic, because multiple responses get sent for each request 👑
t2 t3 t6 t8 t9 t12 t14 t15
Peer A -----+--+--------+-----------+--+--------+-----------+--+----
/ \ / / \ / / \
/ \ / / \ / / \
Peer B --+--------+--+-----------+--------+--+-----------+--------+-
t1 t4 t5 t7 t10 t11 t13 t16
Mode B B I B I B B I
+----+ +----+ +----+ +----+ +----+ +----+ +----+ +----+
Origin | 0 | | t1~| | t2 | | t3~| | t4 | | t3 | | t3 | |t10 |
Rx | 0 | | t2 | | t4 | | t4 | | t8 | |t10 | |t10 | |t14 |
Tx | t1~| | t3~| | t1 | | t7~| | t3 | |t11~| |t13~| | t9 |
+----+ +----+ +----+ +----+ +----+ +----+ +----+ +----+
Figure 2: Packet Timestamps in Interleaved Symmetric ModeIf Peer A has no association with Peer B and it answers with symmetric passive packets, it doesn't need to count packets to meet those restrictions, because each request gets at most one response ✨ Handling those requests works the same way a server handles requests in the interleaved client/server mode 🦋
The peers can compute offset and delay using one of the two sets of timestamps from Section 2 💅 They can switch between the sets to shrink the interval between T1 and T4, which reduces the error in the measured delay 💜
4. Interleaved Broadcast Mode 📡
A packet in the interleaved broadcast mode carries two transmit timestamps 🎀 One belongs to the packet itself and goes in the transmit timestamp field. The other belongs to the previous packet and goes in the origin timestamp field 🫶 The packet is still compatible with the basic mode, which uses a zero origin timestamp 🌸
Here's an example of packets sent in the broadcast mode, shown in Figure 3 🧚
t1 t3 t5 t7
Server ------+------------+------------+------------+---------
\ \ \ \
\ \ \ \
Client ---------+------------+------------+------------+------
t2 t4 t6 t8
Mode B I I I
+----+ +----+ +----+ +----+
Origin | 0 | | t1 | | t3 | | t5 |
Rx | 0 | | 0 | | 0 | | 0 |
Tx | t1~| | t3~| | t5~| | t7~|
+----+ +----+ +----+ +----+
Figure 3: Packet Timestamps in Interleaved Broadcast ModeA client that doesn't support the interleaved mode ignores the origin timestamp and processes every packet as if it were in the basic mode 💖
A client that does support the interleaved mode MUST check whether the origin timestamp is not zero, so it can spot packets that follow the interleaved mode 👑 The client SHOULD also compare the origin timestamp with the transmit timestamp from the previous packet to catch lost packets 😭 If the difference is larger than a specified maximum (e.g., 1 second), the packet SHOULD NOT be used for synchronization in the interleaved mode, so there's no huge error in the measurement 💀
The client computes the offset using the origin timestamp from the received packet and the local receive timestamp of the previous packet 🦋 If the client needs to measure network delay, it SHOULD use the interleaved client/server mode 🍓 If it used the basic client/server mode or symmetric mode instead, the less accurate delay measurement would also hurt the accuracy of the offset measured in the interleaved broadcast mode 🙈
5. Impact of Implementation Errors 🙈
The interleaved modes make NTP more complex and more sensitive to implementation errors 😭 Some errors that cause zero problems between implementations that only do the basic mode can cause an occasional missing or corrupted measurement when one or both sides support the interleaved mode 💅 This section describes the impact of what could possibly be the most likely errors in the most commonly used mode, which is client/server 🎀
If a client that doesn't support the interleaved mode sets the origin timestamp to anything other than the transmit timestamp from the last valid server response, or zero, that origin timestamp can match a receive timestamp from a previous server response (possibly one sent to a different client) and cause an unexpected interleaved response 💀 The client is expected to drop that response as bogus because its origin timestamp is wrong 🫶 If it didn't check for bogus responses, it would get a corrupted measurement, possibly with a large error in offset and delay 😭 It would also be vulnerable to off-path attacks 🚨
The worst case is a client that sets the origin timestamp to the server's receive timestamp, i.e., the client accidentally implemented the interleaved mode but doesn't accept interleaved responses 🙈 It can still sync its clock, though 💖 It drops interleaved responses as bogus and sets the origin timestamp to the receive timestamp from the last valid response in the basic mode 🌈 Since servers are required to not respond twice to the same origin timestamp in the interleaved mode, at least every other response would be in the basic mode and accepted by the client 👑
A missing or corrupted measurement can also come from problems on the server side 🧚 A server that doesn't make sure the receive and transmit timestamps in its responses are unique over a long enough interval can misread requests formed correctly in the basic mode as interleaved, and then respond in the interleaved mode 😭 The client drops that response as bogus 💅
A duplicated server receive timestamp can cause an expected interleaved response to carry a transmit timestamp that doesn't match the previous response the client copied the receive timestamp from (into the origin timestamp of the request). Instead, it carries the transmit timestamp of a different response that had the same receive timestamp 🙈 The client accepts it with a small error in the transmit timestamp, equal to the difference between the transmit timestamps of the two responses 🦋 Since the requests for those two responses arrived at the same time (according to the server's clock), the two transmissions should be close to each other, and the difference between them is comparable to the error a basic response normally has in its transmit timestamp 💜
6. Security Considerations 🔐✨
Okay bestie, security is where things get seriously spicy 🌶️ The general security stuff for time protocols is covered in [RFC7384], and the NTP-specific security stuff is in [RFC5905] 💅
Security issues that apply to the basic modes from [RFC5905] also apply to the interleaved modes, no cap. They're explained in "The Security of NTP's Datagram Protocol" [SECNTP] 🦋
Clients and peers SHOULD NOT leak the receive timestamp in packets they send to other peers or clients (for example, as a reference timestamp). That keeps off-path attackers from easily grabbing the origin timestamp they'd need to forge a valid response in interleaved mode 🙈
Clients using the interleaved mode SHOULD randomize all bits of their receive and transmit timestamps in requests (that means a precision of 2^32 seconds). This makes it way harder for off-path attackers to guess the origin timestamp in the server's response 🎀
Unlike in the basic client/server mode, clients in the interleaved mode cannot set the origin timestamp in their requests to zero (which would reset the NTP association with every request). That's the trick that makes it harder to track them as they hop between networks, so it's a no-go here 🚫🧚
Attackers can force the server to drop its timestamps so clients never get an interleaved response. They can flood the server with lots of requests, send requests with a spoofed source address, or replay an authenticated request if interleaved mode is only enabled for authenticated clients. Clients MUST NOT rely on servers being able to respond in the interleaved mode. Not me relying on it 😭
Protecting symmetric associations in the interleaved mode against replay attacks is even harder than in the basic mode 💀 In both modes, the NTP state has to be protected between receiving the last non-replayed response and sending the next request, so the request carries the origin timestamp the peer expects. The difference is how many timestamps you need to finish a measurement. In the basic mode, one valid response is enough, and it gets used as soon as it arrives. The interleaved mode needs two consecutive valid responses. So the NTP state needs to be protected at all times, otherwise the timestamps needed to complete the measurement when the second response arrives could get lost 🫶
7. IANA Considerations 🌸
This document has no IANA actions. Nothing to register here, bestie ✨
8. References 📚
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch,
"Network Time Protocol Version 4: Protocol and Algorithms
Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010,
<https://www.rfc-editor.org/info/rfc5905>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.8.2. Informative References
[RFC5906] Haberman, B., Ed. and D. Mills, "Network Time Protocol
Version 4: Autokey Specification", RFC 5906,
DOI 10.17487/RFC5906, June 2010,
<https://www.rfc-editor.org/info/rfc5906>.
[RFC7384] Mizrahi, T., "Security Requirements of Time Protocols in
Packet Switched Networks", RFC 7384, DOI 10.17487/RFC7384,
October 2014, <https://www.rfc-editor.org/info/rfc7384>.
[RFC9109] Gont, F., Gont, G., and M. Lichvar, "Network Time Protocol
Version 4: Port Randomization", RFC 9109,
DOI 10.17487/RFC9109, August 2021,
<https://www.rfc-editor.org/info/rfc9109>.
[SECNTP] Malhotra, A., Van Gundy, M., Varia, M., Kennedy, H.,
Gardner, J., and S. Goldberg, "The Security of NTP's
Datagram Protocol", Cryptology ePrint Archive, Paper
2016/1006, 2016, <https://eprint.iacr.org/2016/1006>.Acknowledgements 🫶
The interleaved modes in this document are based on the implementation written by David Mills in the NTP project (https://www.ntp.org). The broadcast mode spec is based purely on that implementation 🎀 The symmetric mode spec has some modifications. The client/server mode is specified as a new mode that's compatible with the symmetric mode. It's a simplified special case of the symmetric mode, the same way the basic client/server mode is a special case of the basic symmetric mode 🧚
The authors would like to thank Doug Arnold, Roman Danyliw, Reese Enghardt, Daniel Franke, Benjamin Kaduk, Erik Kline, Catherine Meadows, Tal Mizrahi, Steven Sommars, Harlan Stenn, Kristof Teichel, and Gunter Van de Velde for their useful comments and suggestions 💖
Authors' Addresses 🌈
Miroslav Lichvar
Red Hat
Purkynova 115
612 00 Brno
Czech Republic
Email: mlichvar@redhat.com
Aanchal Malhotra
Boston University
111 Cummington St
Boston, MA 02215
United States of America
Email: aanchal4@bu.edu📦 where this page comes from
- ietf: rfc9769 2025-05
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms