idnits 2.17.1 draft-ietf-ippm-owdp-14.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 3667, Section 5.1 on line 18. -- Found old boilerplate from RFC 3978, Section 5.5 on line 2276. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 2253. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 2260. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 2282), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 38. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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? ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. 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 185 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 '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 (December 2004) is 7065 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 2001 -- Looks like a reference, but probably isn't: '16' on line 1909 == Missing Reference: 'Loop' is mentioned on line 1595, but not defined == Missing Reference: 'K' is mentioned on line 1922, but not defined -- Looks like a reference, but probably isn't: '4' on line 1968 -- Looks like a reference, but probably isn't: '2' on line 1999 -- Looks like a reference, but probably isn't: '0' on line 1977 -- Looks like a reference, but probably isn't: '15' on line 2041 -- Looks like a reference, but probably isn't: '1000000' on line 2130 == Unused Reference: 'RFC2026' is defined on line 2140, but no explicit reference was found in the text == Unused Reference: 'RFC2330' is defined on line 2146, but no explicit reference was found in the text == Unused Reference: 'RFC2836' is defined on line 2159, but no explicit reference was found in the text == Unused Reference: 'RIPE-NLUUG' is defined on line 2182, but no explicit reference was found in the text == Unused Reference: 'SURVEYOR-INET' is defined on line 2189, 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 1321 ** 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 informational reference (is this intentional?): RFC 1305 (Obsoleted by RFC 5905) -- Obsolete informational reference (is this intentional?): RFC 1750 (Obsoleted by RFC 4086) -- 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: 13 errors (**), 0 flaws (~~), 12 warnings (==), 20 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: June 2005 Anatoly Karp 5 Jeff W. Boote 6 Matthew J. Zekauskas 7 Internet2 8 December 2004 10 A One-way Active Measurement Protocol (OWAMP) 11 13 Status of this Memo 15 By submitting this Internet-Draft, I certify that any applicable 16 patent or other IPR claims of which I am aware have been disclosed, 17 and any of which I become aware will be disclosed, in accordance with 18 RFC 3668. 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 2004. All Rights Reserved. 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 Zero Padding (IZP) . . . . . . . . . . . . . 11 58 3.3. Values of the Accept Field . . . . . . . . . . . . . . 11 59 3.4. OWAMP-Control Commands . . . . . . . . . . . . . . . . 12 60 3.5. Creating Test Sessions . . . . . . . . . . . . . . . . 12 61 3.6. Send Schedules . . . . . . . . . . . . . . . . . . . . 17 62 3.7. Starting Test Sessions . . . . . . . . . . . . . . . . 18 63 3.8. Stop-Sessions . . . . . . . . . . . . . . . . . . . . 19 64 3.9. Fetch-Session . . . . . . . . . . . . . . . . . . . . 22 65 4. OWAMP-Test . . . . . . . . . . . . . . . . . . . . . . . . 27 66 4.1. Sender Behavior . . . . . . . . . . . . . . . . . . . 27 67 4.1.1. Packet Timings . . . . . . . . . . . . . . . . . 27 68 4.1.2. Packet Format and Content . . . . . . . . . . . . 28 69 4.2. Receiver Behavior . . . . . . . . . . . . . . . . . . 31 70 5. Computing Exponentially Distributed Pseudo-Random Numbers . 33 71 5.1. High-Level Description of the Algorithm . . . . . . . 33 72 5.2. Data Types, Representation, and Arithmetic . . . . . . 34 73 5.3. Uniform Random Quantities . . . . . . . . . . . . . . 35 74 6. Security Considerations . . . . . . . . . . . . . . . . . . 36 75 6.1. Introduction . . . . . . . . . . . . . . . . . . . . . 36 76 6.2. Preventing Third-Party Denial of Service . . . . . . . 37 77 6.3. Covert Information Channels . . . . . . . . . . . . . 37 78 6.4. Requirement to Include AES in Implementations . . . . 37 79 6.5. Resource Use Limitations . . . . . . . . . . . . . . . 37 80 6.6. Use of Cryptographic Primitives in OWAMP . . . . . . . 38 81 6.7. Required Properties of MD5 . . . . . . . . . . . . . . 39 82 6.8. The Use of AES-CBC-MAC . . . . . . . . . . . . . . . . 41 83 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . 42 84 8. Internationalization Considerations . . . . . . . . . . . . 42 85 9. Appendix A: Sample C Code for Exponential Deviates . . . . 42 86 10. Appendix B: Test Vectors for Exponential Deviates . . . . 47 87 11. Normative References . . . . . . . . . . . . . . . . . . . 48 88 12. Informative References . . . . . . . . . . . . . . . . . . 48 89 13. Authors' Addresses . . . . . . . . . . . . . . . . . . . . 49 91 1. Introduction 93 The IETF IP Performance Metrics (IPPM) working group has proposed 94 draft standard metrics for one-way packet delay [RFC2679] and loss 95 [RFC2680] across Internet paths. Although there are now several 96 measurement platforms that implement collection of these metrics 97 [SURVEYOR] [RIPE] [BRIX], there is not currently a standard that 98 would permit initiation of test streams or exchange of packets to 99 collect singleton metrics in an interoperable manner. 101 With the increasingly wide availability of affordable global 102 positioning systems (GPS) and CDMA-based time sources, hosts 103 increasingly have available to them very accurate time 104 sources--either directly or through their proximity to Network Time 105 Protocol (NTP) primary (stratum 1) time servers. By standardizing a 106 technique for collecting IPPM one-way active measurements, we hope to 107 create an environment where IPPM metrics may be collected across a 108 far broader mesh of Internet paths than is currently possible. One 109 particularly compelling vision is of widespread deployment of open 110 OWAMP servers that would make measurement of one-way delay as 111 commonplace as measurement of round-trip time using an ICMP-based 112 tool like ping. 114 Additional design goals of OWAMP include: being hard to detect and 115 manipulate, security, logical separation of control and test 116 functionality, and support for small test packets. (Being hard to 117 detect makes interference with measurements more difficult for 118 intermediaries in the middle of the network.) 120 OWAMP test traffic is hard to detect because it is simply a stream of 121 UDP packets from and to negotiated port numbers, with potentially 122 nothing static in the packets (size is negotiated, as well). OWAMP 123 also supports an encrypted mode that further obscures the traffic, at 124 the same time making it impossible to alter timestamps undetectably. 126 Security features include optional authentication and/or encryption 127 of control and test messages. These features may be useful to 128 prevent unauthorized access to results or man-in-the-middle attackers 129 who attempt to provide special treatment to OWAMP test streams or who 130 attempt to modify sender-generated timestamps to falsify test 131 results. 133 The key words "MUST", "REQUIRED", "SHOULD", "RECOMMENDED", and "MAY" 134 in this document are to be interpreted as described in [RFC2119]. 136 1.1. Relationship of Test and Control Protocols 138 OWAMP actually consists of two inter-related protocols: OWAMP-Control 139 and OWAMP-Test. OWAMP-Control is used to initiate, start, and stop 140 test sessions and fetch their results, while OWAMP-Test is used to 141 exchange test packets between two measurement nodes. 143 Although OWAMP-Test may be used in conjunction with a control 144 protocol other than OWAMP-Control, the authors have deliberately 145 chosen to include both protocols in the same draft to encourage the 146 implementation and deployment of OWAMP-Control as a common 147 denominator control protocol for one-way active measurements. Having 148 a complete and open one-way active measurement solution that is 149 simple to implement and deploy is crucial to assuring a future in 150 which inter-domain one-way active measurement could become as 151 commonplace as ping. We neither anticipate nor recommend that 152 OWAMP-Control form the foundation of a general-purpose extensible 153 measurement and monitoring control protocol. 155 OWAMP-Control is designed to support the negotiation of one-way 156 active measurement sessions and results retrieval in a 157 straightforward manner. At session initiation, there is a negotiation 158 of sender and receiver addresses and port numbers, session start 159 time, session length, test packet size, the mean Poisson sampling 160 interval for the test stream, and some attributes of the very general 161 RFC 2330 notion of packet type, including packet size and per-hop 162 behavior (PHB) [RFC2474], which could be used to support the 163 measurement of one-way network characteristics across differentiated 164 services networks. Additionally, OWAMP-Control supports per-session 165 encryption and authentication for both test and control traffic, 166 measurement servers that can act as proxies for test stream 167 endpoints, and the exchange of a seed value for the pseudo-random 168 Poisson process that describes the test stream generated by the 169 sender. 171 We believe that OWAMP-Control can effectively support one-way active 172 measurement in a variety of environments, from publicly accessible 173 measurement beacons running on arbitrary hosts to network monitoring 174 deployments within private corporate networks. If integration with 175 Simple Network Management Protocol (SNMP) or proprietary network 176 management protocols is required, gateways may be created. 178 1.2. Logical Model 180 Several roles are logically separated to allow for broad flexibility 181 in use. Specifically, we define: 183 Session-Sender the sending endpoint of an OWAMP-Test session; 185 Session-Receiver the receiving endpoint of an OWAMP-Test session; 187 Server an end system that manages one or more OWAMP-Test 188 sessions, is capable of configuring per-session 189 state in session endpoints, and is capable of 190 returning the results of a test session; 192 Control-Client an end system that initiates requests for 193 OWAMP-Test sessions, triggers the start of a set 194 of sessions, and may trigger their termination; and 196 Fetch-Client an end system that initiates requests to fetch 197 the results of completed OWAMP-Test sessions. 199 One possible scenario of relationships between these roles is shown 200 below. 202 +----------------+ +------------------+ 203 | Session-Sender |--OWAMP-Test-->| Session-Receiver | 204 +----------------+ +------------------+ 205 ^ ^ 206 | | 207 | | 208 | | 209 | +----------------+<----------------+ 210 | | Server |<-------+ 211 | +----------------+ | 212 | ^ | 213 | | | 214 | OWAMP-Control OWAMP-Control 215 | | | 216 v v v 217 +----------------+ +-----------------+ 218 | Control-Client | | Fetch-Client | 219 +----------------+ +-----------------+ 221 (Unlabeled links in the figure are unspecified by this draft and may 222 be proprietary protocols.) 224 Different logical roles can be played by the same host. For example, 225 in the figure above, there could actually be only two hosts: one 226 playing the roles of Control-Client, Fetch-Client, and 227 Session-Sender, and the other playing the roles of Server and 228 Session-Receiver. This is shown below. 230 +-----------------+ +------------------+ 231 | Control-Client |<--OWAMP-Control-->| Server | 232 | Fetch-Client | | | 233 | Session-Sender |---OWAMP-Test----->| Session-Receiver | 234 +-----------------+ +------------------+ 236 Finally, because many Internet paths include segments that transport 237 IP over ATM, delay and loss measurements can include the effects of 238 ATM segmentation and reassembly (SAR). Consequently, OWAMP has been 239 designed to allow for small test packets that would fit inside the 240 payload of a single ATM cell (this is only achieved in 241 unauthenticated and encrypted modes). 243 2. Protocol Overview 245 As described above, OWAMP consists of two inter-related protocols: 246 OWAMP-Control and OWAMP-Test. The former is layered over TCP and is 247 used to initiate and control measurement sessions and to fetch their 248 results. The latter protocol is layered over UDP and is used to send 249 singleton measurement packets along the Internet path under test. 251 The initiator of the measurement session establishes a TCP connection 252 to a well-known port on the target point and this connection remains 253 open for the duration of the OWAMP-Test sessions. IANA will be 254 requested to allocate a well-known port number for OWAMP-Control 255 sessions. An OWAMP server SHOULD listen to this well-known port. 257 OWAMP-Control messages are transmitted only before OWAMP-Test 258 sessions are actually started and after they complete (with the 259 possible exception of an early Stop-Sessions message). 261 The OWAMP-Control and OWAMP-Test protocols support three modes of 262 operation: unauthenticated, authenticated, and encrypted. The 263 authenticated or encrypted modes require endpoints to possess a 264 shared secret. 266 All multi-octet quantities defined in this document are represented 267 as unsigned integers in network byte order unless specified 268 otherwise. 270 3. OWAMP-Control 272 Each type of OWAMP-Control message has a fixed length. The recipient 273 will know the full length of a message after examining the first 16 274 octets of it. No message is shorter than 16 octets. 276 An implementation SHOULD expunge unused state to prevent denial-of- 277 service attacks, or unbounded memory usage, on the server. For 278 example, if the full control message is not received within some 279 number of minutes after it is expected, the TCP connection associated 280 with the OWAMP-Control session SHOULD be dropped. In absence of 281 other considerations, 30 minutes seems like a reasonable upper bound. 283 3.1. Connection Setup 285 Before either a Control-Client or a Fetch-Client can issue commands 286 of a Server, it has to establish a connection to the server. 288 First, a client opens a TCP connection to the server on a well-known 289 port. The server responds with a server greeting: 291 0 1 2 3 292 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 293 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 294 | | 295 | Unused (12 octets) | 296 | | 297 |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 298 | Modes | 299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 300 | | 301 | Challenge (16 octets) | 302 | | 303 | | 304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 306 The following Mode values are meaningful: 1 for unauthenticated, 2 307 for authenticated, and 4 for encrypted. The value of the Modes field 308 sent by the server is the bit-wise OR of the mode values that it is 309 willing to support during this session. Thus, the last three bits of 310 the Modes 32-bit value are used. The first 29 bits MUST be zero. A 311 client MUST ignore the values in the first 29 bits of the Modes 312 value. (This way, the bits are available for future protocol 313 extensions. This is the only intended extension mechanism.) 315 Challenge is a random sequence of octets generated by the server; it 316 is used subsequently by the client to prove possession of a shared 317 secret in a manner prescribed below. 319 If Modes value is zero, the server does not wish to communicate with 320 the client and MAY close the connection immediately. The client 321 SHOULD close the connection if it receives a greeting with Modes 322 equal to zero. The client MAY close the connection if the client's 323 desired mode is unavailable. 325 Otherwise, the client MUST respond with the following message: 327 0 1 2 3 328 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 329 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 330 | Mode | 331 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 332 | | 333 . . 334 . Username (16 octets) . 335 . . 336 | | 337 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 338 | | 339 . . 340 . Token (32 octets) . 341 . . 342 | | 343 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 344 | | 345 . . 346 . Client-IV (16 octets) . 347 . . 348 | | 349 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 351 Here Mode is the mode that the client chooses to use during this 352 OWAMP-Control session. It will also be used for all OWAMP-Test 353 sessions started under control of this OWAMP-Control session. In 354 Mode, one or zero bits MUST be set within last three bits. The first 355 29 bits of Mode MUST be zero. A server MUST ignore the values of the 356 first 29 bits. If zero Mode bits are set by the client, the client 357 indicates that it will not continue with the session; in this case, 358 the client and the server SHOULD close the TCP connection associated 359 with the OWAMP-Control session. 361 In unauthenticated mode, Username, Token, and Client-IV are unused. 363 Otherwise, Username is a 16-octet indicator that tells the server 364 which shared secret the client wishes to use to authenticate or 365 encrypt, while Token is the concatenation of a 16-octet challenge and 366 a 16-octet Session-key, encrypted using the AES (Advanced Encryption 367 Standard) [AES] in Cipher Block Chaining (CBC). Encryption MUST be 368 performed using an Initialization Vector (IV) of zero and a key value 369 that is the shared secret associated with Username. (Both the server 370 and the client use the same mappings from user names to secret keys. 371 The server, being prepared to conduct sessions with more than one 372 client, uses user names to choose the appropriate secret key; a 373 client would typically have different secret keys for different 374 servers. The situation is analogous to that of passwords, except 375 that secret keys, rather than having the low entropy typical of 376 passwords, are suitable for use as AES keys.) 378 The shared secret MUST be generated with sufficient entropy not to 379 reduce the security of the underlying cipher. Typical methods of its 380 generation might be from a random number generator [RFC1750] or from 381 the hash of a passphrase. If the shared secret is provided as a 382 passphrase (typical for the case of interactive tools) then the MD5 383 sum [RFC1321] of the passphrase (without possible newline 384 character(s) at the end of the passphrase) MUST be used as the key 385 for encryption by the client and decryption by the server (the 386 passphrase also MUST NOT contain newlines in the middle). This 387 ensures that a passphrase used to generate a secret in one 388 implementation will generate the same secret in another 389 implementation and the implementations will, therefore, be 390 interoperable. 392 Session-key and Client-IV are generated randomly by the client. 393 Session-key MUST be generated with sufficient entropy not to reduce 394 the security of the underlying cipher [RFC1750]. Client-IV merely 395 needs to be unique (i.e., it MUST never be repeated for different 396 sessions using the same secret key; a simple way to achieve that 397 without the use of cumbersome state is to generate the Client-IV 398 strings using a cryptographically secure pseudo-random number source: 399 if this is done, the first repetition is unlikely to occur before 400 2^64 sessions with the same secret key are conducted). 402 The server MUST respond with the following message: 404 0 1 2 3 405 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 406 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 407 | | 408 | MBZ (15 octets) | 409 | | 410 | +-+-+-+-+-+-+-+-+ 411 | | Accept | 412 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 413 | | 414 | Server-IV (16 octets) | 415 | | 416 | | 417 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 418 | Uptime (Timestamp) | 419 | | 420 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 421 | IZP (8 octets) | 422 | | 423 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 425 The MBZ 15-octet part MUST be zero. The client MUST ignore its 426 value. MBZ (MUST be zero) fields here and hereafter have the same 427 semantics: the party that sends the message MUST set the field to a 428 string of zero bits; the party that interprets the message MUST 429 ignore the value. (This way the field could be used for future 430 extensions.) 432 Server-IV is generated randomly by the server. In unauthenticated 433 mode, Server-IV is unused. 435 The Accept field indicates the server's willingness to continue 436 communication. A zero value in the Accept field means that the 437 server accepts the authentication and is willing to conduct further 438 transactions. Non-zero values indicate that the server does not 439 accept the authentication or, for some other reason, is not willing 440 to conduct further transactions in this OWAMP-Control session. The 441 full list of available Accept values is described in Section 3.3, 442 ``Values of the Accept Field''. 444 If a negative (non-zero) response is sent, the server MAY and the 445 client SHOULD close the connection after this message. 447 Uptime is a timestamp representing the time when the current 448 instantiation of the server started operating. (For example, in a 449 multi-user general purpose operating system (OS), it could be the 450 time when the server process was started.) If Accept is non-zero, 451 Uptime SHOULD be set to a string of zeros. In authenticated and 452 encrypted modes, Uptime is encrypted as described in the next 453 section, unless Accept is non-zero. (Authenticated and encrypted mode 454 cannot be entered unless the control connection can be initialized.) 456 Timestamp format is described in Section 4.1.2. The same 457 instantiation of the server SHOULD report the same exact Uptime value 458 to each client in each session. 460 Integrity Zero Padding (IZP) is treated the same way as IZP in the 461 next section and beyond. 463 The previous transactions constitute connection setup. 465 3.2. Integrity Zero Padding (IZP) 467 IZP MUST be all zeros in all messages that use IZP. The recipient of 468 a message where IZP is not zero MUST reject the message, as it is an 469 indication of tampering with the content of the message by an 470 intermediary (or brokenness). If the message is part of 471 OWAMP-Control, the session MUST be terminated and results 472 invalidated. If the message is part of OWAMP-Test, it MUST be 473 silently ignored. This will ensure data integrity. In 474 unauthenticated mode, IZP is nothing more than a simple check. In 475 authenticated and encrypted modes, however, it ensures, in 476 conjunction with properties of CBC chaining mode, that everything 477 received before was not tampered with. For this reason, it is 478 important to check the IZP field as soon as possible, so that bad 479 data doesn't get propagated. 481 3.3. Values of the Accept Field 483 Accept values are used throughout the OWAMP-Control protocol to 484 communicate the server response to client requests. The full set of 485 valid Accept field values are: 487 0 OK. 489 1 Failure, reason unspecified (catch-all). 491 2 Internal error. 493 3 Some aspect of request is not supported. 495 4 Cannot perform request due to permanent resource limitations. 497 5 Cannot perform request due to temporary resource limitations. 499 All other values are reserved. The sender of the message MAY use the 500 value of 1 for all non-zero Accept values. A message sender SHOULD 501 use the correct Accept value if it is going to use other values. The 502 message receiver MUST interpret all values of Accept other than these 503 reserved values as 1. This way, other values are available for 504 future extensions. 506 3.4. OWAMP-Control Commands 508 In authenticated or encrypted mode (which are identical as far as 509 OWAMP-Control is concerned, and only differ in OWAMP-Test) all 510 further communications are encrypted with the Session-key, using CBC 511 mode. The client encrypts its stream using Client-IV. The server 512 encrypts its stream using Server-IV. 514 The following commands are available for the client: Request-Session, 515 Start-Sessions, Stop-Sessions, and Fetch-Session. The command 516 Stop-Sessions is available to both the client and the server. (The 517 server can also send other messages in response to commands it 518 receives.) 520 After the client sends the Start-Sessions command and until it both 521 sends and receives (in an unspecified order) the Stop-Sessions 522 command, it is said to be conducting active measurements. Similarly, 523 the server is said to be conducting active measurements after it 524 receives the Start-Sessions command and until it both sends and 525 receives (in an unspecified order) the Stop-Sessions command. 527 While conducting active measurements, the only command available is 528 Stop-Sessions. 530 These commands are described in detail below. 532 3.5. Creating Test Sessions 534 Individual one-way active measurement sessions are established using 535 a simple request/response protocol. An OWAMP client MAY issue zero or 536 more Request-Session messages to an OWAMP server, which MUST respond 537 to each with an Accept-Session message. An Accept-Session message 538 MAY refuse a request. 540 The format of Request-Session message is as follows: 542 0 1 2 3 543 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 544 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 545 | 1 | MBZ | IPVN | Conf-Sender | Conf-Receiver | 546 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 547 | Number of Schedule Slots | 548 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 549 | Number of Packets | 550 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 551 | Sender Port | Receiver Port | 552 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 553 | Sender Address | 554 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 555 | | 556 | Sender Address (cont.) or MBZ (12 octets) | 557 | | 558 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 559 | Receiver Address | 560 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 561 | | 562 | Receiver Address (cont.) or MBZ (12 octets) | 563 | | 564 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 565 | | 566 | SID (16 octets) | 567 | | 568 | | 569 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 570 | Padding Length | 571 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 572 | Start Time | 573 | | 574 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 575 | Timeout, (8 octets) | 576 | | 577 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 578 | Type-P Descriptor | 579 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 580 | MBZ (8 octets) | 581 | | 582 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 583 | | 584 | IZP (16 octets) | 585 | | 586 | | 587 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 589 This is immediately followed by one or more schedule slot 590 descriptions (the number of schedule slots is specified in the 591 `Number of Schedule Slots' field above): 593 0 1 2 3 594 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 595 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 596 | Slot Type | | 597 +-+-+-+-+-+-+-+-+ MBZ (15 octets) | 598 | | 599 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 600 | Slot Parameter (Timestamp) | 601 | | 602 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 604 These are immediately followed by IZP: 606 0 1 2 3 607 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 608 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 609 | | 610 | IZP (16 octets) | 611 | | 612 | | 613 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 615 All these messages comprise one logical message: the Request-Session 616 command. 618 Above, the first octet (1) indicates that this is Request-Session 619 command. 621 IPVN is the IP version numbers for Sender and Receiver. When the IP 622 version number is 4, 12 octets follow the 4-octet IPv4 address stored 623 in Sender Address and Receiver Address. These octets MUST be set to 624 zero by the client and MUST be ignored by the server. Currently 625 meaningful IPVN values are 4 and 6. 627 Conf-Sender and Conf-Receiver MUST be set to 0 or 1 by the client. 628 The server MUST interpret any non-zero value as 1. If the value is 629 1, the server is being asked to configure the corresponding agent 630 (sender or receiver). In this case, the corresponding Port value 631 SHOULD be disregarded by the server. At least one of Conf-Sender and 632 Conf-Receiver MUST be 1. (Both can be set, in which case the server 633 is being asked to perform a session between two hosts it can 634 configure.) 636 Number of Schedule Slots, as mentioned before, specifies the number 637 of slot records that go between the two blocks of IZP. It is used by 638 the sender to determine when to send test packets (see next section). 640 Number of Packets is the number of active measurement packets to be 641 sent during this OWAMP-Test session (note that either the server or 642 the client can abort the session early). 644 If Conf-Sender is not set, Sender Port is the UDP port from which 645 OWAMP-Test packets will be sent. If Conf-Receiver is not set, 646 Receiver Port is the UDP port OWAMP-Test to which packets are 647 requested to be sent. 649 The Sender Address and Receiver Address fields contain, respectively, 650 the sender and receiver addresses of the end points of the Internet 651 path over which an OWAMP test session is requested. 653 SID is the session identifier. It can be used in later sessions as 654 an argument for the Fetch-Session command. It is meaningful only if 655 Conf-Receiver is 0. This way, the SID is always generated by the 656 receiving side. See the end of the section for information on how 657 the SID is generated. 659 Padding length is the number of octets to be appended to the normal 660 OWAMP-Test packet (see more on padding in discussion of OWAMP-Test). 662 Start Time is the time when the session is to be started (but not 663 before Start-Sessions command is issued). This timestamp is in the 664 same format as OWAMP-Test timestamps. 666 Timeout (or a loss threshold) is an interval of time (expressed as a 667 timestamp). A packet belonging to the test session that is being set 668 up by the current Request-Session command will be considered lost if 669 it is not received during Timeout seconds after it is sent. 671 Type-P Descriptor covers only a subset of (very large) Type-P space. 672 If the first two bits of the Type-P Descriptor are 00, then 673 subsequent six bits specify the requested Differentiated Services 674 Codepoint (DSCP) value of sent OWAMP-Test packets, as defined in 675 RFC 2474. If the first two bits of Type-P descriptor are 01, then 676 the subsequent 16 bits specify the requested PHB Identification Code 677 (PHB ID), as defined in RFC 2836. 679 Therefore, the value of all zeros specifies the default best-effort 680 service. 682 If Conf-Sender is set, the Type-P Descriptor is to be used to 683 configure the sender to send packets according to its value. If 684 Conf-Sender is not set, the Type-P Descriptor is a declaration of how 685 the sender will be configured. 687 If Conf-Sender is set and the server does not recognize the Type-P 688 Descriptor, or it cannot or does not wish to set the corresponding 689 attributes on OWAMP-Test packets, it SHOULD reject the session 690 request. If Conf-Sender is not set, the server SHOULD accept or 691 reject the session paying no attention to the value of the Type-P 692 Descriptor. 694 To each Request-Session message, an OWAMP server MUST respond with an 695 Accept-Session message: 697 0 1 2 3 698 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 699 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 700 | Accept | MBZ | Port | 701 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| 702 | | 703 | SID (16 octets) | 704 | | 705 | | 706 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 707 | | 708 | IZP (12 octets) | 709 | | 710 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 712 In this message, zero in the Accept field means that the server is 713 willing to conduct the session. A non-zero value indicates rejection 714 of the request. The full list of available Accept values is 715 described in Section 3.3, ``Values of the Accept Field''. 717 If the server rejects a Request-Session message, it SHOULD not close 718 the TCP connection. The client MAY close it if it receives negative 719 response to the Request-Session message. 721 The meaning of Port in the response depends on the values of 722 Conf-Sender and Conf-Receiver in the query that solicited the 723 response. If both were set, the Port field is unused. If only 724 Conf-Sender was set, Port is the port from which to expect OWAMP-Test 725 packets. If only Conf-Receiver was set, Port is the port to which 726 OWAMP-Test packets are sent. 728 If only Conf-Sender was set, the SID field in the response is unused. 729 Otherwise, SID is a unique server-generated session identifier. It 730 can be used later as handle to fetch the results of a session. 732 SIDs SHOULD be constructed by concatenation of the 4-octet IPv4 IP 733 number belonging to the generating machine, an 8-octet timestamp, and 734 a 4-octet random value. To reduce the probability of collisions, if 735 the generating machine has any IPv4 addresses (with the exception of 736 loopback), one of them SHOULD be used for SID generation, even if all 737 communication is IPv6-based. If it has no IPv4 addresses at all, the 738 last four octets of an IPv6 address MAY be used instead. Note that 739 SID is always chosen by the receiver. If truly random values are not 740 available, it is important that the SID be made unpredictable, as 741 knowledge of the SID might be used for access control. 743 3.6. Send Schedules 745 The sender and the receiver both need to know the same send schedule. 746 This way, when packets are lost, the receiver knows when they were 747 supposed to be sent. It is desirable to compress common schedules 748 and still to be able to use an arbitrary one for the test sessions. 749 In many cases, the schedule will consist of repeated sequences of 750 packets: this way, the sequence performs some test, and the test is 751 repeated a number of times to gather statistics. 753 To implement this, we have a schedule with a given number of slots. 754 Each slot has a type and a parameter. Two types are supported: 755 exponentially distributed pseudo-random quantity (denoted by a code 756 of 0) and a fixed quantity (denoted by a code of 1). The parameter 757 is expressed as a timestamp and specifies a time interval. For a 758 type 0 slot (exponentially distributed pseudo-random quantity) this 759 interval is the mean value (or 1/lambda if the distribution density 760 function is expressed as lambda*exp(-lambda*x) for positive values of 761 x). For a type 1 (fixed quantity) slot, the parameter is the delay 762 itself. The sender starts with the beginning of the schedule, and 763 executes the instructions in the slots: for a slot of type 0, wait an 764 exponentially distributed time with a mean of the specified parameter 765 and then send a test packet (and proceed to the next slot); for a 766 slot of type 1, wait the specified time and send a test packet (and 767 proceed to the next slot). The schedule is circular: when there are 768 no more slots, the sender returns to the first slot. 770 The sender and the receiver need to be able to reproducibly execute 771 the entire schedule (so, if a packet is lost, the receiver can still 772 attach a send timestamp to it). Slots of type 1 are trivial to 773 reproducibly execute. To reproducibly execute slots of type 0, we 774 need to be able to generate pseudo-random exponentially distributed 775 quantities in a reproducible manner. The way this is accomplished is 776 discussed later. 778 Using this mechanism one can easily specify common testing scenarios. 779 Some examples include: 781 + Poisson stream: a single slot of type 0; 783 + Periodic stream: a single slot of type 1; 785 + Poisson stream of back-to-back packet pairs: two slots -- type 0 786 with a non-zero parameter and type 1 with a zero parameter. 788 Further, a completely arbitrary schedule can be specified (albeit 789 inefficiently) by making the number of test packets equal to the 790 number of schedule slots. In this case, the complete schedule is 791 transmitted in advance of an OWAMP-Test session. 793 3.7. Starting Test Sessions 795 Having requested one or more test sessions and received affirmative 796 Accept-Session responses, an OWAMP client MAY start the execution of 797 the requested test sessions by sending a Start-Sessions message to 798 the server. 800 The format of this message is as follows: 802 0 1 2 3 803 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 804 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 805 | 2 | | 806 +-+-+-+-+-+-+-+-+ | 807 | MBZ (15 octets) | 808 | | 809 | | 810 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 811 | | 812 | IZP (16 octets) | 813 | | 814 | | 815 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 817 The server MUST respond with an Start-Ack message (which SHOULD be 818 sent as quickly as possible). Start-Ack messages have the following 819 format: 821 0 1 2 3 822 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 823 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 824 | Accept | | 825 +-+-+-+-+-+-+-+-+ | 826 | MBZ (15 octets) | 827 | | 828 | | 829 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 830 | | 831 | IZP (16 octets) | 832 | | 833 | | 834 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 836 If Accept is non-zero, the Start-Sessions request was rejected; zero 837 means that the command was accepted. The full list of available 838 Accept values is described in Section 3.3, ``Values of the Accept 839 Field''. The server MAY, and the client SHOULD, close the connection 840 in the case of a rejection. 842 The server SHOULD start all OWAMP-Test streams immediately after it 843 sends the response or immediately after their specified start times, 844 whichever is later. If the client represents a Sender, the client 845 SHOULD start its OWAMP-Test streams immediately after it sees the 846 Start-Ack response from the Server (if the Start-Sessions command was 847 accepted) or immediately after their specified start times, whichever 848 is later. See more on OWAMP-Test sender behavior in a separate 849 section below. 851 3.8. Stop-Sessions 853 The Stop-Sessions message may be issued by either the Control-Client 854 or the Server. The format of this command is as follows: 856 0 1 2 3 857 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 858 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 859 | 3 | Accept | MBZ | 860 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 861 | Number of Sessions | 862 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 863 | MBZ (8 octets) | 864 | | 865 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 867 This is immediately followed by zero or more session description 868 records (the number of session description records is specified in 869 the ``Number of Sessions'' field above). The session description 870 record is used to indicate which packets were actually sent by the 871 sender process (rather than skipped). The header of the session 872 description record is as follows: 874 0 1 2 3 875 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 876 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| 877 | | 878 | SID (16 octets) | 879 | | 880 | | 881 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 882 | Next Seqno | 883 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 884 | Number of Skip Ranges | 885 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 887 This is immediately followed by zero or more Skip Range descriptions 888 as specified by the ``Number of Skip Ranges'' field above. Skip 889 Ranges are simply two sequence numbers that, together, indicate a 890 range of packets that were not sent: 892 0 1 2 3 893 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 894 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| 895 | First Seqno Skipped | 896 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 897 | Last Seqno Skipped | 898 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 900 Skip Ranges MUST be in order. The last (possibly full, possibly 901 incomplete) block (16 octets) of data MUST be padded with zeros, if 902 necessary. This ensures that the next session description record 903 starts on a block boundary. 905 Finally, a single block (16 octets) of IZP is concatenated on the end 906 to complete the Stop-Sessions message. 908 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 909 | | 910 | IZP (16 octets) | 911 | | 912 | | 913 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 915 All these records comprise one logical message: the Stop-Sessions 916 command. 918 Above, the first octet (3) indicates that this is the Stop-Sessions 919 command. 921 Non-zero Accept values indicate a failure of some sort. Zero values 922 indicate normal (but possibly premature) completion. The full list 923 of available Accept values is described in Section 3.3, ``Values of 924 the Accept Field''. 926 If Accept had a non-zero value (from either party), results of all 927 OWAMP-Test sessions spawned by this OWAMP-Control session SHOULD be 928 considered invalid, even if a Fetch-Session with SID from this 929 session works for a different OWAMP-Control session. If Accept was 930 not transmitted at all (for whatever reason, including the TCP 931 connection used for OWAMP-Control breaking), the results of all 932 OWAMP-Test sessions spawned by this OWAMP-control session MAY be 933 considered invalid. 935 Number of Sessions indicates the number of session description 936 records that immediately follow the Stop-Sessions header. 938 Number of Sessions MUST contain the number of send sessions started 939 by the local side of the control connection that have not been 940 previously terminated by a Stop-Sessions command (i.e., the 941 Control-Client MUST account for each accepted Request-Session where 942 Conf-Receiver was set; the Control-Server MUST account for each 943 accepted Request-Session where Conf-Sender was set). If the 944 Stop-Sessions message does not account for exactly the send sessions 945 controlled by that side, then it is to be considered invalid and the 946 connection SHOULD be closed and any results obtained considered 947 invalid. 949 Each session description record represents one OWAMP-Test session. 951 SID is the session identifier (SID) used to indicate which send 952 session is being described. 954 Next Seqno indicates the next sequence number that would have been 955 sent from this send session. For completed sessions, this will equal 956 NumPackets from the Request-Session. 958 Number of Skip Ranges indicates the number of holes that actually 959 occurred in the sending process. This is a range of packets that were 960 never actually sent by the sending process. For example, if a send 961 session is started too late for the first 10 packets to be sent and 962 this is the only hole in the schedule, then ``Number of Skip Ranges'' 963 would be 1. The single Skip Range description will have First Seqno 964 Skipped equal to 0 and Last Seqno Skipped equal to 9. This is 965 described further in the ``Sender Behavior'' section. 967 If the OWAMP-Control connection breaks when the Stop-Sessions command 968 is sent, the receiver MAY not completely invalidate the session 969 results. It MUST discard all record of packets that follow (in other 970 words, have greater sequence number than) the last packet that was 971 actually received before before any lost packet records. This will 972 help differentiate between packet losses that occurred in the network 973 and packets the sending process may have never sent. 975 If a receiver of an OWAMP-Test session learns, through an OWAMP- 976 Control Stop-Sessions message, that the OWAMP-Test sender's last 977 sequence number is lower than any sequence number actually received, 978 the results of the complete OWAMP-Test session MUST be invalidated. 980 A receiver of an OWAMP-Test session, upon receipt of an OWAMP-Control 981 Stop-Sessions command, MUST discard any packet records -- including 982 lost packet records -- with a (computed) send time that falls between 983 the current time minus Timeout and the current time. This ensures 984 statistical consistency for the measurement of loss and duplicates in 985 the event that the Timeout is greater than the time it takes for the 986 Stop-Sessions command to take place. 988 To effect complete sessions, each side of the control connection 989 SHOULD wait until all sessions are complete before sending the 990 Stop-Sessions message. The completed time of each sessions is 991 determined as Timeout after the scheduled time for the last sequence 992 number. Endpoints MAY add a small increment to the computed 993 completed time for send endpoints to ensure the Stop-Sessions message 994 reaches the receiver endpoint after Timeout. 996 To effect a premature stop of sessions, the party that initiates this 997 command MUST stop its OWAMP-Test send streams to send the Session 998 Packets Sent values before sending this command. That party SHOULD 999 wait until receiving the response Stop-Sessions message before 1000 stopping the receiver streams so that it can use the values from the 1001 received Stop-Sessions message to validate the data. 1003 3.9. Fetch-Session 1005 The format of this client command is as follows: 1007 0 1 2 3 1008 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 1009 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1010 | 4 | | 1011 +-+-+-+-+-+-+-+-+ | 1012 | MBZ (7 octets) | 1013 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1014 | Begin Seq | 1015 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1016 | End Seq | 1017 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1018 | | 1019 | SID (16 octets) | 1020 | | 1021 | | 1022 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1023 | | 1024 | IZP (16 octets) | 1025 | | 1026 | | 1027 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1029 Begin Seq is the sequence number of the first requested packet. End 1030 Seq is the sequence number of the last requested packet. If Begin 1031 Seq is all zeros and End Seq is all ones, complete session is said to 1032 be requested. 1034 If a complete session is requested and the session is still in 1035 progress, or has terminated in any way other than normal, the request 1036 to fetch session results MUST be denied. If an incomplete session is 1037 requested, all packets received so far that fall into the requested 1038 range SHOULD be returned. Note that, since no commands can be issued 1039 between Start-Sessions and Stop-Sessions, incomplete requests can 1040 only happen on a different OWAMP-Control connection (from the same or 1041 different host as Control-Client). 1043 The server MUST respond with a Fetch-Ack message. The format of this 1044 server response is as follows: 1046 0 1 2 3 1047 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 1048 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1049 | Accept | Finished | MBZ (2 octets) | 1050 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1051 | Next Seqno | 1052 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1053 | Number of Skip Ranges | 1054 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1055 | Number of Records | 1056 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1057 | | 1058 | IZP (16 octets) | 1059 | | 1060 | | 1061 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1063 Again, non-zero in the Accept field means a rejection of command. 1064 The server MUST specify zero for all remaining fields if Accept is 1065 non-zero. The client MUST ignore all remaining fields (except for the 1066 IZP) if Accept is non-zero. The full list of available Accept values 1067 is described in Section 3.3, ``Values of the Accept Field''. 1069 Finished is non-zero if the OWAMP-Test session has terminated. 1071 Next Seqno indicates the next sequence number that would have been 1072 sent from this send session. For completed sessions, this will equal 1073 NumPackets from the Request-Session. This information is only 1074 available if the session has terminated. If Finished is zero, then 1075 Next Seqno MUST be set to zero by the server. 1077 Number of Skip Ranges indicates the number of holes that actually 1078 occurred in the sending process. This information is only available 1079 if the session has terminated. If Finished is zero, then Skip Ranges 1080 MUST be set to zero by the server. 1082 Number of Records is the number of packet records that fall within 1083 the requested range. This number might be less than the Number of 1084 Packets in the reproduction of the Request-Session command because of 1085 a session that ended prematurely or it might be greater because of 1086 duplicates. 1088 If Accept was non-zero, this concludes the response to the Fetch- 1089 Session message. If Accept was 0, the server then MUST immediately 1090 send the OWAMP-Test session data in question. 1092 The OWAMP-Test session data consists of the following (concatenated): 1094 + A reproduction of the Request-Session command that was used to 1095 start the session; it is modified so that actual sender and 1096 receiver port numbers that were used by the OWAMP-Test session 1097 always appear in the reproduction. 1099 + Zero or more (as specified) Skip Range descriptions. The last 1100 (possibly full, possibly incomplete) block (16 octets) of Skip 1101 Range descriptions is padded with zeros if necessary. (These 1102 zeros are simple padding and should be distinguished from the 16 1103 octets of IZP that follow.) 1105 + 16 octets of IZP. 1107 + Zero or more (as specified) packet records. The last (possibly 1108 full, possibly incomplete) block (16 octets) of data is padded 1109 with zeros if necessary. (These zeros are simple padding and 1110 should be distinguished from the 16 octets of IZP that follow.) 1112 + 16 octets of IZP. 1114 Skip Range descriptions are simply two sequence numbers that, 1115 together, indicate a range of packets that were not sent: 1117 0 1 2 3 1118 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 1119 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| 1120 | First Seqno Skipped | 1121 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1122 | Last Seqno Skipped | 1123 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1125 Skip Range descriptions should be sent out in order, as sorted by 1126 First Seqno. If any Skip Ranges overlap, or are out of order, the 1127 session data is to be considered invalid and the connection SHOULD be 1128 closed and any results obtained considered invalid. 1130 Each packet record is 25 octets, and includes 4 octets of sequence 1131 number, 8 octets of send timestamp, 2 octets of send timestamp error 1132 estimate, 8 octets of receive timestamp, 2 octets of receive 1133 timestamp error estimate, and 1 octet of Time To Live (TTL), or Hop 1134 Limit in IPv6: 1136 0 1 2 3 1137 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 1138 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1139 00| Seq Number | 1140 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1141 04| Send Error Estimate | Receive Error Estimate | 1142 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1143 08| Send Timestamp | 1144 12| | 1145 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1146 16| Receive Timestamp | 1147 20| | 1148 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1149 24| TTL | 1150 +-+-+-+-+-+-+-+-+ 1152 Packet records are sent out in the same order the actual packets were 1153 received. Therefore, the data is in arrival order. 1155 Note that lost packets (if any losses were detected during the 1156 OWAMP-Test session) MUST appear in the sequence of packets. They can 1157 appear either at the point when the loss was detected or at any later 1158 point. Lost packet records are distinguished as follows: 1160 + A send timestamp filled with the presumed send time (as computed 1161 by the send schedule). 1163 + A send error estimate filled with Multiplier=1, Scale=64, and S=0 1164 (see the OWAMP-Test description for definition of these quantities 1165 and explanation of timestamp format and error estimate format). 1167 + A normal receive error estimate as determined by the error of the 1168 clock being used to declare the packet lost. (It is declared lost 1169 if it is not received by the Timeout after the presumed send time, 1170 as determined by the receiver's clock.) 1172 + A receive timestamp consisting of all zero bits. 1174 + A TTL value of 255. 1176 4. OWAMP-Test 1178 This section describes OWAMP-Test protocol. It runs over UDP using 1179 sender and receiver IP and port numbers negotiated during the 1180 Request-Session exchange. 1182 As with OWAMP-Control, OWAMP-Test has three modes: unauthenticated, 1183 authenticated, and encrypted. All OWAMP-Test sessions that are 1184 spawned by an OWAMP-Control session inherit its mode. 1186 OWAMP-Control client, OWAMP-Control server, OWAMP-Test sender, and 1187 OWAMP-Test receiver can potentially all be different machines. (In a 1188 typical case, we expect that there will be only two machines.) 1190 4.1. Sender Behavior 1192 4.1.1. Packet Timings 1194 Send schedules based on slots, described previously, in conjunction 1195 with scheduled session start time, enable the sender and the receiver 1196 to compute the same exact packet sending schedule independently of 1197 each other. These sending schedules are independent for different 1198 OWAMP-Test sessions, even if they are governed by the same 1199 OWAMP-Control session. 1201 Consider any OWAMP-Test session. Once Start-Sessions exchange is 1202 complete, the sender is ready to start sending packets. Under normal 1203 OWAMP use circumstances, the time to send the first packet is in the 1204 near future (perhaps a fraction of a second away). The sender SHOULD 1205 send packets as close as possible to their scheduled time, with the 1206 following exception: if the scheduled time to send is in the past, 1207 and separated from the present by more than Timeout time, the sender 1208 MUST NOT send the packet. (Indeed, such a packet would be considered 1209 lost by the receiver anyway.) The sender MUST keep track of which 1210 packets it does not send. It will use this to tell the receiver what 1211 packets were not sent by setting Skip Ranges in the Stop-Sessions 1212 message from the sender to the receiver upon completion of the test. 1213 The Skip Ranges are also sent to a Fetch-Client as part of the 1214 session data results. These holes in the sending schedule can happen 1215 if a time in the past was specified in the Request-Session command, 1216 or if the Start-Sessions exchange took unexpectedly long, or if the 1217 sender could not start serving the OWAMP-Test session on time due to 1218 internal scheduling problems of the OS. Packets in the past, but 1219 separated from the present by less than Timeout value, SHOULD be sent 1220 as quickly as possible. With normal test rates and timeout values, 1221 the number of packets in such a burst is limited. Nevertheless, 1222 hosts SHOULD NOT intentionally schedule sessions so that such bursts 1223 of packets occur. 1225 Regardless of any scheduling delays, each packet that is actually 1226 sent MUST have the best possible approximation of its real time of 1227 departure as its timestamp (in the packet). 1229 4.1.2. Packet Format and Content 1231 The sender sends the receiver a stream of packets with the schedule 1232 specified in the Request-Session command. The sender SHOULD set the 1233 TTL in IPv4 (or Hop Limit in IPv6) in the UDP packet to 255. The 1234 format of the body of a UDP packet in the stream depends on the mode 1235 being used. 1237 For unauthenticated mode: 1239 0 1 2 3 1240 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 1241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1242 | Sequence Number | 1243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1244 | Timestamp | 1245 | | 1246 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1247 | Error Estimate | | 1248 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1249 | | 1250 . . 1251 . Packet Padding . 1252 . . 1253 | | 1254 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1256 For authenticated and encrypted modes: 1258 0 1 2 3 1259 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 1260 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1261 | Sequence Number | 1262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1263 | | 1264 | IZP (12 octets) | 1265 | | 1266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1267 | Timestamp | 1268 | | 1269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1270 | Error Estimate | | 1271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1272 | IZP (6 octets) | 1273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1274 | | 1275 . . 1276 . Packet Padding . 1277 . . 1278 | | 1279 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1281 The format of the timestamp is the same as in [RFC1305] and is as 1282 follows: first 32 bits represent the unsigned integer number of 1283 seconds elapsed since 0h on 1 January 1900; next 32 bits represent 1284 the fractional part of a second that has elapsed since then. 1286 So, Timestamp is represented as follows: 1287 0 1 2 3 1288 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 1289 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1290 | Integer part of seconds | 1291 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1292 | Fractional part of seconds | 1293 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1295 The Error Estimate specifies the estimate of the error and 1296 synchronization. It has the following format: 1298 0 1 1299 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 1300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1301 |S|Z| Scale | Multiplier | 1302 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1304 The first bit S SHOULD be set if the party generating the timestamp 1305 has a clock that is synchronized to UTC using an external source 1306 (e.g., the bit should be set if GPS hardware is used and it indicates 1307 that it has acquired current position and time or if NTP is used and 1308 it indicates that it has synchronized to an external source, which 1309 includes stratum 0 source, etc.); if there is no notion of external 1310 synchronization for the time source, the bit SHOULD NOT be set. The 1311 next bit has the same semantics as MBZ fields elsewhere: it MUST be 1312 set to zero by the sender and ignored by everyone else. The next six 1313 bits, Scale, form an unsigned integer; Multiplier is an unsigned 1314 integer as well. They are interpreted as follows: the error estimate 1315 is equal to Multiplier*2^(-32)*2^Scale (in seconds). [Notation 1316 clarification: 2^Scale is two to the power of Scale.] Multiplier 1317 MUST NOT be set to zero. If Multiplier is zero, the packet SHOULD be 1318 considered corrupt and discarded. 1320 Sequence numbers start with zero and are incremented by one for each 1321 subsequent packet. 1323 The minimum data segment length is, therefore, 14 octets in 1324 unauthenticated mode, and 32 octets in both authenticated mode and 1325 encrypted modes. 1327 The OWAMP-Test packet layout is the same in authenticated and 1328 encrypted modes. The encryption operations are, however, different. 1329 The difference is that in encrypted mode both the sequence number and 1330 the timestamp are encrypted to provide maximum data integrity 1331 protection while in authenticated mode the sequence number is 1332 encrypted and the timestamp is sent in clear text. Sending the 1333 timestamp in clear text in authenticated mode allows one to reduce 1334 the time between when a timestamp is obtained by a sender and when 1335 the packet is shipped out. In encrypted mode, the sender has to 1336 fetch the timestamp, encrypt it, and send it; in authenticated mode, 1337 the middle step is removed, potentially improving accuracy (the 1338 sequence number can be encrypted before the timestamp is fetched). 1340 In authenticated mode, the first block (16 octets) of each packet is 1341 encrypted using AES Electronic Cookbook (ECB) mode. 1343 The key to use is obtained as follows: the 16-octet session 1344 identifier (SID) is encrypted with the same session key as is used 1345 for the corresponding OWAMP-Control session (where it is used in a 1346 different chaining mode); this is a single-block ECB encryption; its 1347 result is the key to use in encrypting (and decrypting) the packets 1348 of the particular OWAMP-Test session. 1350 ECB mode used for encrypting the first block of OWAMP-Test packets in 1351 authenticated mode does not involve any actual chaining; this way, 1352 lost, duplicated, or reordered packets do not cause problems with 1353 deciphering any packet in an OWAMP-Test session. 1355 In encrypted mode, the first two blocks (32 octets) are encrypted 1356 using AES CBC mode. The key to use is obtained in the same way as 1357 the key for authenticated mode. Each OWAMP-Test packet is encrypted 1358 as a separate stream, with just one chaining operation; chaining does 1359 not span multiple packets so that lost, duplicated, or reordered 1360 packets do not cause problems. The initialization vector for the CBC 1361 encryption is a string of zeros. 1363 Implementation note: Naturally, the key schedule for each OWAMP-Test 1364 session need only be set up once per session, not once per packet. 1366 In unauthenticated mode, no encryption is applied. 1368 Packet Padding in OWAMP-Test SHOULD be pseudo-random (it MUST be 1369 generated independently of any other pseudo-random numbers mentioned 1370 in this document). However, implementations MUST provide a 1371 configuration parameter, an option, or a different means of making 1372 Packet Padding consist of all zeros. 1374 The time elapsed between packets is computed according to the slot 1375 schedule as mentioned in Request-Session command description. At 1376 that point, we skipped over the issue of computing exponentially 1377 distributed pseudo-random numbers in a reproducible fashion. It is 1378 discussed later in a separate section. 1380 4.2. Receiver Behavior 1382 The receiver knows when the sender will send packets. The following 1383 parameter is defined: Timeout (from Request-Session). Packets that 1384 are delayed by more than Timeout are considered lost (or `as good as 1385 lost'). Note that there is never an actual assurance of loss by the 1386 network: a `lost' packet might still be delivered at any time. The 1387 original specification for IPv4 required that packets be delivered 1388 within TTL seconds or never (with TTL having a maximum value of 255). 1389 To the best of the authors' knowledge, this requirement was never 1390 actually implemented (and, of course, only a complete and universal 1391 implementation would ensure that packets do not travel for longer 1392 than TTL seconds). In fact, in IPv6, the name of this field has 1393 actually been changed to Hop Limit. Further, IPv4 specification 1394 makes no claims about the time it takes the packet to traverse the 1395 last link of the path. 1397 The choice of a reasonable value of Timeout is a problem faced by a 1398 user of OWAMP protocol, not by an implementor. A value such as two 1399 minutes is very safe. Note that certain applications (such as 1400 interactive `one-way ping') might wish to obtain the data faster than 1401 that. 1403 As packets are received, 1405 + Timestamp the received packet. 1407 + In authenticated or encrypted mode, decrypt the first block (16 1408 octets) of the packet body. 1410 + Store the packet sequence number, send time, receive time, and the 1411 TTL for IPv4 (or Hop Limit for IPv6) from the packet IP header for 1412 the results to be transferred. 1414 + Packets not received within the Timeout are considered lost. They 1415 are recorded with their true sequence number, presumed send time, 1416 receive time consisting of a string of zero bits, and TTL (or Hop 1417 Limit) of 255. 1419 Implementations SHOULD fetch the TTL/Hop Limit value from the IP 1420 header of the packet. If an implementation does not fetch the actual 1421 TTL value (the only good reason to not do so is inability to access 1422 the TTL field of arriving packets), it MUST record the TTL value as 1423 255. 1425 Packets that are actually received are recorded in the order of 1426 arrival. Lost packet records serve as indications of the send times 1427 of lost packets. They SHOULD be placed either at the point where the 1428 receiver learns about the loss or at any later point; in particular, 1429 one MAY place all the records that correspond to lost packets at the 1430 very end. 1432 Packets that have send time in the future MUST be recorded normally, 1433 without changing their send timestamp, unless they have to be 1434 discarded. (Send timestamps in the future would normally indicate 1435 clocks that differ by more than the delay. Some data -- such as 1436 jitter -- can be extracted even without knowledge of time difference. 1437 For other kinds of data, the adjustment is best handled by the data 1438 consumer on the basis of the complete information in a measurement 1439 session, as well as, possibly, external data.) 1441 Packets with a sequence number that was already observed (duplicate 1442 packets) MUST be recorded normally. (Duplicate packets are sometimes 1443 introduced by IP networks. The protocol has to be able to measure 1444 duplication.) 1446 If any of the following is true, the packet MUST be discarded: 1448 + Send timestamp is more than Timeout in the past or in the future. 1450 + Send timestamp differs by more than Timeout from the time when the 1451 packet should have been sent according to its sequence number. 1453 + In authenticated or encrypted mode, any of the bits of zero 1454 padding inside the first 16 octets of packet body is non-zero. 1456 5. Computing Exponentially Distributed Pseudo-Random Numbers 1458 Here we describe the way exponential random quantities used in the 1459 protocol are generated. While there is a fair number of algorithms 1460 for generating exponential random variables, most of them rely on 1461 having logarithmic function as a primitive, resulting in potentially 1462 different values, depending on the particular implementation of the 1463 math library. We use algorithm 3.4.1.S in [KNUTH], which is free 1464 of the above-mentioned problem, and guarantees the same output on any 1465 implementation. The algorithm belongs to the ziggurat family 1466 developed in the 1970s by G. Marsaglia, M. Sibuya and J. H. Ahrens 1467 [ZIGG]. It replaces the use of logarithmic function by clever bit 1468 manipulation, still producing the exponential variates on output. 1470 5.1. High-Level Description of the Algorithm 1472 For ease of exposition, the algorithm is first described with all 1473 arithmetic operations being interpreted in their natural sense. 1474 Later, exact details on data types, arithmetic, and generation of the 1475 uniform random variates used by the algorithm are given. It is an 1476 almost verbatim quotation from [KNUTH], p.133. 1478 Algorithm S: Given a real positive number 'mu', produce an 1479 exponential random variate with mean 'mu'. 1481 First, the constants 1483 Q[k] = (ln2)/(1!) + (ln2)^2/(2!) + ... + (ln2)^k/(k!), 1 <= k <= 11 1485 are computed in advance. The exact values which MUST be used by all 1486 implementations are given in the next section. This is necessary to 1487 insure that exactly the same pseudo-random sequences are produced by 1488 all implementations. 1490 S1. [Get U and shift.] Generate a 32-bit uniform random binary 1491 fraction 1493 U = (.b0 b1 b2 ... b31) [note the binary point] 1495 Locate the first zero bit b_j, and shift off the leading (j+1) bits, 1496 setting U <- (.b_{j+1} ... b31) 1498 Note: In the rare case that the zero has not been found, it is 1499 prescribed that the algorithm return (mu*32*ln2). 1501 S2. [Immediate acceptance?] If U < ln2, set X <- mu*(j*ln2 + U) and 1502 terminate the algorithm. (Note that Q[1] = ln2.) 1504 S3. [Minimize.] Find the least k >= 2 such that U < Q[k]. Generate k 1505 new uniform random binary fractions U1,...,Uk and set V <- 1506 min(U1,...,Uk). 1508 S4. [Deliver the answer.] Set X <- mu*(j + V)*ln2. 1510 5.2. Data Types, Representation, and Arithmetic 1512 The high-level algorithm operates on real numbers -- typically 1513 represented as floating point numbers. This specification prescribes 1514 that unsigned 64-bit integers be used instead. 1516 u_int64_t integers are interpreted as real numbers by placing the 1517 decimal point after the first 32 bits. In other words, conceptually, 1518 the interpretation is given by the map: 1520 u_int64_t u; 1522 u |--> (double)u / (2**32) 1524 The algorithm produces a sequence of such u_int64_t integers that, 1525 for any given value of SID, is guaranteed to be the same on any 1526 implementation. 1528 We specify that the u_int64_t representations of the first 11 values 1529 of the Q array in the high-level algorithm MUST be as follows: 1531 #1 0xB17217F8, 1532 #2 0xEEF193F7, 1533 #3 0xFD271862, 1534 #4 0xFF9D6DD0, 1535 #5 0xFFF4CFD0, 1536 #6 0xFFFEE819, 1537 #7 0xFFFFE7FF, 1538 #8 0xFFFFFE2B, 1539 #9 0xFFFFFFE0, 1540 #10 0xFFFFFFFE, 1541 #11 0xFFFFFFFF 1543 For example, Q[1] = ln2 is indeed approximated by 0xB17217F8/(2**32) 1544 = 0.693147180601954; for j > 11, Q[j] is 0xFFFFFFFF. 1546 Small integer j in the high-level algorithm is represented as 1547 u_int64_t value j * (2**32). 1549 Operation of addition is done as usual on u_int64_t numbers; however, 1550 the operation of multiplication in the high-level algorithm should be 1551 replaced by 1553 (u, v) |---> (u * v) >> 32. 1555 Implementations MUST compute the product (u * v) exactly. For 1556 example, a fragment of unsigned 128-bit arithmetic can be implemented 1557 for this purpose (see sample implementation below). 1559 5.3. Uniform Random Quantities 1561 The procedure for obtaining a sequence of 32-bit random numbers (such 1562 as U in algorithm S) relies on using AES encryption in counter mode. 1563 To describe the exact working of the algorithm, we introduce two 1564 primitives from Rijndael. Their prototypes and specification are 1565 given below, and they are assumed to be provided by the supporting 1566 Rijndael implementation, such as [RIJN]. 1568 + A function that initializes a Rijndael key with bytes from seed 1569 (the SID will be used as the seed): 1571 void KeyInit(unsigned char seed[16]); 1573 + A function that encrypts the 16-octet block inblock with the 1574 specified key, returning a 16-octet encrypted block. Here 1575 keyInstance is an opaque type used to represent Rijndael keys: 1577 void BlockEncrypt(keyInstance key, unsigned char inblock[16]); 1579 Algorithm Unif: given a 16-octet quantity seed, produce a sequence of 1580 unsigned 32-bit pseudo-random uniformly distributed integers. In 1581 OWAMP, the SID (session ID) from Control protocol plays the role of 1582 seed. 1584 U1. [Initialize Rijndael key] key <- KeyInit(seed) [Initialize an 1585 unsigned 16-octet (network byte order) counter] c <- 0 U2. [Need 1586 more random bytes?] Set i <- c mod 4. If (i == 0) set s <- 1587 BlockEncrypt(key, c) 1589 U3. [Increment the counter as unsigned 16-octet quantity] c <- c + 1 1591 U4. [Do output] Output the i_th quartet of octets from s starting 1592 from high-order octets, converted to native byte order and 1593 represented as OWPNum64 value (as in 3.b). 1595 U5. [Loop] Go to step U2. 1597 6. Security Considerations 1599 6.1. Introduction 1601 The goal of authenticated mode to let one passphrase-protect the 1602 service provided by a particular OWAMP-Control server. One can 1603 imagine a variety of circumstances where this could be useful. 1604 Authenticated mode is designed to prohibit theft of service. 1606 An additional design objective of the authenticated mode was to make 1607 it impossible for an attacker who cannot read traffic between OWAMP- 1608 Test sender and receiver to tamper with test results in a fashion 1609 that affects the measurements, but not other traffic. 1611 The goal of encrypted mode is quite different: to make it hard for a 1612 party in the middle of the network to make results look `better' than 1613 they should be. This is especially true if one of client and server 1614 does not coincide with either sender or receiver. 1616 Encryption of OWAMP-Control using AES CBC mode with blocks of zeros 1617 after each message aims to achieve two goals: (i) to provide secrecy 1618 of exchange; (ii) to provide authentication of each message. 1620 6.2. Preventing Third-Party Denial of Service 1622 OWAMP-Test sessions directed at an unsuspecting party could be used 1623 for denial of service (DoS) attacks. In unauthenticated mode, 1624 servers SHOULD limit receivers to hosts they control or to the OWAMP- 1625 Control client. 1627 6.3. Covert Information Channels 1629 OWAMP-Test sessions could be used as covert channels of information. 1630 Environments that are worried about covert channels should take this 1631 into consideration. 1633 6.4. Requirement to Include AES in Implementations 1635 Notice that AES, in counter mode, is used for pseudo-random number 1636 generation, so implementation of AES MUST be included, even in a 1637 server that only supports unauthenticated mode. 1639 6.5. Resource Use Limitations 1641 An OWAMP server can consume resources of various kinds. The two most 1642 important kinds of resources are network capacity and memory (primary 1643 or secondary) for storing test results. 1645 Any implementation of OWAMP server MUST include technical mechanisms 1646 to limit the use of network capacity and memory. Mechanisms for 1647 managing the resources consumed by unauthenticated users and users 1648 authenticated with a username and passphrase SHOULD be separate. The 1649 default configuration of an implementation MUST enable these 1650 mechanisms and set the resource use limits to conservatively low 1651 values. 1653 One way to design the resource limitation mechanisms is as follows: 1654 assign each session to a user class. User classes are partially 1655 ordered with ``includes'' relation, with one class (``all users'') 1656 that is always present and that includes any other class. The 1657 assignment of a session to a user class can be based on the presence 1658 of authentication of the session, the user name, IP address range, 1659 time of day, and, perhaps, other factors. Each user class would have 1660 a limit for usage of network capacity (specified in units of 1661 bit/second) and memory for storing test results (specified in units 1662 of octets). Along with the limits for resource use, current use 1663 would be tracked by the server. When a session is requested by a 1664 user in a specific user class, the resources needed for this session 1665 are computed: the average network capacity use (based on the sending 1666 schedule) and the maximum memory use (based on the number of packets 1667 and number of octets each packet would need to be stored internally 1668 -- note that outgoing sessions would not require any memory use). 1669 These resource use numbers are added to the current resource use 1670 numbers for the given user class; if such addition would take the 1671 resource use outside of the limits for the given user class, the 1672 session is rejected. When resources are reclaimed, corresponding 1673 measures are subtracted from the current use. Network capacity is 1674 reclaimed as soon as the session ends. Memory is reclaimed when the 1675 data is deleted. For unauthenticated sessions, memory consumed by an 1676 OWAMP-Test session SHOULD be reclaimed after the OWAMP-Control 1677 connection that initiated the session is closed (gracefully or 1678 otherwise). For authenticated sessions, the administrator who 1679 configures the service should be able to decide the exact policy, but 1680 useful policy mechanisms that MAY be implemented are the ability to 1681 automatically reclaim memory when the data is retrieved and the 1682 ability to reclaim memory after a certain configurable (based on user 1683 class) period of time passes after the OWAMP-Test session terminates. 1685 6.6. Use of Cryptographic Primitives in OWAMP 1687 At an early stage in designing the protocol, we considered using 1688 Transport Layer Security (TLS) [RFC2246, RFC3546] and IPsec [RFC2401] 1689 as cryptographic security mechanisms for OWAMP. The disadvantages of 1690 those are as follows (not an exhaustive list): 1692 Regarding TLS: 1694 + While TLS could be used to secure TCP-based OWAMP-Control, but 1695 difficult to use to secure UDP-based OWAMP-Test: OWAMP-Test 1696 packets, if lost, are not resent, so packets have to be 1697 (optionally) encrypted and authenticated while retaining 1698 individual usability. Stream-based TLS is not conducive of this. 1700 + Dealing with streams, does not authenticate individual messages 1701 (even in OWAMP-Control). The easiest way out would be to add some 1702 known-format padding to each message and verify that the format of 1703 the padding is intact before using the message. The solution 1704 would thus lose some of its appeal (``just use TLS''); it would 1705 also be much more difficult to evaluate the security of this 1706 scheme with the various modes and options of TLS -- it would 1707 almost certainly not be secure with all. The capacity of an 1708 attacker to replace parts of messages (namely, the end) with 1709 random garbage could have serious security implications and would 1710 need to be analyzed carefully: suppose, for example, that a 1711 parameter that is used in some form to control the rate were 1712 replaced by random garbage -- chances are the result (an unsigned 1713 integer) would be quite large. 1715 + Dependent on the mode of use, one can end up with a requirement 1716 for certificates for all users and a PKI. Even if one is to 1717 accept that PKI is desirable, there just isn't a usable one today. 1719 + TLS requires a fairly large implementation. OpenSSL, for example, 1720 is larger than our implementation of OWAMP as a whole. This can 1721 matter for embedded implementations. 1723 Regarding IPsec: 1725 + What we now call authenticated mode would not be possible (in 1726 IPsec you can't authenticate part of a packet). 1728 + The deployment paths of IPsec and OWAMP could be separate if OWAMP 1729 does not depend on IPsec. After nine years of IPsec, only 0.05% 1730 of traffic on an advanced backbone network such as Abilene uses 1731 IPsec (for comparison purposes with encryption above layer 4, SSH 1732 use is at 2-4% and HTTPS use is at 0.2-0.6%). It is desirable to 1733 be able to deploy OWAMP on as large of a number of different 1734 platforms as possible. 1736 + The deployment problems of a protocol dependent on IPsec would be 1737 especially acute in the case of lightweight embedded devices. 1738 Ethernet switches, DSL ``modems,'' and other such devices mostly 1739 do not support IPsec. 1741 + The API for manipulating IPsec from an application is currently 1742 poorly understood. Writing a program that needs to encrypt some 1743 packets, authenticate some packets, and leave some open -- for the 1744 same destination -- would become more of an exercise in IPsec 1745 rather than in IP measurement. 1747 For the enumerated reasons, we decided to use a simple cryptographic 1748 protocol (based on a block cipher in CBC mode) that is different from 1749 TLS and IPsec. 1751 6.7. Required Properties of MD5 1753 The protocol makes use of the MD5 hash function to convert a 1754 user-supplied passphrase into a key that will be used to encrypt a 1755 short piece of random data (the session key). 1757 In this document we use cryptographic terminology of [MENEZES]. 1759 It has long been suspected, and has been conclusively shown recently 1760 that MD5 is not a collision-resistant hash function. Since collision 1761 resistance was one of design goals of MD5, this casts strong 1762 suspicion on the other design goals of MD5, namely preimage 1763 resistance and 2nd preimage resistance. 1765 OWAMP does not rely on any of these properties. 1767 The properties of MD5 that are necessary are as follows: (1) it is a 1768 function that maps arbitrary length inputs into 128-bit outputs 1769 [fixed-length hash function], (2) a change in any bit of the input 1770 usually results in a change of a few bits of output [weakened 1771 avalanche property], (3) many 128-bit strings have preimages [almost 1772 surjective], and (4) the visible special structure of 1773 natural-language text possibly present in the passphrase is concealed 1774 after application of the function. These are very weak requirements 1775 that many functions satisfy. Something resembling CRC-128 would work 1776 just as well. 1778 We chose MD5 here because it has the required properties and is 1779 widely implemented, understood, and documented. Alternatives would 1780 include (1) a non-cryptographic primitive, such as CRC-128, (2) SHA-1 1781 truncated to 128 bits, or (3) a hash function based on AES (using 1782 Matyas-Meyer-Oseas, Davies-Meyer, or Miyaguchi-Preneel constructions; 1783 we would probably gravitate towards the last one if a block-cipher- 1784 based cryptographically secure hash function were required). Note 1785 that option 1 would not have any cryptographically relevant 1786 properties. We chose not to use it because of lack of 1787 well-documented 128-bit checksums; this specification would incur an 1788 unnecessary burden precisely defining one, providing test vectors, 1789 etc., with no advantage over MD5. Option 2, SHA-1, belongs to the 1790 MD4 family that appears to be under suspicion in light of recent 1791 developments. To avoid creating an impression that any potential 1792 future changes in the status of SHA-1 can affect the status of OWAMP 1793 we chose not to use it. Option 3 would result in a hash function 1794 that, with the current state of knowledge, would probably be one of 1795 the most cryptographically sound. Our requirements 1-4 from the 1796 preceding paragraph, however, do not call for a cryptographically 1797 sound hash function. Just as with CRC-128, this specification would 1798 need to define the hash function and provide test vectors (and 1799 perhaps sample code); we see no advantage in this approach versus 1800 using MD5. (Note that the performance advantages of MD5 are 1801 irrelevant for this application, as the hash is computed on a 1802 relatively short human-supplied string only once per OWAMP-Control 1803 session, so if the Miyaguchi-Preneel construction were documented in 1804 an RFC, we might just as well have used that.) 1806 6.8. The Use of AES-CBC-MAC 1808 OWAMP relies on AES-CBC-MAC for message authentication. Random IV 1809 choice is important for prevention of a codebook attack on the first 1810 block; it is unimportant for the purposes of CBC-MAC authentication 1811 (it should also be noted that, with its 128-bit block size, AES is 1812 more resistant to codebook attacks than ciphers with shorter blocks; 1813 we use random IV anyway). 1815 IZP, when decrypted, MUST be zero. It is crucial to check for this 1816 before using the message, otherwise existential forgery becomes 1817 possible. The complete message for which IZP is decrypted to non- 1818 zero MUST be discarded (for both short messages consisting of a few 1819 blocks and potentially long messages, such as a response to the 1820 Fetch-Session command). 1822 Since OWAMP messages can have different numbers of blocks, the 1823 existential forgery attack described in example 9.62 of [MENEZES] 1824 becomes a concern. To prevent it (and to simplify implementation), 1825 the length of any message becomes known after decrypting the first 1826 block of it. 1828 A special case is the first (fixed-length) message sent by the 1829 client. There, the token is a concatenation of the 128-bit challenge 1830 (transmitted by the server in the clear) and a 128-bit session key 1831 (generated randomly by the client, encrypted with AES-CBC with IV=0. 1832 Since IV=0, the challenge (a single cipher block) is simply encrypted 1833 with the secret key. Therefore, we rely on resistance of AES to 1834 chosen plaintext attacks (as the challenge could be substituted by an 1835 attacker). It should be noted that the number of blocks of chosen 1836 plaintext an attacker can have encrypted with the secret key is 1837 limited by the number of sessions the client wants to initiate. An 1838 attacker who knows the encryption of a server's challenge can produce 1839 an existential forgery of the session key and thus disrupt the 1840 session; however, any attacker can disrupt a session by corrupting 1841 the protocol messages in an arbitrary fashion, therefore no new 1842 threat is created here; nevertheless, we require that the server 1843 never issues the same challenge twice (if challenges are generated 1844 randomly, a repetition would occur, on average, after 2^64 sessions; 1845 we deem this satisfactory as this is enough even for an implausibly 1846 busy server that participates in 1,000,000 sessions per second to go 1847 without repetitions for more than 500 centuries). With respect to 1848 the second part of the token, an attacker can produce an existential 1849 forgery of the session key by modifying the second half of the 1850 client's token while leaving the first part intact. This forgery, 1851 however, would be immediately discovered by the client when the IZP 1852 on the server's next message (acceptance or rejection of the 1853 connection) does not verify. 1855 7. IANA Considerations 1857 IANA is requested to allocate a well-known TCP port number for the 1858 OWAMP-Control part of the OWAMP protocol. 1860 8. Internationalization Considerations 1862 The protocol does not carry any information in a natural language. 1864 9. Appendix A: Sample C Code for Exponential Deviates 1866 The values in array Q[] are the exact values that MUST be used by all 1867 implementations (see sections 5.1 and 5.2). This appendix only 1868 serves for illustrative purposes. 1870 /* 1871 ** Example usage: generate a stream of exponential (mean 1) 1872 ** random quantities (ignoring error checking during initialization). 1873 ** If a variate with some mean mu other than 1 is desired, the output 1874 ** of this algorithm can be multiplied by mu according to the rules 1875 ** of arithmetic we described. 1877 ** Assume that a 16-octet 'seed' has been initialized 1878 ** (as the shared secret in OWAMP, for example) 1879 ** unsigned char seed[16]; 1881 ** OWPrand_context next; 1883 ** (initialize state) 1884 ** OWPrand_context_init(&next, seed); 1886 ** (generate a sequence of exponential variates) 1887 ** while (1) { 1888 ** u_int64_t num = OWPexp_rand64(&next); 1889 1890 ... 1891 ** } 1892 */ 1894 #include 1896 typedef u_int64_t u_int64_t; 1898 /* (K - 1) is the first k such that Q[k] > 1 - 1/(2^32). */ 1899 #define K 12 1900 #define BIT31 0x80000000UL /* See if first bit in the lower 1901 32 bits is zero. */ 1902 #define MASK32(n) ((n) & 0xFFFFFFFFUL) 1904 #define EXP2POW32 0x100000000ULL 1906 typedef struct OWPrand_context { 1907 unsigned char counter[16]; /* Counter (network byte order). */ 1908 keyInstance key; /* Key to encrypt the counter. */ 1909 unsigned char out[16]; /* The encrypted block. */ 1910 } OWPrand_context; 1912 /* 1913 ** The array has been computed according to the formula: 1914 ** 1915 ** Q[k] = (ln2)/(1!) + (ln2)^2/(2!) + ... + (ln2)^k/(k!) 1916 ** 1917 ** as described in algorithm S. (The values below have been 1918 ** multiplied by 2^32 and rounded to the nearest integer.) 1919 ** These exact values MUST be used so that different implementation 1920 ** produce the same sequences. 1921 */ 1922 static u_int64_t Q[K] = { 1923 0, /* Placeholder - so array indices start from 1. */ 1924 0xB17217F8, 1925 0xEEF193F7, 1926 0xFD271862, 1927 0xFF9D6DD0, 1928 0xFFF4CFD0, 1929 0xFFFEE819, 1930 0xFFFFE7FF, 1931 0xFFFFFE2B, 1932 0xFFFFFFE0, 1933 0xFFFFFFFE, 1934 0xFFFFFFFF 1935 }; 1937 /* this element represents ln2 */ 1938 #define LN2 Q[1] 1940 /* 1941 ** Convert an unsigned 32-bit integer into a u_int64_t number. 1942 */ 1943 u_int64_t 1944 OWPulong2num64(u_int32_t a) 1945 { 1946 return ((u_int64_t)1 << 32) * a; 1947 } 1948 /* 1949 ** Arithmetic functions on u_int64_t numbers. 1950 */ 1952 /* 1953 ** Addition. 1954 */ 1955 u_int64_t 1956 OWPnum64_add(u_int64_t x, u_int64_t y) 1957 { 1958 return x + y; 1959 } 1961 /* 1962 ** Multiplication. Allows overflow. Straightforward implementation 1963 ** of Algorithm 4.3.1.M (p.268) from [KNUTH]. 1964 */ 1965 u_int64_t 1966 OWPnum64_mul(u_int64_t x, u_int64_t y) 1967 { 1968 unsigned long w[4]; 1969 u_int64_t xdec[2]; 1970 u_int64_t ydec[2]; 1972 int i, j; 1973 u_int64_t k, t, ret; 1975 xdec[0] = MASK32(x); 1976 xdec[1] = MASK32(x>>32); 1977 ydec[0] = MASK32(y); 1978 ydec[1] = MASK32(y>>32); 1980 for (j = 0; j < 4; j++) 1981 w[j] = 0; 1983 for (j = 0; j < 2; j++) { 1984 k = 0; 1985 for (i = 0; ; ) { 1986 t = k + (xdec[i]*ydec[j]) + w[i + j]; 1987 w[i + j] = t%EXP2POW32; 1988 k = t/EXP2POW32; 1989 if (++i < 2) 1990 continue; 1991 else { 1992 w[j + 2] = k; 1993 break; 1994 } 1995 } 1997 } 1999 ret = w[2]; 2000 ret <<= 32; 2001 return w[1] + ret; 2002 } 2004 /* 2005 ** Seed the random number generator using a 16-byte quantity 'seed' 2006 ** (== the session ID in OWAMP). This function implements step U1 2007 ** of algorithm Unif. 2008 */ 2010 void 2011 OWPrand_context_init(OWPrand_context *next, unsigned char *seed) 2012 { 2013 int i; 2015 /* Initialize the key */ 2016 rijndaelKeyInit(next->key, seed); 2018 /* Initialize the counter with zeros */ 2019 memset(next->out, 0, 16); 2020 for (i = 0; i < 16; i++) 2021 next->counter[i] = 0UL; 2022 } 2024 /* 2025 ** Random number generating functions. 2026 */ 2028 /* 2029 ** Generate and return a 32-bit uniform random string (saved in the less 2030 ** significant half of the u_int64_t). This function implements steps 2031 ** U2-U4 of the algorithm Unif. 2032 */ 2033 u_int64_t 2034 OWPunif_rand64(OWPrand_context *next) 2035 { 2036 int j; 2037 u_int8_t *buf; 2038 u_int64_t ret = 0; 2040 /* step U2 */ 2041 u_int8_t i = next->counter[15] & (u_int8_t)3; 2042 if (!i) 2043 rijndaelEncrypt(next->key, next->counter, next->out); 2045 /* Step U3. Increment next.counter as a 16-octet single 2046 quantity in network byte order for AES counter mode. */ 2047 for (j = 15; j >= 0; j--) 2048 if (++next->counter[j]) 2049 break; 2051 /* Step U4. Do output. The last 4 bytes of ret now contain the 2052 random integer in network byte order */ 2053 buf = &next->out[4*i]; 2054 for (j=0; j<4; j++) { 2055 ret <<= 8; 2056 ret += *buf++; 2057 } 2058 return ret; 2059 } 2061 /* 2062 ** Generate an exponential deviate with mean 1. 2063 */ 2064 u_int64_t 2065 OWPexp_rand64(OWPrand_context *next) 2066 { 2067 unsigned long i, k; 2068 u_int32_t j = 0; 2069 u_int64_t U, V, J, tmp; 2071 /* Step S1. Get U and shift */ 2072 U = OWPunif_rand64(next); 2074 while ((U & BIT31) && (j < 32)) { /* Shift until first 0. */ 2075 U <<= 1; 2076 j++; 2077 } 2078 /* Remove the 0 itself. */ 2079 U <<= 1; 2081 U = MASK32(U); /* Keep only the fractional part. */ 2082 J = OWPulong2num64(j); 2084 /* Step S2. Immediate acceptance? */ 2085 if (U < LN2) /* return (j*ln2 + U) */ 2086 return OWPnum64_add(OWPnum64_mul(J, LN2), U); 2088 /* Step S3. Minimize. */ 2089 for (k = 2; k < K; k++) 2090 if (U < Q[k]) 2091 break; 2092 V = OWPunif_rand64(next); 2093 for (i = 2; i <= k; i++) { 2094 tmp = OWPunif_rand64(next); 2095 if (tmp < V) 2096 V = tmp; 2097 } 2099 /* Step S4. Return (j+V)*ln2 */ 2100 return OWPnum64_mul(OWPnum64_add(J, V), LN2); 2101 } 2103 10. Appendix B: Test Vectors for Exponential Deviates 2105 It is important that the test schedules generated by different 2106 implementations from identical inputs be identical. The non-trivial 2107 part is the generation of pseudo-random exponentially distributed 2108 deviates. To aid implementors in verifying interoperability, several 2109 test vectors are provided. For each of the four given 128-bit values 2110 of SID represented as hexadecimal numbers, 1,000,000 exponentially 2111 distributed 64-bit deviates are generated as described above. As 2112 they are generated, they are all added to each other. The sum of all 2113 1,000,000 deviates is given as a hexadecimal number for each SID. An 2114 implementation MUST produce exactly these hexadecimal numbers. To 2115 aid in the verification of the conversion of these numbers to values 2116 of delay in seconds, approximate values are given (assuming 2117 lambda=1). An implementation SHOULD produce delay values in seconds 2118 that are close to the ones given below. 2120 SID = 0x2872979303ab47eeac028dab3829dab2 2121 SUM[1000000] = 0x000f4479bd317381 (1000569.739036 seconds) 2123 SID = 0x0102030405060708090a0b0c0d0e0f00 2124 SUM[1000000] = 0x000f433686466a62 (1000246.524512 seconds) 2126 SID = 0xdeadbeefdeadbeefdeadbeefdeadbeef 2127 SUM[1000000] = 0x000f416c8884d2d3 (999788.533277 seconds) 2129 SID = 0xfeed0feed1feed2feed3feed4feed5ab 2130 SUM[1000000] = 0x000f3f0b4b416ec8 (999179.293967 seconds) 2132 11. Normative References 2134 [AES] Advanced Encryption Standard (AES), 2135 http://csrc.nist.gov/encryption/aes/ 2137 [RFC1321] R. Rivest, `The MD5 Message-Digest Algorithm', RFC 1321, 2138 April 1992. 2140 [RFC2026] S. Bradner, `The Internet Standards Process -- Revision 3', 2141 RFC 2026, October 1996. 2143 [RFC2119] S. Bradner, `Key words for use in RFCs to Indicate 2144 Requirement Levels', RFC 2119, March 1997. 2146 [RFC2330] V. Paxon, G. Almes, J. Mahdavi, M. Mathis, `Framework for 2147 IP Performance Metrics' RFC 2330, May 1998. 2149 [RFC2474] K. Nichols, S. Blake, F. Baker, D. Black, `Definition of 2150 the Differentiated Services Field (DS Field) in the IPv4 and 2151 IPv6 Headers', RFC 2474, December 1998. 2153 [RFC2679] G. Almes, S. Kalidindi, and M. Zekauskas, `A One-way Delay 2154 Metric for IPPM', RFC 2679, September 1999. 2156 [RFC2680] G. Almes, S. Kalidindi, and M. Zekauskas, `A One-way Packet 2157 Loss Metric for IPPM', RFC 2680, September 1999. 2159 [RFC2836] S. Brim, B. Carpenter, F. Le Faucheur, `Per Hop Behavior 2160 Identification Codes', RFC 2836, May 2000. 2162 12. Informative References 2164 [BRIX] Brix Networks, http://www.brixnet.com/ 2166 [ZIGG] G. Marsaglia, M. Sibuya, and J. H. Ahrens, Communications of 2167 ACM, 15 (1972), 876-877. 2169 [MENEZES] A. J. Menezes, P. C. van Oorschot, and S. A. Vanstone, 2170 Handbook of Applied Cryptography, CRC Press, revised reprint 2171 with updates, 1997. 2173 [KNUTH] D. Knuth, The Art of Computer Programming, vol.2, 3rd 2174 edition, 1998. 2176 [RIJN] Reference ANSI C Implementation of Rijndael 2177 http://www.esat.kuleuven.ac.be/~rijmen/rijndael/rijndaelref.zip 2179 [RIPE] RIPE NCC Test-Traffic Measurements home, 2180 http://www.ripe.net/test-traffic/. 2182 [RIPE-NLUUG] H. Uijterwaal and O. Kolkman, `Internet Delay 2183 Measurements Using Test-Traffic', Spring 1998 Dutch Unix User 2184 Group Meeting, 2185 http://www.ripe.net/test-traffic/Talks/9805_nluug.ps.gz. 2187 [SURVEYOR] Surveyor Home Page, http://www.advanced.org/surveyor/. 2189 [SURVEYOR-INET] S. Kalidindi and M. Zekauskas, `Surveyor: An 2190 Infrastructure for Network Performance Measurements', 2191 Proceedings of INET'99, June 1999. 2192 http://www.isoc.org/inet99/proceedings/4h/4h_2.htm 2194 [RFC1305] D. Mills, `Network Time Protocol (Version 3) Specification, 2195 Implementation and Analysis', RFC 1305, March 1992. 2197 [RFC1750] D. Eastlake 3rd, S. Crocker, J. Schiller, `Randomness 2198 Recommendations for Security', December 1994. 2200 [RFC2246] T. Dierks, C. Allen, `The TLS Protocol Version 1.0', 2201 January 1999. 2203 [RFC2401] S. Kent, R. Atkinson, `Security Architecture for the 2204 Internet Protocol', November 1998. 2206 [RFC3546] S. Blake-Wilson, M. Nystrom, D. Hopwood, J. Mikkelsen, T. 2207 Wright, `Transport Layer Security (TLS) Extensions', June 2003. 2209 13. Authors' Addresses 2211 Stanislav Shalunov 2212 Internet2 2213 1000 Oakbrook Drive, Suite 300 2214 Ann Arbor, MI 48104 2215 Email: shalunov@internet2.edu 2216 SIP: shalunov@internet2.edu 2217 Benjamin Teitelbaum 2218 Internet2 2219 1000 Oakbrook Drive, Suite 300 2220 Ann Arbor, MI 48104 2221 Email: ben@internet2.edu 2222 SIP: ben@internet2.edu 2224 Anatoly Karp 2225 4710 Regent St, Apt 81B 2226 Madison, WI 53705 2227 Telephone: +1-608-347-6255 2228 Email: ankarp@charter.net 2230 Jeff W. Boote 2231 Internet2 2232 1000 Oakbrook Drive, Suite 300 2233 Ann Arbor, MI 48104 2234 Email: boote@internet2.edu 2235 SIP: boote@internet2.edu 2237 Matthew J. Zekauskas 2238 Internet2 2239 1000 Oakbrook Drive, Suite 300 2240 Ann Arbor, MI 48104 2241 Email: matt@internet2.edu 2242 SIP: matt@internet2.edu 2244 Intellectual Property 2246 The IETF takes no position regarding the validity or scope of any 2247 Intellectual Property Rights or other rights that might be claimed to 2248 pertain to the implementation or use of the technology described in 2249 this document or the extent to which any license under such rights 2250 might or might not be available; nor does it represent that it has 2251 made any independent effort to identify any such rights. Information 2252 on the procedures with respect to rights in RFC documents can be found 2253 in BCP 78 and BCP 79. 2255 Copies of IPR disclosures made to the IETF Secretariat and any 2256 assurances of licenses to be made available, or the result of an 2257 attempt made to obtain a general license or permission for the use of 2258 such proprietary rights by implementers or users of this 2259 specification can be obtained from the IETF on-line IPR repository at 2260 http://www.ietf.org/ipr. 2262 The IETF invites any interested party to bring to its attention any 2263 copyrights, patents or patent applications, or other proprietary 2264 rights which may cover technology that may be required to implement 2265 this standard. Please address the information to the IETF at 2266 ietf-ipr@ietf.org. 2268 Disclaimer of Validity 2270 This document and the information contained herein are provided on an 2271 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 2272 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 2273 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 2274 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 2275 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 2276 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2278 Copyright Statement 2280 Copyright (C) The Internet Society (2004). This document is subject 2281 to the rights, licenses and restrictions contained in BCP 78, and 2282 except as set forth therein, the authors retain all their rights. 2284 Acknowledgments 2286 We would like to thank Guy Almes, Hamid Asgari, Steven Van den 2287 Berghe, Eric Boyd, Robert Cole, Joan Cucchiara, Stephen Donnelly, 2288 Susan Evett, Kaynam Hedayat, Petri Helenius, Kitamura Yasuichi, 2289 Daniel H. T. R. Lawson, Will E. Leland, Bruce A. Mah, Allison Mankin, 2290 Al Morton, Attila Pasztor, Randy Presuhn, Matthew Roughan, Andy 2291 Scherrer, Henk Uijterwaal, and Sam Weiler for their comments, 2292 suggestions, reviews, helpful discussion and proof-reading. 2294 Expiration date: June 2005