idnits 2.17.1 draft-ietf-ippm-port-twamp-test-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 abstract seems to indicate that this document updates RFC5357, but the header doesn't have an 'Updates:' line to match this. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC4656, updated by this document, for RFC5378 checks: 2000-11-22) -- 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 (November 4, 2018) is 1997 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) == Missing Reference: 'RFCXXXX' is mentioned on line 292, but not defined ** Downref: Normative reference to an Informational RFC: RFC 7594 -- Duplicate reference: RFC5357, mentioned in 'TimDISCUSS', was also mentioned in 'RFC5357'. Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Morton, Ed. 3 Internet-Draft AT&T Labs 4 Updates: 4656 and 5357 (if approved) G. Mirsky, Ed. 5 Intended status: Standards Track ZTE Corp. 6 Expires: May 8, 2019 November 4, 2018 8 OWAMP and TWAMP Well-Known Port Assignments 9 draft-ietf-ippm-port-twamp-test-03 11 Abstract 13 This memo explains the motivation and describes the re-assignment of 14 well-known ports for the OWAMP and TWAMP protocols for control and 15 measurement, and clarifies the meaning and composition of these 16 standards track protocol names for the industry. 18 The memo updates RFC 4656 and RFC 5357, in terms of the UDP well- 19 known port assignments, and clarifies the complete OWAMP and TWAMP 20 protocol composition for the industry. 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 https://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 May 8, 2019. 39 Copyright Notice 41 Copyright (c) 2018 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 (https://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 . . . . . . . . . . . . . . . . . . . . 3 58 3. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 4. Definitions and Background . . . . . . . . . . . . . . . . . 3 60 5. New Well-Known Ports . . . . . . . . . . . . . . . . . . . . 4 61 5.1. Impact on TWAMP-Control Protocol . . . . . . . . . . . . 4 62 5.2. Impact on OWAMP-Control Protocol . . . . . . . . . . . . 5 63 5.3. Impact on OWAMP/TWAMP-Test Protocols . . . . . . . . . . 5 64 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 65 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 66 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 7 67 9. Appendix A . . . . . . . . . . . . . . . . . . . . . . . . . 7 68 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 69 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 70 11.1. Normative References . . . . . . . . . . . . . . . . . . 8 71 11.2. Informative References . . . . . . . . . . . . . . . . . 9 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 74 1. Introduction 76 The IETF IP Performance Metrics (IPPM) working group first developed 77 the One-Way Active Measurement Protocol, OWAMP, specified in 78 [RFC4656]. Further protocol development to support testing resulted 79 in the Two-Way Active Measurement Protocol, TWAMP, specified in 80 [RFC5357]. 82 Both OWAMP and TWAMP require the implementation of a control and mode 83 negotiation protocol (OWAMP-Control and TWAMP-Control) which employs 84 the reliable transport services of TCP (including security 85 configuration and key derivation). The control protocols arrange for 86 the configuration and management of test sessions using the 87 associated test protocol (OWAMP-Test or TWAMP-Test) on UDP transport. 89 This memo recognizes the value of assigning a well-known UDP port to 90 the *-Test protocols, and that this goal can easily be arranged 91 through port re-assignments. 93 2. Requirements Language 95 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 96 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 97 "OPTIONAL" in this document are to be interpreted as described in 98 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, 99 as shown here. 101 3. Scope 103 The scope of this memo is to re-allocate well-known ports for the UDP 104 Test protocols that compose necessary parts of their respective 105 standards track protocols, OWAMP and TWAMP, along with clarifications 106 of the complete protocol composition for the industry. 108 The memo updates [RFC4656] and [RFC5357], in terms of the UDP well- 109 known port assignments. 111 4. Definitions and Background 113 This section defines key terms and clarifies the required composition 114 of the OWAMP and TWAMP standards-track protocols. 116 OWAMP-Control is the protocol defined in Section 3 of [RFC4656]. 118 OWAMP-Test is the protocol defined in Section 4 of [RFC4656]. 120 OWAMP is described in a direct quote from Section 1.1 of[RFC4656]: 121 "OWAMP actually consists of two inter-related protocols: OWAMP- 122 Control and OWAMP-Test." A similar sentence appears in Section 2 of 123 [RFC4656]. Since the consensus of many dictionary definitions of 124 "consist" is "composed or made up of", implementation of both OWAMP- 125 Control and OWAMP-Test are REQUIRED for standards-track OWAMP 126 specified in [RFC4656]. 128 TWAMP-Control is the protocol defined in Section 3 of [RFC5357]. 130 TWAMP-Test is the protocol defined in Section 4 of [RFC5357]. 132 TWAMP is described in a direct quote from Section 1.1 of [RFC5357]: 133 "Similar to OWAMP [RFC4656], TWAMP consists of two inter-related 134 protocols: TWAMP-Control and TWAMP-Test." Since the consensus of 135 many dictionary definitions of "consist" is "composed or made up of", 136 implementation of both TWAMP-Control and TWAMP-Test are REQUIRED for 137 standards-track TWAMP specified in [RFC5357]. 139 TWAMP Light is an idea described in Informative Appendix I of 140 [RFC5357], and includes an un-specified control protocol (possibly 141 communicating through non-standard means) combined with the TWAMP- 142 Test protocol. The TWAMP Light idea was relegated to the 143 Appendix because it failed to meet the requirements for IETF 144 protocols (there are no specifications for negotiating this form of 145 operation, and no specifications for mandatory-to-implement security 146 features), as described in Appendix A of this memo, which cites 147 [LarsAD] and [TimDISCUSS] . 149 Since the idea of TWAMP Light clearly includes the TWAMP-Test 150 component of TWAMP, it is considered reasonable for future systems to 151 use the TWAMP-Test well-known UDP port (whose re-allocated assignment 152 is requested here). Clearly, the TWAMP Light idea envisions many 153 components and communication capabilities beyond TWAMP-Test 154 (implementing the security requirements, for example), otherwise 155 Appendix I of [RFC5357] would be one sentence long (equivocating 156 TWAMP Light with TWAMP-Test only). 158 5. New Well-Known Ports 160 Originally, both TCP and UDP well-known ports were assigned to the 161 control protocols that are essential components of standards track 162 OWAMP and TWAMP. 164 Since OWAMP-Control and TWAMP-Control require TCP transport, they 165 cannot make use of the UDP ports which were originally assigned. 166 However, test sessions using OWAMP-Test or TWAMP-Test operate on UDP 167 transport. 169 This memo requests re-assignment of the UDP well-known port from the 170 Control protocol to the Test protocol (see the IANA Considerations 171 Section 7). Use of this UDP port is OPTIONAL in standards-track 172 OWAMP and TWAMP. It may simplify some operations to have a well- 173 known port available for the Test protocols, or for future 174 specifications involving TWAMP-Test to use this port as a default 175 port. For example, [TR-390] is a specification for testing at the 176 customer edge of IP networks, and whose implememntations should 177 benefit. 179 5.1. Impact on TWAMP-Control Protocol 181 Section 3.5 [RFC5357] describes the detailed process of negotiating 182 the Receiver Port number, on which the TWAMP Session-Reflector will 183 send and receive TWAMP-Test packets. The Control-Client, acting on 184 behalf of the Session-Sender, proposes the Receiver port number from 185 the Dynamic Port range [RFC6335]: 187 "The Receiver Port is the desired UDP port to which TWAMP-Test 188 packets will be sent by the Session-Sender (the port where the 189 Session-Reflector is asked to receive test packets). The Receiver 190 Port is also the UDP port from which TWAMP-Test packets will be 191 sent by the Session-Reflector (the Session-Reflector will use the 192 same UDP port to send and receive packets)." 194 It is possible that the proposed Receiver Port may be not available, 195 e.g., the port is in use by another test session or another 196 application. In this case: 198 "... the Server at the Session-Reflector MAY suggest an alternate 199 and available port for this session in the Port field. The 200 Control-Client either accepts the alternate port, or composes a 201 new Session-Request message with suitable parameters. Otherwise, 202 the Server uses the Accept field to convey other forms of session 203 rejection or failure to the Control Client and MUST NOT suggest an 204 alternate port; in this case, the Port field MUST be set to zero." 206 A Control Client that supports use of the allocated TWAMP-Test 207 Receiver Port Section 7 MAY request to use that port number in the 208 Request-TW-Session Command. If the Server does not support the 209 allocated TWAMP-Test Receiver Port, then it sends an alternate port 210 number in the Accept-Session message with Accept field = 0. Thus the 211 deployment of the allocated TWAMP Receiver Port number is backward 212 compatible with existing TWAMP-Control solutions that are based on 213 [RFC5357]. Of course, use of a UDP port number chosen from the 214 Dynamic Port range [RFC6335] will help to avoid the situation when 215 the Control-Client or Server finds the proposed port being already in 216 use. 218 5.2. Impact on OWAMP-Control Protocol 220 As described above, an OWAMP Control Client that supports use of the 221 allocated OWAMP-Test Receiver Port Section 7 MAY request to use that 222 port number in the Request-Session Command. If the Server does not 223 support the allocated OWAMP-Test Receiver Port (or does not have the 224 port available), then it sends an alternate port number in the 225 Accept-Session message with Accept field = 0. Further exchanges 226 proceed as already specified. 228 5.3. Impact on OWAMP/TWAMP-Test Protocols 230 OWAMP/TWAMP-Test may be used to measure IP performance metrics in an 231 Equal Cost Multipath (ECMP) environment. Though algorithms to 232 balance IP flows among available paths have not been standardized, 233 the most common is the five-tuple that uses destination IP address, 234 source IP address, protocol type, destination port number, and source 235 port number. When attempting to monitor different paths in ECMP 236 network, it is sufficient to vary only one of five parameters, e.g. 238 the source port number. Thus, there will be no negative impact on 239 ability to arrange concurrent OWAMP/TWAMP test sessions between the 240 same test points to monitor different paths in the ECMP network when 241 using the re-allocated UDP port number as the Receiver Port, as use 242 of the port is optional. 244 6. Security Considerations 246 The security considerations that apply to any active measurement of 247 live paths are relevant here as well (see [RFC4656] and [RFC5357]). 249 When considering privacy of those involved in measurement or those 250 whose traffic is measured, the sensitive information available to 251 potential observers is greatly reduced when using active techniques 252 which are within this scope of work. Passive observations of user 253 traffic for measurement purposes raise many privacy issues. We refer 254 the reader to the security and privacy considerations described in 255 the Large Scale Measurement of Broadband Performance (LMAP) Framework 256 [RFC7594], which covers both active and passive techniques. 258 The registered UDP port as the Receiver Port for OWAMP/TWAMP-Test 259 could become a target of denial-of-service (DoS) or used to aid man- 260 in-the-middle (MITM) attacks. To improve protection from the DoS 261 following methods are recommended: 263 o filtering access to the OWAMP/TWAMP Receiver Port by access list; 265 o using a non-globally routable IP address for the OWAMP/TWAMP 266 Session-Reflector address. 268 A MITM attack may try to modify the content of the OWAMP/TWAMP-Test 269 packets in order to alter the measurement results. However, an 270 implementation can use authenticated mode to detect modification of 271 data. In addition, use encrypted mode to prevent eavesdropping and 272 un-detected modification of the OWAMP/TWAMP-Test packets. 274 7. IANA Considerations 276 This memo requests re-allocation of two UDP port numbers from the 277 System Ports range [RFC6335]. Specifically, this memo requests that 278 IANA re-allocate UDP ports 861 and 862 as shown below, leaving the 279 TCP port assignments as-is: 281 +------------+-------+---------+----------------------+-------------+ 282 | Service | Port | Transp. | Description | Reference | 283 | Name | Num. | Protocol| | | 284 | | | | | | 285 +------------+-------+---------+----------------------+-------------+ 286 | owamp- | 861 | tcp | OWAMP-Control | [RFC4656] | 287 | control | | | | | 288 | owamp-test | 861 | udp | OWAMP-Test | [RFCXXXX] | 289 | | | | | | 290 | twamp- | 862 | tcp | TWAMP-Control | [RFC5357] | 291 | control | | | | | 292 | twamp-test | 862 | udp | TWAMP-Test Receiver | [RFCXXXX] | 293 | | | | Port | | 294 +------------+-------+---------+----------------------+-------------+ 296 Table 1 Re-allocated OWAMP and TWAMP Ports 298 where RFCXXXX is this memo when published. The Assignee and Contact 299 should information be updated as follows: 301 Assignee: IESG 303 Contact: IETF Chair 305 8. Contributors 307 Richard Foote and Luis M. Contreras made notable contributions on 308 this topic. 310 9. Appendix A 312 This informative Appendix provides the Background on the decision to 313 move the TWAMP Light idea to an informative Appendix in [RFC5357]. 315 The TWAMP Light idea was relegated to the Appendix because it failed 316 to meet the requirements for IETF protocols (there are no 317 specifications for negotiating this form of operation, and no 318 specifications for mandatory-to-implement security features), as 319 described in the references below: 321 o Lars Eggert's Area Director review [LarsAD], where he pointed out 322 that having two variants of TWAMP, Light and Complete (called 323 standards track TWAMP here), required a protocol mechanism to 324 negotiate which variant will be used. See Lars' comment on Sec 325 5.2. The working group consensus was to place the TWAMP Light 326 description in Appendix I, and to refer to the Appendix only as an 327 "incremental path to adopting TWAMP, by implementing the TWAMP- 328 Test protocol first". 330 o Tim Polk's DISCUSS Ballot, which points out that TWAMP Light was 331 an incomplete specification because the key required for 332 authenticated and encrypted modes depended on the TWAMP-Control 333 Session key. See Tim's DISCUSS on 2008-07-16 [TimDISCUSS]. 334 Additional requirement statements were added in the Appendix to 335 address Tim's DISCUSS Ballot (see the last three paragraphs of 336 Appendix I in [RFC5357]). 338 Since the idea of TWAMP Light clearly includes the TWAMP-Test 339 protocol and other undefined facilities, Appendix I of [RFC5357] 340 simply describes ideas of how TWAMP-Test might be used ouside of the 341 context of Standards-Track TWAMP. 343 10. Acknowledgements 345 The authors thank the IPPM working group for their rapid review; also 346 Muthu Arul Mozhi Perumal and Luay Jalil for their participation and 347 suggestions. 349 11. References 351 11.1. Normative References 353 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 354 Requirement Levels", BCP 14, RFC 2119, 355 DOI 10.17487/RFC2119, March 1997, 356 . 358 [RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M. 359 Zekauskas, "A One-way Active Measurement Protocol 360 (OWAMP)", RFC 4656, DOI 10.17487/RFC4656, September 2006, 361 . 363 [RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J. 364 Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)", 365 RFC 5357, DOI 10.17487/RFC5357, October 2008, 366 . 368 [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. 369 Cheshire, "Internet Assigned Numbers Authority (IANA) 370 Procedures for the Management of the Service Name and 371 Transport Protocol Port Number Registry", BCP 165, 372 RFC 6335, DOI 10.17487/RFC6335, August 2011, 373 . 375 [RFC7594] Eardley, P., Morton, A., Bagnulo, M., Burbridge, T., 376 Aitken, P., and A. Akhter, "A Framework for Large-Scale 377 Measurement of Broadband Performance (LMAP)", RFC 7594, 378 DOI 10.17487/RFC7594, September 2015, 379 . 381 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 382 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 383 May 2017, . 385 11.2. Informative References 387 [LarsAD] "https://mailarchive.ietf.org/arch/msg/ippm/ 388 LzcTPYhPhWhbb5-ncR046XKpnzo", April 2008. 390 [TimDISCUSS] 391 "https://datatracker.ietf.org/doc/rfc5357/history/", July 392 2008. 394 [TR-390] "TR-390 Performance Measurement from IP Edge to Custom er 395 Equipment using TWAMP Light, Issue: 1", May 2017, 396 . 399 Authors' Addresses 401 Al Morton (editor) 402 AT&T Labs 403 200 Laurel Avenue South 404 Middletown, NJ 07748 405 USA 407 Phone: +1 732 420 1571 408 Fax: +1 732 368 1192 409 Email: acmorton@att.com 411 Greg Mirsky (editor) 412 ZTE Corp. 414 Email: gregimirsky@gmail.com