Internet DRAFT - draft-mirsky-ippm-twamp-refl-registered-port
draft-mirsky-ippm-twamp-refl-registered-port
Network Working Group G. Mirsky
Internet-Draft ZTE Corp.
Updates: 5357 (if approved) M. Perumal
Intended status: Standards Track Ericsson
Expires: December 2, 2017 R. Foote
Nokia
L. M. Contreras
Telefonica
L. Jalil
Verizon
May 31, 2017
UDP Port Allocation for the Receiver Port in Two-Way Active Measurement
Protocol (TWAMP)
draft-mirsky-ippm-twamp-refl-registered-port-03
Abstract
This document arguments and requests re-allocation of an UDP port
number from the System Ports range for a Reflector in Two-Way Active
Measurement Protocol (TWAMP). This document, if accepted, will be an
update to the TWAMP Test protocol specified in RFC 5357.
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 http://datatracker.ietf.org/drafts/current/.
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 December 2, 2017.
Copyright Notice
Copyright (c) 2017 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
Mirsky, et al. Expires December 2, 2017 [Page 1]
Internet-Draft Registered Receiver Port Number in TWAMP May 2017
(http://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 Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 2
3. Impact to TWAMP-Control Protocol . . . . . . . . . . . . . . 3
4. Impact to TWAMP-Test Protocol . . . . . . . . . . . . . . . . 3
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4
6. Security Considerations . . . . . . . . . . . . . . . . . . . 4
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 5
8. Normative References . . . . . . . . . . . . . . . . . . . . 5
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5
1. Introduction
One particular compelling vision of the Two-Way Active Measurement
Protocol (TWAMP) [RFC5357] is widespread deployment of open servers
that would make IP Performance Metrics (IPPM) measurements a
commonplace. This is complemented by the proliferation of the
Internet of Things (IoT) devices, such as sensors, and the need for
obtaining IPPM measurements from those devices by the service
provider. IoT devices are often constrained by limited processing
power and memory and benefit from TWAMP Light, as defined in
Appendix I [RFC5357].
TWAMP Light provides a simple solution for devices to act as test
points in the network, by avoiding the need for the TWAMP-Control
protocol [RFC5357]. In the absence of TWAMP-Control, a registered
(default) UDP port that can be used as the Receiver Port for TWAMP-
Test will simplify configuration and management of the TWAMP-Light
test sessions.
This document requests re-allocation of the UDP port number from the
System Ports range [RFC6335] as Receiver Port for TWAMP-Test.
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 in
[RFC2119].
Mirsky, et al. Expires December 2, 2017 [Page 2]
Internet-Draft Registered Receiver Port Number in TWAMP May 2017
3. Impact to TWAMP-Control Protocol
Section 3.5 [RFC5357] describes in details the process of negotiating
value of the Receiver Port. The Control-Client, acting on behalf of
the Session-Sender, proposes the 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)."
But the proposed Receiver Port may be not available, e.g. being in
use by other 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
Session- Sender 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."
The allocated TWAMP Receiver Port number Section 5 MAY be advertised
by the Server. The Control Client that supports use of the allocated
TWAMP Receiver Port MUST accept the port number advertised by the
Server. If the Server does not support the allocated TWAMP Receiver
Port, then it sends another Session-Request message with new
parameters. Thus the deployment of the allocated TWAMP Receiver Port
number is backward compatible with existing TWAMP-Control solutions
that are based on [RFC5357]. At the same time, use of the UDP port
number allocated from the User Port range [RFC6335] will help to
avoid the situation when the Server finds the proposed port being
already in use.
4. Impact to TWAMP-Test Protocol
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 had 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. To attempt to monitor different paths in ECMP network is
sufficient to variate only one of five parameters, e.g. the source
port number. Thus, there will be no negative impact on ability to
have concurrent TWAMP test sessions between the same test points to
Mirsky, et al. Expires December 2, 2017 [Page 3]
Internet-Draft Registered Receiver Port Number in TWAMP May 2017
monitor different paths in the ECMP network when using the allocated
UDP port number as the Receiver Port.
The allocation of the TWAMP Receiver Port from the User Port Range
[RFC6335] benefits TWAMP Light mode of the TWAMP-Test. The allocated
UDP port number Section 5 may be used as default value for the
Receiver Port to simplify configuration and management of the TWAMP-
Light test sessions.
5. IANA Considerations
The Service Name and Transport Protocol Port Number Registry defined
in [RFC6335].
[RFC5357] has been allocated UDP port 862 for TWAMP-Control protocol.
IANA is requested to re-assign UDP port 862 as follows:
+--------+------+-------+----------------+---------------+----------+
| Servic | Port | Trans | Description | Semantics | Referenc |
| e Name | Numb | port | | Definition | e |
| | er | Proto | | | |
| | | col | | | |
+--------+------+-------+----------------+---------------+----------+
| twamp- | 862 | UDP | TWAMP-Test | Section 4 | This |
| test | | | Receiver Port | | document |
+--------+------+-------+----------------+---------------+----------+
Table 1: TWAMP Receiver Port
6. Security Considerations
The registered UDP port as the Receiver Port for TWAMP-Test may be
used as target of denial-of-service (DoS) or used by man-in-the-
middle (MitM) attack. To improve protection from the DoS following
methods are recommended:
o filtering access to the TWAMP Receiver Port by access list;
o non-routable IPs outside of the domain for the TWAMP loopback.
MitM attack may try to modify the content of the TWAMP-Test packet
thus altering measurement results. An implementation can use data
consistency check to detect modification of data. In addition, it
can use encryption of TWAMP-Test packets to prevent eavesdropping.
Mirsky, et al. Expires December 2, 2017 [Page 4]
Internet-Draft Registered Receiver Port Number in TWAMP May 2017
7. Acknowledgments
TBD
8. 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,
<http://www.rfc-editor.org/info/rfc2119>.
[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,
<http://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,
<http://www.rfc-editor.org/info/rfc6335>.
Authors' Addresses
Greg Mirsky
ZTE Corp.
Email: gregimirsky@gmail.com
Muthu Arul Mozhi Perumal
Ericsson
Ferns Icon
Doddanekundi, Mahadevapura
Bangalore, Karnataka 560037
India
Email: p.muthu.arul.mozhi@ericsson.com
Richard Foote
Nokia
Email: footer.foote@nokia.com
Mirsky, et al. Expires December 2, 2017 [Page 5]
Internet-Draft Registered Receiver Port Number in TWAMP May 2017
Luis M. Contreras
Telefonica
Email: luismiguel.contrerasmurillo@telefonica.com
Luay Jalil
Verizon
Email: luay.jalil@verizon.com
Mirsky, et al. Expires December 2, 2017 [Page 6]