--- 1/draft-ietf-ippm-owdp-reqs-00.txt 2006-02-04 23:46:05.000000000 +0100 +++ 2/draft-ietf-ippm-owdp-reqs-01.txt 2006-02-04 23:46:05.000000000 +0100 @@ -1,19 +1,19 @@ Network Working Group S. Shalunov -Expiration Date: January 2002 B. Teitelbaum +Expiration Date: April 2002 B. Teitelbaum Advanced Network & Services and Internet2 - July 2001 + November 2001 A One-way Active Measurement Protocol Requirements - + 1. Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. @@ -34,76 +34,89 @@ this memo is unlimited. 2. Abstract With growing availability of good time sources to network nodes, it becomes increasingly possible to measure one-way IP performance metrics with high precision. To do so in an interoperable manner, a common protocol for such measurements is required. This document specifies requirements for a one-way active measurement protocol (OWAMP) standard. The protocol can measure one-way delay, as well as - unidirectional characteristics such as one-way loss and others. + other unidirectional characteristics, such as one-way loss. 3. Motivations and Goals The IETF IP Performance Metrics (IPPM) working group has proposed draft standard metrics for one-way packet delay [RFC2679] and loss [RFC 2680] across Internet paths. Although there are now several measurement platforms that implement the collection of these metrics ([CQOS], [BRIX], [RIPE], [SURVEYOR]), there is not currently a - standard for interoperability. + standard for interoperability. This requirements document is aimed + at defining a protocol that allows users to do measurements using + devices from different vendors at both ends and get meaningful + results. With the increasingly wide availability of affordable global positioning system (GPS) and CDMA based time sources, hosts - increasingly have available to them very accurate time - sources--either directly or through their proximity to NTP primary - (stratum 1) time servers. By standardizing a technique for - collecting IPPM one-way active measurements, we hope to create an - environment where these metrics may be collected across a far broader - mesh of Internet paths than is currently possible. One particularly - compelling vision is of widespread deployment of open one-way active - measurement beacons that would make measurements of one-way delay as - commonplace as measurements of round-trip time are today using ICMP- - based tools like ping. + increasingly have available to them time sources that allow hosts to + time-stamp packets with accuracies substantially better than the + delays seen on the Internet--either directly or through their + proximity to NTP primary (stratum 1) time servers. By standardizing + a technique for collecting IPPM one-way active measurements, we hope + to create an environment where these metrics may be collected across + a far broader mesh of Internet paths than is currently possible. One + particularly compelling vision is of widespread deployment of open + one-way active measurement beacons that would make measurements of + one-way delay as commonplace as measurements of round-trip time are + today using ICMP-based tools like ping. Even without very accurate + timestamps one can measure characteristics such as, e.g., loss with + acceptable for many practical purposes quality. - To support interoperability between alternative OWDP implementations + To support interoperability between alternative OWAMP implementations and make possible a world where "one-way ping" could become commonplace, a standard is required that specifies how test streams are initiated, how test packets are exchanged, and how test results are retrieved. Detailed functional requirements are given in the subsequent section. 4. Functional Requirements - The protocol(s) should provide ability to measure, record, and + The protocol(s) should provide the ability to measure, record, and distribute the results of measurements of one-way singleton network characteristics such as characteristics defined in [RFC2679] and - [RFC2680]. + [RFC2680]. Result reporting, sampling, and time stamps are to be + within the framework of [RFC2330]. It should be possible to measure arbitrary one-way singleton - characteristics (e.g., loss, average delay, mean delay, jitter, 90th - percentile of delay, etc.). Since RFC2679 and RFC2680 standardize on - Poisson streams of test packets, Poisson streams at least should be - supported. + characteristics (e.g., loss, median delay, mean delay, jitter, 90th + percentile of delay, etc.); this is achieved by keeping all the raw + data for post-processing by the final data consumer, as specified in + section 4.1. Since RFC2679 and RFC2680 standardize metrics based on + Poisson sampling processes, Poisson streams must be supported by the + protocol(s). Non-singleton characteristics (such as those related to trains of packets, back-to-back tuples, and so forth) and application traffic - simulation aren't areas that the protocol(s) need to address. + simulation need not be addressed. However, they may be addressed if + considered practical and not in contradiction to other design goals. 4.1. Keeping All Data for Post-processing To facilitate the broadest possible use of obtained measurement results, the protocol(s) should not necessitate any required post- - processing. All data obtained during a measurement session should be - available after it is finished if desired by endpoint so that various - characteristics can be computed from the raw data using arbitrary - algorithms. + processing. (This does not apply to implementation details such as + converting timestamps from ticks since midnight into a canonical form + or applying calibration constants; such details should naturally be + hidden.) All data obtained during a measurement session should be + available after it is finished if desired by the data consumer so + that various characteristics can be computed from the raw data using + arbitrary algorithms. 4.2. Result Distribution A means to distribute measurement results (between hosts participating in a measurement session and beyond) should be provided. Since there can exist a wide variety of scenarios as to where the final data destination should be, these should be invoked separately from measurement requests (e.g., receiver should not have to automatically send measurement results to the sender, since it may be the receiver or a third host that are the ultimate data @@ -111,194 +124,262 @@ At the same time, ability to transfer results directly to their destination (without need for potentially large intermediate transfers) should be provided. 4.3. Protocol Separation Since measurement session setup and the actual measurement session (i) are different tasks; (ii) require different levels of functionality, flexibility, and implementation effort; (iii) may need - to run over different transport protocols, there should exist - different protocols for conducting the actual measurement session on - one side and for session setup/teardown/confirmation/retrieval on the - other. These protocols are further referred to as OWDP-Test and - OWDP-Control, respectively. + to run over different transport protocols, there should exist a + protocol for conducting the actual measurement session on one side + and a protocol for session setup/teardown/confirmation/retrieval on + the other. These protocols are further referred to as OWAMP-Test and + OWAMP-Control, respectively. - It should be possible to use devices that only support OWDP-Test but - not OWDP-Control to conduct measurement sessions (such devices will + It should be possible to use devices that only support OWAMP-Test but + not OWAMP-Control to conduct measurement sessions (such devices will necessarily need to support one form of session setup protocol or the other, but it doesn't have to be known to external parties). - OWDP-Control would thus become a common protocol for different + OWAMP-Control would thus become a common protocol for different domains, which may or may not use it for session setup internally. 4.4. Test Protocol The test protocol needs to be implemented on all measurement nodes and should therefore have the following characteristics: + Be lightweight and easy to implement. + Be suitable for implementation on a wide range of measurement nodes. - + Since the protocol needs to be able to measure individual packet - delivery time and has to run on various machines, it needs to - support UDP as transport protocol. + + Allow UDP as the transport protocol, since the protocol needs to + be able to measure individual packet delivery times and has to run + on various machines. - + It should be possible to use varying packet sizes and network - services, as negotiated using OWDP-Control. + + Support varying packet sizes and network services (e.g., DSCP + marking), as negotiated by OWAMP-Control. - + To be a lowest common denominator, OWDP-Test packet format should - only include universally meaningful fields, and minimum number of - them. + + Be as simple as possible, but no simpler; the OWAMP-Test packet + format should include only universally meaningful fields, and + minimum number of them. - + It should be possible to make packets generated by OWDP-Test as - small as possible, to be able to accurately measure paths where - packet-splitting technologies such as ATM are used. + + It should be possible to generate OWAMP-Test packets small enough, + so that when encapsulated, each fits inside a single ATM cell. + + + Data needed to calculate experimental errors on the final result + should be included in the packets. 4.5. Control Protocol - Control protocol needs to provide abilities to: + Control protocol needs to provide the capability to: + authenticate peers to each other using a common authentication method that doesn't require building any new authentication infrastructure, such as user ID and a shared secret; - - + schedule zero or more OWDP-Test sessions (which do not have to be - between the peers of OWDP-Control conversation); + + schedule zero or more OWAMP-Test sessions (which do not have to be + between the peers of OWAMP-Control conversation); + start sessions simultaneously or at a pre-scheduled per-session times; - + retrieve OWDP-Test session results (of OWDP-Test sessions - scheduled in the current and other OWDP-Control sessions); + + retrieve OWAMP-Test session results (of OWAMP-Test sessions + scheduled in the current and other OWAMP-Control sessions); - + confirm graceful completion of session or abort them prematurely - (for both sides). + + confirm graceful completion of sessions and allow either side to + abort a session prematurely. - The OWDP-Control design should not preclude the ability to record - extended periods of losses. It should provide peers with the ability - to always distinguish between network and peer failures. + The OWAMP-Control design should not preclude the ability to record + extended periods of losses. It should always provide peers with the + ability to distinguish between network and peer failures. + +4.6. Support for Measurements with Different Packet Types + + Since the notion of a packet of type P from [RFC2330], section 13 + doesn't always imply precise definition of packet type, some + decisions narrowing the scope of possible packet types need to be + made at measurement protocol design stage. Further, measurement with + packets of certain types, while feasible in more closed settings than + those implied by OWAMP, become very hard to perform in an open inter- + domain fashion (e.g., measurements with particular packets with + broken IP checksum or particular loose source routing options). + + In addition, very general packet type specification could result in + several problems: + + + Many OWAMP-Test speakers will be Unix or other general purpose + computers. These will inevitably have higher losses when + listening to raw network traffic. Raw sockets will induce higher + loss rate than one would have with UDP measurements. + + + It's not at all clear (short of standardizing tcpdump syntax) how + to describe formally the filter that a receiver should use to + listen for test traffic. + + + Suppose an identity of an authenticated user becomes compromised. + Now the attacker could use that to run TCP sessions to the rlogin + port of machines around servers that trust this user to perform + measurements (or, less drastically, to send spam from that + network). The ability to perform measurements is transformed into + an ability to generate arbitrary traffic on behalf of all the + senders an OWAMP-Control server controls. + + + Carefully crafted packets could cause disruption to some link- + layer protocols. Implementors can't know what to disallow + (scrambling is different for different link-layer technologies). + + It appears that allowing one to ask a measurement server to generate + arbitrary packets becomes an unmanageable security hole and a + formidable specification and implementation hurdle. + + For these reasons, we only require OWAMP to support a small subspace + of the whole packet type space. Namely, it should be possible to + conduct measurements with a given Differentiated Services Codepoint + (DSCP) [RFC2474] or a given Per Hop Behavior Identification Code (PHB + ID) [RFC2836]. 5. Scalability While some measurement architecture designs have inherent scalability problems (e.g., a full mesh of always-on measurements among N measurement nodes requires O(N^2) total resources, such as storage - space and link capacity), OWDP itself should not exaggerate the + space and link capacity), OWAMP itself should not exaggerate the problem or make it impossible (where it is in principle possible) to design other architectures that are free of scalability deficiencies. + It is the protocol user's responsibility to decide how to use the + protocol and which measurements to conduct. + 6. Security Considerations -6.1. Being Hard to Detect +6.1. Modes of Operation + + Since the protocol(s) will be used in widely varying circumstances + using widely varying equipment, it is necessary to have more than one + mode of operation security-wise. + + It should be possible to operate in a completely "open" mode, where + no security mechanisms are used. We call this "unauthenticated + mode". + + It should also be possible to operate in a mode where all security + mechanisms are enabled and security objectives are realized to the + fullest extent possible. We call this "encrypted mode". + + Since timestamp encryption takes a certain amount of time, which may + be hard to predict on some devices (with a time-sharing OS), a mode + should be provided that is similar to encrypted mode, but in which + timestamps are not encrypted. In this mode, all security properties + of the encrypted mode that can be retained without timestamp + encryption should be present. + + To make implementation more manageable, the number of other options + and modes should be kept to the absolute practical minimum. Where + choosing a single mechanism for achieving anything related to + security is possible, such choice should be made at specification + phase and be put into the standard. + +6.2. Being Hard to Interfere with by Applying Special Treatment to + Measurement Packets The design of the protocol should make it possible to run sessions that would make it very difficult for any intermediate party to make results appear better than they would be if no interference was attempted. -6.2. Secrecy/Confidentiality +6.3. Secrecy/Confidentiality It should be possible to make it infeasible for any outside party - without knowledge of shared secret being used to learn what - information is exchanged using OWDP-Control by inspecting OWDP- - Control stream or by actively modifying it. + without knowledge of the shared secret being used to learn what + information is exchanged using OWAMP-Control by inspecting an OWAMP- + Control stream or actively modifying it. (It is recognized that some information will inevitably leak from the - mere fact of communication and from presence and timing of concurrent - and subsequent OWDP-Test traffic.) + mere fact of communication and from the presence and timing of + concurrent and subsequent OWAMP-Test traffic.) -6.3. Authentication +6.4. Authentication It should be possible to authenticate peers to each other using a user ID and a shared secret. It should be infeasible for any external party without knowledge of the shared secret to obtain any information about it by observing, initiating, or modifying protocol transactions. It should also be infeasible for such party to use any information obtained by observing, modifying or initiating protocol transactions to impersonate (other) valid users. -6.4. Integrity - - Facility to authenticate each message of the control protocol and - their exact sequence and attribution to a given session has to be - provided, so that any interference during a conversation (other than - detention of some messages) can be detected. - - Facility to authenticate each message of the test protocol and its - attribution to a specific session has to be provided, so that - modifications of OWDP-Test messages can be detected. - - Facility to do the latter in such a way that timestamps themselves - aren't encrypted and security properties are only valid for an - attacker that cannot observe valid traffic between OWDP-Test sender - and receiver has to be provided. - -6.5. Modes of Operation - - Since the protocol(s) will be used in widely varying circumstances - using widely varying equipment, it is necessary to have more than one - mode of operation security-wise. - - A mode that is completely "open" (an unauthenticated mode) should be - provided, where no security mechanisms are used. +6.5. Integrity - A mode where all security mechanisms are enabled and security - objectives are realized to fullest extent possible (an encrypted - mode) should be provided. + So that it is possible to detect any interference during a + conversation (other than the detention of some messages), facility + must be provided to authenticate each message of the control + protocol, its attribution to a given session, and its exact placement + in the sequence of control protocol exchanges. - Since timestamp encryption takes certain time, which may be hard to - predict on some devices (with a time-sharing OS), a mode similar to - encrypted mode, but where timestamps aren't encrypted, should be - provided. In said mode, all security properties of encrypted mode - that can be retained without timestamp encryption should be present. + It must also be possible to authenticate each message of the test + protocol and its attribution to a specific session, so that + modifications of OWAMP-Test messages can be detected. It must be + possible to do this in a fashion that does not require timestamps + themselves to be encrypted; in this case, security properties are + valid only when an attacker cannot observe valid traffic between the + OWAMP-Test sender and receiver. 7. IANA Considerations Relevant IANA considerations will be placed into the protocol specification document itself, and not into the requirements document. 8. References [BRIX] Brix 1000 Verifier, http://www.brixnet.com/products/brix1000.html [CQOS] CQOS Home Page, http://www.cqos.com/ + [RFC2330] V. Paxson, G. Almes, J. Mahdavi, M. Mathis, "Framework for + IP Performance Metrics", RFC 2330, May 1998. + + [RFC2474] K. Nichols, S. Blake, F. Baker, D. Black, "Definition of + the Differentiated Services Field (DS Field) in the IPv4 and + IPv6 Headers", RFC 2474, December 1998. + [RFC2679] G. Almes, S. Kalidindi, and M. Zekauskas, "A One-way Delay Metric for IPPM", RFC 2679, September 1999. [RFC2680] G. Almes, S. Kalidindi, and M. Zekauskas, "A One-way Packet Loss Metric for IPPM", RFC 2680, September 1999. + [RFC2836] S. Brim, B. Carpenter, F. Le Faucheur, "Per Hop Behavior + Identification Codes", RFC 2836, May 2000. + [RIPE] RIPE NCC Test-Traffic Measurements home, http://www.ripe.net/test-traffic/ [SURVEYOR] Surveyor Home Page, http://www.advanced.org/surveyor/ 9. Authors' Addresses Stanislav Shalunov Internet2 - 200 Business Park Drive + 200 Business Park Drive, Suite 307 Armonk, NY 10504 USA Phone: +1 914 765 1182 EMail: shalunov@internet2.edu Benjamin Teitelbaum Advanced Network & Services - 200 Business Park Drive + 200 Business Park Drive, Suite 307 Armonk, NY 10504 USA Phone: +1 914 765 1118 EMail: ben@advanced.org - Expiration date: January 2002 + Expiration date: April 2002