< draft-ietf-ippm-stamp-05.txt | draft-ietf-ippm-stamp-06.txt > | |||
---|---|---|---|---|
Network Working Group G. Mirsky | Network Working Group G. Mirsky | |||
Internet-Draft ZTE Corp. | Internet-Draft ZTE Corp. | |||
Intended status: Standards Track G. Jun | Intended status: Standards Track G. Jun | |||
Expires: June 1, 2019 ZTE Corporation | Expires: October 25, 2019 ZTE Corporation | |||
H. Nydell | H. Nydell | |||
Accedian Networks | Accedian Networks | |||
R. Foote | R. Foote | |||
Nokia | Nokia | |||
November 28, 2018 | April 23, 2019 | |||
Simple Two-way Active Measurement Protocol | Simple Two-way Active Measurement Protocol | |||
draft-ietf-ippm-stamp-05 | draft-ietf-ippm-stamp-06 | |||
Abstract | Abstract | |||
This document describes a Simple Two-way Active Measurement Protocol | This document describes a Simple Two-way Active Measurement Protocol | |||
which enables the measurement of both one-way and round-trip | which enables the measurement of both one-way and round-trip | |||
performance metrics like delay, delay variation, and packet loss. | performance metrics like delay, delay variation, and packet loss. | |||
Status of This Memo | Status of This Memo | |||
This Internet-Draft is submitted in full conformance with the | This Internet-Draft is submitted in full conformance with the | |||
skipping to change at page 1, line 37 ¶ | skipping to change at page 1, line 37 ¶ | |||
Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
Task Force (IETF). Note that other groups may also distribute | Task Force (IETF). Note that other groups may also distribute | |||
working documents as Internet-Drafts. The list of current Internet- | working documents as Internet-Drafts. The list of current Internet- | |||
Drafts is at https://datatracker.ietf.org/drafts/current/. | Drafts is at https://datatracker.ietf.org/drafts/current/. | |||
Internet-Drafts are draft documents valid for a maximum of six months | Internet-Drafts are draft documents valid for a maximum of six months | |||
and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
This Internet-Draft will expire on June 1, 2019. | This Internet-Draft will expire on October 25, 2019. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2018 IETF Trust and the persons identified as the | Copyright (c) 2019 IETF Trust and the persons identified as the | |||
document authors. All rights reserved. | document authors. All rights reserved. | |||
This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
Provisions Relating to IETF Documents | Provisions Relating to IETF Documents | |||
(https://trustee.ietf.org/license-info) in effect on the date of | (https://trustee.ietf.org/license-info) in effect on the date of | |||
publication of this document. Please review these documents | publication of this document. Please review these documents | |||
carefully, as they describe your rights and restrictions with respect | carefully, as they describe your rights and restrictions with respect | |||
to this document. Code Components extracted from this document must | to this document. Code Components extracted from this document must | |||
include Simplified BSD License text as described in Section 4.e of | include Simplified BSD License text as described in Section 4.e of | |||
the Trust Legal Provisions and are provided without warranty as | the Trust Legal Provisions and are provided without warranty as | |||
skipping to change at page 2, line 18 ¶ | skipping to change at page 2, line 18 ¶ | |||
Table of Contents | Table of Contents | |||
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 | |||
2. Conventions used in this document . . . . . . . . . . . . . . 3 | 2. Conventions used in this document . . . . . . . . . . . . . . 3 | |||
2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 | 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 | |||
2.2. Requirements Language . . . . . . . . . . . . . . . . . . 3 | 2.2. Requirements Language . . . . . . . . . . . . . . . . . . 3 | |||
3. Softwarization of Performance Measurement . . . . . . . . . . 3 | 3. Softwarization of Performance Measurement . . . . . . . . . . 3 | |||
4. Theory of Operation . . . . . . . . . . . . . . . . . . . . . 4 | 4. Theory of Operation . . . . . . . . . . . . . . . . . . . . . 4 | |||
4.1. Session-Sender Behavior and Packet Format . . . . . . . . 4 | 4.1. Session-Sender Behavior and Packet Format . . . . . . . . 4 | |||
4.1.1. Session-Sender Packet Format in Unauthenticated Mode 4 | 4.1.1. Session-Sender Packet Format in Unauthenticated Mode 4 | |||
4.1.2. Session-Sender Packet Format in Authenticated Mode . 7 | 4.1.2. Session-Sender Packet Format in Authenticated Mode . 6 | |||
4.2. Session-Reflector Behavior and Packet Format . . . . . . 7 | 4.2. Session-Reflector Behavior and Packet Format . . . . . . 7 | |||
4.2.1. Session-Reflector Packet Format in Unauthenticated | 4.2.1. Session-Reflector Packet Format in Unauthenticated | |||
Mode . . . . . . . . . . . . . . . . . . . . . . . . 8 | Mode . . . . . . . . . . . . . . . . . . . . . . . . 8 | |||
4.2.2. Session-Reflector Packet Format in Authenticated Mode 10 | 4.2.2. Session-Reflector Packet Format in Authenticated Mode 9 | |||
4.3. Integrity and Confidentiality Protection in STAMP . . . . 12 | 4.3. Integrity and Confidentiality Protection in STAMP . . . . 11 | |||
4.4. Interoperability with TWAMP Light . . . . . . . . . . . . 12 | 4.4. Interoperability with TWAMP Light . . . . . . . . . . . . 11 | |||
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 | 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 | |||
6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 | 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 | |||
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 | 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 | |||
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 | 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 | |||
8.1. Normative References . . . . . . . . . . . . . . . . . . 13 | 8.1. Normative References . . . . . . . . . . . . . . . . . . 12 | |||
8.2. Informative References . . . . . . . . . . . . . . . . . 14 | 8.2. Informative References . . . . . . . . . . . . . . . . . 13 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 | |||
1. Introduction | 1. Introduction | |||
Development and deployment of Two-Way Active Measurement Protocol | Development and deployment of Two-Way Active Measurement Protocol | |||
(TWAMP) [RFC5357] and its extensions, e.g., [RFC6038] that defined | (TWAMP) [RFC5357] and its extensions, e.g., [RFC6038] that defined | |||
features such as Reflect Octets and Symmetrical Size for TWAMP | features such as Reflect Octets and Symmetrical Size for TWAMP | |||
provided invaluable experience. Several independent implementations | provided invaluable experience. Several independent implementations | |||
exist, have been deployed and provide important operational | exist, have been deployed and provide important operational | |||
performance measurements. At the same time, there has been | performance measurements. At the same time, there has been | |||
noticeable interest in using a simpler mechanism for active | noticeable interest in using a simpler mechanism for active | |||
performance monitoring that can provide deterministic behavior and | performance monitoring that can provide deterministic behavior and | |||
inherit separation of control (vendor-specific configuration or | inherit separation of control (vendor-specific configuration or | |||
orchestration) and test functions. One of such is Performance | orchestration) and test functions. One of such is Performance | |||
Measurement from IP Edge to Customer Equipment using TWAMP Light from | Measurement from IP Edge to Customer Equipment using TWAMP Light from | |||
Broadband Forum ([BBF.TR-390]). This document defines active | Broadband Forum [BBF.TR-390] used as the reference TWAMP Light that, | |||
performance measurement test protocol, Simple Two-way Active | according to [RFC8545], includes sub-set of TWAMP-Test functions in | |||
Measurement Protocol (STAMP), that enables measurement of both one- | combination with other applications that provide, for example, | |||
way and round-trip performance metrics like delay, delay variation, | control and security. This document defines active performance | |||
and packet loss. | measurement test protocol, Simple Two-way Active Measurement Protocol | |||
(STAMP), that enables measurement of both one-way and round-trip | ||||
performance metrics like delay, delay variation, and packet loss. | ||||
2. Conventions used in this document | 2. Conventions used in this document | |||
2.1. Terminology | 2.1. Terminology | |||
AES Advanced Encryption Standard | AES Advanced Encryption Standard | |||
CBC Cipher Block Chaining | CBC Cipher Block Chaining | |||
ECB Electronic Cookbook | ECB Electronic Cookbook | |||
skipping to change at page 3, line 39 ¶ | skipping to change at page 3, line 41 ¶ | |||
2.2. Requirements Language | 2.2. Requirements Language | |||
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | |||
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and | "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and | |||
"OPTIONAL" in this document are to be interpreted as described in BCP | "OPTIONAL" in this document are to be interpreted as described in BCP | |||
14 [RFC2119] [RFC8174] when, and only when, they appear in all | 14 [RFC2119] [RFC8174] when, and only when, they appear in all | |||
capitals, as shown here. | capitals, as shown here. | |||
3. Softwarization of Performance Measurement | 3. Softwarization of Performance Measurement | |||
Figure 1 presents Simple Two-way Active Measurement Protocol (STAMP) | Figure 1 presents the Simple Two-way Active Measurement Protocol | |||
Session-Sender and Session-Reflector with a measurement session. The | (STAMP) Session-Sender and Session-Reflector with a measurement | |||
configuration and management of the STAMP Session-Sender, Session- | session. The configuration and management of the STAMP Session- | |||
Reflector and management of the STAMP sessions can be achieved | Sender, Session-Reflector and management of the STAMP sessions can be | |||
through various means. Command Line Interface, OSS/BSS using SNMP or | achieved through various means. Command Line Interface, OSS/BSS | |||
SDN using Netconf/YANG are but a few examples. | (operations support system/business support system as a combination | |||
of two systems used to support a range of telecommunication services) | ||||
using SNMP or controllers in Software-Defined Networking using | ||||
Netconf/YANG are but a few examples. | ||||
o----------------------------------------------------------o | o----------------------------------------------------------o | |||
| Configuration and | | | Configuration and | | |||
| Management | | | Management | | |||
o----------------------------------------------------------o | o----------------------------------------------------------o | |||
|| || | || || | |||
|| || | || || | |||
|| || | || || | |||
+----------------------+ +-------------------------+ | +----------------------+ +-------------------------+ | |||
| STAMP Session-Sender | <--- STAMP---> | STAMP Session-Reflector | | | STAMP Session-Sender | <--- STAMP---> | STAMP Session-Reflector | | |||
skipping to change at page 4, line 28 ¶ | skipping to change at page 4, line 28 ¶ | |||
4. Theory of Operation | 4. Theory of Operation | |||
STAMP Session-Sender transmits test packets toward STAMP Session- | STAMP Session-Sender transmits test packets toward STAMP Session- | |||
Reflector. STAMP Session-Reflector receives Session-Sender's packet | Reflector. STAMP Session-Reflector receives Session-Sender's packet | |||
and acts according to the configuration and optional control | and acts according to the configuration and optional control | |||
information communicated in the Session-Sender's test packet. STAMP | information communicated in the Session-Sender's test packet. STAMP | |||
defines two different test packet formats, one for packets | defines two different test packet formats, one for packets | |||
transmitted by the STAMP-Session-Sender and one for packets | transmitted by the STAMP-Session-Sender and one for packets | |||
transmitted by the STAMP-Session-Reflector. STAMP supports two | transmitted by the STAMP-Session-Reflector. STAMP supports two | |||
modes: unauthenticated and authenticated. Unauthenticated STAMP test | modes: unauthenticated and authenticated. Unauthenticated STAMP test | |||
packets are compatible on the wire with unauthenticated TWAMP-Test | packets, defined in Section 4.1.1 and Section 4.2.1, ensure | |||
[RFC5357] packet formats. | interworking between STAMP and TWAMP Light as described in | |||
Section 4.4 packet formats. | ||||
By default, STAMP uses symmetrical packets, i.e., size of the packet | By default, STAMP uses symmetrical packets, i.e., size of the packet | |||
transmitted by Session-Reflector equals the size of the packet | transmitted by Session-Reflector equals the size of the packet | |||
received by the Session-Reflector. | received by the Session-Reflector. | |||
4.1. Session-Sender Behavior and Packet Format | 4.1. Session-Sender Behavior and Packet Format | |||
4.1.1. Session-Sender Packet Format in Unauthenticated Mode | ||||
Because STAMP supports symmetrical test packets, STAMP Session-Sender | Because STAMP supports symmetrical test packets, STAMP Session-Sender | |||
packet has a minimum size of 44 octets in unauthenticated mode, see | packet has a minimum size of 44 octets in unauthenticated mode, see | |||
Figure 2, and 48 octets in the authenticated mode, see Figure 4. | Figure 2, and 112 octets in the authenticated mode, see Figure 4. | |||
For unauthenticated mode: | 4.1.1. Session-Sender Packet Format in Unauthenticated Mode | |||
STAMP Session-Sender packet format in unauthenticated mode: | ||||
0 1 2 3 | 0 1 2 3 | |||
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 | 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 | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Sequence Number | | | Sequence Number | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Timestamp | | | Timestamp | | |||
| | | | | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Error Estimate | | | | Error Estimate | | | |||
skipping to change at page 5, line 27 ¶ | skipping to change at page 5, line 27 ¶ | |||
| MBZ (27 octets) | | | MBZ (27 octets) | | |||
| | | | | | |||
| | | | | | |||
| | | | | | |||
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | Server Octets | | | | | Server Octets | | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | |||
| Remaining Packet Padding (to be reflected) | | | Remaining Packet Padding (to be reflected) | | |||
~ (length in octets specified in Server Octets) ~ | ~ (length in octets specified in Server Octets) ~ | |||
+ +-+-+-+-+-+-+-+-+ | + +-+-+-+-+-+-+-+-+ | |||
| | Comp.MBZ | | | | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Type | Length | | ||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
~ Value ~ | ||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
Figure 2: STAMP Session-Sender test packet format in unauthenticated | Figure 2: STAMP Session-Sender test packet format in unauthenticated | |||
mode | mode | |||
where fields are defined as the following: | where fields are defined as the following: | |||
o Sequence Number is four octets long field. For each new session | o Sequence Number is four octets long field. For each new session | |||
its value starts at zero and is incremented with each transmitted | its value starts at zero and is incremented with each transmitted | |||
packet. | packet. | |||
o Timestamp is eight octets long field. STAMP node MUST support | o Timestamp is eight octets long field. STAMP node MUST support | |||
Network Time Protocol (NTP) version 4 64-bit timestamp format | Network Time Protocol (NTP) version 4 64-bit timestamp format | |||
[RFC5905]. STAMP node MAY support IEEE 1588v2 Precision Time | [RFC5905], the format used in [RFC5357]. STAMP node MAY support | |||
Protocol truncated 64-bit timestamp format [IEEE.1588.2008]. | IEEE 1588v2 Precision Time Protocol truncated 64-bit timestamp | |||
format [IEEE.1588.2008], the format used in [RFC8186]. | ||||
o Error Estimate is two octets long field with format displayed in | o Error Estimate is two octets long field with format displayed in | |||
Figure 3 | Figure 3 | |||
0 1 | 0 1 | |||
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 | 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
|S|Z| Scale | Multiplier | | |S|Z| Scale | Multiplier | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
Figure 3: Error Estimate Format | Figure 3: Error Estimate Format | |||
skipping to change at page 6, line 29 ¶ | skipping to change at page 6, line 29 ¶ | |||
The STAMP Session-Sender and Session-Reflector MAY use, not use, | The STAMP Session-Sender and Session-Reflector MAY use, not use, | |||
or set value of the Z field in accordance with the timestamp | or set value of the Z field in accordance with the timestamp | |||
format in use. This optional field is to enhance operations, but | format in use. This optional field is to enhance operations, but | |||
local configuration or defaults could be used in its place. | local configuration or defaults could be used in its place. | |||
o Must-be-Zero (MBZ) field in the session-sender unauthenticated | o Must-be-Zero (MBZ) field in the session-sender unauthenticated | |||
packet is 27 octets long. It MUST be all zeroed on the | packet is 27 octets long. It MUST be all zeroed on the | |||
transmission and ignored on receipt. | transmission and ignored on receipt. | |||
o Server Octets field is two octets long field. It MUST follow the | o Server Octets field is optional two octets long field. This field | |||
27 octets long MBZ field. The Reflect Octets capability defined | is used for the Reflect Octets capability defined in [RFC6038]. | |||
in [RFC6038]. The value in the Server Octets field equals the | If being used, the Server Octets field MUST follow the 27 octets | |||
long MBZ field. The value in the Server Octets field equals the | ||||
number of octets the Session-Reflector is expected to copy back to | number of octets the Session-Reflector is expected to copy back to | |||
the Session-Sender starting with the Server Octets field. Thus | the Session-Sender starting with the Server Octets field. Thus | |||
the minimal non-zero value for the Server Octets field is two. | the minimum non-zero value for the Server Octets field is two. | |||
Therefore, the value of one is invalid. If none of Payload to be | Therefore, the value of one is invalid. If none of Payload to be | |||
copied, the value of the Server Octets field MUST be set to zero | copied, the value of the Server Octets field MUST be set to zero | |||
on transmit. | on transmit. | |||
o Remaining Packet Padding is an optional field of variable length. | o Remaining Packet Padding is an optional field of variable length. | |||
The number of octets in the Remaining Packet Padding field is the | The number of octets in the Remaining Packet Padding field is the | |||
value of the Server Octets field less the length of the Server | value of the Server Octets field minus the length of the Server | |||
Octets field. | Octets field. | |||
o Comp.MBZ is variable length field used to achieve alignment on a | ||||
word boundary. Thus the length of Comp.MBZ field may be only 0, | ||||
1, 2 or 3 octets. The value of the field MUST be zeroed on | ||||
transmission and ignored on receipt. | ||||
4.1.2. Session-Sender Packet Format in Authenticated Mode | 4.1.2. Session-Sender Packet Format in Authenticated Mode | |||
For authenticated mode: | STAMP Session-Sender packet format in authenticated mode: | |||
0 1 2 3 | 0 1 2 3 | |||
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 | 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 | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Sequence Number | | | Sequence Number | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | | | | | |||
| MBZ (12 octets) | | | MBZ (12 octets) | | |||
| | | | | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Timestamp | | | Timestamp | | |||
| | | | | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Error Estimate | | | | Error Estimate | | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | |||
~ ~ | ~ ~ | |||
| MBZ (70 octets) | | | MBZ (70 octets) | | |||
~ ~ | ~ ~ | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Type | Length | | ||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
~ Value ~ | ||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
~ Comp.MBZ ~ | ||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| | | | | | |||
| HMAC (16 octets) | | | HMAC (16 octets) | | |||
| | | | | | |||
| | | | | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
Figure 4: STAMP Session-Sender test packet format in authenticated | Figure 4: STAMP Session-Sender test packet format in authenticated | |||
mode | mode | |||
The field definitions are the same as the unauthenticated mode, | The field definitions are the same as the unauthenticated mode, | |||
listed in Section 4.1.1. Also, Comp.MBZ field is variable length | listed in Section 4.1.1. Also, Comp.MBZ field is a variable length | |||
field to align the packet on 16 octets boundary. Also, the packet | field to align the packet on 16 octets boundary. Also, the packet | |||
includes a key-hashed message authentication code (HMAC) ([RFC2104]) | includes a key-hashed message authentication code (HMAC) ([RFC2104]) | |||
hash at the end of the PDU. | hash at the end of the PDU. The detailed use of the HMAC field is | |||
described in Section 4.3. | ||||
4.2. Session-Reflector Behavior and Packet Format | 4.2. Session-Reflector Behavior and Packet Format | |||
The Session-Reflector receives the STAMP test packet, verifies it, | The Session-Reflector receives the STAMP test packet, verifies it, | |||
prepares and transmits the reflected test packet. | prepares and transmits the reflected test packet. | |||
Two modes of STAMP Session-Reflector characterize the expected | Two modes of STAMP Session-Reflector characterize the expected | |||
behavior and, consequently, performance metrics that can be measured: | behavior and, consequently, performance metrics that can be measured: | |||
o Stateless - STAMP Session-Reflector does not maintain test state | o Stateless - STAMP Session-Reflector does not maintain test state | |||
skipping to change at page 9, line 30 ¶ | skipping to change at page 8, line 44 ¶ | |||
| Session-Sender Timestamp | | | Session-Sender Timestamp | | |||
| | | | | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Session-Sender Error Estimate | MBZ | | | Session-Sender Error Estimate | MBZ | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
|Ses-Sender TTL | | | |Ses-Sender TTL | | | |||
+-+-+-+-+-+-+-+-+ + | +-+-+-+-+-+-+-+-+ + | |||
| | | | | | |||
~ Packet Padding (reflected) ~ | ~ Packet Padding (reflected) ~ | |||
+ +-+-+-+-+-+-+-+-+ | + +-+-+-+-+-+-+-+-+ | |||
| | Comp.MBZ | | | | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Type | Length | | ||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
~ Value ~ | ||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
Figure 5: STAMP Session-Reflector test packet format in | Figure 5: STAMP Session-Reflector test packet format in | |||
unauthenticated mode | unauthenticated mode | |||
where fields are defined as the following: | where fields are defined as the following: | |||
o Sequence Number is four octets long field. The value of the | o Sequence Number is four octets long field. The value of the | |||
Sequence Number field is set according to the mode of the STAMP | Sequence Number field is set according to the mode of the STAMP | |||
Session-Reflector: | Session-Reflector: | |||
skipping to change at page 10, line 17 ¶ | skipping to change at page 9, line 28 ¶ | |||
Z flag of the Error Estimate field as described in Section 4.1. | Z flag of the Error Estimate field as described in Section 4.1. | |||
o Error Estimate has the same size and interpretation as described | o Error Estimate has the same size and interpretation as described | |||
in Section 4.1. | in Section 4.1. | |||
o Session-Sender Sequence Number, Session-Sender Timestamp, and | o Session-Sender Sequence Number, Session-Sender Timestamp, and | |||
Session-Sender Error Estimate are copies of the corresponding | Session-Sender Error Estimate are copies of the corresponding | |||
fields in the STAMP test packet sent by the Session-Sender. | fields in the STAMP test packet sent by the Session-Sender. | |||
o Session-Sender TTL is one octet long field, and its value is the | o Session-Sender TTL is one octet long field, and its value is the | |||
copy of the TTL field from the received STAMP test packet. | copy of the TTL field in IPv4 (or Hop Limit in IPv6) from the | |||
received STAMP test packet. | ||||
o Packet Padding (reflected) is an optional variable length field. | o Packet Padding (reflected) is an optional variable length field. | |||
The length of the Packet Padding (reflected) field MUST be equal | The length of the Packet Padding (reflected) field MUST be equal | |||
to the value of the Server Octets field (Figure 2). If the value | to the value of the Server Octets field (Figure 2). If the value | |||
is non-zero, the Session-Reflector MUST copy number of octets | is non-zero, the Session-Reflector MUST copy number of octets | |||
equal to the value of Server Octets field starting with the Server | equal to the value of Server Octets field starting with the Server | |||
Octets field. | Octets field. | |||
o Comp.MBZ is variable length field used to achieve alignment on a | o Comp.MBZ is a variable length field used to achieve alignment on a | |||
word boundary. Thus the length of Comp.MBZ field may be only 0, | word boundary. Thus the length of Comp.MBZ field may be only 0, | |||
1, 2 or 3 octets. The value of the field MUST be zeroed on | 1, 2 or 3 octets. The value of the field MUST be zeroed on | |||
transmission and ignored on receipt. | transmission and ignored on receipt. | |||
4.2.2. Session-Reflector Packet Format in Authenticated Mode | 4.2.2. Session-Reflector Packet Format in Authenticated Mode | |||
For the authenticated mode: | For the authenticated mode: | |||
0 1 2 3 | 0 1 2 3 | |||
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 | 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 | |||
skipping to change at page 11, line 27 ¶ | skipping to change at page 10, line 39 ¶ | |||
| Session-Sender Error Estimate | | | | Session-Sender Error Estimate | | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | |||
| MBZ (6 octets) | | | MBZ (6 octets) | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
|Ses-Sender TTL | | | |Ses-Sender TTL | | | |||
+-+-+-+-+-+-+-+-+ + | +-+-+-+-+-+-+-+-+ + | |||
| | | | | | |||
| MBZ (15 octets) | | | MBZ (15 octets) | | |||
| | | | | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Type | Length | | ||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
~ Value ~ | ||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
~ Comp.MBZ ~ | ||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| HMAC (16 octets) | | | HMAC (16 octets) | | |||
| | | | | | |||
| | | | | | |||
| | | | | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
Figure 6: STAMP Session-Reflector test packet format in authenticated | Figure 6: STAMP Session-Reflector test packet format in authenticated | |||
mode | mode | |||
The field definitions are the same as the unauthenticated mode, | The field definitions are the same as the unauthenticated mode, | |||
listed in Section 4.2.1. Additionally, the packet MAY include | listed in Section 4.2.1. Additionally, the packet MAY include | |||
Comp.MBZ field is variable length field to align the packet on 16 | Comp.MBZ field is a variable length field to align the packet on 16 | |||
octets boundary. Also, STAMP Session-Reflector test packet format in | octets boundary. Also, STAMP Session-Reflector test packet format in | |||
authenticated mode includes a key (HMAC) ([RFC2104]) hash at the end | authenticated mode includes a key (HMAC) ([RFC2104]) hash at the end | |||
of the PDU. | of the PDU. The detailed use of the HMAC field is in Section 4.3. | |||
4.3. Integrity and Confidentiality Protection in STAMP | 4.3. Integrity and Confidentiality Protection in STAMP | |||
To provide integrity protection, each STAMP message is being | To provide integrity protection, each STAMP message is being | |||
authenticated by adding Hashed Message Authentication Code (HMAC). | authenticated by adding Hashed Message Authentication Code (HMAC). | |||
STAMP uses HMAC-SHA-256 truncated to 128 bits (similarly to the use | STAMP uses HMAC-SHA-256 truncated to 128 bits (similarly to the use | |||
of it in IPSec defined in [RFC4868]); hence the length of the HMAC | of it in IPSec defined in [RFC4868]); hence the length of the HMAC | |||
field is 16 octets. HMAC uses own key and the definition of the | field is 16 octets. HMAC uses own key and the definition of the | |||
mechanism to distribute the HMAC key is outside the scope of this | mechanism to distribute the HMAC key is outside the scope of this | |||
specification. One example is to use an orchestrator to configure | specification. One example is to use an orchestrator to configure | |||
HMAC key based on STAMP YANG data model [I-D.ietf-ippm-stamp-yang]. | HMAC key based on STAMP YANG data model [I-D.ietf-ippm-stamp-yang]. | |||
HMAC MUST be verified as early as possible to avoid using or | HMAC MUST be verified as early as possible to avoid using or | |||
propagating corrupted data. | propagating corrupted data. | |||
If confidentiality protection for STAMP is required, encryption at | If confidentiality protection for STAMP is required, encryption at | |||
the higher level MUST be used. | the higher level MUST be used. For example, STAMP packets could be | |||
transmitted in the dedicated IPsec tunnel or share the IPsec tunnel | ||||
with the monitored flow. | ||||
4.4. Interoperability with TWAMP Light | 4.4. Interoperability with TWAMP Light | |||
One of the essential requirements to STAMP is the ability to | One of the essential requirements to STAMP is the ability to | |||
interwork with TWAMP Light device. There are two possible | interwork with a TWAMP Light device. There are two possible | |||
combinations for such use case: | combinations for such use case: | |||
o STAMP Session-Sender with TWAMP Light Session-Reflector; | o STAMP Session-Sender with TWAMP Light Session-Reflector; | |||
o TWAMP Light Session-Sender with STAMP Session-Reflector. | o TWAMP Light Session-Sender with STAMP Session-Reflector. | |||
In the former case, Session-Sender MAY not be aware that its Session- | In the former case, the Session-Sender MAY not be aware that its | |||
Reflector does not support STAMP. For example, TWAMP Light Session- | Session-Reflector does not support STAMP. For example, a TWAMP Light | |||
Reflector may not support the use of UDP port 862 as defined in | Session-Reflector may not support the use of UDP port 862 as defined | |||
[I-D.ietf-ippm-port-twamp-test]. Thus STAMP Session-Sender MUST be | in [RFC8545]. Thus STAMP Session-Sender MUST be able to send test | |||
able to send test packets to destination UDP port number from the | packets to destination UDP port number from the Dynamic and/or | |||
Dynamic and/or Private Ports range 49152-65535, test management | Private Ports range 49152-65535, test management system should find a | |||
system should find port number that both devices can use. And if any | port number that both devices can use. And if any of STAMP | |||
of TLV-based STAMP extensions are used, the TWAMP Light Session- | extensions are used, the TWAMP Light Session-Reflector will view them | |||
Reflector will view them as Packet Padding field. The Session-Sender | as Packet Padding field. The Session-Sender SHOULD use the default | |||
SHOULD use the default format for its timestamps - NTP. And it MAY | format for its timestamps - NTP. And it MAY use PTPv2 timestamp | |||
use PTPv2 timestamp format. | format. | |||
In the latter scenario, the test management system should set STAMP | In the latter scenario, the test management system should set STAMP | |||
Session-Reflector to use UDP port number from the Dynamic and/or | Session-Reflector to use UDP port number from the Dynamic and/or | |||
Private Ports range. As for Packet Padding field that the TWAMP | Private Ports range. As for Packet Padding field that the TWAMP | |||
Light Session-Sender includes in its transmitted packet, the STAMP | Light Session-Sender includes in its transmitted packet, the STAMP | |||
Session-Reflector will process it according to [RFC6038] and return | Session-Reflector will process it according to [RFC6038] and return | |||
reflected packet of the symmetrical size. The Session-Reflector MUST | reflected packet of the symmetrical size. The Session-Reflector MUST | |||
use the default format for its timestamps - NTP. | use the default format for its timestamps - NTP. | |||
5. IANA Considerations | 5. IANA Considerations | |||
This document doesn't have any IANA action. This section may be | This document doesn't have any IANA action. This section may be | |||
removed before the publication. | removed before the publication. | |||
6. Security Considerations | 6. Security Considerations | |||
In general, all the security considerations related to TWAMP-Test, | ||||
discussed in [RFC5357] apply to STAMP. Since STAMP uses the well- | ||||
known UDP port number allocated for the OWAMP-Test/TWAMP-Test | ||||
Receiver port, the security considerations and measures to mitigate | ||||
the risk of the attack using the registered port number documented in | ||||
Section 6 [RFC8545] equally apply to STAMP. Because of the control | ||||
and management of a STAMP test being outside the scope of this | ||||
specification only the more general requirement is set: | ||||
To mitigate the possible attack vector, the control and management | ||||
of a STAMP test session MUST use the secured transport. | ||||
Use of HMAC-SHA-256 in the authenticated mode protects the data | Use of HMAC-SHA-256 in the authenticated mode protects the data | |||
integrity of the STAMP test packets. | integrity of the STAMP test packets. | |||
7. Acknowledgments | 7. Acknowledgments | |||
Authors express their appreciation to Jose Ignacio Alvarez-Hamelin | Authors express their appreciation to Jose Ignacio Alvarez-Hamelin | |||
and Brian Weis for their great insights into the security and | and Brian Weis for their great insights into the security and | |||
identity protection, and the most helpful and practical suggestions. | identity protection, and the most helpful and practical suggestions. | |||
Also, our sincere thanks to David Ball for his thorough review and | ||||
helpful comments. | ||||
8. References | 8. References | |||
8.1. Normative References | 8.1. Normative References | |||
[BBF.TR-390] | ||||
"Performance Measurement from IP Edge to Customer | ||||
Equipment using TWAMP Light", BBF TR-390, May 2017. | ||||
[I-D.ietf-ippm-port-twamp-test] | ||||
Morton, A. and G. Mirsky, "OWAMP and TWAMP Well-Known Port | ||||
Assignments", draft-ietf-ippm-port-twamp-test-03 (work in | ||||
progress), November 2018. | ||||
[IEEE.1588.2008] | [IEEE.1588.2008] | |||
"Standard for a Precision Clock Synchronization Protocol | "Standard for a Precision Clock Synchronization Protocol | |||
for Networked Measurement and Control Systems", | for Networked Measurement and Control Systems", | |||
IEEE Standard 1588, March 2008. | IEEE Standard 1588, March 2008. | |||
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | |||
Requirement Levels", BCP 14, RFC 2119, | Requirement Levels", BCP 14, RFC 2119, | |||
DOI 10.17487/RFC2119, March 1997, | DOI 10.17487/RFC2119, March 1997, | |||
<https://www.rfc-editor.org/info/rfc2119>. | <https://www.rfc-editor.org/info/rfc2119>. | |||
skipping to change at page 14, line 24 ¶ | skipping to change at page 13, line 34 ¶ | |||
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC | [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC | |||
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, | 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, | |||
May 2017, <https://www.rfc-editor.org/info/rfc8174>. | May 2017, <https://www.rfc-editor.org/info/rfc8174>. | |||
[RFC8186] Mirsky, G. and I. Meilik, "Support of the IEEE 1588 | [RFC8186] Mirsky, G. and I. Meilik, "Support of the IEEE 1588 | |||
Timestamp Format in a Two-Way Active Measurement Protocol | Timestamp Format in a Two-Way Active Measurement Protocol | |||
(TWAMP)", RFC 8186, DOI 10.17487/RFC8186, June 2017, | (TWAMP)", RFC 8186, DOI 10.17487/RFC8186, June 2017, | |||
<https://www.rfc-editor.org/info/rfc8186>. | <https://www.rfc-editor.org/info/rfc8186>. | |||
[RFC8545] Morton, A., Ed. and G. Mirsky, Ed., "Well-Known Port | ||||
Assignments for the One-Way Active Measurement Protocol | ||||
(OWAMP) and the Two-Way Active Measurement Protocol | ||||
(TWAMP)", RFC 8545, DOI 10.17487/RFC8545, March 2019, | ||||
<https://www.rfc-editor.org/info/rfc8545>. | ||||
8.2. Informative References | 8.2. Informative References | |||
[BBF.TR-390] | ||||
"Performance Measurement from IP Edge to Customer | ||||
Equipment using TWAMP Light", BBF TR-390, May 2017. | ||||
[I-D.ietf-ippm-stamp-yang] | [I-D.ietf-ippm-stamp-yang] | |||
Mirsky, G., Xiao, M., and W. Luo, "Simple Two-way Active | Mirsky, G., Xiao, M., and W. Luo, "Simple Two-way Active | |||
Measurement Protocol (STAMP) Data Model", draft-ietf-ippm- | Measurement Protocol (STAMP) Data Model", draft-ietf-ippm- | |||
stamp-yang-02 (work in progress), September 2018. | stamp-yang-03 (work in progress), March 2019. | |||
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- | [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- | |||
Hashing for Message Authentication", RFC 2104, | Hashing for Message Authentication", RFC 2104, | |||
DOI 10.17487/RFC2104, February 1997, | DOI 10.17487/RFC2104, February 1997, | |||
<https://www.rfc-editor.org/info/rfc2104>. | <https://www.rfc-editor.org/info/rfc2104>. | |||
[RFC4868] Kelly, S. and S. Frankel, "Using HMAC-SHA-256, HMAC-SHA- | [RFC4868] Kelly, S. and S. Frankel, "Using HMAC-SHA-256, HMAC-SHA- | |||
384, and HMAC-SHA-512 with IPsec", RFC 4868, | 384, and HMAC-SHA-512 with IPsec", RFC 4868, | |||
DOI 10.17487/RFC4868, May 2007, | DOI 10.17487/RFC4868, May 2007, | |||
<https://www.rfc-editor.org/info/rfc4868>. | <https://www.rfc-editor.org/info/rfc4868>. | |||
End of changes. 38 change blocks. | ||||
98 lines changed or deleted | 100 lines changed or added | |||
This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |