idnits 2.17.1 draft-ietf-ippm-twamp-reflect-octets-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- 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 (July 13, 2009) is 5395 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 660, but not defined == Unused Reference: 'RFC2434' is defined on line 710, 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 (==), 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 L. Ciavattone 4 Intended status: Standards Track AT&T Labs 5 Expires: January 14, 2010 July 13, 2009 7 TWAMP Reflect Octets Feature 8 draft-ietf-ippm-twamp-reflect-octets-02 10 Status of this Memo 12 This Internet-Draft is submitted to IETF in full conformance with the 13 provisions of BCP 78 and BCP 79. This document may contain material 14 from IETF Documents or IETF Contributions published or made publicly 15 available before November 10, 2008. The person(s) controlling the 16 copyright in some of this material may not have granted the IETF 17 Trust the right to allow modifications of such material outside the 18 IETF Standards Process. Without obtaining an adequate license from 19 the person(s) controlling the copyright in such materials, this 20 document may not be modified outside the IETF Standards Process, and 21 derivative works of it may not be created outside the IETF Standards 22 Process, except to format it for publication as an RFC or to 23 translate it into languages other than English. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF), its areas, and its working groups. Note that 27 other groups may also distribute working documents as Internet- 28 Drafts. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 The list of current Internet-Drafts can be accessed at 36 http://www.ietf.org/ietf/1id-abstracts.txt. 38 The list of Internet-Draft Shadow Directories can be accessed at 39 http://www.ietf.org/shadow.html. 41 This Internet-Draft will expire on January 14, 2010. 43 Copyright Notice 45 Copyright (c) 2009 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 in effect on the date of 50 publication of this document (http://trustee.ietf.org/license-info). 51 Please review these documents carefully, as they describe your rights 52 and restrictions with respect to this document. 54 Abstract 56 The IETF has completed its work on the core specification of TWAMP - 57 the Two-Way Active Measurement Protocol. This memo describes a new 58 feature for TWAMP: an optional capability where the responder host 59 returns some of the command octets or padding octets to the 60 controller, and/or ensures that the same test packet sizes are used 61 in both directions. 63 Requirements Language 65 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 66 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 67 document are to be interpreted as described in RFC 2119 [RFC2119]. 69 Table of Contents 71 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 72 2. Purpose and Scope . . . . . . . . . . . . . . . . . . . . . . 4 73 3. TWAMP Control Extensions . . . . . . . . . . . . . . . . . . . 5 74 3.1. Connection Setup with Reflect Padding Feature . . . . . . 5 75 3.2. Request-TW-Session Packet Format . . . . . . . . . . . . . 6 76 3.3. Accept Session Packet Format . . . . . . . . . . . . . . . 8 77 3.4. Additional considerations . . . . . . . . . . . . . . . . 8 78 4. Extended TWAMP Test . . . . . . . . . . . . . . . . . . . . . 9 79 4.1. Sender Behavior . . . . . . . . . . . . . . . . . . . . . 9 80 4.1.1. Packet Timings . . . . . . . . . . . . . . . . . . . . 9 81 4.1.2. Packet Formats and Contents . . . . . . . . . . . . . 9 82 4.1.3. Padding Truncation . . . . . . . . . . . . . . . . . . 11 83 4.2. Reflector Behavior . . . . . . . . . . . . . . . . . . . . 12 84 4.2.1. Packet Format and Contents . . . . . . . . . . . . . . 12 85 4.2.2. Padding Truncation . . . . . . . . . . . . . . . . . . 13 86 5. Possible Alternative . . . . . . . . . . . . . . . . . . . . . 14 87 6. Security Considerations . . . . . . . . . . . . . . . . . . . 16 88 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 89 7.1. Registry Specification . . . . . . . . . . . . . . . . . . 17 90 7.2. Registry Management . . . . . . . . . . . . . . . . . . . 17 91 7.3. Experimental Numbers . . . . . . . . . . . . . . . . . . . 17 92 7.4. Registry Contents . . . . . . . . . . . . . . . . . . . . 17 93 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18 94 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 95 9.1. Normative References . . . . . . . . . . . . . . . . . . . 18 96 9.2. Informative References . . . . . . . . . . . . . . . . . . 18 97 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 99 1. Introduction 101 The IETF has completed its work on the core specification of TWAMP - 102 the Two-Way Active Measurement Protocol [RFC5357]. TWAMP is an 103 extension of the One-way Active Measurement Protocol, OWAMP 104 [RFC4656]. The TWAMP specification gathered wide review as it 105 approached completion, and the by-products were several 106 recommendations for new features in TWAMP. There are a growing 107 number TWAMP implementations at present, and wide-spread usage is 108 expected. There are even devices that are designed to test 109 implementations for protocol compliance. 111 This memo describes a new feature for TWAMP. This feature adds the 112 OPTIONAL capability for the responder host to return a limited number 113 of unassigned (padding) octets to the Control-Client or Session- 114 Sender entities. With this capability, the Control-Client or 115 Session-Sender can embed octets of information it deems useful and 116 have the assurance that the corresponding reply/test packet will 117 contain that information when it is reflected and returned (by the 118 Server or Session-Reflector. The feature also adds the Session- 119 Reflector capability to assure that reflected test packets SHALL have 120 their padding octets truncated, so that TWAMP-Test protocol uses the 121 same packet size in both directions of transmission. 123 The relationship between this memo and TWAMP is intended to be an 124 update to [RFC5357] when published. 126 2. Purpose and Scope 128 The purpose of this memo is to describe a new feature for TWAMP 129 [RFC5357]. The feature enhances the TWAMP responder's capabilities 130 to perform simple operations on control and test packets: the 131 reflection of octets or padding and the guaranteed truncation of 132 padding to compensate for the different sizes of TWAMP fields in the 133 test packets. Motivations include permitting the controller host to 134 tag packets with an index for simplified identification, and/or 135 assert that the same size test packets MUST be used in each 136 direction. 138 The scope of the memo is currently limited to specifications of the 139 following feature: 141 o Extension of the modes of operation through assignment of new 142 values in the Mode Field (see section 3.1 [RFC4656] for the format 143 of the Server Greeting message), while retaining backward 144 compatibility with the core TWAMP [RFC5357] implementations. 145 These two values identify the ability of the Server/ 146 Session-Reflector to reflect specific octets back to the Client/ 147 Session-Sender, and/or to truncate padding octets and ensure that 148 TWAMP-Test protocol uses the same packet size in both directions. 150 3. TWAMP Control Extensions 152 TWAMP-Control protocol [RFC5357] uses the Modes Field to identify and 153 select specific communication capabilities, and this field is a 154 recognized extension mechanism. The following sections describe one 155 such extension. 157 3.1. Connection Setup with Reflect Padding Feature 159 TWAMP connection establishment follows the procedure defined in 160 section 3.1 of [RFC4656] and section 3.1 of [RFC5357]. The new 161 feature requires two new bit positions (and values) to identify the 162 ability of the Server/Session-Reflector to reflect specific octets 163 back to the Control-Client/Session-Sender, and to truncate padding 164 octets when required. With this added feature, the complete set of 165 TWAMP Modes Field bit positions and values would be as follows: 167 Value Description Reference/Explanation 168 0 Reserved 169 1 Unauthenticated RFC4656, Section 3.1 170 2 Authenticated RFC4656, Section 3.1 171 4 Encrypted RFC4656, Section 3.1 172 8 Unauth. TEST protocol, draft-ietf-more-twamp (3) 173 Encrypted CONTROL 174 -------------------------------------------------------- 175 xxx Reflect Octets new bit position (X) 176 Capability 177 yyy Truncate Padding new bit position (Y) 178 Capability 180 In the original OWAMP Modes Field, setting bit positions 0, 1 or 2 181 indicated the security mode of the Control protocol, and the Test 182 protocol inherited the same mode (see section 4 of [RFC4656]). In 183 the memo [I-D.ietf-ippm-more-twamp], bit position 3 allows 184 unauthenticated TWAMP Test protocol to be used with encryption on the 185 TWAMP-Control protocol. 187 The Server sets one or both of the new bit positions (X and Y) in the 188 Modes Field of the Server Greeting message to indicate its 189 capabilities and willingness to operate in these modes if desired. 190 >>>IANA: change X and Y to the assigned values <<< 191 If the Control-Client intends to operate all test sessions invoked 192 with this control connection using one or both of the new modes, it 193 MUST set the Modes Field bit corresponding to that function in the 194 Setup Response message. 196 3.2. Request-TW-Session Packet Format 198 The bits designated for the Reflect Octets feature in the Request-TW- 199 Session command are as shown in the packet format below. 201 0 1 2 3 202 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 203 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 204 | 5 | MBZ | IPVN | Conf-Sender | Conf-Receiver | 205 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 206 | Number of Schedule Slots | 207 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 208 . . 209 . ... Many fields (66 octets) not shown ... . 210 . . 211 . . 212 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 213 | Padding Length | 214 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 215 | Start Time, (8 octets) | 216 | | 217 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 218 | Timeout, (8 octets) | 219 | | 220 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 221 | Type-P Descriptor | 222 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 223 | Octets to be reflected | Length of padding to reflect | 224 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 225 | MBZ (4 octets) | 226 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 227 | | 228 | HMAC (16 octets) | 229 | | 230 | | 231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 233 The "Padding Length" Field *continues* to specify the number of 234 padding octets that the Session-Sender will append to ALL TWAMP-Test 235 packets associated with this test session. See below for 236 considerations on the minimum length of the padding octets, 237 especially when complying with the options described in this memo, 238 following the definitions of the two new fields that follow the 239 Type-P Descriptor. 241 Note that the number of padding octets appended to the Session- 242 Reflector's test packet depends on support for the OPTIONAL Truncate 243 Padding mode, or the RECOMMENDED truncation process in TWAMP section 244 4.2.1 [RFC5357]. 246 The "Octets to be reflected" Field SHALL be 2 octets long, as shown 247 and contains the octets that the Server MUST reflect in the Accept 248 Session message as specified below. 250 The "Length of padding to reflect" Field SHALL be 2 octets long, and 251 contain an unsigned binary value in units of octets. This field 252 communicates the length of the padding in the TWAMP-Test Packet that 253 the Session-Sender expects to be reflected, and the length of octets 254 that the Session-Reflector SHALL return in include in its TWAMP-Test 255 packet format (see section 4.2). By including this length field in 256 the Request-TW-Session message, a Server is able to determine if it 257 can comply with a specific request to reflect padding in the TWAMP- 258 Test packets, and to arrange for the Session-Reflector processing in 259 advance. 261 The "Padding Length" SHOULD be >= 27 octets when specifying a test 262 session using the Unauthenticated TWAMP-Test mode, to allow for the 263 RECOMMENDED truncation process in TWAMP section 4.2.1 [RFC5357]. 265 The "Padding Length" SHOULD be >= 56 octets when specifying a test 266 session using the Authenticated or Encrypted TWAMP-Test modes, to 267 allow for the RECOMMENDED truncation process in TWAMP section 4.2.1 268 [RFC5357]. 270 The "Padding Length" SHALL be > the "Length of padding to reflect" 271 when specifying a test session using the OPTIONAL Reflect Octets 272 mode. 274 The "Padding Length" SHALL be >= 27 + "Length of padding to reflect" 275 octets when specifying a test session using BOTH the OPTIONAL Reflect 276 Octets mode and OPTIONAL Truncate Padding mode with the 277 Unauthenticated TWAMP-Test mode. 279 The "Padding Length" SHALL be >= 56 + "Length of padding to reflect" 280 octets when specifying a test session using BOTH the OPTIONAL Reflect 281 Octets mode and OPTIONAL Truncate Padding mode with the Authenticated 282 or Encrypted TWAMP-Test modes. 284 3.3. Accept Session Packet Format 286 The bits designated for the Reflect Padding feature in the Accept 287 Session command are as shown in the packet format below. 289 0 1 2 3 290 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 291 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 292 | Accept | MBZ | Port | 293 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| 294 | | 295 | SID (16 octets) | 296 | | 297 | | 298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 299 | Reflected octets | Server octets | 300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 301 | MBZ (8 octets) | 302 | | 303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 304 | | 305 | HMAC (16 octets) | 306 | | 307 | | 308 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 310 The "Reflected octets" field SHALL contain the octets from the 311 Request-TW-Session "Octets to be reflected" Field, and be 2 octets 312 long, as shown. 314 The "Server octets" field SHALL contain information that the Server 315 intends to be returned in the TWAMP-Test packet padding to-be- 316 reflected Field, OR SHALL be zero, and be 2 octets long, as shown. 317 Although the Server determines the SID, this field is very long (16 318 octets) and does not normally appear in TWAMP-Test packets. 320 In Truncate Padding mode, IF calculations on the Padding lengths 321 reveal that there are insufficient octets supplied to produce equal- 322 length Session-Sender and Session-Reflector test packets, then the 323 Accept Field MUST be set to 3 = some aspect of the request is not 324 supported. 326 3.4. Additional considerations 328 The value of the Modes Field sent by the Server in the Server 329 Greeting message is the bit-wise OR of the mode values that it is 330 willing to support during this session. 332 Thus, the last six bits of the Modes 32-bit Field are used. A client 333 conforming to this extension of [RFC5357] MAY ignore the values in 334 the first 24 bits of the Modes Field, or it MAY support other 335 features that are communicated in these bit positions. (The first 24 336 bits are available for future protocol extensions.) 338 Other ways in which TWAMP extends OWAMP are described in [RFC5357]. 340 4. Extended TWAMP Test 342 The TWAMP test protocol is similar to the OWAMP [RFC4656] test 343 protocol with the exception that the Session-Reflector transmits test 344 packets to the Session-Sender in response to each test packet it 345 receives. TWAMP section 4[RFC5357] defines two additional test 346 packet formats for packets transmitted by the Session-Reflector. The 347 appropriate format depends on the security mode chosen. The new 348 modes specified here utilize some of the padding octets within each 349 test packet format, or require truncation of those octets depending 350 on the security mode in use. 352 4.1. Sender Behavior 354 This section describes extensions to the behavior of the TWAMP 355 Session-Sender. 357 4.1.1. Packet Timings 359 The Send Schedule is not utilized in TWAMP, and this is unchanged in 360 this memo. 362 4.1.2. Packet Formats and Contents 364 The Session-Sender packet format and content follow the same 365 procedure and guidelines as defined in section 4.1.2 of [RFC4656] (as 366 indicated in section 4.1.2 of TWAMP [RFC5357]). 368 The Reflect octets mode re-designates the original TWAMP-Test (and 369 OWAMP-Test) Packet Padding Field (see section 4.1.2 of [RFC4656]), as 370 shown below for unauthenticated mode: 372 0 1 2 3 373 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 374 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 375 | Sequence Number | 376 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 377 | Timestamp | 378 | | 379 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 380 | Error Estimate | | 381 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 382 | | 383 | Packet Padding (to be reflected) | 384 . (length in octets specified in command) . 385 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 386 . . 387 . Additional Packet Padding . 388 . . 389 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 391 The "Packet Padding (to be reflected)" Field SHALL correspond to the 392 length of octets specified in the Request-TW-Session "Length of 393 padding to reflect" Field to this test session. These are the octets 394 that the Session-Sender expects will be returned by the Session- 395 Reflector. 397 The length of the "Additional Packet Padding" Field is the difference 398 between two fields in the Request-TW-Session command, as follows: 400 "Additional Packet Padding", in octets = 402 "Padding Length" - "Length of padding to reflect" 404 One possible use of the first 4 octets of the "Packet Padding (to be 405 reflected)" Field is shown below: 407 0 1 2 3 408 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 409 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 410 | Server octets | 411 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 412 | Client octets | | 413 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 414 | Packet Padding (to be reflected) | 415 . (length in octets specified elsewhere) . 416 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 417 In this example, the "Client octets" and the "Server octets" fields 418 contain the same information that the Client and Server exchanged in 419 the Request-TW-Session and Accept-Session messages corresponding to 420 this specific test session. These octets would be reflected the same 421 as the rest of the "Packet Padding (to be reflected)" Field. 423 4.1.3. Padding Truncation 425 When the Truncate Padding mode is selected and communicated in the 426 Setup Response message, the Session-Sender MUST anticipate a minimum 427 padding required to achieve equal size test packets in both 428 directions. The amount of padding needed depends on BOTH the 429 security mode (Unauthenticated/Authenticated/Encrypted) and whether 430 the Reflect Octets mode is selected simultaneously. 432 When using the Truncate Padding mode, the Session-Sender MUST append 433 sufficient Packet Padding octets to allow the same IP packet payload 434 lengths to be used in each direction of transmission (this is usually 435 desirable). To compensate for the Session-Reflector's larger test 436 packet format, the Session-Sender MUST append at least 27 octets of 437 padding in Unauthenticated mode, and at least 56 octets in 438 Authenticated and Encrypted modes. The sizes of TWAMP Test protocol 439 packets and the resulting truncated padding to achieve equal packet 440 sizes in both directions are shown in the table below: 442 +-------------------+----------------------+---------------------+ 443 | Octets in: | Unauthenticated Mode | Auth/Encrypted Mode | 444 +-------------------+----------------------+---------------------+ 445 | Reflector Header | 41 | 104 | 446 | Sender Header | 14 | 48 | 447 | Truncated Padding | 27 | 56 | 448 +-------------------+----------------------+---------------------+ 450 TWAMP-Test Padding Trucation 452 When using the Reflect Octets mode simultaneously with the Truncate 453 Padding mode, the Session-Sender MUST append at least 27 octets of 454 padding plus the "Length of the padding to reflect" octets when 455 operating in Unauthenticated mode. The Session-Sender MUST append at 456 least 56 octets of padding plus the "Length of the padding to 457 reflect" octets when operating in Authenticated and Encrypted modes. 459 4.2. Reflector Behavior 461 The TWAMP Reflector follows the procedures and guidelines in section 462 4.2 of [RFC5357], with the following additional functions: 464 o Reflect Octets mode: Designated octets in the "Packet Padding (to 465 be reflected)" field of the Session-Sender's test packet MUST be 466 included in the Session-Reflector's test packet. 468 o Truncate Padding mode: Octets in the packet padding field of the 469 Session-Sender's test packet MUST be truncated so that the length 470 of the Session-Reflector's test packet equals the length of the 471 Session-Sender's test packet. 473 4.2.1. Packet Format and Contents 475 The Reflect Padding feature re-designates the packet padding field, 476 as shown below for unauthenticated mode: 478 0 1 2 3 479 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 480 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 481 | Sequence Number | 482 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 483 | Timestamp | 484 | | 485 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 486 | Error Estimate | MBZ | 487 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 488 | Receive Timestamp | 489 | | 490 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 491 | Sender Sequence Number | 492 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 493 | Sender Timestamp | 494 | | 495 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 496 | Sender Error Estimate | MBZ | 497 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 498 | Sender TTL | Packet Padding (from Session-Sender) | 499 +-+-+-+-+-+-+-+-+ + 500 . . 501 + +-+-+-+-+-+-+-+-+ 502 | Packet Padding (from Session-Sender) | | 503 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 504 | | 505 | | 506 . Additional Packet Padding . 507 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 508 The "Packet Padding (from Session-Sender)" field MUST be the same 509 octets as the "Packet Padding (to be reflected)" field in the 510 Session-Sender's test packet, and therefore MUST conform to the 511 length specified in the Request-TW-Session message. 513 IF the test packet length is truncated within the padding fields in 514 conformance with the RECOMMENDED truncation process in TWAMP section 515 4.2.1 [RFC5357], THEN ALL padding designated to be reflected MUST be 516 reflected by Session-Reflectors using this feature. 518 4.2.2. Padding Truncation 520 Note that the Session-Reflector Test Packet Formats are larger than 521 the Sender's formats. When the Truncate Padding mode is selected and 522 communicated in the Setup Response message, the Session-Reflector 523 must truncate a specific number of padding octets to achieve equal 524 size test packets in both directions. The number of octets truncated 525 depends on BOTH the security mode (Unauthenticated/Authenticated/ 526 Encrypted) and whether the Reflect octets mode is selected 527 simultaneously. 529 When using the Truncate Padding mode, the Session-Reflector MUST 530 truncate exactly 27 octets of padding in Unauthenticated mode, and 531 exactly 56 octets in Authenticated and Encrypted modes. The Session- 532 Reflector MAY re-use the Sender's Packet Padding (since the 533 requirements for padding generation are the same for each), and in 534 this case the Session-Reflector MUST truncate the padding such that 535 the highest number octets are discarded. 537 When simultaneously using the Truncate Padding mode AND Reflect 538 octets mode, the Session-Reflector MUST reflect the designated octets 539 from the Session-Sender's test packet in the "Packet Padding (from 540 Session-Sender)" Field, and MAY re-use additional Packet Padding from 541 the Session-Sender. The Session-Reflector MUST truncate the padding 542 such that the highest number octets are discarded, and the test 543 packet length equals the Session-Sender's packet length. 545 5. Possible Alternative 547 If new TWAMP-Test packet formats are defined, the Reflect Octets and 548 Truncate Padding modes could be folded into one new mode. 550 It would be possible to obtain even 4 octet boundaries in the revised 551 format. 553 It is also possible to simplfy test packet reflection by leaving the 554 Session-Sender's fields exactly as received, and replacing the 555 Discard Fill Field with the new time stamps and sequence number 556 determined by the Session-Reflector. 558 No calculations on padding are needed, and symmetrical packet size is 559 ensured for both directions of transmssion. 561 The "Packet Padding (to be reflected)" Field could contain 562 information that is TLV encoded, but in general the padding is opaque 563 to the Session-Reflector. 565 This Alternative is illustrated for discussion purposes. 567 New Session-Sender Test Packet Format: 569 0 1 2 3 570 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 571 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 572 | Sequence Number | 573 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 574 | Timestamp | 575 | | 576 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 577 | Error Estimate | MBZ (2 octets) | 578 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 579 | | 580 | | 581 | | 582 | Discard Fill | 583 | | 584 | | 585 | | 586 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 587 | | 588 | Packet Padding (to be reflected) | 589 . (length in octets specified elsewhere) . 590 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 591 . . 592 . Additional Packet Padding . 593 . . 594 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 595 The "Discard Fill" octets are discarded at the Session-Reflector. 597 New Session-Reflector Test Packet format: 599 0 1 2 3 600 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 601 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 602 | Sender Sequence Number | 603 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 604 | Sender Timestamp | 605 | | 606 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 607 | Sender Error Estimate | MBZ | 608 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 609 | Reflector Receive Timestamp | 610 | | 611 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 612 | Reflector Sequence Number | 613 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 614 | Reflector's Sending Timestamp | 615 | | 616 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 617 | Sender Error Estimate | MBZ | 618 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 619 | Sender TTL | MBZ (3 octets) | 620 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 621 . . 622 . Packet Padding (from Session-Sender) . 623 | | 624 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 625 . Additional Packet Padding . 626 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 628 6. Security Considerations 630 These extended modes of operation do not appear to permit any new 631 attacks on hosts communicating with core TWAMP [RFC5357] ??? 633 The security considerations that apply to any active measurement of 634 live networks are relevant here as well. See [RFC4656] and 635 [RFC5357]. 637 7. IANA Considerations 639 This memo adds two mode combinations to the IANA registry for the 640 TWAMP Modes Field, and describes behavior when the new modes are 641 used. This field is a recognized extension mechanism for TWAMP. 643 7.1. Registry Specification 645 IANA has created a TWAMP-Modes registry (as requested in 646 [I-D.ietf-ippm-more-twamp]). TWAMP-Modes are specified in TWAMP 647 Server Greeting messages and Set-up Response messages, as described 648 in section 3.1 of [RFC5357], consistent with section 3.1 of 649 [RFC4656], and extended by this memo. Modes are indicated by setting 650 bits in the 32-bit Modes field. Thus, this registry can contain a 651 total of 32 possible values. 653 7.2. Registry Management 655 Because the Modes registry can contain only thirty-two values, and 656 because TWAMP is an IETF protocol, this registry must be updated only 657 by "IETF Consensus" as specified in [RFC2434](an RFC documenting 658 registry use that is approved by the IESG). For the Modes registry, 659 we expect that new features will be assigned using monotonically 660 increasing bit positions and in the range [0-31] and the 661 corresponding values, unless there is a good reason to do otherwise. 663 7.3. Experimental Numbers 665 No experimental values are currently assigned for the Modes Registry. 667 7.4. Registry Contents 669 TWAMP Modes Registry is recommended to be augmented as follows: 671 Value Description Semantics Definition 672 0 Reserved 674 1 Unauthenticated RFC4656, Section 3.1 676 2 Authenticated RFC4656, Section 3.1 678 4 Encrypted RFC4656, Section 3.1 680 8 Unauth. TEST protocol, draft-ietf-more-twamp (3) 681 Auth. CONTROL 682 -------------------------------------------------------- 683 xxx Reflect Octets this memo, section 3.1 684 Capability new bit position (X) 685 yyy Truncate Padding this memo, section 3.1 686 Capability new bit position (Y) 687 The suggested values are 689 X=4, xxx=16 690 Y=5, yyy=32 692 8. Acknowledgements 694 The authors would like to thank Walt Steverson for helpful review and 695 comments. 697 9. References 699 9.1. Normative References 701 [I-D.ietf-ippm-more-twamp] 702 Morton, A. and K. Hedayat, "More Features for the Two-Way 703 Active Measurement Protocol - TWAMP", 704 draft-ietf-ippm-more-twamp-02 (work in progress), 705 May 2009. 707 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 708 Requirement Levels", BCP 14, RFC 2119, March 1997. 710 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 711 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 712 October 1998. 714 [RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M. 715 Zekauskas, "A One-way Active Measurement Protocol 716 (OWAMP)", RFC 4656, September 2006. 718 [RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J. 719 Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)", 720 RFC 5357, October 2008. 722 9.2. Informative References 724 [x] "". 726 Authors' Addresses 728 Al Morton 729 AT&T Labs 730 200 Laurel Avenue South 731 Middletown,, NJ 07748 732 USA 734 Phone: +1 732 420 1571 735 Fax: +1 732 368 1192 736 Email: acmorton@att.com 737 URI: http://home.comcast.net/~acmacm/ 739 Len Ciavattone 740 AT&T Labs 741 200 Laurel Avenue South 742 Middletown,, NJ 07748 743 USA 745 Phone: +1 732 420 1239 746 Fax: 747 Email: lencia@att.com 748 URI: