idnits 2.17.1 draft-morton-ippm-twamp-tcp-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 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 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 15, 2013) is 3938 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) == Unused Reference: 'RFC1305' is defined on line 381, but no explicit reference was found in the text == Unused Reference: 'RFC5938' is defined on line 399, but no explicit reference was found in the text == Unused Reference: 'RFC6038' is defined on line 403, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1305 (Obsoleted by RFC 5905) == Outdated reference: A later version (-10) exists of draft-ietf-ippm-rate-problem-03 Summary: 1 error (**), 0 flaws (~~), 5 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) July 15, 2013 5 Intended status: Standards Track 6 Expires: January 16, 2014 8 TWAMP Control of a TCP Connection 9 draft-morton-ippm-twamp-tcp-00 11 Abstract 13 This memo describes a feature for the core specification of TWAMP - 14 the Two-Way Active Measurement Protocol: an optional capability where 15 a TCP connection can be coordinated between two participating hosts. 16 The feature includes the ability to control TCP configuration 17 settings and byte stream characteristics, enabling diagnostic 18 testing. 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 January 16, 2014. 43 Copyright Notice 45 Copyright (c) 2013 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 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. Purpose and Scope . . . . . . . . . . . . . . . . . . . . . . 3 62 3. TWAMP Control Extensions . . . . . . . . . . . . . . . . . . . 4 63 3.1. Connection Setup with New Features . . . . . . . . . . . . 4 64 3.2. TCP Connection: Request-TW-Session Packet Format . . . . . 5 65 3.3. TCP Connection: Accept Session Packet Format . . . . . . . 6 66 3.4. Stopping Test Sessions . . . . . . . . . . . . . . . . . . 8 67 3.5. Additional considerations . . . . . . . . . . . . . . . . 8 68 4. TWAMP Test for TCP Connection Feature . . . . . . . . . . . . 8 69 4.1. Initiater Behavior . . . . . . . . . . . . . . . . . . . . 8 70 4.2. Listener Behavior . . . . . . . . . . . . . . . . . . . . 8 71 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 72 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 73 6.1. Registry Specification . . . . . . . . . . . . . . . . . . 9 74 6.2. Modes Registry Contents . . . . . . . . . . . . . . . . . 9 75 6.3. Command Number Registry Contents . . . . . . . . . . . . . 9 76 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 77 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 78 8.1. Normative References . . . . . . . . . . . . . . . . . . . 10 79 8.2. Informative References . . . . . . . . . . . . . . . . . . 11 80 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11 82 1. Introduction 84 TWAMP - the Two-Way Active Measurement Protocol [RFC5357] is an 85 extension of the One-way Active Measurement Protocol, OWAMP 86 [RFC4656]. The TWAMP specification gathered wide review as it was 87 deployed, resulting in recommendations for new features. 89 An open question in the IPPM problem statement draft 90 [I-D.ietf-ippm-rate-problem] is whether testing with TCP transport 91 protocol is a needed capability. The current TWAMP test protocol 92 capability is limited to UDP transport. 94 This memo describes a feature for the core specification of TWAMP - 95 the Two-Way Active Measurement Protocol: an optional capability where 96 a TCP connection can be coordinated between two participating hosts. 97 The feature includes the ability to control TCP configuration 98 settings and byte stream characteristics, enabling diagnostic 99 testing. 101 This memo is an update to the TWAMP core protocol specified in 102 [RFC5357]. Measurement systems are not required to implement the 103 features described in this memo to claim compliance with [RFC5357]. 105 TWAMP was selected to host the TCP Connection feature because OWAMP 106 [RFC4656] was not extended to use the Mixed Security mode, and this 107 is a distinct advantage in testing. 109 Throughout this memo, the bits marked MBZ (Must Be Zero) MUST be set 110 to zero by senders and MUST be ignored by receivers. Also, the HMAC 111 (Hashed Message Authentication Code) MUST be calculated as defined in 112 Section 3.2 of [RFC4656]. 114 2. Purpose and Scope 116 The purpose of this memo is to define an OPTIONAL feature for TWAMP 117 [RFC5357]. The feature controls capability to setup a TCP connection 118 and coordinate the configuration details of that connection between 119 the test sender and the reflector hosts. 121 This memo is intended to satisfy key requirements contained in the 122 IPPM problem statement [I-D.ietf-ippm-rate-problem]. Referring to 123 the reference path defined in [I-D.morton-ippm-lmap-path], possible 124 measurement points include a Subscriber's host (mp000), the access 125 service demarcation point (mp100), Intra IP access where a globally 126 routable address is present (mp150), or the gateway between the 127 measured access network and other networks (mp190). 129 This memo extends the modes of operation through assignment of two 130 new values in the Modes Field (see section 3.1 of[RFC4656] for the 131 format of the Server Greeting message), while retaining backward 132 compatibility with the core TWAMP [RFC5357] implementations. The two 133 new values correspond to the two roles (connection initiator or 134 connection listener) defined in this memo. 136 When the Server and Control-Client have agreed to use one of the TCP 137 Connection modes during control connection setup, then the Control- 138 Client, the Server, the Session-Sender, and the Session-Reflector 139 MUST all conform to the requirements of that mode, as identified 140 below. 142 3. TWAMP Control Extensions 144 TWAMP-Control protocol [RFC5357] uses the Modes Field to identify and 145 select specific communication capabilities, and this field is a 146 recognized extension mechanism. The following sections describe two 147 such extensions. 149 3.1. Connection Setup with New Features 151 TWAMP connection establishment follows the procedure defined in 152 section 3.1 of [RFC4656] and section 3.1 of [RFC5357]. The new 153 features require two new bit positions (and values). See the IANA 154 section below for details on the assigned values and bit positions. 156 The Server sets one or both of the TCP Connection bit positions in 157 the Modes Field of the Server Greeting message to indicate its 158 capabilities and willingness to operate in either of these modes 159 (connection initiator or connection listener) if desired. 161 If the Control-Client intends to operate all test sessions invoked 162 with this control connection using one of the new modes, it MUST set 163 the Mode Field bit corresponding to each function in the Setup 164 Response message. With this and other *compatible* extensions, the 165 Control-Client MAY set multiple Mode Field bits in the Setup Response 166 message. The TCP Connection features are mutually exclusive, and 167 MUST NOT be used together. 169 The following Mode settings are compatible with either TCP Connection 170 Mode: 172 o Unauthenticated mode (value 1) 174 o Unauthenticated TEST protocol, Encrypted CONTROL (value 8) 175 The latter is referred to as the Mixed Security Mode. 177 The function of Integrity Protections and Values of the Accept Field 178 (sections 3.2 and 3.3 of [RFC5357]) remain as described. 180 3.2. TCP Connection: Request-TW-Session Packet Format 182 The bits designated for the TCP Connection feature in the Request-TW- 183 Session command are as shown in the packet format below. 185 This is a new command, designated by the TWAMP-Control Command Number 186 XX (where XX will be assigned by IANA). 188 0 1 2 3 189 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 190 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 191 | XX | MBZ | IPVN | MBZ | 192 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 194 . . 195 . ... Many fields (?? octets) not formatted ... . 196 . . 197 Session ID (SID) 198 Initiator Address (v4 or v6) 199 Initiator Port 200 Listener Address (v4 or v6) 201 Listener Port 202 TCP Configuration Fields (for Initiator and Listener) 203 (such as Max Advertised Sender Window, 204 Initial Window, 205 MSS (recommended) 206 Congestion Control (selection from a list?) 208 Stream Configuration Fields (for Initiator and Listener) 209 (such as Length of PDU to write, 210 Number of PDUs to write, 211 Max Duration of the TCP connection 213 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 214 | Type-P Descriptor | 215 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 216 | MBZ (4 octets) | 217 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 218 | MBZ (4 octets) | 219 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 220 | | 221 | HMAC (16 octets) | 222 | | 223 | | 224 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 226 field formatting is TBD 228 3.3. TCP Connection: Accept Session Packet Format 230 The Accept Session command for the TCP Connection feature is as shown 231 in the packet format below. 233 0 1 2 3 234 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 236 | Accept | MBZ | Port | 237 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| 238 | | 239 | SID (16 octets) | 240 | | 241 | | 242 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 243 | MBZ (4 octets) | 244 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 245 | MBZ (8 octets) | 246 | | 247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 248 | | 249 | HMAC (16 octets) | 250 | | 251 | | 252 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 254 If a TWAMP Server receives an unrecognized command number, it MUST 255 respond with the Accept field = 3 in the Accept-Session message. The 256 augmented Accept Field values are listed below. 258 o 0 = OK (Accept the session) 260 o 1 = Failure, reason unspecified 262 o 2 = Internal Error 264 o 3 = Some aspect of the request is not supported 266 o 4 = Cannot perform request due to permanent resource limitations 268 o 5 = Cannot perform request due to temporary resource limitations 270 o 6 = Requested Port Not Available 272 o 7 = Requested Address Not Available 274 All other values are reserved for future use. Reception of a non- 275 designated value MUST be interpreted as 1 = Failure. 277 3.4. Stopping Test Sessions 279 The Control-Client SHALL stop in-progress test sessions using 280 standardized methods, section 3.8 of [RFC5357]. 282 3.5. Additional considerations 284 The value of the Modes Field sent by the Server in the Server 285 Greeting message is the bit-wise OR of the mode values that it is 286 willing to support during this session. 288 With the publication of this memo as an RFC, the last ?? bit 289 positions of the Modes 32-bit Field are used. A Control-Client 290 conforming to this extension of [RFC5357] MAY ignore the values in 291 the higher bits of the Modes Field, or it MAY support other features 292 that are communicated in those bit positions. The other bits are 293 available for future protocol extensions. 295 4. TWAMP Test for TCP Connection Feature 297 This section will include additional considerations for the TCP 298 Connection Initiator and Listener, once a session has been requested 299 and accepted. 301 4.1. Initiater Behavior 303 This section describes extensions to the behavior of the TWAMP TCP 304 Initiator. 306 4.2. Listener Behavior 308 The TWAMP TCP Listener 310 5. Security Considerations 312 These extended modes of operation do not appear to permit any new 313 attacks on hosts communicating with core TWAMP [RFC5357]. 315 The security considerations that apply to any active measurement of 316 live networks are relevant here as well. See [RFC4656] and 317 [RFC5357]. 319 6. IANA Considerations 321 This memo adds two modes to the IANA registry for the TWAMP Modes 322 Field, and describes behavior when the new modes are used. This 323 field is a recognized extension mechanism for TWAMP. 325 6.1. Registry Specification 327 IANA has created a TWAMP-Modes registry (as requested in [RFC5618]). 328 TWAMP-Modes are specified in TWAMP Server Greeting messages and 329 Set-up Response messages, as described in section 3.1 of [RFC5357], 330 consistent with section 3.1 of [RFC4656], and extended by this memo. 331 Modes are indicated by setting bits in the 32-bit Modes field that 332 correspond to values in the Modes registry. For the TWAMP-Modes 333 registry, we expect that new features will be assigned increasing 334 registry values that correspond to single bit positions, unless there 335 is a good reason to do otherwise (more complex encoding than single 336 bit positions may be used in the future, to access the 2^32 value 337 space). 339 6.2. Modes Registry Contents 341 TWAMP Modes Registry is recommended to be augmented as follows: 343 Value Description Semantics Definition 344 -------------------------------------------------------- 345 xxx TCP Connection this memo, section 3.1 346 Initiator new bit position (X) 347 yyy TCP Connection this memo, section 3.1 348 Listener new bit position (Y) 350 >>>IANA: change xxx, yyy, X, Y, and RFC???? to the assigned values 352 The suggested values are 354 X=?, xxx=??? 356 Y=?, yyy=??? <<<< 358 6.3. Command Number Registry Contents 360 TWAMP-Control Command Number Registry is recommended to be augmented 361 as follows: 363 Value Description Semantics Definition 364 -------------------------------------------------------- 365 XX TCP Connection this memo, section 3.2 367 >>>IANA: change XX to the assigned values 369 The suggested values are 371 XX=11, <<<< 373 7. Acknowledgements 375 The author will complete this section as appropriate. 377 8. References 379 8.1. Normative References 381 [RFC1305] Mills, D., "Network Time Protocol (Version 3) 382 Specification, Implementation", RFC 1305, March 1992. 384 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 385 Requirement Levels", BCP 14, RFC 2119, March 1997. 387 [RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M. 388 Zekauskas, "A One-way Active Measurement Protocol 389 (OWAMP)", RFC 4656, September 2006. 391 [RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J. 392 Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)", 393 RFC 5357, October 2008. 395 [RFC5618] Morton, A. and K. Hedayat, "Mixed Security Mode for the 396 Two-Way Active Measurement Protocol (TWAMP)", RFC 5618, 397 August 2009. 399 [RFC5938] Morton, A. and M. Chiba, "Individual Session Control 400 Feature for the Two-Way Active Measurement Protocol 401 (TWAMP)", RFC 5938, August 2010. 403 [RFC6038] Morton, A. and L. Ciavattone, "Two-Way Active Measurement 404 Protocol (TWAMP) Reflect Octets and Symmetrical Size 405 Features", RFC 6038, October 2010. 407 8.2. Informative References 409 [I-D.ietf-ippm-rate-problem] 410 Morton, A., "Rate Measurement Test Protocol Problem 411 Statement", draft-ietf-ippm-rate-problem-03 (work in 412 progress), April 2013. 414 [I-D.morton-ippm-lmap-path] 415 Bagnulo, M., Burbridge, T., Crawford, S., Eardley, P., and 416 A. Morton, "A Reference Path and Measurement Points for 417 LMAP", draft-morton-ippm-lmap-path-01 (work in progress), 418 February 2013. 420 Author's Address 422 Al Morton 423 AT&T Labs 424 200 Laurel Avenue South 425 Middletown,, NJ 07748 426 USA 428 Phone: +1 732 420 1571 429 Fax: +1 732 368 1192 430 Email: acmorton@att.com 431 URI: http://home.comcast.net/~acmacm/