idnits 2.17.1 draft-ietf-ippm-owamp-registry-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 220 has weird spacing: '... Shared thi...' (Using the creation date from RFC4656, updated by this document, for RFC5378 checks: 2000-11-22) -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (August 26, 2015) is 3166 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) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 2 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 (if approved) August 26, 2015 5 Intended status: Standards Track 6 Expires: February 27, 2016 8 Registries for the One-Way Active Measurement Protocol - OWAMP 9 draft-ietf-ippm-owamp-registry-01 11 Abstract 13 This memo describes the registries for OWAMP - the One-Way Active 14 Measurement Protocol. The registries allow assignment of MODE bit 15 positions and OWAMP Command numbers. The memo also requests that 16 IANA establish the registries for new features, called the OWAMP- 17 Modes registry and the OWAMP Control Command Number registry. This 18 memo updates RFC 4656. 20 Requirements Language 22 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 23 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 24 document are to be interpreted as described in RFC 2119 [RFC2119]. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on February 27, 2016. 43 Copyright Notice 45 Copyright (c) 2015 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 This document may contain material from IETF Documents or IETF 59 Contributions published or made publicly available before November 60 10, 2008. The person(s) controlling the copyright in some of this 61 material may not have granted the IETF Trust the right to allow 62 modifications of such material outside the IETF Standards Process. 63 Without obtaining an adequate license from the person(s) controlling 64 the copyright in such materials, this document may not be modified 65 outside the IETF Standards Process, and derivative works of it may 66 not be created outside the IETF Standards Process, except to format 67 it for publication as an RFC or to translate it into languages other 68 than English. 70 Table of Contents 72 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 73 2. Purpose and Scope . . . . . . . . . . . . . . . . . . . . . . 3 74 3. IANA Considerations for OWAMP Control Registries . . . . . . 3 75 3.1. Control Command Number Registry . . . . . . . . . . . . . 3 76 3.1.1. Registry Specification . . . . . . . . . . . . . . . 3 77 3.1.2. Registry Management . . . . . . . . . . . . . . . . . 4 78 3.1.3. Experimental Numbers . . . . . . . . . . . . . . . . 4 79 3.1.4. OWAMP-Control Command Numbers Initial Contents . . . 4 80 3.2. OWAMP-Modes . . . . . . . . . . . . . . . . . . . . . . . 4 81 3.2.1. Registry Specification . . . . . . . . . . . . . . . 4 82 3.2.2. Registry Management . . . . . . . . . . . . . . . . . 5 83 3.2.3. Experimental Numbers . . . . . . . . . . . . . . . . 5 84 3.2.4. OWAMP-Modes Initial Contents . . . . . . . . . . . . 5 85 4. Security Considerations . . . . . . . . . . . . . . . . . . . 6 86 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 87 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 88 6.1. Normative References . . . . . . . . . . . . . . . . . . 6 89 6.2. Informative References . . . . . . . . . . . . . . . . . 7 90 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7 92 1. Introduction 94 The One-way Active Measurement Protocol, OWAMP [RFC4656] was prepared 95 to support measurements of metrics specified by the IP Performance 96 Metrics (IPPM) working group in the IETF. The Two-Way Active 97 Measurement Protocol, TWAMP [RFC5357] is an extension of OWAMP. The 98 TWAMP specification gathered wide review as it approached completion, 99 and the by-products were several recommendations for new features in 100 TWAMP. As a result, a registry of new features was established for 101 TWAMP. However, there were no new features proposed for OWAMP until 102 recently [I-D.ietf-ippm-ipsec]. 104 This memo establishes the needed registries for OWAMP, and updates 105 [RFC4656]. 107 2. Purpose and Scope 109 The purpose and scope of this memo is to describe and request the 110 establishment of registries for future OWAMP [RFC4656] extensions. 111 IANA already administrates the "Two-way Active Measurement Protocol 112 (TWAMP) Parameters", and this request follows a similar form (with 113 one exception identified below). 115 This memo also provides the initial contents for the OWAMP 116 registries. 118 3. IANA Considerations for OWAMP Control Registries 120 OWAMP-Control protocol coordinates the measurement capability. All 121 OWAMP-Control messages follow specifications defined in section 3 of 122 [RFC4656]. 124 3.1. Control Command Number Registry 126 IANA is requested to create a OWAMP-Control Command Number registry. 128 OWAMP-Control Commands follow specifications defined in section 3.4 129 of [RFC4656]. 131 3.1.1. Registry Specification 133 OWAMP-Control Commands Numbers are specified in the first octet of 134 OWAMP-Control-Client command messages consistent with section 3 of 135 [RFC4656]. There are a maximum of 256 command numbers. 137 3.1.2. Registry Management 139 Because the "OWAMP-Control Command Numbers" registry can contain only 140 256 values, and because OWAMP is an IETF protocol, these registries 141 MUST be updated only by "IETF Consensus" as specified in [RFC5226] 142 (an RFC that documents registry use and is approved by the IESG). 144 3.1.3. Experimental Numbers 146 One experimental value is currently assigned in the Command Numbers 147 Registry, as indicated in the initial contents below. 149 3.1.4. OWAMP-Control Command Numbers Initial Contents 151 OWAMP-Control Commands follows the procedure defined in section 3.5 152 of [RFC4656] (and in the remainder of section 3). 154 The complete set of OWAMP-Control Command Numbers are as follows 155 (including one reserved bit position): 157 OWAMP-Control Command Numbers Registry 159 Value Description Semantics Reference 160 Definition 161 ========================================================== 162 0 Reserved 163 1 Request-Session Section 3.5 RFC 4656 164 2 Start-Sessions Section 3.7 RFC 4656 165 3 Stop-Sessions Section 3.8 RFC 4656 166 4 Fetch-Sessions Section 3.9 RFC 4656 167 5-253 Unassigned 168 254 Experimentation This Memo 169 255 Reserved 171 3.2. OWAMP-Modes 173 IANA is requested to create an OWAMP-Modes registry. 175 3.2.1. Registry Specification 177 OWAMP-Modes are specified in OWAMP Server Greeting messages and Set- 178 up Response messages consistent with section 3.1 of [RFC4656]. Modes 179 are currently indicated by setting single bits in the 32-bit Modes 180 Field. However, more complex encoding may be used in the future. 182 3.2.2. Registry Management 184 Because the "OWAMP-Modes" are based on only 32 bit positions with 185 each position conveying a unique feature, and because OWAMP is an 186 IETF protocol, these registries MUST be updated only by "IETF 187 Consensus" as specified in [RFC5226] (an RFC that documents registry 188 use and is approved by the IESG). IANA SHOULD allocate monotonically 189 increasing bit positions when requested. 191 3.2.3. Experimental Numbers 193 No experimental bit positions are currently assigned in the Modes 194 Registry, as indicated in the initial contents below. 196 3.2.4. OWAMP-Modes Initial Contents 198 OWAMP-Control connection establishment follows the procedure defined 199 in section 3.1 of [RFC4656]. 201 In the OWAMP-Modes registry, assignments are straightforward on the 202 basis of bit positions, and there are no references to values - this 203 is a difference from the comparable TWAMP registry (and a topic for 204 improvement in the TWAMP-Modes registry which is reconciled in 205 [I-D.ietf-ippm-ipsec]). 207 An Extension of the OWAMP-Modes is proposed in [I-D.ietf-ippm-ipsec]. 208 With this extension, the complete set of OWAMP Mode bit positions are 209 as follows (including one reserved bit position): 211 OWAMP-Modes Registry 213 Bit Semantics 214 Pos. Description Definition Reference 215 ===================================================== 216 0 Unauthenticated Section 3.1 RFC4656 217 1 Authenticated Section 3.1 RFC4656 218 2 Encrypted Section 3.1 RFC4656 219 3 Reserved this memo 220 4 IKEv2-derived Shared this memo and 221 Secret Key Section 5 RFC_TBD 222 5-31 Unassigned 224 (where RFC_TBD the published version of draft-ietf-ippm-ipsec) 226 In the original OWAMP Modes field, setting bit position 0, 1 or 2 227 indicated the security mode of the Control protocol, and the Test 228 protocol inherited the same mode (see section 4 of [RFC4656]). 230 The value of the Modes Field sent by the Server in the Server- 231 Greeting message is the bit-wise OR of the modes (bit positions) that 232 it is willing to support during this session. Thus, the five least 233 significant bits of the Modes 32-bit Field are used. When no other 234 features are activated, the 27 most significant bits MUST be zero. A 235 Control-Client conforming to [RFC4656] MAY ignore the values in the 236 29 most significant bits of the Modes Field, or it MAY support 237 features that are communicated in other bit positions, such as the 238 IKEv2-derived Shared Secret Key extension [I-D.ietf-ippm-ipsec]. 240 OWAMP and TWAMP registries for Modes may grow to contain different 241 features and functions due to the inherent differences in one-way and 242 two-way measurement configurations and the metrics they measure. No 243 attempt will be made to coordinate them unnecessarily, except the 244 Reserved bit position 3 above. This is available for assignment if a 245 mixed security mode similar to[RFC5618] is defined for OWAMP, and 246 would allow alignment with the comparable TWAMP feature. 248 4. Security Considerations 250 As this memo simply requests the creation of OWAMP registries, it 251 presents no new security or privacy issues for the Internet. 253 The security considerations that apply to any active measurement of 254 live networks are relevant here as well. See [RFC4656] and 255 [RFC5357]. 257 Privacy considerations for measurement systems, particularly when 258 Internet users participate in the tests in some way, are described in 259 [I-D.ietf-lmap-framework]. 261 5. Acknowledgements 263 The author would like to thank Kostas Pentikousis, Nalini Elkins, 264 Mike Ackermann, and Greg Mirsky for insightful reviews and comments. 266 6. References 268 6.1. Normative References 270 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 271 Requirement Levels", BCP 14, RFC 2119, 272 DOI 10.17487/RFC2119, March 1997, 273 . 275 [RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M. 276 Zekauskas, "A One-way Active Measurement Protocol 277 (OWAMP)", RFC 4656, DOI 10.17487/RFC4656, September 2006, 278 . 280 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 281 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 282 DOI 10.17487/RFC5226, May 2008, 283 . 285 [RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J. 286 Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)", 287 RFC 5357, DOI 10.17487/RFC5357, October 2008, 288 . 290 6.2. Informative References 292 [I-D.ietf-ippm-ipsec] 293 Pentikousis, K., Zhang, E., and Y. Cui, "IKEv2-derived 294 Shared Secret Key for O/TWAMP", draft-ietf-ippm-ipsec-11 295 (work in progress), August 2015. 297 [I-D.ietf-lmap-framework] 298 Eardley, P., Morton, A., Bagnulo, M., Burbridge, T., 299 Aitken, P., and A. Akhter, "A framework for Large-Scale 300 Measurement of Broadband Performance (LMAP)", draft-ietf- 301 lmap-framework-14 (work in progress), April 2015. 303 [RFC5618] Morton, A. and K. Hedayat, "Mixed Security Mode for the 304 Two-Way Active Measurement Protocol (TWAMP)", RFC 5618, 305 DOI 10.17487/RFC5618, August 2009, 306 . 308 Author's Address 310 Al Morton 311 AT&T Labs 312 200 Laurel Avenue South 313 Middletown,, NJ 07748 314 USA 316 Phone: +1 732 420 1571 317 Fax: +1 732 368 1192 318 Email: acmorton@att.com 319 URI: http://home.comcast.net/~acmacm/