RFC 8545

Well-Known Port Assignments for the One-Way Active Measurement Protocol (OWAMP) and the Two-Way Active Measurement Protocol (TWAMP)

📅 published March 2019, from ietf

🎀 RFC 8545: Well-Known Port Assignments for OWAMP and TWAMP 🎀

okay bestie, so this is an Internet Standards Track doc, which means it's the real deal, not a vibe 💅 It's by A. Morton (Ed.) from AT&T Labs and G. Mirsky (Ed.) from ZTE Corp., and it's dated March 2019 🌸 It's published as RFC 8545, and it updates RFC 4656 and RFC 5357 (the OWAMP and TWAMP specs) in terms of their UDP well-known port assignments ✨ ISSN is 2070-1721 if you're keeping receipts 🧾

Abstract ✨

okay so this memo is basically about why we're reshuffling the well-known ports for OWAMP and TWAMP, the two active measurement protocols, for control and measurement 🦋 It also clears up what these Standards Track protocol names actually mean and what they're made of, so the whole industry is on the same page 📖

This memo updates RFCs 4656 and 5357, specifically the UDP well-known port assignments 🎯 and it also clarifies the complete OWAMP and TWAMP protocol composition, so nobody gets confused about what "OWAMP" or "TWAMP" includes 💖

Status of This Memo 🫶

This is an Internet Standards Track document ✅

It's a product of the Internet Engineering Task Force (IETF) and represents the consensus of the IETF community 🌈 It got public review and was approved for publication by the Internet Engineering Steering Group (IESG) 👑 More info on Internet Standards is in Section 2 of RFC 7841 💜

Info about the current status, any errata, and how to give feedback can be found at:

https://www.rfc-editor.org/info/rfc8545

Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved. 💅

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication 📜 Please actually read these, because they spell out your rights and restrictions 🙈 Code Components pulled out of this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come without warranty as described in the Simplified BSD License ⚠️

Table of Contents 🧚

1. Introduction ....................................................3
2. Requirements Language ...........................................3
3. Scope ...........................................................3
4. Definitions and Background ......................................3
5. New Well-Known Ports ............................................5
   5.1. Impact on TWAMP-Control Protocol ...........................5
   5.2. Impact on OWAMP-Control Protocol ...........................6
   5.3. Impact on OWAMP-Test/TWAMP-Test Protocols ..................6
6. Security Considerations .........................................7
7. IANA Considerations .............................................8
8. References ......................................................8
   8.1. Normative References .......................................8
   8.2. Informative References .....................................9
Appendix A. Background on TWAMP Light .............................10
Acknowledgements ..................................................11
Contributors ......................................................11
Authors' Addresses ................................................11

1. Introduction 🌸

okay so the IETF IP Performance Metrics (IPPM) Working Group first built OWAMP, which is specified in [RFC4656] ✨ Then they kept developing for testing and got TWAMP, specified in [RFC5357] 💖

Both OWAMP and TWAMP need a control and mode negotiation protocol (OWAMP-Control and TWAMP-Control) that runs over the reliable transport of TCP, including security configuration and key derivation 🔐 The control protocols set up and manage test sessions, and those sessions use the matching test protocol (OWAMP-Test or TWAMP-Test) over UDP 🦋

The IETF sees the value in giving the OWAMP-Test and TWAMP-Test protocols a well-known UDP port 🎀 and it knows this can be done pretty easily through port reassignments 💅

2. Requirements Language 💜

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be read as described in BCP 14 [RFC2119] [RFC8174], but only when they show up in ALL CAPS like this 🫶

3. Scope 🧚

The scope here is twofold 🌈 (1) reallocate the well-known ports for the UDP test protocols that are necessary parts of their Standards Track protocols (OWAMP and TWAMP), and (2) clarify what these Standards Track protocol names mean and what they're made of, so the industry is clear 💖

This memo updates [RFC4656] and [RFC5357], specifically the UDP well-known port assignments ✨

4. Definitions and Background 📖

okay, this section defines the key terms and spells out the required composition of the OWAMP and TWAMP Standards Track protocols 💅

"OWAMP-Control" is the protocol defined in Section 3 of [RFC4656] 🎀

"OWAMP-Test" is the protocol defined in Section 4 of [RFC4656] 🎀

Here's the direct quote from Section 1.1 of [RFC4656] describing OWAMP: "OWAMP actually consists of two inter-related protocols: OWAMP-Control and OWAMP-Test." A similar sentence shows up in Section 2 of [RFC4656] 👑 To be totally clear, implementing both OWAMP-Control and OWAMP-Test is REQUIRED for Standards Track OWAMP as specified in [RFC4656] 🔥 (this follows the consensus of many dictionary definitions of "consist" 😭)

"TWAMP-Control" is the protocol defined in Section 3 of [RFC5357] 🌸

"TWAMP-Test" is the protocol defined in Section 4 of [RFC5357] 🌸

And for TWAMP, the direct quote from Section 1.1 of [RFC5357] goes: "Similar to OWAMP [RFC4656], TWAMP consists of two inter-related protocols: TWAMP-Control and TWAMP-Test." Same deal here: implementing both TWAMP-Control and TWAMP-Test is REQUIRED for Standards Track TWAMP as specified in [RFC5357] (again applying the consensus of many dictionary definitions of "consist") 🧚

"TWAMP Light" is an idea described in Appendix I ("TWAMP Light (Informative)") of [RFC5357] 🦋 TWAMP Light includes an unspecified control protocol combined with the TWAMP-Test protocol. In [RFC5357], TWAMP Light got bumped to Appendix I because it didn't meet the requirements for IETF protocols 🙈 (there are no specs for negotiating this form of operation and no specs for mandatory-to-implement security features), as explained in Appendix A of this memo 💀 See also [LarsAD] and [TimDISCUSS] 👀

Since the TWAMP Light idea clearly includes the TWAMP-Test component of TWAMP, it's considered reasonable for future systems to use the TWAMP-Test well-known UDP port (whose reallocated assignment is specified in this document) ✨ Clearly though, the TWAMP Light idea imagines lots of components and communication capabilities beyond TWAMP-Test (like implementing the security requirements, for example) 🔐 Otherwise, Appendix I of [RFC5357] would be one sentence long, equating TWAMP Light with TWAMP-Test only 😭

5. New Well-Known Ports 👑

Originally, both TCP and UDP well-known ports were assigned to the control protocols that are essential parts of Standards Track OWAMP and TWAMP 🌸

Since OWAMP-Control and TWAMP-Control need TCP transport, they can't use the UDP ports that were originally assigned 💔 But test sessions using OWAMP-Test or TWAMP-Test run on UDP transport 🦋

So per this memo, IANA has reassigned the UDP well-known port from the control protocol to the test protocol (see Section 7, "IANA Considerations") 🎀 Using this UDP port is OPTIONAL in Standards Track OWAMP and TWAMP 🫶 It may simplify some operations to have a well-known port available for the test protocols, or for future specifications involving TWAMP-Test to use this port as a default port ✨ For example, [TR-390] is a specification for testing at the customer edge of IP networks, and conforming implementations will benefit from the reallocation of the well-known UDP port to the test protocol 🧚

5.1. Impact on TWAMP-Control Protocol 💅

Section 3.5 of [RFC5357] describes the detailed process for negotiating the Receiver Port number, which is where the TWAMP Session-Reflector sends and receives TWAMP-Test packets 🦋 Quoted text below 👇 The Control-Client, acting on behalf of the Session-Sender, proposes the Receiver Port number from the Dynamic Ports range [RFC6335]:

   The Receiver Port is the desired UDP port to which TWAMP-Test
   packets will be sent by the Session-Sender (the port where the
   Session-Reflector is asked to receive test packets).  The Receiver
   Port is also the UDP port from which TWAMP-Test packets will be
   sent by the Session-Reflector (the Session-Reflector will use the
   same UDP port to send and receive packets).

It's possible the proposed Receiver Port isn't available, for example if it's already in use by another test session or another application 😭 In that case, we update the last paragraph of Section 3.5 of [RFC5357] per Erratum ID 1587 (see <https://www.rfc-editor.org/errata/eid1587>) like this 🔥

   ... the Server at the Session-Reflector MAY suggest an alternate
   and available port for this session in the Port field.  The
   Control-Client either accepts the alternate port or composes a new
   Session-Request message with suitable parameters.  Otherwise, the
   Server uses the Accept field to convey other forms of session
   rejection or failure to the Control-Client and MUST NOT suggest an
   alternate port; in this case, the Port field MUST be set to zero.

A Control-Client that supports the use of the allocated TWAMP-Test Receiver Port (Section 7) MAY request that port number in the Request-TW-Session command 🎀 If the Server doesn't support the allocated TWAMP-Test Receiver Port, it sends an alternate port number in the Accept-Session message with Accept field = 0 🫶 So deploying the allocated TWAMP Receiver Port number is backward compatible with existing TWAMP-Control solutions based on [RFC5357] ✨ Of course, picking a UDP port number from the Dynamic Ports range [RFC6335] will help avoid the situation where the Control-Client or Server finds the proposed port is already in use 🧚

5.2. Impact on OWAMP-Control Protocol 🌈

Like described above, an OWAMP-Control client that supports the use of the allocated OWAMP-Test Receiver Port (Section 7) MAY request that port number in the Request-Session command 💖 If the Server doesn't support the allocated OWAMP-Test Receiver Port (or doesn't have the port available), it sends an alternate port number in the Accept-Session message with Accept field = 0 🦋 Further exchanges proceed as already specified 💅

5.3. Impact on OWAMP-Test/TWAMP-Test Protocols

OKAY so bestie, this one is about ECMP networks 🦋 (that's Equal-Cost Multipath, where traffic can take more than one path at once). OWAMP-Test/TWAMP-Test can totally be used to measure IP performance metrics there ✨. The thing is, the algorithms that split IP flows across those paths were never standardized 🫠, but the most common one looks at a five-tuple: destination IP address, source IP address, protocol type, destination port number, and source port number 💅.

So if you want to monitor different paths, you only need to change ONE of those five things, like the source port number 🌸. That means you can still set up concurrent OWAMP/TWAMP test sessions between the same test points to watch different paths, even when you're using the reallocated UDP port number as the Receiver Port 🎀. Why? Because using that port is optional 💖. No negative impact, periodt 👑.

6. Security Considerations ⚠️

Okay this section is SERIOUS and I'm not gonna sugarcoat it 😭. The security considerations that apply to any active measurement of live paths are relevant here too (see [RFC4656] and [RFC5357]) 🔥.

Privacy is a whole vibe 🌈. When it comes to the people doing the measuring, or whose traffic is being measured, the sensitive info that potential observers can get is WAY reduced when you use the active techniques in this scope 🙈. Passive observation of user traffic for measurement, though? That raises a LOT of privacy issues 💀. For the full picture, go check the security and privacy considerations in the Large-Scale Measurement of Broadband Performance (LMAP) framework [RFC7594], which covers both active and passive techniques 🧚.

Now the spicy part 🌶️. The registered UDP port used as the Receiver Port for OWAMP-Test/TWAMP-Test could become a target of denial of service (DoS) attacks, or get used to help man-in-the-middle (MITM) attacks 😱. To improve protection against DoS, the following methods are RECOMMENDED:

  • filtering access to the OWAMP/TWAMP Receiver Port via an access list.
  • using a non-globally routable IP address for the OWAMP/TWAMP Session-Reflector address.

A MITM attacker might try to modify the contents of OWAMP-Test/TWAMP-Test packets to mess with the measurement results 😤. However, an implementation can use authenticated mode to detect modification of data 🔐. On top of that, an implementation can use encrypted mode to prevent eavesdropping and undetected modification of the OWAMP-Test/TWAMP-Test packets 🫶.

There's also a risk that a network under test gives special treatment to flows involving the well-known UDP port, whether or not it knows the source and destination addresses of the measurement systems 🙃. That could bias the results through preferential or detrimental processing 📉. Not it! 🙅‍♀️

7. IANA Considerations 🧾

IANA reallocated two UDP port numbers from the System Ports range of the "Service Name and Transport Protocol Port Number Registry" [RFC6335] 🎀. Specifically, IANA reallocated UDP ports 861 and 862 as shown below, and left the TCP port assignments as they were 💜. IANA also updated the Assignee and Contact for these ports (both UDP and TCP) to be the IESG and the IETF Chair, respectively 👑.

+---------------+--------+-----------+------------------+-----------+
| Service       | Port   | Transport | Description      | Reference |
| Name          | Number | Protocol  |                  |           |
+---------------+--------+-----------+------------------+-----------+
| owamp-control | 861    | tcp       | OWAMP-Control    | RFC 4656  |
| owamp-test    | 861    | udp       | OWAMP-Test       | RFC 8545  |
|               |        |           |    Receiver Port |           |
|               |        |           |                  |           |
| twamp-control | 862    | tcp       | TWAMP-Control    | RFC 5357  |
| twamp-test    | 862    | udp       | TWAMP-Test       | RFC 8545  |
|               |        |           |    Receiver Port |           |
+---------------+--------+-----------+------------------+-----------+

8. References 📚

8.1. Normative References

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.

[RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M. Zekauskas, "A One-way Active Measurement Protocol (OWAMP)", RFC 4656, DOI 10.17487/RFC4656, September 2006, <https://www.rfc-editor.org/info/rfc4656>.

[RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J. Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)", RFC 5357, DOI 10.17487/RFC5357, October 2008, <https://www.rfc-editor.org/info/rfc5357>.

[RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. Cheshire, "Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry", BCP 165, RFC 6335, DOI 10.17487/RFC6335, August 2011, <https://www.rfc-editor.org/info/rfc6335>.

[RFC7594] Eardley, P., Morton, A., Bagnulo, M., Burbridge, T., Aitken, P., and A. Akhter, "A Framework for Large-Scale Measurement of Broadband Performance (LMAP)", RFC 7594, DOI 10.17487/RFC7594, September 2015, <https://www.rfc-editor.org/info/rfc7594>.

[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.

8.2. Informative References

[IPPM-TWAMP-06] Hedayat, K., Krzanowski, R., Yum, K., Morton, A., and J. Babiarz, "A Two-way Active Measurement Protocol (TWAMP)", Work in Progress, draft-ietf-ippm-twamp-06, December 2007.

[LarsAD] Eggert, L., "Subject: [ippm] AD review: draft-ietf-ippm-twamp-06.txt", message to the ippm mailing list, April 2008, <https://mailarchive.ietf.org/ rch/msg/ippm/LzcTPYhPhWhbb5-ncR046XKpnzo>.

[TimDISCUSS] "Tim Polk's Ballot discuss", July 2008, <https://datatracker.ietf.org/doc/rfc5357/history>.

[TR-390] Broadband Forum, "TR-390: Performance Measurement from IP Edge to Customer Equipment using TWAMP Light", Issue: 1, May 2017, <https://www.broadband-forum.org/technical/ download/TR-390.pdf>.

Appendix A. Background on TWAMP Light 🌙

This informative appendix gives the background on the decision to move the TWAMP Light idea to an informative appendix in [RFC5357] 🦋.

As also noted in Section 4, the TWAMP Light idea was relegated to Appendix I of [RFC5357] because it failed to meet the requirements for IETF protocols 🙃. There are no specifications for negotiating this form of operation, and no specifications for mandatory-to-implement security features 😬. The references below explain the details:

  • Lars Eggert's Area Director review [LarsAD] 🧐: he pointed out that having two variants of TWAMP (TWAMP Light and Complete TWAMP) requires a protocol mechanism to negotiate which variant will be used. Note that "Complete TWAMP" is called "Standards Track TWAMP" in this document. See Lars's "Section 5.2, paragraph 0" comment on [LarsAD], which refers to a section in [IPPM-TWAMP-06]. The working group consensus was to place the TWAMP Light description in Appendix I and to refer to that appendix only as an "incremental path to adopting TWAMP, by implementing the TWAMP-Test protocol first."
  • Tim Polk's "Ballot discuss" of 2008-07-16 [TimDISCUSS] 🎤: it points out that TWAMP Light was an incomplete specification because the key required for authenticated and encrypted modes depended on the TWAMP-Control Session key. Additional requirement statements were added in Appendix I to address Tim's Ballot discuss (see the last three paragraphs of Appendix I in [RFC5357]).

Since the idea of TWAMP Light clearly includes the TWAMP-Test protocol and other undefined facilities, Appendix I of [RFC5357] simply describes ideas for how TWAMP-Test might be used outside of the context of Standards Track TWAMP 💜.

Acknowledgements 🫶

The authors thank the IPPM Working Group for their rapid review. Thanks also to Muthu Arul Mozhi Perumal and Luay Jalil for their participation and suggestions 💖.

Contributors 🌸

Richard Foote and Luis M. Contreras made notable contributions on this topic ✨.

Authors' Addresses 📮

Al Morton (editor) AT&T Labs 200 Laurel Avenue South Middletown, NJ 07748 United States of America

Phone: +1 732 420 1571 Fax: +1 732 368 1192 Email: acmorton@att.com

Greg Mirsky (editor) ZTE Corp.

Email: gregimirsky@gmail.com

📦 where this page comes from