idnits 2.17.1 draft-ietf-ippm-stamp-03.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 : ---------------------------------------------------------------------------- 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 date (October 15, 2018) is 2019 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) == Outdated reference: A later version (-04) exists of draft-ietf-ippm-port-twamp-test-02 -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE.1588.2008' == Outdated reference: A later version (-12) exists of draft-ietf-ippm-stamp-yang-02 Summary: 0 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 G. Mirsky 3 Internet-Draft ZTE Corp. 4 Intended status: Standards Track G. Jun 5 Expires: April 18, 2019 ZTE Corporation 6 H. Nydell 7 Accedian Networks 8 R. Foote 9 Nokia 10 October 15, 2018 12 Simple Two-way Active Measurement Protocol 13 draft-ietf-ippm-stamp-03 15 Abstract 17 This document describes a Simple Two-way Active Measurement Protocol 18 which enables measurement of both one-way and round-trip performance 19 metrics like delay, delay variation, and packet loss. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at https://datatracker.ietf.org/drafts/current/. 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 This Internet-Draft will expire on April 18, 2019. 38 Copyright Notice 40 Copyright (c) 2018 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (https://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. Conventions used in this document . . . . . . . . . . . . . . 3 57 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 58 2.2. Requirements Language . . . . . . . . . . . . . . . . . . 3 59 3. Softwarization of Performance Measurement . . . . . . . . . . 3 60 4. Theory of Operation . . . . . . . . . . . . . . . . . . . . . 4 61 4.1. Session-Sender Behavior and Packet Format . . . . . . . . 4 62 4.1.1. Session-Sender Packet Format in Unauthenticated Mode 4 63 4.1.2. Session-Sender Packet Format in Authenticated and 64 Encrypted Modes . . . . . . . . . . . . . . . . . . . 7 65 4.2. Session-Reflector Behavior and Packet Format . . . . . . 8 66 4.2.1. Session-Reflector Packet Format in Unauthenticated 67 Mode . . . . . . . . . . . . . . . . . . . . . . . . 9 68 4.2.2. Session-Reflector Packet Format in Authenticated and 69 Encrypted Modes . . . . . . . . . . . . . . . . . . . 10 70 4.3. Authentication and Encryption Operations on STAMP Packets 12 71 4.4. Interoperability with TWAMP Light . . . . . . . . . . . . 12 72 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 73 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 74 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 75 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 76 8.1. Normative References . . . . . . . . . . . . . . . . . . 13 77 8.2. Informative References . . . . . . . . . . . . . . . . . 14 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 80 1. Introduction 82 Development and deployment of Two-Way Active Measurement Protocol 83 (TWAMP) [RFC5357] and its extensions, e.g., [RFC6038] that defined 84 features such as Reflect Octets and Symmetrical Size for TWAMP 85 provided invaluable experience. Several independent implementations 86 exist, have been deployed and provide important operational 87 performance measurements. At the same time, there has been 88 noticeable interest in using a simpler mechanism for active 89 performance monitoring that can provide deterministic behavior and 90 inherit separation of control (vendor-specific configuration or 91 orchestration) and test functions. One of such is Performance 92 Measurement from IP Edge to Customer Equipment using TWAMP Light from 93 Broadband Forum ([BBF.TR-390]). This document defines active 94 performance measurement test protocol, Simple Two-way Active 95 Measurement Protocol (STAMP), that enables measurement of both one- 96 way and round-trip performance metrics like delay, delay variation, 97 and packet loss. 99 2. Conventions used in this document 101 2.1. Terminology 103 AES Advanced Encryption Standard 105 CBC Cipher Block Chaining 107 ECB Electronic Cookbook 109 KEK Key-encryption Key 111 STAMP - Simple Two-way Active Measurement Protocol 113 NTP - Network Time Protocol 115 PTP - Precision Time Protocol 117 HMAC Hashed Message Authentication Code 119 OWAMP One-Way Active Measurement Protocol 121 TWAMP Two-Way Active Measurement Protocol 123 2.2. Requirements Language 125 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 126 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 127 "OPTIONAL" in this document are to be interpreted as described in BCP 128 14 [RFC2119] [RFC8174] when, and only when, they appear in all 129 capitals, as shown here. 131 3. Softwarization of Performance Measurement 133 Figure 1 presents Simple Two-way Active Measurement Protocol (STAMP) 134 Session-Sender and Session-Reflector with a measurement session. The 135 configuration and management of the STAMP Session-Sender, Session- 136 Reflector and management of the STAMP sessions can be achieved 137 through various means. Command Line Interface, OSS/BSS using SNMP or 138 SDN using Netconf/YANG are but a few examples. 140 o----------------------------------------------------------o 141 | Configuration and | 142 | Management | 143 o----------------------------------------------------------o 144 || || 145 || || 146 || || 147 +----------------------+ +-------------------------+ 148 | STAMP Session-Sender | <--- STAMP---> | STAMP Session-Reflector | 149 +----------------------+ +-------------------------+ 151 Figure 1: STAMP Reference Model 153 4. Theory of Operation 155 STAMP Session-Sender transmits test packets toward STAMP Session- 156 Reflector. STAMP Session-Reflector receives Session-Sender's packet 157 and acts according to the configuration and optional control 158 information communicated in the Session-Sender's test packet. STAMP 159 defines two different test packet formats, one for packets 160 transmitted by the STAMP-Session-Sender and one for packets 161 transmitted by the STAMP-Session-Reflector. STAMP supports three 162 modes: unauthenticated, authenticated, and encrypted. 163 Unauthenticated STAMP test packets are compatible on the wire with 164 unauthenticated TWAMP-Test [RFC5357] packet formats. 166 By default, STAMP uses symmetrical packets, i.e., size of the packet 167 transmitted by Session-Reflector equals the size of the packet 168 received by the Session-Reflector. 170 4.1. Session-Sender Behavior and Packet Format 172 4.1.1. Session-Sender Packet Format in Unauthenticated Mode 174 Because STAMP supports symmetrical test packets, STAMP Session-Sender 175 packet has a minimum size of 44 octets in unauthenticated mode, see 176 Figure 2, and 48 octets in authenticated or encrypted modes, see 177 Figure 4. 179 For unauthenticated mode: 181 0 1 2 3 182 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 183 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 184 | Sequence Number | 185 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 186 | Timestamp | 187 | | 188 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 189 | Error Estimate | | 190 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 191 | | 192 | | 193 | MBZ (27 octets) | 194 | | 195 | | 196 | | 197 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 198 | | Server Octets | | 199 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 200 | Remaining Packet Padding (to be reflected) | 201 ~ (length in octets specified in Server Octets) ~ 202 + +-+-+-+-+-+-+-+-+ 203 | | Comp.MBZ | 204 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 205 | Type | Length | 206 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 207 ~ Value ~ 208 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 210 Figure 2: STAMP Session-Sender test packet format in unauthenticated 211 mode 213 where fields are defined as the following: 215 o Sequence Number is four octets long field. For each new session 216 its value starts at zero and is incremented with each transmitted 217 packet. 219 o Timestamp is eight octets long field. STAMP node MUST support 220 Network Time Protocol (NTP) version 4 64-bit timestamp format 221 [RFC5905]. STAMP node MAY support IEEE 1588v2 Precision Time 222 Protocol truncated 64-bit timestamp format [IEEE.1588.2008]. 224 o Error Estimate is two octets long field with format displayed in 225 Figure 3 226 0 1 227 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 229 |S|Z| Scale | Multiplier | 230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 232 Figure 3: Error Estimate Format 234 where S, Scale, and Multiplier fields are interpreted as they have 235 been defined in section 4.1.2 [RFC4656]; and Z field - as has been 236 defined in section 2.3 [RFC8186]: 238 * 0 - NTP 64 bit format of a timestamp; 240 * 1 - PTPv2 truncated format of a timestamp. 242 The STAMP Session-Sender and Session-Reflector MAY use, not use, 243 or set value of the Z field in accordance with the timestamp 244 format in use. This optional field is to enhance operations, but 245 local configuration or defaults could be used in its place. 247 o Must-be-Zero (MBZ) field in the session-sender unauthenticated 248 packet is 27 octets long. It MUST be all zeroed on the 249 transmission and ignored on receipt. 251 o Server Octets field is two octets long field. It MUST follow the 252 27 octets long MBZ field. The Reflect Octets capability defined 253 in [RFC6038]. The value in the Server Octets field equals the 254 number of octets the Session-Reflector is expected to copy back to 255 the Session-Sender starting with the Server Octets field. Thus 256 the minimal non-zero value for the Server Octets field is two. 257 Therefore, the value of one is invalid. If none of Payload to be 258 copied, the value of the Server Octets field MUST be set to zero 259 on transmit. 261 o Remaining Packet Padding is an optional field of variable length. 262 The number of octets in the Remaining Packet Padding field is the 263 value of the Server Octets field less the length of the Server 264 Octets field. 266 o Comp.MBZ is variable length field used to achieve alignment on a 267 word boundary. Thus the length of Comp.MBZ field may be only 0, 268 1, 2 or 3 octets. The value of the field MUST be zeroed on 269 transmission and ignored on receipt. 271 The unauthenticated STAMP Session-Sender packet MAY include Type- 272 Length-Value encodings that immediately follow the Comp. MBZ field. 274 o Type field is two octets long. The value of the Type field is the 275 codepoint allocated by IANA Section 5 that identifies data in the 276 Value field. 278 o Length is two octets long field, and its value is the length of 279 the Value field in octets. 281 o Value field contains the application specific information. The 282 length of the Value field MUST be four octets aligned. 284 4.1.2. Session-Sender Packet Format in Authenticated and Encrypted 285 Modes 287 For authenticated and encrypted modes: 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 | Sequence Number | 293 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 294 | | 295 | MBZ (12 octets) | 296 | | 297 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 298 | Timestamp | 299 | | 300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 301 | Error Estimate | | 302 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 303 ~ ~ 304 | MBZ (70 octets) | 305 ~ ~ 306 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 307 | Type | Length | 308 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 309 ~ Value ~ 310 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 311 ~ Comp.MBZ ~ 312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 313 | | 314 | HMAC (16 octets) | 315 | | 316 | | 317 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 319 Figure 4: STAMP Session-Sender test packet format in authenticated or 320 encrypted modes 322 The field definitions are the same as the unauthenticated mode, 323 listed in Section 4.1.1. Also, Comp.MBZ field is variable length 324 field to align the packet on 16 octets boundary. Also, the packet 325 includes a key-hashed message authentication code (HMAC) ([RFC2104]) 326 hash at the end of the PDU. 328 The STAMP Session-Sender-packet format (Figure 4) is the same in 329 authenticated and encrypted modes. The encryption and authentication 330 operations are, however, different and protect the data as follows: 332 in the authenticated mode the Sequence Number is protected while 333 the Timestamp and the Error Estimate are sent in clear text; 335 in encrypted mode all fields, including the timestamp and Error 336 Estimate, are protected to provide maximum data confidentiality 337 and integrity protection. 339 Sending the Timestamp in clear text in authenticated mode allows more 340 consistent reading of time by a Session-Sender on the transmission of 341 the test packet. Reading of the time in encrypted mode must be 342 followed by its encryption which introduces variable delay thus 343 affecting calculated timing metrics. 345 4.2. Session-Reflector Behavior and Packet Format 347 The Session-Reflector receives the STAMP test packet, verifies it, 348 prepares and transmits the reflected test packet. 350 Two modes of STAMP Session-Reflector characterize the expected 351 behavior and, consequently, performance metrics that can be measured: 353 o Stateless - STAMP Session-Reflector does not maintain test state 354 and will reflect the received sequence number without 355 modification. As a result, only round-trip packet loss can be 356 calculated while the reflector is operating in stateless mode. 358 o Stateful - STAMP Session-Reflector maintains test state thus 359 enabling the ability to determine forward loss, gaps recognized in 360 the received sequence number. As a result, both near-end 361 (forward) and far-end (backward) packet loss can be computed. 362 That implies that the STAMP Session-Reflector MUST keep a state 363 for each accepted STAMP-test session, uniquely identifying STAMP- 364 test packets to one such session instance, and enabling adding a 365 sequence number in the test reply that is individually incremented 366 on a per-session basis. 368 4.2.1. Session-Reflector Packet Format in Unauthenticated Mode 370 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 | MBZ | 381 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 382 | Receive Timestamp | 383 | | 384 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 385 | Session-Sender Sequence Number | 386 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 387 | Session-Sender Timestamp | 388 | | 389 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 390 | Session-Sender Error Estimate | MBZ | 391 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 392 |Ses-Sender TTL | | 393 +-+-+-+-+-+-+-+-+ + 394 | | 395 ~ Packet Padding (reflected) ~ 396 + +-+-+-+-+-+-+-+-+ 397 | | Comp.MBZ | 398 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 399 | Type | Length | 400 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 401 ~ Value ~ 402 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 404 Figure 5: STAMP Session-Reflector test packet format in 405 unauthenticated mode 407 where fields are defined as the following: 409 o Sequence Number is four octets long field. The value of the 410 Sequence Number field is set according to the mode of the STAMP 411 Session-Reflector: 413 * in the stateless mode the Session-Reflector copies the value 414 from the received STAMP test packet's Sequence Number field; 416 * in the stateful mode the Session-Reflector counts the received 417 STAMP test packets in each test session and uses that counter 418 to set the value of the Sequence Number field. 420 o Timestamp and Receiver Timestamp fields are each eight octets 421 long. The format of these fields, NTP or PTPv2, indicated by the 422 Z flag of the Error Estimate field as described in Section 4.1. 424 o Error Estimate has the same size and interpretation as described 425 in Section 4.1. 427 o Session-Sender Sequence Number, Session-Sender Timestamp, and 428 Session-Sender Error Estimate are copies of the corresponding 429 fields in the STAMP test packet sent by the Session-Sender. 431 o Session-Sender TTL is one octet long field, and its value is the 432 copy of the TTL field from the received STAMP test packet. 434 o Packet Padding (reflected) is an optional variable length field. 435 The length of the Packet Padding (reflected) field MUST be equal 436 to the value of the Server Octets field (Figure 2). If the value 437 is non-zero, the Session-Reflector copies octets starting with the 438 Server Octets field. 440 o Comp.MBZ is variable length field used to achieve alignment on a 441 word boundary. Thus the length of Comp.MBZ field may be only 0, 442 1, 2 or 3 octets. The value of the field MUST be zeroed on 443 transmission and ignored on receipt. 445 4.2.2. Session-Reflector Packet Format in Authenticated and Encrypted 446 Modes 448 For authenticated and encrypted modes: 450 0 1 2 3 451 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 452 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 453 | Sequence Number | 454 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 455 | MBZ (12 octets) | 456 | | 457 | | 458 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 459 | Timestamp | 460 | | 461 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 462 | Error Estimate | | 463 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 464 | MBZ (6 octets) | 465 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 466 | Receive Timestamp | 467 | | 468 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 469 | MBZ (8 octets) | 470 | | 471 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 472 | Session-Sender Sequence Number | 473 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 474 | MBZ (12 octets) | 475 | | 476 | | 477 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 478 | Session-Sender Timestamp | 479 | | 480 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 481 | Session-Sender Error Estimate | | 482 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 483 | MBZ (6 octets) | 484 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 485 |Ses-Sender TTL | | 486 +-+-+-+-+-+-+-+-+ + 487 | | 488 | MBZ (15 octets) | 489 | | 490 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 491 | Type | Length | 492 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 493 ~ Value ~ 494 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 495 ~ Comp.MBZ ~ 496 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 497 | HMAC (16 octets) | 498 | | 499 | | 500 | | 501 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 503 Figure 6: STAMP Session-Reflector test packet format in authenticated 504 or encrypted modes 506 The field definitions are the same as the unauthenticated mode, 507 listed in Section 4.2.1. Additionally, the packet MAY include 508 Comp.MBZ field is variable length field to align the packet on 16 509 octets boundary. Also, STAMP Session-Reflector test packet format in 510 authenticated or encrypted modes includes a key (HMAC) ([RFC2104]) 511 hash at the end of the PDU. 513 4.3. Authentication and Encryption Operations on STAMP Packets 515 STAMP uses a two-pronged approach to protect the confidentiality and 516 integrity of the measurement information. In authenticated and 517 encrypted modes each STAMP message is being authenticated by adding 518 Hashed Message Authentication Code (HMAC). STAMP uses HMAC-SHA1 519 truncated to 128 bits; hence the length of the HMAC field is 16 520 octets. HMAC uses its own key. Mechanism to distribute the HMAC key 521 is outside the scope of this specification. One example is to use an 522 orchestrator to configure HMAC key based on STAMP YANG data model 523 [I-D.ietf-ippm-stamp-yang]. HMAC MUST be verified as early as 524 possible to avoid using or propagating corrupted data. 526 In the authenticated mode only the first 16 octets block of the STAMP 527 test packet (Figure 6 and Figure 6) is encrypted using AES Electronic 528 Codebook (ECB) mode. In the encrypted mode, the whole STAMP test 529 packet excluding the HMAC field is encrypted. STAMP using AES-CBC 530 (Cipher Block Chaining) mode. Distribution and management of AES key 531 are outside the scope of this specification. 533 4.4. Interoperability with TWAMP Light 535 One of the essential requirements to STAMP is the ability to 536 interwork with TWAMP Light device. There are two possible 537 combinations for such use case: 539 o STAMP Session-Sender with TWAMP Light Session-Reflector; 541 o TWAMP Light Session-Sender with STAMP Session-Reflector. 543 In the former case, Session-Sender MAY not be aware that its Session- 544 Reflector does not support STAMP. For example, TWAMP Light Session- 545 Reflector may not support the use of UDP port 862 as defined in 546 [I-D.ietf-ippm-port-twamp-test]. Thus STAMP Session-Sender MUST be 547 able to send test packets to destination UDP port number from the 548 Dynamic and/or Private Ports range 49152-65535, test management 549 system should find port number that both devices can use. And if any 550 of TLV-based STAMP extensions are used, the TWAMP Light Session- 551 Reflector will view them as Packet Padding field. The Session-Sender 552 SHOULD use the default format for its timestamps - NTP. And it MAY 553 use PTPv2 timestamp format. 555 In the latter scenario, the test management system should set STAMP 556 Session-Reflector to use UDP port number from the Dynamic and/or 557 Private Ports range. As for Packet Padding field that the TWAMP 558 Light Session-Sender includes in its transmitted packet, the STAMP 559 Session-Reflector will process it according to [RFC6038] and return 560 reflected packet of the symmetrical size. The Session-Reflector MUST 561 use the default format for its timestamps - NTP. 563 5. IANA Considerations 565 This document doesn't have any IANA action. This section may be 566 removed before the publication. 568 6. Security Considerations 570 Use of HMAC in authenticated and encrypted modes may be used to 571 simultaneously verify both the data integrity and the authentication 572 of the STAMP test packets. 574 7. Acknowledgments 576 TBD 578 8. References 580 8.1. Normative References 582 [BBF.TR-390] 583 "Performance Measurement from IP Edge to Customer 584 Equipment using TWAMP Light", BBF TR-390, May 2017. 586 [I-D.ietf-ippm-port-twamp-test] 587 Morton, A. and G. Mirsky, "OWAMP and TWAMP Well-Known Port 588 Assignments", draft-ietf-ippm-port-twamp-test-02 (work in 589 progress), October 2018. 591 [IEEE.1588.2008] 592 "Standard for a Precision Clock Synchronization Protocol 593 for Networked Measurement and Control Systems", 594 IEEE Standard 1588, March 2008. 596 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 597 Requirement Levels", BCP 14, RFC 2119, 598 DOI 10.17487/RFC2119, March 1997, 599 . 601 [RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M. 602 Zekauskas, "A One-way Active Measurement Protocol 603 (OWAMP)", RFC 4656, DOI 10.17487/RFC4656, September 2006, 604 . 606 [RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J. 607 Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)", 608 RFC 5357, DOI 10.17487/RFC5357, October 2008, 609 . 611 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, 612 "Network Time Protocol Version 4: Protocol and Algorithms 613 Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, 614 . 616 [RFC6038] Morton, A. and L. Ciavattone, "Two-Way Active Measurement 617 Protocol (TWAMP) Reflect Octets and Symmetrical Size 618 Features", RFC 6038, DOI 10.17487/RFC6038, October 2010, 619 . 621 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 622 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 623 May 2017, . 625 [RFC8186] Mirsky, G. and I. Meilik, "Support of the IEEE 1588 626 Timestamp Format in a Two-Way Active Measurement Protocol 627 (TWAMP)", RFC 8186, DOI 10.17487/RFC8186, June 2017, 628 . 630 8.2. Informative References 632 [I-D.ietf-ippm-stamp-yang] 633 Mirsky, G., Xiao, M., and W. Luo, "Simple Two-way Active 634 Measurement Protocol (STAMP) Data Model", draft-ietf-ippm- 635 stamp-yang-02 (work in progress), September 2018. 637 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 638 Hashing for Message Authentication", RFC 2104, 639 DOI 10.17487/RFC2104, February 1997, 640 . 642 Authors' Addresses 644 Greg Mirsky 645 ZTE Corp. 647 Email: gregimirsky@gmail.com 648 Guo Jun 649 ZTE Corporation 650 68# Zijinghua Road 651 Nanjing, Jiangsu 210012 652 P.R.China 654 Phone: +86 18105183663 655 Email: guo.jun2@zte.com.cn 657 Henrik Nydell 658 Accedian Networks 660 Email: hnydell@accedian.com 662 Richard Foote 663 Nokia 665 Email: footer.foote@nokia.com