idnits 2.17.1 draft-mymb-sfc-nsh-allocation-timestamp-07.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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (October 21, 2020) is 1282 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-10 -- Obsolete informational reference (is this intentional?): RFC 8321 (Obsoleted by RFC 9341) 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 T. Mizrahi 3 Internet-Draft Huawei 4 Intended status: Informational I. Yerushalmi 5 Expires: April 24, 2021 D. Melman 6 Marvell 7 R. Browne 8 Intel 9 October 21, 2020 11 Network Service Header (NSH) Context Header Allocation: Timestamp 12 draft-mymb-sfc-nsh-allocation-timestamp-07 14 Abstract 16 This memo defines an allocation for the Context Headers of the 17 Network Service Header (NSH), which incorporates the packet's 18 timestamp, a sequence number, and a source interface identifier. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at https://datatracker.ietf.org/drafts/current/. 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 This Internet-Draft will expire on April 24, 2021. 37 Copyright Notice 39 Copyright (c) 2020 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (https://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 57 2.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 3 58 3. NSH Context Header Allocation . . . . . . . . . . . . . . . . 3 59 4. Timestamping Use Cases . . . . . . . . . . . . . . . . . . . 5 60 4.1. Network Analytics . . . . . . . . . . . . . . . . . . . . 5 61 4.2. Alternate Marking . . . . . . . . . . . . . . . . . . . . 5 62 4.3. Consistent Updates . . . . . . . . . . . . . . . . . . . 6 63 5. Synchronization Considerations . . . . . . . . . . . . . . . 6 64 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 65 7. Security Considerations . . . . . . . . . . . . . . . . . . . 6 66 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 67 8.1. Normative References . . . . . . . . . . . . . . . . . . 7 68 8.2. Informative References . . . . . . . . . . . . . . . . . 7 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 71 1. Introduction 73 The Network Service Header (NSH), defined in [RFC8300], is an 74 encapsulation header that is used in Service Function Chains (SFC). 76 The NSH specification [RFC8300] supports two possible methods of 77 including metadata in the NSH; MD Type 0x1 and MD Type 0x2. When 78 using MD Type 0x1 the NSH includes 16 octets of Context Header 79 fields. The current memo proposes an allocation for the MD Type 0x1 80 Context Headers, which incorporates the timestamp of the packet, a 81 sequence number, and a source interface identifier. 83 In a nutshell, packets that enter the SFC-Enabled Domain are 84 timestamped. The timestamp is measured by the Classifier [RFC7665], 85 and incorporated in the NSH. The timestamp may be used for various 86 different purposes, including delay measurement, packet marking for 87 passive performance monitoring, and timestamp-based policies. 88 Notably, the timestamp does not increase the packet length, since it 89 is incorporated in the MD Type 0x1 Mandatory Context Headers. 91 The source interface identifier indicates the interface through which 92 the packet was received at the classifier. This identifer may 93 specify a physical or a virtual interface. The sequence numbers can 94 be used by Service Functions (SFs) to detect out-of-order delivery or 95 duplicate transmissions. The sequence number is maintained on a per- 96 source-interface basis. 98 KPI-stamping [RFC8592] defines an NSH timestamping mechanism that 99 uses the MD Type 0x2 format. The current memo defines a compact MD 100 Type 0x1 Context Header that does not require the packet to be 101 extended beyond the NSH header. Furthermore, the two timestamping 102 mechanisms can be used in concert, as further discussed below. 104 2. Terminology 106 2.1. Requirements Language 108 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 109 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 110 document are to be interpreted as described in RFC 2119 [RFC2119]. 112 2.2. Abbreviations 114 The following abbreviations are used in this document: 116 KPI Key Performance Indicators [RFC8592] 118 NSH Network Service Header [RFC8300] 120 MD Metadata [RFC8300] 122 SF Service Function [RFC7665] 124 SFC Service Function Chaining [RFC7665] 126 3. NSH Context Header Allocation 128 This memo defines the following Context Header allocation, as 129 presented in Figure 1. 131 0 1 2 3 132 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 133 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 134 | Sequence Number | 135 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 136 | Source Interface | 137 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 138 | Timestamp | 139 | | 140 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 142 Figure 1: NSH Timestamp Allocation. 144 The NSH Timestamp Allocation includes the following fields: 146 o Sequence Number - a 32-bit sequence number. The sequence number 147 is maintained on a per-source-interface basis. The sequence 148 numbers can be used by SFs to detect out-of-order delivery, or 149 duplicate transmissions. 151 o Source Interface - a 32-bit source interface identifier that is 152 assigned by the Classifier. 154 o Timestamp - this field is 8 octets long, and specifies the time at 155 which the packet was received by the Classifier. Two possible 156 timestamp formats can be used for this field: the two 64-bit 157 recommended formats specified in [RFC8877]. One of the formats is 158 based on the [IEEE1588] timestamp format, and the other is based 159 on the [RFC5905] format. It is assumed that in a given 160 administrative domain only one of the formats will be used, and 161 that the control plane determines which timestamp format is used. 163 The two timestamp formats that can be used in the timestamp field 164 are: 166 o IEEE 1588 Truncated Timestamp Format: as specified in Section 4.3 167 of [RFC8877]. This timestamp format uses the 64 least significant 168 bits of the IEEE 1588-2008 Precision Time Protocol format 169 [IEEE1588], and consists of a 32-bit seconds field followed by a 170 32-bit nanoseconds field. 172 0 1 2 3 173 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 174 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 175 | Seconds | 176 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 177 | Nanoseconds | 178 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 180 Figure 2: IEEE 1588 Truncated Timestamp Format [IEEE1588]. 182 o NTP [RFC5905] 64-bit Timestamp Format: as specified in 183 Section 4.2.1 of [RFC8877]. This format consists of a 32-bit 184 seconds field followed by a 32-bit fractional second field. 186 0 1 2 3 187 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 188 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 189 | Seconds | 190 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 191 | Fraction | 192 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 194 Figure 3: NTP [RFC5905] 64-bit Timestamp Format 196 Synchronization aspects of the timestamp format are discussed in 197 Section 5. 199 4. Timestamping Use Cases 201 4.1. Network Analytics 203 Per-packet timestamping enables coarse-grained monitoring of the 204 network delay along the Service Function Chain. Once a potential 205 problem or bottleneck is detected, for example when the delay exceeds 206 a certain policy, a highly-granular hop-by-hop monitoring mechanism, 207 such as [RFC8592] or [I-D.ietf-ippm-ioam-data], can be triggered, 208 allowing to analyze and localize the problem. 210 Timestamping is also useful for logging and for flow analytics. It 211 is often useful to maintain the timestamp of the first and last 212 packet of the flow. Furthermore, traffic mirroring and sampling 213 often requires a timestamp to be attached to analyzed packets. 214 Attaching the timestamp to the NSH Context Header provides an in-band 215 common time reference that can be used for various network analytics 216 applications. 218 4.2. Alternate Marking 220 A possible approach for passive performance monitoring is to use an 221 alternate marking method [RFC8321]. This method requires data 222 packets to carry a field that marks (colors) the traffic, and enables 223 passive measurement of packet loss, delay, and delay variation. The 224 value of this marking field is periodically toggled between two 225 values. 227 When the timestamp is incorporated in the NSH Context Header, it can 228 natively be used for alternate marking. For example, the least 229 significant bit of the timestamp Seconds field can be used for this 230 purpose, since the value of this bit is inherently toggled every 231 second. 233 4.3. Consistent Updates 235 The timestamp can be used for taking policy decisions such as 236 'Perform action A if timestamp>=T_0'. This can be used for enforcing 237 time-of-day policies or periodic policies in service functions. 238 Furthermore, timestamp-based policies can be used for enforcing 239 consistent network updates, as discussed in [DPT]. 241 5. Synchronization Considerations 243 Some of the applications that make use of the timestamp require the 244 Classifer and SFs to be synchronized to a common time reference, for 245 example using the Network Time Protocol [RFC5905], or the Precision 246 Time Protocol [IEEE1588]. Although it is not a requirement to use a 247 clock synchronization mechanism, it is expected that depending on the 248 applications that use the timestamp, such synchronization mechanisms 249 will be used in most deployments that use the timestamp allocation. 251 6. IANA Considerations 253 This memo includes no request to IANA. 255 7. Security Considerations 257 The security considerations of NSH in general are discussed in 258 [RFC8300]. The security considerations of in-band timestamping in 259 the context of NSH is discussed in [RFC8592], and the current section 260 is based on that discussion. 262 The use of in-band timestamping, as defined in this document, can be 263 used as a means for network reconnaissance. By passively 264 eavesdropping to timestamped traffic, an attacker can gather 265 information about network delays and performance bottlenecks. A man- 266 in-the-middle attacker can maliciously modify timestamps in order to 267 attack applications that use the timestamp values, such as 268 performance monitoring applications. 270 Since the timestamping mechanism relies on an underlying time 271 synchronization protocol, by attacking the time protocol an attack 272 can potentially compromise the integrity of the NSH timestamp. A 273 detailed discussion about the threats against time protocols and how 274 to mitigate them is presented in [RFC7384]. 276 8. References 277 8.1. Normative References 279 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 280 Requirement Levels", BCP 14, RFC 2119, 281 DOI 10.17487/RFC2119, March 1997, 282 . 284 [RFC8300] Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed., 285 "Network Service Header (NSH)", RFC 8300, 286 DOI 10.17487/RFC8300, January 2018, 287 . 289 8.2. Informative References 291 [DPT] Mizrahi, T., Moses, Y., "The Case for Data Plane 292 Timestamping in SDN", IEEE INFOCOM Workshop on Software- 293 Driven Flexible and Agile Networking (SWFAN), 2016. 295 [I-D.ietf-ippm-ioam-data] 296 Brockners, F., Bhandari, S., and T. Mizrahi, "Data Fields 297 for In-situ OAM", draft-ietf-ippm-ioam-data-10 (work in 298 progress), July 2020. 300 [IEEE1588] 301 IEEE, "IEEE 1588 Standard for a Precision Clock 302 Synchronization Protocol for Networked Measurement and 303 Control Systems Version 2", 2008. 305 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, 306 "Network Time Protocol Version 4: Protocol and Algorithms 307 Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, 308 . 310 [RFC7384] Mizrahi, T., "Security Requirements of Time Protocols in 311 Packet Switched Networks", RFC 7384, DOI 10.17487/RFC7384, 312 October 2014, . 314 [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function 315 Chaining (SFC) Architecture", RFC 7665, 316 DOI 10.17487/RFC7665, October 2015, 317 . 319 [RFC8321] Fioccola, G., Ed., Capello, A., Cociglio, M., Castaldelli, 320 L., Chen, M., Zheng, L., Mirsky, G., and T. Mizrahi, 321 "Alternate-Marking Method for Passive and Hybrid 322 Performance Monitoring", RFC 8321, DOI 10.17487/RFC8321, 323 January 2018, . 325 [RFC8592] Browne, R., Chilikin, A., and T. Mizrahi, "Key Performance 326 Indicator (KPI) Stamping for the Network Service Header 327 (NSH)", RFC 8592, DOI 10.17487/RFC8592, May 2019, 328 . 330 [RFC8877] Mizrahi, T., Fabini, J., and A. Morton, "Guidelines for 331 Defining Packet Timestamps", RFC 8877, 332 DOI 10.17487/RFC8877, September 2020, 333 . 335 Authors' Addresses 337 Tal Mizrahi 338 Huawei 339 Israel 341 Email: tal.mizrahi.phd@gmail.com 343 Ilan Yerushalmi 344 Marvell 345 6 Hamada 346 Yokneam 2066721 347 Israel 349 Email: yilan@marvell.com 351 David Melman 352 Marvell 353 6 Hamada 354 Yokneam 2066721 355 Israel 357 Email: davidme@marvell.com 359 Rory Browne 360 Intel 361 Dromore House 362 Shannon, Co.Clare 363 Ireland 365 Email: rory.browne@intel.com