idnits 2.17.1 draft-ietf-ippm-owdp-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Abstract section. ** The document seems to lack an Introduction section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 190 instances of too long lines in the document, the longest one being 1 character in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 133: '...ns. OWDP server SHOULD listen to this...' RFC 2119 keyword, line 169: '... field MAY be committed....' RFC 2119 keyword, line 172: '...ent), the server MAY close the connect...' RFC 2119 keyword, line 173: '... client SHOULD close the connection ...' RFC 2119 keyword, line 176: '...wise, the client MUST respond with the...' (20 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == 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 (November 2000) is 8535 days in the past. Is this intentional? 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: 'RFC2679' is mentioned on line 41, but not defined ** Obsolete undefined reference: RFC 2679 (Obsoleted by RFC 7679) == Missing Reference: 'RFC 2680' is mentioned on line 42, but not defined ** Obsolete undefined reference: RFC 2680 (Obsoleted by RFC 7680) == Missing Reference: 'RFC958' is mentioned on line 587, but not defined ** Obsolete undefined reference: RFC 958 (Obsoleted by RFC 1059, RFC 1119, RFC 1305) == Unused Reference: 'RFC2330' is defined on line 700, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'AES' ** Downref: Normative reference to an Informational RFC: RFC 2330 -- Possible downref: Non-RFC (?) normative reference: ref. 'RIPE' -- Possible downref: Non-RFC (?) normative reference: ref. 'SURVEYOR' Summary: 13 errors (**), 0 flaws (~~), 6 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Shalunov 3 Internet Draft Internet2 4 Expiration Date: May 2001 B. Teitelbaum 5 Advanced Network & Services and Internet2 6 M. Zekauskas 7 Advanced Network & Services 8 November 2000 10 A One-way Delay Measurement Protocol 11 13 1. Status of this Memo 15 This document is an Internet-Draft and is in full conformance with 16 all provisions of Section 10 of RFC2026. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt 31 The list of Internet-Draft shadow directories can be accessed at 32 http://www.ietf.org/shadow.html 34 This memo provides information for the Internet community. This memo 35 does not specify an Internet standard of any kind. Distribution of 36 this memo is unlimited. 38 2. Motivation and Goals 40 The IETF IP Performance Metrics (IPPM) working group has proposed 41 draft standard metrics for one-way packet delay [RFC2679] and loss 42 [RFC 2680] across Internet paths. Although there are now several 43 measurement platforms that implement collection of these metrics 44 [SURVEYOR], [RIPE], there is to date no standard that would permit 45 initiation of test streams or exchange of packets to collect 46 singleton metrics in an interoperable manner. 48 With the increasingly wide availability of affordable global 49 positioning system (GPS) and CDMA based time sources, hosts 50 increasingly have available to them very accurate time 51 sources--either directly or through their proximity to NTP primary 52 (stratum 1) time servers. By standardizing a technique for 53 collecting IPPM one-way delay measurements, we hope to create an 54 environment where IPPM metrics may be collected across a far broader 55 mesh of Internet paths than is currently possible. One particularly 56 compelling vision is of widespread deployment of open OWDP servers 57 that would make measurement of one-way delay as commonplace as 58 measurement of round-trip time using an ICMP-based tool like ping. 60 Additional design goals of OWDP include stealth, security, logical 61 separation of control and test functionality, and support for small 62 test packets. 64 Stealth is achieved by making test packet streams look as much as 65 possible like ordinary Internet traffic. Towards this goal, OWDP's 66 test protocol is layered over UDP and allows for a wide range of 67 packet sizes and port numbers. Additionally, OWDP supports an 68 encrypted mode that obscures all transmitted data, making detection 69 of OWDP test activity by Internet service providers very difficult. 71 Security features include optional authentication and/or encryption 72 of control and test messages. These features may be useful to 73 prevent unauthorized access to results or man-in-the-middle attackers 74 who attempt to provide special treatment to OWDP test streams or who 75 attempt to modify sender-generated timestamps to falsify test 76 results. 78 OWDP actually consists of two inter-related protocols: OWDP-Control 79 and OWDP-Test with several roles logically separated to allow for 80 broad flexibility in use. Specifically, the following roles are 81 logically separate: Control-Client, Retrieve-Client, Server, Session- 82 Source, and Session-Receiver. The relationships between these are 83 shown below. 85 +----------------+ +------------------+ 86 | Session-Source |--OWDP-Test-->| Session-Receiver | 87 +----------------+ +------------------+ 88 ^ ^ 89 | | 90 | | 91 V | 92 +----------------+<---------------------+ 93 | Server |<------------+ 94 +----------------+ | 95 ^ | 96 | | 97 OWDP-Control OWDP-Control 98 | | 99 V V 100 +----------------+ +-----------------+ 101 | Control-Client | | Retrieve-Client | 102 +----------------+ +-----------------+ 104 A Control-Client speaks to a Server and may request test session 105 initiation and may request that accepted test sessions be started and 106 stopped. A Retrieve-Client also speaks to a Server and may request 107 the results of an OWDP test session. The test session itself consists 108 of a stream of singleton OWDP-Test packets sent from Session-Source 109 to Session-Receiver. 111 Any combination these logical blocks may, in fact, be collocated. 113 [FIXME: Insert interesting examples.] 115 Finally, because many Internet paths include segments that transport 116 IP over ATM, delay and loss measurements can include the effects of 117 ATM segmentation and reassembly (SAR). Consequently, OWDP has been 118 designed to allow for small test packets that would fit inside the 119 payload of a single ATM cell. 121 3. Protocol Overview 123 OWDP actually consists of two inter-related protocols: OWDP-Control 124 and OWDP-Test. The former is layered over TCP and is used to 125 initiate and control measurement sessions and to fetch their results. 126 The latter protocol is layered over UDP and is used to send singleton 127 measurement packets along the Internet path under test. 129 The initiator of the measurement session establishes a TCP connection 130 to a well-known port on the target point and this connection remains 131 open for the duration of the OWDP-Test sessions. IANA will be 132 requested to allocate a well-known port number for OWDP-Control 133 sessions. OWDP server SHOULD listen to this well-known port. 135 OWDP-Control messages are transmitted only before OWDP-Test sessions 136 actually started and after they complete (with the possible exception 137 of an early Stop-Sessions message). 139 The protocol allows negotiating three modes of operation of OWDP- 140 Control and OWDP-Test: unauthenticated, authenticated, and encrypted. 141 If authenticated or encrypted mode is desired, endpoints must possess 142 a shared secret. 144 3.1. OWDP-Control 146 The client opens a TCP connection to the server on a well-known port. 148 The server responds with server greeting: 149 0 1 2 3 150 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 151 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 152 | | 153 . Unused (15 octets) . 154 . . 155 . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 156 | | Modes | 157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 158 | | 159 . . 160 . Challenge (16 octets) . 161 . . 162 | | 163 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 165 The following mode values are meaningful: 1 for unauthenticated, 2 166 for authenticated, 4 for encrypted. The value of the Modes field 167 sent by the server is the bit-wise OR of the mode values it is 168 willing to support during this session. If Modes is 1, the Challenge 169 field MAY be committed. 171 If Modes octet is zero (server doesn't wish to communicate with this 172 client), the server MAY close the connection after this message. The 173 client SHOULD close the connection if it gets a greeting with Modes 174 equal to zero. 176 Otherwise, the client MUST respond with the following message: 178 0 1 2 3 179 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 180 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 181 | Mode | Unused | 182 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 183 | KID | 184 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 185 | | 186 . . 187 . Token (32 octets) . 188 . . 189 | | 190 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 191 | | 192 . . 193 . Client-IV (16 octets) . 194 . . 195 | | 196 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 198 Here Mode is the mode that the client chooses to use during this 199 OWDP-Control session. It will also be used for all OWDP-Test 200 sessions started under control of this OWDP-Control session. 202 In unauthenticated mode, KID, Token, and Client-IV are unused. 204 Otherwise, KID (key ID) is a 4-octet indicator of which shared secret 205 the client wishes to use to authenticate or encrypt and Token is the 206 concatenation of a 16-octet challenge and a 16-octet Session-key, 207 encrypted using the AES (Advanced Encryption Standard) [AES] in 208 Cipher Block Chaining (CBC). Encryption MUST be performed using an 209 Initialization Vector (IV) of zero and a key value that is the shared 210 secret associated with KID. 212 Session-key and Client-IV are generated randomly by the client. 214 The server MUST respond with the following message: 216 0 1 2 3 217 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 218 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 219 | | 220 . Unused (15 octets) . 221 . . 222 . +-+-+-+-+-+-+-+-+ 223 | | Yes/No | 224 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 225 | | 226 . . 227 . Server-IV (16 octets) . 228 . . 229 | | 230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 232 Here "Yes/No" is either 1 or 0. Yes (0) means that the server 233 accepts the authentication and is willing to conduct further 234 transactions. No (any non-zero value) means that the server doesn't 235 accept authentication provided by the client, or for some other 236 reason is not willing to conduct further transactions in this OWDP- 237 Control session. 239 If a "No" response is sent, the server MAY close the connection after 240 this message. The client SHOULD close the connection if it gets 241 message that says "No" at this stage. 243 The previous transactions constitute connection setup. 245 In authenticated or encrypted mode (which are identical as far as 246 OWDP-Control is concerned, and only differ in OWDP-Test) all further 247 communications are encrypted with the Session-key, using CBC mode. 248 The client encrypts its stream using Client-IV. The server encrypts 249 its stream using Server-IV. 251 The following commands are available for the client: Request-Session, 252 Start-Sessions, End-Sessions, Retrieve-Session. The command End- 253 Sessions is available to both client and server. 255 [FIXME: move next two paragraphs below?] After Start-Sessions is 256 sent/received by the client/server, and before it both sends and 257 receives End-Sessions (order unspecified), it is said to be 258 conducting active measurements. 260 While conducting active measurements, the only command available is 261 End-Session. 263 3.2. Creating Test Sessions 265 Individual one-way delay measurement sessions are established using a 266 simple request/response protocol. An OWDP client, may issue one or 267 more Request-Session messages to an OWDP server, which must respond 268 to each with an Accept-Session message. An Accept-Session message may 269 refuse a request. 271 The format of Request-Session message is as follows: 272 0 1 2 3 273 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 274 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 275 | 1 | Represents | IPVN | Unused | 276 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 277 | Source Address | 278 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 279 | Source Address (cont.) or Unused | 280 | | 281 | | 282 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 283 | Unused | Port | 284 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 285 | | 286 | SID (16 octets) | 287 | | 288 | | 289 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 290 | Dest Address | 291 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 292 | Dest Address (cont.) or Unused | 293 | | 294 | | 295 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 296 | Inv-Lambda | 297 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 298 | Packets | 299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 300 | Padding Length | 301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 302 | Start Time | 303 | | 304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 305 | Accuracy | 306 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 308 Here the first octet (1) indicates that this is Request-Session 309 command. 311 Represents can have three values: Source (0), Dest (1), and Third- 312 Party(2). It tells the server on whose behalf the client is 313 speaking. 315 The meaning of Port depends on the value of Represents. If it is 316 Source, Port is the port to expect OWDP-Test packets from. Is it is 317 Dest, Port is the port to send OWDP-Test packets to. Port is unused 318 in the case of a Third-Party client. 320 The Source Address and Dest Address fields contain respectively the 321 source and destination addresses of the end points of the Internet 322 path over which an OWDP test session is requested. The IPVN field 323 contains the IP version number of the source and destination 324 addresses that follow. In the case of IPVN=4, twelve unused octets 325 follow each address. 327 SID is the session identifier. It can be used in later sessions as 328 an argument for Retrieve-Session command. It is meaningful only if 329 Represents is Dest. 331 The field Inv-Lambda is an unsigned integer and is the scaled 332 reciprocal in microseconds of rate at which the Poisson test stream 333 is to be generated. This allows the average Poisson sampling 334 interval for the requested test session to be set to between 1 335 microsecond and over an hour. 337 The value Packets is the number of active measurement packets to be 338 sent during this OWDP-Test session (note that both server and client 339 can abort the session early). 341 Padding length is the number of octets to be appended to normal OWDP- 342 Test packet (see more on padding in discussion of OWDP-Test). 344 To each Request-Session message, an OWDP server MUST respond with an 345 Accept-Session message: 347 0 1 2 3 348 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 349 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 350 | Accept | | 351 +-+-+-+-+-+-+-+-+ | 352 | | 353 | Unused | 354 | | 355 | | 356 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 357 | Unused | Port | 358 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 359 | | 360 | SID (16 octets) | 361 | | 362 | | 363 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 364 | Zero Padding | 365 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 367 Zero in the Accept field means that the server is willing to conduct 368 the session. Any non-zero indicates rejection of the request. 370 If the server rejects a Request-Session command, it SHOULD not close 371 the TCP connection. The client MAY close it if it gets negative 372 response to Request-Session. 374 The meaning of Port depend on the value of Represents in the query 375 that solicited the response. If it was Dest, Port is the port to 376 expect OWDP-Test packets from. Is it was Source, Port is the port to 377 send OWDP-Test packets to. If is was Third-Party, the Port field is 378 unused. 380 SID is a locally-unique server-generated session identifier. It can 381 be used later as handle to retrieve the results of a session. An 382 OWDP server MUST return an SID, if Represents was Source or Third- 383 Party. It is not meaningful if Represents was Dest. 385 3.3. Starting Test Sessions 387 Having requested one or more test sessions and received affirmative 388 Accept-Session responses, an OWDP client may start the execution of 389 the requested test sessions by sending a Start-Sessions message to 390 the server. 392 The format of this message is as follows: 394 0 1 2 3 395 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 396 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 397 | 2 | | 398 +-+-+-+-+-+-+-+-+ | 399 | Unused | 400 | | 401 | | 402 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 403 | | 404 | Zero Padding (16 octets) | 405 | | 406 | | 407 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 409 The server MUST respond with an Control-Ack message (which SHOULD be 410 sent as quickly as possible). Control-Ack messages have the following 411 format: 413 0 1 2 3 414 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 415 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 416 | Accept | | 417 +-+-+-+-+-+-+-+-+ | 418 | Unused | 419 | | 420 | | 421 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 422 | | 423 | Zero Padding (16 octets) | 424 | | 425 | | 426 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 428 If Accept has any non-zero value, the Start-Sessions request was 429 rejected; zero means that the command was accepted. The server MAY 430 and the client SHOULD close the connection in the case of a negative 431 response. 433 The server SHOULD start all OWDP-Test streams immediately after it 434 sends the response or immediately after their specified start times, 435 whichever is later. (Note that a client can effect an immediate 436 start by specifying in Request-Session a Start Time in the past.) The 437 client represents a Source, the client SHOULD start its OWDP-Test 438 streams immediately after it sees the Control-Ack response from the 439 Server. 441 3.4. Stop-Sessions 443 The Stop-Sessions message may be issued by either the Control-Client 444 or the Server. The format of this command is as follows: 446 0 1 2 3 447 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 448 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 449 | 3 | | 450 +-+-+-+-+-+-+-+-+ | 451 | Unused | 452 | | 453 | | 454 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 455 | | 456 | Zero Padding (16 octets) | 457 | | 458 | | 459 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 461 Normally, the client SHOULD send this command after the OWDP-Test 462 streams have completed. However, either client or server MAY send it 463 prematurely. 465 The party that receives this command MUST stop its OWDP-Test streams 466 and respond with a Control-Ack message. Any non-zero value in Accept 467 field means something went wrong. A zero value means OWDP-Test 468 streams have been successfully stopped. 470 3.5. Retrieve-Session 472 The format of this client command is as follows: 474 0 1 2 3 475 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 476 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 477 | 4 | | 478 +-+-+-+-+-+-+-+-+ | 479 | Unused | 480 | | 481 | | 482 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 483 | | 484 | SID | 485 | | 486 | | 487 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 488 | | 489 | Zero Padding (16 octets) | 490 | | 491 | | 492 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 494 The server MUST respond with a Control-Ack message. Again, any non- 495 zero value in the Accept field means rejection of command. Zero 496 means that data will follow. 498 If Yes/No was 0, the server then MUST send the OWDP-Test session data 499 in question, followed by 16 octets of zero padding. 501 Each packet is represented with 20 octets, and includes 4 octets of 502 sequence number, 8 octets of send timestamp, and 8 octets of receive 503 timestamp. 505 The last (possibly full, possibly incomplete) block (16 octets) of 506 data is padded with zeros. A zero padding consisting of 16 octets is 507 then appended. 509 4. OWDP-Test 511 This section describes OWDP-Test protocol. It runs over UDP using 512 source and destination IP and port numbers negotiated during Session- 513 Prepare exchange. 515 As OWDP-Control, OWDP-Test has three modes: unauthenticated, 516 authenticated, and encrypted. All OWDP-Test sessions spawned by an 517 OWDP-Control session inherit its mode. 519 OWDP-Control client, OWDP-Control server, OWDP-Test sender, and OWDP- 520 Test receiver can potentially all be different machines. (In a 521 typical case we expect that there will be only two machines.) 523 4.1. Sender Behavior 525 The sender sends the receiver a stream of packets with Poisson 526 distribution of times between packets. The format of the body of a 527 UDP packet in the stream depends on the mode being used. 529 For unauthenticated mode: 531 0 1 2 3 532 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 533 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 534 | Sequence Number | 535 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 536 | Timestamp | 537 | | 538 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 539 | | 540 . . 541 . Zero padding (0-65515 octets) . 542 . . 543 | | 544 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 546 For authenticated mode: 548 0 1 2 3 549 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 550 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 551 | Sequence Number | 552 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 553 | | 554 | Zero Padding | 555 | | 556 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 557 | Timestamp | 558 | | 559 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 560 | | 561 . . 562 . Zero padding (0-65503 octets) . 563 . . 564 | | 565 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 567 For encrypted mode: 569 0 1 2 3 570 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 571 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 572 | Sequence Number | 573 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 574 | Timestamp | 575 | | 576 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 577 | Zero Padding | 578 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 579 | | 580 . . 581 . Zero padding (0-65511 octets) . 582 . . 583 | | 584 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 586 The format of timestamp is the same as that of NTP v3 protocol 587 [RFC958]. Quoting from RFC 958: 589 NTP timestamps are represented as a 64-bit fixed-point number, in 590 seconds relative to 0000 UT on 1 January 1900. The integer part 591 is in the first 32 bits and the fraction part in the last 32 bits, 592 as shown in the following diagram. 594 0 1 2 3 595 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 596 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 597 | Integer Part | 598 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 599 | Fraction Part | 600 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 602 This format allows convenient multiple-precision arithmetic and 603 conversion to Time Protocol representation (seconds), but does 604 complicate the conversion to ICMP Timestamp message representation 605 (milliseconds). The low-order fraction bit increments at about 606 0.2-nanosecond intervals, so a free-running one-millisecond clock 607 will be in error only a small fraction of one part per million, or 608 less than a second per year. 610 Sequence numbers start with 0. 612 The minimum data segment length is therefore 12 octets in 613 unauthenticated mode, 24 octets in authenticated mode, and 16 octets 614 in encrypted mode. 616 In authenticated and encrypted mode, the first block (16 octets) of 617 each packet is encrypted using AES ECB mode. 619 In unauthenticated mode, no encryption is applied. 621 The time elapsed between packets is (pseudo) random, with exponential 622 (Poisson) distribution. As suggested in RFC 2330, the ith sampling 623 interval Ei may be computed using inverse transform: 625 Ei = -log(Ui) / lambda 627 where Ui is uniformly distributed between 0 and 1 and obtained using 628 AES with SID as the key, running in counter mode (first encrypted 629 block is 0, second encrypted block is 1 in network octet order, etc.) 630 and lambda is the desired mean rate of the sampling distribution. 631 [FIXME: should state precisely how the 16 byte block is interpreted 632 as a number between 0 and 1]. 634 The parameter lambda is has the value requested in the Request-Session 635 message of the OWDP-Control negotiation that spawned the session. 637 The logarithm and division in the formula above MUST be computed using 638 IEEE 754 standard floating point arithmetic. [HELP WANTED!: Someone 639 with a stronger background in numerical analysis to specify how to 640 compute the sampling intervals precisely and portably!] 642 4.2. Receiver Behavior 644 FIXME: Expand this sketch. 646 As packets are received, 648 + Timestamp the received packet. 650 + Store the packet sequence number, send times, and receive times 651 for the results to be transferred. 653 + Packets not received within parameter Tl, the loss threshold are 654 considered lost. FIXME: loss threshold not mentioned above. also 655 need to decide if the receiver knows which packets are lost, and 656 if so how is it represented in the results perhaps (seqno presumed 657 send time, receive time of 0). 659 5. Security Considerations 661 The goal of authenticated mode to let one be able to password-protect 662 service provided by a particular OWDP-Control server. One can 663 imagine a variety of circumstances where this could be useful. 664 Authenticated mode is designed to prohibit theft of service. 666 Additional design objective of authenticated mode was to make it 667 impossible for an attacker who cannot read traffic between OWDP-Test 668 sender and receiver to tamper with test results in a fashion that 669 affects the measurements, but not other traffic. 671 The goal of encrypted mode is quite different: To make it hard for a 672 party in the middle of the network to make results look "better" than 673 they should be. This is especially true if one of client and server 674 doesn't coincide with neither sender nor receiver. 676 Encryption of OWDP-Control using AES CBC mode with blocks of zeros 677 after each message aims to achieve two goals: (i) to provide secrecy 678 of exchange; (ii) to provide authentication of each message. 680 FIXME: More stuff to go here. 682 Notice that AES in counter mode is used for pseudo-random number 683 generation, so implementation of AES MUST be included even in a 684 server that only supports unauthenticated mode. 686 6. References 688 [AES] Advanced Encryption Standard (AES), 689 http://csrc.nist.gov/encryption/aes/ 691 [RFC958]D. Mills, "Network Time Protocol (NTP)", RFC 958, September 692 1985. 694 [RFC2026]S. Bradner, "The Internet Standards Process -- Revision 3", 695 RFC 2026, October 1996. 697 [RFC2119]S. Bradner, "Key words for use in RFCs to Indicate 698 Requirement Levels", RFC 2119, March 1997. 700 [RFC2330] V. Paxon, G. Almes, J. Mahdavi, M. Mathis, "Framework 701 for IP Performance Metrics" RFC 2330, May 1998. 703 [RFC2679]G. Almes, S. Kalidindi, and M. Zekauskas, "A One-way Delay 704 Metric for IPPM", RFC 2679, September 1999. 706 [RFC2680]G. Almes, S. Kalidindi, and M. Zekauskas, "A One-way Packet 707 Loss Metric for IPPM", RFC 2680, September 1999. 709 [RIPE] Ripe Test-Traffic Home page, http://www.ripe.net/test- 710 traffic/. 712 [RIPE-NLUUG]H. Uijterwaal and O. Kolkman, "Internet Delay 713 Measurements Using Test-Traffic", Spring 1998 Dutch Unix User 714 Group Meeting, http://www.ripe.net/ripencc/mem- 715 services/ttm/Talks/9805_nluug.ps.gz. (NOTE: it's actually 716 postscript, not gzip'd postscript.) 718 [SURVEYOR] Surveyor Home Page, http://www.advanced.org/surveyor/. 720 [SURVEYOR-INET]S. Kalidindi and M. Zekauskas, "Surveyor: An 721 Infrastructure for Network Performance Measurements", 722 Proceedings of INET'99, June 1999. 723 http://www.isoc.org/inet99/proceedings/4h/4h_2.htm 725 7. Authors' Addresses 727 Stanislav Shalunov 728 Internet2 / UCAID 729 200 Business Park Drive 730 Armonk, NY 10504 731 USA 733 Phone: +1 914 765 1182 734 EMail: shalunov@internet2.edu 736 Benjamin Teitelbaum 737 Advanced Network & Services 738 200 Business Park Drive 739 Armonk, NY 10504 740 USA 742 Phone: +1 914 765 1118 743 EMail: ben@advanced.org 745 Matthew J. Zekauskas 746 Advanced Network & Services, Inc. 747 200 Business Park Drive 748 Armonk, NY 10504 749 USA 751 Phone: +1 914 765 1112 752 EMail: kalidindi@advanced.org 754 Expiration date: May 2001