idnits 2.17.1 draft-mymb-sfc-nsh-allocation-timestamp-09.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 (June 17, 2021) is 1041 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-17) exists of draft-ietf-ippm-ioam-data-12 -- Obsolete informational reference (is this intentional?): RFC 8321 (Obsoleted by RFC 9341) Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group T. Mizrahi 3 Internet-Draft Huawei 4 Intended status: Informational I. Yerushalmi 5 Expires: December 19, 2021 D. Melman 6 Marvell 7 R. Browne 8 Intel 9 June 17, 2021 11 Network Service Header (NSH) Context Header Allocation: Timestamp 12 draft-mymb-sfc-nsh-allocation-timestamp-09 14 Abstract 16 The Network Service Header (NSH) specification defines two possible 17 methods of including metadata (MD): MD Type 0x1 and MD Type 0x2. MD 18 Type 0x1 uses a fixed-length Context Header. The allocation of this 19 Context Header, i.e., its structure and semantics, has not been 20 standardized. This memo presents an allocation for the fixed Context 21 Headers of NSH, which incorporates the packet's timestamp, a sequence 22 number, and a source interface identifier. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at https://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on December 19, 2021. 41 Copyright Notice 43 Copyright (c) 2021 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (https://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 61 2.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 4 62 3. NSH Timestamp Context Header Allocation . . . . . . . . . . . 4 63 4. Timestamping Use Cases . . . . . . . . . . . . . . . . . . . 6 64 4.1. Network Analytics . . . . . . . . . . . . . . . . . . . . 6 65 4.2. Alternate Marking . . . . . . . . . . . . . . . . . . . . 6 66 4.3. Consistent Updates . . . . . . . . . . . . . . . . . . . 7 67 5. Synchronization Considerations . . . . . . . . . . . . . . . 7 68 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 69 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 70 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 71 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 72 9.1. Normative References . . . . . . . . . . . . . . . . . . 8 73 9.2. Informative References . . . . . . . . . . . . . . . . . 8 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 76 1. Introduction 78 The Network Service Header (NSH), defined in [RFC8300], is an 79 encapsulation header that is used as the service encapsulation in the 80 Service Function Chains (SFC) architecture [RFC7665]. 82 In order to share metadata along a service path, the NSH 83 specification [RFC8300] supports two methods: a fixed-length Context 84 Header (MD Type 0x1) and a variable-length Context Header (MD Type 85 0x2). When using MD Type 0x1 the NSH includes 16 octets of Context 86 Header fields. 88 The NSH specification [RFC8300] has not defined the semantics of the 89 16-octet Context Header, nor how it is used by NSH-aware service 90 functions, SFFs and proxies. Some allocation schemes were proposed 91 in the past to acoommodate specific use cases, e.g., 92 [I-D.ietf-sfc-nsh-dc-allocation] and 93 [I-D.ietf-sfc-nsh-broadband-allocation]. 95 This memo defines an allocation for the MD Type 0x1 Context Header, 96 which incorporates the timestamp of the packet, a sequence number, 97 and a source interface identifier. It is noted that other MD Type 98 0x1 allocations might be specified in the future. Although MD Type 99 0x1 allocations are currently not being standardized by the SFC 100 working group, a consistent format (allocation) should be used in an 101 SFC-enabled domain in order to allow interoperability. 103 In a nutshell, packets that enter the SFC-enabled domain are 104 timestamped by a Classifier [RFC7665]. Thus, the timestamp, sequence 105 number and source interface are incorporated in the NSH Context 106 Header. As defined in [RFC8300], if reclassification is used, it may 107 result in an update to the NSH metadata. Specifically, when the 108 Timestamp Context Header is used, a reclassifier may either leave it 109 unchanged, or update the three fields: timestamp, sequence number and 110 source interface. 112 The Timestamp Context Header includes three fields that may be used 113 for various purposes. The timestamp field may be used for logging, 114 troubleshooting, delay measurement, packet marking for performance 115 monitoring, and timestamp-based policies. The source interface 116 identifier indicates the interface through which the packet was 117 received at the classifier. This identifier may specify a physical 118 or a virtual interface. The sequence numbers can be used by Service 119 Functions (SFs) to detect out-of-order delivery or duplicate 120 transmissions. Note that duplicate packet detection is possible when 121 multiple copies are received by the same SF, but is not necessarily 122 possible when there are multiple instances of the same SF and 123 duplicate copies of a packet are spread across different instances of 124 the SF. The sequence number is maintained on a per-source-interface 125 basis. 127 This document presents the Timestamp Context Header, but does not 128 specify the functionality of the SFs that receive the Context Header. 129 Although a few possible use cases are described in the document, the 130 SF behavior and application are outside the scope of this document. 132 KPI-stamping [RFC8592] defines an NSH timestamping mechanism that 133 uses the MD Type 0x2 format. The current memo defines a compact MD 134 Type 0x1 Context Header that does not require the packet to be 135 extended beyond the NSH header. Furthermore, the two timestamping 136 mechanisms can be used in concert, as further discussed in 137 Section 4.1. 139 2. Terminology 140 2.1. Requirements Language 142 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 143 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 144 "OPTIONAL" in this document are to be interpreted as described in BCP 145 14 [RFC2119] [RFC8174] when, and only when, they appear in all 146 capitals, as shown here. 148 2.2. Abbreviations 150 The following abbreviations are used in this document: 152 KPI Key Performance Indicators [RFC8592] 154 NSH Network Service Header [RFC8300] 156 MD Metadata [RFC8300] 158 SF Service Function [RFC7665] 160 SFC Service Function Chaining [RFC7665] 162 3. NSH Timestamp Context Header Allocation 164 This memo defines the following fixed-length Context Header 165 allocation, as presented in Figure 1. 167 0 1 2 3 168 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 169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 170 | Sequence Number | 171 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 172 | Source Interface | 173 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 174 | Timestamp | 175 | | 176 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 178 Figure 1: NSH Timestamp Allocation. 180 The NSH Timestamp Allocation that is defined in this memo MUST 181 include the following fields: 183 o Sequence Number - a 32-bit sequence number. The sequence number 184 is maintained on a per-source-interface basis. Sequence numbers 185 can be used by SFs to detect out-of-order delivery, or duplicate 186 transmissions. The Classifier increments the sequence number by 1 187 for each packet received through the source interface. This 188 requires the classifier to maintain a per-source-interface 189 counter. The sequence number is initialized to a random number on 190 startup. After it reaches its maximal value (2^32-1) the sequence 191 number wraps around back to zero. 193 o Source Interface - a 32-bit source interface identifier that is 194 assigned by the Classifier. The source interface is unique in the 195 context of the given classifier. 197 o Timestamp - this field is 8 octets long, and specifies the time at 198 which the packet was received by the Classifier. Two possible 199 timestamp formats can be used for this field: the two 64-bit 200 recommended formats specified in [RFC8877]. One of the formats is 201 based on the [IEEE1588] timestamp format, and the other is based 202 on the [RFC5905] format. 204 The NSH specification [RFC8300] does not specify the possible 205 coexistence of multiple MD Type 0x1 Context Header formats in a 206 single SFC-enabled domain. It is assumed that the Timestamp Context 207 Header will be deployed in an SFC-enabled domain that uniquely uses 208 this Context Header format. Thus, operators SHOULD ensure that 209 either a consistent Context Header format is used in the SFC-enabled 210 domain, or that there is a clear policy that allows SFs to know the 211 Context Header format of each packet. Specifically, operators are 212 expected to ensure the consistent use of a timestamp format across 213 the whole SFC-enabled domain. 215 The two timestamp formats that can be used in the timestamp field 216 are: 218 o IEEE 1588 Truncated Timestamp Format: this format is specified in 219 Section 4.3 of [RFC8877]. For the reader's convenience this 220 format is illustrated in Figure 2. 222 0 1 2 3 223 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 224 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 225 | Seconds | 226 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 227 | Nanoseconds | 228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 230 Figure 2: IEEE 1588 Truncated Timestamp Format [IEEE1588]. 232 o NTP [RFC5905] 64-bit Timestamp Format: this format is specified in 233 Section 4.4 of [RFC8877]. For the reader's convenience this 234 format is illustrated in Figure 3. 236 0 1 2 3 237 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 238 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 239 | Seconds | 240 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 241 | Fraction | 242 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 244 Figure 3: NTP [RFC5905] 64-bit Timestamp Format 246 Synchronization aspects of the timestamp format in the context of the 247 NSH timestamp allocation are discussed in Section 5. 249 4. Timestamping Use Cases 251 4.1. Network Analytics 253 Per-packet timestamping enables coarse-grained monitoring of the 254 network delay along the Service Function Chain. Once a potential 255 problem or bottleneck is detected, for example when the delay exceeds 256 a certain policy, a highly-granular hop-by-hop monitoring mechanism, 257 such as [RFC8592] or [I-D.ietf-ippm-ioam-data], can be triggered, 258 allowing to analyze and localize the problem. 260 Timestamping is also useful for logging, troubleshooting and for flow 261 analytics. It is often useful to maintain the timestamp of the first 262 and last packet of the flow. Furthermore, traffic mirroring and 263 sampling often requires a timestamp to be attached to analyzed 264 packets. Attaching the timestamp to the NSH provides an in-band 265 common time reference that can be used for various network analytics 266 applications. 268 4.2. Alternate Marking 270 A possible approach for passive performance monitoring is to use an 271 alternate marking method [RFC8321]. This method requires data 272 packets to carry a field that marks (colors) the traffic, and enables 273 passive measurement of packet loss, delay, and delay variation. The 274 value of this marking field is periodically toggled between two 275 values. 277 When the timestamp is incorporated in the NSH, it can natively be 278 used for alternate marking. For example, the least significant bit 279 of the timestamp Seconds field can be used for this purpose, since 280 the value of this bit is inherently toggled every second. 282 4.3. Consistent Updates 284 The timestamp can be used for taking policy decisions such as 285 'Perform action A if timestamp>=T_0'. This can be used for enforcing 286 time-of-day policies or periodic policies in service functions. 287 Furthermore, timestamp-based policies can be used for enforcing 288 consistent network updates, as discussed in [DPT]. It should be 289 noted that, as in the case of Alternate Marking, this use case alone 290 does not require a full 64-bit timestamp, but could be implemented 291 with a significantly smaller number of bits. 293 5. Synchronization Considerations 295 Some of the applications that make use of the timestamp require the 296 Classifier and SFs to be synchronized to a common time reference, for 297 example using the Network Time Protocol [RFC5905] or the Precision 298 Time Protocol [IEEE1588]. Although it is not a requirement to use a 299 clock synchronization mechanism, it is expected that depending on the 300 applications that use the timestamp, such synchronization mechanisms 301 will be used in most deployments that use the timestamp allocation. 303 6. IANA Considerations 305 This memo includes no request to IANA. 307 7. Security Considerations 309 The security considerations of NSH in general are discussed in 310 [RFC8300]. NSH is typically run within a confined trust domain. 311 However, if a trust domain is not enough to provide the operator with 312 the protection against the timestamp threats described below, then 313 the operator SHOULD use transport-level protection between SFC 314 processing nodes as described in [RFC8300]. 316 The security considerations of in-band timestamping in the context of 317 NSH is discussed in [RFC8592], and the current section is based on 318 that discussion. 320 The use of in-band timestamping, as defined in this document, can be 321 used as a means for network reconnaissance. By passively 322 eavesdropping to timestamped traffic, an attacker can gather 323 information about network delays and performance bottlenecks. A man- 324 in-the-middle attacker can maliciously modify timestamps in order to 325 attack applications that use the timestamp values, such as 326 performance monitoring applications. 328 Since the timestamping mechanism relies on an underlying time 329 synchronization protocol, by attacking the time protocol an attack 330 can potentially compromise the integrity of the NSH timestamp. A 331 detailed discussion about the threats against time protocols and how 332 to mitigate them is presented in [RFC7384]. 334 8. Acknowledgments 336 The authors thank Mohamed Boucadair and Greg Mirsky for their 337 thorough reviews and detailed comments. 339 9. References 341 9.1. Normative References 343 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 344 Requirement Levels", BCP 14, RFC 2119, 345 DOI 10.17487/RFC2119, March 1997, 346 . 348 [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function 349 Chaining (SFC) Architecture", RFC 7665, 350 DOI 10.17487/RFC7665, October 2015, 351 . 353 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 354 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 355 May 2017, . 357 [RFC8300] Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed., 358 "Network Service Header (NSH)", RFC 8300, 359 DOI 10.17487/RFC8300, January 2018, 360 . 362 [RFC8877] Mizrahi, T., Fabini, J., and A. Morton, "Guidelines for 363 Defining Packet Timestamps", RFC 8877, 364 DOI 10.17487/RFC8877, September 2020, 365 . 367 9.2. Informative References 369 [DPT] Mizrahi, T., Moses, Y., "The Case for Data Plane 370 Timestamping in SDN", IEEE INFOCOM Workshop on Software- 371 Driven Flexible and Agile Networking (SWFAN), 2016. 373 [I-D.ietf-ippm-ioam-data] 374 Brockners, F., Bhandari, S., and T. Mizrahi, "Data Fields 375 for In-situ OAM", draft-ietf-ippm-ioam-data-12 (work in 376 progress), February 2021. 378 [I-D.ietf-sfc-nsh-broadband-allocation] 379 Napper, J., Kumar, S., Muley, P., Hendericks, W., and M. 380 Boucadair, "NSH Context Header Allocation for Broadband", 381 draft-ietf-sfc-nsh-broadband-allocation-01 (work in 382 progress), June 2018. 384 [I-D.ietf-sfc-nsh-dc-allocation] 385 Guichard, J., Smith, M., Kumar, S., Majee, S., and T. 386 Mizrahi, "Network Service Header (NSH) MD Type 1: Context 387 Header Allocation (Data Center)", draft-ietf-sfc-nsh-dc- 388 allocation-02 (work in progress), September 2018. 390 [IEEE1588] 391 IEEE, "IEEE 1588 Standard for a Precision Clock 392 Synchronization Protocol for Networked Measurement and 393 Control Systems Version 2", 2008. 395 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, 396 "Network Time Protocol Version 4: Protocol and Algorithms 397 Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, 398 . 400 [RFC7384] Mizrahi, T., "Security Requirements of Time Protocols in 401 Packet Switched Networks", RFC 7384, DOI 10.17487/RFC7384, 402 October 2014, . 404 [RFC8321] Fioccola, G., Ed., Capello, A., Cociglio, M., Castaldelli, 405 L., Chen, M., Zheng, L., Mirsky, G., and T. Mizrahi, 406 "Alternate-Marking Method for Passive and Hybrid 407 Performance Monitoring", RFC 8321, DOI 10.17487/RFC8321, 408 January 2018, . 410 [RFC8592] Browne, R., Chilikin, A., and T. Mizrahi, "Key Performance 411 Indicator (KPI) Stamping for the Network Service Header 412 (NSH)", RFC 8592, DOI 10.17487/RFC8592, May 2019, 413 . 415 Authors' Addresses 416 Tal Mizrahi 417 Huawei 418 Israel 420 Email: tal.mizrahi.phd@gmail.com 422 Ilan Yerushalmi 423 Marvell 424 6 Hamada 425 Yokneam 2066721 426 Israel 428 Email: yilan@marvell.com 430 David Melman 431 Marvell 432 6 Hamada 433 Yokneam 2066721 434 Israel 436 Email: davidme@marvell.com 438 Rory Browne 439 Intel 440 Dromore House 441 Shannon, Co.Clare 442 Ireland 444 Email: rory.browne@intel.com