idnits 2.17.1 draft-ietf-ippm-owdp-reqs-06.txt: ** The Abstract section seems to be numbered 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. == 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 Introduction section. Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 (June 2003) is 7621 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: 'RFC 2680' is mentioned on line 49, but not defined ** Obsolete undefined reference: RFC 2680 (Obsoleted by RFC 7680) ** Downref: Normative reference to an Informational RFC: RFC 2330 ** Obsolete normative reference: RFC 2679 (Obsoleted by RFC 7679) ** Obsolete normative reference: RFC 2680 (Obsoleted by RFC 7680) ** Obsolete normative reference: RFC 2836 (Obsoleted by RFC 3140) Summary: 9 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Stanislav Shalunov 3 Internet Draft Benjamin Teitelbaum 4 Expiration Date: December 2003 Internet2 5 June 2003 7 A One-way Active Measurement Protocol Requirements 8 10 1. Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft shadow directories can be accessed at 29 http://www.ietf.org/shadow.html 31 This memo provides information for the Internet community. This memo 32 does not specify an Internet standard of any kind. Distribution of 33 this memo is unlimited. 35 2. Abstract 37 With growing availability of good time sources to network nodes, it 38 becomes increasingly possible to measure one-way IP performance 39 metrics with high precision. To do so in an interoperable manner, a 40 common protocol for such measurements is required. This document 41 specifies requirements for a one-way active measurement protocol 42 (OWAMP) standard. The protocol can measure one-way delay, as well as 43 other unidirectional characteristics, such as one-way loss. 45 3. Motivations and Goals 47 The IETF IP Performance Metrics (IPPM) working group has proposed 48 draft standard metrics for one-way packet delay [RFC2679] and loss 49 [RFC 2680] across Internet paths. Although there are now several 50 measurement platforms that implement the collection of these metrics 51 ([CQOS], [BRIX], [RIPE], [SURVEYOR]), there is not currently a 52 standard for interoperability. This requirements document is aimed 53 at defining a protocol that allows users to do measurements using 54 devices from different vendors at both ends and get meaningful 55 results. 57 With the increasingly wide availability of affordable global 58 positioning system (GPS) and CDMA based time sources, hosts 59 increasingly have available to them time sources that allow hosts to 60 time-stamp packets with accuracies substantially better than the 61 delays seen on the Internet--either directly or through their 62 proximity to NTP primary (stratum 1) time servers. By standardizing 63 a technique for collecting IPPM one-way active measurements, we hope 64 to create an environment where these metrics may be collected across 65 a far broader mesh of Internet paths than is currently possible. One 66 particularly compelling vision is of widespread deployment of open 67 one-way active measurement beacons that would make measurements of 68 one-way delay as commonplace as measurements of round-trip time are 69 today using ICMP-based tools like ping. Even without very accurate 70 timestamps one can measure characteristics such as loss with quality 71 acceptable for many practical purposes, e.g., network operations. 73 To support interoperability between alternative OWAMP implementations 74 and make possible a world where "one-way ping" could become 75 commonplace, a standard is required that specifies how test streams 76 are initiated, how test packets are exchanged, and how test results 77 are retrieved. Detailed functional requirements are given in the 78 subsequent section. 80 4. Functional Requirements 82 The protocol(s) should provide the ability to measure, record, and 83 distribute the results of measurements of one-way singleton network 84 characteristics such as characteristics defined in [RFC2679] and 85 [RFC2680]. Result reporting, sampling, and time stamps are to be 86 within the framework of [RFC2330]. 88 It should be possible to measure arbitrary one-way singleton 89 characteristics (e.g., loss, median delay, mean delay, jitter, 90th 90 percentile of delay, etc.); this is achieved by keeping all the raw 91 data for post-processing by the final data consumer, as specified in 92 section 4.1. Since RFC2679 and RFC2680 standardize metrics based on 93 Poisson sampling processes, Poisson streams must be supported by the 94 protocol(s). 96 Non-singleton characteristics (such as those related to trains of 97 packets, back-to-back tuples, and so forth) and application traffic 98 simulation need not be addressed. However, they may be addressed if 99 considered practical and not in contradiction to other design goals. 101 4.1. Keeping All Data for Post-processing 103 To facilitate the broadest possible use of obtained measurement 104 results, the protocol(s) should not necessitate any required post- 105 processing. (This does not apply to implementation details such as 106 converting timestamps from ticks since midnight into a canonical form 107 or applying calibration constants; such details should naturally be 108 hidden.) All data obtained during a measurement session should be 109 available after the session is finished if desired by the data 110 consumer so that various characteristics can be computed from the raw 111 data using arbitrary algorithms. 113 4.2. Result Distribution 115 A means to distribute measurement results (between hosts 116 participating in a measurement session and beyond) should be 117 provided. Since there can exist a wide variety of scenarios as to 118 where the final data destination should be, these should be invoked 119 separately from measurement requests (e.g., receiver should not have 120 to automatically send measurement results to the sender, since it may 121 be the receiver or a third host that are the ultimate data 122 destination). 124 At the same time, ability to transfer results directly to their 125 destination (without need for potentially large intermediate 126 transfers) should be provided. 128 4.3. Protocol Separation 130 Since measurement session setup and the actual measurement session 131 (i) are different tasks; (ii) require different levels of 132 functionality, flexibility, and implementation effort; (iii) may need 133 to run over different transport protocols, there should exist two 134 protocols: one for conducting the actual measurement session and 135 another for session setup/teardown/confirmation/retrieval. These 136 protocols are further referred to as OWAMP-Test and OWAMP-Control, 137 respectively. 139 It should be possible to use devices that only support OWAMP-Test but 140 not OWAMP-Control to conduct measurement sessions (such devices will 141 necessarily need to support one form of session setup protocol or the 142 other, but it doesn't have to be known to external parties). 144 OWAMP-Control would thus become a common protocol for different 145 administrative domains, which may or may not use it for session setup 146 internally. 148 4.4. Test Protocol 150 The test protocol needs to be implemented on all measurement nodes 151 and should therefore have the following characteristics: 153 + Be lightweight and easy to implement. 155 + Be suitable for implementation on a wide range of measurement 156 nodes. 158 + Allow UDP as the transport protocol, since the protocol needs to 159 be able to measure individual packet delivery times and has to run 160 on various machines (see the section "Support for Measurements 161 with Different Packet Types" below for further discussion). 163 + Support varying packet sizes and network services (e.g., DSCP 164 marking), as negotiated by OWAMP-Control. 166 + Be as simple as possible, but no simpler than necessary to 167 implement requirements set forth in this document; the OWAMP-Test 168 packet format should include only universally meaningful fields, 169 and minimum number of them. 171 + If practical, it should be possible to generate OWAMP-Test packets 172 small enough, so that when encapsulated, each fits inside a single 173 ATM cell. 175 + Data needed to calculate experimental errors on the final result 176 should be included in every OWAMP-Test packet. 178 4.5. Control Protocol 180 Control protocol needs to provide the capability to: 182 + authenticate peers to each other using a common authentication 183 method that doesn't require building any new authentication 184 infrastructure, such as user ID and a shared secret; 186 + schedule zero or more OWAMP-Test sessions (which do not have to be 187 between the peers of OWAMP-Control conversation); 189 + start OWAMP-Test sessions simultaneously or at a pre-scheduled 190 per-session times; 192 + retrieve OWAMP-Test session results (of OWAMP-Test sessions 193 scheduled in the current and other OWAMP-Control sessions); 195 + confirm graceful completion of sessions and allow either side to 196 abort a session prematurely. 198 The OWAMP-Control design should not preclude the ability to record 199 extended periods of losses. It should always provide peers with the 200 ability to distinguish between network and peer failures. 202 4.6. Support for Measurements with Different Packet Types 204 Since the notion of a packet of type P from [RFC2330], section 13 205 doesn't always imply precise definition of packet type, some 206 decisions narrowing the scope of possible packet types need to be 207 made at measurement protocol design stage. Further, measurement with 208 packets of certain types, while feasible in more closed settings than 209 those implied by OWAMP, become very hard to perform in an open inter- 210 domain fashion (e.g., measurements with particular packets with 211 broken IP checksum or particular loose source routing options). 213 In addition, very general packet type specification could result in 214 several problems: 216 + Many OWAMP-Test speakers will be general purpose computers with a 217 multitasking operating system that includes a socket interface. 218 These will inevitably have higher losses when listening to raw 219 network traffic. Raw sockets will induce higher loss rate than 220 one would have with UDP measurements. 222 + It's not at all clear (short of standardizing tcpdump syntax) how 223 to describe formally the filter that a receiver should use to 224 listen for test traffic. 226 + Suppose an identity of an authenticated user becomes compromised. 227 Now the attacker could use that to run TCP sessions to the rlogin 228 port of machines around servers that trust this user to perform 229 measurements (or, less drastically, to send spam from that 230 network). The ability to perform measurements is transformed into 231 an ability to generate arbitrary traffic on behalf of all the 232 senders an OWAMP-Control server controls. 234 + Carefully crafted packets could cause disruption to some link- 235 layer protocols. Implementors can't know what to disallow 236 (scrambling is different for different link-layer technologies). 238 It appears that allowing one to ask a measurement server to generate 239 arbitrary packets becomes an unmanageable security hole and a 240 formidable specification and implementation hurdle. 242 For these reasons, we only require OWAMP to support a small subspace 243 of the whole packet type space. Namely, it should be possible to 244 conduct measurements with a given Differentiated Services Codepoint 245 (DSCP) [RFC2474] or a given Per Hop Behavior Identification Code (PHB 246 ID) [RFC2836]. 248 5. Scalability 250 While some measurement architecture designs have inherent scalability 251 problems (e.g., a full mesh of always-on measurements among N 252 measurement nodes requires O(N^2) total resources, such as storage 253 space and link capacity), OWAMP itself should not exaggerate the 254 problem or make it impossible (where it is in principle possible) to 255 design other architectures that are free of scalability deficiencies. 257 It is the protocol user's responsibility to decide how to use the 258 protocol and which measurements to conduct. 260 6. Security Considerations 262 6.1. Authentication 264 It should be possible to authenticate peers to each other using a 265 user ID and a shared secret. It should be infeasible for any 266 external party without knowledge of the shared secret to obtain any 267 information about it by observing, initiating, or modifying protocol 268 transactions. 270 It should also be infeasible for such party to use any information 271 obtained by observing, modifying or initiating protocol transactions 272 to impersonate (other) valid users. 274 6.2. Authorization 276 Authorization shall normally be performed on the basis of the 277 authenticated identity (such as username) and the specification shall 278 require all implementations to support such a mode of authorization. 279 Different identities (or classes of identities) can have different 280 testing priviliges. The use of authorization for arriving at 281 specific policy decisions (such as whether to allow a specific test 282 with a specific source and destination and with a given test send 283 schedule -- which would determine the average network capacity 284 utilization -- at a given time) is up to the users. 286 6.3. Being Hard to Interfere with by Applying Special Treatment to 287 Measurement Packets 289 The design of the protocol should make it possible to run sessions 290 that would make it very difficult for any intermediate party to make 291 results appear better than they would be if no interference was 292 attempted. 294 This is different from cryptographic assurance of data integrity, 295 because one can manipulate the results without changing any data in 296 the packets. For example, if OWAMP-Test packets are easy to identify 297 (e.g., they all come to a well-known port number), an intermediate 298 party might place OWAMP-Test traffic into a priority queue at a 299 congested link thus ensuring that the results of the measurement 300 appear better than what would be experienced by other traffic. It 301 should not be easy for intermediate parties to identify OWAMP-Test 302 packets (just as it should not be easy for restaurants to identify 303 restaurant critics). 305 6.4. Secrecy/Confidentiality 307 It should be possible to make it infeasible for any outside party 308 without knowledge of the shared secret being used to learn what 309 information is exchanged using OWAMP-Control by inspecting an OWAMP- 310 Control stream or actively modifying it. 312 (It is recognized that some information will inevitably leak from the 313 mere fact of communication and from the presence and timing of 314 concurrent and subsequent OWAMP-Test traffic.) 316 6.5. Integrity 318 So that it is possible to detect any interference during a 319 conversation (other than the detention of some messages), facility 320 must be provided to authenticate each message of the OWAMP-Control 321 protocol, its attribution to a given session, and its exact placement 322 in the sequence of control protocol exchanges. 324 It must also be possible to authenticate each message of the test 325 protocol and its attribution to a specific session, so that 326 modifications of OWAMP-Test messages can be detected. It must be 327 possible to do this in a fashion that does not require timestamps 328 themselves to be encrypted; in this case, security properties are 329 valid only when an attacker cannot observe valid traffic between the 330 OWAMP-Test sender and receiver. 332 6.6. Replay Attacks 334 OWAMP-Control must be resistant to any replay attacks. 336 OWAMP-Test, on the other hand, is a protocol for network measurement. 337 One of the attributes of networks is packet duplication. OWAMP-Test 338 has to be suitable for measurement of duplication. This would make 339 it vulnerable to attacks that involve replaying a recent packet. For 340 the recipient of such a packet it is impossible to determine whether 341 the duplication is malicious or naturally occurring. 343 OWAMP-Test should measure all duplication -- malicious or otherwise. 344 Note that this is similar to delay attacks: an attacker can hold up a 345 packet for some short period of time and then release it to continue 346 on its way to the recipient. There's no way such delay can be 347 reliably distinguished from naturally occuring delay by the 348 recipient. 350 OWAMP-Test should measure the network as it was. Note, however, that 351 this does not prevent the data from being sanitized at a later stage 352 of processing, analysis, or consumption. Some sanity checks (those 353 that are deemed reliable and erring on the side of inclusion) should 354 be performed by OWAMP-Test recipient immediately. 356 6.7. Modes of Operation 358 Since the protocol(s) will be used in widely varying circumstances 359 using widely varying equipment, it is necessary be able to support 360 varying degrees of security modes of operation. The parameters to be 361 considered include: confidentiality, data origin authentication, 362 integrity and replay protection. 364 It should also be possible to operate in a mode where all security 365 mechanisms are enabled and security objectives are realized to the 366 fullest extent possible. We call this "encrypted mode". 368 Since timestamp encryption takes a certain amount of time, which may 369 be hard to predict on some devices (with a time-sharing OS), a mode 370 should be provided that is similar to encrypted mode, but in which 371 timestamps are not encrypted. In this mode, all security properties 372 of the encrypted mode that can be retained without timestamp 373 encryption should be present. We call this "authenticated mode". 375 It should be possible to operate in a completely "open" mode, where 376 no cryptographic security mechanisms are used. We call this 377 "unauthenticated mode". In this mode, mandatory-to-use mechanisms 378 must be specified that prevent the use of the protocol for network 379 capacity starvation denial-of-service attacks (e.g., only sending 380 test data back to the client that requested them to be sent with the 381 request delivered over a TCP connection). 383 To make implementation more manageable, the number of other options 384 and modes should be kept to the absolute practical minimum. Where 385 choosing a single mechanism for achieving anything related to 386 security is possible, such choice should be made at specification 387 phase and be put into the standard. 389 7. IANA Considerations 391 Relevant IANA considerations will be placed into the protocol 392 specification document itself, and not into the requirements 393 document. 395 8. Normative References 397 [RFC2330] V. Paxson, G. Almes, J. Mahdavi, M. Mathis, "Framework for 398 IP Performance Metrics", RFC 2330, May 1998. 400 [RFC2474] K. Nichols, S. Blake, F. Baker, D. Black, "Definition of 401 the Differentiated Services Field (DS Field) in the IPv4 and 402 IPv6 Headers", RFC 2474, December 1998. 404 [RFC2679] G. Almes, S. Kalidindi, and M. Zekauskas, "A One-way Delay 405 Metric for IPPM", RFC 2679, September 1999. 407 [RFC2680] G. Almes, S. Kalidindi, and M. Zekauskas, "A One-way Packet 408 Loss Metric for IPPM", RFC 2680, September 1999. 410 [RFC2836] S. Brim, B. Carpenter, F. Le Faucheur, "Per Hop Behavior 411 Identification Codes", RFC 2836, May 2000. 413 9. Informative References 415 [BRIX] Brix 1000 Verifier, 416 http://www.brixnet.com/products/brix1000.html 418 [CQOS] CQOS Home Page, http://www.cqos.com/ 420 [RIPE] RIPE NCC Test-Traffic Measurements home, 421 http://www.ripe.net/test-traffic/ 423 [SURVEYOR] Surveyor Home Page, http://www.advanced.org/surveyor/ 425 10. Authors' Addresses 427 Stanislav Shalunov 429 Benjamin Teitelbaum 431 Expiration date: December 2003