UDP Port Allocation for the Receiver Port in Two-Way Active Measurement Protocol (TWAMP)
draft-mirsky-ippm-twamp-refl-registered-port-01

Network Working Group                                          G. Mirsky
Internet-Draft                                                M. Perumal
Updates: 5357 (if approved)                                     Ericsson
Intended status: Standards Track                                R. Foote
Expires: April 16, 2017                                            Nokia
                                                         L. M. Contreras
                                                              Telefonica
                                                        October 13, 2016

UDP Port Allocation for the Receiver Port in Two-Way Active Measurement
                            Protocol (TWAMP)
            draft-mirsky-ippm-twamp-refl-registered-port-01

Abstract

   This document arguments and requests allocation of an UDP port number
   from the User 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 April 16, 2017.

Copyright Notice

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

Mirsky, et al.           Expires April 16, 2017                 [Page 1]
Internet-Draft  Registered Receiver Port Number in TWAMP    October 2016

   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 . . . . . . . . . . . . . . . . . . . . . . .   4
   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 TWAP-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 allocation of the UDP port number from the
   User Port 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 April 16, 2017                 [Page 2]
Internet-Draft  Registered Receiver Port Number in TWAMP    October 2016

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 (TBA) 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 April 16, 2017                 [Page 3]
Internet-Draft  Registered Receiver Port Number in TWAMP    October 2016

   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 (TBA ) 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].

   IANA is requested to reserve a new UDP port number from the User Port
   range as follows:

   +----------+----------------+-----------------------+---------------+
   | UDP Port | Description    | Semantics Definition  | Reference     |
   | Number   |                |                       |               |
   +----------+----------------+-----------------------+---------------+
   | TBA      | TWAMP Receiver | Section 4             | This document |
   |          | Port           |                       |               |
   +----------+----------------+-----------------------+---------------+

                       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.

7.  Acknowledgments

   TBD

Mirsky, et al.           Expires April 16, 2017                 [Page 4]
Internet-Draft  Registered Receiver Port Number in TWAMP    October 2016

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
   Ericsson

   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

   Luis M. Contreras
   Telefonica

   Email: luismiguel.contrerasmurillo@telefonica.com

Mirsky, et al.           Expires April 16, 2017                 [Page 5]