RFC 3763

One-way Active Measurement Protocol (OWAMP) Requirements

📅 published April 2004, from ietf

RFC 3763: One-way Active Measurement Protocol (OWAMP) Requirements 💖

okay bestie, this is the RFC that kicks off the whole OWAMP era 🦋 It's Request for Comments: 3763 from the Network Working Group, written by S. Shalunov and B. Teitelbaum at Internet2 ✨ Its category is Informational 🎀 and the date is April 2004 🌸 The header doesn't list anything it obsoletes or updates 🫶

Status of This Memo 📜

This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.

Copyright (C) The Internet Society (2004). All Rights Reserved.

Abstract 🦋

With good time sources getting easier for network nodes to reach, it's becoming way more possible to measure one-way IP performance metrics with high precision 🕰️ To do that in an interoperable way, a common protocol for these measurements is required. This document specifies requirements for a one-way active measurement protocol (OWAMP) standard. The protocol can measure one-way delay, plus other unidirectional characteristics like one-way loss 💅

1. Motivations and Goals ✨

okay so the IETF IP Performance Metrics (IPPM) working group has proposed standards track metrics for one-way packet delay [RFC2679] and loss [RFC 2680] across Internet paths. There are now several measurement platforms that collect these metrics ([CQOS], [BRIX], [RIPE], [SURVEYOR]), but there is not currently a standard for interoperability 😭 This requirements document is aimed at defining a protocol that lets users do measurements using devices from different vendors at both ends and still get meaningful results 💜

With GPS and CDMA based time sources getting more affordable and available, hosts increasingly have access to time sources that let them 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 can be collected across a far broader mesh of Internet paths than is currently possible 🌐 One especially compelling vision is widespread deployment of open one-way active measurement beacons, which would make measurements of one-way delay as commonplace as round-trip time measurements are today with ICMP-based tools like ping 🏓 Even without very accurate timestamps, you can measure things like loss with quality that's acceptable for many practical purposes, e.g., network operations 🍓

To support interoperability between alternative OWAMP implementations and make a world where "one-way ping" could become commonplace possible, 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 👑

2. Functional Requirements 🎀

The protocol(s) should provide the ability to measure, record, and distribute the results of measurements of one-way singleton network characteristics, such as the characteristics defined in [RFC2679] and [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, 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 2.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 need not be addressed. However, they may be addressed if considered practical and not in contradiction to other design goals 🦋

2.1. Keeping All Data for Post-processing 🧹

To make the broadest possible use of 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 the session is finished, if the data consumer wants it, so that various characteristics can be computed from the raw data using arbitrary algorithms 💅

2.2. Result Distribution 📬

A means to distribute measurement results (between hosts participating in a measurement session and beyond) should be provided. Since there can be a wide variety of scenarios for where the final data destination is, these should be invoked separately from measurement requests. For example, the receiver should not have to automatically send measurement results to the sender, since it may be the receiver or a third host that is the ultimate data destination 🫶

At the same time, the ability to transfer results directly to their destination, without the need for potentially large intermediate transfers, should be provided ✨

2.3. Protocol Separation ✂️

Measurement session setup and the actual measurement session (i) are different tasks; (ii) require different levels of functionality, flexibility, and implementation effort; and (iii) may need to run over different transport protocols. So 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 administrative domains, which may or may not use it for session setup internally 🌸

2.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 (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).
  • 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 a minimum number of them.
  • If practical, it should be possible to generate OWAMP-Test packets small enough that, when encapsulated, each fits inside a single ATM cell.
  • Data needed to calculate experimental errors on the final result should be included in every OWAMP-Test packet.

2.5. Control Protocol 🎛️

The 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 the OWAMP-Control conversation);
  • start OWAMP-Test sessions simultaneously or at 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 abort a session prematurely.

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 🔍

2.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 a precise definition of packet type, some decisions narrowing the scope of possible packet types need to be made at the measurement protocol design stage. Further, measurements 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, a very general packet type specification could result in several problems:

  • 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 a higher loss rate than one would have with UDP measurements.
  • It's not at all clear (short of standardizing tcpdump syntax) how to formally describe the filter that a receiver should use to listen for test traffic.
  • Suppose the 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. this one is a whole horror movie 💀
  • Carefully crafted packets could cause disruption to some link-layer protocols. Implementors can't know what to disallow, since 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) [RFC3140] 🎀

3. 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), 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 💅

4. Security Considerations 🔐

4.1. Authentication 🔐

okay so peers should be able to prove who they are to each other using a user ID and a shared secret, bestie 🗝️ and an outside party with no clue what the secret is should be totally locked out. Like, they shouldn't be able to learn anything about it just by watching, starting, or messing with protocol conversations 🚫

They also shouldn't be able to take anything they picked up from watching, tampering with, or starting those conversations and use it to pretend to be another valid user. Main character energy means nobody gets to be someone else 💅

4.2. Authorization 🎟️

Authorization shall normally be performed on the basis of the authenticated identity (such as username), and the specification shall require all implementations to support that mode. 🙌 Different identities (or classes of identities) can have different testing privileges, so not everyone gets the same VIP pass ✨

Using authorization to make specific policy calls is up to the users, though. Stuff like whether a specific test is allowed between a given source and destination, and what its send schedule looks like at a given time, is totally their call. That schedule is what sets the average network capacity utilization, so it matters a lot 📊

4.3. Being Hard to Interfere with by Applying Special Treatment to Measurement Packets 🕵️‍♀️

The protocol design should make it possible to run sessions where it's super hard for any middle party to make the results look better than they would have if nobody tried to interfere 🙈

This is different from cryptographic data integrity 🔒, because someone can totally mess with the results without changing a single byte of the packets 😳 Picture this: if OWAMP-Test packets are easy to spot (say they all show up on a well-known port number), a middle party could shove them into a priority queue on a congested link. Now the measurement looks amazing while everyone else's traffic is suffering 📉 It should not be easy for middle parties to identify OWAMP-Test packets, just like restaurants shouldn't be able to spot the restaurant critics 🍽️🕶️

4.4. Secrecy/Confidentiality 🤫

It should be possible to make it totally infeasible for any outside party without the shared secret to figure out what info is being exchanged over OWAMP-Control, whether they're just peeking at an OWAMP-Control stream or actively messing with it 🙅‍♀️

Okay, but real talk: some info will inevitably leak just from the fact that communication is happening, plus the presence and timing of concurrent and later OWAMP-Test traffic. It is what it is 🫠

4.5. Integrity 🧩

So we can spot any interference during a conversation (other than someone just holding onto some messages), there must be a way to authenticate each OWAMP-Control message 🔏 That covers the message itself, which session it belongs to, and exactly where it sits in the sequence of control protocol exchanges. No sneaky reordering!

It must also be possible to authenticate each OWAMP-Test message and tie it to a specific session, so any changes to OWAMP-Test messages can be caught 🕵️ The catch is that this has to work without encrypting the timestamps themselves. In that setup, the security properties only hold when an attacker cannot watch valid OWAMP-Test traffic between the sender and receiver 👀

4.6. Replay Attacks 🔁

OWAMP-Control must be resistant to any replay attacks. No replaying old messages and getting away with it 🙅‍♀️

OWAMP-Test is a different story, because it's a network measurement protocol 📡 Networks love duplicating packets, so OWAMP-Test has to be good at measuring duplication. That also makes it open to attacks that replay a recent packet. The problem is that the recipient of such a packet has no way to tell whether the duplicate is malicious or just naturally happening 🤷‍♀️

So OWAMP-Test should measure all duplication, malicious or not 💯 This is kind of like delay attacks, where an attacker holds a packet for a bit and then releases it to keep going to the recipient ⏳ The recipient can't reliably tell that kind of delay apart from natural delay either.

OWAMP-Test should measure the network as it was. ✨ Now, that doesn't stop the data from being cleaned up later on in processing, analysis, or consumption 🧹 Some sanity checks should be done by the OWAMP-Test recipient right away, but only the ones that are reliable, and they should err on the side of inclusion 🫶

4.7. Modes of Operation 🎛️

The protocols are gonna be used in wildly different situations with wildly different equipment 🖥️ so it's necessary to support different levels of security modes. The things to think about include confidentiality, data origin authentication, integrity, and replay protection 💅

It should also be possible to run in a mode where all the security mechanisms are on and the security goals are hit as fully as possible. We're calling this "encrypted mode" 🔐✨

Timestamp encryption takes a certain amount of time, and that can be hard to predict on some devices (especially ones with a time-sharing OS) ⏱️ So there should be a mode similar to encrypted mode, except timestamps aren't encrypted. In this mode, every security property from encrypted mode that can still hold without timestamp encryption should stay in place. We're calling this one "authenticated mode" 🎀

It should be possible to run in a totally "open" mode with no cryptographic security mechanisms. We're calling this "unauthenticated mode" 🌸 But even here, mandatory-to-use mechanisms must be specified to stop the protocol from being used for network capacity starvation denial-of-service attacks. One example is only sending test data back to the client that asked for it, with the request delivered over a TCP connection 🛡️ Another is stopping a worm from using the protocol to blast test data at a huge number of hosts in a short time. For that, open mode requests should only be made by humans, and their acceptance should be rate-limited 🤖🚫

Last thing: the number of other options and modes should be kept to the absolute practical minimum, since too many choices make implementation a nightmare 😭 Wherever a single mechanism can do the job for anything security-related, that choice should be made at the specification phase and written into the standard 📜

5. IANA Considerations 📋

The relevant IANA considerations will live in the protocol specification document itself, not in the requirements document 📄

6. References 📚

6.1. Normative References 💜

[RFC2330]  Paxson, V., Almes, G., Mahdavi, J. and M. Mathis,
           "Framework for IP Performance Metrics", RFC 2330, May
           1998.

[RFC2474]  Nichols, K., Blake, S., Baker, F. and D. Black,
           "Definition of the Differentiated Services Field (DS
           Field) in the IPv4 and IPv6 Headers", RFC 2474, December
           1998.

[RFC2679]  Almes, G., Kalidindi, S. and M. Zekauskas, "A One-way
           Delay Metric for IPPM", RFC 2679, September 1999.

[RFC2680]  Almes, G., Kalidindi, S. and M. Zekauskas, "A One-way
           Packet Loss Metric for IPPM", RFC 2680, September 1999.

[RFC3140]  Black, D., Brim, S., Carpenter, B. and F. Le Faucheur,
           "Per Hop Behavior Identification Codes", RFC 3140, June
           2001.

6.2. Informative References 🦋

[BRIX]     Brix 1000 Verifier,
           http://www.brixnet.com/products/brix1000.html

[CQOS]     CQOS Home Page, http://www.cqos.com/

[RIPE]     RIPE NCC Test-Traffic Measurements home,
           http://www.ripe.net/test-traffic/

[SURVEYOR] Surveyor Home Page, http://www.advanced.org/surveyor/

7. Authors' Addresses ✍️

  • Stanislav Shalunov, EMail: shalunov@internet2.edu
  • Benjamin Teitelbaum, EMail: ben@internet2.edu

Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. 🌈

This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 🙏

Intellectual Property 🧠

The IETF takes no position on the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document, or on whether any license under such rights might or might not be available. It also doesn't claim to have made any independent effort to identify any such rights. Info on the procedures for rights in RFC documents can be found in BCP 78 and BCP 79 📚

Copies of IPR disclosures made to the IETF Secretariat, any assurances of licenses to be made available, or the result of an attempt to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF's online IPR repository at http://www.ietf.org/ipr. 🗂️

The IETF invites any interested party to bring to its attention any copyrights, patents, patent applications, or other proprietary rights that may cover technology required to implement this standard. Please send that info to the IETF at ietf-ipr@ietf.org 💌

Acknowledgement 🌷

Funding for the RFC Editor function is currently provided by the Internet Society. 💖

📦 where this page comes from