OWAMP and TWAMP Well-Known Port
AssignmentsAT&T Labs200 Laurel Avenue SouthMiddletownNJ07748USA+1 732 420 1571+1 732 368 1192acmorton@att.comZTE Corp.gregimirsky@gmail.comThis 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.The IETF IP Performance Metrics (IPPM) working group first developed
the One-Way Active Measurement Protocol, OWAMP, specified in . 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.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 when, and only when, they
appear in all capitals, as shown here.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 and , in terms of the UDP well-known port assignments.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 .OWAMP-Test is the protocol defined in Section 4 of .OWAMP is described in a direct quote from Section 1.1 of: "OWAMP actually consists of two inter-related
protocols: OWAMP-Control and OWAMP-Test." A similar sentence appears in
Section 2 of . 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 .TWAMP-Control is the protocol defined in Section 3 of .TWAMP-Test is the protocol defined in Section 4 of .TWAMP is described in a direct quote from Section 1.1 of : "Similar to OWAMP , 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 .TWAMP Light is an idea described in Informative Appendix I of , 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:Lars Eggert's Area Director review , 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".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 . Additional requirement statements were added
in the Appendix to address Tim's DISCUSS Ballot (see the last three
paragraphs of Appendix I in ).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).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 which were originally assigned.
However, test sessions using OWAMP-Test or TWAMP-Test operate on UDP
transport.This memo requests re-assignment of the UDP well-known port from the
Control protocol to the Test protocol (see the IANA Considerations ). 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.Section 3.5 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 : "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 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 . Of course, use of a UDP port number
chosen from the Dynamic Port range will help
to avoid the situation when the Control-Client or Server finds the
proposed port being already in use.As described above, an OWAMP Control Client that supports use of
the allocated OWAMP-Test Receiver Port 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.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.The security considerations that apply to any active measurement of
live paths are relevant here as well (see and
).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 , 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: filtering access to the OWAMP/TWAMP Receiver Port by access
list;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.This memo requests re-allocation of two UDP port numbers from the
System Ports range . Specifically, this memo
requests that IANA re-allocate UDP ports 861 and 862 as shown below,
leaving the TCP port assignments as-is:where RFCXXXX is this memo when published.Richard Foote and Luis M. Contreras made notable contributions on
this topic.The authors thank the IPPM working group for their rapid review; also
Muthu Arul Mozhi Perumal and Luay Jalil for their participation and
suggestions.https://mailarchive.ietf.org/arch/msg/ippm/LzcTPYhPhWhbb5-ncR046XKpnzohttps://datatracker.ietf.org/doc/rfc5357/history/