idnits 2.17.1 draft-mirsky-ippm-twamp-refl-registered-port-01.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 (October 13, 2016) is 2745 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 M. Perumal 4 Updates: 5357 (if approved) Ericsson 5 Intended status: Standards Track R. Foote 6 Expires: April 16, 2017 Nokia 7 L. M. Contreras 8 Telefonica 9 October 13, 2016 11 UDP Port Allocation for the Receiver Port in Two-Way Active Measurement 12 Protocol (TWAMP) 13 draft-mirsky-ippm-twamp-refl-registered-port-01 15 Abstract 17 This document arguments and requests allocation of an UDP port number 18 from the User Ports range for a Reflector in Two-Way Active 19 Measurement Protocol (TWAMP) . This document, if accepted, will be 20 an update to the TWAMP Test protocol specified in RFC 5357. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on April 16, 2017. 39 Copyright Notice 41 Copyright (c) 2016 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 2 58 3. Impact to TWAMP-Control Protocol . . . . . . . . . . . . . . 3 59 4. Impact to TWAMP-Test Protocol . . . . . . . . . . . . . . . . 3 60 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 61 6. Security Considerations . . . . . . . . . . . . . . . . . . . 4 62 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 4 63 8. Normative References . . . . . . . . . . . . . . . . . . . . 5 64 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5 66 1. Introduction 68 One particular compelling vision of the Two-Way Active Measurement 69 Protocol (TWAMP) [RFC5357] is widespread deployment of open servers 70 that would make IP Performance Metrics (IPPM) measurements a 71 commonplace. This is complemented by the proliferation of the 72 Internet of Things (IoT) devices, such as sensors, and the need for 73 obtaining IPPM measurements from those devices by the service 74 provider. IoT devices are often constrained by limited processing 75 power and memory and benefit from TWAMP Light, as defined in 76 Appendix I [RFC5357]. 78 TWAMP Light provides a simple solution for devices to act as test 79 points in the network, by avoiding the need for the TWAMP-Control 80 protocol [RFC5357]. In the absence of TWAP-Control, a registered 81 (default) UDP port that can be used as the Receiver Port for TWAMP- 82 Test will simplify configuration and management of the TWAMP-Light 83 test sessions. 85 This document requests allocation of the UDP port number from the 86 User Port range [RFC6335] as Receiver Port for TWAMP-Test. 88 2. Requirements Language 90 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 91 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 92 "OPTIONAL" in this document are to be interpreted as described in 93 [RFC2119]. 95 3. Impact to TWAMP-Control Protocol 97 Section 3.5 [RFC5357] describes in details the process of negotiating 98 value of the Receiver Port. The Control-Client, acting on behalf of 99 the Session-Sender, proposes the port number from the Dynamic Port 100 range [RFC6335]: 102 "The Receiver Port is the desired UDP port to which TWAMP-Test 103 packets will be sent by the Session-Sender (the port where the 104 Session-Reflector is asked to receive test packets). The Receiver 105 Port is also the UDP port from which TWAMP-Test packets will be 106 sent by the Session-Reflector (the Session-Reflector will use the 107 same UDP port to send and receive packets)." 109 But the proposed Receiver Port may be not available, e.g. being in 110 use by other test session or another application. In this case: 112 "... the Server at the Session-Reflector MAY suggest an alternate 113 and available port for this session in the Port field. The 114 Session- Sender either accepts the alternate port, or composes a 115 new Session- Request message with suitable parameters. Otherwise, 116 the Server uses the Accept field to convey other forms of session 117 rejection or failure to the Control Client and MUST NOT suggest an 118 alternate port; in this case, the Port field MUST be set to zero." 120 The allocated TWAMP Receiver Port number (TBA) MAY be advertised by 121 the Server. The Control Client that supports use of the allocated 122 TWAMP Receiver Port MUST accept the port number advertised by the 123 Server. If the Server does not support the allocated TWAMP Receiver 124 Port, then it sends another Session-Request message with new 125 parameters. Thus the deployment of the allocated TWAMP Receiver Port 126 number is backward compatible with existing TWAMP-Control solutions 127 that are based on [RFC5357]. At the same time, use of the UDP port 128 number allocated from the User Port range [RFC6335] will help to 129 avoid the situation when the Server finds the proposed port being 130 already in use. 132 4. Impact to TWAMP-Test Protocol 134 TWAMP-Test may be used to measure IP performance metrics in an Equal 135 Cost Multipath (ECMP) environment. Though algorithms to balance IP 136 flows among available paths had not been standardized, the most 137 common is the Five-tuple that uses destination IP address, source IP 138 address, protocol type, destination port number, and source port 139 number. To attempt to monitor different paths in ECMP network is 140 sufficient to variate only one of five parameters, e.g. the source 141 port number. Thus, there will be no negative impact on ability to 142 have concurrent TWAMP test sessions between the same test points to 143 monitor different paths in the ECMP network when using the allocated 144 UDP port number as the Receiver Port. 146 The allocation of the TWAMP Receiver Port from the User Port Range 147 [RFC6335] benefits TWAMP Light mode of the TWAMP-Test. The allocated 148 UDP port number (TBA ) may be used as default value for the Receiver 149 Port to simplify configuration and management of the TWAMP-Light test 150 sessions. 152 5. IANA Considerations 154 The Service Name and Transport Protocol Port Number Registry defined 155 in [RFC6335]. 157 IANA is requested to reserve a new UDP port number from the User Port 158 range as follows: 160 +----------+----------------+-----------------------+---------------+ 161 | UDP Port | Description | Semantics Definition | Reference | 162 | Number | | | | 163 +----------+----------------+-----------------------+---------------+ 164 | TBA | TWAMP Receiver | Section 4 | This document | 165 | | Port | | | 166 +----------+----------------+-----------------------+---------------+ 168 Table 1: TWAMP Receiver Port 170 6. Security Considerations 172 The registered UDP port as the Receiver Port for TWAMP-Test may be 173 used as target of denial-of-service (DoS) or used by man-in-the- 174 middle (MitM) attack. To improve protection from the DoS following 175 methods are recommended: 177 o filtering access to the TWAMP Receiver Port by access list; 179 o non-routable IPs outside of the domain for the TWAMP loopback. 181 MitM attack may try to modify the content of the TWAMP-Test packet 182 thus altering measurement results. An implementation can use data 183 consistency check to detect modification of data. In addition, it 184 can use encryption of TWAMP-Test packets to prevent eavesdropping. 186 7. Acknowledgments 188 TBD 190 8. Normative References 192 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 193 Requirement Levels", BCP 14, RFC 2119, 194 DOI 10.17487/RFC2119, March 1997, 195 . 197 [RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J. 198 Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)", 199 RFC 5357, DOI 10.17487/RFC5357, October 2008, 200 . 202 [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. 203 Cheshire, "Internet Assigned Numbers Authority (IANA) 204 Procedures for the Management of the Service Name and 205 Transport Protocol Port Number Registry", BCP 165, 206 RFC 6335, DOI 10.17487/RFC6335, August 2011, 207 . 209 Authors' Addresses 211 Greg Mirsky 212 Ericsson 214 Email: gregimirsky@gmail.com 216 Muthu Arul Mozhi Perumal 217 Ericsson 218 Ferns Icon 219 Doddanekundi, Mahadevapura 220 Bangalore, Karnataka 560037 221 India 223 Email: p.muthu.arul.mozhi@ericsson.com 225 Richard Foote 226 Nokia 228 Email: footer.foote@nokia.com 230 Luis M. Contreras 231 Telefonica 233 Email: luismiguel.contrerasmurillo@telefonica.com