idnits 2.17.1 draft-ietf-ippm-more-twamp-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 346. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 357. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 364. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 370. 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 Copyright Line does not match the current year -- 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 19, 2008) is 5639 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 257, but not defined == Unused Reference: 'RFC2434' is defined on line 292, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 7 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 Intended status: Standards Track K. Hedayat 5 Expires: April 22, 2009 Brix Networks 6 October 19, 2008 8 More Features for TWAMP 9 draft-ietf-ippm-more-twamp-00 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on April 22, 2009. 36 Abstract 38 The IETF has completed its work on TWAMP - the Two-Way Active 39 Measurement Protocol. This memo describes a simple extension to 40 TWAMP, the option to use different security modes in the TWAMP- 41 Control and TWAMP-Test protocols. 43 Requirements Language 45 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 46 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 47 document are to be interpreted as described in RFC 2119 [RFC2119]. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2. Purpose and Scope . . . . . . . . . . . . . . . . . . . . . . . 3 53 3. TWAMP Control Extensions . . . . . . . . . . . . . . . . . . . 3 54 3.1. Extended Connection Setup . . . . . . . . . . . . . . . . . 4 55 4. Extended TWAMP Test . . . . . . . . . . . . . . . . . . . . . . 5 56 4.1. Sender Behavior . . . . . . . . . . . . . . . . . . . . . . 5 57 4.1.1. Packet Timings . . . . . . . . . . . . . . . . . . . . 5 58 4.1.2. Packet Format and Content . . . . . . . . . . . . . . . 5 59 4.2. Reflector Behavior . . . . . . . . . . . . . . . . . . . . 6 60 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 61 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 62 6.1. Registry Specification . . . . . . . . . . . . . . . . . . 6 63 6.2. Registry Management . . . . . . . . . . . . . . . . . . . . 6 64 6.3. Experimental Numbers . . . . . . . . . . . . . . . . . . . 7 65 6.4. Initial Registry Contents . . . . . . . . . . . . . . . . . 7 66 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 67 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 68 8.1. Normative References . . . . . . . . . . . . . . . . . . . 7 69 8.2. Informative References . . . . . . . . . . . . . . . . . . 8 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 71 Intellectual Property and Copyright Statements . . . . . . . . . . 9 73 1. Introduction 75 The IETF has completed its work on the core specification of TWAMP - 76 the Two-Way Active Measurement Protocol [RFC5357]. TWAMP is an 77 extension of the One-way Active Measurement Protocol, OWAMP 78 [RFC4656]. The TWAMP specification gathered wide review as it 79 approached completion, and the by-products were several 80 recommendations for new features in TWAMP. There are a growing 81 number TWAMP implementations at present, and wide-spread usage is 82 expected. There are even devices that are designed to test 83 implementations for protocol compliance. 85 This memo describes a simple extension for TWAMP, the option to use 86 different security modes in the TWAMP-Control and TWAMP-Test 87 protocols. 89 The relationship between this memo and TWAMP is intended to be an 90 update to [RFC5357] when published. 92 2. Purpose and Scope 94 The purpose of this memo is to describe and specify an extension for 95 TWAMP [RFC5357]. The features and extensions were vetted before 96 adoption in this memo. 98 The scope of the memo is limited to specifications of the following: 100 o Extension of the modes of operation through assignment of one new 101 value in the Mode field (see section 3.1 of [RFC4656]), while 102 retaining backward compatibility with TWAMP [RFC5357] 103 implementations. This value adds the OPTIONAL ability to use 104 different security modes in the TWAMP-Control and TWAMP-Test 105 protocols. The motivation for this extension is to permit the low 106 packet rate TWAMP-Control protocol to utilize a stronger mode of 107 integrity protection than that used in the TWAMP-Test protocol. 109 3. TWAMP Control Extensions 111 TWAMP-Control protocol is a derivative of the OWAMP-Control protocol, 112 and coordinates a two-way measurement capability. All TWAMP Control 113 messages are similar in format and follow similar guidelines to those 114 defined in section 3 of [RFC4656] with the exceptions described in 115 TWAMP [RFC5357], and in the following sections. 117 All OWAMP-Control messages apply to TWAMP-Control, except for the 118 Fetch Session command. 120 3.1. Extended Connection Setup 122 TWAMP connection establishment follows the same procedure defined in 123 section 3.1 of [RFC4656]. This extended mode assigns one new bit 124 position (and value) to allow the Test protocol security mode to 125 operate in Unauthenticated mode, while the Control protocol operates 126 in Encrypted mode. With this extension, the complete set of TWAMP 127 values are as follows: 129 Value Description Reference/Explanation 130 0 Reserved 131 1 Unauthenticated RFC4656, Section 3.1 132 2 Authenticated RFC4656, Section 3.1 133 4 Encrypted RFC4656, Section 3.1 134 8 Unauth. TEST protocol, new bit position (3) 135 Encrypted CONTROL 137 In the original OWAMP Modes field, setting bit positions 0, 1 or 2 138 indicated the security mode of the Control protocol, and the Test 139 protocol inherited the same mode (see section 4 of [RFC4656]). In 140 this extension to TWAMP, setting Modes Field bit position 3 SHALL 141 discontinue the inheritance of the security mode in the Test 142 protocol, and each protocol's mode SHALL be as specified below. When 143 the desired TWAMP Test protocol mode is identical to the Control 144 Session mode, the corresponding Modes Field bit (position 0, 1 or 2) 145 SHALL be set. The table below gives the various combinations of 146 integrity protection that are permissible in TWAMP (with this 147 extension). The Test protocol SHALL use the mode in each column 148 corresponding to the Modes Field bit position. 150 -------------------------------------------------------- 151 Protocol | Permissible Mode Combinations (Modes bit set) 152 -------------------------------------------------------- 153 Control | Unauth.(0)| Auth. == Encrypted (1,2,3) 154 -------------------------------------------------------- 155 | Unauth.(0)| Unauth. (3) 156 ----------------------------------------------- 157 Test | | Auth.(1) 158 ----------------------------------------------- 159 | | Encrypted (2) 160 -------------------------------------------------------- 162 Note that the TWAMP-Control protocol security measures are identical 163 in the Authenticated and Encrypted Modes. Therefore, only one new 164 bit position (3) is needed to convey the single mixed security mode. 166 The value of the Modes Field sent by the Server in the Server- 167 Greeting message is the bit-wise OR of the modes (bit positions) that 168 it is willing to support during this session. Thus, the last four 169 bits of the Modes 32-bit Field are used. The first 28 bits MUST be 170 zero. A client conforming to this extension of [RFC5357] MAY ignore 171 the values in the first 28 bits of the Modes Field, or it MAY support 172 other features that are communicated in these bit positions. 174 Other ways in which TWAMP extends OWAMP are described in [RFC5357]. 176 4. Extended TWAMP Test 178 The TWAMP test protocol is similar to the OWAMP [RFC4656] test 179 protocol with the exception that the Session-Reflector transmits test 180 packets to the Session-Sender in response to each test packet it 181 receives. TWAMP [RFC5357] defines two different test packet formats, 182 one for packets transmitted by the Session-Sender and one for packets 183 transmitted by the Session-Reflector. As with OWAMP-Test protocol 184 there are three security modes: unauthenticated, authenticated, and 185 encrypted. This TWAMP extension makes it possible to use TWAMP-Test 186 Unauthenticated mode regardless of the mode used in the TWAMP-Control 187 protocol. 189 4.1. Sender Behavior 191 This section describes REQUIRED extensions to the behavior of the 192 TWAMP Sender. 194 4.1.1. Packet Timings 196 The Send Schedule is not utilized in TWAMP, and there are no 197 extensions defined in this memo. 199 4.1.2. Packet Format and Content 201 The Session Sender packet format and content MUST follow the same 202 procedure and guidelines as defined in section 4.1.2 of [RFC4656] and 203 section 4.1.2 of [RFC5357], with the following exceptions: 205 o the Send Schedule is not used, and 207 o the Sessions-Sender MUST support the mixed security mode 208 (Unauthenticated TEST, Encrypted CONTROL,value 8, bit position 3) 209 defined in section 3.1 of this memo. 211 4.2. Reflector Behavior 213 The TWAMP Reflector is REQUIRED to follow the procedures and 214 guidelines in section 4.2 of [RFC5357], with the following 215 extensions: 217 o the Sessions-Reflector MUST support the mixed security mode 218 (Unauthenticated TEST, Encrypted CONTROL,value 8, bit position 3) 219 defined in section 3.1 of this memo. 221 5. Security Considerations 223 The extended mixed-mode of operation permits stronger security/ 224 integrity protection on the TWAMP-Control protocol while 225 simultaneously emphasizing accuracy or efficiency on the TWAMP-Test 226 protocol, thus making it possible to increase overall security when 227 compared to the previous options. 229 The security considerations that apply to any active measurement of 230 live networks are relevant here as well. See [RFC4656] and 231 [RFC5357]. 233 6. IANA Considerations 235 This memo adds three security mode combinations to the OWAMP-Control 236 specification[RFC4656], and describes behavior when the new modes are 237 used. This memo requests creation an IANA registry for the TWAMP 238 Mode field. This field is a recognized extension mechanism for 239 TWAMP. 241 6.1. Registry Specification 243 IANA is requested to create a TWAMP-Modes registry. TWAMP-Modes are 244 specified in TWAMP Server Greeting messages and Set-up Response 245 messages consistent with section 3.1 of [RFC4656], and extended by 246 this memo. Modes are indicated by setting bits in the 32-bit Modes 247 Field. Thus, this registry can contain a total of 32 possible bit 248 positions and corresponding values. 250 6.2. Registry Management 252 Because the TWAMP-Modes registry can contain only thirty-two values, 253 and because TWAMP is an IETF protocol, this registry must be updated 254 only by "IETF Consensus" as specified in [RFC2434](an RFC documenting 255 registry use that is approved by the IESG). For the Modes registry, 256 we expect that new features will be assigned using monotonically 257 increasing bit positions and in the range [0-31] and the 258 corresponding values, unless there is a good reason to do otherwise. 260 6.3. Experimental Numbers 262 No experimental values are currently assigned for the Modes Registry. 264 6.4. Initial Registry Contents 266 TWAMP Modes Registry 268 Value Description Semantics Definition 269 0 Reserved 271 1 Unauthenticated RFC4656, Section 3.1 273 2 Authenticated RFC4656, Section 3.1 275 4 Encrypted RFC4656, Section 3.1 277 8 Unauth. TEST protocol, this document, Section 3.1 278 Encrypted CONTROL 280 7. Acknowledgements 282 The authors would like to thank Len Ciavattone for helpful review and 283 comments. 285 8. References 287 8.1. Normative References 289 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 290 Requirement Levels", BCP 14, RFC 2119, March 1997. 292 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 293 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 294 October 1998. 296 [RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M. 297 Zekauskas, "A One-way Active Measurement Protocol 298 (OWAMP)", RFC 4656, September 2006. 300 [RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J. 301 Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)", 302 RFC 5357, October 2008. 304 8.2. Informative References 306 [x] "". 308 Authors' Addresses 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/ 321 Kaynam Hedayat 322 Brix Networks 323 285 Mill Road 324 Chelmsford, MA 01824 325 USA 327 Phone: +1 328 Fax: +1 329 Email: khedayat@brixnet.com 330 URI: http://www.brixnet.com/ 332 Full Copyright Statement 334 Copyright (C) The IETF Trust (2008). 336 This document is subject to the rights, licenses and restrictions 337 contained in BCP 78, and except as set forth therein, the authors 338 retain all their rights. 340 This document and the information contained herein are provided on an 341 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 342 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 343 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 344 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 345 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 346 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 348 Intellectual Property 350 The IETF takes no position regarding the validity or scope of any 351 Intellectual Property Rights or other rights that might be claimed to 352 pertain to the implementation or use of the technology described in 353 this document or the extent to which any license under such rights 354 might or might not be available; nor does it represent that it has 355 made any independent effort to identify any such rights. Information 356 on the procedures with respect to rights in RFC documents can be 357 found in BCP 78 and BCP 79. 359 Copies of IPR disclosures made to the IETF Secretariat and any 360 assurances of licenses to be made available, or the result of an 361 attempt made to obtain a general license or permission for the use of 362 such proprietary rights by implementers or users of this 363 specification can be obtained from the IETF on-line IPR repository at 364 http://www.ietf.org/ipr. 366 The IETF invites any interested party to bring to its attention any 367 copyrights, patents or patent applications, or other proprietary 368 rights that may cover technology that may be required to implement 369 this standard. Please address the information to the IETF at 370 ietf-ipr@ietf.org.