idnits 2.17.1 draft-morton-ippm-more-twamp-02.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 344. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 355. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 362. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 368. 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 (July 13, 2008) is 5738 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 254, but not defined == Unused Reference: 'RFC2434' is defined on line 294, but no explicit reference was found in the text == Outdated reference: A later version (-09) exists of draft-ietf-ippm-twamp-08 ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) Summary: 2 errors (**), 0 flaws (~~), 4 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: January 14, 2009 Brix Networks 6 July 13, 2008 8 More Features for TWAMP 9 draft-morton-ippm-more-twamp-02 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 January 14, 2009. 36 Abstract 38 The IETF is completing its work on TWAMP - the Two-Way Active 39 Measurement Protocol. This memo describes additional features for 40 TWAMP, essentially the ability to use different security modes in the 41 TWAMP-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 is completing its work on TWAMP - the Two-Way Active 76 Measurement Protocol [I-D.ietf-ippm-twamp], which is an extension to 77 the One-way Active Measurement Protocol, OWAMP [RFC4656]. The TWAMP 78 specification gathered wide review as it approached completion, and 79 the by-products were several recommendations for new features in 80 TWAMP. There are a growing number TWAMP implementations at present, 81 and wide-spread usage is expected. There are even devices emerging 82 that test implementations for protocol compliance. 84 This memo describes additional features for TWAMP, such as the 85 ability to use different security modes in the TWAMP-Control and 86 TWAMP-Test protocols. 88 The relationship between this memo and the TWAMP is intended to be an 89 update to the TWAMP RFC when published. 91 2. Purpose and Scope 93 The purpose of this memo is to specify additional functions and 94 features for TWAMP [I-D.ietf-ippm-twamp]. The features and 95 extensions were vetted before adoption in this memo. 97 The scope of the memo is limited to specifications of the following 98 features: 100 1. Extension of the modes of operation through assignment of new 101 values in the Mode field (see section 3.1 of [RFC4656]), while 102 retaining backward compatibility with TWAMP [I-D.ietf-ippm-twamp] 103 implementations. These values add the ability to use different 104 security modes in the TWAMP-Control and TWAMP-Test protocols. 105 The motivation for this extension is to permit the low packet 106 rate TWAMP-Control protocol to utilize a stronger mode of 107 integrity protection than that used in the TWAMP-Test protocol. 109 (other items may be added) 111 3. TWAMP Control Extensions 113 TWAMP-Control protocol is a derivative of the OWAMP-Control protocol, 114 and provides two-way measurement capability. All TWAMP Control 115 messages are similar in format and follow similar guidelines to those 116 defined in section 3 of [RFC4656] with the exceptions described in 117 TWAMP [I-D.ietf-ippm-twamp], and in the following sections. 119 All OWAMP-Control messages apply to TWAMP-Control, except for the 120 Fetch Session command. 122 3.1. Extended Connection Setup 124 TWAMP connection establishment follows the same procedure defined in 125 section 3.1 of [RFC4656]. The extended modes assign three new bit 126 positions (and values) to allow the Test protocol security mode to 127 differ from the Control protocol mode. With this extension, the 128 complete set of TWAMP values are as follows: 130 Value Description Reference/Explanation 131 0 Reserved 132 1 Unauthenticated RFC4656, Section 3.1 133 2 Authenticated RFC4656, Section 3.1 134 4 Encrypted RFC4656, Section 3.1 135 8 Unauth. TEST protocol, new bit position (3) 136 Encrypted CONTROL 138 In the original OWAMP mode field, setting bit positions 0, 1 or 2 139 indicated the security mode of the Control protocol, and the Test 140 protocol inherited the same mode (see section 4 of [RFC4656]). In 141 this extension to TWAMP, setting a higher mode field bit position (3) 142 SHALL discontinue the inheritance of the security mode in the Test 143 protocol, and each protocol's mode SHALL be specified explicitly. 144 When the desired TWAMP Test protocol mode is identical to the Control 145 Session mode, the corresponding mode bit (position 0, 1 or 2) SHALL 146 be set. The table below gives the various combinations that are now 147 permissible in TWAMP, where the Test protocol may use one of the 148 modes in each column corresponding to a Control mode. 150 ------------------------------------------------------- 151 Protocol | Permissible Mode Combinations (mode bit set) 152 ------------------------------------------------------- 153 Control | Unauth.(0)| Auth.(1)| Encrypted (2) 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 mode is needed to cover all mixed secuity modes that are possible. 166 The value of the Modes field sent by the Server is the bit-wise OR of 167 the mode values that it is willing to support during this session. 168 Thus, the last four bits of the Modes 32-bit field are used. The 169 first 28 bits MUST be zero. A client conforming to this version of 170 the specification MUST ignore the values in the first 28 bits of the 171 Modes value. (This way, the bits are available for future protocol 172 extensions.) 174 Other ways in which TWAMP extends OWAMP are described in 175 [I-D.ietf-ippm-twamp]. 177 4. Extended TWAMP Test 179 The TWAMP test protocol is similar to the OWAMP [RFC4656] test 180 protocol with the exception that the Session-Reflector transmits test 181 packets to the Session-Sender in response to each test packet it 182 receives. TWAMP [I-D.ietf-ippm-twamp] defines two different test 183 packet formats, one for packets transmitted by the Session-Sender and 184 one for packets transmitted by the Session-Reflector. As with OWAMP- 185 Test protocol there are three security modes: unauthenticated, 186 authenticated, and encrypted. The extension to TWAMP makes it 187 possible to specify these modes independently from the mode used in 188 the TWAMP-Control protocol. 190 4.1. Sender Behavior 192 This section describes extensions to the behavior of the TWAMP 193 Sender. 195 4.1.1. Packet Timings 197 The Send Schedule is not utilized in TWAMP, and there are no 198 extensions defined in this memo. 200 4.1.2. Packet Format and Content 202 The Session Sender packet format and content follow the same 203 procedure and guidelines as defined in section 4.1.2 of [RFC4656], 204 with the following exceptions: 206 o the Send Schedule is not used, and 208 o the support of additional security mode combinations defined in 209 section 3.1 of this memo. 211 4.2. Reflector Behavior 213 The TWAMP Reflector follows the procedures and guidelines in section 214 4.2 of [I-D.ietf-ippm-twamp], with the following extensions: 216 o the support of additional security mode combinations defined in 217 section 3.1 of this memo. 219 5. Security Considerations 221 These extended modes of operation permit stronger integrity 222 protection on the TWAMP-Control protocol while simultaneously 223 emphasizing accuracy or efficiency on the TWAMP-Test protocol, thus 224 enhancing overall security when compared to the previous options. 226 The security considerations that apply to any active measurement of 227 live networks are relevant here as well. See [RFC4656] and 228 [I-D.ietf-ippm-twamp]. 230 6. IANA Considerations 232 This memo adds three security mode combinations to the OWAMP-Control 233 specification[RFC4656], and describes behavior when the new modes are 234 used. This memo requests creation an IANA registry for the TWAMP 235 Mode field. This field is a recognized extension mechanism for 236 TWAMP. 238 6.1. Registry Specification 240 IANA is requested to create a TWAMP-Modes registry. TWAMP-Modes are 241 specified in TWAMP Server Greeting messages and Set-up Response 242 messages consistent with section 3.1 of [RFC4656], and extended by 243 this memo. Modes are indicated by setting bits in the 32-bit Modes 244 field. Thus, this registry can contain a total of 32 possible 245 values. 247 6.2. Registry Management 249 Because the Modes registry can contain only thirty-two values, and 250 because TWAMP is an IETF protocol, this registry must be updated only 251 by "IETF Consensus" as specified in [RFC2434](an RFC documenting 252 registry use that is approved by the IESG). For the Modes registry, 253 we expect that new features will be assigned using monotonically 254 increasing bit positions and in the range [0-31] and the 255 corresponding values, unless there is a good reason to do otherwise. 257 6.3. Experimental Numbers 259 No experimental values are currently assigned for the Modes Registry. 261 6.4. Initial Registry Contents 263 TWAMP Modes Registry 265 Value Description Semantics Definition 266 0 Reserved 268 1 Unauthenticated RFC4656, Section 3.1 270 2 Authenticated RFC4656, Section 3.1 272 4 Encrypted RFC4656, Section 3.1 274 8 Unauth. TEST protocol, this document, Section 3.1 275 Encrypted CONTROL 277 7. Acknowledgements 279 The authors would like to thank Len Ciavattone for helpful review and 280 comments. 282 8. References 284 8.1. Normative References 286 [I-D.ietf-ippm-twamp] 287 Babiarz, J., "A Two-way Active Measurement Protocol 288 (TWAMP)", draft-ietf-ippm-twamp-08 (work in progress), 289 June 2008. 291 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 292 Requirement Levels", BCP 14, RFC 2119, March 1997. 294 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 295 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 296 October 1998. 298 [RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M. 299 Zekauskas, "A One-way Active Measurement Protocol 300 (OWAMP)", RFC 4656, September 2006. 302 8.2. Informative References 304 [x] "". 306 Authors' Addresses 308 Al Morton 309 AT&T Labs 310 200 Laurel Avenue South 311 Middletown,, NJ 07748 312 USA 314 Phone: +1 732 420 1571 315 Fax: +1 732 368 1192 316 Email: acmorton@att.com 317 URI: http://home.comcast.net/~acmacm/ 319 Kaynam Hedayat 320 Brix Networks 321 285 Mill Road 322 Chelmsford, MA 01824 323 USA 325 Phone: +1 326 Fax: +1 327 Email: khedayat@brixnet.com 328 URI: http://www.brixnet.com/ 330 Full Copyright Statement 332 Copyright (C) The IETF Trust (2008). 334 This document is subject to the rights, licenses and restrictions 335 contained in BCP 78, and except as set forth therein, the authors 336 retain all their rights. 338 This document and the information contained herein are provided on an 339 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 340 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 341 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 342 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 343 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 344 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 346 Intellectual Property 348 The IETF takes no position regarding the validity or scope of any 349 Intellectual Property Rights or other rights that might be claimed to 350 pertain to the implementation or use of the technology described in 351 this document or the extent to which any license under such rights 352 might or might not be available; nor does it represent that it has 353 made any independent effort to identify any such rights. Information 354 on the procedures with respect to rights in RFC documents can be 355 found in BCP 78 and BCP 79. 357 Copies of IPR disclosures made to the IETF Secretariat and any 358 assurances of licenses to be made available, or the result of an 359 attempt made to obtain a general license or permission for the use of 360 such proprietary rights by implementers or users of this 361 specification can be obtained from the IETF on-line IPR repository at 362 http://www.ietf.org/ipr. 364 The IETF invites any interested party to bring to its attention any 365 copyrights, patents or patent applications, or other proprietary 366 rights that may cover technology that may be required to implement 367 this standard. Please address the information to the IETF at 368 ietf-ipr@ietf.org.