idnits 2.17.1 draft-mymb-sfc-nsh-allocation-timestamp-06.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 (April 14, 2019) is 1810 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-05 == Outdated reference: A later version (-09) exists of draft-ietf-ntp-packet-timestamps-06 -- Obsolete informational reference (is this intentional?): RFC 8321 (Obsoleted by RFC 9341) Summary: 0 errors (**), 0 flaws (~~), 4 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 Network.IO Innovation Lab 4 Intended status: Informational I. Yerushalmi 5 Expires: October 16, 2019 D. Melman 6 Marvell 7 R. Browne 8 Intel 9 April 14, 2019 11 Network Service Header (NSH) Context Header Allocation: Timestamp 12 draft-mymb-sfc-nsh-allocation-timestamp-06 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 October 16, 2019. 37 Copyright Notice 39 Copyright (c) 2019 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 [I-D.browne-sfc-nsh-kpi-stamp] defines an NSH 99 timestamping mechanism that uses the MD Type 0x2 format. The current 100 memo defines a compact MD Type 0x1 Context Header that does not 101 require the packet to be extended beyond the NSH header. 102 Furthermore, the two timestamping mechanisms can be used in concert, 103 as further discussed below. 105 2. Terminology 107 2.1. Requirements Language 109 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 110 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 111 document are to be interpreted as described in RFC 2119 [RFC2119]. 113 2.2. Abbreviations 115 The following abbreviations are used in this document: 117 KPI Key Performance Indicators 118 [I-D.browne-sfc-nsh-kpi-stamp] 120 NSH Network Service Header [RFC8300] 122 MD Metadata [RFC8300] 124 SF Service Function [RFC7665] 126 SFC Service Function Chaining [RFC7665] 128 3. NSH Context Header Allocation 130 This memo defines the following Context Header allocation, as 131 presented in Figure 1. 133 0 1 2 3 134 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 135 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 136 | Sequence Number | 137 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 138 | Source Interface | 139 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 140 | Timestamp | 141 | | 142 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 144 Figure 1: NSH Timestamp Allocation. 146 The NSH Timestamp Allocation includes the following fields: 148 o Sequence Number - a 32-bit sequence number. The sequence number 149 is maintained on a per-source-interface basis. The sequence 150 numbers can be used by SFs to detect out-of-order delivery, or 151 duplicate transmissions. 153 o Source Interface - a 32-bit source interface identifier that is 154 assigned by the Classifier. 156 o Timestamp - this field is 8 octets long, and specifies the time at 157 which the packet was received by the Classifier. Two possible 158 timestamp formats can be used for this field: the two 64-bit 159 recommended formats specified in [I-D.ietf-ntp-packet-timestamps]. 160 One of the formats is based on the [IEEE1588] timestamp format, 161 and the other is based on the [RFC5905] format. It is assumed 162 that in a given administrative domain only one of the formats will 163 be used, and that the control plane determines which timestamp 164 format is used. 166 The two timestamp formats that can be used in the timestamp field 167 are: 169 o IEEE 1588 Truncated Timestamp Format: as specified in Section 4.3 170 of [I-D.ietf-ntp-packet-timestamps]. This timestamp format uses 171 the 64 least significant bits of the IEEE 1588-2008 Precision Time 172 Protocol format [IEEE1588], and consists of a 32-bit seconds field 173 followed by a 32-bit nanoseconds field. 175 0 1 2 3 176 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 177 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 178 | Seconds | 179 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 180 | Nanoseconds | 181 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 183 Figure 2: IEEE 1588 Truncated Timestamp Format [IEEE1588]. 185 o NTP [RFC5905] 64-bit Timestamp Format: as specified in 186 Section 4.2.1 of [I-D.ietf-ntp-packet-timestamps]. This format 187 consists of a 32-bit seconds field followed by a 32-bit fractional 188 second field. 190 0 1 2 3 191 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 192 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 193 | Seconds | 194 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 195 | Fraction | 196 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 198 Figure 3: NTP [RFC5905] 64-bit Timestamp Format 200 Synchronization aspects of the timestamp format are discussed in 201 Section 5. 203 4. Timestamping Use Cases 205 4.1. Network Analytics 207 Per-packet timestamping enables coarse-grained monitoring of the 208 network delay along the Service Function Chain. Once a potential 209 problem or bottleneck is detected, for example when the delay exceeds 210 a certain policy, a highly-granular hop-by-hop monitoring mechanism, 211 such as [I-D.browne-sfc-nsh-kpi-stamp] or [I-D.ietf-ippm-ioam-data], 212 can be triggered, allowing to analyze and localize the problem. 214 Timestamping is also useful for logging and for flow analytics. It 215 is often useful to maintain the timestamp of the first and last 216 packet of the flow. Furthermore, traffic mirroring and sampling 217 often requires a timestamp to be attached to analyzed packets. 218 Attaching the timestamp to the NSH Context Header provides an in-band 219 common time reference that can be used for various network analytics 220 applications. 222 4.2. Alternate Marking 224 A possible approach for passive performance monitoring is to use an 225 alternate marking method [RFC8321]. This method requires data 226 packets to carry a field that marks (colors) the traffic, and enables 227 passive measurement of packet loss, delay, and delay variation. The 228 value of this marking field is periodically toggled between two 229 values. 231 When the timestamp is incorporated in the NSH Context Header, it can 232 natively be used for alternate marking. For example, the least 233 significant bit of the timestamp Seconds field can be used for this 234 purpose, since the value of this bit is inherently toggled every 235 second. 237 4.3. Consistent Updates 239 The timestamp can be used for taking policy decisions such as 240 'Perform action A if timestamp>=T_0'. This can be used for enforcing 241 time-of-day policies or periodic policies in service functions. 242 Furthermore, timestamp-based policies can be used for enforcing 243 consistent network updates, as discussed in [DPT]. 245 5. Synchronization Considerations 247 Some of the applications that make use of the timestamp require the 248 Classifer and SFs to be synchronized to a common time reference, for 249 example using the Network Time Protocol [RFC5905], or the Precision 250 Time Protocol [IEEE1588]. Although it is not a requirement to use a 251 clock synchronization mechanism, it is expected that depending on the 252 applications that use the timestamp, such synchronization mechanisms 253 will be used in most deployments that use the timestamp allocation. 255 6. IANA Considerations 257 This memo includes no request to IANA. 259 7. Security Considerations 261 The security considerations of NSH in general are discussed in 262 [RFC8300]. The security considerations of in-band timestamping in 263 the context of NSH is discussed in [I-D.browne-sfc-nsh-kpi-stamp], 264 and the current section is based on that discussion. 266 The use of in-band timestamping, as defined in this document, can be 267 used as a means for network reconnaissance. By passively 268 eavesdropping to timestamped traffic, an attacker can gather 269 information about network delays and performance bottlenecks. A man- 270 in-the-middle attacker can maliciously modify timestamps in order to 271 attack applications that use the timestamp values, such as 272 performance monitoring applications. 274 Since the timestamping mechanism relies on an underlying time 275 synchronization protocol, by attacking the time protocol an attack 276 can potentially compromise the integrity of the NSH timestamp. A 277 detailed discussion about the threats against time protocols and how 278 to mitigate them is presented in [RFC7384]. 280 8. References 281 8.1. Normative References 283 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 284 Requirement Levels", BCP 14, RFC 2119, 285 DOI 10.17487/RFC2119, March 1997, 286 . 288 [RFC8300] Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed., 289 "Network Service Header (NSH)", RFC 8300, 290 DOI 10.17487/RFC8300, January 2018, 291 . 293 8.2. Informative References 295 [DPT] Mizrahi, T., Moses, Y., "The Case for Data Plane 296 Timestamping in SDN", IEEE INFOCOM Workshop on Software- 297 Driven Flexible and Agile Networking (SWFAN), 2016. 299 [I-D.browne-sfc-nsh-kpi-stamp] 300 Browne, R., Chilikin, A., and T. Mizrahi, "A Key 301 Performance Indicators (KPI) Stamping for the Network 302 Service Header (NSH)", draft-browne-sfc-nsh-kpi-stamp-07 303 (work in progress), February 2019. 305 [I-D.ietf-ippm-ioam-data] 306 Brockners, F., Bhandari, S., Pignataro, C., Gredler, H., 307 Leddy, J., Youell, S., Mizrahi, T., Mozes, D., Lapukhov, 308 P., Chang, R., daniel.bernier@bell.ca, d., and J. Lemon, 309 "Data Fields for In-situ OAM", draft-ietf-ippm-ioam- 310 data-05 (work in progress), March 2019. 312 [I-D.ietf-ntp-packet-timestamps] 313 Mizrahi, T., Fabini, J., and A. Morton, "Guidelines for 314 Defining Packet Timestamps", draft-ietf-ntp-packet- 315 timestamps-06 (work in progress), February 2019. 317 [IEEE1588] 318 IEEE, "IEEE 1588 Standard for a Precision Clock 319 Synchronization Protocol for Networked Measurement and 320 Control Systems Version 2", 2008. 322 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, 323 "Network Time Protocol Version 4: Protocol and Algorithms 324 Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, 325 . 327 [RFC7384] Mizrahi, T., "Security Requirements of Time Protocols in 328 Packet Switched Networks", RFC 7384, DOI 10.17487/RFC7384, 329 October 2014, . 331 [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function 332 Chaining (SFC) Architecture", RFC 7665, 333 DOI 10.17487/RFC7665, October 2015, 334 . 336 [RFC8321] Fioccola, G., Ed., Capello, A., Cociglio, M., Castaldelli, 337 L., Chen, M., Zheng, L., Mirsky, G., and T. Mizrahi, 338 "Alternate-Marking Method for Passive and Hybrid 339 Performance Monitoring", RFC 8321, DOI 10.17487/RFC8321, 340 January 2018, . 342 Authors' Addresses 344 Tal Mizrahi 345 Huawei Network.IO Innovation Lab 346 Israel 348 Email: tal.mizrahi.phd@gmail.com 350 Ilan Yerushalmi 351 Marvell 352 6 Hamada 353 Yokneam 2066721 354 Israel 356 Email: yilan@marvell.com 358 David Melman 359 Marvell 360 6 Hamada 361 Yokneam 2066721 362 Israel 364 Email: davidme@marvell.com 365 Rory Browne 366 Intel 367 Dromore House 368 Shannon, Co.Clare 369 Ireland 371 Email: rory.browne@intel.com