idnits 2.17.1 draft-ietf-ippm-more-twamp-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 mention this, which it should. 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 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 (May 20, 2009) is 5448 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: '0-31' is mentioned on line 292, but not defined == Unused Reference: 'RFC5226' is defined on line 329, but no explicit reference was found in the text ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 3 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: 5357 (if approved) K. Hedayat 5 Intended status: Standards Track EXFO 6 Expires: November 21, 2009 May 20, 2009 8 More Features for the Two-Way Active Measurement Protocol - TWAMP 9 draft-ietf-ippm-more-twamp-02 11 Status of this Memo 13 This Internet-Draft is submitted to IETF in full conformance with the 14 provisions of BCP 78 and BCP 79. This document may contain material 15 from IETF Documents or IETF Contributions published or made publicly 16 available before November 10, 2008. The person(s) controlling the 17 copyright in some of this material may not have granted the IETF 18 Trust the right to allow modifications of such material outside the 19 IETF Standards Process. Without obtaining an adequate license from 20 the person(s) controlling the copyright in such materials, this 21 document may not be modified outside the IETF Standards Process, and 22 derivative works of it may not be created outside the IETF Standards 23 Process, except to format it for publication as an RFC or to 24 translate it into languages other than English. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF), its areas, and its working groups. Note that 28 other groups may also distribute working documents as Internet- 29 Drafts. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 The list of current Internet-Drafts can be accessed at 37 http://www.ietf.org/ietf/1id-abstracts.txt. 39 The list of Internet-Draft Shadow Directories can be accessed at 40 http://www.ietf.org/shadow.html. 42 This Internet-Draft will expire on November 21, 2009. 44 Copyright Notice 46 Copyright (c) 2009 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 in effect on the date of 51 publication of this document (http://trustee.ietf.org/license-info). 52 Please review these documents carefully, as they describe your rights 53 and restrictions with respect to this document. 55 Abstract 57 This memo describes a simple extension to TWAMP - the Two-Way Active 58 Measurement Protocol. The extension adds the option to use different 59 security modes in the TWAMP-Control and TWAMP-Test protocols 60 simultaneously. The memo also requests that IANA establish a 61 registry for additional new features, called the TWAMP-Modes 62 registry. 64 Requirements Language 66 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 67 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 68 document are to be interpreted as described in RFC 2119 [RFC2119]. 70 Table of Contents 72 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 73 2. Purpose and Scope . . . . . . . . . . . . . . . . . . . . . . . 4 74 3. TWAMP Control Extensions . . . . . . . . . . . . . . . . . . . 4 75 3.1. Extended Control Connection Setup . . . . . . . . . . . . . 5 76 4. Extended TWAMP Test . . . . . . . . . . . . . . . . . . . . . . 6 77 4.1. Sender Behavior . . . . . . . . . . . . . . . . . . . . . . 7 78 4.1.1. Packet Timings . . . . . . . . . . . . . . . . . . . . 7 79 4.1.2. Packet Format and Content . . . . . . . . . . . . . . . 7 80 4.2. Reflector Behavior . . . . . . . . . . . . . . . . . . . . 7 81 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 82 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8 83 6.1. Registry Specification . . . . . . . . . . . . . . . . . . 8 84 6.2. Registry Management . . . . . . . . . . . . . . . . . . . . 8 85 6.3. Experimental Numbers . . . . . . . . . . . . . . . . . . . 8 86 6.4. Initial Registry Contents . . . . . . . . . . . . . . . . . 8 87 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 88 8. Normative References . . . . . . . . . . . . . . . . . . . . . 9 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 91 1. Introduction 93 The Two-Way Active Measurement Protocol, TWAMP [RFC5357] is an 94 extension of the One-way Active Measurement Protocol, OWAMP 95 [RFC4656]. The TWAMP specification gathered wide review as it 96 approached completion, and the by-products were several 97 recommendations for new features in TWAMP. There is a growing number 98 TWAMP implementations at present, and wide-spread usage is expected. 99 There are even devices that are designed to test implementations for 100 protocol compliance. 102 This memo describes a simple extension for TWAMP, the option to use 103 different security modes in the TWAMP-Control and TWAMP-Test 104 protocols (mixed security mode). It also requests that IANA 105 establish a registry for additional new features, called the TWAMP- 106 Modes registry. 108 When the Server and Control-Client have agreed to use the mixed 109 security mode during control connection setup, then the Control- 110 Client, the Server, the Session-Sender and the Session-Reflector MUST 111 all conform to the requirements of this mode as described in sections 112 3, 4, and 5. 114 This memo updates [RFC5357]. 116 2. Purpose and Scope 118 The purpose of this memo is to describe and specify an extension for 119 TWAMP [RFC5357], and request the establishment of a registry for 120 future TWAMP extensions. 122 The scope of the memo is limited to specifications of the following: 124 o Extension of the modes of operation through assignment of one new 125 value in the Mode field (see section 3.1 of [RFC4656]), while 126 retaining backward compatibility with TWAMP [RFC5357] 127 implementations. This value adds the OPTIONAL ability to use 128 different security modes in the TWAMP-Control and TWAMP-Test 129 protocols. The motivation for this extension is to permit the low 130 packet rate TWAMP-Control protocol to utilize a stronger mode of 131 integrity protection than that used in the TWAMP-Test protocol. 133 3. TWAMP Control Extensions 135 TWAMP-Control protocol is a derivative of the OWAMP-Control protocol, 136 and coordinates a two-way measurement capability. All TWAMP Control 137 messages are similar in format and follow similar guidelines to those 138 defined in section 3 of [RFC4656] with the exceptions described in 139 TWAMP [RFC5357], and in the following sections. 141 All OWAMP-Control messages apply to TWAMP-Control, except for the 142 Fetch Session command. 144 3.1. Extended Control Connection Setup 146 TWAMP-Control connection establishment follows the same procedure 147 defined in section 3.1 of [RFC4656]. This extended mode assigns one 148 new bit position (and value) to allow the Test protocol security mode 149 to operate in Unauthenticated mode, while the Control protocol 150 operates in Encrypted mode. With this extension, the complete set of 151 TWAMP Mode values are as follows: 153 Value Description Reference/Explanation 154 0 Reserved 155 1 Unauthenticated RFC4656, Section 3.1 156 2 Authenticated RFC4656, Section 3.1 157 4 Encrypted RFC4656, Section 3.1 158 8 Unauth. TEST protocol, new bit position (3) 159 Encrypted CONTROL 161 In the original OWAMP and TWAMP Modes field, setting bit position 0, 162 1 or 2 indicated the security mode of the Control protocol, and the 163 Test protocol inherited the same mode (see section 4 of [RFC4656]). 165 In this extension to TWAMP, when the Control-Client sets Modes Field 166 bit position 3, it SHALL discontinue the inheritance of the security 167 mode in the Test protocol, and each protocol's mode SHALL be as 168 specified below. When the desired TWAMP-Test protocol mode is 169 identical to the Control Session mode, the corresponding Modes Field 170 bit (position 0, 1 or 2) SHALL be set by the Control-Client. The 171 table below gives the various combinations of integrity protection 172 that are permissible in TWAMP (with this extension). The TWAMP- 173 Control and TWAMP-Test protocols SHALL use the mode in each column 174 corresponding to the bit position set in the Modes Field. 176 -------------------------------------------------------- 177 Protocol | Permissible Mode Combinations (Modes bit set) 178 -------------------------------------------------------- 179 Control | Unauth.(0)| Auth. == Encrypted (1,2,3) 180 -------------------------------------------------------- 181 | Unauth.(0)| Unauth. (3) 182 ----------------------------------------------- 183 Test | | Auth.(1) 184 ----------------------------------------------- 185 | | Encrypted (2) 186 -------------------------------------------------------- 188 Note that the TWAMP-Control protocol security measures are identical 189 in the Authenticated and Encrypted Modes. Therefore, only one new 190 bit position (3) is needed to convey the single mixed security mode. 192 The value of the Modes Field sent by the Server in the Server- 193 Greeting message is the bit-wise OR of the modes (bit positions) that 194 it is willing to support during this session. Thus, the last four 195 bits of the Modes 32-bit Field are used. When no other features are 196 activated, the first 28 bits MUST be zero. A client conforming to 197 this extension of [RFC5357] MAY ignore the values in the first 28 198 bits of the Modes Field, or it MAY support other features that are 199 communicated in these bit positions. 201 Other ways in which TWAMP extends OWAMP are described in [RFC5357]. 203 4. Extended TWAMP Test 205 The TWAMP test protocol is similar to the OWAMP [RFC4656] test 206 protocol with the exception that the Session-Reflector transmits test 207 packets to the Session-Sender in response to each test packet it 208 receives. TWAMP [RFC5357] defines two different test packet formats, 209 one for packets transmitted by the Session-Sender and one for packets 210 transmitted by the Session-Reflector. As with OWAMP-Test protocol 211 there are three security modes that also determine the test packet 212 format: unauthenticated, authenticated, and encrypted. This TWAMP 213 extension makes it possible to use TWAMP-Test Unauthenticated mode 214 regardless of the mode used in the TWAMP-Control protocol. 216 When the Server has identified the ability to support the mixed 217 security mode, the Control-Client has selected the mixed security 218 mode in its Set-Up-Response, and the Server responds with a zero 219 Accept field in the Server-Start message, these extensions are 220 REQUIRED. 222 4.1. Sender Behavior 224 This section describes extensions to the behavior of the TWAMP 225 Session-Sender. 227 4.1.1. Packet Timings 229 The Send Schedule is not utilized in TWAMP, and there are no 230 extensions defined in this memo. 232 4.1.2. Packet Format and Content 234 The Session-Sender packet format and content MUST follow the same 235 procedure and guidelines as defined in section 4.1.2 of [RFC4656] and 236 section 4.1.2 of [RFC5357], with the following exceptions: 238 o the Send Schedule is not used, and 240 o the Session-Sender MUST support the mixed security mode 241 (Unauthenticated TEST, Encrypted CONTROL, value 8, bit position 3) 242 defined in section 3.1 of this memo. 244 4.2. Reflector Behavior 246 The TWAMP Session-Reflector is REQUIRED to follow the procedures and 247 guidelines in section 4.2 of [RFC5357], with the following 248 extensions: 250 o the Session-Reflector MUST support the mixed security mode 251 (Unauthenticated TEST, Encrypted CONTROL, value 8, bit position 3) 252 defined in section 3.1 of this memo. 254 5. Security Considerations 256 The extended mixed-mode of operation permits stronger security/ 257 integrity protection on the TWAMP-Control protocol while 258 simultaneously emphasizing accuracy or efficiency on the TWAMP-Test 259 protocol, thus making it possible to increase overall security when 260 compared to the previous options. 262 The security considerations that apply to any active measurement of 263 live networks are relevant here as well. See [RFC4656] and 264 [RFC5357]. 266 6. IANA Considerations 268 This memo adds one security mode bit position/value beyond those in 269 the OWAMP-Control specification[RFC4656], and describes behavior when 270 the new mode is used. This memo requests creation of an IANA 271 registry for the TWAMP Modes field. This field is a recognized 272 extension mechanism for TWAMP. 274 6.1. Registry Specification 276 IANA is requested to create a TWAMP-Modes registry. TWAMP-Modes are 277 specified in TWAMP Server Greeting messages and Set-up Response 278 messages consistent with section 3.1 of [RFC4656] and section 3.1 of 279 [RFC5357], and extended by this memo. Modes are currently indicated 280 by setting single bits in the 32-bit Modes Field. However, more 281 complex encoding may be used in the future. Thus, this registry can 282 contain a total of 2^32 possible assignments. 284 6.2. Registry Management 286 Because the TWAMP-Modes registry can contain a maximum of 2^32 287 values, and because TWAMP is an IETF protocol, this registry must be 288 updated only by "IETF Review" as specified in [RFC5226](an RFC 289 documenting registry use that is approved by the IESG). For the 290 TWAMP-Modes registry, we expect that new features will be assigned 291 using monotonically increasing single bit positions and in the range 292 [0-31], unless there is a good reason to do otherwise (more complex 293 encoding than single bit positions may be used in the future, to 294 access the 2^32 value space). 296 6.3. Experimental Numbers 298 No experimental values are currently assigned for the Modes Registry. 300 6.4. Initial Registry Contents 302 TWAMP Modes Registry 303 Value Description Semantics Definition 304 0 Reserved 306 1 Unauthenticated RFC4656, Section 3.1 308 2 Authenticated RFC4656, Section 3.1 310 4 Encrypted RFC4656, Section 3.1 312 8 Unauth. TEST protocol, this document, Section 3.1 313 Encrypted CONTROL 315 7. Acknowledgements 317 The authors would like to thank Len Ciavattone for helpful review and 318 comments. 320 8. Normative References 322 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 323 Requirement Levels", BCP 14, RFC 2119, March 1997. 325 [RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M. 326 Zekauskas, "A One-way Active Measurement Protocol 327 (OWAMP)", RFC 4656, September 2006. 329 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 330 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 331 May 2008. 333 [RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J. 334 Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)", 335 RFC 5357, October 2008. 337 Authors' Addresses 339 Al Morton 340 AT&T Labs 341 200 Laurel Avenue South 342 Middletown,, NJ 07748 343 USA 345 Phone: +1 732 420 1571 346 Fax: +1 732 368 1192 347 Email: acmorton@att.com 348 URI: http://home.comcast.net/~acmacm/ 350 Kaynam Hedayat 351 EXFO 352 285 Mill Road 353 Chelmsford, MA 01824 354 USA 356 Phone: +1 357 Fax: +1 358 Email: kaynam.hedayat@exfo.com 359 URI: http://www.exfo.com/