Movatterモバイル変換
[0]ホーム
[RFC Home] [TEXT|PDF|HTML] [Tracker] [IPR] [Info page]
PROPOSED STANDARD
Internet Engineering Task Force (IETF) A. Morton, Ed.Request for Comments: 8545 AT&T LabsUpdates:4656,5357 G. Mirsky, Ed.Category: Standards Track ZTE Corp.ISSN: 2070-1721 March 2019Well-Known Port Assignments forthe One-Way Active Measurement Protocol (OWAMP) andthe Two-Way Active Measurement Protocol (TWAMP)Abstract This memo explains the motivation and describes the reassignment of well-known ports for the One-Way Active Measurement Protocol (OWAMP) and the Two-Way Active Measurement Protocol (TWAMP) for control and measurement. It also clarifies the meaning and composition of these Standards Track protocol names for the industry. This memo updates RFCs 4656 and 5357, in terms of the UDP well-known port assignments, and it clarifies the complete OWAMP and TWAMP protocol composition for the industry.Status of This Memo This is an Internet Standards Track document. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available inSection 2 of RFC 7841. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained athttps://www.rfc-editor.org/info/rfc8545.Morton & Mirsky Standards Track [Page 1]
RFC 8545 OWAMP/TWAMP Well-Known Ports March 2019Copyright Notice Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject toBCP 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 of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.Table of Contents1. Introduction ....................................................32. Requirements Language ...........................................33. Scope ...........................................................34. Definitions and Background ......................................35. New Well-Known Ports ............................................55.1. Impact on TWAMP-Control Protocol ...........................55.2. Impact on OWAMP-Control Protocol ...........................65.3. Impact on OWAMP-Test/TWAMP-Test Protocols ..................66. Security Considerations .........................................77. IANA Considerations .............................................88. References ......................................................88.1. Normative References .......................................88.2. Informative References .....................................9Appendix A. Background on TWAMP Light .............................10 Acknowledgements ..................................................11 Contributors ......................................................11 Authors' Addresses ................................................11Morton & Mirsky Standards Track [Page 2]
RFC 8545 OWAMP/TWAMP Well-Known Ports March 20191. Introduction The IETF IP Performance Metrics (IPPM) Working Group first developed the One-Way Active Measurement Protocol (OWAMP), as specified in [RFC4656]. Further protocol development to support testing resulted in the Two-Way Active Measurement Protocol (TWAMP), as specified in [RFC5357]. Both OWAMP and TWAMP require the implementation of a control and mode negotiation protocol (OWAMP-Control and TWAMP-Control) that employs the reliable transport services of TCP (including security configuration and key derivation). The control protocols arrange for the configuration and management of test sessions using the associated test protocol (OWAMP-Test or TWAMP-Test) on UDP transport. The IETF recognizes the value of assigning a well-known UDP port to the OWAMP-Test and TWAMP-Test protocols and also recognizes that this goal can be easily arranged 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 interpreted as described inBCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.3. Scope The scope of this memo is twofold: (1) to reallocate the well-known ports for the UDP test protocols that compose necessary parts of their respective Standards Track protocols (OWAMP and TWAMP) and (2) to clarify the meaning and composition of these Standards Track protocol names for the industry. This memo updates [RFC4656] and [RFC5357], in terms of the UDP well-known port assignments.4. Definitions and Background This section defines key terms and clarifies the required composition of the OWAMP and TWAMP Standards Track protocols. "OWAMP-Control" is the protocol defined inSection 3 of [RFC4656]. "OWAMP-Test" is the protocol defined inSection 4 of [RFC4656].Morton & Mirsky Standards Track [Page 3]
RFC 8545 OWAMP/TWAMP Well-Known Ports March 2019 OWAMP is described in this direct quote fromSection 1.1 of [RFC4656]: "OWAMP actually consists of two inter-related protocols: OWAMP-Control and OWAMP-Test." A similar sentence appears inSection 2 of [RFC4656]. For avoidance of doubt, the implementation of both OWAMP-Control and OWAMP-Test is REQUIRED for Standards Track OWAMP as specified in [RFC4656] (applying the consensus of many dictionary definitions of "consist"). "TWAMP-Control" is the protocol defined inSection 3 of [RFC5357]. "TWAMP-Test" is the protocol defined inSection 4 of [RFC5357]. TWAMP is described in this direct quote fromSection 1.1 of [RFC5357]: "Similar to OWAMP [RFC4656], TWAMP consists of two inter-related protocols: TWAMP-Control and TWAMP-Test." For avoidance of doubt, the implementation of both TWAMP-Control and TWAMP-Test is REQUIRED for Standards Track TWAMP as specified in [RFC5357] (applying the consensus of many dictionary definitions of "consist"). "TWAMP Light" is an idea described inAppendix I ("TWAMP Light (Informative)") of [RFC5357]; TWAMP Light includes an unspecified control protocol combined with the TWAMP-Test protocol. In [RFC5357], the TWAMP Light idea was relegated toAppendix I because TWAMP Light 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), as described inAppendix A of this memo. See also [LarsAD] and [TimDISCUSS]. Since the idea of TWAMP Light clearly includes the TWAMP-Test component of TWAMP, it is considered reasonable for future systems to use the TWAMP-Test well-known UDP port (whose reallocated assignment is specified in this document). Clearly, the TWAMP Light idea envisions many components and communication capabilities beyond TWAMP-Test (implementing the security requirements, for example); otherwise,Appendix I of [RFC5357] would be one sentence long (equating TWAMP Light with TWAMP-Test only).Morton & Mirsky Standards Track [Page 4]
RFC 8545 OWAMP/TWAMP Well-Known Ports March 20195. New Well-Known Ports Originally, both TCP and UDP well-known ports were assigned to the control protocols that are essential components of Standards Track OWAMP and TWAMP. Since OWAMP-Control and TWAMP-Control require TCP transport, they cannot make use of the UDP ports that were originally assigned. However, test sessions using OWAMP-Test or TWAMP-Test operate on UDP transport. Per this memo, IANA has reassigned the UDP well-known port from the control protocol to the test protocol (seeSection 7 ("IANA Considerations")). The use of 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 reallocation of the well-known UDP port to the test protocol.5.1. Impact on TWAMP-Control ProtocolSection 3.5 of [RFC5357] describes the detailed process of negotiating the Receiver Port number, on which the TWAMP Session-Reflector will send and receive TWAMP-Test packets; see the 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 is possible that the proposed Receiver Port may not be available, e.g., the port is in use by another test session or another application. In this case, we update the last paragraph ofSection 3.5 of [RFC5357] per Erratum ID 1587 (see <https://www.rfc-editor.org/errata/eid1587>) as follows: ... 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, theMorton & Mirsky Standards Track [Page 5]
RFC 8545 OWAMP/TWAMP Well-Known Ports March 2019 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 to use that port number in the Request-TW-Session command. If the Server does not support the allocated TWAMP-Test Receiver Port, then it sends an alternate port number in the Accept-Session message with Accept field = 0. Thus, the deployment of the allocated TWAMP Receiver Port number is backward compatible with existing TWAMP-Control solutions that are based on [RFC5357]. Of course, using a UDP port number chosen from the Dynamic Ports range [RFC6335] will help avoid the situation where the Control-Client or Server finds that the proposed port is already in use.5.2. Impact on OWAMP-Control Protocol As described above, an OWAMP-Control client that supports the use of the allocated OWAMP-Test Receiver Port (Section 7) MAY request to use that port number in the Request-Session command. If the Server does not support the allocated OWAMP-Test Receiver Port (or does not have the port available), then 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 OWAMP-Test/TWAMP-Test may be used to measure IP performance metrics in an Equal-Cost Multipath (ECMP) environment. Though algorithms to balance IP flows among available paths have not been standardized, the most common is the five-tuple that uses destination IP address, source IP address, protocol type, destination port number, and source port number. When attempting to monitor different paths in an ECMP network, it is sufficient to vary only one of five parameters, e.g., the source port number. Thus, there will be no negative impact on the ability to arrange concurrent OWAMP/TWAMP test sessions between the same test points to monitor different paths in the ECMP network when using the reallocated UDP port number as the Receiver Port, as using the port is optional.Morton & Mirsky Standards Track [Page 6]
RFC 8545 OWAMP/TWAMP Well-Known Ports March 20196. Security Considerations The security considerations that apply to any active measurement of live paths are relevant here as well (see [RFC4656] and [RFC5357]). When considering the privacy of those involved in measurement or those whose traffic is measured, the sensitive information available to potential observers is greatly reduced when using active techniques that are within this scope of work. Passive observations of user traffic for measurement purposes raise many privacy issues. We refer the reader to the security and privacy considerations described in the Large-Scale Measurement of Broadband Performance (LMAP) framework [RFC7594], which covers both active and passive techniques. The registered UDP port as the Receiver Port for OWAMP-Test/ TWAMP-Test could become a target of denial of service (DoS) or could be used to aid man-in-the-middle (MITM) attacks. To improve protection against DoS, the following methods are recommended: o filtering access to the OWAMP/TWAMP Receiver Port via an access list. o using a non-globally routable IP address for the OWAMP/TWAMP Session-Reflector address. A MITM attacker may try to modify the contents of the OWAMP-Test/ TWAMP-Test packets in order to alter the measurement results. However, an implementation can use authenticated mode to detect modification of data. In addition, an implementation can use encrypted mode to prevent eavesdropping and undetected modification of the OWAMP-Test/TWAMP-Test packets. There is also the risk of a network under test giving special treatment to flows involving the well-known UDP port, with or without knowing source and destination addresses of measurement systems, and thus biasing the results through preferential or detrimental processing.Morton & Mirsky Standards Track [Page 7]
RFC 8545 OWAMP/TWAMP Well-Known Ports March 20197. IANA Considerations IANA has reallocated two UDP port numbers from the System Ports range of the "Service Name and Transport Protocol Port Number Registry" [RFC6335]. Specifically, IANA has reallocated UDP ports 861 and 862 as shown below, leaving the TCP port assignments as is. IANA has 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. References8.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>.Morton & Mirsky Standards Track [Page 8]
RFC 8545 OWAMP/TWAMP Well-Known Ports March 2019 [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 inRFC 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>.Morton & Mirsky Standards Track [Page 9]
RFC 8545 OWAMP/TWAMP Well-Known Ports March 2019Appendix A. Background on TWAMP Light This informative appendix provides the background on the decision to move the TWAMP Light idea to an informative appendix in [RFC5357]. As also noted inSection 4, the TWAMP Light idea was relegated toAppendix 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), as described in the references cited below: o Lars Eggert's Area Director review [LarsAD], where 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 inAppendix I and to refer to that appendix only as an "incremental path to adopting TWAMP, by implementing the TWAMP-Test protocol first." o Tim Polk's "Ballot discuss" of 2008-07-16 [TimDISCUSS], which 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 inAppendix I to address Tim's Ballot discuss (see the last three paragraphs ofAppendix 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.Morton & Mirsky Standards Track [Page 10]
RFC 8545 OWAMP/TWAMP Well-Known Ports March 2019Acknowledgements 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.comMorton & Mirsky Standards Track [Page 11]
[8]ページ先頭