idnits 2.17.1 draft-ietf-ippm-owdp-01.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 195 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 159: '... An OWDP server SHOULD listen to this...' RFC 2119 keyword, line 202: '...h the client and MAY close the connect...' RFC 2119 keyword, line 203: '... SHOULD close the connection if it g...' RFC 2119 keyword, line 206: '...wise, the client MUST respond with the...' RFC 2119 keyword, line 238: '...CBC). Encryption MUST be performed usi...' (31 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 89 has weird spacing: '...eceiver the ...' == Line 100 has weird spacing: '...-Client an ...' == 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 (December 2000) is 8530 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 655, but not defined ** Obsolete undefined reference: RFC 958 (Obsoleted by RFC 1059, RFC 1119, RFC 1305) == Unused Reference: 'RFC2330' is defined on line 805, 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 (~~), 8 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: June 2001 B. Teitelbaum 5 Advanced Network & Services and Internet2 6 M. Zekauskas 7 Advanced Network & Services 8 December 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 not currently a standard that would 45 permit 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. OWDP-Control is used to initiate, start, stop and 80 retrieve test sessions, while OWDP-Test is the actual one-way delay 81 test protocol that exchanges singleton test packets between two 82 measurement nodes. 84 Several roles are logically separated to allow for broad flexibility 85 in use. Specifically, we define: 87 Session-Sender the sending endpoint of an OWDP-Test session; 89 Session-Receiver the receiving endpoint of an OWDP-Test session; 91 Server an end system that manages one or more OWDP-Test 92 sessions, is capable of configuring per-session 93 state in session endpoints, and is capable of 94 returning the results of a test session; 96 Control-Client an end system that initiates requests for 97 OWDP-Test sessions, triggers the start of a set 98 of sessions, and may trigger their termination; 100 Retrieve-Client an end system that initiates requests to retrieve 101 the results of completed OWDP-Test sessions; 103 One possible scenario of relationships between these roles is shown 104 below. 106 +----------------+ +------------------+ 107 | Session-Sender |--OWDP-Test-->| Session-Receiver | 108 +----------------+ +------------------+ 109 ^ ^ 110 | | 111 | | 112 | | 113 | +----------------+<----------------+ 114 | | Server |<-------+ 115 | +----------------+ | 116 | ^ | 117 | | | 118 | OWDP-Control OWDP-Control 119 | | | 120 v v v 121 +----------------+ +-----------------+ 122 | Control-Client | | Retrieve-Client | 123 +----------------+ +-----------------+ 125 (Unlabeled links in the figure are unspecified by this draft and may 126 be proprietary protocols.) 128 Different logical roles can be played by the same host. For example, 129 in the figure above, there could actually be only two hosts: one 130 playing the roles of Control-Client, Retrieve-Client, and Session- 131 Sender, and the other playing the roles of Server and Session- 132 Receiver. This is shown below. 134 +-----------------+ +------------------+ 135 | Control-Client |<--OWDP-Control-->| Server | 136 | Retrieve-Client | | | 137 | Session-Sender |---OWDP-Test----->| Session-Receiver | 138 +-----------------+ +------------------+ 140 Finally, because many Internet paths include segments that transport 141 IP over ATM, delay and loss measurements can include the effects of 142 ATM segmentation and reassembly (SAR). Consequently, OWDP has been 143 designed to allow for small test packets that would fit inside the 144 payload of a single ATM cell (this is only achieved in 145 unauthenticated and encrypted modes). 147 3. Protocol Overview 149 OWDP consists of two inter-related protocols: OWDP-Control and OWDP- 150 Test. The former is layered over TCP and is used to initiate and 151 control measurement sessions and to fetch their results. The latter 152 protocol is layered over UDP and is used to send singleton 153 measurement packets along the Internet path under test. 155 The initiator of the measurement session establishes a TCP connection 156 to a well-known port on the target point and this connection remains 157 open for the duration of the OWDP-Test sessions. IANA will be 158 requested to allocate a well-known port number for OWDP-Control 159 sessions. An OWDP server SHOULD listen to this well-known port. 161 OWDP-Control messages are transmitted only before OWDP-Test sessions 162 are actually started and after they complete (with the possible 163 exception of an early Stop-Session message). 165 The OWDP-Control and OWDP-Test protocols support three modes of 166 operation: unauthenticated, authenticated, and encrypted. The 167 authenticated or encrypted modes require endpoints to possess a 168 shared secret. 170 4. OWDP-Control 172 4.1. Connection Setup 174 Before either a Control-Client or a Retrieve-Client can issue 175 commands of a Server, it must establish a connection to the server. 177 First, a client opens a TCP connection to the server on a well-known 178 port. The server responds with a server greeting: 180 0 1 2 3 181 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 182 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 183 | | 184 . Unused (15 octets) . 185 . . 186 . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 187 | | Modes | 188 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 189 | | 190 . . 191 . Challenge (16 octets) . 192 . . 193 | | 194 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 196 The following mode values are meaningful: 1 for unauthenticated, 2 197 for authenticated, 4 for encrypted. The value of the Modes field 198 sent by the server is the bit-wise OR of the mode values that it is 199 willing to support during this session. 201 If the Modes octet is zero, the server doesn't wish to communicate 202 with the client and MAY close the connection immediately. The client 203 SHOULD close the connection if it gets a greeting with Modes equal to 204 zero. 206 Otherwise, the client MUST respond with the following message: 208 0 1 2 3 209 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 210 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 211 | Mode | Unused | 212 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 213 | KID | 214 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 215 | | 216 . . 217 . Token (32 octets) . 218 . . 219 | | 220 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 221 | | 222 . . 223 . Client-IV (16 octets) . 224 . . 225 | | 226 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 228 Here Mode is the mode that the client chooses to use during this 229 OWDP-Control session. It will also be used for all OWDP-Test 230 sessions started under control of this OWDP-Control session. 232 In unauthenticated mode, KID, Token, and Client-IV are unused. 234 Otherwise, KID (key ID) is a 4-octet indicator of which shared secret 235 the client wishes to use to authenticate or encrypt and Token is the 236 concatenation of a 16-octet challenge and a 16-octet Session-key, 237 encrypted using the AES (Advanced Encryption Standard) [AES] in 238 Cipher Block Chaining (CBC). Encryption MUST be performed using an 239 Initialization Vector (IV) of zero and a key value that is the shared 240 secret associated with KID. 242 Session-key and Client-IV are generated randomly by the client. 244 The server MUST respond with the following message: 246 0 1 2 3 247 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 248 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 249 | | 250 . Unused (15 octets) . 251 . . 252 . +-+-+-+-+-+-+-+-+ 253 | | Yes/No | 254 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 255 | | 256 . . 257 . Server-IV (16 octets) . 258 . . 259 | | 260 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 262 A zero value in the "Yes/No" field means that the server accepts the 263 authentication and is willing to conduct further transactions. Any 264 non-zero value means that the server does not accept the 265 authentication provided by the client or, for some other reason, is 266 not willing to conduct further transactions in this OWDP-Control 267 session. If a "No" response is sent, the server MAY close the 268 connection after this message. The client SHOULD close the 269 connection if it gets message that says "No" at this stage. 271 The previous transactions constitute connection setup. 273 4.2. OWDP-Control Commands 275 In authenticated or encrypted mode (which are identical as far as 276 OWDP-Control is concerned, and only differ in OWDP-Test) all further 277 communications are encrypted with the Session-key, using CBC mode. 278 The client encrypts its stream using Client-IV. The server encrypts 279 its stream using Server-IV. 281 The following commands are available for the client: Request-Session, 282 Start-Sessions, Stop-Session, Retrieve-Session. The command Stop- 283 Session is available to both client and server. 285 After Start-Sessions is sent/received by the client/server, and 286 before it both sends and receives Stop-Session (order unspecified), 287 it is said to be conducting active measurements. 289 While conducting active measurements, the only command available is 290 Stop-Session. 292 These commands are described in detail below. 294 4.3. Creating Test Sessions 296 Individual one-way delay measurement sessions are established using a 297 simple request/response protocol. An OWDP client MAY issue zero or 298 more Request-Session messages to an OWDP server, which MUST respond 299 to each with an Accept-Session message. An Accept-Session message 300 MAY refuse a request. 302 The format of Request-Session message is as follows: 304 0 1 2 3 305 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 306 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 307 | 1 |IPVN-S | IPVN-R| Conf-Sender | Conf-Receiver | 308 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 309 | Sender Address | 310 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 311 | Sender Address (cont.) or Unused | 312 | | 313 | | 314 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 315 | Receiver Address | 316 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 317 | Receiver Address (cont.) or Unused | 318 | | 319 | | 320 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 321 | Sender Port | Receiver Port | 322 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 323 | | 324 | SID (16 octets) | 325 | | 326 | | 327 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 328 | TTL | Flags | PHB ID | 329 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 330 | Inv-Lambda | 331 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 332 | Packets | 333 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 334 | Padding Length | 335 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 336 | Start Time | 337 | | 338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 339 | Sender Precision | Receiver Precision | 340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 341 | | 342 | Zero Padding | 343 | | 344 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 346 Here the first octet (1) indicates that this is Request-Session 347 command. 349 IPVN-S and IPVN-R are IP version numbers for Sender and Receiver. In 350 the case of IP version number being 4, twelve unused octets follow 351 the four-octet address. 353 Conf-Sender and Conf-Receiver can be 0 or 1. If 1, the server is 354 being asked to configure the corresponding agent (sender or 355 receiver). In this case, the corresponding Port value SHOULD be 356 disregarded by the server. At least one of Conf-Sender and Conf- 357 Receiver MUST be 1. 359 The Sender Address and Receiver Address fields contain respectively 360 the sender and receiver addresses of the end points of the Internet 361 path over which an OWDP test session is requested. 363 SID is the session identifier. It can be used in later sessions as 364 an argument for Retrieve-Session command. It is meaningful only if 365 Conf-Receiver is 1. 367 The field Inv-Lambda is an unsigned integer and is the scaled 368 reciprocal of rate (in microseconds) at which the Poisson test stream 369 is to be generated. This allows the average Poisson sampling 370 interval for the requested test session to be set to between 1 371 microsecond and over an hour. 373 The value Packets is the number of active measurement packets to be 374 sent during this OWDP-Test session (note that both server and client 375 can abort the session early). 377 Padding length is the number of octets to be appended to normal OWDP- 378 Test packet (see more on padding in discussion of OWDP-Test). 380 Start Time is the time when the session is to be started (but not 381 before Start-Sessions command is issued). 383 Sender Precision and Receiver Precision are signed integers in the 384 range +32 to -32 indicating the precision of the corresponding 385 clocks, in seconds to the nearest power of two, as described in 386 RFC 958. Sender Precision is meaningful only if Conf-Sender is not 387 set. Receiver Precision is meaningful only if Conf-Receiver is not 388 set. 390 To each Request-Session message, an OWDP server MUST respond with an 391 Accept-Session message: 393 0 1 2 3 394 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 395 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 396 | Accept | Unused | Port | 397 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| 398 | | 399 | SID (16 octets) | 400 | | 401 | | 402 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 403 | Sender Precision | Receiver Precision | 404 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 405 | | 406 | | 407 | Zero Padding | 408 | | 409 | | 410 | | 411 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 413 Zero in the Accept field means that the server is willing to conduct 414 the session. Any non-zero value indicates rejection of the request. 416 If the server rejects a Request-Session command, it SHOULD not close 417 the TCP connection. The client MAY close it if it gets negative 418 response to Request-Session. 420 The meaning of Port depend on the values of Conf-Sender and Conf- 421 Receiver in the query that solicited the response. If both were set, 422 Port field is unused. If only Conf-Sender was set, Port is the port 423 to expect OWDP-Test packets from. If only Conf-Receiver was set, 424 Port is the port to send OWDP-Test packets to. 426 If only Conf-Sender was set, SID is unused. Otherwise, SID is a 427 unique server-generated session identifier. It can be used later as 428 handle to retrieve the results of a session. 430 SIDs SHOULD be constructed by concatenation of 4-octet IPv4 IP number 431 belonging to the generating machine, 8-octet timestamp, and 4-octet 432 random value. 434 Sender Precision and Receiver Precision have the same meaning as in 435 Request-Session command. Sender Precision is meaningful only if 436 Conf-Sender is set. Receiver Precision is meaningful only if Conf- 437 Receiver is set. 439 4.4. Starting Test Sessions 441 Having requested one or more test sessions and received affirmative 442 Accept-Session responses, an OWDP client may start the execution of 443 the requested test sessions by sending a Start-Sessions message to 444 the server. 446 The format of this message is as follows: 448 0 1 2 3 449 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 450 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 451 | 2 | | 452 +-+-+-+-+-+-+-+-+ | 453 | Unused | 454 | | 455 | | 456 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 457 | | 458 | Zero Padding (16 octets) | 459 | | 460 | | 461 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 463 The server MUST respond with an Control-Ack message (which SHOULD be 464 sent as quickly as possible). Control-Ack messages have the following 465 format: 467 0 1 2 3 468 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 469 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 470 | Accept | | 471 +-+-+-+-+-+-+-+-+ | 472 | Unused | 473 | | 474 | | 475 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 476 | | 477 | Zero Padding (16 octets) | 478 | | 479 | | 480 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 482 If Accept has any non-zero value, the Start-Sessions request was 483 rejected; zero means that the command was accepted. The server MAY 484 and the client SHOULD close the connection in the case of a negative 485 response. 487 The server SHOULD start all OWDP-Test streams immediately after it 488 sends the response or immediately after their specified start times, 489 whichever is later. (Note that a client can effect an immediate 490 start by specifying in Request-Session a Start Time in the past.) If 491 the client represents a Sender, the client SHOULD start its OWDP-Test 492 streams immediately after it sees the Control-Ack response from the 493 Server. 495 4.5. Stop-Sessions 497 The Stop-Sessions message may be issued by either the Control-Client 498 or the Server. The format of this command is as follows: 500 0 1 2 3 501 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 502 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 503 | 3 | Accept | | 504 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 505 | Unused | 506 | | 507 | | 508 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 509 | | 510 | Zero Padding (16 octets) | 511 | | 512 | | 513 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 515 Normally, the client SHOULD send this command after the OWDP-Test 516 streams have completed. However, either client or server MAY send it 517 prematurely. 519 Non-zero value of Accept indicates a failure of some sort. Zero 520 values indicates normal (but possibly premature) completion. If 521 Accept had non-zero value (from either party), or if it was not 522 transmitted at all (for whatever reason, including TCP connection 523 used for OWDP-Control breaking), results of all OWDP-Test sessions 524 spawned by this OWDP-Control session SHOULD be considered invalid, 525 even if Retrieve-Session with SID from this session works during a 526 different OWDP-Control session. 528 The party that receives this command MUST stop its OWDP-Test streams 529 and respond with a Stop-Sessions message. Any non-zero value in 530 Accept field means something went wrong. A zero value means OWDP- 531 Test streams have been successfully stopped. 533 4.6. Retrieve-Session 535 The format of this client command is as follows: 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 | 4 | | 541 +-+-+-+-+-+-+-+-+ | 542 | Unused | 543 | | 544 | | 545 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 546 | | 547 | SID | 548 | | 549 | | 550 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 551 | | 552 | Zero Padding (16 octets) | 553 | | 554 | | 555 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 557 The server MUST respond with a Control-Ack message. Again, any non- 558 zero value in the Accept field means rejection of command. Zero 559 means that data will follow. 561 If Yes/No was 0, the server then MUST send the OWDP-Test session data 562 in question, followed by 16 octets of zero padding. 564 The transmission starts with 4 octets that contain the number of 565 records that will follow, each record representing one received 566 packet. This is followed by 2 octets of Sender Precision, 2 octets 567 of Receiver precision, and 8 octets of zero padding. 569 Each packet is represented with 20 octets, and includes 4 octets of 570 sequence number, 8 octets of send timestamp, and 8 octets of receive 571 timestamp. 573 The last (possibly full, possibly incomplete) block (16 octets) of 574 data is padded with zeros. A zero padding consisting of 16 octets is 575 then appended. 577 5. OWDP-Test 579 This section describes OWDP-Test protocol. It runs over UDP using 580 sender and receiver IP and port numbers negotiated during Session- 581 Prepare exchange. 583 As OWDP-Control, OWDP-Test has three modes: unauthenticated, 584 authenticated, and encrypted. All OWDP-Test sessions spawned by an 585 OWDP-Control session inherit its mode. 587 OWDP-Control client, OWDP-Control server, OWDP-Test sender, and OWDP- 588 Test receiver can potentially all be different machines. (In a 589 typical case we expect that there will be only two machines.) 591 5.1. Sender Behavior 593 The sender sends the receiver a stream of packets with Poisson 594 distribution of times between packets. The format of the body of a 595 UDP packet in the stream depends on the mode being used. 597 For unauthenticated mode: 599 0 1 2 3 600 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 601 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 602 | Sequence Number | 603 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 604 | Timestamp | 605 | | 606 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 607 | | 608 . . 609 . Packet padding (0-65515 octets) . 610 . . 611 | | 612 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 614 For authenticated mode: 616 0 1 2 3 617 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 618 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 619 | Sequence Number | 620 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 621 | | 622 | Zero Padding | 623 | | 624 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 625 | Timestamp | 626 | | 627 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 628 | | 629 . . 630 . Packet padding (0-65503 octets) . 631 . . 632 | | 633 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 635 For encrypted mode: 637 0 1 2 3 638 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 639 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 640 | Sequence Number | 641 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 642 | Timestamp | 643 | | 644 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 645 | Zero Padding | 646 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 647 | | 648 . . 649 . Packet padding (0-65511 octets) . 650 . . 651 | | 652 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 654 The format of timestamp is the same as that of NTP v3 protocol 655 [RFC958]. Quoting from RFC 958: 657 NTP timestamps are represented as a 64-bit fixed-point number, in 658 seconds relative to 0000 UT on 1 January 1900. The integer part 659 is in the first 32 bits and the fraction part in the last 32 bits, 660 as shown in the following diagram. 662 0 1 2 3 663 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 664 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 665 | Integer Part | 666 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 667 | Fraction Part | 668 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 670 This format allows convenient multiple-precision arithmetic and 671 conversion to Time Protocol representation (seconds), but does 672 complicate the conversion to ICMP Timestamp message representation 673 (milliseconds). The low-order fraction bit increments at about 674 0.2-nanosecond intervals, so a free-running one-millisecond clock 675 will be in error only a small fraction of one part per million, or 676 less than a second per year. 678 Sequence numbers start with 0. 680 The minimum data segment length is therefore 12 octets in 681 unauthenticated mode, 24 octets in authenticated mode, and 16 octets 682 in encrypted mode. 684 In authenticated and encrypted mode, the first block (16 octets) of 685 each packet is encrypted using AES ECB mode. 687 In unauthenticated mode, no encryption is applied. 689 The time elapsed between packets is pseudo-random, with exponential 690 distribution (resulting in a Poisson stream of packets). As 691 suggested in RFC 2330, the ith sampling interval Ei may be computed 692 using inverse transform: 694 Ei = -ln(Ui) * Inv-Lambda 696 where Ui is uniformly distributed between 0 and 1 and lambda is the 697 desired mean time between packets. 699 Pseudo-random stream of bits is obtained using AES with SID as the 700 key, running in counter mode (first encrypted block is 0, second 701 encrypted block is 1 in network octet order, etc.) Each block of 64 702 bits is used to obtain one pseudo-random number uniformly distributed 703 between 0 and 1. If the bits are Bj (j=1..64, numbered left to 704 right), the resulting value is 705 U = B1*2^{-1} + B2*2^{-2} + ... B64*2^{-64} 707 The parameter lambda is has the value requested in the Request- 708 Session message of the OWDP-Control negotiation that spawned the 709 session. 711 The logarithm and division in the formula above MUST be computed 712 using IEEE 754 standard floating point arithmetic. [HELP WANTED!: 713 Someone with a stronger background in numerical analysis to specify 714 how to compute the sampling intervals precisely and portably!] 716 Finally, Packet Padding SHOULD be pseudo-random (generated 717 independently of any other pseudo-random numbers mentioned in this 718 document). However, implementations MUST provide a configuration 719 parameter, an option, or a different means of making Packet Padding 720 consist of all zeros. 722 5.2. Receiver Behavior 724 Receiver knows when the sender will send packets. The following 725 parameter is defined: loss threshold. It SHOULD be 10 minutes and 726 MAY be more, but not more than 60 minutes. 728 As packets are received, 730 + Timestamp the received packet. 732 + In authenticated or encrypted mode, decrypt first block (16 733 octets) of packet body. 735 + Store the packet sequence number, send times, and receive times 736 for the results to be transferred. 738 + Packets not received within the loss threshold are considered 739 lost. They are recorded with their seqno, presumed send time, and 740 receive time consisting of a string of zero bits. 742 Packets that have send time in the future MUST be recorded normally, 743 without changing their send timestamp, unless they have to be 744 discarded. 746 If any of the following is true, packet MUST be discarded: 748 + Send timestamp is more than loss threshold in the past or in the 749 future. 751 + Send timestamp differs by more than loss threshold from the time 752 when the packet should have been sent according to its seqno. 754 + In authenticated or encrypted mode, any of the bits of zero 755 padding inside the first 16 octets of packet body is non-zero. 757 6. Security Considerations 759 The goal of authenticated mode to let one password-protect service 760 provided by a particular OWDP-Control server. One can imagine a 761 variety of circumstances where this could be useful. Authenticated 762 mode is designed to prohibit theft of service. 764 Additional design objective of authenticated mode was to make it 765 impossible for an attacker who cannot read traffic between OWDP-Test 766 sender and receiver to tamper with test results in a fashion that 767 affects the measurements, but not other traffic. 769 The goal of encrypted mode is quite different: To make it hard for a 770 party in the middle of the network to make results look "better" than 771 they should be. This is especially true if one of client and server 772 doesn't coincide with neither sender nor receiver. 774 Encryption of OWDP-Control using AES CBC mode with blocks of zeros 775 after each message aims to achieve two goals: (i) to provide secrecy 776 of exchange; (ii) to provide authentication of each message. 778 OWDP-Test sessions directed at an unsuspecting party could be used 779 for denial of service (DoS) attacks. In unauthenticated mode servers 780 should limits receivers to hosts they control or to the OWDP-Control 781 client. 783 OWDP-Test sessions could be used as covert channels of information. 784 Environments that are worried about covert channels should take this 785 into consideration. 787 Notice that AES in counter mode is used for pseudo-random number 788 generation, so implementation of AES MUST be included even in a 789 server that only supports unauthenticated mode. 791 7. References 793 [AES] Advanced Encryption Standard (AES), 794 http://csrc.nist.gov/encryption/aes/ 796 [RFC958]D. Mills, "Network Time Protocol (NTP)", RFC 958, September 797 1985. 799 [RFC2026]S. Bradner, "The Internet Standards Process -- Revision 3", 800 RFC 2026, October 1996. 802 [RFC2119]S. Bradner, "Key words for use in RFCs to Indicate 803 Requirement Levels", RFC 2119, March 1997. 805 [RFC2330] V. Paxon, G. Almes, J. Mahdavi, M. Mathis, "Framework 806 for IP Performance Metrics" RFC 2330, May 1998. 808 [RFC2679]G. Almes, S. Kalidindi, and M. Zekauskas, "A One-way Delay 809 Metric for IPPM", RFC 2679, September 1999. 811 [RFC2680]G. Almes, S. Kalidindi, and M. Zekauskas, "A One-way Packet 812 Loss Metric for IPPM", RFC 2680, September 1999. 814 [RFC2836]S. Brim, B. Carpenter, F. Le Faucheur, "Per Hop Behavior 815 Identification Codes", RFC 2836, May 2000. 817 [RIPE] Ripe Test-Traffic Home page, http://www.ripe.net/test- 818 traffic/. 820 [RIPE-NLUUG]H. Uijterwaal and O. Kolkman, "Internet Delay 821 Measurements Using Test-Traffic", Spring 1998 Dutch Unix User 822 Group Meeting, http://www.ripe.net/ripencc/mem- 823 services/ttm/Talks/9805_nluug.ps.gz. (NOTE: it's actually 824 postscript, not gzip'd postscript.) 826 [SURVEYOR] Surveyor Home Page, http://www.advanced.org/surveyor/. 828 [SURVEYOR-INET]S. Kalidindi and M. Zekauskas, "Surveyor: An 829 Infrastructure for Network Performance Measurements", 830 Proceedings of INET'99, June 1999. 831 http://www.isoc.org/inet99/proceedings/4h/4h_2.htm 833 8. Authors' Addresses 835 Stanislav Shalunov 836 Internet2 / UCAID 837 200 Business Park Drive 838 Armonk, NY 10504 839 USA 841 Phone: +1 914 765 1182 842 EMail: shalunov@internet2.edu 843 Benjamin Teitelbaum 844 Advanced Network & Services 845 200 Business Park Drive 846 Armonk, NY 10504 847 USA 849 Phone: +1 914 765 1118 850 EMail: ben@advanced.org 852 Matthew J. Zekauskas 853 Advanced Network & Services, Inc. 854 200 Business Park Drive 855 Armonk, NY 10504 856 USA 858 Phone: +1 914 765 1112 859 EMail: matt@advanced.org 861 Expiration date: June 2001