idnits 2.17.1 draft-ietf-ippm-owdp-03.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 194 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 196: '... An OWDP server SHOULD listen to this...' RFC 2119 keyword, line 217: '...xpected, connection SHOULD be dropped....' RFC 2119 keyword, line 248: '... the client and MAY close the connect...' RFC 2119 keyword, line 249: '... SHOULD close the connection if it g...' RFC 2119 keyword, line 252: '...wise, the client MUST respond with the...' (39 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 126 has weird spacing: '...eceiver the ...' == Line 137 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 (February 2001) is 8471 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) == Unused Reference: 'RFC2330' is defined on line 892, 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: 12 errors (**), 0 flaws (~~), 7 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: April 2002 B. Teitelbaum 5 Advanced Network & Services and Internet2 6 M. Zekauskas 7 Advanced Network & Services 8 February 2001 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 being hard to detect and 61 manipulate, security, logical separation of control and test 62 functionality, and support for small test packets. 64 OWDP test traffic is hard to detect, because it is simply a stream of 65 UDP packets from and to negotiated port numbers with potentially 66 nothing static in the packets (size is negotiated, too). 67 Additionally, OWDP supports an encrypted mode, that further obscures 68 the traffic, at the same time making it impossible to alter 69 timestamps undetectably. 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 2.1. Relationship of Test and Control Protocols 80 OWDP actually consists of two inter-related protocols: OWDP-Control 81 and OWDP-Test. OWDP-Control is used to initiate, start, stop and 82 retrieve test sessions, while OWDP-Test is used to exchange test 83 packets between two measurement nodes. 85 Although OWDP-Test may be used in conjunction with a control protocol 86 other than OWDP-Control, the authors have deliberately chosen to 87 include both protocols in the same draft to encourage the 88 implementation and deployment of OWDP-Control as a common denominator 89 control protocol for one-way delay measurement. Having a complete and 90 open one-way delay measurement solution that is simple to implement 91 and deploy is crucial to assuring a future in which inter-domain one- 92 way delay measurement could become as commonplace as ping. We neither 93 anticipate nor recommend that OWDP-Control form the foundation of a 94 general purpose, extensible, measurement and monitoring control 95 protocol. 97 OWDP-Control is designed to support the negotiation of one-way delay 98 measurement sessions and results retrieval in a straightforward 99 manner. At session initiation, there is a negotiation of sender and 100 receiver addresses and port numbers, session start time, session 101 length, test packet size, the mean Poisson sampling interval for the 102 test stream, and some attributes of the very general RFC 2330 notion 103 of "packet type", including packet size and per-hop behavior (PHB) 104 [RFC2474], which could be used to support the measurement of one-way 105 delay across diff-serv networks. Additionally, OWDP-Control supports 106 per-session encryption and authentication for both test and control 107 traffic, measurement servers which may act as proxies for test stream 108 endpoints, and the exchange of a seed value for the pseudo-random 109 Poisson process that describes the test stream generated by the 110 sender. 112 We believe that OWDP-Control can effectively support one-way delay 113 measurement in a variety of environments, from publicly accessible 114 delay "beacons" running on arbitrary hosts to network monitoring 115 deployments within private corporate intra-nets. If integration with 116 SNMP or proprietary network management protocols is required, 117 gateways may be created. 119 2.2. Logical Model 121 Several roles are logically separated to allow for broad flexibility 122 in use. Specifically, we define: 124 Session-Sender the sending endpoint of an OWDP-Test session; 126 Session-Receiver the receiving endpoint of an OWDP-Test session; 128 Server an end system that manages one or more OWDP-Test 129 sessions, is capable of configuring per-session 130 state in session endpoints, and is capable of 131 returning the results of a test session; 133 Control-Client an end system that initiates requests for 134 OWDP-Test sessions, triggers the start of a set 135 of sessions, and may trigger their termination; 137 Retrieve-Client an end system that initiates requests to retrieve 138 the results of completed OWDP-Test sessions; 140 One possible scenario of relationships between these roles is shown 141 below. 143 +----------------+ +------------------+ 144 | Session-Sender |--OWDP-Test-->| Session-Receiver | 145 +----------------+ +------------------+ 146 ^ ^ 147 | | 148 | | 149 | | 150 | +----------------+<----------------+ 151 | | Server |<-------+ 152 | +----------------+ | 153 | ^ | 154 | | | 155 | OWDP-Control OWDP-Control 156 | | | 157 v v v 158 +----------------+ +-----------------+ 159 | Control-Client | | Retrieve-Client | 160 +----------------+ +-----------------+ 162 (Unlabeled links in the figure are unspecified by this draft and may 163 be proprietary protocols.) 165 Different logical roles can be played by the same host. For example, 166 in the figure above, there could actually be only two hosts: one 167 playing the roles of Control-Client, Retrieve-Client, and Session- 168 Sender, and the other playing the roles of Server and Session- 169 Receiver. This is shown below. 171 +-----------------+ +------------------+ 172 | Control-Client |<--OWDP-Control-->| Server | 173 | Retrieve-Client | | | 174 | Session-Sender |---OWDP-Test----->| Session-Receiver | 175 +-----------------+ +------------------+ 177 Finally, because many Internet paths include segments that transport 178 IP over ATM, delay and loss measurements can include the effects of 179 ATM segmentation and reassembly (SAR). Consequently, OWDP has been 180 designed to allow for small test packets that would fit inside the 181 payload of a single ATM cell (this is only achieved in 182 unauthenticated and encrypted modes). 184 3. Protocol Overview 186 As described above, OWDP consists of two inter-related protocols: 187 OWDP-Control and OWDP-Test. The former is layered over TCP and is 188 used to initiate and control measurement sessions and to fetch their 189 results. The latter protocol is layered over UDP and is used to send 190 singleton measurement packets along the Internet path under test. 192 The initiator of the measurement session establishes a TCP connection 193 to a well-known port on the target point and this connection remains 194 open for the duration of the OWDP-Test sessions. IANA will be 195 requested to allocate a well-known port number for OWDP-Control 196 sessions. An OWDP server SHOULD listen to this well-known port. 198 OWDP-Control messages are transmitted only before OWDP-Test sessions 199 are actually started and after they complete (with the possible 200 exception of an early Stop-Session message). 202 The OWDP-Control and OWDP-Test protocols support three modes of 203 operation: unauthenticated, authenticated, and encrypted. The 204 authenticated or encrypted modes require endpoints to possess a 205 shared secret. 207 All multi-octet quantities defined in this document are represented 208 in network byte order. 210 4. OWDP-Control 212 Each type of OWDP-Control message has a fixed length. The recipient 213 will know the full length of a message after examining first 16 214 octets of it. No message is shorter than 16 octets. 216 If the full message is not received within 30 minutes after it is 217 expected, connection SHOULD be dropped. 219 4.1. Connection Setup 221 Before either a Control-Client or a Retrieve-Client can issue 222 commands of a Server, it must establish a connection to the server. 224 First, a client opens a TCP connection to the server on a well-known 225 port. The server responds with a server greeting: 227 0 1 2 3 228 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 229 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 230 | | 231 | Unused (12 octets) | 232 | | 233 |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 234 | Modes | 235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 236 | | 237 | Challenge (16 octets) | 238 | | 239 | | 240 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 242 The following mode values are meaningful: 1 for unauthenticated, 2 243 for authenticated, 4 for encrypted. The value of the Modes field 244 sent by the server is the bit-wise OR of the mode values that it is 245 willing to support during this session. 247 If Modes value is zero, the server doesn't wish to communicate with 248 the client and MAY close the connection immediately. The client 249 SHOULD close the connection if it gets a greeting with Modes equal to 250 zero. 252 Otherwise, the client MUST respond with the following message: 254 0 1 2 3 255 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 256 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 257 | Mode | 258 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 259 | KID | 260 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 261 | | 262 . . 263 . Token (32 octets) . 264 . . 265 | | 266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 267 | | 268 . . 269 . Client-IV (16 octets) . 270 . . 271 | | 272 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 274 Here Mode is the mode that the client chooses to use during this 275 OWDP-Control session. It will also be used for all OWDP-Test 276 sessions started under control of this OWDP-Control session. In 277 Mode, one or zero bits MUST be set. 279 In unauthenticated mode, KID, Token, and Client-IV are unused. 281 Otherwise, KID (key ID) is a 4-octet indicator of which shared secret 282 the client wishes to use to authenticate or encrypt and Token is the 283 concatenation of a 16-octet challenge and a 16-octet Session-key, 284 encrypted using the AES (Advanced Encryption Standard) [AES] in 285 Cipher Block Chaining (CBC). Encryption MUST be performed using an 286 Initialization Vector (IV) of zero and a key value that is the shared 287 secret associated with KID. 289 Session-key and Client-IV are generated randomly by the client. 291 The server MUST respond with the following message: 293 0 1 2 3 294 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 295 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 296 | | 297 | Unused (15 octets) | 298 | | 299 + +-+-+-+-+-+-+-+-+ 300 | | Accept | 301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 302 | | 303 | Server-IV (16 octets) | 304 | | 305 | | 306 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 308 A zero value in the Accept field means that the server accepts the 309 authentication and is willing to conduct further transactions. A 310 value of 1 means that the server does not accept the authentication 311 provided by the client or, for some other reason, is not willing to 312 conduct further transactions in this OWDP-Control session. All other 313 values are reserved. If a negative response is sent, the server MAY 314 and the client SHOULD close the connection after this message. 316 The previous transactions constitute connection setup. 318 4.2. OWDP-Control Commands 320 In authenticated or encrypted mode (which are identical as far as 321 OWDP-Control is concerned, and only differ in OWDP-Test) all further 322 communications are encrypted with the Session-key, using CBC mode. 323 The client encrypts its stream using Client-IV. The server encrypts 324 its stream using Server-IV. 326 The following commands are available for the client: Request-Session, 327 Start-Sessions, Stop-Session, Retrieve-Session. The command Stop- 328 Session is available to both client and server. 330 After Start-Sessions is sent/received by the client/server, and 331 before it both sends and receives Stop-Session (order unspecified), 332 it is said to be conducting active measurements. 334 While conducting active measurements, the only command available is 335 Stop-Session. 337 These commands are described in detail below. 339 4.3. Creating Test Sessions 341 Individual one-way delay measurement sessions are established using a 342 simple request/response protocol. An OWDP client MAY issue zero or 343 more Request-Session messages to an OWDP server, which MUST respond 344 to each with an Accept-Session message. An Accept-Session message 345 MAY refuse a request. 347 The format of Request-Session message is as follows: 349 0 1 2 3 350 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 351 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 352 | 1 |IPVN-S | IPVN-R| Conf-Sender | Conf-Receiver | 353 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 354 | Sender Address | 355 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 356 | Sender Address (cont.) or Unused | 357 | | 358 | | 359 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 360 | Receiver Address | 361 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 362 | Receiver Address (cont.) or Unused | 363 | | 364 | | 365 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 366 | Sender Port | Receiver Port | 367 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 368 | | 369 | SID (16 octets) | 370 | | 371 | | 372 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 373 | Inv-Lambda | 374 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 375 | Packets | 376 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 377 | Padding Length | 378 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 379 | Start Time | 380 | | 381 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 382 | Type-P Descriptor | 383 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 384 | | 385 | Zero Padding (16 octets) | 386 | | 387 | | 388 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 390 Here the first octet (1) indicates that this is Request-Session 391 command. 393 IPVN-S and IPVN-R are IP version numbers for Sender and Receiver. In 394 the case of IP version number being 4, twelve unused octets follow 395 the four-octet address. 397 Conf-Sender and Conf-Receiver can be 0 or 1. If 1, the server is 398 being asked to configure the corresponding agent (sender or 399 receiver). In this case, the corresponding Port value SHOULD be 400 disregarded by the server. At least one of Conf-Sender and Conf- 401 Receiver MUST be 1. (Both can be set, in which case the server is 402 being asked to perform a session between two hosts it can configure.) 404 The Sender Address and Receiver Address fields contain respectively 405 the sender and receiver addresses of the end points of the Internet 406 path over which an OWDP test session is requested. 408 If Conf-Sender is not set, Sender Port is the UDP port OWDP-Test 409 packets will be sent from. If Conf-Receiver is not set, Receiver 410 Port is the UDP port OWDP-Test packets are requested to be sent to. 412 SID is the session identifier. It can be used in later sessions as 413 an argument for Retrieve-Session command. It is meaningful only if 414 Conf-Receiver is 1. 416 The field Inv-Lambda is an unsigned integer and is the scaled 417 reciprocal of rate (in microseconds) at which the Poisson test stream 418 is to be generated. This allows the average Poisson sampling 419 interval for the requested test session to be set to between 1 420 microsecond and over an hour. 422 The value Packets is the number of active measurement packets to be 423 sent during this OWDP-Test session (note that both server and client 424 can abort the session early). 426 Padding length is the number of octets to be appended to normal OWDP- 427 Test packet (see more on padding in discussion of OWDP-Test). 429 Start Time is the time when the session is to be started (but not 430 before Start-Sessions command is issued). This timestamp is in the 431 same format as OWDP-Test timestamps. 433 Type-P Descriptor covers only a subset of (very large) Type-P space. 434 If the first two bits of Type-P Descriptor are 00, then subsequent 6 435 bits specify the requested Differentiated Services Codepoint (DSCP) 436 value of sent OWDP-Test packets as defined in RFC 2474. If the first 437 two bits of Type-P descriptor are 01, then subsequent 16 bits specify 438 the requested Per Hop Behavior Identification Code (PHB ID) as 439 defined in RFC 2836. 441 Therefore, the value of all zeros specifies the default best-effort 442 service. 444 If Conf-Sender is set, Type-P Descriptor is to be used to configure 445 the sender to send packets according to its value. If Conf-Sender is 446 not set, Type-P Descriptor is a declaration of how the sender will be 447 configured. 449 If Conf-Sender is set and the server doesn't recognize Type-P 450 Descriptor, cannot or does not wish to set the corresponding 451 attributes on OWDP-Test packets, it SHOULD reject the session 452 request. If Conf-Sender is not set, the server SHOULD accept the 453 session regardless of the value of Type-P Descriptor. 455 To each Request-Session message, an OWDP server MUST respond with an 456 Accept-Session message: 458 0 1 2 3 459 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 460 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 461 | Accept | Unused | Port | 462 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| 463 | | 464 | SID (16 octets) | 465 | | 466 | | 467 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 468 | | 469 | Zero Padding (12 octets) | 470 | | 471 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 473 Zero in the Accept field means that the server is willing to conduct 474 the session. A value of 1 indicates rejection of the request. All 475 other values are reserved. 477 If the server rejects a Request-Session command, it SHOULD not close 478 the TCP connection. The client MAY close it if it gets negative 479 response to Request-Session. 481 The meaning of Port depend on the values of Conf-Sender and Conf- 482 Receiver in the query that solicited the response. If both were set, 483 Port field is unused. If only Conf-Sender was set, Port is the port 484 to expect OWDP-Test packets from. If only Conf-Receiver was set, 485 Port is the port to send OWDP-Test packets to. 487 If only Conf-Sender was set, SID is unused. Otherwise, SID is a 488 unique server-generated session identifier. It can be used later as 489 handle to retrieve the results of a session. 491 SIDs SHOULD be constructed by concatenation of 4-octet IPv4 IP number 492 belonging to the generating machine, 8-octet timestamp, and 4-octet 493 random value. 495 Sender Precision and Receiver Precision have the same meaning as in 496 Request-Session command. Sender Precision is meaningful only if 497 Conf-Sender is set. Receiver Precision is meaningful only if Conf- 498 Receiver is set. 500 4.4. Starting Test Sessions 502 Having requested one or more test sessions and received affirmative 503 Accept-Session responses, an OWDP client may start the execution of 504 the requested test sessions by sending a Start-Sessions message to 505 the server. 507 The format of this message is as follows: 509 0 1 2 3 510 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 511 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 512 | 2 | | 513 +-+-+-+-+-+-+-+-+ | 514 | Unused (15 octets) | 515 | | 516 | | 517 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 518 | | 519 | Zero Padding (16 octets) | 520 | | 521 | | 522 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 524 The server MUST respond with an Control-Ack message (which SHOULD be 525 sent as quickly as possible). Control-Ack messages have the following 526 format: 528 0 1 2 3 529 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 530 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 531 | Accept | | 532 +-+-+-+-+-+-+-+-+ | 533 | Unused (15 octets) | 534 | | 535 | | 536 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 537 | | 538 | Zero Padding (16 octets) | 539 | | 540 | | 541 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 543 If Accept is 1, the Start-Sessions request was rejected; zero means 544 that the command was accepted. All other values are reserved. The 545 server MAY and the client SHOULD close the connection in the case of 546 a negative response. 548 The server SHOULD start all OWDP-Test streams immediately after it 549 sends the response or immediately after their specified start times, 550 whichever is later. (Note that a client can effect an immediate 551 start by specifying in Request-Session a Start Time in the past.) If 552 the client represents a Sender, the client SHOULD start its OWDP-Test 553 streams immediately after it sees the Control-Ack response from the 554 Server. 556 4.5. Stop-Sessions 558 The Stop-Sessions message may be issued by either the Control-Client 559 or the Server. The format of this command is as follows: 561 0 1 2 3 562 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 563 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 564 | 3 | Accept | | 565 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 566 | Unused (14 octets) | 567 | | 568 | | 569 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 570 | | 571 | Zero Padding (16 octets) | 572 | | 573 | | 574 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 576 Normally, the client SHOULD send this command after the OWDP-Test 577 streams have completed. However, either client or server MAY send it 578 prematurely. 580 Value of 1 of Accept indicates a failure of some sort. Zero values 581 indicates normal (but possibly premature) completion. All other 582 values are reserved. If Accept had non-zero value (from either 583 party), or if it was not transmitted at all (for whatever reason, 584 including TCP connection used for OWDP-Control breaking), results of 585 all OWDP-Test sessions spawned by this OWDP-Control session SHOULD be 586 considered invalid, even if Retrieve-Session with SID from this 587 session works during a different OWDP-Control session. 589 The party that receives this command MUST stop its OWDP-Test streams 590 and respond with a Stop-Sessions message. Any non-zero value in 591 Accept field means something went wrong. A zero value means OWDP- 592 Test streams have been successfully stopped. 594 4.6. Retrieve-Session 596 The format of this client command is as follows: 598 0 1 2 3 599 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 600 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 601 | 4 | | 602 +-+-+-+-+-+-+-+-+ | 603 | Unused (17 octets) | 604 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 605 | Begin Seq | 606 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 607 | End Seq | 608 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 609 | | 610 | SID (16 octets) | 611 | | 612 | | 613 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 614 | | 615 | Zero Padding (16 octets) | 616 | | 617 | | 618 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 620 Begin Seq is the sequence number of the first requested packet. End 621 Seq is the sequence number of the last requested packet. If Begin 622 Seq is all zeros and End Seq is all ones, complete session is said to 623 be requested. 625 If a complete session is requested and the session is still in 626 progress, or has terminated in any way other than normal, the request 627 to retrieve session results MUST be denied. If an incomplete session 628 is requested, all packets received so far that fall into the 629 requested range SHOULD be returned. 631 The server MUST respond with a Control-Ack message. Again, 1 in the 632 Accept field means rejection of command. Zero means that data will 633 follow. All other values are reserved. 635 If Yes/No was 0, the server then MUST send the OWDP-Test session data 636 in question, followed by 16 octets of zero padding. 638 The transmission starts with 4 octets that contain the number of 639 records that will follow, each record representing one received 640 packet. This is followed by 4 octets of Type-P Descriptor and 8 641 octets of zero padding. 643 Each packet is represented with 20 octets, and includes 4 octets of 644 sequence number, 8 octets of send timestamp, and 8 octets of receive 645 timestamp. 647 The last (possibly full, possibly incomplete) block (16 octets) of 648 data is padded with zeros if necessary. A zero padding consisting of 649 16 octets is then appended. 651 5. OWDP-Test 653 This section describes OWDP-Test protocol. It runs over UDP using 654 sender and receiver IP and port numbers negotiated during Session- 655 Prepare exchange. 657 As OWDP-Control, OWDP-Test has three modes: unauthenticated, 658 authenticated, and encrypted. All OWDP-Test sessions spawned by an 659 OWDP-Control session inherit its mode. 661 OWDP-Control client, OWDP-Control server, OWDP-Test sender, and OWDP- 662 Test receiver can potentially all be different machines. (In a 663 typical case we expect that there will be only two machines.) 665 5.1. Sender Behavior 667 The sender sends the receiver a stream of packets with Poisson 668 distribution of times between packets. The format of the body of a 669 UDP packet in the stream depends on the mode being used. 671 For unauthenticated mode: 673 0 1 2 3 674 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 675 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 676 | Sequence Number | 677 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 678 | Timestamp | 679 | | 680 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 681 | | 682 . . 683 . Packet padding (0-65515 octets) . 684 . . 685 | | 686 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 688 For authenticated mode: 690 0 1 2 3 691 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 692 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 693 | Sequence Number | 694 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 695 | | 696 | Zero Padding (12 octets) | 697 | | 698 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 699 | Timestamp | 700 | | 701 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 702 | | 703 . . 704 . Packet padding (0-65503 octets) . 705 . . 706 | | 707 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 709 For encrypted mode: 711 0 1 2 3 712 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 713 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 714 | Sequence Number | 715 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 716 | Timestamp | 717 | | 718 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 719 | Zero Padding | 720 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 721 | | 722 . . 723 . Packet padding (0-65511 octets) . 724 . . 725 | | 726 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 728 The format of the timestamp is influenced by RFC 1305 and is as 729 follows: first 32 bits represent the unsigned integer number of 730 seconds elapsed since 0h on 1 January 1900; next 24 bits represent 731 the fractional part of a second that has elapsed since then (so, 732 first 56 bits of the timestamp would be the same as the corresponding 733 bits of NTP v3 timestamp). The remaining octet specifies 734 synchronization and precision. The first bit is set if the party 735 generating the timestamp has a clock that is synchronized to an 736 external source (e.g., the bit should be set if GPS hardware is used 737 and it indicates that it has acquired current position and time or if 738 NTP is used and it indicates that it has synchronized to an external 739 source, which includes stratum 0 source, etc.); if there is no notion 740 of external synchronization for the time source (e.g., a cesium 741 oscillator is used directly), the bit SHOULD be set. The next bit is 742 currently unused and may be set to an arbitrary value. The remaining 743 six bits form an unsigned integer, which is the number of bits in the 744 time-specifying main part of the timestamp that the party generating 745 timestamp believes to be correct (this should be set conservatively). 746 When generating a timestamp, one MUST ensure that this number falls 747 into the range from 0 to 56; when interpreting a timestamp, one MUST 748 treat numbers in the range 57 to 63 identically to the number 56. 750 More rigorous semantics of precision indicators are out of scope of 751 OWDP, but may be negotiated out-of-band. 753 So, timestamp is represented as follows: 754 0 1 2 3 755 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 756 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 757 | Integer part of seconds | 758 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 759 | Fractional part of seconds |S|U| Prec | 760 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 761 where S is the synchronization bit, U is currently unused, and Prec 762 is the unsigned integer in the range from 0 to 56 discussed above. 764 Sequence numbers start with 0 and are incremented by 1 for each 765 subsequent packet. 767 The minimum data segment length is therefore 12 octets in 768 unauthenticated mode, 24 octets in authenticated mode, and 16 octets 769 in encrypted mode. 771 In authenticated and encrypted mode, the first block (16 octets) of 772 each packet is encrypted using AES ECB mode. 774 In unauthenticated mode, no encryption is applied. 776 The time elapsed between packets is pseudo-random, with exponential 777 distribution (resulting in a Poisson stream of packets). As 778 suggested in RFC 2330, the ith sampling interval Ei may be computed 779 using inverse transform: 781 Ei = -ln(Ui) * Inv-Lambda 783 where Ui is uniformly distributed between 0 and 1 and lambda is the 784 desired mean time between packets. 786 Pseudo-random stream of bits is obtained using AES with SID as the 787 key, running in counter mode (first encrypted block is 0, second 788 encrypted block is 1 in network octet order, etc.) Each block of 64 789 bits is used to obtain one pseudo-random number uniformly distributed 790 between 0 and 1. If the bits are Bj (j=1..64, numbered left to 791 right), the resulting value is 792 U = B1*2^{-1} + B2*2^{-2} + ... B64*2^{-64} 794 The parameter lambda is has the value requested in the Request- 795 Session message of the OWDP-Control negotiation that spawned the 796 session. 798 The logarithm and division in the formula above MUST be computed 799 using IEEE 754 standard floating point arithmetic. [HELP WANTED!: 800 Someone with a stronger background in numerical analysis to specify 801 how to compute the sampling intervals precisely and portably!] 803 Finally, Packet Padding SHOULD be pseudo-random (generated 804 independently of any other pseudo-random numbers mentioned in this 805 document). However, implementations MUST provide a configuration 806 parameter, an option, or a different means of making Packet Padding 807 consist of all zeros. 809 5.2. Receiver Behavior 811 Receiver knows when the sender will send packets. The following 812 parameter is defined: loss threshold. It SHOULD be 10 minutes and 813 MAY be more, but not more than 60 minutes. 815 As packets are received, 817 + Timestamp the received packet. 819 + In authenticated or encrypted mode, decrypt first block (16 820 octets) of packet body. 822 + Store the packet sequence number, send times, and receive times 823 for the results to be transferred. 825 + Packets not received within the loss threshold are considered 826 lost. They are recorded with their seqno, presumed send time, and 827 receive time consisting of a string of zero bits. 829 Packets that have send time in the future MUST be recorded normally, 830 without changing their send timestamp, unless they have to be 831 discarded. 833 If any of the following is true, packet MUST be discarded: 835 + Send timestamp is more than loss threshold in the past or in the 836 future. 838 + Send timestamp differs by more than loss threshold from the time 839 when the packet should have been sent according to its seqno. 841 + In authenticated or encrypted mode, any of the bits of zero 842 padding inside the first 16 octets of packet body is non-zero. 844 6. Security Considerations 846 The goal of authenticated mode to let one password-protect service 847 provided by a particular OWDP-Control server. One can imagine a 848 variety of circumstances where this could be useful. Authenticated 849 mode is designed to prohibit theft of service. 851 Additional design objective of authenticated mode was to make it 852 impossible for an attacker who cannot read traffic between OWDP-Test 853 sender and receiver to tamper with test results in a fashion that 854 affects the measurements, but not other traffic. 856 The goal of encrypted mode is quite different: To make it hard for a 857 party in the middle of the network to make results look "better" than 858 they should be. This is especially true if one of client and server 859 doesn't coincide with neither sender nor receiver. 861 Encryption of OWDP-Control using AES CBC mode with blocks of zeros 862 after each message aims to achieve two goals: (i) to provide secrecy 863 of exchange; (ii) to provide authentication of each message. 865 OWDP-Test sessions directed at an unsuspecting party could be used 866 for denial of service (DoS) attacks. In unauthenticated mode servers 867 should limits receivers to hosts they control or to the OWDP-Control 868 client. 870 OWDP-Test sessions could be used as covert channels of information. 871 Environments that are worried about covert channels should take this 872 into consideration. 874 Notice that AES in counter mode is used for pseudo-random number 875 generation, so implementation of AES MUST be included even in a 876 server that only supports unauthenticated mode. 878 7. References 880 [AES] Advanced Encryption Standard (AES), 881 http://csrc.nist.gov/encryption/aes/ 883 [RFC1305]D. Mills, "Network Time Protocol (Version 3) Specification, 884 Implementation and Analysis", RFC 1305, March 1992. 886 [RFC2026]S. Bradner, "The Internet Standards Process -- Revision 3", 887 RFC 2026, October 1996. 889 [RFC2119]S. Bradner, "Key words for use in RFCs to Indicate 890 Requirement Levels", RFC 2119, March 1997. 892 [RFC2330] V. Paxon, G. Almes, J. Mahdavi, M. Mathis, "Framework 893 for IP Performance Metrics" RFC 2330, May 1998. 895 [RFC2474] K. Nichols, S. Blake, F. Baker, D. Black, "Definition 896 of the Differentiated Services Field (DS Field) in the IPv4 and 897 IPv6 Headers", RFC 2474, December 1998. 899 [RFC2679]G. Almes, S. Kalidindi, and M. Zekauskas, "A One-way Delay 900 Metric for IPPM", RFC 2679, September 1999. 902 [RFC2680]G. Almes, S. Kalidindi, and M. Zekauskas, "A One-way Packet 903 Loss Metric for IPPM", RFC 2680, September 1999. 905 [RFC2836]S. Brim, B. Carpenter, F. Le Faucheur, "Per Hop Behavior 906 Identification Codes", RFC 2836, May 2000. 908 [RIPE] RIPE NCC Test-Traffic Measurements home, 909 http://www.ripe.net/test-traffic/. 911 [RIPE-NLUUG]H. Uijterwaal and O. Kolkman, "Internet Delay 912 Measurements Using Test-Traffic", Spring 1998 Dutch Unix User 913 Group Meeting, http://www.ripe.net/test- 914 traffic/Talks/9805_nluug.ps.gz. 916 [SURVEYOR] Surveyor Home Page, http://www.advanced.org/surveyor/. 918 [SURVEYOR-INET]S. Kalidindi and M. Zekauskas, "Surveyor: An 919 Infrastructure for Network Performance Measurements", 920 Proceedings of INET'99, June 1999. 921 http://www.isoc.org/inet99/proceedings/4h/4h_2.htm 923 8. Authors' Addresses 925 Stanislav Shalunov 926 Internet2 / UCAID 927 200 Business Park Drive 928 Armonk, NY 10504 929 USA 931 Phone: +1 914 765 1182 932 EMail: shalunov@internet2.edu 934 Benjamin Teitelbaum 935 Advanced Network & Services 936 200 Business Park Drive 937 Armonk, NY 10504 938 USA 940 Phone: +1 914 765 1118 941 EMail: ben@advanced.org 943 Matthew J. Zekauskas 944 Advanced Network & Services, Inc. 945 200 Business Park Drive 946 Armonk, NY 10504 947 USA 949 Phone: +1 914 765 1112 950 EMail: matt@advanced.org 952 Expiration date: April 2002