idnits 2.17.00 (12 Aug 2021) /tmp/idnits29514/draft-morton-ippm-port-twamp-test-00.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 (June 25, 2017) is 1790 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 208, 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 3 Internet-Draft AT&T Labs 4 Updates: 4656 and 5357 (if approved) June 25, 2017 5 Intended status: Standards Track 6 Expires: December 27, 2017 8 OWAMP and TWAMP Well-Known Port Assignments 9 draft-morton-ippm-port-twamp-test-00 11 Abstract 13 This memo describes new well-known port assignments for the OWAMP and 14 TWAMP protocols for control and measurement, and clarifies the 15 meaning and composition of these standards track protocol names for 16 the industry. 18 The memo updates RFC 4656 and RFC 5357, in terms of the UDP well- 19 known port assignments. 21 Requirements Language 23 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 24 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 25 document are to be interpreted as described in RFC 2119 [RFC2119]. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on December 27, 2017. 44 Copyright Notice 46 Copyright (c) 2017 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 62 2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 63 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 4. New Well-Known Ports . . . . . . . . . . . . . . . . . . . . 4 65 5. Security Considerations . . . . . . . . . . . . . . . . . . . 4 66 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 67 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 68 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 69 8.1. Normative References . . . . . . . . . . . . . . . . . . 5 70 8.2. Informative References . . . . . . . . . . . . . . . . . 6 71 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6 73 1. Introduction 75 The IETF IP Performance Metrics (IPPM) working group first developed 76 the One-Way Active Measurement Protocol, OWAMP, specified in 77 [RFC4656]. Further protocol development to support testing resulted 78 in the Two-Way Active Measurement Protocol, TWAMP, specified in 79 [RFC5357]. 81 Both OWAMP and TWAMP require the implementation of a control and mode 82 negotiation protocol (OWAMP-Control and TWAMP-Control) which employs 83 the reliable transport services of TCP (including security 84 configuration and key derivation). The control protocols arrange for 85 the configuration and management of test sessions using the 86 associated test protocol (OWAMP-Test or TWAMP-Test) on UDP transport. 88 This memo recognizes the value of assigning a well-known UDP port to 89 the *-Test protocols, and that this goal can easily be arranged 90 through port re-assignments. 92 2. Scope 94 The scope of this memo is to re-allocate well-known ports for the UDP 95 Test protocols that compose necessary parts of their respective 96 standards track protocols, OWAMP and TWAMP (along with clarifications 97 of the complete protocol composition). 99 The memo updates [RFC4656] and [RFC5357], in terms of the UDP well- 100 known port assignments. 102 3. Definitions 104 This section defines key terms and clarifies the required composition 105 of the OWAMP and TWAMP standards-track protocols. 107 OWAMP-Control is the protocol defined in Section 3 of [RFC4656]. 109 OWAMP-Test is the protocol defined in Section 4 of [RFC4656]. 111 OWAMP is described in a direct quote from Section 1.1 of[RFC4656]: 112 "OWAMP actually consists of two inter-related protocols: OWAMP- 113 Control and OWAMP-Test." A similar sentence appears in Section 2 of 114 [RFC4656]. Since the consensus of many dictionary definitions of 115 "consist" is "composed or made up of", implementation of both OWAMP- 116 Control and OWAMP-Test are REQUIRED for standards-track OWAMP for 117 standards-track OWAMP specified in [RFC4656]. 119 TWAMP-Control is the protocol defined in Section 3 of [RFC5357]. 121 TWAMP-Test is the protocol defined in Section 4 of [RFC5357]. 123 TWAMP is described in a direct quote from Section 1.1 of [RFC5357]: 124 "Similar to OWAMP [RFC4656], TWAMP consists of two inter-related 125 protocols: TWAMP-Control and TWAMP-Test." Since the consensus of 126 many dictionary definitions of "consist" is "composed or made up of", 127 implementation of both TWAMP-Control and TWAMP-Test are REQUIRED for 128 standards-track TWAMP specified in [RFC5357]. 130 TWAMP Light is an idea described in Informative Appendix I of 131 [RFC5357], and includes an un-specified control protocol (possibly 132 communicating through non-standard means) combined with the TWAMP- 133 Test protocol. The TWAMP Light idea was relegated to the 134 Appendix because it failed to meet the requirements for IETF 135 protocols (there are no specifications for negotiating this form of 136 operation, and no specifications for mandatory-to-implement security 137 features), as decribed in the references below: 139 o Lars Eggert's Area Director review [LarsAD], where he pointed out 140 that having two variants of TWAMP, Light and Complete (called 141 standards track TWAMP here), required a protocol mechanism to 142 negotiate which variant will be used. See Lars' comment on Sec 143 5.2. The working group consensus was to place the TWAMP Light 144 description in Appendix I, and to refer to the Appendix only as an 145 "incremental path to adopting TWAMP, by implementing the TWAMP- 146 Test protocol first". 148 o Tim Polk's DISCUSS Ballot, which points out that TWAMP Light was 149 an incomplete specification because the key required for 150 authenticated and encrypted modes depended on the TWAMP-Control 151 Session key. See Tim's DISCUSS on 2008-07-16 [TimDISCUSS]. 152 Additional requirement statements were added in the Appendix to 153 address Tim's DISCUSS Ballot (see the last three paragraphs of 154 Appendix I in [RFC5357]). 156 Since the idea of TWAMP Light clearly includes the TWAMP-Test 157 component of TWAMP, it is considered reasonable for future systems to 158 use the TWAMP-Test well-known UDP port (whose re-allocated purpose is 159 requested here). Clearly, the TWAMP Light idea envisions many 160 components and communication capabilities beyond TWAMP-Test 161 (facilitating the security requirements, for example), otherwise the 162 Appendix would be one sentence long (equivocating TWAMP Light with 163 TWAMP-Test). 165 4. New Well-Known Ports 167 Originally, both TCP and UDP well-known ports were assigned to the 168 control protocols that are essential components of standards track 169 OWAMP and TWAMP. 171 Since OWAMP-Control and TWAMP-Control require TCP transport, they 172 cannot make use of the UDP ports which were originally assigned. 173 However, test sessions using OWAMP-Test or TWAMP-Test operate on UDP 174 transport. It may simplify some operations to have a well-known port 175 available for the Test protocols as a default port, and this memo 176 requests re-assignment of the UDP well-known port from the Control 177 protocol to the Test protocol (see the IANA Considerations section). 179 5. Security Considerations 181 The security considerations that apply to any active measurement of 182 live paths are relevant here as well. See [RFC4656] and [RFC5357]. 184 When considering privacy of those involved in measurement or those 185 whose traffic is measured, the sensitive information available to 186 potential observers is greatly reduced when using active techniques 187 which are within this scope of work. Passive observations of user 188 traffic for measurement purposes raise many privacy issues. We refer 189 the reader to the security and privacy considerations described in 190 the Large Scale Measurement of Broadband Performance (LMAP) Framework 191 [RFC7594], which covers both active and passive techniques. 193 6. IANA Considerations 195 This memo requests that IANA re-allocate UDP ports 861 and 862 as 196 shown below, leaving the TCP port assignments as-is: 198 Service Port Protocol Description 200 owamp-control 861 tcp OWAMP-Control [RFC4656] 202 owamp-test 861 udp OWAMP-Test [RFCXXXX] 204 twamp-control 862 tcp Two-way Active Measurement 205 Protocol (TWAMP) Control [RFC5357] 207 twamp-test 862 udp Two-way Active Measurement 208 Protocol (TWAMP) Test [RFCXXXX] 210 where RFCXXXX is this memo when published. 212 7. Acknowledgements 214 The author thanks ... 216 8. References 218 8.1. Normative References 220 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 221 Requirement Levels", BCP 14, RFC 2119, 222 DOI 10.17487/RFC2119, March 1997, 223 . 225 [RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M. 226 Zekauskas, "A One-way Active Measurement Protocol 227 (OWAMP)", RFC 4656, DOI 10.17487/RFC4656, September 2006, 228 . 230 [RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J. 231 Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)", 232 RFC 5357, DOI 10.17487/RFC5357, October 2008, 233 . 235 [RFC7594] Eardley, P., Morton, A., Bagnulo, M., Burbridge, T., 236 Aitken, P., and A. Akhter, "A Framework for Large-Scale 237 Measurement of Broadband Performance (LMAP)", RFC 7594, 238 DOI 10.17487/RFC7594, September 2015, 239 . 241 8.2. Informative References 243 [LarsAD] "https://mailarchive.ietf.org/arch/msg/ippm/ 244 LzcTPYhPhWhbb5-ncR046XKpnzo", April 2008. 246 [TimDISCUSS] 247 "https://datatracker.ietf.org/doc/rfc5357/history/", July 248 2008. 250 Author's Address 252 Al Morton 253 AT&T Labs 254 200 Laurel Avenue South 255 Middletown, NJ 07748 256 USA 258 Phone: +1 732 420 1571 259 Fax: +1 732 368 1192 260 Email: acmorton@att.com 261 URI: http://home.comcast.net/~acmacm/