RFC 4656
A One-way Active Measurement Protocol (OWAMP)
RFC 4656: A One-way Active Measurement Protocol (OWAMP) 🦋
Okay bestie, the vibe check on RFC 4656 is immaculate ✨ It's a Standards Track doc from September 2006, published under the Network Working Group. The authors are S. Shalunov, B. Teitelbaum, A. Karp, J. Boote, and M. Zekauskas, all from Internet2 🎀. The header doesn't list anything it obsoletes or updates, so it's a fresh start, no drama 💅
Status of This Memo 📜
This document is an Internet standards track protocol for the Internet community, and it's asking for discussion and suggestions for improvements 🌸 If you want the standardization state and status of this protocol, check the current edition of the "Internet Official Protocol Standards" (STD 1). Distribution of this memo is unlimited, so share it with everyone 💜
Copyright Notice ⭐
Copyright (C) The Internet Society (2006). Mic drop 🎤
Abstract 🔥
The One-Way Active Measurement Protocol (OWAMP) measures one-way stuff like one-way delay and one-way loss. Getting high-precision readings on these one-way IP performance metrics became possible once good time sources (like GPS and CDMA) got widely available. OWAMP is what makes these measurements interoperable, and that's the whole point 👑
Table of Contents 📑
1. Introduction ....................................................2
1.1. Relationship of Test and Control Protocols .................3
1.2. Logical Model ..............................................4
2. Protocol Overview ...............................................5
3. OWAMP-Control ...................................................6
3.1. Connection Setup ...........................................6
3.2. Integrity Protection (HMAC) ...............................11
3.3. Values of the Accept Field ................................11
3.4. OWAMP-Control Commands ....................................12
3.5. Creating Test Sessions ....................................13
3.6. Send Schedules ............................................18
3.7. Starting Test Sessions ....................................19
3.8. Stop-Sessions .............................................20
3.9. Fetch-Session .............................................24
4. OWAMP-Test .....................................................27
4.1. Sender Behavior ...........................................28
4.1.1. Packet Timings .....................................28
4.1.2. OWAMP-Test Packet Format and Content ...............29
4.2. Receiver Behavior .........................................33
5. Computing Exponentially Distributed Pseudo-Random Numbers ......35
5.1. High-Level Description of the Algorithm ...................35
5.2. Data Types, Representation, and Arithmetic ................36
5.3. Uniform Random Quantities .................................37
6. Security Considerations ........................................38
6.1. Introduction ..............................................38
6.2. Preventing Third-Party Denial of Service ..................38
6.3. Covert Information Channels ...............................39
6.4. Requirement to Include AES in Implementations .............39
6.5. Resource Use Limitations ..................................39
6.6. Use of Cryptographic Primitives in OWAMP ..................40
6.7. Cryptographic Primitive Replacement .......................42
6.8. Long-term Manually Managed Keys ...........................43
6.9. (Not) Using Time as Salt ..................................44
6.10. The Use of AES-CBC and HMAC ..............................44
7. Acknowledgements ...............................................45
8. IANA Considerations ............................................45
9. Internationalization Considerations ............................46
10. References ....................................................46
10.1. Normative References .....................................46
10.2. Informative References ...................................47
Appendix A: Sample C Code for Exponential Deviates ................49
Appendix B: Test Vectors for Exponential Deviates .................541. Introduction 🌈
The IETF IP Performance Metrics (IPPM) working group already defined metrics for one-way packet delay [RFC2679] and loss [RFC2680] across Internet paths 🛣️ There are several measurement platforms that actually collect these metrics today [SURVEYOR] [SURVEYOR-INET] [RIPE] [BRIX], but there's no standard that lets you start test streams or swap packets to collect singleton metrics in an interoperable way. It's giving chaos 😭
With GPS and CDMA-based time sources getting more affordable and widely available, hosts now have really accurate time sources. They get these either directly, or by sitting close to Network Time Protocol (NTP) primary (stratum 1) time servers ⏱️ By standardizing a technique for collecting IPPM one-way active measurements, the goal is an environment where these metrics can be gathered across a much broader mesh of Internet paths than is possible right now. The dream? Open OWAMP servers everywhere, so measuring one-way delay becomes as normal as measuring round-trip time with an ICMP-based tool like ping 🧚
Other design goals of OWAMP include being hard to detect and manipulate, security, logical separation of control and test functionality, and support for small test packets 💖 (Being hard to detect makes it harder for intermediaries sitting in the middle of the network to mess with measurements 🙈)
OWAMP test traffic is hard to detect because it's just a stream of UDP packets going to and from negotiated port numbers, with potentially nothing static in the packets (the size is negotiated too) 🦋 OWAMP also has an encrypted mode that hides the traffic even more and makes it impossible to alter timestamps without it being detectable 🔒
Security features include optional authentication and/or encryption of control and test messages 🫶 These can help prevent unauthorized access to results, or stop man-in-the-middle attacks that try to give OWAMP test streams special treatment, or that try to change sender-generated timestamps to fake the test results 💀
In this document, the key words "MUST", "REQUIRED", "SHOULD", "RECOMMENDED", and "MAY" are to be interpreted as described in [RFC2119].
1.1. Relationship of Test and Control Protocols 🧩
OWAMP is actually two inter-related protocols: OWAMP-Control and OWAMP-Test. OWAMP-Control initiates, starts, and stops test sessions and fetches their results, whereas OWAMP-Test exchanges test packets between two measurement nodes ✨
OWAMP-Test can be used with a control protocol other than OWAMP-Control, but the authors deliberately put both protocols in the same RFC. The goal is to encourage implementing and deploying OWAMP-Control as a common denominator control protocol for one-way active measurements 👑 Having a complete, open one-way active measurement solution that's simple to implement and deploy is crucial to a future where inter-domain one-way active measurement becomes as commonplace as ping. They neither anticipate nor recommend that OWAMP-Control form the foundation of a general-purpose extensible measurement and monitoring control protocol 🙅♀️
OWAMP-Control is designed to negotiate one-way active measurement sessions and retrieve results in a straightforward way 💅 At session initiation, sender and receiver addresses and port numbers get negotiated, along with session start time, session length, test packet size, the mean Poisson sampling interval for the test stream, and some attributes of the very general [RFC 2330] notion of packet type, including packet size and per-hop behavior (PHB) [RFC2474]. That last bit could be used to measure one-way network characteristics across differentiated services networks 🍓 OWAMP-Control also supports per-session encryption and authentication for both test and control traffic, measurement servers that can act as proxies for test stream endpoints, and the exchange of a seed value for the pseudo-random Poisson process that describes the test stream generated by the sender 🌸
We believe OWAMP-Control can effectively support one-way active measurement in a variety of environments, from publicly accessible measurement beacons running on arbitrary hosts to network monitoring deployments inside private corporate networks 🎀 If integration with Simple Network Management Protocol (SNMP) or proprietary network management protocols is required, gateways may be created.
Part 1 of 13 is done, bestie 🫶 Part 2 is coming next, so stay tuned 💜
1.2. Logical Model ✨
okay so the roles are separated on purpose, bestie, so you can mix and match them however you want 💅 Here's the cast:
Session-Sender: the sending endpoint of an OWAMP-Test session 📤Session-Receiver: the receiving endpoint of an OWAMP-Test session 📥Server: an end system that manages one or more OWAMP-Test sessions. It can configure per-session state in the session endpoints and can return the results of a test session 🎀Control-Client: an end system that starts requests for OWAMP-Test sessions, triggers the start of a set of sessions, and may trigger their termination 🎬Fetch-Client: an end system that starts requests to fetch the results of completed OWAMP-Test sessions 🧚
here's one possible way the roles can hang out together 🦋
+----------------+ +------------------+
| Session-Sender |--OWAMP-Test-->| Session-Receiver |
+----------------+ +------------------+
^ ^
| |
| |
| |
| +----------------+<----------------+
| | Server |<-------+
| +----------------+ |
| ^ |
| | |
| OWAMP-Control OWAMP-Control
| | |
v v v
+----------------+ +-----------------+
| Control-Client | | Fetch-Client |
+----------------+ +-----------------+(the unlabeled links in that picture aren't specced by this document, so they could be proprietary protocols 🤷♀️)
and roles can totally be played by the same host 🫶 in the picture above there could be just two hosts: one playing Control-Client, Fetch-Client, and Session-Sender, and the other playing Server and Session-Receiver. it looks like this:
+-----------------+ +------------------+
| Control-Client |<--OWAMP-Control-->| Server |
| Fetch-Client | | |
| Session-Sender |---OWAMP-Test----->| Session-Receiver |
+-----------------+ +------------------+finally, lowkey the most iconic part 😭 a lot of Internet paths include segments that carry IP over ATM, so delay and loss measurements can pick up the effects of ATM segmentation and reassembly (SAR). so OWAMP was designed to allow small test packets that fit inside the payload of a single ATM cell. and yes, this is only achieved in unauthenticated mode 💀
2. Protocol Overview ✨
okay so OWAMP is made of two best friends who work together: OWAMP-Control and OWAMP-Test 👯♀️ OWAMP-Control rides on top of TCP and is used to start and control measurement sessions and to fetch their results. OWAMP-Test rides on top of UDP and sends singleton measurement packets along the Internet path being tested 🌊
the person starting a measurement session opens a TCP connection to the well-known port 861 on the target point 🎯 that connection stays open for the whole duration of the OWAMP-Test sessions. an OWAMP server SHOULD listen on this well-known port 🎀
OWAMP-Control messages only get sent before OWAMP-Test sessions actually start and after they're completed. the one exception is an early Stop-Sessions message 🛑
OWAMP-Control and OWAMP-Test support three modes: unauthenticated, authenticated, and encrypted 🔐 the authenticated and encrypted modes require that the endpoints share a secret, so make sure you've got that sorted first 🤭
all multi-octet quantities in this document are unsigned integers in network byte order, unless it says otherwise 🔢✨
3. OWAMP-Control 💜
the type of each OWAMP-Control message can be found after reading the first 16 octets 👀 and the length of each message can be worked out once you've read its fixed-size part. no message is shorter than 16 octets, so you'll always have enough to peek at 🧚
now for the safety tea ☕ an implementation SHOULD expunge unused state so that attackers can't cause denial-of-service, and so the server's memory doesn't grow without bound 🚨 for example, if the full control message hasn't arrived within some number of minutes after it was expected, the TCP connection associated with the OWAMP-Control session SHOULD be dropped 🙅♀️ with no other considerations in play, 30 minutes seems like a reasonable upper bound ⏰ literally a whole vibe check on your server's patience 💅
3.1. Connection Setup 🎀
Okay so, before a Control-Client or a Fetch-Client can send any commands to a server, they have to set up a connection first 💅. A client opens a TCP connection to the server on the well-known port 861 🔌. The server answers with its greeting 👋:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Unused (12 octets) |
| |
|+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Modes |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Challenge (16 octets) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Salt (16 octets) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Count (4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| MBZ (12 octets) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+So the Modes field is where the vibe gets decided 🎭. Mode 1 means unauthenticated, 2 means authenticated, and 4 means encrypted 🔐. The server puts the bit-wise OR of every mode it's willing to support in this session into Modes. Only the last three bits get used, which means the first 29 bits MUST be zero. A client MUST ignore the values in the first 29 bits of the Modes value. Those bits are saved for future protocol extensions, and that's the only intended extension mechanism 🌈.
Challenge is a random sequence of octets that the server generates 🎲. The client uses it later to prove it knows a shared secret, and we'll get to how that works in a sec.
Salt and Count are the ingredients for deriving a key from a shared secret 🧂. Salt MUST be generated pseudo-randomly (independently of anything else in this document). Count MUST be a power of 2. Count MUST be at least 1024. Count SHOULD be increased as more computing power becomes common 📈.
If the Modes value is zero, the server isn't interested in talking to this client, so it MAY close the connection right away 🚪. The client SHOULD close the connection if it gets a greeting with Modes equal to zero. The client MAY also close the connection if the mode it wanted is unavailable 🙅♀️.
Otherwise, the client MUST respond with the Set-Up-Response message 💌:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mode |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. KeyID (80 octets) .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Token (64 octets) .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Client-IV (16 octets) .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Here, Mode is the mode the client picks for this OWAMP-Control session 🎯. That same mode is also used for every OWAMP-Test session started under this OWAMP-Control session. In Mode, one or zero bits MUST be set within the last three bits. If one bit is set within the last three bits, that bit MUST indicate a mode the server agreed to use (i.e., the same bit MUST have been set by the server in the server greeting). The first 29 bits of Mode MUST be zero. A server MUST ignore the values of the first 29 bits. If zero Mode bits are set by the client, the client is saying "nah, I'm out" 🙃, and in that case the client and the server SHOULD close the TCP connection associated with the OWAMP-Control session.
In unauthenticated mode, KeyID, Token, and Client-IV are unused 🫥. Otherwise, KeyID is a UTF-8 string of up to 80 octets (if it's shorter, it gets padded with zero octets). It tells the server which shared secret the client wants to use to authenticate or encrypt 🗝️. Token is the concatenation of a 16-octet challenge, a 16-octet AES Session-key used for encryption, and a 32-octet HMAC-SHA1 Session-key used for authentication 🧩. The token itself is encrypted using the AES (Advanced Encryption Standard) [AES] in Cipher Block Chaining (CBC). Encryption MUST be performed using an Initialization Vector (IV) of zero and a key derived from the shared secret associated with KeyID. Both the server and the client use the same mappings from KeyIDs to shared secrets. The server can handle sessions with more than one client, so it uses KeyIDs to pick the right secret key, and a client would typically have different secret keys for different servers. It's basically the same deal as with passwords 🔑.
The shared secret is a passphrase, and it MUST not contain newlines. The secret key is derived from the passphrase using the password-based key derivation function PBKDF2 (PKCS #5) [RFC2898]. PBKDF2 needs a few parameters: the PRF is HMAC-SHA1 [RFC2104], and the salt and count are the ones the server transmitted 🧁.
The AES Session-key, HMAC Session-key, and Client-IV are all generated randomly by the client 🎰. AES Session-key and HMAC Session-key MUST be generated with enough entropy that they don't weaken the underlying cipher [RFC4086]. Client-IV only needs to be unique, meaning it MUST never be repeated for different sessions using the same secret key. A simple way to get that without a bunch of annoying state is to generate Client-IV values with a cryptographically secure pseudo-random number source. If you do that, the first repeat is unlikely to show up before 2^64 sessions with the same secret key have happened 🌌.
The server MUST respond with the Server-Start message 🚀:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| MBZ (15 octets) |
| |
| +-+-+-+-+-+-+-+-+
| | Accept |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Server-IV (16 octets) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Start-Time (Timestamp) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MBZ (8 octets) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+The MBZ parts MUST be zero, and the client MUST ignore their value. MBZ (MUST be zero) fields here and after all have the same meaning: the party sending the message MUST set the field so that all bits are equal to zero, and the party interpreting the message MUST ignore the value. This way, the field could be used for future extensions 🧸.
Server-IV is generated randomly by the server. In unauthenticated mode, Server-IV is unused 🙈.
The Accept field shows whether the server is willing to keep going 🤝. A zero value means the server accepts the authentication and is willing to handle further transactions ✅. A non-zero value means the server either doesn't accept the authentication or, for some other reason, won't handle further transactions in this OWAMP-Control session ❌. You can see the full list of Accept values in Section 3.3, "Values of the Accept Field" 📋.
If a negative (non-zero) response is sent, the server MAY (and the client SHOULD) close the connection after this message 👋.
Start-Time is a timestamp for when the current instance of the server started operating ⏰. (For example, on a multi-user general purpose operating system, it could be the time the server process was started.) If Accept is non-zero, Start-Time SHOULD have all of its bits set to zero. In authenticated and encrypted modes, Start-Time is encrypted as described in Section 3.4, "OWAMP-Control Commands", unless Accept is non-zero. Authenticated and encrypted mode can't be entered unless the control connection can be initialized 🔒.
The timestamp format is described in Section 4.1.2 🕰️. The same instance of the server SHOULD report the exact same Start-Time value to each client in each session 💜.
And that's it, the previous transactions are the whole connection setup ✨.
3.2. Integrity Protection (HMAC) 🔐
Okay so every message in OWAMP-Control (we also call these commands in this doc, bc it's the same thing 💅) gets its own HMAC stamped on it. The HMAC is HMAC-SHA1 cut down to 128 bits, so every HMAC field is 16 octets. An HMAC needs a key, and the HMAC Session-key gets sent along with the AES Session-key during OWAMP-Control connection setup. The HMAC Session-key SHOULD be derived independently of the AES Session-key (an implementation, of course, MAY use the same mechanism to generate the random bits for both keys) ✨.
Each HMAC covers everything sent in one direction, starting right after the previous HMAC (not including it) and going up to the start of the new HMAC. So once encryption is set up, each bit of the OWAMP-Control connection gets authenticated by an HMAC exactly once. It's giving perfect coverage 🫶.
When encrypting, authentication happens before encryption, so the HMAC blocks get encrypted along with the rest of the stream. When decrypting, the order flips, obviously: decrypt first, then check the HMAC, then use the data 🔄.
The HMAC MUST be checked as early as possible to avoid using and propagating corrupt data. No corrupt data in the group chat, periodt 🚫
In open mode, the HMAC fields are unused and have the same semantics as MBZ fields 🌸.
3.3. Values of the Accept Field 💌
Accept values are how the server replies to client requests throughout the OWAMP-Control protocol. The full set of valid Accept field values is below 👑:
0 OK.
1 Failure, reason unspecified (catch-all).
2 Internal error.
3 Some aspect of request is not supported.
4 Cannot perform request due to permanent resource limitations.
5 Cannot perform request due to temporary resource limitations.All other values are reserved. The sender of the message MAY use the value of 1 for all non-zero Accept values. A message sender SHOULD use the correct Accept value if it is going to use other values. The message receiver MUST interpret all values of Accept other than these reserved values as 1. This way, the other values stay open for future extensions 🦋.
3.4. OWAMP-Control Commands 🎀
In authenticated or encrypted mode (which are identical as far as OWAMP-Control is concerned, and only differ in OWAMP-Test), everything after that gets encrypted with the AES Session-key (using CBC mode) and authenticated with the HMAC Session-key. The client encrypts everything it sends through the freshly established OWAMP-Control connection using stream encryption, with Client-IV as the IV. The server does the same on its side, using Server-IV as the IV 🧚.
The IVs themselves are sent in cleartext. Encryption starts with the block right after the block that contains the IV. The two streams (one going from the client to the server and one going back) are encrypted independently, each with its own IV, but they both use the same key (the AES Session-key) 🔑.
The following commands are available to the client: Request-Session, Start-Sessions, Stop-Sessions, and Fetch-Session. The Stop-Sessions command is available to both the client and the server. (The server can also send other messages in response to commands it gets 💬.)
After the client sends the Start-Sessions command, and until it both sends and receives the Stop-Sessions command (in no particular order), it is said to be conducting active measurements. The server is said to be conducting active measurements in the same way, starting once it receives the Start-Sessions command and ending once it both sends and receives the Stop-Sessions command (again, in an unspecified order) 📊.
While conducting active measurements, the only command available is Stop-Sessions 🛑.
These commands are described in detail below 👀.
3.5. Creating Test Sessions 🧪
Individual one-way active measurement sessions get set up with a simple request/response protocol. An OWAMP client MAY issue zero or more Request-Session messages to an OWAMP server, and the server MUST respond to each one with an Accept-Session message. An Accept-Session message MAY refuse a request 🙅♀️.
The format of the Request-Session message looks like this 📦:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1 | MBZ | IPVN | Conf-Sender | Conf-Receiver |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of Schedule Slots |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of Packets |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender Port | Receiver Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Sender Address (cont.) or MBZ (12 octets) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receiver Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Receiver Address (cont.) or MBZ (12 octets) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| SID (16 octets) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Padding Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Start Time |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timeout, (8 octets) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type-P Descriptor |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MBZ (8 octets) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| HMAC (16 octets) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+This is immediately followed by one or more schedule slot descriptions (the number of schedule slots is specified in the "Number of Schedule Slots" field above) 🗓️:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Slot Type | |
+-+-+-+-+-+-+-+-+ MBZ (7 octets) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Slot Parameter (Timestamp) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+These are immediately followed by the HMAC 🔏:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| HMAC (16 octets) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+All these pieces make up one logical message: the Request-Session command 🧩.
Above, the first octet (1) tells you this is the Request-Session command 🎯.
IPVN is the IP version number for the Sender and Receiver. When the IP version number is 4, 12 octets follow the 4-octet IPv4 address stored in Sender Address and Receiver Address. These octets MUST be set to zero by the client and MUST be ignored by the server. Currently meaningful IPVN values are 4 and 6 🌈.
Conf-Sender and Conf-Receiver MUST be set to 0 or 1 by the client. The server MUST interpret any non-zero value as 1. If the value is 1, the server is being asked to configure the corresponding agent (sender or receiver). In this case, the corresponding Port value SHOULD be disregarded by the server. At least one of Conf-Sender and Conf-Receiver MUST be 1. (Both can be set, in which case the server is being asked to set up a session between two hosts it can configure 🤝.)
Number of Schedule Slots, as mentioned before, specifies how many slot records go between the two HMAC blocks. The sender uses it to figure out when to send test packets (see next section ⏰).
Number of Packets is the number of active measurement packets to be sent during this OWAMP-Test session (note that either the server or the client can abort the session early 🛑).
If Conf-Sender is not set, Sender Port is the UDP port that OWAMP-Test packets will be sent from. If Conf-Receiver is not set, Receiver Port is the UDP port that OWAMP-Test packets are requested to be sent to 📮.
The Sender Address and Receiver Address fields hold, respectively, the sender and receiver addresses of the end points of the Internet path over which an OWAMP test session is requested 🛣️.
SID is the session identifier. It can be used in later sessions as an argument for the Fetch-Session command. It is only meaningful if Conf-Receiver is 0. That means the SID is always generated by the receiving side. See the end of the section for how the SID gets generated 🪪.
Padding Length is the number of octets to be appended to the normal OWAMP-Test packet (see more on padding in the discussion of OWAMP-Test) 🫧.
Start Time is the time when the session is to be started (but not before the Start-Sessions command is issued). This timestamp uses the same format as OWAMP-Test timestamps 🕰️.
Timeout (or a loss threshold) is an interval of time, expressed as a timestamp. A packet belonging to the test session being set up by the current Request-Session command will be considered lost if it is not received within Timeout seconds after it is sent 💀.
Okay so the Type-P Descriptor only covers a slice of the (absolutely massive) Type-P space, bestie 💅 Here's the tea: if the first two bits are 00, the next six bits are the requested Differentiated Services Codepoint (DSCP) value for the sent OWAMP-Test packets, as defined in [RFC2474] ✨. If the first two bits are 01, the next 16 bits are the requested PHB Identification Code (PHB ID), as defined in [RFC2836] 🦋.
So an all-zeros value means default best-effort service. Iconic, simple, and no notes 🫶
If Conf-Sender is set, the Type-P Descriptor gets used to configure the sender so it sends packets according to its value. If Conf-Sender is not set, the Type-P Descriptor is just a declaration of how the sender will be configured 🎀
If Conf-Sender is set and the server doesn't recognize the Type-P Descriptor, or it can't or doesn't want to set the matching attributes on OWAMP-Test packets, it SHOULD reject the session request. If Conf-Sender is not set, the server SHOULD accept or reject the session and totally ignore the Type-P Descriptor value 🙈
To each Request-Session message, an OWAMP server MUST respond with an Accept-Session message:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Accept | MBZ | Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
| |
| SID (16 octets) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| MBZ (12 octets) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| HMAC (16 octets) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+In this message, zero in the Accept field means the server is willing to conduct the session ✅ A non-zero value means the request was rejected. The full list of Accept values lives in Section 3.3, "Values of the Accept Field".
If the server rejects a Request-Session message, it SHOULD not close the TCP connection. The client MAY close it if it gets a negative response to the Request-Session message 🌸
The meaning of Port in the response depends on the values of Conf-Sender and Conf-Receiver in the query that asked for it. If both were set, the Port field is unused. If only Conf-Sender was set, Port is the port to expect OWAMP-Test packets from. If only Conf-Receiver was set, Port is the port that OWAMP-Test packets get sent to 🧚
If only Conf-Sender was set, the SID field in the response is unused. Otherwise, SID is a unique server-generated session identifier. It can be used later as a handle to fetch the results of a session 💜
SIDs SHOULD be constructed by concatenating the 4-octet IPv4 IP number of the generating machine, an 8-octet timestamp, and a 4-octet random value. To reduce the chance of collisions, if the generating machine has any IPv4 addresses (except loopback), one of them SHOULD be used for SID generation, even if all communication is IPv6-based. If it has no IPv4 addresses at all, the last four octets of an IPv6 address MAY be used instead. Note that SID is always chosen by the receiver. If truly random values aren't available, the SID has to be made unpredictable, because knowing the SID might be used for access control 🔥
Lowkey the SID is a secret-ish handle, so unpredictability matters. Don't skip it, bestie 🙈
3.6. Send Schedules
The sender and the receiver both need to know the same send schedule. That way, when packets get lost, the receiver still knows when they were supposed to be sent 🦋 It's desirable to compress common schedules while still being able to use an arbitrary one for test sessions. In lots of cases the schedule is repeated sequences of packets: the sequence performs some test, and the test gets repeated a bunch of times to gather statistics 📊
To make this happen, we have a schedule with a given number of slots. Each slot has a type and a parameter. Two types are supported: an exponentially distributed pseudo-random quantity (denoted by a code of 0) and a fixed quantity (denoted by a code of 1). The parameter is expressed as a timestamp and specifies a time interval. For a type 0 slot (exponentially distributed pseudo-random quantity), that interval is the mean value (or 1/lambda if the distribution density function is expressed as lambda*exp(-lambda*x) for positive values of x). For a type 1 (fixed quantity) slot, the parameter is the delay itself. The sender starts at the beginning of the schedule and runs through the slots: for a type 0 slot, wait an exponentially distributed time with a mean of the specified parameter and then send a test packet (and move on to the next slot); for a type 1 slot, wait the specified time and send a test packet (and move on to the next slot). The schedule is circular: when there are no more slots, the sender goes back to the first slot 🔁
The sender and the receiver need to be able to reproducibly execute the entire schedule (so if a packet is lost, the receiver can still attach a send timestamp to it) 💅 Type 1 slots are trivial to reproducibly execute. To reproducibly execute type 0 slots, we need to be able to generate pseudo-random exponentially distributed quantities in a reproducible manner. The way this is accomplished is discussed later in Section 5, "Computing Exponentially Distributed Pseudo-Random Numbers" 🧠
Using this mechanism, you can easily specify common testing scenarios. Here are some examples:
- Poisson stream: a single slot of type 0.
- Periodic stream: a single slot of type 1.
- Poisson stream of back-to-back packet pairs: two slots, type 0 with a non-zero parameter and type 1 with a zero parameter.
Further, a completely arbitrary schedule can be specified (albeit inefficiently) by making the number of test packets equal to the number of schedule slots. In this case, the complete schedule is transmitted in advance of an OWAMP-Test session 🎀
3.7. Starting Test Sessions
Once you've requested one or more test sessions and gotten affirmative Accept-Session responses, an OWAMP client MAY start the requested test sessions by sending a Start-Sessions message to the server 🚀
The format of this message is as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 2 | |
+-+-+-+-+-+-+-+-+ |
| MBZ (15 octets) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| HMAC (16 octets) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+The server MUST respond with a Start-Ack message (which SHOULD be sent as quickly as possible). Start-Ack messages have the following format:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Accept | |
+-+-+-+-+-+-+-+-+ |
| MBZ (15 octets) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| HMAC (16 octets) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+If Accept is non-zero, the Start-Sessions request was rejected. Zero means the command was accepted ✨ The full list of Accept values is in Section 3.3, "Values of the Accept Field". The server MAY, and the client SHOULD, close the connection in the case of a rejection 🙈
The server SHOULD start all OWAMP-Test streams immediately after it sends the response, or immediately after their specified start times, whichever is later. If the client represents a Sender, the client SHOULD start its OWAMP-Test streams immediately after it sees the Start-Ack response from the Server (if the Start-Sessions command was accepted), or immediately after their specified start times, whichever is later. See more on OWAMP-Test sender behavior in a separate section below 💖
3.8. Stop-Sessions ✨
okay so either the Control-Client or the Server can send a Stop-Sessions message 💅 this is the command that wraps things up, and here's what it looks like:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 3 | Accept | MBZ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of Sessions |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MBZ (8 octets) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+right after the header come zero or more session description records 🦋 (how many is set by the Number of Sessions field up top). each record tells you which packets were actually sent by the sender process, versus the ones it skipped. the record header looks like this:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
| |
| SID (16 octets) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Seqno |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of Skip Ranges |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+then you get zero or more Skip Range descriptions, again counted by the Number of Skip Ranges field 🎀 a Skip Range is just two sequence numbers that together mark a stretch of packets that never got sent:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
| First Seqno Skipped |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Last Seqno Skipped |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+skip ranges MUST be in order 🌸 and the last block of data (full or incomplete, 16 octets) MUST be padded with zeros if it needs it. that's what makes sure the next session description record starts on a block boundary, so it stays neat and tidy 🧚
finally, a single 16-octet HMAC block gets glued onto the end to complete the message 🔐
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| HMAC (16 octets) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+all of those pieces together count as one logical message: the Stop-Sessions command. the first octet (3) is what tells you it's a Stop-Sessions command 🙌
About Accept: a non-zero value means something went wrong. a zero means it finished normally, even if that was a little early 🌈 the full list of values lives in Section 3.3, "Values of the Accept Field".
ifAcceptis non-zero (from either side), then the results of every OWAMP-Test session spawned by this OWAMP-Control session SHOULD be treated as invalid 💀 and that's true even if a Fetch-Session with the SID from this session somehow works for a different OWAMP-Control session. ifAcceptnever got sent at all (for any reason, including the TCP connection for OWAMP-Control breaking), the results of those OWAMP-Test sessions MAY be treated as invalid instead.
the Number of Sessions field just tells you how many session description records come right after the Stop-Sessions header ✨
The count has to be exact. Number of Sessions MUST hold the number of send sessions that the local side started and that haven't already been ended by an earlier Stop-Sessions command. so, the Control-Client MUST account for each accepted Request-Session where Conf-Receiver was set, and the Control-Server MUST account for each accepted Request-Session where Conf-Sender was set 🫶 if the message doesn't account for exactly the send sessions that side controls, then it's invalid. the connection SHOULD be closed, and any results gathered are considered invalid 😭
each session description record stands for one OWAMP-Test session. SID is the session identifier that says which send session is being described 🦋
Next Seqno is the next sequence number that would have been sent from this send session. for completed sessions, it'll match NumPackets from the Request-Session 💜
Number of Skip Ranges counts the holes that actually happened in the sending process, meaning the stretches of packets the sender never actually sent. for example, say a send session starts too late to send the first 10 packets, and that's the only hole in the schedule. then Number of Skip Ranges is 1, and the one Skip Range has First Seqno Skipped equal to 0 and Last Seqno Skipped equal to 9 🍓 there's more on this in the "Sender Behavior" section.
When the connection breaks: if the OWAMP-Control connection drops while Stop-Sessions is being sent, the receiver MAY not completely invalidate the session results 🙈 but it MUST discard all record of packets that come after (meaning, that have a greater sequence number than) the last packet it actually received before any lost-packet records. that helps tell apart the packets lost in the network from packets the sending process never sent in the first place.
if a receiver of an OWAMP-Test session learns, from a Stop-Sessions message, that the OWAMP-Test sender's last sequence number is lower than any sequence number it actually received, then the results of the entire OWAMP-Test session MUST be invalidated. it's giving "start over" energy 💀
Cleaning up the window: when a receiver of an OWAMP-Test session gets a Stop-Sessions command, it MUST discard any packet records (lost ones included) whose computed send time falls between the current time minus Timeout and the current time. this keeps the loss and duplicate stats consistent, especially when Timeout is longer than it takes for the Stop-Sessions command to happen 📊✨
Finishing sessions the proper way: each side of the control connection SHOULD wait until all of its sessions are complete before sending Stop-Sessions 👑 a session counts as complete Timeout after the scheduled time of its last sequence number. endpoints MAY add a small increment to that completed time for send endpoints, so the Stop-Sessions message reaches the receiver endpoint after Timeout has passed 🎀
Stopping early: to end sessions prematurely, the party starting this command MUST stop its OWAMP-Test send streams before sending it, so the Session Packets Sent values are accurate 🌸 then that party SHOULD wait until the response Stop-Sessions message comes back before it stops the receiver streams. that way it can use the values from the received Stop-Sessions message to validate the data. bestie, that's the whole ending arc 💖
3.9. Fetch-Session ✨
okay so this is the client command for Fetch-Session 🎀 it looks like this:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 4 | |
+-+-+-+-+-+-+-+-+ |
| MBZ (7 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Begin Seq |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| End Seq |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| SID (16 octets) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| HMAC (16 octets) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Begin Seq is the sequence number of the first packet you're asking for 🦋 and End Seq is the sequence number of the last one. If Begin Seq is all zeros and End Seq is all ones, that's a complete session request, aka "give me the whole thing" 💜
okay now the real tea 🫶 if someone asks for a complete session and it's still running, or it ended in any way that wasn't a normal finish, the request to fetch session results MUST be denied. no exceptions bestie 🙅♀️
if they ask for an incomplete session instead, all the packets received so far that fall into the requested range SHOULD be returned ✨ also, since no commands can be sent between Start-Sessions and Stop-Sessions, incomplete requests can only happen on a different OWAMP-Control connection (from the same or a different host as the Control-Client) 🧚
the server MUST respond with a Fetch-Ack message 💅 it looks like this:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Accept | Finished | MBZ (2 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Seqno |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of Skip Ranges |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of Records |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| HMAC (16 octets) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+so, same rule as always: a non-zero Accept means the command got rejected 🙅♀️ when that happens, the server MUST specify zero for all remaining fields. and the client MUST ignore all the remaining fields (except for the HMAC) if Accept is non-zero. the full list of Accept values lives in Section 3.3, "Values of the Accept Field" 📖
- Finished is non-zero if the OWAMP-Test session has terminated 🏁
- Next Seqno is the next sequence number that would have been sent from this send session. for completed sessions it'll match NumPackets from the Request-Session. this info only exists once the session has ended, so if Finished is zero, the server MUST set Next Seqno to zero 🫠
- Number of Skip Ranges is how many holes actually happened in the sending process. same deal: only available after the session ends, and if Finished is zero, the server MUST set it to zero 🕳️
- Number of Records is how many packet records fall inside the requested range. this could be less than the Number of Packets from the Request-Session if the session ended early, or more because of duplicates 👯♀️
if Accept was non-zero, that's the end of the response to the Fetch-Session message 💀 but if Accept was 0, the server MUST immediately send the OWAMP-Test session data in question 🚀
the session data is made of these pieces, concatenated together 🧩
- a reproduction of the Request-Session command that started the session. it's modified so the actual sender and receiver port numbers the OWAMP-Test session used always show up in the reproduction
- zero or more Skip Range descriptions (as specified). the last block (16 octets) of Skip Range descriptions gets padded with zeros if needed, and that block might be full or incomplete
- 16 octets of HMAC
- zero or more packet records (as specified). the last block (16 octets) of data gets padded with zeros if needed, and again it might be full or incomplete
- 16 octets of HMAC
Skip Range descriptions are basically two sequence numbers that together mark a range of packets that were not sent 🌸
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
| First Seqno Skipped |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Last Seqno Skipped |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Skip Range descriptions should be sent out in order, sorted by First Seqno. if any Skip Ranges overlap or come out of order, the session data is considered invalid, the connection SHOULD be closed, and any results you got are considered invalid too 🚨 this is giving "do not pass go" energy
each packet record is 25 octets 🎀 it holds a 4-octet sequence number, an 8-octet send timestamp, a 2-octet send timestamp error estimate, an 8-octet receive timestamp, a 2-octet receive timestamp error estimate, and a 1-octet Time To Live (TTL), or Hop Limit in IPv6 ✨
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
00| Seq Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
04| Send Error Estimate | Receive Error Estimate |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
08| Send Timestamp |
12| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
16| Receive Timestamp |
20| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
24| TTL |
+-+-+-+-+-+-+-+-+packet records get sent out in the same order the real packets were received 📬 so the data is in arrival order, bestie.
now, lost packets (if any losses were detected during the OWAMP-Test session) MUST show up in the sequence of packets 😭 they can appear right when the loss was detected or at any later point. you can spot a lost packet record by these signs 🔍
- its send timestamp is filled with the presumed send time (as computed by the send schedule)
- its send error estimate is filled with Multiplier=1, Scale=64, and S=0 (check the OWAMP-Test description for what these quantities mean and how the timestamp format and error estimate format work)
- its receive error estimate is a normal one, based on the error of the clock that was used to declare the packet lost. (it gets declared lost if it isn't received by the Timeout after the presumed send time, as measured by the receiver's clock ⏰)
- its receive timestamp is all zero bits
- its TTL value is 255
4. OWAMP-Test 🌈
okay this section is all about OWAMP-Test 💖 it runs over UDP, using the sender and receiver IP and port numbers that got negotiated during the Request-Session exchange 🦋
just like OWAMP-Control, OWAMP-Test has three modes: unauthenticated, authenticated, and encrypted. every OWAMP-Test session spawned by an OWAMP-Control session inherits that session's mode 🔐
the OWAMP-Control client, the OWAMP-Control server, the OWAMP-Test sender, and the OWAMP-Test receiver can all potentially be different machines 🖥️ (in a typical case we expect there will only be two machines, so no stress 🫶)
4.1. Sender Behavior 💅
4.1.1. Packet Timings ⏱️
okay so the send schedules are based on slots (we covered those earlier) and the scheduled session start time 🎀 together those let the sender and the receiver compute the exact same packet sending schedule, totally independently of each other 🧠 and these sending schedules are independent for different OWAMP-Test sessions, even if they're all governed by the same OWAMP-Control session 💜
let's say we're looking at any OWAMP-Test session. once the Start-Sessions exchange is complete, the sender is ready to start sending packets ✨ under normal OWAMP circumstances, the time to send the first packet is right around the corner (maybe a fraction of a second away) 🏃♀️
the sender SHOULD send packets as close as possible to their scheduled time, with one exception: if the scheduled time to send is in the past and it's separated from the present by more than Timeout time, the sender MUST NOT send that packet 🙅♀️ (honestly, a packet like that would be considered lost by the receiver anyway, so why bother 💀)
the sender MUST keep track of which packets it doesn't send 📝 it uses that list to tell the receiver what got skipped by setting Skip Ranges in the Stop-Sessions message from sender to receiver when the test wraps up. the Skip Ranges also go to a Fetch-Client as part of the session data results 🎁
holes in the sending schedule can happen for a few reasons 🕳️
- a time in the past was specified in the Request-Session command
- the Start-Sessions exchange took unexpectedly long
- the sender couldn't start serving the OWAMP-Test session on time because of internal scheduling problems in the OS
packets that are in the past but separated from the present by less than the Timeout value SHOULD be sent as quickly as possible 🏎️ with normal test rates and timeout values, the number of packets in a burst like that stays limited. still though, hosts SHOULD NOT intentionally schedule sessions so that bursts like that happen 🙈
and regardless of any scheduling delays, each packet that actually gets sent MUST have the best possible approximation of its real time of departure as its timestamp (in the packet) ⭐ no fudging the time, periodt 💅
4.1.2. OWAMP-Test Packet Format and Content ✨
okay so the sender sends the receiver a stream of packets 📦, spaced out by whatever schedule got set in the Request-Session command. The sender SHOULD set the TTL in IPv4 (or Hop Limit in IPv6) in the UDP packet to 255 💅. The body of each UDP packet changes depending on the mode, so here's both layouts 🎀
For unauthenticated mode:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error Estimate | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
. .
. Packet Padding .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+For authenticated and encrypted modes:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| MBZ (12 octets) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error Estimate | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| MBZ (6 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| HMAC (16 octets) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Packet Padding .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+The timestamp uses the same format as in [RFC1305] 🕰️ The first 32 bits are the unsigned integer number of seconds elapsed since 0h on 1 January 1900, and the next 32 bits are the fractional part of a second that has elapsed since then. So Timestamp looks like this:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Integer part of seconds |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Fractional part of seconds |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+The Error Estimate tells you how much error and synchronization slop there might be 🎯 It looks like this:
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S|Z| Scale | Multiplier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+The first bit, S, SHOULD be set if the party making the timestamp has a clock synced to UTC using an external source 🛰️ For example, it should be set if GPS hardware is used and says it has a current position and time, or if NTP is used and says it has synced to an external source (stratum 0 sources count too, etc.). If there's no real notion of external sync for the time source, the bit SHOULD NOT be set. The next bit has the same vibe as the MBZ fields everywhere else: it MUST be set to zero by the sender and ignored by everyone else 🙈 The next six bits, Scale, form an unsigned integer, and Multiplier is an unsigned integer too. Here's the math: the error estimate equals Multiplier*2^(-32)*2^Scale (in seconds). (Quick notation check: 2^Scale is two to the power of Scale 🧮) Multiplier MUST NOT be set to zero 🚫 If Multiplier is zero, the packet SHOULD be considered corrupt and discarded 💀
Sequence numbers start at zero and go up by one for each packet after that 🔢
The minimum data segment length is therefore 14 octets in unauthenticated mode, and 48 octets in both authenticated and encrypted modes.
The OWAMP-Test packet layout is the same in authenticated and encrypted modes, but the encryption and authentication operations are different 🔐 In encrypted mode, both the sequence number and the timestamp are protected, for maximum data confidentiality and integrity. In authenticated mode, only the sequence number is protected and the timestamp is sent in clear text. Sending the timestamp in clear text lets you cut down the time between when a sender grabs a timestamp and when the packet actually goes out 🏎️ In encrypted mode, the sender has to fetch the timestamp, encrypt it, and then send it. In authenticated mode that middle step is gone, which can potentially improve accuracy, since the sequence number can be encrypted and authenticated before the timestamp is fetched ✨
In authenticated mode, the first block (16 octets) of each packet is encrypted using AES Electronic Cookbook (ECB) mode 🎀
Just like each OWAMP-Control session, each OWAMP-Test session has two keys: an AES Session-key and an HMAC Session-key 🗝️ The difference is where they come from. For OWAMP-Control, the client generates the keys and sends them over (as part of the Token) during connection setup, in the Set-Up-Response message. For OWAMP-Test, which is what we're talking about here, the keys are derived from the OWAMP-Control keys and the SID 🧚
The OWAMP-Test AES Session-key is made like this: the OWAMP-Control AES Session-key (the same one used for the matching OWAMP-Control session, just in a different chaining mode) gets encrypted with AES, using the 16-octet session identifier (SID) as the key. That's a single-block ECB encryption, and its result is the OWAMP-Test AES Session-key used to encrypt and decrypt the packets of that particular OWAMP-Test session. Heads up: the OWAMP-Test AES Session-key, the OWAMP-Control AES Session-key, and the SID are all 16 octets each 🌸
The OWAMP-Test HMAC Session-key is made like this: the OWAMP-Control HMAC Session-key (the same HMAC Session-key used for the matching OWAMP-Control session) gets encrypted with AES, using the 16-octet SID as the key. This is a two-block CBC encryption, always done with IV=0, and its result is the OWAMP-Test HMAC Session-key used to authenticate the packets of that OWAMP-Test session. Note that the OWAMP-Test HMAC Session-key and the OWAMP-Control HMAC Session-key are each 32 octets, while the SID is 16 octets 🦋
ECB mode, used for encrypting the first block of OWAMP-Test packets in authenticated mode, doesn't do any real chaining. That means lost, duplicated, or reordered packets don't cause trouble when you try to decipher any packet in an OWAMP-Test session 🙌
In encrypted mode, the first two blocks (32 octets) are encrypted using AES CBC mode 🔒 The AES Session-key is obtained the same way as the key for authenticated mode. Each OWAMP-Test packet is encrypted as its own separate stream, with just one chaining operation. Chaining never spans multiple packets, so lost, duplicated, or reordered packets don't cause problems. The initialization vector for the CBC encryption is a value with all bits equal to zero 🫶
Implementation note: the key schedule for each OWAMP-Test session MAY be set up only once per session, not once per packet 🧠
HMAC in OWAMP-Test only covers the part of the packet that's also encrypted. So in authenticated mode, HMAC covers the first block (16 octets), and in encrypted mode, HMAC covers the first two blocks (32 octets). In OWAMP-Test, the HMAC itself is not encrypted. (This is different from OWAMP-Control, where stream-mode encryption is used, so everything including the HMAC blocks ends up encrypted 🍓)
In unauthenticated mode, no encryption or authentication is applied 🌈
Packet Padding in OWAMP-Test SHOULD be pseudo-random, and it MUST be generated independently of any other pseudo-random numbers mentioned in this document 🎲 However, implementations MUST provide a configuration parameter, an option, or some other means of making Packet Padding consist of all zeros 👑
The time elapsed between packets is computed according to the slot schedule mentioned in the Request-Session command description ⏱️ We skipped over how to compute exponentially distributed pseudo-random numbers in a reproducible way, but that gets covered later in a separate section 💜
4.2. Receiver Behavior ✨
okay so the receiver always knows when the sender is gonna send packets 👀 There's one parameter here: Timeout (it comes from Request-Session). Any packet that arrives later than Timeout counts as lost, or "as good as lost" 💀 ngl the network never actually promises a loss, because a "lost" packet can still show up whenever it wants 🙈
Fun history moment: the original IPv4 spec said packets had to arrive within TTL seconds or not at all, with TTL maxing out at 255. The authors don't know of anyone who actually implemented that, and honestly only a perfect, universal implementation could stop packets from wandering around for longer than TTL seconds 😭 IPv6 even renamed the field to Hop Limit. IPv4 also says nothing about how long a packet takes to cross the last link of the path.
Picking a reasonable Timeout is the user's problem, not the implementor's 💅 Two minutes is super safe. Some apps, like interactive "one-way ping", might want answers faster than that though.
As packets come in:
- timestamp the received packet;
- in authenticated or encrypted mode, decrypt and authenticate as necessary (packets for which authentication fails MUST be discarded); and
- store the packet sequence number, send time, receive time, and the TTL for IPv4 (or Hop Limit for IPv6) from the packet IP header for the results to be transferred.
Packets that don't arrive within the Timeout are considered lost 🥀 They get recorded with their true sequence number, their presumed send time, a receive time value with all bits being zero, and a TTL (or Hop Limit) of 255.
Implementations SHOULD fetch the TTL/Hop Limit value from the IP header of the packet ✨ The only good reason not to is being unable to access the TTL field of arriving packets. If an implementation doesn't fetch the actual TTL value, it MUST record the TTL value as 255.
Packets that actually arrive get recorded in the order they showed up 📬 Lost packet records act as clues about when the lost packets were sent. They SHOULD be placed either at the point where the receiver learns about the loss or at any later point. Honestly, one MAY place all the records that correspond to lost packets at the very end, and that's totally valid 🧚
Packets whose send time is in the future MUST be recorded normally, without changing their send timestamp, unless they have to be discarded. (Future send timestamps would usually mean the clocks differ by more than the delay. Some data, like jitter, can still be pulled out without knowing the time difference. For other kinds of data, the data consumer should handle the adjustment, using the complete info from a measurement session and maybe some external data 🤓)
Duplicate packets are a real thing 👯♀️ IP networks sometimes introduce them, so the protocol has to be able to measure duplication. Packets with a sequence number that was already observed (duplicate packets) MUST be recorded normally.
If any of the following is true, the packet MUST be discarded 🗑️
- Send timestamp is more than Timeout in the past or in the future.
- Send timestamp differs by more than Timeout from the time when the packet should have been sent according to its sequence number.
- In authenticated or encrypted mode, HMAC verification fails.
5. Computing Exponentially Distributed Pseudo-Random Numbers 🎲
Here's how the exponential random quantities used in the protocol get generated 🧠 There are tons of algorithms for exponential random variables, but most of them lean on a logarithm function as a primitive. That can give different values depending on how each math library implements it, which is a mess. So we use algorithm 3.4.1.S from [KNUTH], which dodges that problem and guarantees the same output on any implementation. It belongs to the ziggurat family, developed in the 1970s by G. Marsaglia, M. Sibuya, and J. H. Ahrens [ZIGG]. Instead of logarithms, it uses clever bit manipulation and still produces exponential variates on output 🦋
5.1. High-Level Description of the Algorithm
First we describe the algorithm with all arithmetic operations taken in their natural sense. Exact details on data types, arithmetic, and generating the uniform random variates come later. This is an almost verbatim quote from [KNUTH], p.133 📖
Algorithm S: Given a real positive number "mu", produce an
exponential random variate with mean "mu".
First, the constants
Q[k] = (ln2)/(1!) + (ln2)^2/(2!) + ... + (ln2)^k/(k!), 1 <= k <= 11
are computed in advance. The exact values which MUST be used by all
implementations are given in the next section. This is necessary to
ensure that exactly the same pseudo-random sequences are produced by
all implementations.
S1. [Get U and shift.] Generate a 32-bit uniform random binary
fraction
U = (.b0 b1 b2 ... b31) [note the binary point]
Locate the first zero bit b_j and shift off the leading (j+1) bits,
setting U <- (.b_{j+1} ... b31)
Note: In the rare case that the zero has not been found, it is
prescribed that the algorithm return (mu*32*ln2).
S2. [Immediate acceptance?] If U < ln2, set X <- mu*(j*ln2 + U) and
terminate the algorithm. (Note that Q[1] = ln2.)
S3. [Minimize.] Find the least k >= 2 such that U < Q[k]. Generate k
new uniform random binary fractions U1,...,Uk and set V <-
min(U1,...,Uk).
S4. [Deliver the answer.] Set X <- mu*(j + V)*ln2.5.2. Data Types, Representation, and Arithmetic
The high-level algorithm works on real numbers, usually stored as floating point numbers. This spec says to use unsigned 64-bit integers instead 🔢
u_int64_t integers get read as real numbers by putting the decimal point after the first 32 bits. Conceptually, the interpretation follows this map:
u_int64_t u;
u |--> (double)u / (2**32)The algorithm spits out a sequence of these u_int64_t integers that, for any given SID, is guaranteed to be the same on every implementation 🫶
The u_int64_t representations of the first 11 values of the Q array in the high-level algorithm MUST be as follows 💜
#1 0xB17217F8,
#2 0xEEF193F7,
#3 0xFD271862,
#4 0xFF9D6DD0,
#5 0xFFF4CFD0,
#6 0xFFFEE819,
#7 0xFFFFE7FF,
#8 0xFFFFFE2B,
#9 0xFFFFFFE0,
#10 0xFFFFFFFE,
#11 0xFFFFFFFFFor example, Q[1] = ln2 is approximated by 0xB17217F8/(2**32) = 0.693147180601954. For j > 11, Q[j] is 0xFFFFFFFF.
A small integer j in the high-level algorithm gets represented as the u_int64_t value j * (2**32).
Addition works as usual on u_int64_t numbers. Multiplication in the high-level algorithm, though, gets swapped out for this:
(u, v) |---> (u * v) >> 32.Implementations MUST compute the product (u * v) exactly 🧮 For example, a fragment of unsigned 128-bit arithmetic can do this job (see the sample implementation in Appendix A).
5.3. Uniform Random Quantities
Getting a sequence of 32-bit random numbers (like U in algorithm S) relies on AES encryption in counter mode 🔐 To explain the exact workings, we bring in two primitives from Rijndael. Their prototypes and specs are below, and they're assumed to come from the supporting Rijndael implementation, such as [RIJN] ✨
- A function that initializes a Rijndael key with bytes from seed (the SID will be used as the seed):
void KeyInit(unsigned char seed[16]);- A function that encrypts the 16-octet block inblock with the specified key, returning a 16-octet encrypted block. Here, keyInstance is an opaque type used to represent Rijndael keys:
void BlockEncrypt(keyInstance key, unsigned char inblock[16]);Algorithm Unif takes a 16-octet quantity seed and produces a sequence of unsigned 32-bit pseudo-random uniformly distributed integers. In OWAMP, the SID (session ID) from the Control protocol plays the role of seed 🌸
U1. [Initialize Rijndael key] key <- KeyInit(seed) [Initialize an
unsigned 16-octet (network byte order) counter] c <- 0
U2. [Need more random bytes?] Set i <- c mod 4. If (i == 0) set s
<- BlockEncrypt(key, c)
U3. [Increment the counter as unsigned 16-octet quantity] c <- c + 1
U4. [Do output] Output the i_th quartet of octets from s starting
from high-order octets, converted to native byte order and
represented as OWPNum64 value (as in 3.b).
U5. [Loop] Go to step U2.6. Security Considerations 🚨
6.1. Introduction
The goal of authenticated mode is to let someone passphrase-protect the service a particular OWAMP-Control server provides. You can picture plenty of situations where that's handy. Authenticated mode is designed to prohibit theft of service 🔒
Authenticated mode also had a second design goal: an attacker who can't read traffic between the OWAMP-Test sender and receiver should be unable to tamper with test results in a way that changes the measurements but not other traffic 🕵️
Encrypted mode is a totally different vibe. Its goal is to make it hard for someone in the middle of the network to make results look "better" than they should. That's especially true when one of the client and server isn't the same as the sender or receiver 👀
Encrypting OWAMP-Control with AES CBC mode, with blocks of HMAC after each message, aims to achieve two things: (i) secrecy of the exchange, and (ii) authentication of each message 💅
6.2. Preventing Third-Party Denial of Service
OWAMP-Test sessions aimed at an unsuspecting party could be used for denial of service (DoS) attacks 😤 In unauthenticated mode, servers SHOULD limit receivers to hosts they control or to the OWAMP-Control client.
Unless otherwise configured, the default behavior of servers MUST be to decline requests where the Receiver Address field is not equal to the address that the control connection was initiated from, or an address of the server (or an address of a host it controls). Given the TCP handshake procedure and sequence numbers in the control connection, this makes sure the hosts sending such requests are actually those hosts themselves, or at least on the path towards them. If either this test or the handshake procedure were left out, attackers anywhere on the Internet could ask for large amounts of test packets to be aimed at victim nodes somewhere else 🚫
In any case, OWAMP-Test packets with a given source address MUST only be sent from the node that has been assigned that address. (In other words, address spoofing is not permitted 🙅♀️)
6.3. Covert Information Channels
OWAMP-Test sessions could be used as covert channels of information 🫣 If your environment is worried about covert channels, definitely take this into consideration.
6.4. Requirement to Include AES in Implementations
Okay, bestie, this one's a must-have 🔐✨. AES in counter mode is used for pseudo-random number generation, so AES MUST be included in the implementation 🎲, even if the server only supports unauthenticated mode 🙈. No exceptions, periodt 💅.
6.5. Resource Use Limitations
Servers can run out of stuff, and that's a whole vibe 😭. The two biggest resources are network capacity and memory (primary or secondary) for storing test results 💾.
Any OWAMP server implementation MUST include technical mechanisms to limit how much network capacity and memory it uses 🛑. The mechanisms for managing resources used by unauthenticated users should be SHOULD-separate from the ones for users authenticated with a KeyID and passphrase, so keep them SEPARATE 🧁. The default configuration of an implementation MUST turn these mechanisms on and set the resource use limits to conservatively low values 🌸.
Here's one way to design the limits 🦋. Assign each session to a user class. User classes are partially ordered with an "includes" relation, and there's always one class called "all users" that includes every other class 👑. A session can be put into a class based on whether it's authenticated, the KeyID, the IP address range, the time of day, and maybe other stuff too 🕰️. Each user class gets a limit for network capacity (in bit/second) and a limit for memory used to store test results (in octets) 📊. The server keeps track of current use as it goes 👀.
When someone requests a session in a specific user class, the server works out what that session needs: the average network capacity use (based on the sending schedule) and the maximum memory use (based on the number of packets and the number of octets each packet would need to be stored internally) 🧮. Outgoing sessions don't need any memory use, btw 🙌. These numbers get added to the current use for that user class. If that would push the use outside the class's limits, the session gets rejected 🚫.
When resources are reclaimed, the same measures get subtracted from current use 🧹. Network capacity is reclaimed as soon as the session ends ⏱️. Memory is reclaimed when the data is deleted 🗑️.
For unauthenticated sessions, memory used by an OWAMP-Test session SHOULD be reclaimed after the OWAMP-Control connection that started it is closed, whether that was graceful or not 🫶. For authenticated sessions, the administrator who sets up the service should be able to decide the exact policy 🎀. Some useful policy mechanisms that MAY be implemented are automatically reclaiming memory once the data is retrieved, and reclaiming memory after a configurable period (based on user class) passes after the OWAMP-Test session terminates ⏳.
6.6. Use of Cryptographic Primitives in OWAMP
Okay, the security-tool drama is real 🍿. Early on, the team thought about using Transport Layer Security (TLS) [RFC2246, RFC3546] and IPsec [RFC2401] to secure OWAMP, and later they also considered DTLS 🧐. Here's why none of them were a perfect fit (and this list isn't exhaustive, fr 💀):
Regarding TLS:
- TLS could secure the TCP-based OWAMP-Control, but using it for the UDP-based OWAMP-Test is hard 😤. OWAMP-Test packets that get lost aren't resent, so each packet has to be (optionally) encrypted and authenticated while still being usable on its own 📦. Stream-based TLS can't really do that easily 🌊.
- TLS works with streams, so it doesn't authenticate individual messages (even in OWAMP-Control) 🧵. The easiest workaround would be to add some known-format padding to each message and check that the padding is intact before using the message 🩹. That would lose some of the "just use TLS" appeal 😅. It would also be way harder to evaluate the security of that scheme across TLS's modes and options, and it would almost certainly not be secure with all of them 🚨. An attacker being able to replace parts of messages (namely, the end) with random garbage could have serious security implications, so that would need careful analysis 😱. Imagine a parameter used to control the rate getting swapped for random garbage. The result, an unsigned integer, would probably be pretty huge 📈.
- Depending on the mode, you could end up needing certificates for all users and a PKI 📜. Even if you think a PKI is desirable, there just isn't a usable one today 💔.
- TLS needs a fairly big implementation. OpenSSL, for example, is bigger than the whole OWAMP implementation they made 🐘. That can matter a lot for embedded implementations 🔌.
Regarding DTLS:
- Duplication and reordering are network phenomena that OWAMP needs to be able to measure 🔁. But DTLS's anti-replay measures and reordering protection would stop those duplicated and reordered packets from reaching the relevant part of the OWAMP code 🙅. You could modify DTLS so those protections are weakened, or even specify examining messages in a carefully crafted sequence somewhere between the DTLS checks 🛠️. But then the advantage of using an existing protocol wouldn't really be realized 😩.
- In authenticated mode, the timestamp is in the clear and isn't protected cryptographically in any way, while the rest of the message gets the same protection as in encrypted mode ⏰. This mode lets you trade off cryptographic protection against timestamp accuracy ⚖️. For example, the APAN hardware implementation of OWAMP [APAN] can support authenticated mode, and its accuracy is in the sub-microsecond range ⚡. The errors in OWAMP measurements of Abilene [Abilene] (done with a software implementation, in its encrypted mode) go over 10us 📉. Different environments have different concerns, and some folks might care about every last microsecond 🕐. At the same time, those same people might care about access control to the service 🔒. Authenticated mode lets them control access to the server while still using unprotected timestamps, maybe ones generated by a hardware device 🧠.
Regarding IPsec:
- What's now called authenticated mode wouldn't be possible, because in IPsec you can't authenticate part of a packet 🚫.
- OWAMP and IPsec could have separate deployment paths if OWAMP doesn't depend on IPsec 🛤️. After nine years of IPsec, only 0.05% of traffic on an advanced backbone network like Abilene uses it 📉. For comparison, SSH use (encryption above layer 4) is at 2-4%, and HTTPS use is at 0.2-0.6% 📊. It's really important to be able to deploy OWAMP on as many different platforms as possible 🌍.
- The deployment problems of a protocol that depends on IPsec would be especially bad for lightweight embedded devices 😬. Ethernet switches, DSL "modems", and other devices like those mostly don't support IPsec 📡.
- The API for manipulating IPsec from an application is currently poorly understood 🤯. Writing a program that needs to encrypt some packets, authenticate some packets, and leave some open for the same destination would turn into more of an IPsec exercise than an IP measurement one 🥴.
For the reasons listed above, they went with a simple cryptographic protocol (based on a block cipher in CBC mode) that is different from both TLS and IPsec 🎉💖
6.7. Cryptographic Primitive Replacement 💅
okay so, someday we might need to swap out AES, or the way OWAMP uses it, for a brand new cryptographic primitive 🔐, or make other security-related changes to the protocol. bestie, the good news is OWAMP already has a super clear spot for this: the Modes word in the server greeting and the Mode response in the Set-Up-Response message 🦋.
say we only need a simple swap, like replacing AES with a different block cipher that has a 128-bit block. you'd take two bits from the reserved (MBZ) part of the Modes word of the server greeting. one bit means "encrypted mode with the new cipher," and the other means "authenticated mode with the new cipher" ✨. here's the lowkey clever part: bit consumption could actually drop from two to one, if the client is allowed to send back a mode selection with more than one bit set. one bit could mean "the new cipher is supported" (for the server) or "selected" (for the client), and the bits we already gave to authenticated and encrypted modes keep doing their thing 🧚. this optimization is unimportant conceptually, but it could be useful in practice to make the best use of bits 💜. once the new cipher is negotiated, every later operation just uses it instead of AES 🎀.
also, the normal transition sequence still applies here 🌸. implementations would probably start by supporting and preferring the new cipher first, and then drop support for the old one (which would presumably be no longer considered secure) 🥀.
if we ever need bigger changes, like swapping AES for a cipher with a 256-bit block, it gets harder ngl 😭. that would mean changing the layout of the messages. the good news is it can still happen inside the OWAMP extensibility framework, using the Modes/Mode words. the meaning of the new bits (or the single bit, if that optimization is used) would cover both the change to message layout and the change in the cryptographic primitive 🌈.
each bit in the Modes word can be used for an independent extension, and the extensions signaled by different bits are orthogonal 👑. for example, one bit might switch from AES-128 to some other cipher, another bit might add a protocol feature (like, e.g., support for measuring over multicast) 🍓, and yet another might change a key derivation function, etc. the progression of versions is not a linear order but a partial order, which is a very main character concept 💅. an implementation can implement any subset of these features. of course, features can be made mandatory to implement, e.g., new, more secure ciphers if they are needed 🔥.
if a cipher with a different key size (say, a 256-bit key) ever becomes needed, a new key derivation function for OWAMP-Test keys would also be needed 🗝️. the semantics of a change in the cipher SHOULD then, in the future, be tied to the semantics of a change in the key derivation function (KDF). one KDF that might be considered is a pseudo-random function (PRF) with appropriately sized output, such as 256 bits. perhaps HMAC-SHA256, if it's still considered a secure PRF by then 🫶. that PRF could derive the OWAMP-Test session keys from the OWAMP-Control session key, by using the OWAMP-Control session key as the HMAC key and the SID as the HMAC message ✨.
⚠️ heads up, bestie: the replacement scheme above is trivially susceptible to downgrade attacks 😱. a malicious party in the middle can flip the mode bits during negotiation so the oldest and weakest mode both sides support is the one that gets used 💀. if that's deemed problematic when the primitive gets replaced, the scheme might be augmented with a measure to prevent such an attack. for example, the two sides could exchange the modes again once a secure channel is established, compare the two sets of mode words, and drop the connection if they don't match 🛡️.
6.8. Long-term Manually Managed Keys 🔑
OWAMP-Control uses long-term keys with manual management 🗂️. these keys are used to automatically negotiate session keys for each OWAMP-Control session that runs in authenticated or encrypted mode. the number of these keys a server manages scales linearly with (and, in fact, is equal to) the number of administratively different users that need to connect to it. those users might be particular humans, roles, or robots representing sites 🤖. similarly, the number of different manual keys each client manages is the number of different servers that client needs to connect to 🖥️. this use of manual long-term keys is compliant with [BCP107] 💖.
6.9. (Not) Using Time as Salt ⏰
a natural idea is to use the current time as salt when deriving session keys. unfortunately, that appears to be too limiting 🙅♀️.
although OWAMP is often run on hosts with well-synchronized clocks, it can also run on hosts whose clocks are completely untrained 🕰️. the delays obtained that way are, of course, not directly usable. however, some metrics, like unidirectional loss, reordering, measures of congestion such as the median delay minus minimum, and many others, are usable directly and immediately. they even improve on what a round-trip measurement would have given you ✨. even delay information can be useful with appropriate post-processing 📊. honestly, one could even argue that running the clocks free and post-processing a mesh of measurements will give better accuracy 🧠. more information is available a posteriori, and correlating data from different hosts is possible in post-processing, but not with online clock training 🫠.
given all this, time is not used as salt in key derivation 🚫🧂.
6.10. The Use of AES-CBC and HMAC 🔐
OWAMP relies on AES-CBC for confidentiality and on HMAC-SHA1 truncated to 128 bits for message authentication 💜. random IV choice is important for preventing a codebook attack on the first block 🎲. it's also worth noting that, with its 128-bit block size, AES is more resistant to codebook attacks than ciphers with shorter blocks are. we use a random IV anyway 🙈.
HMAC MUST verify. 😤 it's crucial to check this before using the message, because otherwise existential forgery becomes possible 🚨. the complete message for which HMAC verification fails MUST be discarded. this applies to short messages of a few blocks, and potentially to long messages too, like a response to the Fetch-Session command 🗑️. if such a message is part of OWAMP-Control, the connection MUST be dropped 💀.
since OWAMP messages can have different numbers of blocks, the existential forgery attack described in example 9.62 of [MENEZES] becomes a concern 😬. to prevent it (and to simplify implementation), the length of any message becomes known after decrypting its first block 🧩.
a special case is the first message sent by the client, which has a fixed length 🎀. there, the token is a concatenation of three things. first, the 128-bit challenge, which the server sends in the clear. second, a 128-bit AES Session-key, which the client generates randomly and encrypts with AES-CBC using IV=0. third, a 256-bit HMAC-SHA1 Session-key used for authentication 🔑. since IV=0, the challenge (a single cipher block) is simply encrypted with the secret key. so we rely on AES's resistance to chosen plaintext attacks, because an attacker could substitute the challenge 🕵️♀️. the number of blocks of chosen plaintext an attacker can get encrypted with the secret key is limited by the number of sessions the client wants to initiate 📉. an attacker who knows the encryption of a server's challenge can produce an existential forgery of the session key and thus disrupt the session. still, any attacker can disrupt a session by corrupting the protocol messages in an arbitrary fashion, so no new threat is created here 😌. even so, we require that the server never issues the same challenge twice 🙏. if challenges are generated randomly, a repetition would occur, on average, after 2^64 sessions. we deem that satisfactory, because it's enough even for an implausibly busy server that participates in 1,000,000 sessions per second to go without repetitions for more than 500 centuries 🤯.
with respect to the second part of the token, an attacker can produce an existential forgery of the session key by modifying the second half of the client's token while leaving the first part intact 👀. this forgery, however, would be immediately discovered by the client. the HMAC on the server's next message (acceptance or rejection of the connection) would fail to verify 🚩.
7. Acknowledgements 🫶
we would like to thank Guy Almes, Mark Allman, Jari Arkko, Hamid Asgari, Steven Van den Berghe, Eric Boyd, Robert Cole, Joan Cucchiara, Stephen Donnelly, Susan Evett, Sam Hartman, Kaynam Hedayat, Petri Helenius, Scott Hollenbeck, Russ Housley, Kitamura Yasuichi, Daniel H. T. R. Lawson, Will E. Leland, Bruce A. Mah, Allison Mankin, Al Morton, Attila Pasztor, Randy Presuhn, Matthew Roughan, Andy Scherrer, Henk Uijterwaal, and Sam Weiler 🌟. they helped out with comments, suggestions, reviews, helpful discussion, and proof-reading, and we are so grateful 💖.
8. IANA Considerations 📋
IANA has allocated a well-known TCP port number (861) for the OWAMP-Control part of the OWAMP protocol 🔌.
9. Internationalization Considerations 🌍
the protocol does not carry any information in a natural language. the possible exception is the KeyID in OWAMP-Control, which is encoded in UTF-8 🌈.
10. References 📚
10.1. Normative References
- [AES] Advanced Encryption Standard (AES), http://csrc.nist.gov/encryption/aes/
- [BCP107] Bellovin, S. and R. Housley, "Guidelines for Cryptographic Key Management", BCP 107, RFC 4107, June 2005.
- [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
- [RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, "Framework for IP Performance Metrics", RFC 2330, May 1998.
- [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998.
- [RFC2679] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way Delay Metric for IPPM", RFC 2679, September 1999.
- [RFC2680] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way Packet Loss Metric for IPPM", RFC 2680, September 1999.
- [RFC2836] Brim, S., Carpenter, B., and F. Le Faucheur, "Per Hop Behavior Identification Codes", RFC 2836, May 2000.
- [RFC2898] Kaliski, B., "PKCS #5: Password-Based Cryptography Specification Version 2.0", RFC 2898, September 2000.
10.2. Informative References 📚
Here's the bonus reading list, the informative references, all the links and papers you need to go deeper 🦋
- [APAN] Z. Shu and K. Kobayashi, "HOTS: An OWAMP-Compliant Hardware Packet Timestamper", In Proceedings of PAM 2005, http://www.springerlink.com/index/W4GBD39YWC11GQTN.pdf
- [BRIX] Brix Networks, http://www.brixnet.com/
- [ZIGG] J. H. Ahrens, U. Dieter, "Computer methods for sampling from the exponential and normal distributions", Communications of ACM, volume 15, issue 10, 873-882, 1972. http://doi.acm.org/10.1145/355604.361593
- [MENEZES] A. J. Menezes, P. C. van Oorschot, and S. A. Vanstone, Handbook of Applied Cryptography, CRC Press, revised reprint with updates, 1997.
- [KNUTH] D. Knuth, The Art of Computer Programming, vol.2, 3rd edition, 1998.
- [Abilene] One-way Latency Measurement (OWAMP), http://e2epi.internet2.edu/owamp/
- [RIJN] Reference ANSI C Implementation of Rijndael, http://www.esat.kuleuven.ac.be/~rijmen/rijndael/rijndaelref.zip
- [RIPE] RIPE NCC Test-Traffic Measurements home, http://www.ripe.net/test-traffic/.
- [SURVEYOR] Surveyor Home Page, http://www.advanced.org/surveyor/.
- [SURVEYOR-INET] S. Kalidindi and M. Zekauskas, "Surveyor: An Infrastructure for Network Performance Measurements", Proceedings of INET'99, June 1999. http://www.isoc.org/inet99/proceedings/4h/4h_2.htm
- [RFC1305] Mills, D., "Network Time Protocol (Version 3) Specification, Implementation and Analysis", RFC 1305, March 1992.
- [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999.
- [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
- [RFC3546] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., and T. Wright, "Transport Layer Security (TLS) Extensions", RFC 3546, June 2003.
- [RFC4086] Eastlake, D., 3rd, Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005.
Appendix A: Sample C Code for Exponential Deviates ✨
Okay so the values in the array Q[] are the exact numbers that every implementation MUST use, no freelancing 🙅♀️ (check out Sections 5.1 and 5.2 for the deets). This appendix is just for illustration, so it's more of a vibe check than a rulebook 💅
/*
** Example usage: generate a stream of exponential (mean 1)
** random quantities (ignoring error checking during initialization).
** If a variate with some mean mu other than 1 is desired, the output
** of this algorithm can be multiplied by mu according to the rules
** of arithmetic we described.
** Assume that a 16-octet 'seed' has been initialized
** (as the shared secret in OWAMP, for example)
** unsigned char seed[16];
** OWPrand_context next;
** (initialize state)
** OWPrand_context_init(&next, seed);
** (generate a sequence of exponential variates)
** while (1) {
** u_int64_t num = OWPexp_rand64(&next);
<do something with num here>
...
** }
*/
#include <stdlib.h>
typedef u_int64_t u_int64_t;
/* (K - 1) is the first k such that Q[k] > 1 - 1/(2^32). */
#define K 12
#define BIT31 0x80000000UL /* See if first bit in the lower
32 bits is zero. */
#define MASK32(n) ((n) & 0xFFFFFFFFUL)
#define EXP2POW32 0x100000000ULL
typedef struct OWPrand_context {
unsigned char counter[16];/* Counter (network byte order).*/
keyInstance key; /* Key to encrypt the counter.*/
unsigned char out[16]; /* The encrypted block.*/
} OWPrand_context;
/*
** The array has been computed according to the formula:
**
** Q[k] = (ln2)/(1!) + (ln2)^2/(2!) + ... + (ln2)^k/(k!)
**
** as described in algorithm S. (The values below have been
** multiplied by 2^32 and rounded to the nearest integer.)
** These exact values MUST be used so that different implementation
** produce the same sequences.
*/
static u_int64_t Q[K] = {
0, /* Placeholder - so array indices start from 1. */
0xB17217F8,
0xEEF193F7,
0xFD271862,
0xFF9D6DD0,
0xFFF4CFD0,
0xFFFEE819,
0xFFFFE7FF,
0xFFFFFE2B,
0xFFFFFFE0,
0xFFFFFFFE,
0xFFFFFFFF
};
/* this element represents ln2 */
#define LN2 Q[1]
/*
** Convert an unsigned 32-bit integer into a u_int64_t number.
*/
u_int64_t
OWPulong2num64(u_int32_t a)
{
return ((u_int64_t)1 << 32) * a;
}
/*
** Arithmetic functions on u_int64_t numbers.
*/
/*
** Addition.
*/
u_int64_t
OWPnum64_add(u_int64_t x, u_int64_t y)
{
return x + y;
}
/*
** Multiplication. Allows overflow. Straightforward implementation
** of Algorithm 4.3.1.M (p.268) from [KNUTH].
*/
u_int64_t
OWPnum64_mul(u_int64_t x, u_int64_t y)
{
unsigned long w[4];
u_int64_t xdec[2];
u_int64_t ydec[2];
int i, j;
u_int64_t k, t, ret;
xdec[0] = MASK32(x);
xdec[1] = MASK32(x>>32);
ydec[0] = MASK32(y);
ydec[1] = MASK32(y>>32);
for (j = 0; j < 4; j++)
w[j] = 0;
for (j = 0; j < 2; j++) {
k = 0;
for (i = 0; ; ) {
t = k + (xdec[i]*ydec[j]) + w[i + j];
w[i + j] = t%EXP2POW32;
k = t/EXP2POW32;
if (++i < 2)
continue;
else {
w[j + 2] = k;
break;
}
}
}
ret = w[2];
ret <<= 32;
return w[1] + ret;
}
/*
** Seed the random number generator using a 16-byte quantity 'seed'
** (== the session ID in OWAMP). This function implements step U1
** of algorithm Unif.
*/
void
OWPrand_context_init(OWPrand_context *next, unsigned char *seed)
{
int i;
/* Initialize the key */
rijndaelKeyInit(next->key, seed);
/* Initialize the counter with zeros */
memset(next->out, 0, 16);
for (i = 0; i < 16; i++)
next->counter[i] = 0UL;
}
/*
** Random number generating functions.
*/
/*
** Generate and return a 32-bit uniform random value (saved in the
**less significant half of the u_int64_t). This function implements
**steps U2-U4 of the algorithm Unif.
*/
u_int64_t
OWPunif_rand64(OWPrand_context *next)
{
int j;
u_int8_t *buf;
u_int64_t ret = 0;
/* step U2 */
u_int8_t i = next->counter[15] & (u_int8_t)3;
if (!i)
rijndaelEncrypt(next->key, next->counter, next->out);
/* Step U3. Increment next.counter as a 16-octet single
quantity in network byte order for AES counter mode. */
for (j = 15; j >= 0; j--)
if (++next->counter[j])
break;
/* Step U4. Do output. The last 4 bytes of ret now contain
the random integer in network byte order */
buf = &next->out[4*i];
for (j=0; j<4; j++) {
ret <<= 8;
ret += *buf++;
}
return ret;
}
/*
** Generate an exponential deviate with mean 1.
*/
u_int64_t
OWPexp_rand64(OWPrand_context *next)
{
unsigned long i, k;
u_int32_t j = 0;
u_int64_t U, V, J, tmp;
/* Step S1. Get U and shift */
U = OWPunif_rand64(next);
while ((U & BIT31) && (j < 32)) { /* Shift until first 0. */
U <<= 1;
j++;
}
/* Remove the 0 itself. */
U <<= 1;
U = MASK32(U); /* Keep only the fractional part. */
J = OWPulong2num64(j);
/* Step S2. Immediate acceptance? */
if (U < LN2) /* return (j*ln2 + U) */
return OWPnum64_add(OWPnum64_mul(J, LN2), U);
/* Step S3. Minimize. */
for (k = 2; k < K; k++)
if (U < Q[k])
break;
V = OWPunif_rand64(next);
for (i = 2; i <= k; i++) {
tmp = OWPunif_rand64(next);
if (tmp < V)
V = tmp;
}
/* Step S4. Return (j+V)*ln2 */
return OWPnum64_mul(OWPnum64_add(J, V), LN2);
}Appendix B: Test Vectors for Exponential Deviates 🧚
Here's the tea ☕ Test schedules built from the same inputs have to come out identical across different implementations, otherwise the whole interop thing falls apart 😭 The tricky part is generating the pseudo-random exponentially distributed deviates. To help you check your work, there are test vectors. For each of the four given 128-bit SID values (written as hex), you generate 1,000,000 exponentially distributed 64-bit deviates like we did above. As you go, you add every single one together, and the total is the hex number listed for that SID.
An implementation MUST produce exactly these hexadecimal numbers. 🎯 If you want to double-check the conversion to seconds, there are approximate values too (assuming lambda=1). An implementation SHOULD produce delay values in seconds that are close to the ones given below 🌸
SID = 0x2872979303ab47eeac028dab3829dab2
SUM[1000000] = 0x000f4479bd317381 (1000569.739036 seconds)
SID = 0x0102030405060708090a0b0c0d0e0f00
SUM[1000000] = 0x000f433686466a62 (1000246.524512 seconds)
SID = 0xdeadbeefdeadbeefdeadbeefdeadbeef
SUM[1000000] = 0x000f416c8884d2d3 (999788.533277 seconds)
SID = 0xfeed0feed1feed2feed3feed4feed5ab
SUM[1000000] = 0x000f3f0b4b416ec8 (999179.293967 seconds)Authors' Addresses 💖
Stanislav Shalunov
Internet2
1000 Oakbrook Drive, Suite 300
Ann Arbor, MI 48104
EMail: shalunov@internet2.edu
WWW: http://www.internet2.edu/~shalunov/
Benjamin Teitelbaum
Internet2
1000 Oakbrook Drive, Suite 300
Ann Arbor, MI 48104
EMail: ben@internet2.edu
WWW: http://people.internet2.edu/~ben/
Anatoly Karp
Computer Sciences Department
University of Wisconsin-Madison
Madison, WI 53706
EMail: akarp@cs.wisc.edu
Jeff W. Boote
Internet2
1000 Oakbrook Drive, Suite 300
Ann Arbor, MI 48104
EMail: boote@internet2.edu
Matthew J. Zekauskas
Internet2
1000 Oakbrook Drive, Suite 300
Ann Arbor, MI 48104
EMail: matt@internet2.eduFull Copyright Statement 💖
Okay bestie, the legal stuff at the end! 🎀 The Internet Society owns the copyright here, Copyright (C) The Internet Society (2006) 📜 This document is subject to the rights, licenses and restrictions in BCP 78, and except as set forth there, the authors keep all their rights 🦋
The doc comes "AS IS" 🫶 THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE 💀 Translation: nobody is promising it's perfect, lol.
Intellectual Property 🔥
Okay so the IETF is NOT taking a side on whether any patents or other IP rights apply to the tech in this document, or whether you can get a license for them 🙈 It also isn't saying it looked for any of those rights itself 🌸 If you want the rules on rights in RFC documents, check BCP 78 and BCP 79 📚
If you're curious about IPR disclosures sent to the IETF Secretariat, or assurances that licenses will be available, or what happens when someone tries to get a general license or permission for implementers or users of this spec, the place to look is the IETF on-line IPR repository at http://www.ietf.org/ipr 🧚
And if you know about any copyrights, patents, patent applications, or other proprietary rights that might cover tech you'd need to implement this standard, tell the IETF! ✨ Email ietf-ipr@ietf.org 💜
Acknowledgement 🌈
Last but not least, the RFC Editor function is funded by the IETF Administrative Support Activity (IASA) 👑 Someone has to keep the lights on for all these RFCs, and they're iconic for it 🫶
📦 where this page comes from
- ietf: rfc4656 2006-09
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms