idnits 2.17.1 draft-ietf-ippm-owdp-16.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 18. -- Found old boilerplate from RFC 3978, Section 5.5 on line 2435. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 2412. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 2419. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document seems to lack an RFC 3979 Section 5, para. 3 IPR Disclosure Invitation -- however, there's a paragraph with a matching beginning. Boilerplate error? Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 2 instances of too long lines in the document, the longest one being 2 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 187 has weird spacing: '...eceiver the...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: The shared secret is a passphrase; it MUST not contain newlines. The secret key is derived from the passphrase using a password-based key derivation function PBKDF2 (PKCS #5) [RFC2898]. The PBKDF2 function requires several parameters: the PRF is HMAC-SHA1 [RFC2104]; the salt and count are as transmitted by the server. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: If the server rejects a Request-Session message, it SHOULD not close the TCP connection. The client MAY close it if it receives negative response to the Request-Session message. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 2006) is 6645 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '1' on line 2147 -- Looks like a reference, but probably isn't: '16' on line 2054 == Missing Reference: 'Loop' is mentioned on line 1644, but not defined == Missing Reference: 'K' is mentioned on line 2068, but not defined -- Looks like a reference, but probably isn't: '4' on line 2115 -- Looks like a reference, but probably isn't: '2' on line 2145 -- Looks like a reference, but probably isn't: '0' on line 2124 -- Looks like a reference, but probably isn't: '15' on line 2187 -- Looks like a reference, but probably isn't: '1000000' on line 2276 == Unused Reference: 'RFC2026' is defined on line 2286, but no explicit reference was found in the text == Unused Reference: 'RFC2330' is defined on line 2295, but no explicit reference was found in the text == Unused Reference: 'RFC2836' is defined on line 2308, but no explicit reference was found in the text == Unused Reference: 'RIPE-NLUUG' is defined on line 2341, but no explicit reference was found in the text == Unused Reference: 'SURVEYOR-INET' is defined on line 2348, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'AES' ** Downref: Normative reference to an Informational RFC: RFC 2104 ** Downref: Normative reference to an Informational RFC: RFC 2330 ** Obsolete normative reference: RFC 2679 (Obsoleted by RFC 7679) ** Obsolete normative reference: RFC 2680 (Obsoleted by RFC 7680) ** Obsolete normative reference: RFC 2836 (Obsoleted by RFC 3140) ** Obsolete normative reference: RFC 2898 (Obsoleted by RFC 8018) -- Obsolete informational reference (is this intentional?): RFC 1305 (Obsoleted by RFC 5905) -- Obsolete informational reference (is this intentional?): RFC 2246 (Obsoleted by RFC 4346) -- Obsolete informational reference (is this intentional?): RFC 2401 (Obsoleted by RFC 4301) -- Obsolete informational reference (is this intentional?): RFC 3546 (Obsoleted by RFC 4366) Summary: 11 errors (**), 0 flaws (~~), 13 warnings (==), 19 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Stanislav Shalunov 3 Internet Draft Benjamin Teitelbaum 4 Expiration Date: August 2006 Anatoly Karp 5 Jeff W. Boote 6 Matthew J. Zekauskas 7 Internet2 8 February 2006 10 A One-way Active Measurement Protocol (OWAMP) 11 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as 23 Internet-Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 Copyright Notice 38 Copyright (C) The Internet Society (2006). 40 Abstract 42 With growing availability of good time sources to network nodes, it 43 becomes increasingly possible to measure one-way IP performance 44 metrics with high precision. To do so in an interoperable manner, a 45 common protocol for such measurements is required. The One-Way 46 Active Measurement Protocol (OWAMP) can measure one-way delay, as 47 well as other unidirectional characteristics, such as one-way loss. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 3 52 1.1. Relationship of Test and Control Protocols . . . . . . 4 53 1.2. Logical Model . . . . . . . . . . . . . . . . . . . . 5 54 2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . 6 55 3. OWAMP-Control . . . . . . . . . . . . . . . . . . . . . . . 7 56 3.1. Connection Setup . . . . . . . . . . . . . . . . . . . 7 57 3.2. Integrity Protection (HMAC) . . . . . . . . . . . . . 12 58 3.3. Values of the Accept Field . . . . . . . . . . . . . . 12 59 3.4. OWAMP-Control Commands . . . . . . . . . . . . . . . . 13 60 3.5. Creating Test Sessions . . . . . . . . . . . . . . . . 14 61 3.6. Send Schedules . . . . . . . . . . . . . . . . . . . . 19 62 3.7. Starting Test Sessions . . . . . . . . . . . . . . . . 20 63 3.8. Stop-Sessions . . . . . . . . . . . . . . . . . . . . 21 64 3.9. Fetch-Session . . . . . . . . . . . . . . . . . . . . 24 65 4. OWAMP-Test . . . . . . . . . . . . . . . . . . . . . . . . 29 66 4.1. Sender Behavior . . . . . . . . . . . . . . . . . . . 29 67 4.1.1. Packet Timings . . . . . . . . . . . . . . . . . 29 68 4.1.2. OWAMP-Test Packet Format and Content . . . . . . 30 69 4.2. Receiver Behavior . . . . . . . . . . . . . . . . . . 34 70 5. Computing Exponentially Distributed Pseudo-Random Numbers . 35 71 5.1. High-Level Description of the Algorithm . . . . . . . 36 72 5.2. Data Types, Representation, and Arithmetic . . . . . . 36 73 5.3. Uniform Random Quantities . . . . . . . . . . . . . . 38 74 6. Security Considerations . . . . . . . . . . . . . . . . . . 39 75 6.1. Introduction . . . . . . . . . . . . . . . . . . . . . 39 76 6.2. Preventing Third-Party Denial of Service . . . . . . . 39 77 6.3. Covert Information Channels . . . . . . . . . . . . . 40 78 6.4. Requirement to Include AES in Implementations . . . . 40 79 6.5. Resource Use Limitations . . . . . . . . . . . . . . . 40 80 6.6. Use of Cryptographic Primitives in OWAMP . . . . . . . 41 81 6.7. Cryptographic primitive replacement . . . . . . . . . 43 82 6.8. Long-term manually managed keys . . . . . . . . . . . 44 83 6.9. (Not) Using Time as Salt . . . . . . . . . . . . . . . 45 84 6.10. The Use of AES-CBC and HMAC . . . . . . . . . . . . . 45 85 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . 46 86 8. Internationalization Considerations . . . . . . . . . . . . 46 87 9. Appendix A: Sample C Code for Exponential Deviates . . . . 47 88 10. Appendix B: Test Vectors for Exponential Deviates . . . . 52 89 11. Normative References . . . . . . . . . . . . . . . . . . . 52 90 12. Informative References . . . . . . . . . . . . . . . . . . 53 91 13. Authors' Addresses . . . . . . . . . . . . . . . . . . . . 54 93 1. Introduction 95 The IETF IP Performance Metrics (IPPM) working group has proposed 96 metrics for one-way packet delay [RFC2679] and loss [RFC2680] across 97 Internet paths. Although there are now several measurement platforms 98 that implement collection of these metrics [SURVEYOR] [RIPE] [BRIX], 99 there is not currently a standard that would permit initiation of 100 test streams or exchange of packets to collect singleton metrics in 101 an interoperable manner. 103 With the increasingly wide availability of affordable global 104 positioning systems (GPS) and CDMA-based time sources, hosts 105 increasingly have available to them very accurate time 106 sources--either directly or through their proximity to Network Time 107 Protocol (NTP) primary (stratum 1) time servers. By standardizing a 108 technique for collecting IPPM one-way active measurements, we hope to 109 create an environment where IPPM metrics may be collected across a 110 far broader mesh of Internet paths than is currently possible. One 111 particularly compelling vision is of widespread deployment of open 112 OWAMP servers that would make measurement of one-way delay as 113 commonplace as measurement of round-trip time using an ICMP-based 114 tool like ping. 116 Additional design goals of OWAMP include: being hard to detect and 117 manipulate, security, logical separation of control and test 118 functionality, and support for small test packets. (Being hard to 119 detect makes interference with measurements more difficult for 120 intermediaries in the middle of the network.) 122 OWAMP test traffic is hard to detect because it is simply a stream of 123 UDP packets from and to negotiated port numbers, with potentially 124 nothing static in the packets (size is negotiated, as well). OWAMP 125 also supports an encrypted mode that further obscures the traffic, at 126 the same time making it impossible to alter timestamps undetectably. 128 Security features include optional authentication and/or encryption 129 of control and test messages. These features may be useful to 130 prevent unauthorized access to results or man-in-the-middle attackers 131 who attempt to provide special treatment to OWAMP test streams or who 132 attempt to modify sender-generated timestamps to falsify test 133 results. 135 The key words "MUST", "REQUIRED", "SHOULD", "RECOMMENDED", and "MAY" 136 in this document are to be interpreted as described in [RFC2119]. 138 1.1. Relationship of Test and Control Protocols 140 OWAMP actually consists of two inter-related protocols: OWAMP-Control 141 and OWAMP-Test. OWAMP-Control is used to initiate, start, and stop 142 test sessions and fetch their results, while OWAMP-Test is used to 143 exchange test packets between two measurement nodes. 145 Although OWAMP-Test may be used in conjunction with a control 146 protocol other than OWAMP-Control, the authors have deliberately 147 chosen to include both protocols in the same draft to encourage the 148 implementation and deployment of OWAMP-Control as a common 149 denominator control protocol for one-way active measurements. Having 150 a complete and open one-way active measurement solution that is 151 simple to implement and deploy is crucial to assuring a future in 152 which inter-domain one-way active measurement could become as 153 commonplace as ping. We neither anticipate nor recommend that 154 OWAMP-Control form the foundation of a general-purpose extensible 155 measurement and monitoring control protocol. 157 OWAMP-Control is designed to support the negotiation of one-way 158 active measurement sessions and results retrieval in a 159 straightforward manner. At session initiation, there is a negotiation 160 of sender and receiver addresses and port numbers, session start 161 time, session length, test packet size, the mean Poisson sampling 162 interval for the test stream, and some attributes of the very general 163 RFC 2330 notion of packet type, including packet size and per-hop 164 behavior (PHB) [RFC2474], which could be used to support the 165 measurement of one-way network characteristics across differentiated 166 services networks. Additionally, OWAMP-Control supports per-session 167 encryption and authentication for both test and control traffic, 168 measurement servers that can act as proxies for test stream 169 endpoints, and the exchange of a seed value for the pseudo-random 170 Poisson process that describes the test stream generated by the 171 sender. 173 We believe that OWAMP-Control can effectively support one-way active 174 measurement in a variety of environments, from publicly accessible 175 measurement beacons running on arbitrary hosts to network monitoring 176 deployments within private corporate networks. If integration with 177 Simple Network Management Protocol (SNMP) or proprietary network 178 management protocols is required, gateways may be created. 180 1.2. Logical Model 182 Several roles are logically separated to allow for broad flexibility 183 in use. Specifically, we define: 185 Session-Sender the sending endpoint of an OWAMP-Test session; 187 Session-Receiver the receiving endpoint of an OWAMP-Test session; 189 Server an end system that manages one or more OWAMP-Test 190 sessions, is capable of configuring per-session 191 state in session endpoints, and is capable of 192 returning the results of a test session; 194 Control-Client an end system that initiates requests for 195 OWAMP-Test sessions, triggers the start of a set 196 of sessions, and may trigger their termination; and 198 Fetch-Client an end system that initiates requests to fetch 199 the results of completed OWAMP-Test sessions. 201 One possible scenario of relationships between these roles is shown 202 below. 204 +----------------+ +------------------+ 205 | Session-Sender |--OWAMP-Test-->| Session-Receiver | 206 +----------------+ +------------------+ 207 ^ ^ 208 | | 209 | | 210 | | 211 | +----------------+<----------------+ 212 | | Server |<-------+ 213 | +----------------+ | 214 | ^ | 215 | | | 216 | OWAMP-Control OWAMP-Control 217 | | | 218 v v v 219 +----------------+ +-----------------+ 220 | Control-Client | | Fetch-Client | 221 +----------------+ +-----------------+ 223 (Unlabeled links in the figure are unspecified by this draft and may 224 be proprietary protocols.) 226 Different logical roles can be played by the same host. For example, 227 in the figure above, there could actually be only two hosts: one 228 playing the roles of Control-Client, Fetch-Client, and 229 Session-Sender, and the other playing the roles of Server and 230 Session-Receiver. This is shown below. 232 +-----------------+ +------------------+ 233 | Control-Client |<--OWAMP-Control-->| Server | 234 | Fetch-Client | | | 235 | Session-Sender |---OWAMP-Test----->| Session-Receiver | 236 +-----------------+ +------------------+ 238 Finally, because many Internet paths include segments that transport 239 IP over ATM, delay and loss measurements can include the effects of 240 ATM segmentation and reassembly (SAR). Consequently, OWAMP has been 241 designed to allow for small test packets that would fit inside the 242 payload of a single ATM cell (this is only achieved in 243 unauthenticated mode). 245 2. Protocol Overview 247 As described above, OWAMP consists of two inter-related protocols: 248 OWAMP-Control and OWAMP-Test. The former is layered over TCP and is 249 used to initiate and control measurement sessions and to fetch their 250 results. The latter protocol is layered over UDP and is used to send 251 singleton measurement packets along the Internet path under test. 253 The initiator of the measurement session establishes a TCP connection 254 to a well-known port XXX on the target point and this connection 255 remains open for the duration of the OWAMP-Test sessions. An OWAMP 256 server SHOULD listen to this well-known port. [RFC Editor: IANA is 257 requested to allocate a well-known port number for OWAMP-Control 258 sessions. Please replace ``XXX'' with the value assigned by IANA.] 260 OWAMP-Control messages are transmitted only before OWAMP-Test 261 sessions are actually started and after they complete (with the 262 possible exception of an early Stop-Sessions message). 264 The OWAMP-Control and OWAMP-Test protocols support three modes of 265 operation: unauthenticated, authenticated, and encrypted. The 266 authenticated or encrypted modes require endpoints to possess a 267 shared secret. 269 All multi-octet quantities defined in this document are represented 270 as unsigned integers in network byte order unless specified 271 otherwise. 273 3. OWAMP-Control 275 Each type of OWAMP-Control message has a fixed length. The recipient 276 will know the full length of a message after examining the first 16 277 octets of it. No message is shorter than 16 octets. 279 An implementation SHOULD expunge unused state to prevent denial-of- 280 service attacks, or unbounded memory usage, on the server. For 281 example, if the full control message is not received within some 282 number of minutes after it is expected, the TCP connection associated 283 with the OWAMP-Control session SHOULD be dropped. In absence of 284 other considerations, 30 minutes seems like a reasonable upper bound. 286 3.1. Connection Setup 288 Before either a Control-Client or a Fetch-Client can issue commands 289 of a Server, it has to establish a connection to the server. 291 First, a client opens a TCP connection to the server on a well-known 292 port XXX. The server responds with a server greeting: [RFC Editor: 293 Please replace ``XXX'' with the well-known port value assigned by 294 IANA.] 295 0 1 2 3 296 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 297 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 298 | | 299 | Unused (12 octets) | 300 | | 301 |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 302 | Modes | 303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 304 | | 305 | Challenge (16 octets) | 306 | | 307 | | 308 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 309 | | 310 | Salt (16 octets) | 311 | | 312 | | 313 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 314 | Count (4 octets) | 315 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 316 | | 317 | MBZ (12 octets) | 318 | | 319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 321 The following Mode values are meaningful: 1 for unauthenticated, 2 322 for authenticated, and 4 for encrypted. The value of the Modes field 323 sent by the server is the bit-wise OR of the mode values that it is 324 willing to support during this session. Thus, the last three bits of 325 the Modes 32-bit value are used. The first 29 bits MUST be zero. A 326 client MUST ignore the values in the first 29 bits of the Modes 327 value. (This way, the bits are available for future protocol 328 extensions. This is the only intended extension mechanism.) 330 Challenge is a random sequence of octets generated by the server; it 331 is used subsequently by the client to prove possession of a shared 332 secret in a manner prescribed below. 334 Salt and Count are parameters used in deriving a key from a shared 335 secret as described below. 337 Salt MUST be generated pseudo-randomly (independently of anything 338 else in this document). 340 Count MUST be a power of 2. Count MUST be at least 1024. Count 341 SHOULD be increased as more computing power becomes common. 343 If Modes value is zero, the server does not wish to communicate with 344 the client and MAY close the connection immediately. The client 345 SHOULD close the connection if it receives a greeting with Modes 346 equal to zero. The client MAY close the connection if the client's 347 desired mode is unavailable. 349 Otherwise, the client MUST respond with the following Set-Up-Response 350 message: 352 0 1 2 3 353 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 354 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 355 | Mode | 356 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 357 | | 358 . . 359 . KeyID (80 octets) . 360 . . 361 | | 362 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 363 | | 364 . . 365 . Token (32 octets) . 366 . . 367 | | 368 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 369 | | 370 . . 371 . Client-IV (16 octets) . 372 . . 373 | | 374 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 376 Here Mode is the mode that the client chooses to use during this 377 OWAMP-Control session. It will also be used for all OWAMP-Test 378 sessions started under control of this OWAMP-Control session. In 379 Mode, one or zero bits MUST be set within last three bits. If it is 380 one bit that is set within the last three bits, this bit MUST 381 indicate a mode that the server agreed to use (i.e., the same bit 382 MUST have been set by the server in the server greeting). The first 383 29 bits of Mode MUST be zero. A server MUST ignore the values of the 384 first 29 bits. If zero Mode bits are set by the client, the client 385 indicates that it will not continue with the session; in this case, 386 the client and the server SHOULD close the TCP connection associated 387 with the OWAMP-Control session. 389 In unauthenticated mode, KeyID, Token, and Client-IV are unused. 391 Otherwise, KeyID is a UTF-8 string, up to 80 octets in length (if the 392 string is shorter, it is padded with zero octets), that tells the 393 server which shared secret the client wishes to use to authenticate 394 or encrypt, while Token is the concatenation of a 16-octet challenge 395 and a 16-octet Session-key, encrypted using the AES (Advanced 396 Encryption Standard) [AES] in Cipher Block Chaining (CBC). Encryption 397 MUST be performed using an Initialization Vector (IV) of zero and a 398 key derived from the shared secret associated with KeyID. (Both the 399 server and the client use the same mappings from KeyIDs to shared 400 secrets. The server, being prepared to conduct sessions with more 401 than one client, uses KeyIDs to choose the appropriate secret key; a 402 client would typically have different secret keys for different 403 servers. The situation is analogous to that with passwords.) 405 The shared secret is a passphrase; it MUST not contain newlines. The 406 secret key is derived from the passphrase using a password-based key 407 derivation function PBKDF2 (PKCS #5) [RFC2898]. The PBKDF2 function 408 requires several parameters: the PRF is HMAC-SHA1 [RFC2104]; the salt 409 and count are as transmitted by the server. 411 Session-key and Client-IV are generated randomly by the client. 412 Session-key MUST be generated with sufficient entropy not to reduce 413 the security of the underlying cipher [RFC4086]. Client-IV merely 414 needs to be unique (i.e., it MUST never be repeated for different 415 sessions using the same secret key; a simple way to achieve that 416 without the use of cumbersome state is to generate the Client-IV 417 values using a cryptographically secure pseudo-random number source: 418 if this is done, the first repetition is unlikely to occur before 419 2^64 sessions with the same secret key are conducted). 421 The server MUST respond with the following Server-Start message: 423 0 1 2 3 424 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 425 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 426 | | 427 | MBZ (15 octets) | 428 | | 429 | +-+-+-+-+-+-+-+-+ 430 | | Accept | 431 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 432 | | 433 | Server-IV (16 octets) | 434 | | 435 | | 436 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 437 | Start-Time (Timestamp) | 438 | | 439 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 440 | MBZ (8 octets) | 441 | | 442 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 444 The MBZ parts MUST be zero. The client MUST ignore their value. MBZ 445 (MUST be zero) fields here and hereafter have the same semantics: the 446 party that sends the message MUST set the field so that all bits are 447 equal to zero; the party that interprets the message MUST ignore the 448 value. (This way the field could be used for future extensions.) 450 Server-IV is generated randomly by the server. In unauthenticated 451 mode, Server-IV is unused. 453 The Accept field indicates the server's willingness to continue 454 communication. A zero value in the Accept field means that the 455 server accepts the authentication and is willing to conduct further 456 transactions. Non-zero values indicate that the server does not 457 accept the authentication or, for some other reason, is not willing 458 to conduct further transactions in this OWAMP-Control session. The 459 full list of available Accept values is described in Section 3.3, 460 ``Values of the Accept Field''. 462 If a negative (non-zero) response is sent, the server MAY and the 463 client SHOULD close the connection after this message. 465 Start-Time is a timestamp representing the time when the current 466 instantiation of the server started operating. (For example, in a 467 multi-user general purpose operating system (OS), it could be the 468 time when the server process was started.) If Accept is non-zero, 469 Start-Time SHOULD be set so that all of its bits are zeros. In 470 authenticated and encrypted modes, Start-Time is encrypted as 471 described in the next section, unless Accept is non-zero. 472 (Authenticated and encrypted mode cannot be entered unless the 473 control connection can be initialized.) 475 Timestamp format is described in Section 4.1.2. The same 476 instantiation of the server SHOULD report the same exact Start-Time 477 value to each client in each session. 479 The previous transactions constitute connection setup. 481 3.2. Integrity Protection (HMAC) 483 Authentication of each message (also referred to as a command in this 484 document) in OWAMP-Control is accomplished by adding an HMAC to it. 485 The HMAC that OWAMP uses is HMAC-SHA1 truncated to 128 bits. Thus, 486 all HMAC fields are 16 octets. An HMAC needs a key. The same key 487 used for AES encryption is used for HMAC authentication. Each HMAC 488 sent covers everything sent in a given direction between the previous 489 HMAC (but not including it) and up to the beginning of the new HMAC. 490 This way, once encryption is set up, each bit of the OWAMP-Control 491 connection is authenticated by an HMAC exactly once. 493 When encrypting, authentication happens before encryption, so HMAC 494 blocks are encrypted along with the rest of the stream. When 495 decrypting, the order, of course, is reversed: first one decrypts, 496 then one checks the HMAC, then one proceeds to use the data. 498 The HMAC MUST be checked as early as possible to avoid using and 499 propagating corrupt data. 501 In open mode, the HMAC fields are unused and have the same semantics 502 as MBZ fields. 504 3.3. Values of the Accept Field 506 Accept values are used throughout the OWAMP-Control protocol to 507 communicate the server response to client requests. The full set of 508 valid Accept field values are: 510 0 OK. 512 1 Failure, reason unspecified (catch-all). 514 2 Internal error. 516 3 Some aspect of request is not supported. 518 4 Cannot perform request due to permanent resource limitations. 520 5 Cannot perform request due to temporary resource limitations. 522 All other values are reserved. The sender of the message MAY use the 523 value of 1 for all non-zero Accept values. A message sender SHOULD 524 use the correct Accept value if it is going to use other values. The 525 message receiver MUST interpret all values of Accept other than these 526 reserved values as 1. This way, other values are available for 527 future extensions. 529 3.4. OWAMP-Control Commands 531 In authenticated or encrypted mode (which are identical as far as 532 OWAMP-Control is concerned, and only differ in OWAMP-Test) all 533 further communications are encrypted with the Session-key, using CBC 534 mode. The client encrypts everything it sends through the just- 535 established OWAMP-Control connection using stream encryption with 536 Client-IV as the IV. Correspondingly, the server encrypts its side 537 of the connection using Server-IV as the IV. 539 The IVs themselves are transmitted in cleartext. Encryption starts 540 with the block immediately following the block containing the IV. 541 The two streams (one going from the client to the server and one 542 going back) are encrypted independently, each with its own IV, but 543 using the same key (the session key). 545 The following commands are available for the client: Request-Session, 546 Start-Sessions, Stop-Sessions, and Fetch-Session. The command 547 Stop-Sessions is available to both the client and the server. (The 548 server can also send other messages in response to commands it 549 receives.) 551 After the client sends the Start-Sessions command and until it both 552 sends and receives (in an unspecified order) the Stop-Sessions 553 command, it is said to be conducting active measurements. Similarly, 554 the server is said to be conducting active measurements after it 555 receives the Start-Sessions command and until it both sends and 556 receives (in an unspecified order) the Stop-Sessions command. 558 While conducting active measurements, the only command available is 559 Stop-Sessions. 561 These commands are described in detail below. 563 3.5. Creating Test Sessions 565 Individual one-way active measurement sessions are established using 566 a simple request/response protocol. An OWAMP client MAY issue zero or 567 more Request-Session messages to an OWAMP server, which MUST respond 568 to each with an Accept-Session message. An Accept-Session message 569 MAY refuse a request. 571 The format of Request-Session message is as follows: 573 0 1 2 3 574 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 575 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 576 | 1 | MBZ | IPVN | Conf-Sender | Conf-Receiver | 577 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 578 | Number of Schedule Slots | 579 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 580 | Number of Packets | 581 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 582 | Sender Port | Receiver Port | 583 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 584 | Sender Address | 585 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 586 | | 587 | Sender Address (cont.) or MBZ (12 octets) | 588 | | 589 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 590 | Receiver Address | 591 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 592 | | 593 | Receiver Address (cont.) or MBZ (12 octets) | 594 | | 595 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 596 | | 597 | SID (16 octets) | 598 | | 599 | | 600 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 601 | Padding Length | 602 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 603 | Start Time | 604 | | 605 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 606 | Timeout, (8 octets) | 607 | | 608 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 609 | Type-P Descriptor | 610 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 611 | MBZ (8 octets) | 612 | | 613 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 614 | | 615 | HMAC (16 octets) | 616 | | 617 | | 618 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 620 This is immediately followed by one or more schedule slot 621 descriptions (the number of schedule slots is specified in the 622 `Number of Schedule Slots' field above): 624 0 1 2 3 625 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 626 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 627 | Slot Type | | 628 +-+-+-+-+-+-+-+-+ MBZ (7 octets) | 629 | | 630 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 631 | Slot Parameter (Timestamp) | 632 | | 633 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 635 These are immediately followed by HMAC: 637 0 1 2 3 638 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 639 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 640 | | 641 | HMAC (16 octets) | 642 | | 643 | | 644 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 646 All these messages comprise one logical message: the Request-Session 647 command. 649 Above, the first octet (1) indicates that this is Request-Session 650 command. 652 IPVN is the IP version numbers for Sender and Receiver. When the IP 653 version number is 4, 12 octets follow the 4-octet IPv4 address stored 654 in Sender Address and Receiver Address. These octets MUST be set to 655 zero by the client and MUST be ignored by the server. Currently 656 meaningful IPVN values are 4 and 6. 658 Conf-Sender and Conf-Receiver MUST be set to 0 or 1 by the client. 659 The server MUST interpret any non-zero value as 1. If the value is 660 1, the server is being asked to configure the corresponding agent 661 (sender or receiver). In this case, the corresponding Port value 662 SHOULD be disregarded by the server. At least one of Conf-Sender and 663 Conf-Receiver MUST be 1. (Both can be set, in which case the server 664 is being asked to perform a session between two hosts it can 665 configure.) 667 Number of Schedule Slots, as mentioned before, specifies the number 668 of slot records that go between the two blocks of HMAC. It is used 669 by the sender to determine when to send test packets (see next 670 section). 672 Number of Packets is the number of active measurement packets to be 673 sent during this OWAMP-Test session (note that either the server or 674 the client can abort the session early). 676 If Conf-Sender is not set, Sender Port is the UDP port from which 677 OWAMP-Test packets will be sent. If Conf-Receiver is not set, 678 Receiver Port is the UDP port OWAMP-Test to which packets are 679 requested to be sent. 681 The Sender Address and Receiver Address fields contain, respectively, 682 the sender and receiver addresses of the end points of the Internet 683 path over which an OWAMP test session is requested. 685 SID is the session identifier. It can be used in later sessions as 686 an argument for the Fetch-Session command. It is meaningful only if 687 Conf-Receiver is 0. This way, the SID is always generated by the 688 receiving side. See the end of the section for information on how 689 the SID is generated. 691 Padding length is the number of octets to be appended to the normal 692 OWAMP-Test packet (see more on padding in discussion of OWAMP-Test). 694 Start Time is the time when the session is to be started (but not 695 before Start-Sessions command is issued). This timestamp is in the 696 same format as OWAMP-Test timestamps. 698 Timeout (or a loss threshold) is an interval of time (expressed as a 699 timestamp). A packet belonging to the test session that is being set 700 up by the current Request-Session command will be considered lost if 701 it is not received during Timeout seconds after it is sent. 703 Type-P Descriptor covers only a subset of (very large) Type-P space. 704 If the first two bits of the Type-P Descriptor are 00, then 705 subsequent six bits specify the requested Differentiated Services 706 Codepoint (DSCP) value of sent OWAMP-Test packets, as defined in 707 RFC 2474. If the first two bits of Type-P descriptor are 01, then 708 the subsequent 16 bits specify the requested PHB Identification Code 709 (PHB ID), as defined in RFC 2836. 711 Therefore, the value of all zeros specifies the default best-effort 712 service. 714 If Conf-Sender is set, the Type-P Descriptor is to be used to 715 configure the sender to send packets according to its value. If 716 Conf-Sender is not set, the Type-P Descriptor is a declaration of how 717 the sender will be configured. 719 If Conf-Sender is set and the server does not recognize the Type-P 720 Descriptor, or it cannot or does not wish to set the corresponding 721 attributes on OWAMP-Test packets, it SHOULD reject the session 722 request. If Conf-Sender is not set, the server SHOULD accept or 723 reject the session paying no attention to the value of the Type-P 724 Descriptor. 726 To each Request-Session message, an OWAMP server MUST respond with an 727 Accept-Session message: 729 0 1 2 3 730 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 731 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 732 | Accept | MBZ | Port | 733 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| 734 | | 735 | SID (16 octets) | 736 | | 737 | | 738 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 739 | | 740 | MBZ (12 octets) | 741 | | 742 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 743 | | 744 | HMAC (16 octets) | 745 | | 746 | | 747 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 749 In this message, zero in the Accept field means that the server is 750 willing to conduct the session. A non-zero value indicates rejection 751 of the request. The full list of available Accept values is 752 described in Section 3.3, ``Values of the Accept Field''. 754 If the server rejects a Request-Session message, it SHOULD not close 755 the TCP connection. The client MAY close it if it receives negative 756 response to the Request-Session message. 758 The meaning of Port in the response depends on the values of 759 Conf-Sender and Conf-Receiver in the query that solicited the 760 response. If both were set, the Port field is unused. If only 761 Conf-Sender was set, Port is the port from which to expect OWAMP-Test 762 packets. If only Conf-Receiver was set, Port is the port to which 763 OWAMP-Test packets are sent. 765 If only Conf-Sender was set, the SID field in the response is unused. 766 Otherwise, SID is a unique server-generated session identifier. It 767 can be used later as handle to fetch the results of a session. 769 SIDs SHOULD be constructed by concatenation of the 4-octet IPv4 IP 770 number belonging to the generating machine, an 8-octet timestamp, and 771 a 4-octet random value. To reduce the probability of collisions, if 772 the generating machine has any IPv4 addresses (with the exception of 773 loopback), one of them SHOULD be used for SID generation, even if all 774 communication is IPv6-based. If it has no IPv4 addresses at all, the 775 last four octets of an IPv6 address MAY be used instead. Note that 776 SID is always chosen by the receiver. If truly random values are not 777 available, it is important that the SID be made unpredictable, as 778 knowledge of the SID might be used for access control. 780 3.6. Send Schedules 782 The sender and the receiver both need to know the same send schedule. 783 This way, when packets are lost, the receiver knows when they were 784 supposed to be sent. It is desirable to compress common schedules 785 and still to be able to use an arbitrary one for the test sessions. 786 In many cases, the schedule will consist of repeated sequences of 787 packets: this way, the sequence performs some test, and the test is 788 repeated a number of times to gather statistics. 790 To implement this, we have a schedule with a given number of slots. 791 Each slot has a type and a parameter. Two types are supported: 792 exponentially distributed pseudo-random quantity (denoted by a code 793 of 0) and a fixed quantity (denoted by a code of 1). The parameter 794 is expressed as a timestamp and specifies a time interval. For a 795 type 0 slot (exponentially distributed pseudo-random quantity) this 796 interval is the mean value (or 1/lambda if the distribution density 797 function is expressed as lambda*exp(-lambda*x) for positive values of 798 x). For a type 1 (fixed quantity) slot, the parameter is the delay 799 itself. The sender starts with the beginning of the schedule, and 800 executes the instructions in the slots: for a slot of type 0, wait an 801 exponentially distributed time with a mean of the specified parameter 802 and then send a test packet (and proceed to the next slot); for a 803 slot of type 1, wait the specified time and send a test packet (and 804 proceed to the next slot). The schedule is circular: when there are 805 no more slots, the sender returns to the first slot. 807 The sender and the receiver need to be able to reproducibly execute 808 the entire schedule (so, if a packet is lost, the receiver can still 809 attach a send timestamp to it). Slots of type 1 are trivial to 810 reproducibly execute. To reproducibly execute slots of type 0, we 811 need to be able to generate pseudo-random exponentially distributed 812 quantities in a reproducible manner. The way this is accomplished is 813 discussed later. 815 Using this mechanism one can easily specify common testing scenarios. 816 Some examples include: 818 + Poisson stream: a single slot of type 0; 820 + Periodic stream: a single slot of type 1; 822 + Poisson stream of back-to-back packet pairs: two slots -- type 0 823 with a non-zero parameter and type 1 with a zero parameter. 825 Further, a completely arbitrary schedule can be specified (albeit 826 inefficiently) by making the number of test packets equal to the 827 number of schedule slots. In this case, the complete schedule is 828 transmitted in advance of an OWAMP-Test session. 830 3.7. Starting Test Sessions 832 Having requested one or more test sessions and received affirmative 833 Accept-Session responses, an OWAMP client MAY start the execution of 834 the requested test sessions by sending a Start-Sessions message to 835 the server. 837 The format of this message is as follows: 839 0 1 2 3 840 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 841 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 842 | 2 | | 843 +-+-+-+-+-+-+-+-+ | 844 | MBZ (15 octets) | 845 | | 846 | | 847 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 848 | | 849 | HMAC (16 octets) | 850 | | 851 | | 852 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 854 The server MUST respond with an Start-Ack message (which SHOULD be 855 sent as quickly as possible). Start-Ack messages have the following 856 format: 858 0 1 2 3 859 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 860 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 861 | Accept | | 862 +-+-+-+-+-+-+-+-+ | 863 | MBZ (15 octets) | 864 | | 865 | | 866 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 867 | | 868 | HMAC (16 octets) | 869 | | 870 | | 871 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 873 If Accept is non-zero, the Start-Sessions request was rejected; zero 874 means that the command was accepted. The full list of available 875 Accept values is described in Section 3.3, ``Values of the Accept 876 Field''. The server MAY, and the client SHOULD, close the connection 877 in the case of a rejection. 879 The server SHOULD start all OWAMP-Test streams immediately after it 880 sends the response or immediately after their specified start times, 881 whichever is later. If the client represents a Sender, the client 882 SHOULD start its OWAMP-Test streams immediately after it sees the 883 Start-Ack response from the Server (if the Start-Sessions command was 884 accepted) or immediately after their specified start times, whichever 885 is later. See more on OWAMP-Test sender behavior in a separate 886 section below. 888 3.8. Stop-Sessions 890 The Stop-Sessions message may be issued by either the Control-Client 891 or the Server. The format of this command is as follows: 893 0 1 2 3 894 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 895 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 896 | 3 | Accept | MBZ | 897 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 898 | Number of Sessions | 899 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 900 | MBZ (8 octets) | 901 | | 902 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 904 This is immediately followed by zero or more session description 905 records (the number of session description records is specified in 906 the ``Number of Sessions'' field above). The session description 907 record is used to indicate which packets were actually sent by the 908 sender process (rather than skipped). The header of the session 909 description record is as follows: 911 0 1 2 3 912 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 913 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| 914 | | 915 | SID (16 octets) | 916 | | 917 | | 918 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 919 | Next Seqno | 920 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 921 | Number of Skip Ranges | 922 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 924 This is immediately followed by zero or more Skip Range descriptions 925 as specified by the ``Number of Skip Ranges'' field above. Skip 926 Ranges are simply two sequence numbers that, together, indicate a 927 range of packets that were not sent: 929 0 1 2 3 930 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 931 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| 932 | First Seqno Skipped | 933 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 934 | Last Seqno Skipped | 935 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 937 Skip Ranges MUST be in order. The last (possibly full, possibly 938 incomplete) block (16 octets) of data MUST be padded with zeros, if 939 necessary. This ensures that the next session description record 940 starts on a block boundary. 942 Finally, a single block (16 octets) of HMAC is concatenated on the 943 end to complete the Stop-Sessions message. 945 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 946 | | 947 | HMAC (16 octets) | 948 | | 949 | | 950 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 952 All these records comprise one logical message: the Stop-Sessions 953 command. 955 Above, the first octet (3) indicates that this is the Stop-Sessions 956 command. 958 Non-zero Accept values indicate a failure of some sort. Zero values 959 indicate normal (but possibly premature) completion. The full list 960 of available Accept values is described in Section 3.3, ``Values of 961 the Accept Field''. 963 If Accept had a non-zero value (from either party), results of all 964 OWAMP-Test sessions spawned by this OWAMP-Control session SHOULD be 965 considered invalid, even if a Fetch-Session with SID from this 966 session works for a different OWAMP-Control session. If Accept was 967 not transmitted at all (for whatever reason, including the TCP 968 connection used for OWAMP-Control breaking), the results of all 969 OWAMP-Test sessions spawned by this OWAMP-control session MAY be 970 considered invalid. 972 Number of Sessions indicates the number of session description 973 records that immediately follow the Stop-Sessions header. 975 Number of Sessions MUST contain the number of send sessions started 976 by the local side of the control connection that have not been 977 previously terminated by a Stop-Sessions command (i.e., the 978 Control-Client MUST account for each accepted Request-Session where 979 Conf-Receiver was set; the Control-Server MUST account for each 980 accepted Request-Session where Conf-Sender was set). If the 981 Stop-Sessions message does not account for exactly the send sessions 982 controlled by that side, then it is to be considered invalid and the 983 connection SHOULD be closed and any results obtained considered 984 invalid. 986 Each session description record represents one OWAMP-Test session. 988 SID is the session identifier (SID) used to indicate which send 989 session is being described. 991 Next Seqno indicates the next sequence number that would have been 992 sent from this send session. For completed sessions, this will equal 993 NumPackets from the Request-Session. 995 Number of Skip Ranges indicates the number of holes that actually 996 occurred in the sending process. This is a range of packets that were 997 never actually sent by the sending process. For example, if a send 998 session is started too late for the first 10 packets to be sent and 999 this is the only hole in the schedule, then ``Number of Skip Ranges'' 1000 would be 1. The single Skip Range description will have First Seqno 1001 Skipped equal to 0 and Last Seqno Skipped equal to 9. This is 1002 described further in the ``Sender Behavior'' section. 1004 If the OWAMP-Control connection breaks when the Stop-Sessions command 1005 is sent, the receiver MAY not completely invalidate the session 1006 results. It MUST discard all record of packets that follow (in other 1007 words, have greater sequence number than) the last packet that was 1008 actually received before before any lost packet records. This will 1009 help differentiate between packet losses that occurred in the network 1010 and packets the sending process may have never sent. 1012 If a receiver of an OWAMP-Test session learns, through an OWAMP- 1013 Control Stop-Sessions message, that the OWAMP-Test sender's last 1014 sequence number is lower than any sequence number actually received, 1015 the results of the complete OWAMP-Test session MUST be invalidated. 1017 A receiver of an OWAMP-Test session, upon receipt of an OWAMP-Control 1018 Stop-Sessions command, MUST discard any packet records -- including 1019 lost packet records -- with a (computed) send time that falls between 1020 the current time minus Timeout and the current time. This ensures 1021 statistical consistency for the measurement of loss and duplicates in 1022 the event that the Timeout is greater than the time it takes for the 1023 Stop-Sessions command to take place. 1025 To effect complete sessions, each side of the control connection 1026 SHOULD wait until all sessions are complete before sending the 1027 Stop-Sessions message. The completed time of each sessions is 1028 determined as Timeout after the scheduled time for the last sequence 1029 number. Endpoints MAY add a small increment to the computed 1030 completed time for send endpoints to ensure the Stop-Sessions message 1031 reaches the receiver endpoint after Timeout. 1033 To effect a premature stop of sessions, the party that initiates this 1034 command MUST stop its OWAMP-Test send streams to send the Session 1035 Packets Sent values before sending this command. That party SHOULD 1036 wait until receiving the response Stop-Sessions message before 1037 stopping the receiver streams so that it can use the values from the 1038 received Stop-Sessions message to validate the data. 1040 3.9. Fetch-Session 1042 The format of this client command is as follows: 1044 0 1 2 3 1045 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 1046 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1047 | 4 | | 1048 +-+-+-+-+-+-+-+-+ | 1049 | MBZ (7 octets) | 1050 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1051 | Begin Seq | 1052 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1053 | End Seq | 1054 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1055 | | 1056 | SID (16 octets) | 1057 | | 1058 | | 1059 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1060 | | 1061 | HMAC (16 octets) | 1062 | | 1063 | | 1064 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1066 Begin Seq is the sequence number of the first requested packet. End 1067 Seq is the sequence number of the last requested packet. If Begin 1068 Seq is all zeros and End Seq is all ones, complete session is said to 1069 be requested. 1071 If a complete session is requested and the session is still in 1072 progress, or has terminated in any way other than normal, the request 1073 to fetch session results MUST be denied. If an incomplete session is 1074 requested, all packets received so far that fall into the requested 1075 range SHOULD be returned. Note that, since no commands can be issued 1076 between Start-Sessions and Stop-Sessions, incomplete requests can 1077 only happen on a different OWAMP-Control connection (from the same or 1078 different host as Control-Client). 1080 The server MUST respond with a Fetch-Ack message. The format of this 1081 server response is as follows: 1083 0 1 2 3 1084 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 1085 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1086 | Accept | Finished | MBZ (2 octets) | 1087 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1088 | Next Seqno | 1089 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1090 | Number of Skip Ranges | 1091 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1092 | Number of Records | 1093 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1094 | | 1095 | HMAC (16 octets) | 1096 | | 1097 | | 1098 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1100 Again, non-zero in the Accept field means a rejection of command. 1101 The server MUST specify zero for all remaining fields if Accept is 1102 non-zero. The client MUST ignore all remaining fields (except for the 1103 HMAC) if Accept is non-zero. The full list of available Accept 1104 values is described in Section 3.3, ``Values of the Accept Field''. 1106 Finished is non-zero if the OWAMP-Test session has terminated. 1108 Next Seqno indicates the next sequence number that would have been 1109 sent from this send session. For completed sessions, this will equal 1110 NumPackets from the Request-Session. This information is only 1111 available if the session has terminated. If Finished is zero, then 1112 Next Seqno MUST be set to zero by the server. 1114 Number of Skip Ranges indicates the number of holes that actually 1115 occurred in the sending process. This information is only available 1116 if the session has terminated. If Finished is zero, then Skip Ranges 1117 MUST be set to zero by the server. 1119 Number of Records is the number of packet records that fall within 1120 the requested range. This number might be less than the Number of 1121 Packets in the reproduction of the Request-Session command because of 1122 a session that ended prematurely or it might be greater because of 1123 duplicates. 1125 If Accept was non-zero, this concludes the response to the Fetch- 1126 Session message. If Accept was 0, the server then MUST immediately 1127 send the OWAMP-Test session data in question. 1129 The OWAMP-Test session data consists of the following (concatenated): 1131 + A reproduction of the Request-Session command that was used to 1132 start the session; it is modified so that actual sender and 1133 receiver port numbers that were used by the OWAMP-Test session 1134 always appear in the reproduction. 1136 + Zero or more (as specified) Skip Range descriptions. The last 1137 (possibly full, possibly incomplete) block (16 octets) of Skip 1138 Range descriptions is padded with zeros if necessary. 1140 + 16 octets of HMAC. 1142 + Zero or more (as specified) packet records. The last (possibly 1143 full, possibly incomplete) block (16 octets) of data is padded 1144 with zeros if necessary. 1146 + 16 octets of HMAC. 1148 Skip Range descriptions are simply two sequence numbers that, 1149 together, indicate a range of packets that were not sent: 1151 0 1 2 3 1152 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 1153 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| 1154 | First Seqno Skipped | 1155 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1156 | Last Seqno Skipped | 1157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1159 Skip Range descriptions should be sent out in order, as sorted by 1160 First Seqno. If any Skip Ranges overlap, or are out of order, the 1161 session data is to be considered invalid and the connection SHOULD be 1162 closed and any results obtained considered invalid. 1164 Each packet record is 25 octets, and includes 4 octets of sequence 1165 number, 8 octets of send timestamp, 2 octets of send timestamp error 1166 estimate, 8 octets of receive timestamp, 2 octets of receive 1167 timestamp error estimate, and 1 octet of Time To Live (TTL), or Hop 1168 Limit in IPv6: 1170 0 1 2 3 1171 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 1172 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1173 00| Seq Number | 1174 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1175 04| Send Error Estimate | Receive Error Estimate | 1176 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1177 08| Send Timestamp | 1178 12| | 1179 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1180 16| Receive Timestamp | 1181 20| | 1182 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1183 24| TTL | 1184 +-+-+-+-+-+-+-+-+ 1186 Packet records are sent out in the same order the actual packets were 1187 received. Therefore, the data is in arrival order. 1189 Note that lost packets (if any losses were detected during the 1190 OWAMP-Test session) MUST appear in the sequence of packets. They can 1191 appear either at the point when the loss was detected or at any later 1192 point. Lost packet records are distinguished as follows: 1194 + A send timestamp filled with the presumed send time (as computed 1195 by the send schedule). 1197 + A send error estimate filled with Multiplier=1, Scale=64, and S=0 1198 (see the OWAMP-Test description for definition of these quantities 1199 and explanation of timestamp format and error estimate format). 1201 + A normal receive error estimate as determined by the error of the 1202 clock being used to declare the packet lost. (It is declared lost 1203 if it is not received by the Timeout after the presumed send time, 1204 as determined by the receiver's clock.) 1206 + A receive timestamp consisting of all zero bits. 1208 + A TTL value of 255. 1210 4. OWAMP-Test 1212 This section describes OWAMP-Test protocol. It runs over UDP using 1213 sender and receiver IP and port numbers negotiated during the 1214 Request-Session exchange. 1216 As with OWAMP-Control, OWAMP-Test has three modes: unauthenticated, 1217 authenticated, and encrypted. All OWAMP-Test sessions that are 1218 spawned by an OWAMP-Control session inherit its mode. 1220 OWAMP-Control client, OWAMP-Control server, OWAMP-Test sender, and 1221 OWAMP-Test receiver can potentially all be different machines. (In a 1222 typical case, we expect that there will be only two machines.) 1224 4.1. Sender Behavior 1226 4.1.1. Packet Timings 1228 Send schedules based on slots, described previously, in conjunction 1229 with scheduled session start time, enable the sender and the receiver 1230 to compute the same exact packet sending schedule independently of 1231 each other. These sending schedules are independent for different 1232 OWAMP-Test sessions, even if they are governed by the same 1233 OWAMP-Control session. 1235 Consider any OWAMP-Test session. Once Start-Sessions exchange is 1236 complete, the sender is ready to start sending packets. Under normal 1237 OWAMP use circumstances, the time to send the first packet is in the 1238 near future (perhaps a fraction of a second away). The sender SHOULD 1239 send packets as close as possible to their scheduled time, with the 1240 following exception: if the scheduled time to send is in the past, 1241 and separated from the present by more than Timeout time, the sender 1242 MUST NOT send the packet. (Indeed, such a packet would be considered 1243 lost by the receiver anyway.) The sender MUST keep track of which 1244 packets it does not send. It will use this to tell the receiver what 1245 packets were not sent by setting Skip Ranges in the Stop-Sessions 1246 message from the sender to the receiver upon completion of the test. 1247 The Skip Ranges are also sent to a Fetch-Client as part of the 1248 session data results. These holes in the sending schedule can happen 1249 if a time in the past was specified in the Request-Session command, 1250 or if the Start-Sessions exchange took unexpectedly long, or if the 1251 sender could not start serving the OWAMP-Test session on time due to 1252 internal scheduling problems of the OS. Packets in the past, but 1253 separated from the present by less than Timeout value, SHOULD be sent 1254 as quickly as possible. With normal test rates and timeout values, 1255 the number of packets in such a burst is limited. Nevertheless, 1256 hosts SHOULD NOT intentionally schedule sessions so that such bursts 1257 of packets occur. 1259 Regardless of any scheduling delays, each packet that is actually 1260 sent MUST have the best possible approximation of its real time of 1261 departure as its timestamp (in the packet). 1263 4.1.2. OWAMP-Test Packet Format and Content 1265 The sender sends the receiver a stream of packets with the schedule 1266 specified in the Request-Session command. The sender SHOULD set the 1267 TTL in IPv4 (or Hop Limit in IPv6) in the UDP packet to 255. The 1268 format of the body of a UDP packet in the stream depends on the mode 1269 being used. 1271 For unauthenticated mode: 1273 0 1 2 3 1274 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 1275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1276 | Sequence Number | 1277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1278 | Timestamp | 1279 | | 1280 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1281 | Error Estimate | | 1282 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1283 | | 1284 . . 1285 . Packet Padding . 1286 . . 1287 | | 1288 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1290 For authenticated and encrypted modes: 1292 0 1 2 3 1293 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 1294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1295 | Sequence Number | 1296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1297 | | 1298 | MBZ (12 octets) | 1299 | | 1300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1301 | Timestamp | 1302 | | 1303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1304 | Error Estimate | | 1305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1306 | MBZ (6 octets) | 1307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1308 | | 1309 | HMAC (16 octets) | 1310 | | 1311 | | 1312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1313 | | 1314 . . 1315 . Packet Padding . 1316 . . 1317 | | 1318 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1320 The format of the timestamp is the same as in [RFC1305] and is as 1321 follows: first 32 bits represent the unsigned integer number of 1322 seconds elapsed since 0h on 1 January 1900; next 32 bits represent 1323 the fractional part of a second that has elapsed since then. 1325 So, Timestamp is represented as follows: 1326 0 1 2 3 1327 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 1328 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1329 | Integer part of seconds | 1330 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1331 | Fractional part of seconds | 1332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1334 The Error Estimate specifies the estimate of the error and 1335 synchronization. It has the following format: 1337 0 1 1338 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 1339 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1340 |S|Z| Scale | Multiplier | 1341 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1343 The first bit S SHOULD be set if the party generating the timestamp 1344 has a clock that is synchronized to UTC using an external source 1345 (e.g., the bit should be set if GPS hardware is used and it indicates 1346 that it has acquired current position and time or if NTP is used and 1347 it indicates that it has synchronized to an external source, which 1348 includes stratum 0 source, etc.); if there is no notion of external 1349 synchronization for the time source, the bit SHOULD NOT be set. The 1350 next bit has the same semantics as MBZ fields elsewhere: it MUST be 1351 set to zero by the sender and ignored by everyone else. The next six 1352 bits, Scale, form an unsigned integer; Multiplier is an unsigned 1353 integer as well. They are interpreted as follows: the error estimate 1354 is equal to Multiplier*2^(-32)*2^Scale (in seconds). [Notation 1355 clarification: 2^Scale is two to the power of Scale.] Multiplier 1356 MUST NOT be set to zero. If Multiplier is zero, the packet SHOULD be 1357 considered corrupt and discarded. 1359 Sequence numbers start with zero and are incremented by one for each 1360 subsequent packet. 1362 The minimum data segment length is, therefore, 14 octets in 1363 unauthenticated mode, and 48 octets in both authenticated mode and 1364 encrypted modes. 1366 The OWAMP-Test packet layout is the same in authenticated and 1367 encrypted modes. The encryption and authentication operations are, 1368 however, different. The difference is that in encrypted mode both 1369 the sequence number and the timestamp are protected to provide 1370 maximum data confidentiality and integrity protection while in 1371 authenticated mode the sequence number is protected while the 1372 timestamp is sent in clear text. Sending the timestamp in clear text 1373 in authenticated mode allows one to reduce the time between when a 1374 timestamp is obtained by a sender and when the packet is shipped out. 1375 In encrypted mode, the sender has to fetch the timestamp, encrypt it, 1376 and send it; in authenticated mode, the middle step is removed, 1377 potentially improving accuracy (the sequence number can be encrypted 1378 and authenticated before the timestamp is fetched). 1380 In authenticated mode, the first block (16 octets) of each packet is 1381 encrypted using AES Electronic Cookbook (ECB) mode. 1383 The key to use is obtained as follows: the 16-octet session 1384 identifier (SID) is encrypted with the same session key as is used 1385 for the corresponding OWAMP-Control session (where it is used in a 1386 different chaining mode); this is a single-block ECB encryption; its 1387 result is the key to use in encrypting (and decrypting) the packets 1388 of the particular OWAMP-Test session. 1390 ECB mode used for encrypting the first block of OWAMP-Test packets in 1391 authenticated mode does not involve any actual chaining; this way, 1392 lost, duplicated, or reordered packets do not cause problems with 1393 deciphering any packet in an OWAMP-Test session. 1395 In encrypted mode, the first two blocks (32 octets) are encrypted 1396 using AES CBC mode. The key to use is obtained in the same way as 1397 the key for authenticated mode. Each OWAMP-Test packet is encrypted 1398 as a separate stream, with just one chaining operation; chaining does 1399 not span multiple packets so that lost, duplicated, or reordered 1400 packets do not cause problems. The initialization vector for the CBC 1401 encryption is a value with all bits equal to zero. 1403 Implementation note: Naturally, the key schedule for each OWAMP-Test 1404 session MAY only be set up once per session, not once per packet. 1406 HMAC in OWAMP-Test only covers the part of the packet that is also 1407 encrypted. So, in authenticated mode, HMAC covers the first block 1408 (16 octets); in encrypted mode, HMAC covers two first blocks (32 1409 octets). In OWAMP-Test HMAC is not encrypted (note that this is 1410 different from OWAMP-Control, where encryption is stream mode is 1411 used, so everything including the HMAC blocks ends up being 1412 encrypted). The key for HMAC (authentication) is the same as the key 1413 for AES (encryption). 1415 In unauthenticated mode, no encryption or authentication is applied. 1417 Packet Padding in OWAMP-Test SHOULD be pseudo-random (it MUST be 1418 generated independently of any other pseudo-random numbers mentioned 1419 in this document). However, implementations MUST provide a 1420 configuration parameter, an option, or a different means of making 1421 Packet Padding consist of all zeros. 1423 The time elapsed between packets is computed according to the slot 1424 schedule as mentioned in Request-Session command description. At 1425 that point, we skipped over the issue of computing exponentially 1426 distributed pseudo-random numbers in a reproducible fashion. It is 1427 discussed later in a separate section. 1429 4.2. Receiver Behavior 1431 The receiver knows when the sender will send packets. The following 1432 parameter is defined: Timeout (from Request-Session). Packets that 1433 are delayed by more than Timeout are considered lost (or `as good as 1434 lost'). Note that there is never an actual assurance of loss by the 1435 network: a `lost' packet might still be delivered at any time. The 1436 original specification for IPv4 required that packets be delivered 1437 within TTL seconds or never (with TTL having a maximum value of 255). 1438 To the best of the authors' knowledge, this requirement was never 1439 actually implemented (and, of course, only a complete and universal 1440 implementation would ensure that packets do not travel for longer 1441 than TTL seconds). In fact, in IPv6, the name of this field has 1442 actually been changed to Hop Limit. Further, IPv4 specification 1443 makes no claims about the time it takes the packet to traverse the 1444 last link of the path. 1446 The choice of a reasonable value of Timeout is a problem faced by a 1447 user of OWAMP protocol, not by an implementor. A value such as two 1448 minutes is very safe. Note that certain applications (such as 1449 interactive `one-way ping') might wish to obtain the data faster than 1450 that. 1452 As packets are received, 1454 + Timestamp the received packet. 1456 + In authenticated or encrypted mode, decrypt and authenticate as 1457 necessary (packets for which authentication fails MUST be 1458 discarded). 1460 + Store the packet sequence number, send time, receive time, and the 1461 TTL for IPv4 (or Hop Limit for IPv6) from the packet IP header for 1462 the results to be transferred. 1464 + Packets not received within the Timeout are considered lost. They 1465 are recorded with their true sequence number, presumed send time, 1466 receive time value with all bits being zero, and TTL (or Hop 1467 Limit) of 255. 1469 Implementations SHOULD fetch the TTL/Hop Limit value from the IP 1470 header of the packet. If an implementation does not fetch the actual 1471 TTL value (the only good reason to not do so is inability to access 1472 the TTL field of arriving packets), it MUST record the TTL value as 1473 255. 1475 Packets that are actually received are recorded in the order of 1476 arrival. Lost packet records serve as indications of the send times 1477 of lost packets. They SHOULD be placed either at the point where the 1478 receiver learns about the loss or at any later point; in particular, 1479 one MAY place all the records that correspond to lost packets at the 1480 very end. 1482 Packets that have send time in the future MUST be recorded normally, 1483 without changing their send timestamp, unless they have to be 1484 discarded. (Send timestamps in the future would normally indicate 1485 clocks that differ by more than the delay. Some data -- such as 1486 jitter -- can be extracted even without knowledge of time difference. 1487 For other kinds of data, the adjustment is best handled by the data 1488 consumer on the basis of the complete information in a measurement 1489 session, as well as, possibly, external data.) 1491 Packets with a sequence number that was already observed (duplicate 1492 packets) MUST be recorded normally. (Duplicate packets are sometimes 1493 introduced by IP networks. The protocol has to be able to measure 1494 duplication.) 1496 If any of the following is true, the packet MUST be discarded: 1498 + Send timestamp is more than Timeout in the past or in the future. 1500 + Send timestamp differs by more than Timeout from the time when the 1501 packet should have been sent according to its sequence number. 1503 + In authenticated or encrypted mode, HMAC verification fails. 1505 5. Computing Exponentially Distributed Pseudo-Random Numbers 1507 Here we describe the way exponential random quantities used in the 1508 protocol are generated. While there is a fair number of algorithms 1509 for generating exponential random variables, most of them rely on 1510 having logarithmic function as a primitive, resulting in potentially 1511 different values, depending on the particular implementation of the 1512 math library. We use algorithm 3.4.1.S in [KNUTH], which is free 1513 of the above-mentioned problem, and guarantees the same output on any 1514 implementation. The algorithm belongs to the ziggurat family 1515 developed in the 1970s by G. Marsaglia, M. Sibuya and J. H. Ahrens 1516 [ZIGG]. It replaces the use of logarithmic function by clever bit 1517 manipulation, still producing the exponential variates on output. 1519 5.1. High-Level Description of the Algorithm 1521 For ease of exposition, the algorithm is first described with all 1522 arithmetic operations being interpreted in their natural sense. 1523 Later, exact details on data types, arithmetic, and generation of the 1524 uniform random variates used by the algorithm are given. It is an 1525 almost verbatim quotation from [KNUTH], p.133. 1527 Algorithm S: Given a real positive number 'mu', produce an 1528 exponential random variate with mean 'mu'. 1530 First, the constants 1532 Q[k] = (ln2)/(1!) + (ln2)^2/(2!) + ... + (ln2)^k/(k!), 1 <= k <= 11 1534 are computed in advance. The exact values which MUST be used by all 1535 implementations are given in the next section. This is necessary to 1536 insure that exactly the same pseudo-random sequences are produced by 1537 all implementations. 1539 S1. [Get U and shift.] Generate a 32-bit uniform random binary 1540 fraction 1542 U = (.b0 b1 b2 ... b31) [note the binary point] 1544 Locate the first zero bit b_j, and shift off the leading (j+1) bits, 1545 setting U <- (.b_{j+1} ... b31) 1547 Note: In the rare case that the zero has not been found, it is 1548 prescribed that the algorithm return (mu*32*ln2). 1550 S2. [Immediate acceptance?] If U < ln2, set X <- mu*(j*ln2 + U) and 1551 terminate the algorithm. (Note that Q[1] = ln2.) 1553 S3. [Minimize.] Find the least k >= 2 such that U < Q[k]. Generate k 1554 new uniform random binary fractions U1,...,Uk and set V <- 1555 min(U1,...,Uk). 1557 S4. [Deliver the answer.] Set X <- mu*(j + V)*ln2. 1559 5.2. Data Types, Representation, and Arithmetic 1561 The high-level algorithm operates on real numbers -- typically 1562 represented as floating point numbers. This specification prescribes 1563 that unsigned 64-bit integers be used instead. 1565 u_int64_t integers are interpreted as real numbers by placing the 1566 decimal point after the first 32 bits. In other words, conceptually, 1567 the interpretation is given by the map: 1569 u_int64_t u; 1571 u |--> (double)u / (2**32) 1573 The algorithm produces a sequence of such u_int64_t integers that, 1574 for any given value of SID, is guaranteed to be the same on any 1575 implementation. 1577 We specify that the u_int64_t representations of the first 11 values 1578 of the Q array in the high-level algorithm MUST be as follows: 1580 #1 0xB17217F8, 1581 #2 0xEEF193F7, 1582 #3 0xFD271862, 1583 #4 0xFF9D6DD0, 1584 #5 0xFFF4CFD0, 1585 #6 0xFFFEE819, 1586 #7 0xFFFFE7FF, 1587 #8 0xFFFFFE2B, 1588 #9 0xFFFFFFE0, 1589 #10 0xFFFFFFFE, 1590 #11 0xFFFFFFFF 1592 For example, Q[1] = ln2 is indeed approximated by 0xB17217F8/(2**32) 1593 = 0.693147180601954; for j > 11, Q[j] is 0xFFFFFFFF. 1595 Small integer j in the high-level algorithm is represented as 1596 u_int64_t value j * (2**32). 1598 Operation of addition is done as usual on u_int64_t numbers; however, 1599 the operation of multiplication in the high-level algorithm should be 1600 replaced by 1602 (u, v) |---> (u * v) >> 32. 1604 Implementations MUST compute the product (u * v) exactly. For 1605 example, a fragment of unsigned 128-bit arithmetic can be implemented 1606 for this purpose (see sample implementation below). 1608 5.3. Uniform Random Quantities 1610 The procedure for obtaining a sequence of 32-bit random numbers (such 1611 as U in algorithm S) relies on using AES encryption in counter mode. 1612 To describe the exact working of the algorithm, we introduce two 1613 primitives from Rijndael. Their prototypes and specification are 1614 given below, and they are assumed to be provided by the supporting 1615 Rijndael implementation, such as [RIJN]. 1617 + A function that initializes a Rijndael key with bytes from seed 1618 (the SID will be used as the seed): 1620 void KeyInit(unsigned char seed[16]); 1622 + A function that encrypts the 16-octet block inblock with the 1623 specified key, returning a 16-octet encrypted block. Here 1624 keyInstance is an opaque type used to represent Rijndael keys: 1626 void BlockEncrypt(keyInstance key, unsigned char inblock[16]); 1628 Algorithm Unif: given a 16-octet quantity seed, produce a sequence of 1629 unsigned 32-bit pseudo-random uniformly distributed integers. In 1630 OWAMP, the SID (session ID) from Control protocol plays the role of 1631 seed. 1633 U1. [Initialize Rijndael key] key <- KeyInit(seed) [Initialize an 1634 unsigned 16-octet (network byte order) counter] c <- 0 U2. [Need 1635 more random bytes?] Set i <- c mod 4. If (i == 0) set s <- 1636 BlockEncrypt(key, c) 1638 U3. [Increment the counter as unsigned 16-octet quantity] c <- c + 1 1640 U4. [Do output] Output the i_th quartet of octets from s starting 1641 from high-order octets, converted to native byte order and 1642 represented as OWPNum64 value (as in 3.b). 1644 U5. [Loop] Go to step U2. 1646 6. Security Considerations 1648 6.1. Introduction 1650 The goal of authenticated mode to let one passphrase-protect the 1651 service provided by a particular OWAMP-Control server. One can 1652 imagine a variety of circumstances where this could be useful. 1653 Authenticated mode is designed to prohibit theft of service. 1655 An additional design objective of the authenticated mode was to make 1656 it impossible for an attacker who cannot read traffic between OWAMP- 1657 Test sender and receiver to tamper with test results in a fashion 1658 that affects the measurements, but not other traffic. 1660 The goal of encrypted mode is quite different: to make it hard for a 1661 party in the middle of the network to make results look `better' than 1662 they should be. This is especially true if one of client and server 1663 does not coincide with either sender or receiver. 1665 Encryption of OWAMP-Control using AES CBC mode with blocks of HMAC 1666 after each message aims to achieve two goals: (i) to provide secrecy 1667 of exchange; (ii) to provide authentication of each message. 1669 6.2. Preventing Third-Party Denial of Service 1671 OWAMP-Test sessions directed at an unsuspecting party could be used 1672 for denial of service (DoS) attacks. In unauthenticated mode, 1673 servers SHOULD limit receivers to hosts they control or to the OWAMP- 1674 Control client. 1676 Unless otherwise configured, the default behavior of servers MUST be 1677 to decline requests where the Receiver Address field is not equal to 1678 the address that the control connection was initiated from or an 1679 address of the server (or an address of a host it controls). Given 1680 the TCP handshake procedure and sequence numbers in the control 1681 connection, this ensures that the hosts that make such requests are 1682 actually those hosts themselves, or at least on the path towards 1683 them. If either this test or the handshake procedure were omitted, 1684 it would become possible for attackers anywhere in the Internet to 1685 request large amounts of test packets be directed against victim 1686 nodes somewhere else. 1688 In any case, OWAMP-Test packets with a given source address MUST only 1689 be sent from the node that has been assigned that address (i.e., 1690 address spoofing is not permitted). 1692 6.3. Covert Information Channels 1694 OWAMP-Test sessions could be used as covert channels of information. 1695 Environments that are worried about covert channels should take this 1696 into consideration. 1698 6.4. Requirement to Include AES in Implementations 1700 Notice that AES, in counter mode, is used for pseudo-random number 1701 generation, so implementation of AES MUST be included even in a 1702 server that only supports unauthenticated mode. 1704 6.5. Resource Use Limitations 1706 An OWAMP server can consume resources of various kinds. The two most 1707 important kinds of resources are network capacity and memory (primary 1708 or secondary) for storing test results. 1710 Any implementation of OWAMP server MUST include technical mechanisms 1711 to limit the use of network capacity and memory. Mechanisms for 1712 managing the resources consumed by unauthenticated users and users 1713 authenticated with a KeyID and passphrase SHOULD be separate. The 1714 default configuration of an implementation MUST enable these 1715 mechanisms and set the resource use limits to conservatively low 1716 values. 1718 One way to design the resource limitation mechanisms is as follows: 1719 assign each session to a user class. User classes are partially 1720 ordered with ``includes'' relation, with one class (``all users'') 1721 that is always present and that includes any other class. The 1722 assignment of a session to a user class can be based on the presence 1723 of authentication of the session, the KeyID, IP address range, time 1724 of day, and, perhaps, other factors. Each user class would have a 1725 limit for usage of network capacity (specified in units of 1726 bit/second) and memory for storing test results (specified in units 1727 of octets). Along with the limits for resource use, current use 1728 would be tracked by the server. When a session is requested by a 1729 user in a specific user class, the resources needed for this session 1730 are computed: the average network capacity use (based on the sending 1731 schedule) and the maximum memory use (based on the number of packets 1732 and number of octets each packet would need to be stored internally 1733 -- note that outgoing sessions would not require any memory use). 1734 These resource use numbers are added to the current resource use 1735 numbers for the given user class; if such addition would take the 1736 resource use outside of the limits for the given user class, the 1737 session is rejected. When resources are reclaimed, corresponding 1738 measures are subtracted from the current use. Network capacity is 1739 reclaimed as soon as the session ends. Memory is reclaimed when the 1740 data is deleted. For unauthenticated sessions, memory consumed by an 1741 OWAMP-Test session SHOULD be reclaimed after the OWAMP-Control 1742 connection that initiated the session is closed (gracefully or 1743 otherwise). For authenticated sessions, the administrator who 1744 configures the service should be able to decide the exact policy, but 1745 useful policy mechanisms that MAY be implemented are the ability to 1746 automatically reclaim memory when the data is retrieved and the 1747 ability to reclaim memory after a certain configurable (based on user 1748 class) period of time passes after the OWAMP-Test session terminates. 1750 6.6. Use of Cryptographic Primitives in OWAMP 1752 At an early stage in designing the protocol, we considered using 1753 Transport Layer Security (TLS) [RFC2246, RFC3546] and IPsec [RFC2401] 1754 as cryptographic security mechanisms for OWAMP; later, we also 1755 considered DTLS. The disadvantages of those are as follows (not an 1756 exhaustive list): 1758 Regarding TLS: 1760 + TLS could be used to secure TCP-based OWAMP-Control, but it would 1761 be difficult to use it to secure UDP-based OWAMP-Test: OWAMP-Test 1762 packets, if lost, are not resent, so packets have to be 1763 (optionally) encrypted and authenticated while retaining 1764 individual usability. Stream-based TLS cannot be easily used for 1765 this. 1767 + Dealing with streams, TLS does not authenticate individual 1768 messages (even in OWAMP-Control). The easiest way out would be to 1769 add some known-format padding to each message and verify that the 1770 format of the padding is intact before using the message. The 1771 solution would thus lose some of its appeal (``just use TLS''); it 1772 would also be much more difficult to evaluate the security of this 1773 scheme with the various modes and options of TLS -- it would 1774 almost certainly not be secure with all. The capacity of an 1775 attacker to replace parts of messages (namely, the end) with 1776 random garbage could have serious security implications and would 1777 need to be analyzed carefully: suppose, for example, that a 1778 parameter that is used in some form to control the rate were 1779 replaced by random garbage -- chances are the result (an unsigned 1780 integer) would be quite large. 1782 + Dependent on the mode of use, one can end up with a requirement 1783 for certificates for all users and a PKI. Even if one is to 1784 accept that PKI is desirable, there just isn't a usable one today. 1786 + TLS requires a fairly large implementation. OpenSSL, for example, 1787 is larger than our implementation of OWAMP as a whole. This can 1788 matter for embedded implementations. 1790 Regarding DTLS: 1792 + Duplication and, similarly, reordering are network phenomena that 1793 OWAMP needs to be able to measure; yet anti-replay measures and 1794 reordering protection of DTLS would prevent the duplicated and 1795 reordered packets from reaching the relevant part of the OWAMP 1796 code. One could, of course, modify DTLS so that these protections 1797 are weakened, or even specify examining the messages in a 1798 carefully crafted sequence somewhere in between of DTLS checks, 1799 but then, of course, the advantage of using an existing protocol 1800 would not be realized. 1802 + In authenticated mode the timestamp is in the clear and not 1803 protected cryptographically in any way, while the rest of the 1804 message has the same protection as in encrypted mode. This mode 1805 allows one to trade off cryptographic protection against accuracy 1806 of timestamps. For example, the APAN hardware implementation of 1807 OWAMP [APAN-OWAMP] is capable of supporting authenticated mode. 1808 The accuracy of these measurements is in sub-microsecond range. 1809 The errors in OWAMP measurements of Abilene [Abilene-OWAMP] (done 1810 using a software implementation, in its encrypted mode) exceed 1811 10us. Users in different environments have different concerns, 1812 and some might very well care about every last microsecond of 1813 accuracy; at the same time, users in these same environments might 1814 care about access control to the service. Authenticated mode 1815 permits them to control access to the server, yet use unprotected 1816 timestamps, perhaps generated by a hardware device. 1818 Regarding IPsec: 1820 + What we now call authenticated mode would not be possible (in 1821 IPsec you can't authenticate part of a packet). 1823 + The deployment paths of IPsec and OWAMP could be separate if OWAMP 1824 does not depend on IPsec. After nine years of IPsec, only 0.05% 1825 of traffic on an advanced backbone network such as Abilene uses 1826 IPsec (for comparison purposes with encryption above layer 4, SSH 1827 use is at 2-4% and HTTPS use is at 0.2-0.6%). It is desirable to 1828 be able to deploy OWAMP on as large of a number of different 1829 platforms as possible. 1831 + The deployment problems of a protocol dependent on IPsec would be 1832 especially acute in the case of lightweight embedded devices. 1833 Ethernet switches, DSL ``modems,'' and other such devices mostly 1834 do not support IPsec. 1836 + The API for manipulating IPsec from an application is currently 1837 poorly understood. Writing a program that needs to encrypt some 1838 packets, authenticate some packets, and leave some open -- for the 1839 same destination -- would become more of an exercise in IPsec 1840 rather than in IP measurement. 1842 For the enumerated reasons, we decided to use a simple cryptographic 1843 protocol (based on a block cipher in CBC mode) that is different from 1844 TLS and IPsec. 1846 6.7. Cryptographic primitive replacement 1848 It might become necessary in the future to replace AES, or the way it 1849 is used in OWAMP, with a new cryptographic primitive---or to make 1850 other security-related changes to the protocol. OWAMP provides a 1851 well-defined point of extensibility: the Modes word in the server 1852 greeting and the Mode response in the Set-Up-Response message. For 1853 example, if a simple replacement of AES with a different block cipher 1854 with a 128-bit block is needed, this could be accomplished as 1855 follows: take two bits from the reserved (MBZ) part of the Modes word 1856 of the server greeting; use one of these bits to indicate encrypted 1857 mode with the new cipher and another one to indicate authenticated 1858 mode with the new cipher. (Bit consumption could, in fact, be 1859 reduced from two to one, if the client is allowed to return a mode 1860 selection with more than a single bit set: one could designate a 1861 single bit to mean that the new cipher is supported [in the case of 1862 the server] or selected [in the case of the client] and continue to 1863 use already allocated bits for authenticated and encrypted modes; 1864 this optimization is unimportant conceptually, but could be useful in 1865 practice to make the best use of bits.) Then, if the new cipher is 1866 negotiated, all subsequent operations simply use it instead of AES. 1867 Note that the normal transition sequence would be used in such a 1868 case: implementations would probably first start supporting and 1869 preferring the new cipher, and then drop support for the old 1870 (presumably no longer considered secure) cipher. 1872 If the need arises to make more extensive changes (perhaps replace 1873 AES with a 256-bit-block cipher), this would be more difficult and 1874 would require changing the layout of the messages. However, the 1875 change can still be conducted within the framework of OWAMP 1876 extensibility using the Modes/Mode words. (The semantics of the new 1877 bits [or single bit, if the optimization described above is used] 1878 would include the change to message layout as well as the change in 1879 the cryptographic primitive.) 1881 Each of the bits in the Modes word can be used for an independent 1882 extension. The extensions signaled by various bits are orthogonal: 1883 for example, one bit might be allocated to change from AES-128 to 1884 some other cipher, another bit might be allocated to add a protocol 1885 feature (such as, e.g., support for measuring over multicast), yet 1886 another might be allocated to change a key derivation function, etc. 1887 The progression of versions is not a linear order, but rather partial 1888 order. An implementation can implement any subset of these features 1889 (of course, features can be made mandatory to implement---e.g., new 1890 more secure ciphers if they are needed). 1892 Should a cipher with a different key size, say a 256-bit key, become 1893 needed, a new key derivation function for OWAMP-Test keys would also 1894 be needed. The semantics of change in the cipher SHOULD then in the 1895 future be tied to semantics of change in the key derivation function 1896 (KDF). One KDF that might be considered for the purpose might be a 1897 pseudo-random function (PRF) with appropriately sized output, such as 1898 256 bits (perhaps HMAC-SHA256, if it is then still considered a 1899 secure PRF), which could then be used to derive the OWAMP-Test 1900 session keys from the OWAMP-Control session key by using the OWAMP- 1901 Control session key as the HMAC key and the SID as HMAC message. 1903 Note that the replacement scheme outlined above is trivially 1904 susceptible to downgrade attacks: a malicious party in the middle can 1905 flip modes bits as the mode is negotiated so that the oldest and 1906 weakest mode supported by the two parties is used. If this is deemed 1907 problematic at the time of cryptographic primitive replacement, the 1908 scheme might be augmented with a measure to prevent such an attack 1909 (by perhaps exchanging the modes again once a secure communications 1910 channel is established, comparing the two sets of mode words, and 1911 dropping the connection should they not match). 1913 6.8. Long-term manually managed keys 1915 OWAMP-Control uses long-term keys with manual management. These keys 1916 are used to automatically negotiate session keys for each OWAMP- 1917 Control session running in authenticated or encrypted mode. The 1918 number of these keys managed by a server scales linearly with (and, 1919 in fact, is equal to) the number of administratively different users 1920 (perhaps particular humans, roles, or robots representing sites) that 1921 need to connect to this server. Similarly, the number of different 1922 manual keys managed by each client is the number of different servers 1923 that the client needs to connect to. This use of manual long-term 1924 keys is compliant with [BCP107]. 1926 6.9. (Not) Using Time as Salt 1928 A natural idea is to use the current time as salt when deriving 1929 session keys. Unfortunately, this appears too limiting. 1931 While OWAMP is often run on hosts with well-synchronized clocks, it 1932 is also possible to run it on hosts with clocks completely untrained. 1933 The delays obtained thusly are, of course, not directly usable; 1934 however, some metrics, such as unidirectional loss, reordering, 1935 measures of congestion such as the median delay minus minimum, and 1936 many others are usable directly and immediately (and improve upon the 1937 information that would have been provided by a round-trip 1938 measurement); further, even delay information can be useful with 1939 appropriate post-processing---indeed, one can even argue that running 1940 the clocks free and post-processing the results of a mesh of 1941 measurements will result in better accuracy, as more information is 1942 available a posteriori and correlation of data from different hosts 1943 is possible in post-processing, but not with online clock training. 1945 Given this, time is not used as salt in key derivation. 1947 6.10. The Use of AES-CBC and HMAC 1949 OWAMP relies on AES-CBC for confidentiality and on HMAC-SHA1 1950 truncated to 128 bits for message authentication. Random IV choice 1951 is important for prevention of a codebook attack on the first block 1952 (it should also be noted that, with its 128-bit block size, AES is 1953 more resistant to codebook attacks than ciphers with shorter blocks; 1954 we use random IV anyway). 1956 HMAC MUST verify. It is crucial to check for this before using the 1957 message, otherwise existential forgery becomes possible. The 1958 complete message for which HMAC verification fails MUST be discarded 1959 (for both short messages consisting of a few blocks and potentially 1960 long messages, such as a response to the Fetch-Session command); if 1961 such a message is part of OWAMP-Control, the connection MUST be 1962 dropped. 1964 Since OWAMP messages can have different numbers of blocks, the 1965 existential forgery attack described in example 9.62 of [MENEZES] 1966 becomes a concern. To prevent it (and to simplify implementation), 1967 the length of any message becomes known after decrypting the first 1968 block of it. 1970 A special case is the first (fixed-length) message sent by the 1971 client. There, the token is a concatenation of the 128-bit challenge 1972 (transmitted by the server in the clear) and a 128-bit session key 1973 (generated randomly by the client, encrypted with AES-CBC with IV=0. 1974 Since IV=0, the challenge (a single cipher block) is simply encrypted 1975 with the secret key. Therefore, we rely on resistance of AES to 1976 chosen plaintext attacks (as the challenge could be substituted by an 1977 attacker). It should be noted that the number of blocks of chosen 1978 plaintext an attacker can have encrypted with the secret key is 1979 limited by the number of sessions the client wants to initiate. An 1980 attacker who knows the encryption of a server's challenge can produce 1981 an existential forgery of the session key and thus disrupt the 1982 session; however, any attacker can disrupt a session by corrupting 1983 the protocol messages in an arbitrary fashion, therefore no new 1984 threat is created here; nevertheless, we require that the server 1985 never issues the same challenge twice (if challenges are generated 1986 randomly, a repetition would occur, on average, after 2^64 sessions; 1987 we deem this satisfactory as this is enough even for an implausibly 1988 busy server that participates in 1,000,000 sessions per second to go 1989 without repetitions for more than 500 centuries). With respect to 1990 the second part of the token, an attacker can produce an existential 1991 forgery of the session key by modifying the second half of the 1992 client's token while leaving the first part intact. This forgery, 1993 however, would be immediately discovered by the client when the HMAC 1994 on the server's next message (acceptance or rejection of the 1995 connection) does not verify. 1997 7. IANA Considerations 1999 IANA is requested to allocate a well-known TCP port number for the 2000 OWAMP-Control part of the OWAMP protocol. 2002 8. Internationalization Considerations 2004 The protocol does not carry any information in a natural language, 2005 with the possible exception of the KeyID in OWAMP-Control, which is 2006 encoded in UTF-8. 2008 9. Appendix A: Sample C Code for Exponential Deviates 2010 The values in array Q[] are the exact values that MUST be used by all 2011 implementations (see sections 5.1 and 5.2). This appendix only 2012 serves for illustrative purposes. 2014 /* 2015 ** Example usage: generate a stream of exponential (mean 1) 2016 ** random quantities (ignoring error checking during initialization). 2017 ** If a variate with some mean mu other than 1 is desired, the output 2018 ** of this algorithm can be multiplied by mu according to the rules 2019 ** of arithmetic we described. 2021 ** Assume that a 16-octet 'seed' has been initialized 2022 ** (as the shared secret in OWAMP, for example) 2023 ** unsigned char seed[16]; 2025 ** OWPrand_context next; 2027 ** (initialize state) 2028 ** OWPrand_context_init(&next, seed); 2030 ** (generate a sequence of exponential variates) 2031 ** while (1) { 2032 ** u_int64_t num = OWPexp_rand64(&next); 2033 2034 ... 2035 ** } 2036 */ 2038 #include 2040 typedef u_int64_t u_int64_t; 2042 /* (K - 1) is the first k such that Q[k] > 1 - 1/(2^32). */ 2043 #define K 12 2045 #define BIT31 0x80000000UL /* See if first bit in the lower 2046 32 bits is zero. */ 2047 #define MASK32(n) ((n) & 0xFFFFFFFFUL) 2049 #define EXP2POW32 0x100000000ULL 2051 typedef struct OWPrand_context { 2052 unsigned char counter[16]; /* Counter (network byte order). */ 2053 keyInstance key; /* Key to encrypt the counter. */ 2054 unsigned char out[16]; /* The encrypted block. */ 2056 } OWPrand_context; 2058 /* 2059 ** The array has been computed according to the formula: 2060 ** 2061 ** Q[k] = (ln2)/(1!) + (ln2)^2/(2!) + ... + (ln2)^k/(k!) 2062 ** 2063 ** as described in algorithm S. (The values below have been 2064 ** multiplied by 2^32 and rounded to the nearest integer.) 2065 ** These exact values MUST be used so that different implementation 2066 ** produce the same sequences. 2067 */ 2068 static u_int64_t Q[K] = { 2069 0, /* Placeholder - so array indices start from 1. */ 2070 0xB17217F8, 2071 0xEEF193F7, 2072 0xFD271862, 2073 0xFF9D6DD0, 2074 0xFFF4CFD0, 2075 0xFFFEE819, 2076 0xFFFFE7FF, 2077 0xFFFFFE2B, 2078 0xFFFFFFE0, 2079 0xFFFFFFFE, 2080 0xFFFFFFFF 2081 }; 2083 /* this element represents ln2 */ 2084 #define LN2 Q[1] 2086 /* 2087 ** Convert an unsigned 32-bit integer into a u_int64_t number. 2088 */ 2089 u_int64_t 2090 OWPulong2num64(u_int32_t a) 2091 { 2092 return ((u_int64_t)1 << 32) * a; 2093 } 2095 /* 2096 ** Arithmetic functions on u_int64_t numbers. 2097 */ 2099 /* 2100 ** Addition. 2101 */ 2102 u_int64_t 2103 OWPnum64_add(u_int64_t x, u_int64_t y) 2104 { 2105 return x + y; 2106 } 2108 /* 2109 ** Multiplication. Allows overflow. Straightforward implementation 2110 ** of Algorithm 4.3.1.M (p.268) from [KNUTH]. 2111 */ 2112 u_int64_t 2113 OWPnum64_mul(u_int64_t x, u_int64_t y) 2114 { 2115 unsigned long w[4]; 2116 u_int64_t xdec[2]; 2117 u_int64_t ydec[2]; 2119 int i, j; 2120 u_int64_t k, t, ret; 2122 xdec[0] = MASK32(x); 2123 xdec[1] = MASK32(x>>32); 2124 ydec[0] = MASK32(y); 2125 ydec[1] = MASK32(y>>32); 2127 for (j = 0; j < 4; j++) 2128 w[j] = 0; 2130 for (j = 0; j < 2; j++) { 2131 k = 0; 2132 for (i = 0; ; ) { 2133 t = k + (xdec[i]*ydec[j]) + w[i + j]; 2134 w[i + j] = t%EXP2POW32; 2135 k = t/EXP2POW32; 2136 if (++i < 2) 2137 continue; 2138 else { 2139 w[j + 2] = k; 2140 break; 2141 } 2142 } 2143 } 2145 ret = w[2]; 2146 ret <<= 32; 2147 return w[1] + ret; 2148 } 2150 /* 2151 ** Seed the random number generator using a 16-byte quantity 'seed' 2152 ** (== the session ID in OWAMP). This function implements step U1 2153 ** of algorithm Unif. 2154 */ 2156 void 2157 OWPrand_context_init(OWPrand_context *next, unsigned char *seed) 2158 { 2159 int i; 2161 /* Initialize the key */ 2162 rijndaelKeyInit(next->key, seed); 2164 /* Initialize the counter with zeros */ 2165 memset(next->out, 0, 16); 2166 for (i = 0; i < 16; i++) 2167 next->counter[i] = 0UL; 2168 } 2170 /* 2171 ** Random number generating functions. 2172 */ 2174 /* 2175 ** Generate and return a 32-bit uniform random value (saved in the less 2176 ** significant half of the u_int64_t). This function implements steps 2177 ** U2-U4 of the algorithm Unif. 2178 */ 2179 u_int64_t 2180 OWPunif_rand64(OWPrand_context *next) 2181 { 2182 int j; 2183 u_int8_t *buf; 2184 u_int64_t ret = 0; 2186 /* step U2 */ 2187 u_int8_t i = next->counter[15] & (u_int8_t)3; 2188 if (!i) 2189 rijndaelEncrypt(next->key, next->counter, next->out); 2191 /* Step U3. Increment next.counter as a 16-octet single 2192 quantity in network byte order for AES counter mode. */ 2193 for (j = 15; j >= 0; j--) 2194 if (++next->counter[j]) 2195 break; 2197 /* Step U4. Do output. The last 4 bytes of ret now contain the 2198 random integer in network byte order */ 2199 buf = &next->out[4*i]; 2200 for (j=0; j<4; j++) { 2201 ret <<= 8; 2202 ret += *buf++; 2203 } 2204 return ret; 2205 } 2207 /* 2208 ** Generate an exponential deviate with mean 1. 2209 */ 2210 u_int64_t 2211 OWPexp_rand64(OWPrand_context *next) 2212 { 2213 unsigned long i, k; 2214 u_int32_t j = 0; 2215 u_int64_t U, V, J, tmp; 2217 /* Step S1. Get U and shift */ 2218 U = OWPunif_rand64(next); 2220 while ((U & BIT31) && (j < 32)) { /* Shift until first 0. */ 2221 U <<= 1; 2222 j++; 2223 } 2224 /* Remove the 0 itself. */ 2225 U <<= 1; 2227 U = MASK32(U); /* Keep only the fractional part. */ 2228 J = OWPulong2num64(j); 2230 /* Step S2. Immediate acceptance? */ 2231 if (U < LN2) /* return (j*ln2 + U) */ 2232 return OWPnum64_add(OWPnum64_mul(J, LN2), U); 2234 /* Step S3. Minimize. */ 2235 for (k = 2; k < K; k++) 2236 if (U < Q[k]) 2237 break; 2238 V = OWPunif_rand64(next); 2239 for (i = 2; i <= k; i++) { 2240 tmp = OWPunif_rand64(next); 2241 if (tmp < V) 2242 V = tmp; 2243 } 2245 /* Step S4. Return (j+V)*ln2 */ 2246 return OWPnum64_mul(OWPnum64_add(J, V), LN2); 2247 } 2249 10. Appendix B: Test Vectors for Exponential Deviates 2251 It is important that the test schedules generated by different 2252 implementations from identical inputs be identical. The non-trivial 2253 part is the generation of pseudo-random exponentially distributed 2254 deviates. To aid implementors in verifying interoperability, several 2255 test vectors are provided. For each of the four given 128-bit values 2256 of SID represented as hexadecimal numbers, 1,000,000 exponentially 2257 distributed 64-bit deviates are generated as described above. As 2258 they are generated, they are all added to each other. The sum of all 2259 1,000,000 deviates is given as a hexadecimal number for each SID. An 2260 implementation MUST produce exactly these hexadecimal numbers. To 2261 aid in the verification of the conversion of these numbers to values 2262 of delay in seconds, approximate values are given (assuming 2263 lambda=1). An implementation SHOULD produce delay values in seconds 2264 that are close to the ones given below. 2266 SID = 0x2872979303ab47eeac028dab3829dab2 2267 SUM[1000000] = 0x000f4479bd317381 (1000569.739036 seconds) 2269 SID = 0x0102030405060708090a0b0c0d0e0f00 2270 SUM[1000000] = 0x000f433686466a62 (1000246.524512 seconds) 2272 SID = 0xdeadbeefdeadbeefdeadbeefdeadbeef 2273 SUM[1000000] = 0x000f416c8884d2d3 (999788.533277 seconds) 2275 SID = 0xfeed0feed1feed2feed3feed4feed5ab 2276 SUM[1000000] = 0x000f3f0b4b416ec8 (999179.293967 seconds) 2278 11. Normative References 2280 [AES] Advanced Encryption Standard (AES), 2281 http://csrc.nist.gov/encryption/aes/ 2283 [BCP107] S. Bellovin, R. Housley, `Guidelines for Cryptographic Key 2284 Management', RFC 4107, June 2005. 2286 [RFC2026] S. Bradner, `The Internet Standards Process -- Revision 3', 2287 RFC 2026, October 1996. 2289 [RFC2104] H. Krawczyk, M. Bellare, R. Canetti, `HMAC: Keyed-Hashing 2290 for Message Authentication', RFC2104, February 1997. 2292 [RFC2119] S. Bradner, `Key words for use in RFCs to Indicate 2293 Requirement Levels', RFC 2119, March 1997. 2295 [RFC2330] V. Paxon, G. Almes, J. Mahdavi, M. Mathis, `Framework for 2296 IP Performance Metrics' RFC 2330, May 1998. 2298 [RFC2474] K. Nichols, S. Blake, F. Baker, D. Black, `Definition of 2299 the Differentiated Services Field (DS Field) in the IPv4 and 2300 IPv6 Headers', RFC 2474, December 1998. 2302 [RFC2679] G. Almes, S. Kalidindi, and M. Zekauskas, `A One-way Delay 2303 Metric for IPPM', RFC 2679, September 1999. 2305 [RFC2680] G. Almes, S. Kalidindi, and M. Zekauskas, `A One-way Packet 2306 Loss Metric for IPPM', RFC 2680, September 1999. 2308 [RFC2836] S. Brim, B. Carpenter, F. Le Faucheur, `Per Hop Behavior 2309 Identification Codes', RFC 2836, May 2000. 2311 [RFC2898] B. Kaliski, `PKCS #5: Password-Based Cryptography 2312 Specification, Version 2.0', RFC 2898, September 2000. 2314 12. Informative References 2316 [APAN-OWAMP] Z. Shu and K. Kobayashi, HOTS: An OWAMP-Compliant 2317 Hardware Packet Timestamper, In Proceedings of PAM 2005, 2318 http://www.pam2005.org/PDF/34310360.pdf 2320 [BRIX] Brix Networks, http://www.brixnet.com/ 2322 [ZIGG] G. Marsaglia, M. Sibuya, and J. H. Ahrens, Communications of 2323 ACM, 15 (1972), 876-877. 2325 [MENEZES] A. J. Menezes, P. C. van Oorschot, and S. A. Vanstone, 2326 Handbook of Applied Cryptography, CRC Press, revised reprint 2327 with updates, 1997. 2329 [KNUTH] D. Knuth, The Art of Computer Programming, vol.2, 3rd 2330 edition, 1998. 2332 [Abilene-OWAMP] One-way Latency Measurement (OWAMP), 2333 http://e2epi.internet2.edu/owamp/ 2335 [RIJN] Reference ANSI C Implementation of Rijndael 2336 http://www.esat.kuleuven.ac.be/~rijmen/rijndael/rijndaelref.zip 2338 [RIPE] RIPE NCC Test-Traffic Measurements home, 2339 http://www.ripe.net/test-traffic/. 2341 [RIPE-NLUUG] H. Uijterwaal and O. Kolkman, `Internet Delay 2342 Measurements Using Test-Traffic', Spring 1998 Dutch Unix User 2343 Group Meeting, 2344 http://www.ripe.net/test-traffic/Talks/9805_nluug.ps.gz. 2346 [SURVEYOR] Surveyor Home Page, http://www.advanced.org/surveyor/. 2348 [SURVEYOR-INET] S. Kalidindi and M. Zekauskas, `Surveyor: An 2349 Infrastructure for Network Performance Measurements', 2350 Proceedings of INET'99, June 1999. 2351 http://www.isoc.org/inet99/proceedings/4h/4h_2.htm 2353 [RFC1305] D. Mills, `Network Time Protocol (Version 3) Specification, 2354 Implementation and Analysis', RFC 1305, March 1992. 2356 [RFC2246] T. Dierks, C. Allen, `The TLS Protocol Version 1.0', 2357 January 1999. 2359 [RFC2401] S. Kent, R. Atkinson, `Security Architecture for the 2360 Internet Protocol', November 1998. 2362 [RFC3546] S. Blake-Wilson, M. Nystrom, D. Hopwood, J. Mikkelsen, T. 2363 Wright, `Transport Layer Security (TLS) Extensions', June 2003. 2365 [RFC4086] D. Eastlake 3rd, J. Schiller, S. Crocker, `Randomness 2366 Recommendations for Security', June 2005. 2368 13. Authors' Addresses 2370 Stanislav Shalunov 2371 Internet2 2372 1000 Oakbrook Drive, Suite 300 2373 Ann Arbor, MI 48104 2374 Email: shalunov@internet2.edu 2375 SIP: shalunov@internet2.edu 2377 Benjamin Teitelbaum 2378 Internet2 2379 1000 Oakbrook Drive, Suite 300 2380 Ann Arbor, MI 48104 2381 Email: ben@internet2.edu 2382 SIP: ben@internet2.edu 2383 Anatoly Karp 2384 4710 Regent St, Apt 81B 2385 Madison, WI 53705 2386 Telephone: +1-608-347-6255 2387 Email: ankarp@charter.net 2389 Jeff W. Boote 2390 Internet2 2391 1000 Oakbrook Drive, Suite 300 2392 Ann Arbor, MI 48104 2393 Email: boote@internet2.edu 2394 SIP: boote@internet2.edu 2396 Matthew J. Zekauskas 2397 Internet2 2398 1000 Oakbrook Drive, Suite 300 2399 Ann Arbor, MI 48104 2400 Email: matt@internet2.edu 2401 SIP: matt@internet2.edu 2403 Intellectual Property 2405 The IETF takes no position regarding the validity or scope of any 2406 Intellectual Property Rights or other rights that might be claimed to 2407 pertain to the implementation or use of the technology described in 2408 this document or the extent to which any license under such rights 2409 might or might not be available; nor does it represent that it has 2410 made any independent effort to identify any such rights. Information 2411 on the procedures with respect to rights in RFC documents can be found 2412 in BCP 78 and BCP 79. 2414 Copies of IPR disclosures made to the IETF Secretariat and any 2415 assurances of licenses to be made available, or the result of an 2416 attempt made to obtain a general license or permission for the use of 2417 such proprietary rights by implementers or users of this 2418 specification can be obtained from the IETF on-line IPR repository at 2419 http://www.ietf.org/ipr. 2421 The IETF invites any interested party to bring to its attention any 2422 copyrights, patents or patent applications, or other proprietary 2423 rights which may cover technology that may be required to implement 2424 this standard. Please address the information to the IETF at 2425 ietf-ipr@ietf.org. 2427 Disclaimer of Validity 2429 This document and the information contained herein are provided on an 2430 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 2431 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 2432 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 2433 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 2434 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 2435 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2437 Copyright Statement 2439 Copyright (C) The Internet Society (2006). This document is subject 2440 to the rights, licenses and restrictions contained in BCP 78, and 2441 except as set forth therein, the authors retain all their rights. 2443 Acknowledgments 2445 We would like to thank Guy Almes, Mark Allman, Jari Arkko, Hamid 2446 Asgari, Steven Van den Berghe, Eric Boyd, Robert Cole, Joan 2447 Cucchiara, Stephen Donnelly, Susan Evett, Sam Hartman, Kaynam 2448 Hedayat, Petri Helenius, Scott Hollenbeck, Russ Housley, Kitamura 2449 Yasuichi, Daniel H. T. R. Lawson, Will E. Leland, Bruce A. Mah, 2450 Allison Mankin, Al Morton, Attila Pasztor, Randy Presuhn, Matthew 2451 Roughan, Andy Scherrer, Henk Uijterwaal, and Sam Weiler for their 2452 comments, suggestions, reviews, helpful discussion and proof-reading. 2454 Expiration date: August 2006