idnits 2.17.1 draft-mymb-sfc-nsh-allocation-timestamp-02.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 (August 20, 2017) is 2442 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-28) exists of draft-ietf-sfc-nsh-19 == Outdated reference: A later version (-07) exists of draft-browne-sfc-nsh-kpi-stamp-01 == Outdated reference: A later version (-14) exists of draft-ietf-ippm-alt-mark-06 == Outdated reference: A later version (-01) exists of draft-mizrahi-intarea-packet-timestamps-00 Summary: 0 errors (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group T. Mizrahi 3 Internet-Draft I. Yerushalmi 4 Intended status: Informational D. Melman 5 Expires: February 21, 2018 Marvell 6 R. Browne 7 Intel 8 August 20, 2017 10 Network Service Header (NSH) Context Header Allocation: Timestamp 11 draft-mymb-sfc-nsh-allocation-timestamp-02 13 Abstract 15 This memo defines an allocation for the Context Headers of the 16 Network Service Header (NSH), which incorporates the packet's 17 timestamp, a sequence number, and a source interface identifier. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on February 21, 2018. 36 Copyright Notice 38 Copyright (c) 2017 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 56 2.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 3 57 3. NSH Context Header Allocation Allocation . . . . . . . . . . 3 58 4. Timestamping Use Cases . . . . . . . . . . . . . . . . . . . 5 59 4.1. Network Analytics . . . . . . . . . . . . . . . . . . . . 5 60 4.2. Alternate Marking . . . . . . . . . . . . . . . . . . . . 6 61 4.3. Consistent Updates . . . . . . . . . . . . . . . . . . . 6 62 5. Synchronization Considerations . . . . . . . . . . . . . . . 6 63 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 64 7. Security Considerations . . . . . . . . . . . . . . . . . . . 6 65 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 66 8.1. Normative References . . . . . . . . . . . . . . . . . . 7 67 8.2. Informative References . . . . . . . . . . . . . . . . . 7 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 70 1. Introduction 72 The Network Service Header (NSH), defined in [I-D.ietf-sfc-nsh], is 73 an encapsulation header that is used in Service Function Chains 74 (SFC). 76 The NSH specification [I-D.ietf-sfc-nsh] supports two possible 77 methods of including metadata in the NSH; MD Type 0x1 and MD Type 78 0x2. When using MD Type 0x1 the NSH includes 16 octets of Context 79 Header fields. The current memo proposes an allocation for the MD 80 Type 0x1 Context Headers, which incorporates the timestamp of the 81 packet, a 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 [I-D.ietf-sfc-nsh] 122 MD Metadata [I-D.ietf-sfc-nsh] 124 SF Service Function [RFC7665] 126 SFC Service Function Chaining [RFC7665] 128 3. NSH Context Header Allocation 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 160 [I-D.mizrahi-intarea-packet-timestamps]. One of the formats is 161 based on the [IEEE1588] timestamp format, and the other is based 162 on the [RFC5905] format. It is assumed that in a given 163 administrative domain only one of the formats will be used, and 164 that the control plane determines which timestamp 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: the format of this field 170 uses the 64 least significant bits of the IEEE 1588-2008 Precision 171 Time Protocol format [IEEE1588]. This truncated format consists 172 of a 32-bit seconds field followed by a 32-bit nanoseconds field. 173 As defined in [IEEE1588], the timestamp specifies the number of 174 seconds elapsed since 1 January 1970 00:00:00 according to the 175 International Atomic Time (TAI). 177 0 1 2 3 178 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 179 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 180 | Seconds | 181 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 182 | Nanoseconds | 183 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 185 Figure 2: IEEE 1588 Truncated Timestamp Format [IEEE1588]. 187 o NTP 64-bit Timestamp Format: this format consists of a 32-bit 188 seconds field followed by a 32-bit fractional second field. As 189 defined in [RFC5905], the timestamp specifies the number of 190 seconds elapsed since 1 January 1900 00:00:00 according to the 191 Coordinated Universal Time (UTC). 193 0 1 2 3 194 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 195 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 196 | Seconds | 197 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 198 | Fraction | 199 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 201 Figure 3: NTP [RFC5905] 64-bit Timestamp Format 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 212 [I-D.brockners-inband-oam-data], can be triggered, allowing to 213 analyze and localize the problem. 215 Timestamping is also useful for logging and for flow analytics. It 216 is often useful to maintain the timestamp of the first and last 217 packet of the flow. Furthermore, traffic mirroring and sampling 218 often requires a timestamp to be attached to analyzed packets. 219 Attaching the timestamp to the NSH Context Header provides an in-band 220 common time reference that can be used for various network analytics 221 applications. 223 4.2. Alternate Marking 225 A possible approach for passive performance monitoring is to use an 226 alternate marking method [I-D.ietf-ippm-alt-mark]. This method 227 requires data packets to carry a field that marks (colors) the 228 traffic, and enables passive measurement of packet loss, delay, and 229 delay variation. The value of this marking field is periodically 230 toggled between two values. 232 When the timestamp is incorporated in the NSH Context Header, it can 233 natively be used for alternate marking. For example, the least 234 significant bit of the timestamp Seconds field can be used for this 235 purpose, since the value of this bit is inherently toggled every 236 second. 238 4.3. Consistent Updates 240 The timestamp can be used for taking policy decisions such as 241 'Perform action A if timestamp>=T_0'. This can be used for enforcing 242 time-of-day policies or periodic policies in service functions. 243 Furthermore, timestamp-based policies can be used for enforcing 244 consistent network updates, as discussed in [DPT]. 246 5. Synchronization Considerations 248 Some of the applications that make use of the timestamp require the 249 Classifer and SFs to be synchronized to a common time reference, for 250 example using the Network Time Protocol [RFC5905], or the Precision 251 Time Protocol [IEEE1588]. 253 6. IANA Considerations 255 This memo includes no request to IANA. 257 7. Security Considerations 259 The security considerations of NSH in general are discussed in 260 [I-D.ietf-sfc-nsh]. The security considerations of in-band 261 timestamping in the context of NSH is discussed in 262 [I-D.browne-sfc-nsh-kpi-stamp], and the current section is based on 263 that discussion. 265 The use of in-band timestamping, as defined in this document, can be 266 used as a means for network reconnaissance. By passively 267 eavesdropping to timestamped traffic, an attacker can gather 268 information about network delays and performance bottlenecks. A man- 269 in-the-middle attacker can maliciously modify timestamps in order to 270 attack applications that use the timestamp values, such as 271 performance monitoring applications. 273 Since the timestamping mechanism relies on an underlying time 274 synchronization protocol, by attacking the time protocol an attack 275 can potentially compromise the integrity of the NSH timestamp. A 276 detailed discussion about the threats against time protocols and how 277 to mitigate them is presented in [RFC7384]. 279 8. References 281 8.1. Normative References 283 [I-D.ietf-sfc-nsh] 284 Quinn, P., Elzur, U., and C. Pignataro, "Network Service 285 Header (NSH)", draft-ietf-sfc-nsh-19 (work in progress), 286 August 2017. 288 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 289 Requirement Levels", BCP 14, RFC 2119, 290 DOI 10.17487/RFC2119, March 1997, . 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.brockners-inband-oam-data] 300 Brockners, F., Bhandari, S., Pignataro, C., Gredler, H., 301 Leddy, J., Youell, S., Mizrahi, T., Mozes, D., Lapukhov, 302 P., Chang, R., and d. daniel.bernier@bell.ca, "Data Fields 303 for In-situ OAM", draft-brockners-inband-oam-data-07 (work 304 in progress), July 2017. 306 [I-D.browne-sfc-nsh-kpi-stamp] 307 Browne, R., Chilikin, A., and T. Mizrahi, "Network Service 308 Header KPI Stamping", draft-browne-sfc-nsh-kpi-stamp-01 309 (work in progress), April 2017. 311 [I-D.ietf-ippm-alt-mark] 312 Fioccola, G., Capello, A., Cociglio, M., Castaldelli, L., 313 Chen, M., Zheng, L., Mirsky, G., and T. Mizrahi, 314 "Alternate Marking method for passive and hybrid 315 performance monitoring", draft-ietf-ippm-alt-mark-06 (work 316 in progress), July 2017. 318 [I-D.mizrahi-intarea-packet-timestamps] 319 Mizrahi, T., Fabini, J., and A. Morton, "Guidelines for 320 Defining Packet Timestamps", draft-mizrahi-intarea-packet- 321 timestamps-00 (work in progress), June 2017. 323 [IEEE1588] 324 IEEE, "IEEE 1588 Standard for a Precision Clock 325 Synchronization Protocol for Networked Measurement and 326 Control Systems Version 2", 2008. 328 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, 329 "Network Time Protocol Version 4: Protocol and Algorithms 330 Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, 331 . 333 [RFC7384] Mizrahi, T., "Security Requirements of Time Protocols in 334 Packet Switched Networks", RFC 7384, DOI 10.17487/RFC7384, 335 October 2014, . 337 [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function 338 Chaining (SFC) Architecture", RFC 7665, 339 DOI 10.17487/RFC7665, October 2015, . 342 Authors' Addresses 344 Tal Mizrahi 345 Marvell 346 6 Hamada 347 Yokneam 2066721 348 Israel 350 Email: talmi@marvell.com 352 Ilan Yerushalmi 353 Marvell 354 6 Hamada 355 Yokneam 2066721 356 Israel 358 Email: yilan@marvell.com 359 David Melman 360 Marvell 361 6 Hamada 362 Yokneam 2066721 363 Israel 365 Email: davidme@marvell.com 367 Rory Browne 368 Intel 369 Dromore House 370 Shannon, Co.Clare 371 Ireland 373 Email: rory.browne@intel.com