idnits 2.17.1 draft-mirsky-ippm-twamp-refl-registered-port-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC5357, but the abstract doesn't seem to directly say this. It does mention RFC5357 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC5357, updated by this document, for RFC5378 checks: 2005-11-11) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (May 31, 2017) is 2522 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group G. Mirsky 3 Internet-Draft ZTE Corp. 4 Updates: 5357 (if approved) M. Perumal 5 Intended status: Standards Track Ericsson 6 Expires: December 2, 2017 R. Foote 7 Nokia 8 L. M. Contreras 9 Telefonica 10 L. Jalil 11 Verizon 12 May 31, 2017 14 UDP Port Allocation for the Receiver Port in Two-Way Active Measurement 15 Protocol (TWAMP) 16 draft-mirsky-ippm-twamp-refl-registered-port-03 18 Abstract 20 This document arguments and requests re-allocation of an UDP port 21 number from the System Ports range for a Reflector in Two-Way Active 22 Measurement Protocol (TWAMP). This document, if accepted, will be an 23 update to the TWAMP Test protocol specified in RFC 5357. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on December 2, 2017. 42 Copyright Notice 44 Copyright (c) 2017 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 2 61 3. Impact to TWAMP-Control Protocol . . . . . . . . . . . . . . 3 62 4. Impact to TWAMP-Test Protocol . . . . . . . . . . . . . . . . 3 63 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 64 6. Security Considerations . . . . . . . . . . . . . . . . . . . 4 65 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 5 66 8. Normative References . . . . . . . . . . . . . . . . . . . . 5 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5 69 1. Introduction 71 One particular compelling vision of the Two-Way Active Measurement 72 Protocol (TWAMP) [RFC5357] is widespread deployment of open servers 73 that would make IP Performance Metrics (IPPM) measurements a 74 commonplace. This is complemented by the proliferation of the 75 Internet of Things (IoT) devices, such as sensors, and the need for 76 obtaining IPPM measurements from those devices by the service 77 provider. IoT devices are often constrained by limited processing 78 power and memory and benefit from TWAMP Light, as defined in 79 Appendix I [RFC5357]. 81 TWAMP Light provides a simple solution for devices to act as test 82 points in the network, by avoiding the need for the TWAMP-Control 83 protocol [RFC5357]. In the absence of TWAMP-Control, a registered 84 (default) UDP port that can be used as the Receiver Port for TWAMP- 85 Test will simplify configuration and management of the TWAMP-Light 86 test sessions. 88 This document requests re-allocation of the UDP port number from the 89 System Ports range [RFC6335] as Receiver Port for TWAMP-Test. 91 2. Requirements Language 93 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 94 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 95 "OPTIONAL" in this document are to be interpreted as described in 96 [RFC2119]. 98 3. Impact to TWAMP-Control Protocol 100 Section 3.5 [RFC5357] describes in details the process of negotiating 101 value of the Receiver Port. The Control-Client, acting on behalf of 102 the Session-Sender, proposes the port number from the Dynamic Port 103 range [RFC6335]: 105 "The Receiver Port is the desired UDP port to which TWAMP-Test 106 packets will be sent by the Session-Sender (the port where the 107 Session-Reflector is asked to receive test packets). The Receiver 108 Port is also the UDP port from which TWAMP-Test packets will be 109 sent by the Session-Reflector (the Session-Reflector will use the 110 same UDP port to send and receive packets)." 112 But the proposed Receiver Port may be not available, e.g. being in 113 use by other test session or another application. In this case: 115 "... the Server at the Session-Reflector MAY suggest an alternate 116 and available port for this session in the Port field. The 117 Session- Sender either accepts the alternate port, or composes a 118 new Session- Request message with suitable parameters. Otherwise, 119 the Server uses the Accept field to convey other forms of session 120 rejection or failure to the Control Client and MUST NOT suggest an 121 alternate port; in this case, the Port field MUST be set to zero." 123 The allocated TWAMP Receiver Port number Section 5 MAY be advertised 124 by the Server. The Control Client that supports use of the allocated 125 TWAMP Receiver Port MUST accept the port number advertised by the 126 Server. If the Server does not support the allocated TWAMP Receiver 127 Port, then it sends another Session-Request message with new 128 parameters. Thus the deployment of the allocated TWAMP Receiver Port 129 number is backward compatible with existing TWAMP-Control solutions 130 that are based on [RFC5357]. At the same time, use of the UDP port 131 number allocated from the User Port range [RFC6335] will help to 132 avoid the situation when the Server finds the proposed port being 133 already in use. 135 4. Impact to TWAMP-Test Protocol 137 TWAMP-Test may be used to measure IP performance metrics in an Equal 138 Cost Multipath (ECMP) environment. Though algorithms to balance IP 139 flows among available paths had not been standardized, the most 140 common is the Five-tuple that uses destination IP address, source IP 141 address, protocol type, destination port number, and source port 142 number. To attempt to monitor different paths in ECMP network is 143 sufficient to variate only one of five parameters, e.g. the source 144 port number. Thus, there will be no negative impact on ability to 145 have concurrent TWAMP test sessions between the same test points to 146 monitor different paths in the ECMP network when using the allocated 147 UDP port number as the Receiver Port. 149 The allocation of the TWAMP Receiver Port from the User Port Range 150 [RFC6335] benefits TWAMP Light mode of the TWAMP-Test. The allocated 151 UDP port number Section 5 may be used as default value for the 152 Receiver Port to simplify configuration and management of the TWAMP- 153 Light test sessions. 155 5. IANA Considerations 157 The Service Name and Transport Protocol Port Number Registry defined 158 in [RFC6335]. 160 [RFC5357] has been allocated UDP port 862 for TWAMP-Control protocol. 161 IANA is requested to re-assign UDP port 862 as follows: 163 +--------+------+-------+----------------+---------------+----------+ 164 | Servic | Port | Trans | Description | Semantics | Referenc | 165 | e Name | Numb | port | | Definition | e | 166 | | er | Proto | | | | 167 | | | col | | | | 168 +--------+------+-------+----------------+---------------+----------+ 169 | twamp- | 862 | UDP | TWAMP-Test | Section 4 | This | 170 | test | | | Receiver Port | | document | 171 +--------+------+-------+----------------+---------------+----------+ 173 Table 1: TWAMP Receiver Port 175 6. Security Considerations 177 The registered UDP port as the Receiver Port for TWAMP-Test may be 178 used as target of denial-of-service (DoS) or used by man-in-the- 179 middle (MitM) attack. To improve protection from the DoS following 180 methods are recommended: 182 o filtering access to the TWAMP Receiver Port by access list; 184 o non-routable IPs outside of the domain for the TWAMP loopback. 186 MitM attack may try to modify the content of the TWAMP-Test packet 187 thus altering measurement results. An implementation can use data 188 consistency check to detect modification of data. In addition, it 189 can use encryption of TWAMP-Test packets to prevent eavesdropping. 191 7. Acknowledgments 193 TBD 195 8. Normative References 197 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 198 Requirement Levels", BCP 14, RFC 2119, 199 DOI 10.17487/RFC2119, March 1997, 200 . 202 [RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J. 203 Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)", 204 RFC 5357, DOI 10.17487/RFC5357, October 2008, 205 . 207 [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. 208 Cheshire, "Internet Assigned Numbers Authority (IANA) 209 Procedures for the Management of the Service Name and 210 Transport Protocol Port Number Registry", BCP 165, 211 RFC 6335, DOI 10.17487/RFC6335, August 2011, 212 . 214 Authors' Addresses 216 Greg Mirsky 217 ZTE Corp. 219 Email: gregimirsky@gmail.com 221 Muthu Arul Mozhi Perumal 222 Ericsson 223 Ferns Icon 224 Doddanekundi, Mahadevapura 225 Bangalore, Karnataka 560037 226 India 228 Email: p.muthu.arul.mozhi@ericsson.com 230 Richard Foote 231 Nokia 233 Email: footer.foote@nokia.com 234 Luis M. Contreras 235 Telefonica 237 Email: luismiguel.contrerasmurillo@telefonica.com 239 Luay Jalil 240 Verizon 242 Email: luay.jalil@verizon.com