--- 1/draft-ietf-ippm-owdp-reqs-01.txt 2006-02-04 23:46:06.000000000 +0100 +++ 2/draft-ietf-ippm-owdp-reqs-02.txt 2006-02-04 23:46:06.000000000 +0100 @@ -1,19 +1,19 @@ -Network Working Group S. Shalunov +Network Working Group Stanislav Shalunov -Expiration Date: April 2002 B. Teitelbaum +Expiration Date: December 2002 Benjamin Teitelbaum Advanced Network & Services and Internet2 - November 2001 + June 2002 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. @@ -61,22 +61,22 @@ 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. + timestamps one can measure characteristics such as loss with quality + acceptable for many practical purposes, e.g., network operations. 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 @@ -100,23 +100,23 @@ 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. (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. + available after the session 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 @@ -124,68 +124,73 @@ 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 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. + to run over different transport protocols, there should exist two + protocols: one for conducting the actual measurement session and + another for session setup/teardown/confirmation/retrieval. These + protocols are further referred to as OWAMP-Test and OWAMP-Control, + respectively. 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). OWAMP-Control would thus become a common protocol for different - domains, which may or may not use it for session setup internally. + administrative 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. + 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. + on various machines (see the section "Support for Measurements + with Different Packet Types" below for further discussion). + Support varying packet sizes and network services (e.g., DSCP marking), as negotiated by OWAMP-Control. - + Be as simple as possible, but no simpler; the OWAMP-Test packet - format should include only universally meaningful fields, and - minimum number of them. + + Be as simple as possible, but no simpler than necessary to + implement requirements set forth in this document; the OWAMP-Test + packet format should include only universally meaningful fields, + and minimum number of them. - + It should be possible to generate OWAMP-Test packets small enough, - so that when encapsulated, each fits inside a single ATM cell. + + If practical, 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. + should be included in every OWAMP-Test packet. 4.5. Control Protocol 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 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 OWAMP-Test session results (of OWAMP-Test sessions scheduled in the current and other OWAMP-Control sessions); + confirm graceful completion of sessions and allow either side to @@ -202,24 +207,25 @@ 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. + + Many OWAMP-Test speakers will be general purpose computers with a + multitasking operating system that includes a socket interface. + 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 @@ -250,52 +256,66 @@ 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. 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. + using widely varying equipment, it is necessary be able to support + varying degrees of security modes of operation. The parameters to be + considered include: confidentiality, data origin authentication, + integrity and replay protection. It should be possible to operate in a completely "open" mode, where - no security mechanisms are used. We call this "unauthenticated - mode". + no cryptographic security mechanisms are used. We call this + "unauthenticated mode". In this mode, care must be taken to avoid + denial-of-service attacks. 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. + encryption should be present. We call this "authenticated mode". 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. + This is different from cryptographic assurance of data integrity, + because one can manipulate the results without changing any data in + the packets. For example, if OWAMP-Test packets are easy to identify + (e.g., they all come to a well-known port number), an intermediate + party might place OWAMP-Test traffic into a priority queue at a + congested link thus ensuring that the results of the measurement + appear better than what would be experienced by other traffic. It + should not be easy for intermediate parties to identify OWAMP-Test + packets (just as it should not be easy for restaurants to identify + restaurant critics). + 6.3. Secrecy/Confidentiality It should be possible to make it infeasible for any outside party 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 the presence and timing of concurrent and subsequent OWAMP-Test traffic.) @@ -365,21 +385,20 @@ 9. Authors' Addresses Stanislav Shalunov Internet2 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, Suite 307 Armonk, NY 10504 USA Phone: +1 914 765 1118 EMail: ben@advanced.org - Expiration date: April 2002 + Expiration date: December 2002