Network Working Group                                     A. Morton, Ed.
Internet-Draft                                                 AT&T Labs
Updates: 4656 and 5357 (if approved)                      G. Mirsky, Ed.
Intended status: Standards Track                               ZTE Corp.
Expires: September 21, 2018                               March 20, April 7, 2019                                   October 4, 2018

              OWAMP and TWAMP Well-Known Port Assignments


   This memo explains the motivation and describes the re-assignment of
   well-known ports for the OWAMP and TWAMP protocols for control and
   measurement, and clarifies the meaning and composition of these
   standards track protocol names for the industry.

   The memo updates RFC 4656 and RFC 5357, in terms of the UDP well-
   known port assignments.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on September 21, 2018. April 7, 2019.

Copyright Notice

   Copyright (c) 2018 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
   ( 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 Contents

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

1.  Introduction

   The IETF IP Performance Metrics (IPPM) working group first developed
   the One-Way Active Measurement Protocol, OWAMP, specified in
   [RFC4656].  Further protocol development to support testing resulted
   in the Two-Way Active Measurement Protocol, TWAMP, specified in

   Both OWAMP and TWAMP require the implementation of a control and mode
   negotiation protocol (OWAMP-Control and TWAMP-Control) which 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.

   This memo recognizes the value of assigning a well-known UDP port to
   the *-Test protocols, and that this goal can easily be arranged
   through port re-assignments.

2.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "OPTIONAL" in this document are to be interpreted as described in

   [RFC2119] [RFC8174] when, and only when, they appear in all capitals,
   as shown here.

3.  Scope

   The scope of this memo is to re-allocate well-known ports for the UDP
   Test protocols that compose necessary parts of their respective
   standards track protocols, OWAMP and TWAMP, along with clarifications
   of the complete protocol composition for the industry.

   The memo updates [RFC4656] and [RFC5357], in terms of the UDP well-
   known port assignments.

4.  Definitions

   This section defines key terms and clarifies 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].

   OWAMP is described in a direct quote from Section 1.1 of[RFC4656]:
   "OWAMP actually consists of two inter-related protocols: OWAMP-
   Control and OWAMP-Test."  A similar sentence appears in Section 2 of
   [RFC4656].  Since the consensus of many dictionary definitions of
   "consist" is "composed or made up of", implementation of both OWAMP-
   Control and OWAMP-Test are REQUIRED for standards-track OWAMP
   specified in [RFC4656].

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

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

   TWAMP is described in a direct quote from Section 1.1 of [RFC5357]:
   "Similar to OWAMP [RFC4656], TWAMP consists of two inter-related
   protocols: TWAMP-Control and TWAMP-Test."  Since the consensus of
   many dictionary definitions of "consist" is "composed or made up of",
   implementation of both TWAMP-Control and TWAMP-Test are REQUIRED for
   standards-track TWAMP specified in [RFC5357].

   TWAMP Light is an idea described in Informative Appendix I of
   [RFC5357], and includes an un-specified control protocol (possibly
   communicating through non-standard means) combined with the TWAMP-
   Test protocol.  The TWAMP Light idea was relegated to the
   Appendix 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 below:

   o  Lars Eggert's Area Director review [LarsAD], where he pointed out
      that having two variants of TWAMP, Light and Complete (called
      standards track TWAMP here), required a protocol mechanism to
      negotiate which variant will be used.  See Lars' comment on Sec
      5.2.  The working group consensus was to place the TWAMP Light
      description in Appendix I, and to refer to the Appendix only as an
      "incremental path to adopting TWAMP, by implementing the TWAMP-
      Test protocol first".

   o  Tim Polk's DISCUSS Ballot, 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.  See Tim's DISCUSS on 2008-07-16 [TimDISCUSS].
      Additional requirement statements were added in the Appendix to
      address Tim's DISCUSS Ballot (see the last three paragraphs of
      Appendix I in [RFC5357]).

   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 re-allocated assignment
   is requested here).  Clearly, the TWAMP Light idea envisions many
   components and communication capabilities beyond TWAMP-Test
   (implementing the security requirements, for example), otherwise the
   Appendix would be one sentence long (equivocating 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 components of standards track

   Since OWAMP-Control and TWAMP-Control require TCP transport, they
   cannot make use of the UDP ports which were originally assigned.
   However, test sessions using OWAMP-Test or TWAMP-Test operate on UDP

   This memo requests re-assignment of the UDP well-known port from the
   Control protocol to the Test protocol (see the IANA Considerations
   Section 7).  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

5.1.  Impact on TWAMP-Control Protocol

   Section 3.5 [RFC5357] describes the detailed process of negotiating
   the Receiver Port number, on which the TWAMP Session-Reflector will
   send and receive TWAMP-Test packets.  The Control-Client, acting on
   behalf of the Session-Sender, proposes the Receiver port number from
   the Dynamic Port 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 be not available,
   e.g., the port is in use by another test session or another
   application.  In this case:

      "... 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 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, use of a UDP port number chosen from the
   Dynamic Port range [RFC6335] will help to avoid the situation when
   the Control-Client or Server finds the proposed port being already in

5.2.  Impact on OWAMP-Control Protocol

   As described above, an OWAMP Control Client that supports 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/TWAMP-Test Protocols

   OWAMP/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 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
   ability to arrange concurrent OWAMP/TWAMP test sessions between the
   same test points to monitor different paths in the ECMP network when
   using the re-allocated UDP port number as the Receiver Port, as use
   of the port is optional.

6.  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 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
   which 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/TWAMP-Test
   could become a target of denial-of-service (DoS) or used to aid man-
   in-the-middle (MITM) attacks.  To improve protection from the DoS
   following methods are recommended:

   o  filtering access to the OWAMP/TWAMP Receiver Port by access list;

   o  using a non-globally routable IP address for the OWAMP/TWAMP
      Session-Reflector address.

   A MITM attack may try to modify the content of the OWAMP/TWAMP-Test
   packets in order to alter the measurement results.  However, an
   implementation can use authenticated mode to detect modification of
   data.  In addition, use encrypted mode to prevent eavesdropping and
   un-detected modification of the OWAMP/TWAMP-Test packets.

7.  IANA Considerations

   This memo requests re-allocation of two UDP port numbers from the
   System Ports range [RFC6335].  Specifically, this memo requests that
   IANA re-allocate UDP ports 861 and 862 as shown below, leaving the
   TCP port assignments as-is:

   | Service    | Port  | Transp. | Description          | Reference   |
   | Name       | Num.  | Protocol|                      |             |
   |            |       |         |                      |             |
   | owamp-     | 861   | tcp     | OWAMP-Control        | [RFC4656]   |
   | control    |       |         |                      |             |
   | owamp-test | 861   | udp     | OWAMP-Test           | [RFCXXXX]   |
   |            |       |         |                      |             |
   | twamp-     | 862   | tcp     | TWAMP-Control        | [RFC5357]   |
   | control    |       |         |                      |             |
   | twamp-test | 862   | udp     | TWAMP-Test Receiver  | [RFCXXXX]   |
   |            |       |         | Port                 |             |

                Table 1 Re-allocated OWAMP and TWAMP Ports

   where RFCXXXX is this memo when published.

8.  Contributors

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

9.  Acknowledgements

   The authors thank the IPPM working group for their rapid review; also
   Muthu Arul Mozhi Perumal and Luay Jalil for their participation and

10.  References

10.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,

   [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,

   [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,

   [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,

   [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,

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <>.

10.2.  Informative References

   [LarsAD]   "
              LzcTPYhPhWhbb5-ncR046XKpnzo", April 2008.

              "", July

Authors' Addresses

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

   Phone: +1 732 420 1571
   Fax:   +1 732 368 1192
   Greg Mirsky (editor)
   ZTE Corp.