idnits 2.17.1 draft-ietf-ippm-owdp-reqs-02.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. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. 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 2002) is 7979 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 50, but not defined ** Obsolete undefined reference: RFC 2680 (Obsoleted by RFC 7680) -- Possible downref: Non-RFC (?) normative reference: ref. 'BRIX' -- Possible downref: Non-RFC (?) normative reference: ref. 'CQOS' ** 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'RIPE' -- Possible downref: Non-RFC (?) normative reference: ref. 'SURVEYOR' Summary: 10 errors (**), 0 flaws (~~), 2 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Stanislav Shalunov 3 Internet Draft Internet2 4 Expiration Date: December 2002 Benjamin Teitelbaum 5 Advanced Network & Services and Internet2 6 June 2002 8 A One-way Active Measurement Protocol Requirements 9 11 1. Status of this Memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft shadow directories can be accessed at 30 http://www.ietf.org/shadow.html 32 This memo provides information for the Internet community. This memo 33 does not specify an Internet standard of any kind. Distribution of 34 this memo is unlimited. 36 2. Abstract 38 With growing availability of good time sources to network nodes, it 39 becomes increasingly possible to measure one-way IP performance 40 metrics with high precision. To do so in an interoperable manner, a 41 common protocol for such measurements is required. This document 42 specifies requirements for a one-way active measurement protocol 43 (OWAMP) standard. The protocol can measure one-way delay, as well as 44 other unidirectional characteristics, such as one-way loss. 46 3. Motivations and Goals 48 The IETF IP Performance Metrics (IPPM) working group has proposed 49 draft standard metrics for one-way packet delay [RFC2679] and loss 50 [RFC 2680] across Internet paths. Although there are now several 51 measurement platforms that implement the collection of these metrics 52 ([CQOS], [BRIX], [RIPE], [SURVEYOR]), there is not currently a 53 standard for interoperability. This requirements document is aimed 54 at defining a protocol that allows users to do measurements using 55 devices from different vendors at both ends and get meaningful 56 results. 58 With the increasingly wide availability of affordable global 59 positioning system (GPS) and CDMA based time sources, hosts 60 increasingly have available to them time sources that allow hosts to 61 time-stamp packets with accuracies substantially better than the 62 delays seen on the Internet--either directly or through their 63 proximity to NTP primary (stratum 1) time servers. By standardizing 64 a technique for collecting IPPM one-way active measurements, we hope 65 to create an environment where these metrics may be collected across 66 a far broader mesh of Internet paths than is currently possible. One 67 particularly compelling vision is of widespread deployment of open 68 one-way active measurement beacons that would make measurements of 69 one-way delay as commonplace as measurements of round-trip time are 70 today using ICMP-based tools like ping. Even without very accurate 71 timestamps one can measure characteristics such as loss with quality 72 acceptable for many practical purposes, e.g., network operations. 74 To support interoperability between alternative OWAMP implementations 75 and make possible a world where "one-way ping" could become 76 commonplace, a standard is required that specifies how test streams 77 are initiated, how test packets are exchanged, and how test results 78 are retrieved. Detailed functional requirements are given in the 79 subsequent section. 81 4. Functional Requirements 83 The protocol(s) should provide the ability to measure, record, and 84 distribute the results of measurements of one-way singleton network 85 characteristics such as characteristics defined in [RFC2679] and 86 [RFC2680]. Result reporting, sampling, and time stamps are to be 87 within the framework of [RFC2330]. 89 It should be possible to measure arbitrary one-way singleton 90 characteristics (e.g., loss, median delay, mean delay, jitter, 90th 91 percentile of delay, etc.); this is achieved by keeping all the raw 92 data for post-processing by the final data consumer, as specified in 93 section 4.1. Since RFC2679 and RFC2680 standardize metrics based on 94 Poisson sampling processes, Poisson streams must be supported by the 95 protocol(s). 97 Non-singleton characteristics (such as those related to trains of 98 packets, back-to-back tuples, and so forth) and application traffic 99 simulation need not be addressed. However, they may be addressed if 100 considered practical and not in contradiction to other design goals. 102 4.1. Keeping All Data for Post-processing 104 To facilitate the broadest possible use of obtained measurement 105 results, the protocol(s) should not necessitate any required post- 106 processing. (This does not apply to implementation details such as 107 converting timestamps from ticks since midnight into a canonical form 108 or applying calibration constants; such details should naturally be 109 hidden.) All data obtained during a measurement session should be 110 available after the session is finished if desired by the data 111 consumer so that various characteristics can be computed from the raw 112 data using arbitrary algorithms. 114 4.2. Result Distribution 116 A means to distribute measurement results (between hosts 117 participating in a measurement session and beyond) should be 118 provided. Since there can exist a wide variety of scenarios as to 119 where the final data destination should be, these should be invoked 120 separately from measurement requests (e.g., receiver should not have 121 to automatically send measurement results to the sender, since it may 122 be the receiver or a third host that are the ultimate data 123 destination). 125 At the same time, ability to transfer results directly to their 126 destination (without need for potentially large intermediate 127 transfers) should be provided. 129 4.3. Protocol Separation 131 Since measurement session setup and the actual measurement session 132 (i) are different tasks; (ii) require different levels of 133 functionality, flexibility, and implementation effort; (iii) may need 134 to run over different transport protocols, there should exist two 135 protocols: one for conducting the actual measurement session and 136 another for session setup/teardown/confirmation/retrieval. These 137 protocols are further referred to as OWAMP-Test and OWAMP-Control, 138 respectively. 140 It should be possible to use devices that only support OWAMP-Test but 141 not OWAMP-Control to conduct measurement sessions (such devices will 142 necessarily need to support one form of session setup protocol or the 143 other, but it doesn't have to be known to external parties). 145 OWAMP-Control would thus become a common protocol for different 146 administrative domains, which may or may not use it for session setup 147 internally. 149 4.4. Test Protocol 151 The test protocol needs to be implemented on all measurement nodes 152 and should therefore have the following characteristics: 154 + Be lightweight and easy to implement. 156 + Be suitable for implementation on a wide range of measurement 157 nodes. 159 + Allow UDP as the transport protocol, since the protocol needs to 160 be able to measure individual packet delivery times and has to run 161 on various machines (see the section "Support for Measurements 162 with Different Packet Types" below for further discussion). 164 + Support varying packet sizes and network services (e.g., DSCP 165 marking), as negotiated by OWAMP-Control. 167 + Be as simple as possible, but no simpler than necessary to 168 implement requirements set forth in this document; the OWAMP-Test 169 packet format should include only universally meaningful fields, 170 and minimum number of them. 172 + If practical, it should be possible to generate OWAMP-Test packets 173 small enough, so that when encapsulated, each fits inside a single 174 ATM cell. 176 + Data needed to calculate experimental errors on the final result 177 should be included in every OWAMP-Test packet. 179 4.5. Control Protocol 181 Control protocol needs to provide the capability to: 183 + authenticate peers to each other using a common authentication 184 method that doesn't require building any new authentication 185 infrastructure, such as user ID and a shared secret; 187 + schedule zero or more OWAMP-Test sessions (which do not have to be 188 between the peers of OWAMP-Control conversation); 190 + start sessions simultaneously or at a pre-scheduled per-session 191 times; 193 + retrieve OWAMP-Test session results (of OWAMP-Test sessions 194 scheduled in the current and other OWAMP-Control sessions); 196 + confirm graceful completion of sessions and allow either side to 197 abort a session prematurely. 199 The OWAMP-Control design should not preclude the ability to record 200 extended periods of losses. It should always provide peers with the 201 ability to distinguish between network and peer failures. 203 4.6. Support for Measurements with Different Packet Types 205 Since the notion of a packet of type P from [RFC2330], section 13 206 doesn't always imply precise definition of packet type, some 207 decisions narrowing the scope of possible packet types need to be 208 made at measurement protocol design stage. Further, measurement with 209 packets of certain types, while feasible in more closed settings than 210 those implied by OWAMP, become very hard to perform in an open inter- 211 domain fashion (e.g., measurements with particular packets with 212 broken IP checksum or particular loose source routing options). 214 In addition, very general packet type specification could result in 215 several problems: 217 + Many OWAMP-Test speakers will be general purpose computers with a 218 multitasking operating system that includes a socket interface. 219 These will inevitably have higher losses when listening to raw 220 network traffic. Raw sockets will induce higher loss rate than 221 one would have with UDP measurements. 223 + It's not at all clear (short of standardizing tcpdump syntax) how 224 to describe formally the filter that a receiver should use to 225 listen for test traffic. 227 + Suppose an identity of an authenticated user becomes compromised. 228 Now the attacker could use that to run TCP sessions to the rlogin 229 port of machines around servers that trust this user to perform 230 measurements (or, less drastically, to send spam from that 231 network). The ability to perform measurements is transformed into 232 an ability to generate arbitrary traffic on behalf of all the 233 senders an OWAMP-Control server controls. 235 + Carefully crafted packets could cause disruption to some link- 236 layer protocols. Implementors can't know what to disallow 237 (scrambling is different for different link-layer technologies). 239 It appears that allowing one to ask a measurement server to generate 240 arbitrary packets becomes an unmanageable security hole and a 241 formidable specification and implementation hurdle. 243 For these reasons, we only require OWAMP to support a small subspace 244 of the whole packet type space. Namely, it should be possible to 245 conduct measurements with a given Differentiated Services Codepoint 246 (DSCP) [RFC2474] or a given Per Hop Behavior Identification Code (PHB 247 ID) [RFC2836]. 249 5. Scalability 251 While some measurement architecture designs have inherent scalability 252 problems (e.g., a full mesh of always-on measurements among N 253 measurement nodes requires O(N^2) total resources, such as storage 254 space and link capacity), OWAMP itself should not exaggerate the 255 problem or make it impossible (where it is in principle possible) to 256 design other architectures that are free of scalability deficiencies. 258 It is the protocol user's responsibility to decide how to use the 259 protocol and which measurements to conduct. 261 6. Security Considerations 263 6.1. Modes of Operation 265 Since the protocol(s) will be used in widely varying circumstances 266 using widely varying equipment, it is necessary be able to support 267 varying degrees of security modes of operation. The parameters to be 268 considered include: confidentiality, data origin authentication, 269 integrity and replay protection. 271 It should be possible to operate in a completely "open" mode, where 272 no cryptographic security mechanisms are used. We call this 273 "unauthenticated mode". In this mode, care must be taken to avoid 274 denial-of-service attacks. 276 It should also be possible to operate in a mode where all security 277 mechanisms are enabled and security objectives are realized to the 278 fullest extent possible. We call this "encrypted mode". 280 Since timestamp encryption takes a certain amount of time, which may 281 be hard to predict on some devices (with a time-sharing OS), a mode 282 should be provided that is similar to encrypted mode, but in which 283 timestamps are not encrypted. In this mode, all security properties 284 of the encrypted mode that can be retained without timestamp 285 encryption should be present. We call this "authenticated mode". 287 To make implementation more manageable, the number of other options 288 and modes should be kept to the absolute practical minimum. Where 289 choosing a single mechanism for achieving anything related to 290 security is possible, such choice should be made at specification 291 phase and be put into the standard. 293 6.2. Being Hard to Interfere with by Applying Special Treatment to 294 Measurement Packets 296 The design of the protocol should make it possible to run sessions 297 that would make it very difficult for any intermediate party to make 298 results appear better than they would be if no interference was 299 attempted. 301 This is different from cryptographic assurance of data integrity, 302 because one can manipulate the results without changing any data in 303 the packets. For example, if OWAMP-Test packets are easy to identify 304 (e.g., they all come to a well-known port number), an intermediate 305 party might place OWAMP-Test traffic into a priority queue at a 306 congested link thus ensuring that the results of the measurement 307 appear better than what would be experienced by other traffic. It 308 should not be easy for intermediate parties to identify OWAMP-Test 309 packets (just as it should not be easy for restaurants to identify 310 restaurant critics). 312 6.3. Secrecy/Confidentiality 314 It should be possible to make it infeasible for any outside party 315 without knowledge of the shared secret being used to learn what 316 information is exchanged using OWAMP-Control by inspecting an OWAMP- 317 Control stream or actively modifying it. 319 (It is recognized that some information will inevitably leak from the 320 mere fact of communication and from the presence and timing of 321 concurrent and subsequent OWAMP-Test traffic.) 323 6.4. Authentication 325 It should be possible to authenticate peers to each other using a 326 user ID and a shared secret. It should be infeasible for any 327 external party without knowledge of the shared secret to obtain any 328 information about it by observing, initiating, or modifying protocol 329 transactions. 331 It should also be infeasible for such party to use any information 332 obtained by observing, modifying or initiating protocol transactions 333 to impersonate (other) valid users. 335 6.5. Integrity 337 So that it is possible to detect any interference during a 338 conversation (other than the detention of some messages), facility 339 must be provided to authenticate each message of the control 340 protocol, its attribution to a given session, and its exact placement 341 in the sequence of control protocol exchanges. 343 It must also be possible to authenticate each message of the test 344 protocol and its attribution to a specific session, so that 345 modifications of OWAMP-Test messages can be detected. It must be 346 possible to do this in a fashion that does not require timestamps 347 themselves to be encrypted; in this case, security properties are 348 valid only when an attacker cannot observe valid traffic between the 349 OWAMP-Test sender and receiver. 351 7. IANA Considerations 353 Relevant IANA considerations will be placed into the protocol 354 specification document itself, and not into the requirements 355 document. 357 8. References 359 [BRIX] Brix 1000 Verifier, 360 http://www.brixnet.com/products/brix1000.html 362 [CQOS] CQOS Home Page, http://www.cqos.com/ 364 [RFC2330] V. Paxson, G. Almes, J. Mahdavi, M. Mathis, "Framework for 365 IP Performance Metrics", RFC 2330, May 1998. 367 [RFC2474] K. Nichols, S. Blake, F. Baker, D. Black, "Definition of 368 the Differentiated Services Field (DS Field) in the IPv4 and 369 IPv6 Headers", RFC 2474, December 1998. 371 [RFC2679] G. Almes, S. Kalidindi, and M. Zekauskas, "A One-way Delay 372 Metric for IPPM", RFC 2679, September 1999. 374 [RFC2680] G. Almes, S. Kalidindi, and M. Zekauskas, "A One-way Packet 375 Loss Metric for IPPM", RFC 2680, September 1999. 377 [RFC2836] S. Brim, B. Carpenter, F. Le Faucheur, "Per Hop Behavior 378 Identification Codes", RFC 2836, May 2000. 380 [RIPE] RIPE NCC Test-Traffic Measurements home, 381 http://www.ripe.net/test-traffic/ 383 [SURVEYOR] Surveyor Home Page, http://www.advanced.org/surveyor/ 385 9. Authors' Addresses 387 Stanislav Shalunov 388 Internet2 389 200 Business Park Drive, Suite 307 390 Armonk, NY 10504 391 USA 393 Phone: +1 914 765 1182 394 EMail: shalunov@internet2.edu 395 Benjamin Teitelbaum 396 Advanced Network & Services 397 200 Business Park Drive, Suite 307 398 Armonk, NY 10504 399 USA 401 Phone: +1 914 765 1118 402 EMail: ben@advanced.org 404 Expiration date: December 2002