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