<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std" docName="draft-morton-ippm-port-twamp-test-02"
     ipr="trust200902" updates="4656 and 5357">
  <front>
    <title abbrev="*WAMP W-K UDP Ports">OWAMP and TWAMP Well-Known Port
    Assignments</title>

    <author fullname="Al Morton" initials="A." role="editor" surname="Morton">
      <organization>AT&amp;T Labs</organization>

      <address>
        <postal>
          <street>200 Laurel Avenue South</street>

          <city>Middletown</city>

          <region>NJ</region>

          <code>07748</code>

          <country>USA</country>
        </postal>

        <phone>+1 732 420 1571</phone>

        <facsimile>+1 732 368 1192</facsimile>

        <email>acmorton@att.com</email>

        <uri/>
      </address>
    </author>

    <author fullname="Greg Mirsky" initials="G." role="editor"
            surname="Mirsky">
      <organization>ZTE Corp.</organization>

      <address>
        <email>gregimirsky@gmail.com</email>
      </address>
    </author>

    <date day="13" month="November" year="2017"/>

    <abstract>
      <t>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.</t>

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

      <t/>
    </abstract>
  </front>

  <middle>
    <section title="Introduction">
      <t>The IETF IP Performance Metrics (IPPM) working group first developed
      the One-Way Active Measurement Protocol, OWAMP, specified in <xref
      target="RFC4656"/>. Further protocol development to support testing
      resulted in the Two-Way Active Measurement Protocol, TWAMP, specified in
      <xref target="RFC5357"/>.</t>

      <t>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.</t>

      <t>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.</t>
    </section>

    <section title="Requirements Language">
      <t>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 in <xref
      target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they
      appear in all capitals, as shown here.</t>
    </section>

    <section title="Scope">
      <t>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.</t>

      <t>The memo updates <xref target="RFC4656"/> and <xref
      target="RFC5357"/>, in terms of the UDP well-known port assignments.</t>
    </section>

    <section title="Definitions">
      <t>This section defines key terms and clarifies the required composition
      of the OWAMP and TWAMP standards-track protocols.</t>

      <t>OWAMP-Control is the protocol defined in Section 3 of <xref
      target="RFC4656"/>.</t>

      <t>OWAMP-Test is the protocol defined in Section 4 of <xref
      target="RFC4656"/>.</t>

      <t>OWAMP is described in a direct quote from Section 1.1 of<xref
      target="RFC4656"> </xref>: "OWAMP actually consists of two inter-related
      protocols: OWAMP-Control and OWAMP-Test." A similar sentence appears in
      Section 2 of <xref target="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 <xref target="RFC4656"/>.</t>

      <t>TWAMP-Control is the protocol defined in Section 3 of <xref
      target="RFC5357"/>.</t>

      <t>TWAMP-Test is the protocol defined in Section 4 of <xref
      target="RFC5357"/>.</t>

      <t>TWAMP is described in a direct quote from Section 1.1 of <xref
      target="RFC5357"/>: "Similar to OWAMP <xref target="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 <xref
      target="RFC5357"/>.</t>

      <t>TWAMP Light is an idea described in Informative Appendix I of <xref
      target="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:<list style="symbols">
          <t>Lars Eggert's Area Director review <xref target="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".</t>

          <t>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 <xref
          target="TimDISCUSS"/>. Additional requirement statements were added
          in the Appendix to address Tim's DISCUSS Ballot (see the last three
          paragraphs of Appendix I in <xref target="RFC5357"/>).</t>
        </list></t>

      <t>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).</t>
    </section>

    <section title="New Well-Known Ports">
      <t>Originally, both TCP and UDP well-known ports were assigned to the
      control protocols that are essential components of standards track OWAMP
      and TWAMP.</t>

      <t>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
      transport. </t>

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

      <section anchor="twamp-control" title="Impact on TWAMP-Control Protocol">
        <t>Section 3.5 <xref target="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 <xref
        target="RFC6335"/>: <list>
            <t>"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)."</t>
          </list></t>

        <t>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: <list>
            <t>"... 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."</t>
          </list></t>

        <t>A Control Client that supports use of the allocated TWAMP-Test
        Receiver Port <xref target="IANA"/> 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 <xref target="RFC5357"/>. Of course, use of a UDP port number
        chosen from the Dynamic Port range <xref target="RFC6335"/> will help
        to avoid the situation when the Control-Client or Server finds the
        proposed port being already in use.</t>
      </section>

      <section title="Impact on OWAMP-Control Protocol">
        <t>As described above, an OWAMP Control Client that supports use of
        the allocated OWAMP-Test Receiver Port <xref target="IANA"/> 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.</t>
      </section>

      <section anchor="twamp-test"
               title="Impact on OWAMP/TWAMP-Test Protocols">
        <t>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.</t>
      </section>
    </section>

    <section anchor="Security" title="Security Considerations">
      <t>The security considerations that apply to any active measurement of
      live paths are relevant here as well (see <xref target="RFC4656"/> and
      <xref target="RFC5357"/>).</t>

      <t>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 <xref
      target="RFC7594"/>, which covers both active and passive techniques.</t>

      <t>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: <list style="symbols">
          <t>filtering access to the OWAMP/TWAMP Receiver Port by access
          list;</t>

          <t>using a non-globally routable IP address for the OWAMP/TWAMP
          Session-Reflector address.</t>
        </list></t>

      <t>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.</t>
    </section>

    <section anchor="IANA" title="IANA Considerations">
      <t>This memo requests re-allocation of two UDP port numbers from the
      System Ports range <xref target="RFC6335"/>. Specifically, this memo
      requests that IANA re-allocate UDP ports 861 and 862 as shown below,
      leaving the TCP port assignments as-is:</t>

      <t><figure align="center"
          title="Table 1  Re-allocated OWAMP and TWAMP Ports">
          <artwork><![CDATA[
+------------+-------+---------+----------------------+-------------+
| Service    | Port  | Transpo | Description          | Reference   |
| Name       | Numbe | rt Prot |                      |             |
|            | r     | ocol    |                      |             |
+------------+-------+---------+----------------------+-------------+
| owamp-     | 861   | tcp     | OWAMP-Control        | [RFC4656]   |
| control    |       |         |                      |             |
| owamp-test | 861   | udp     | OWAMP-Test           | [RFCXXXX]   |
|            |       |         |                      |             |
| twamp-     | 861   | tcp     | TWAMP-Control        | [RFC5357]   |
| control    |       |         |                      |             |
| twamp-test | 862   | udp     | TWAMP-Test Receiver  | [RFCXXXX]   |
|            |       |         | Port                 |             |
+------------+-------+---------+----------------------+-------------+

]]></artwork>
        </figure></t>

      <t>where RFCXXXX is this memo when published.</t>
    </section>

    <section anchor="Contrib" title="Contributors">
      <t>Richard Foote and Luis M. Contreras made notable contributions on
      this topic.</t>
    </section>

    <section anchor="Acknowledgements" title="Acknowledgements">
      <t>The authors thank the IPPM working group for their rapid review; also
      Muthu Arul Mozhi Perumal and Luay Jalil for their participation and
      suggestions.</t>
    </section>
  </middle>

  <back>
    <references title="Normative References">
      <?rfc include="reference.RFC.2119"?>

      <?rfc include='reference.RFC.4656'?>

      <?rfc include='reference.RFC.5357'?>

      <?rfc include='reference.RFC.6335'?>

      <?rfc include='reference.RFC.7594'?>

      <?rfc include='reference.RFC.8174'?>
    </references>

    <references title="Informative References">
      <?rfc ?>

      <reference anchor="LarsAD">
        <front>
          <title>https://mailarchive.ietf.org/arch/msg/ippm/LzcTPYhPhWhbb5-ncR046XKpnzo</title>

          <author fullname="Lars Eggert">
            <organization/>
          </author>

          <date day="2" month="April" year="2008"/>
        </front>
      </reference>

      <reference anchor="TimDISCUSS">
        <front>
          <title>https://datatracker.ietf.org/doc/rfc5357/history/</title>

          <author>
            <organization/>
          </author>

          <date day="16 " month="July" year="2008"/>
        </front>
      </reference>
    </references>
  </back>
</rfc>
