idnits 2.17.00 (12 Aug 2021) /tmp/idnits53962/draft-ietf-sfc-nsh-integrity-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 (September 20, 2021) is 236 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'ThisDocument' is mentioned on line 1183, but not defined -- Possible downref: Non-RFC (?) normative reference: ref. 'GCM' ** Downref: Normative reference to an Informational RFC: RFC 2104 ** Downref: Normative reference to an Informational RFC: RFC 7665 == Outdated reference: A later version (-04) exists of draft-irtf-cfrg-aead-limits-03 Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SFC M. Boucadair 3 Internet-Draft Orange 4 Intended status: Standards Track T. Reddy 5 Expires: March 24, 2022 Akamai 6 D. Wing 7 Citrix 8 September 20, 2021 10 Integrity Protection for the Network Service Header (NSH) and Encryption 11 of Sensitive Context Headers 12 draft-ietf-sfc-nsh-integrity-09 14 Abstract 16 This specification presents an optional method to add integrity 17 protection directly to the Network Service Header (NSH) used for 18 Service Function Chaining (SFC). Also, this specification allows for 19 the encryption of sensitive metadata that is carried in the NSH. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at https://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on March 24, 2022. 38 Copyright Notice 40 Copyright (c) 2021 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (https://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 3. Assumptions and Basic Requirements . . . . . . . . . . . . . 5 58 4. Design Overview . . . . . . . . . . . . . . . . . . . . . . . 7 59 4.1. Supported Security Services . . . . . . . . . . . . . . . 7 60 4.1.1. Encrypt All or a Subset of Context Headers . . . . . 7 61 4.1.2. Integrity Protection . . . . . . . . . . . . . . . . 8 62 4.2. One Secret Key, Two Security Services . . . . . . . . . . 10 63 4.3. Mandatory-to-Implement Authenticated Encryption and HMAC 64 Algorithms . . . . . . . . . . . . . . . . . . . . . . . 11 65 4.4. Key Management . . . . . . . . . . . . . . . . . . . . . 11 66 4.5. New NSH Variable-Length Context Headers . . . . . . . . . 12 67 4.6. Encapsulation of NSH within NSH . . . . . . . . . . . . . 12 68 5. New NSH Variable-Length Context Headers . . . . . . . . . . . 13 69 5.1. MAC#1 Context Header . . . . . . . . . . . . . . . . . . 14 70 5.2. MAC#2 Context Header . . . . . . . . . . . . . . . . . . 16 71 6. Timestamp Format . . . . . . . . . . . . . . . . . . . . . . 18 72 7. Processing Rules . . . . . . . . . . . . . . . . . . . . . . 19 73 7.1. Generic Behavior . . . . . . . . . . . . . . . . . . . . 19 74 7.2. MAC NSH Data Generation . . . . . . . . . . . . . . . . . 20 75 7.3. Encrypted NSH Metadata Generation . . . . . . . . . . . . 21 76 7.4. Timestamp for Replay Attack Prevention . . . . . . . . . 21 77 7.5. NSH Data Validation . . . . . . . . . . . . . . . . . . . 22 78 7.6. Decryption of NSH Metadata . . . . . . . . . . . . . . . 23 79 8. MTU Considerations . . . . . . . . . . . . . . . . . . . . . 23 80 9. Security Considerations . . . . . . . . . . . . . . . . . . . 24 81 9.1. MAC#1 . . . . . . . . . . . . . . . . . . . . . . . . . . 26 82 9.2. MAC#2 . . . . . . . . . . . . . . . . . . . . . . . . . . 26 83 9.3. Time Synchronization . . . . . . . . . . . . . . . . . . 26 84 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 85 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 27 86 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 27 87 12.1. Normative References . . . . . . . . . . . . . . . . . . 27 88 12.2. Informative References . . . . . . . . . . . . . . . . . 28 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30 91 1. Introduction 93 Many advanced Service Functions (SFs) are enabled for the delivery of 94 value-added services. Typically, SFs are used to meet various 95 service objectives such as IP address sharing, avoiding covert 96 channels, detecting Denial-of-Service (DoS) attacks and protecting 97 network infrastructures against them, network slicing, etc. Because 98 of the proliferation of such advanced SFs together with complex 99 service deployment constraints that demand more agile service 100 delivery procedures, operators need to rationalize their service 101 delivery logic and control its complexity while optimising service 102 activation time cycles. The overall problem space is described in 103 [RFC7498]. 105 [RFC7665] presents a data plane architecture addressing the 106 problematic aspects of existing service deployments, including 107 topological dependence and configuration complexity. It also 108 describes an architecture for the specification, creation, and 109 maintenance of Service Function Chains (SFCs) within a network. That 110 is, how to define an ordered set of SFs and ordering constraints that 111 must be applied to packets/flows selected as a result of traffic 112 classification. [RFC8300] specifies the SFC encapsulation: Network 113 Service Header (NSH). 115 The NSH data is unauthenticated and unencrypted, forcing a service 116 topology that requires security and privacy to use a transport 117 encapsulation that supports such features (Section 8.2 of [RFC8300]). 119 Note that some transport encapsulations (e.g., IPsec) only provide 120 hop-by-hop security between two SFC data plane elements (e.g., two 121 Service Function Forwarders (SFFs), SFF to SF) and do not provide SF- 122 to-SF security of NSH metadata. For example, if IPsec is used, SFFs 123 or SFs within a Service Function Path (SFP) that are not authorized 124 to access the sensitive metadata (e.g., privacy-sensitive 125 information) will have access to the metadata. As a reminder, the 126 metadata referred to is information that is inserted by Classifiers 127 or intermediate SFs and shared with downstream SFs; such information 128 is not visible to the communication endpoints (Section 4.9 of 129 [RFC7665]). 131 The lack of such capability was reported during the development of 132 [RFC8300] and [RFC8459]. The reader may refer to Section 3.2.1 of 133 [I-D.arkko-farrell-arch-model-t] for a discussion on the need for 134 more awareness about attacks from within closed domains. 136 This specification fills that gap for SFC (that is, it defines the 137 "NSH Variable Header-Based Integrity" option mentioned in 138 Section 8.2.1 of [RFC8300]). Concretely, this document adds 139 integrity protection and optional encryption of sensitive metadata 140 directly to the NSH (Section 4). The integrity protection covers the 141 packet payload and provides replay protection (Section 7.4). Thus, 142 the NSH does not have to rely upon an underlying transport 143 encapsulation for security. 145 This specification introduces new Variable-Length Context Headers to 146 carry fields necessary for integrity-protected NSH headers and 147 encrypted Context Headers (Section 5). This specification is only 148 applicable to NSH MD Type 0x02 (Section 2.5 of [RFC8300]). MTU 149 considerations are discussed in Section 8. This specification is not 150 applicable to NSH MD Type 0x01 (Section 2.4 of [RFC8300]) because 151 that MD Type only allows a Fixed-Length Context Header whose size is 152 16-bytes; that is not sufficient to accommodate both the metadata and 153 message integrity of the NSH data. 155 This specification limits access to NSH-supplied information along an 156 SFP to entities that have a need to interpret it. 158 The mechanism specified in this document does not preclude the use of 159 transport security. Such considerations are deployment-specific. 161 It is out of the scope of this document to specify an NSH-aware 162 control plane solution. 164 2. Terminology 166 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 167 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 168 "OPTIONAL" in this document are to be interpreted as described in BCP 169 14 [RFC2119] [RFC8174] when, and only when, they appear in all 170 capitals, as shown here. 172 This document makes use of the terms defined in [RFC7665] and 173 [RFC8300]. The term "transport encapsulation" used in this document 174 refers to the outer encapsulation (e.g., Generic Routing 175 Encapsulation (GRE), IPsec, Generic Protocol Extension for VXLAN 176 (VXLAN-GPE)) that is used to carry NSH-encapsulated packets as per 177 Section 4 of [RFC8300]. 179 The document defines the following terms: 181 SFC data plane element: Refers to NSH-aware SF, SFF, SFC Proxy, or 182 Classifier as defined in the SFC data plane architecture [RFC7665] 183 and further refined in [RFC8300]. 185 SFC control element: Is a logical entity that instructs one or more 186 SFC data plane elements on how to process NSH packets within an 187 SFC-enabled domain. 189 Key Identifier: Is used to identify keys to authorized entities. 190 See, for example, 'kid' usage in [RFC7635]. 192 NSH data: The NSH is composed of a Base Header, a Service Path 193 Header, and optional Context Headers. NSH data refers to all the 194 above headers and the packet or frame on which the NSH is imposed 195 to realize an SFP. 197 NSH imposer: Refers to an SFC data plane element that is entitled to 198 impose the NSH with the Context Headers defined in this document. 200 3. Assumptions and Basic Requirements 202 Section 2 of [RFC8300] specifies that the NSH data can be spread over 203 three headers: 205 o Base Header: Provides information about the service header and the 206 payload protocol. 208 o Service Path Header: Provides path identification and location 209 within an SFP. 211 o Context Header(s): Carries metadata (i.e., context data) along a 212 service path. 214 The NSH allows sharing context information (a.k.a., metadata) with 215 downstream NSH-aware data plane elements on a per SFC/SFP basis. To 216 that aim: 218 The Classifier is instructed by an SFC control element about the 219 set of context information to be supplied for a given service 220 function chain. 222 An NSH-aware SF is instructed by an SFC control element about any 223 metadata it needs to attach to packets for a given service 224 function chain. This instruction may occur any time during the 225 validity lifetime of an SFC/SFP. For a given service function 226 chain, the NSH-aware SF is also provided with an order for 227 consuming a set of contexts supplied in a packet. 229 An NSH-aware SF can also be instructed by an SFC control element 230 about the behavior it should adopt after consuming context 231 information that was supplied in the NSH. For example, the 232 context information can be maintained, updated, or stripped. 234 An SFC Proxy may be instructed by an SFC control element about the 235 behavior it should adopt to process the context information that 236 was supplied in the NSH on behalf of an NSH-unaware SF (e.g., the 237 context information can be maintained or stripped). The SFC Proxy 238 may also be instructed to add some new context information into 239 the NSH on behalf of an NSH-unaware SF. 241 In reference to Table 1, 243 o Classifiers, NSH-aware SFs, and SFC proxies are entitled to update 244 the Context Header(s). 246 o Only NSH-aware SFs and SFC proxies are entitled to update the 247 Service Path Header. 249 o SFFs are entitled to modify the Base Header (TTL value, for 250 example). Nevertheless, SFFs are not supposed to act on the 251 Context Headers or look into the content of the Context Headers 252 (Section 4.3 of [RFC7665]). 254 Thus, the following requirements: 256 o Only Classifiers, NSH-aware SFs, and SFC proxies must be able to 257 encrypt and decrypt a given Context Header. 259 o Both encrypted and unencrypted Context Headers may be included in 260 the same NSH. 262 o The solution must provide integrity protection for the Service 263 Path Header. 265 o The solution must provide optional integrity protection for the 266 Base Header. The implications of disabling such checks are 267 discussed in Section 9.1. 269 +----------------+-----------------------------+-------------------+ 270 | | Insert, remove, or replace | Update the NSH | 271 | | the NSH | | 272 | | | | 273 | SFC Data Plane +---------+---------+---------+---------+---------+ 274 | Element | | | |Decrement| Update | 275 | | Insert | Remove | Replace | Service | Context | 276 | | | | | Index |Header(s)| 277 +================+=========+=========+=========+=========+=========+ 278 | | + | | + | | + | 279 | Classifier | | | | | | 280 +----------------+---------+---------+---------+---------+---------+ 281 |Service Function| | + | | | | 282 |Forwarder (SFF) | | | | | | 283 +----------------+---------+---------+---------+---------+---------+ 284 |Service Function| | | | + | + | 285 | (SF) | | | | | | 286 +----------------+---------+---------+---------+---------+---------+ 287 | | + | + | | + | + | 288 | SFC Proxy | | | | | | 289 +----------------+---------+---------+---------+---------+---------+ 291 Table 1: Summary of NSH Actions 293 4. Design Overview 295 4.1. Supported Security Services 297 This specification provides the functions described in the following 298 subsections. 300 4.1.1. Encrypt All or a Subset of Context Headers 302 The solution allows encrypting all or a subset of NSH Context Headers 303 by Classifiers, NSH-aware SFs, and SFC proxies. 305 As depicted in Table 2, SFFs are not involved in data encryption. 307 +-----------------+------------------------------+------------------+ 308 | Data Plane | Base and Service Path | Context Header | 309 | Element | Headers Encryption | Encryption | 310 +-----------------+------------------------------+------------------+ 311 | Classifier | No | Yes | 312 | SFF | No | No | 313 | NSH-aware SF | No | Yes | 314 | SFC Proxy | No | Yes | 315 | NSH-unaware SF | No | No | 316 +-----------------+------------------------------+------------------+ 318 Table 2: Encryption Function Supported by SFC Data Plane Elements 320 Classifier(s), NSH-aware SFs, and SFC proxies are instructed with the 321 set of Context Headers (privacy-sensitive metadata, typically) that 322 must be encrypted. Encryption keying material is only provided to 323 these SFC data plane elements. 325 The control plane may indicate the set of SFC data plane elements 326 that are entitled to supply a given Context Header (e.g., in 327 reference to their identifiers as assigned within the SFC-enabled 328 domain). It is out of the scope of this document to elaborate on how 329 such instructions are provided to the appropriate SFC data plane 330 elements, nor to detail the structure used to store the instructions. 332 The Service Path Header (Section 2 of [RFC8300]) is not encrypted 333 because SFFs use Service Index (SI) in conjunction with Service Path 334 Identifier (SPI) for determining the next SF in the path. 336 4.1.2. Integrity Protection 338 The solution provides integrity protection for the NSH data. Two 339 levels of assurance (LoAs) are supported. 341 The first level of assurance is where all NSH data except the Base 342 Header are integrity protected (Figure 1). In this case, the NSH 343 imposer may be a Classifier, an NSH-aware SF, or an SFC Proxy. SFFs 344 are not provided with authentication material. Further details are 345 discussed in Section 5.1. 347 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 348 | Transport Encapsulation | 349 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+... 350 | Base Header | | 351 +->+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ N 352 | | Service Path Header | S 353 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ H 354 | | Context Header(s) | | 355 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+... 356 | | Original Packet | 357 +->+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 358 | 359 +------Scope of integrity protected data 361 Figure 1: First Level of Assurance 363 The second level of assurance is where all NSH data, including the 364 Base Header, are integrity protected (Figure 2). In this case, the 365 NSH imposer may be a Classifier, an NSH-aware SF, an SFF, or an SFC 366 Proxy. Further details are provided in Section 5.2. 368 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 369 | Transport Encapsulation | 370 +->+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+... 371 | | Base Header | | 372 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ N 373 | | Service Path Header | S 374 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ H 375 | | Context Header(s) | | 376 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+... 377 | | Original Packet | 378 +->+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 379 | 380 +----Scope of integrity protected data 382 Figure 2: Second Level of Assurance 384 The integrity protection scope is explicitly signaled to NSH-aware 385 SFs, SFFs, and SFC proxies in the NSH by means of a dedicated MD Type 386 (Section 5). 388 In both levels of assurance, the Context Headers and the packet on 389 which the NSH is imposed are subject to integrity protection. 391 Table 3 classifies the data plane elements as being involved in 392 providing integrity protection for the NSH or not. 394 +--------------------+----------------------------------+ 395 | Data Plane Element | Integrity Protection | 396 +--------------------+----------------------------------+ 397 | Classifier | Yes | 398 | SFF | No (first LoA); Yes (second LoA) | 399 | NSH-aware SF | Yes | 400 | SFC Proxy | Yes | 401 | NSH-unaware SF | No | 402 +--------------------+----------------------------------+ 404 Table 3: Integrity Protection Supported by SFC Data Plane Elements 406 4.2. One Secret Key, Two Security Services 408 The Authenticated Encryption with Associated Data (AEAD) interface 409 defined in Section 5 of [RFC5116] is used to encrypt the Context 410 Headers that carry sensitive metadata and to provide integrity 411 protection for the encrypted Context Headers. 413 The secondary keys MAC_KEY and ENC_KEY are generated from the input 414 secret key (K) as follows; each of these two keys is an octet string: 416 MAC_KEY: consists of the initial MAC_KEY_LEN octets of K, in order. 417 The MAC_KEY is used for calculating the message integrity of the 418 NSH data. In other words, the integrity protection provided by 419 the cryptographic mechanism is extended to also provide protection 420 for the unencrypted Context Headers and the packet on which the 421 NSH is imposed. 423 ENC_KEY: consists of the final ENC_KEY_LEN octets of K, in order. 424 The ENC_KEY is used as the symmetric encryption key for encrypting 425 the Context Headers. 427 The Hashed Message Authentication Mode (HMAC) algorithm discussed in 428 [RFC4868] is used to protect the integrity of the NSH data. The 429 algorithm for implementing and validating HMACs is provided in 430 [RFC2104]. 432 The advantage of using both AEAD and HMAC algorithms (instead of just 433 AEAD) is that NSH-aware SFs and SFC proxies only need to re-compute 434 the message integrity of the NSH data after decrementing the Service 435 Index (SI) and do not have to re-compute the ciphertext. The other 436 advantage is that SFFs do not have access to the ENC_KEY and cannot 437 act on the encrypted Context Headers and (in the case of the second 438 level of assurance) SFFs do have access to the MAC_KEY. Similarly, 439 an NSH-aware SF or SFC Proxy not allowed to decrypt the Context 440 Headers will not have access to the ENC_KEY. 442 The authenticated encryption algorithm or HMAC algorithm to be used 443 by SFC data plane elements is typically controlled using the SFC 444 control plane. Mandatory to implement authenticated encryption and 445 HMAC algorithms are listed in Section 4.3. 447 The authenticated encryption process takes four inputs, each of which 448 is an octet string: a secret key (ENC_KEY, referred to as K in 449 [RFC5116]), a plaintext (P), associated data (A) (which contains the 450 data to be authenticated, but not encrypted), and a nonce (N). A 451 ciphertext (C) is generated as an output as discussed in Section 2.1 452 of [RFC5116]. 454 In order to decrypt and verify, the cipher takes as input ENC_KEY, N, 455 A, and C. The output is either the plaintext or an error indicating 456 that the decryption failed as described in Section 2.2 of [RFC5116]. 458 4.3. Mandatory-to-Implement Authenticated Encryption and HMAC 459 Algorithms 461 Classifiers, NSH-aware SFs, and SFC proxies MUST implement the 462 AES_128_GCM [GCM][RFC5116] algorithm and SHOULD implement the 463 AES_192_GCM and AES_256_GCM algorithms. 465 Classifiers, NSH-aware SFs, and SFC proxies MUST implement the HMAC- 466 SHA-256-128 algorithm and SHOULD implement the HMAC-SHA-384-192 and 467 HMAC-SHA-512-256 algorithms. 469 SFFs MAY implement the aforementioned cipher suites and HMAC 470 algorithms. 472 Note: The use of AES_128_CBC_HMAC_SHA_256 algorithm would have 473 avoided the need for a second 128-bit authentication tag, but due 474 to the nature of how Cipher Block Chaining (CBC) mode operates, 475 AES_128_CBC_HMAC_SHA_256 allows for malleability of plaintexts. 476 This malleability allows for attackers that know the MAC key but 477 not the encryption key to make changes in the ciphertext and, if 478 parts of the plaintext are known, create arbitrary blocks of 479 plaintext. This specification mandates the use of separate AEAD 480 and MAC protections to prevent this type of attack. 482 4.4. Key Management 484 The procedure for the allocation/provisioning of secret keys (K) and 485 authenticated encryption algorithm or MAC_KEY and HMAC algorithm is 486 outside the scope of this specification. As such, this specification 487 does not mandate the support of any specific mechanism. 489 The document does not assume nor preclude the following: 491 o The same keying material is used for all the service functions 492 used within an SFC-enabled domain. 494 o Distinct keying material is used per SFP by all involved SFC data 495 path elements. 497 o Per-tenant keys are used. 499 In order to accommodate deployments relying upon keying material per 500 SFC/SFP and also the need to update keys after encrypting NSH data 501 for a certain amount of time, this document uses key identifiers to 502 unambiguously identify the appropriate keying material and associated 503 algorithms for MAC and encryption. This use of in-band identifiers 504 addresses the problem of synchronization of keying material. 506 Additional information on manual vs. automated key management and 507 when one should be used over the other can be found in [RFC4107]. 509 The risk involved in using a group-shared symmetric key increases 510 with the size of the group to which it is shared. Additional 511 security issues are discussed in Section 9. 513 4.5. New NSH Variable-Length Context Headers 515 New NSH Variable-Length Context Headers are defined in Section 5 for 516 NSH data integrity protection and, optionally, encryption of Context 517 Headers carrying sensitive metadata. Concretely, an NSH imposer 518 includes (1) the key identifier to identify the keying material, (2) 519 the timestamp to protect against replay attacks (Section 7.4), and 520 (3) the Message Authentication Code (MAC) for the target NSH data 521 (depending on the integrity protection scope) calculated using the 522 MAC_KEY and optionally Context Headers encrypted using ENC_KEY. 524 An SFC data plane element that needs to check the integrity of the 525 NSH data uses MAC_KEY and the HMAC algorithm for the key identifier 526 being carried in the NSH. 528 An NSH-aware SF or SFC Proxy that needs to decrypt some Context 529 Headers uses ENC_KEY and the decryption algorithm for the key 530 identifier being carried in the NSH. 532 Section 7 specifies the detailed procedure. 534 4.6. Encapsulation of NSH within NSH 536 As discussed in Section 3 of [RFC8459], an SFC-enabled domain 537 (called, upper-level domain) may be decomposed into many sub-domains 538 (called, lower-level domains). In order to avoid maintaining state 539 to restore back upper-level NSH information at the boundaries of 540 lower-level domains, two NSH levels are used: an Upper-NSH which is 541 imposed at the boundaries of the upper-level domain and a Lower-NSH 542 that is pushed by the Classifier of a lower-level domain in front of 543 the original NSH (Figure 3). As such, the Upper-NSH information is 544 carried along the lower-level chain without modification. The packet 545 is forwarded in the top-level domain according to the Upper-NSH, 546 while it is forwarded according to the Lower-NSH in a lower-level 547 domain. 549 +---------------------------------+ 550 | Transport Encapsulation | 551 +->+---------------------------------+ 552 | | Lower-NSH Header | 553 | +---------------------------------+ 554 | | Upper-NSH Header | 555 | +---------------------------------+ 556 | | Original Packet | 557 +->+---------------------------------+ 558 | 559 | 560 +----Scope of NSH security protection 561 provided by a lower-level domain 563 Figure 3: Encapsulation of NSH within NSH 565 SFC data plane elements of a lower-level domain include the Upper-NSH 566 when computing the MAC. 568 Keying material used at the upper-level domain SHOULD NOT be the same 569 as the one used by a lower-level domain. 571 5. New NSH Variable-Length Context Headers 573 This section specifies the format of new Variable-Length Context 574 headers that are used for NSH integrity protection and, optionally, 575 Context Headers encryption. 577 In particular, this section defines two "MAC and Encrypted Metadata" 578 Context Headers; each having specific deployment constraints. Unlike 579 Section 5.1, the level of assurance provided in Section 5.2 requires 580 sharing MAC_KEY with SFFs. Both Context headers have the same format 581 as shown in Figure 4. 583 0 1 2 3 584 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 585 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 586 | Metadata Class | Type |U| Length | 587 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 588 | Key Id Len | Key Identifier (Variable) ~ 589 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 590 ~ Timestamp (8 bytes) ~ 591 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 592 | Nonce Length | Nonce (Variable) ~ 593 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 594 | Message Authentication Code and optional Encrypted | 595 ~ Context Headers (Variable) ~ 596 | | 597 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 599 Figure 4: MAC and Encrypted Metadata Context Header 601 The "MAC and Encrypted Metadata" Context Headers are padded out to a 602 multiple of 4 bytes as per Section 2.2 of [RFC8300]. The "MAC and 603 Encrypted Metadata" Context Header, if included, MUST always be the 604 last Context Header. 606 5.1. MAC#1 Context Header 608 MAC#1 Context Header is a variable-length Context Header that carries 609 the Message Authentication Code (MAC) for the Service Path Header, 610 Context Headers, and the inner packet on which NSH is imposed, 611 calculated using MAC_KEY, and optionally Context Headers encrypted 612 using ENC_KEY. The scope of the integrity protection provided by 613 this Context Header is depicted in Figure 5. 615 This MAC scheme does not require sharing MAC_KEY with SFFs. It does 616 not require to re-compute the MAC by each SFF because of TTL 617 processing. Section 9.1 discusses the possible threat associated 618 with this level of assurance. 620 0 1 2 3 621 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 622 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 623 |Ver|O|U| TTL | Length |U|U|U|U|MD Type| Next Protocol | 624 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<--+ 625 | Service Path Identifier | Service Index | | 626 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 627 ~ Variable-Length Unencrypted Context Headers (opt.) ~ | 628 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 629 | Metadata Class | Type |U| Length | | 630 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 631 | Key Id Len | Key Identifier (Variable) ~ | 632 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 633 ~ Timestamp (8 bytes) ~ | 634 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 635 | Nonce Length | Nonce (Variable) ~ | 636 +->+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 637 | ~ Encrypted Context Headers (opt.) ~ | 638 +->+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 639 | ~ Message Authentication Code ~ | 640 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 641 | | | | 642 | ~ Inner Packet on which NSH is imposed ~ | 643 | | | | 644 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<--| 645 | | 646 | Integrity Protection Scope ----+ 647 +----Encrypted Data 649 Figure 5: Scope of MAC#1 651 In reference to Figure 4, the description of the fields is as 652 follows: 654 Metadata Class: MUST be set to 0x0 (Section 2.5.1 of [RFC8300]). 656 Type: TBD1 (See Section 10) 658 U: Unassigned bit (Section 2.5.1 of [RFC8300]). 660 Length: Indicates the length of the variable-length metadata, in 661 bytes. Padding considerations are discussed in Section 2.5.1 of 662 [RFC8300]. 664 Key Id Len: Variable. Carries the length of the key identifier, in 665 octets. 667 Key Identifier: Carries a variable-length Key Identifier object used 668 to identify and deliver keys to SFC data plane elements. This 669 identifier is helpful to accommodate deployments relying upon 670 keying material per SFC/SFP. The key identifier helps in 671 resolving the problem of synchronization of keying material. A 672 single key identifier is used to lookup both the ENC_KEY and the 673 MAC_KEY associated with a key, and the corresponding encryption 674 and MAC algorithms used with those keys. 676 Timestamp: Refer to Section 6 for more details about the structure 677 of this field. 679 Nonce Length: Carries the length of the Nonce. If the Context 680 Headers are only integrity protected, "Nonce Length" is set to 681 zero (that is, no "Nonce" is included). 683 Nonce: Carries the Nonce for the authenticated encryption operation 684 (Section 3.1 of [RFC5116]). 686 Encrypted Context Headers: Carries the optional encrypted Context 687 Headers. 689 Message Authentication Code: Covers the entire NSH data, excluding 690 the Base header. 692 5.2. MAC#2 Context Header 694 MAC#2 Context Header is a variable-length Context Header that carries 695 the MAC for the entire NSH data calculated using MAC_KEY and 696 optionally Context Headers encrypted using ENC_KEY. The scope of the 697 integrity protection provided by this Context Header is depicted in 698 Figure 6. 700 0 1 2 3 701 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 702 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<--+ 703 |Ver|O|U| TTL | Length |U|U|U|U|MD Type| Next Protocol | | 704 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 705 | Service Path Identifier | Service Index | | 706 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 707 ~ Variable-Length Unencrypted Context Headers (opt.) ~ | 708 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 709 | Metadata Class | Type |U| Length | | 710 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 711 | Key Id Len | Key Identifier (Variable) ~ | 712 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 713 ~ Timestamp (8 bytes) ~ | 714 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 715 | Nonce Length | Nonce (Variable) ~ | 716 +->+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 717 | ~ Encrypted Context Headers (opt.) ~ | 718 +->+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 719 | ~ Message Authentication Code ~ | 720 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 721 | | | | 722 | ~ Inner Packet on which NSH is imposed ~ | 723 | | | | 724 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<--| 725 | | 726 | Integrity Protection Scope ----+ 727 +----Encrypted Data 729 Figure 6: Scope of MAC#2 731 In reference to Figure 4, the description of the fields is as 732 follows: 734 Metadata Class: MUST be set to 0x0 (Section 2.5.1 of [RFC8300]). 736 Type: TBD2 (See Section 10) 738 U: Unassigned bit (Section 2.5.1 of [RFC8300]). 740 Length: Indicates the length of the variable-length metadata, in 741 bytes. Padding considerations are discussed in Section 2.5.1 of 742 [RFC8300]. 744 Key Id Len: See Section 5.1. 746 Key Identifier: See Section 5.1. 748 Timestamp: See Section 6. 750 Nonce Length: See Section 5.1. 752 Nonce: See Section 5.1. 754 Encrypted Context Headers: Carries the optional encrypted Context 755 Headers. 757 Message Authentication Code: Covers the entire NSH data. 759 6. Timestamp Format 761 This section follows the template provided in Section 3 of [RFC8877]. 763 The format of the Timestamp field introduced in Section 5 is depicted 764 in Figure 7. 766 0 1 2 3 767 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 768 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 769 | Seconds | 770 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 771 | Fraction | 772 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 774 Figure 7: Timestamp Field Format 776 Timestamp field format: 778 Seconds: specifies the integer portion of the number of seconds 779 since the epoch. 781 + Size: 32 bits. 783 + Units: seconds. 785 Fraction: specifies the fractional portion of the number of 786 seconds since the epoch. 788 + Size: 32 bits. 790 + Units: the unit is 2^(-32) seconds, which is roughly equal to 791 233 picoseconds. 793 Epoch: 795 The epoch is 1970-01-01T00:00 in UTC time. Note this epoch value 796 is different from the one used in Section 6 of [RFC5905] (which 797 will wrap around in 2036). 799 Leap seconds: 801 This timestamp format is affected by leap seconds. The timestamp 802 represents the number of seconds elapsed since the epoch minus the 803 number of leap seconds. 805 Resolution: 807 The resolution is 2^(-32) seconds. 809 Wraparound: 811 This time format wraps around every 2^32 seconds, which is roughly 812 136 years. The next wraparound will occur in the year 2106. 814 Synchronization aspects: 816 It is assumed that SFC data plane elements are synchronized to UTC 817 using a synchronization mechanism that is outside the scope of 818 this document. In typical deployments, SFC data plane elements 819 use NTP [RFC5905] for synchronization. Thus, the timestamp may be 820 derived from the NTP-synchronized clock, allowing the timestamp to 821 be measured with respect to the clock of an NTP server. Since 822 this time format is specified in terms of UTC, it is affected by 823 leap seconds (in a manner analogous to the NTP time format, which 824 is similar). Therefore, the value of a timestamp during or 825 slightly after a leap second may be temporarily inaccurate. 827 7. Processing Rules 829 The following subsections describe the processing rules for integrity 830 protected NSH and optionally encrypted Context Headers. 832 7.1. Generic Behavior 834 This document adheres to the recommendations in Section 8.1 of 835 [RFC8300] for handling the Context Headers at both ingress and egress 836 SFC boundary nodes (i.e., to strip the entire NSH, including Context 837 Headers). 839 Failures of a classifier to inject the Context Headers defined in 840 this document SHOULD be logged locally while a notification alarm MAY 841 be sent to an SFC control element. Failures of an NSH-aware node to 842 validate the integrity of the NSH data MUST cause that packet to be 843 discarded while a notification alarm MAY be sent to an SFC control 844 element. The details of sending notification alarms (i.e., the 845 parameters that affect the transmission of the notification alarms 846 depending on the information in the context header such as frequency, 847 thresholds, and content in the alarm) SHOULD be configurable. 849 NSH-aware SFs and SFC proxies MAY be instructed to strip some 850 encrypted Context Headers from the packet or to pass the data to the 851 next SF in the service function chain after processing the content of 852 the Context Headers. If no instruction is provided, the default 853 behavior for intermediary NSH-aware nodes is to maintain such Context 854 Headers so that the information can be passed to next NSH-aware hops. 855 NSH-aware SFs and SFC proxies MUST re-apply the integrity protection 856 if any modification is made to the Context Headers (e.g., strip a 857 Context Header, update the content of an existing Context Header, 858 insert a new Context Header). 860 An NSH-aware SF or SFC Proxy that is not allowed to decrypt any 861 Context Headers MUST NOT be given access to the ENC_KEY. 863 Otherwise, an NSH-aware SF or SFC Proxy that receives encrypted 864 Context Headers, for which it is not allowed to consume a specific 865 Context Header it decrypts (but consumes others), MUST keep that 866 Context Header unaltered when forwarding the packet upstream. 868 Only one instance of "MAC and Encrypted Metadata" Context Header 869 (Section 5) is allowed in an NSH level. If multiple instances of 870 "MAC and Encrypted Metadata" Context Header are included in an NSH 871 level, the SFC data plane element MUST process the first instance and 872 ignore subsequent instances, and MAY log or increase a counter for 873 this event as per Section 2.5.1 of [RFC8300]. If NSH-in-NSH is used 874 (Section 4.6), distinct LoAs may be used for each NSH level. 876 MTU and fragmentation considerations are discussed in Section 8. 878 7.2. MAC NSH Data Generation 880 After performing any Context Header encryption, the HMAC algorithm 881 discussed in [RFC4868] is used to integrity protect the target NSH 882 data. An NSH imposer inserts a "MAC and Encrypted Metadata" Context 883 Header for integrity protection (Section 5). 885 The NSH imposer sets the MAC field to zero and then computes the 886 message integrity for the target NSH data (depending on the integrity 887 protection scope discussed in Section 5) using MAC_KEY and HMAC 888 algorithm. It inserts the computed digest in the MAC field of the 889 "MAC and Encrypted Metadata" Context Header. The length of the MAC 890 is decided by the HMAC algorithm adopted for the particular key 891 identifier. 893 The Message Authentication Code (T) computation process for the 894 target NSH data with HMAC-SHA-256-128() can be illustrated as 895 follows: 897 T = HMAC-SHA-256-128(MAC_KEY, target NSH data) 899 An entity in the SFP that updates the NSH MUST follow the above 900 behavior to maintain message integrity of the NSH for subsequent 901 validations. 903 7.3. Encrypted NSH Metadata Generation 905 An NSH imposer can encrypt Context Headers carrying sensitive 906 metadata, i.e., encrypted and unencrypted metadata may be carried 907 simultaneously in the same NSH packet (Sections 5 and 6). 909 In order to prevent pervasive monitoring [RFC7258], it is RECOMMENDED 910 to encrypt all Context Headers. All Context Headers carrying 911 privacy-sensitive metadata MUST be encrypted; by doing so, privacy- 912 sensitive metadata is not revealed to attackers. Privacy specific 913 threats are discussed in Section 5.2 of [RFC6973]. 915 Using the secret key (ENC_KEY) and authenticated encryption 916 algorithm, the NSH imposer encrypts the Context Headers (as set, for 917 example, in Section 3) and inserts the resulting payload in the "MAC 918 and Encrypted Metadata" Context Header (Section 5). The additional 919 authenticated data input to the AEAD function is a zero-length byte 920 string. The entire Context Header carrying a sensitive metadata is 921 encrypted (that is, including the MD Class, Type, Length, and 922 associated metadata of each Context Header). 924 More details about the exact encryption procedure are provided in 925 Section 2.1 of [RFC5116]. In this case, the associated data (A) 926 input is zero-length for AES-GCM. 928 An authorized entity in the SFP that updates the content of an 929 encrypted Context Header or needs to add a new encrypted Context 930 Header MUST also follow the aforementioned behavior. 932 7.4. Timestamp for Replay Attack Prevention 934 The Timestamp imposed by an initial Classifier is left untouched 935 along an SFP. However, it can be updated when reclassification 936 occurs (Section 4.8 of [RFC7665]). The same considerations for 937 setting the Timestamp are followed in both initial classification and 938 reclassification (Section 6). 940 The received NSH is accepted by an NSH-aware node if the Timestamp 941 (TS) in the NSH is recent enough to the reception time of the NSH 942 (TSrt). The following formula is used for this check: 944 -Delta < (TSrt - TS) < +Delta 946 The Delta interval is a configurable parameter. The default value 947 for the allowed Delta is 2 seconds. Special care should be taken 948 when setting very low Delta values as this may lead to dropping 949 legitimate traffic. If the timestamp is not within the boundaries, 950 then the SFC data plane element receiving such packet MUST discard 951 the NSH message. 953 Replay attacks within the Delta window may be detected by an NSH- 954 aware node by recording a unique value derived from the packet, for 955 example, a unique value from the MAC field value. Such an NSH-aware 956 node will detect and reject duplicates. If for legitimate service 957 reasons, some flows have to be duplicated but still share portion of 958 an SFP with the original flow, legitimate duplicate packets will be 959 tagged by NSH-aware nodes involved in that segment as replay packets 960 unless sufficient entropy is added to the duplicate packet. How such 961 an entropy is added is implementation-specific. 963 Note: Within the timestamp delta window, defining a sequence 964 number to protect against replay attacks may be considered. In 965 such mode, NSH-aware nodes must discard packets with duplicate 966 sequence numbers within the timestamp delta window. However, in 967 deployments with several instances of the same SF (e.g., cluster 968 or load-balanced SFs), a mechanism to coordinate among those 969 instances to discard duplicate sequence numbers is required. 970 Because the coordination mechanism to comply with this requirement 971 is service-specific, this document does not include this 972 protection. 974 All SFC data plane elements must be synchronized among themselves. 975 These elements may be synchronized to a global reference time. 977 7.5. NSH Data Validation 979 When an SFC data plane element that conforms to this specification 980 needs to check the validity of the NSH data, it MUST ensure that a 981 "MAC and Encrypted Metadata" Context Header is included in a received 982 NSH packet. The imposer MUST silently discard the packet and MUST 983 log an error at least once per the SPI if at least one of the 984 following is observed: 986 o the "MAC and Encrypted Metadata" Context Header is missing, 988 o the enclosed key identifier is unknown or invalid (e.g., the 989 corresponding key expired), 991 o the timestamp is invalid (Section 7.4). 993 If the timestamp check is successfully passed, the SFC data plane 994 element proceeds with NSH data integrity validation. After storing 995 the value of the MAC field in the "MAC and Encrypted Metadata" 996 Context Header, the SFC data plane element fills the MAC field with 997 zeros. Then, the SFC data plane element generates the message 998 integrity for the target NSH data (depending on the integrity 999 protection scope discussed in Section 5) using MAC_KEY and HMAC 1000 algorithm. If the value of the newly generated digest is identical 1001 to the stored one, the SFC data plane element is certain that the NSH 1002 data has not been tampered and validation is therefore successful. 1003 Otherwise, the NSH packet MUST be discarded. The comparison of the 1004 computed HMAC value to the stored value MUST be done in a constant- 1005 time manner to thwart timing attacks. 1007 7.6. Decryption of NSH Metadata 1009 If entitled to consume a supplied encrypted Context Header, an NSH- 1010 aware SF or SFC Proxy decrypts metadata using (K) and decryption 1011 algorithm for the key identifier in the NSH. 1013 Authenticated encryption algorithm has only a single output, either a 1014 plaintext or a special symbol (FAIL) that indicates that the inputs 1015 are not authentic (Section 2.2 of [RFC5116]). 1017 8. MTU Considerations 1019 The SFC architecture prescribes that additional information be added 1020 to packets to: 1022 o Identify SFPs: this is typically the NSH Base Header and Service 1023 Path Header. 1025 o Carry metadata such as those defined in Section 5. 1027 o Steer the traffic along the SFPs: transport encapsulation. 1029 This added information increases the size of the packet to be carried 1030 along an SFP. 1032 Aligned with Section 5 of [RFC8300], it is RECOMMENDED for network 1033 operators to increase the underlying MTU so that NSH traffic is 1034 forwarded within an SFC-enabled domain without fragmentation. The 1035 available underlying MTU should be taken into account by network 1036 operators when providing SFs with the required Context Headers to be 1037 injected per SFP and the size of the data to be carried in these 1038 Context Headers. 1040 If the underlying MTU cannot be increased to accommodate the NSH 1041 overhead, network operators may rely upon a transport encapsulation 1042 protocol with the required fragmentation handling. The impact of 1043 activating such feature on SFFs should be carefully assessed by 1044 network operators (Section 5.6 of [RFC7665]). 1046 When dealing with MTU issues, network operators should consider the 1047 limitations of various tunnel mechanisms such as those discussed in 1048 [I-D.ietf-intarea-tunnels]. 1050 9. Security Considerations 1052 Data plane SFC-related security considerations, including privacy, 1053 are discussed in Section 6 of [RFC7665] and Section 8 of [RFC8300]. 1054 In particular, Section 8.2.2 of [RFC8300] states that attached 1055 metadata (i.e., Context Headers) should be limited to that necessary 1056 for correct operation of the SFP. Also, that section indicates that 1057 [RFC8165] discusses metadata considerations that operators can take 1058 into account when using NSH. 1060 The guidelines for cryptographic key management are discussed in 1061 [RFC4107]. The group key management protocol related security 1062 considerations discussed in Section 8 of [RFC4046] needs to be taken 1063 into consideration. 1065 The interaction between the SFC data plane elements and a key 1066 management system MUST NOT be transmitted in clear since this would 1067 completely destroy the security benefits of the integrity protection 1068 solution defined in this document. 1070 The secret key (K) must have an expiration time assigned as the 1071 latest point in time before which the key may be used for integrity 1072 protection of NSH data and encryption of Context Headers. Prior to 1073 the expiration of the secret key, all participating NSH-aware nodes 1074 SHOULD have the control plane distribute a new key identifier and 1075 associated keying material so that when the secret key is expired, 1076 those nodes are prepared with the new secret key. This allows the 1077 NSH imposer to switch to the new key identifier as soon as necessary. 1078 It is RECOMMENDED that the next key identifier and associated keying 1079 material be distributed by the control plane well prior to the secret 1080 key expiration time. Additional guidance for users of AEAD functions 1081 about rekeying can be found in [I-D.irtf-cfrg-aead-limits]. 1083 The security and integrity of the key-distribution mechanism is vital 1084 to the security of the SFC system as a whole. 1086 NSH data are exposed to several threats: 1088 o A on-path attacker modifying the NSH data. 1090 o Attacker spoofing the NSH data. 1092 o Attacker capturing and replaying the NSH data. 1094 o Data carried in Context Headers revealing privacy-sensitive 1095 information to attackers. 1097 o Attacker replacing the packet on which the NSH is imposed with a 1098 modified or bogus packet. 1100 In an SFC-enabled domain where the above attacks are possible, (1) 1101 NSH data MUST be integrity-protected and replay-protected, and (2) 1102 privacy-sensitive NSH metadata MUST be encrypted for confidentiality 1103 preservation purposes. The Base and Service Path headers are not 1104 encrypted. 1106 MACs with two levels of assurance are defined in Section 5. 1107 Considerations specific to each level of assurance are discussed in 1108 Sections 9.1 and 9.2. 1110 The attacks discussed in [I-D.nguyen-sfc-security-architecture] are 1111 handled owing to the solution specified in this document, except for 1112 attacks dropping packets. Such attacks can be detected relying upon 1113 statistical analysis; such analysis is out of the scope of this 1114 document. Also, if SFFs are not involved in the integrity checks, a 1115 misbehaving SFF which decrements SI while this should be done by an 1116 SF (SF bypass attack) will be detected by an upstream SF because the 1117 integrity check will fail. 1119 Some events are logged locally with notification alerts sent by NSH- 1120 aware nodes to a Control Element. These events SHOULD be rate- 1121 limited. 1123 The solution specified in this document does not provide data origin 1124 authentication. 1126 In order to detect compromised nodes, it is assumed that appropriate 1127 mechanisms to monitor and audit an SFC-enabled domain to detect 1128 misbehavior and to deter misuse are in place. Compromised nodes can 1129 thus be withdrawn from active service function chains using 1130 appropriate control plane mechanisms. 1132 9.1. MAC#1 1134 An active attacker can potentially modify the Base header (e.g., 1135 decrement the TTL so the next SFF in the SFP discards the NSH 1136 packet). An active attacker can typically also drop NSH packets. As 1137 such, this attack is not considered an attack against the security 1138 mechanism specified in the document. 1140 It is expected that specific devices in the SFC-enabled domain will 1141 be configured such that no device other than the classifiers (when 1142 reclassification is enabled), NSH-aware SFs, and SFC proxies will be 1143 able to update the integrity protected NSH data (Section 7.1), and 1144 also such that no device other than the NSH-aware SFs and SFC proxies 1145 will be able to decrypt and update the Context Headers carrying 1146 sensitive metadata (Section 7.1). In other words, if the NSH-aware 1147 SFs and SFC proxies in the SFC-enabled domain are considered fully 1148 trusted to act on the NSH data. Only these elements can have access 1149 to sensitive NSH metadata and the keying material used to integrity 1150 protect NSH data and encrypt Context Headers. 1152 9.2. MAC#2 1154 SFFs can detect whether an illegitimate node has altered the content 1155 of the Base header. Such messages must be discarded with appropriate 1156 logs and alarms generated (see Section 7.1). 1158 Similar to Section 9.1, no device other than the NSH-aware SFs and 1159 SFC proxies in the SFC-enabled domain should be able to decrypt and 1160 update the Context Headers carrying sensitive metadata. 1162 9.3. Time Synchronization 1164 [RFC8633] describes best current practices to be considered in 1165 deployments where SFC data plane elements use NTP for time 1166 synchronization purposes. 1168 Also, a mechanism to provide cryptographic security for NTP is 1169 specified in [RFC8915]. 1171 10. IANA Considerations 1173 This document requests IANA to assign the following types from the 1174 "NSH IETF-Assigned Optional Variable-Length Metadata Types" (0x0000 1175 IETF Base NSH MD Class) registry available at: 1176 https://www.iana.org/assignments/nsh/nsh.xhtml#optional-variable- 1177 length-metadata-types. 1179 +-------+-------------------------------+----------------+ 1180 | Value | Description | Reference | 1181 +=======+===============================+================+ 1182 | TBD1 | MAC and Encrypted Metadata #1 | [ThisDocument] | 1183 | TBD2 | MAC and Encrypted Metadata #2 | [ThisDocument] | 1184 +-------+-------------------------------+----------------+ 1186 11. Acknowledgements 1188 This document was edited as a follow-up to the discussion in 1189 IETF#104: https://datatracker.ietf.org/meeting/104/materials/slides- 1190 104-sfc-sfc-chair-slides-01 (slide 7). 1192 Thanks to Joel Halpern, Christian Jacquenet, Dirk von Hugo, Tal 1193 Mizrahi, Daniel Migault, Diego Lopez, Greg Mirsky, and Dhruv Dhody 1194 for the comments. 1196 Many thanks to Steve Hanna for the valuable secdir review and Juergen 1197 Schoenwaelder for the opsdir review. 1199 Thanks to Greg Mirsky for the Shepherd review. 1201 Thanks to Alvaro Retana, Lars Eggert, Martin Duke, Erik Kline, 1202 Zaheduzzaman Sarker, Eric Vyncke, Roman Danyliw, Murray Kucherawy, 1203 John Scudder, and Benjamin Kaduk for the IESG review. 1205 12. References 1207 12.1. Normative References 1209 [GCM] Dworkin, M., "Recommendation for Block Cipher Modes of 1210 Operation: Galois/Counter Mode (GCM) and GMAC", 1211 NIST Special Publication 800-38D, November 2007. 1213 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 1214 Hashing for Message Authentication", RFC 2104, 1215 DOI 10.17487/RFC2104, February 1997, 1216 . 1218 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1219 Requirement Levels", BCP 14, RFC 2119, 1220 DOI 10.17487/RFC2119, March 1997, 1221 . 1223 [RFC4107] Bellovin, S. and R. Housley, "Guidelines for Cryptographic 1224 Key Management", BCP 107, RFC 4107, DOI 10.17487/RFC4107, 1225 June 2005, . 1227 [RFC4868] Kelly, S. and S. Frankel, "Using HMAC-SHA-256, HMAC-SHA- 1228 384, and HMAC-SHA-512 with IPsec", RFC 4868, 1229 DOI 10.17487/RFC4868, May 2007, 1230 . 1232 [RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated 1233 Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008, 1234 . 1236 [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function 1237 Chaining (SFC) Architecture", RFC 7665, 1238 DOI 10.17487/RFC7665, October 2015, 1239 . 1241 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1242 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1243 May 2017, . 1245 [RFC8300] Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed., 1246 "Network Service Header (NSH)", RFC 8300, 1247 DOI 10.17487/RFC8300, January 2018, 1248 . 1250 12.2. Informative References 1252 [I-D.arkko-farrell-arch-model-t] 1253 Arkko, J. and S. Farrell, "Challenges and Changes in the 1254 Internet Threat Model", draft-arkko-farrell-arch-model- 1255 t-04 (work in progress), July 2020. 1257 [I-D.ietf-intarea-tunnels] 1258 Touch, J. and M. Townsley, "IP Tunnels in the Internet 1259 Architecture", draft-ietf-intarea-tunnels-10 (work in 1260 progress), September 2019. 1262 [I-D.irtf-cfrg-aead-limits] 1263 Guenther, F., Thomson, M., and C. A. Wood, "Usage Limits 1264 on AEAD Algorithms", draft-irtf-cfrg-aead-limits-03 (work 1265 in progress), July 2021. 1267 [I-D.nguyen-sfc-security-architecture] 1268 THANG, N. C. and M. Park, "A Security Architecture Against 1269 Service Function Chaining Threats", draft-nguyen-sfc- 1270 security-architecture-00 (work in progress), November 1271 2019. 1273 [RFC4046] Baugher, M., Canetti, R., Dondeti, L., and F. Lindholm, 1274 "Multicast Security (MSEC) Group Key Management 1275 Architecture", RFC 4046, DOI 10.17487/RFC4046, April 2005, 1276 . 1278 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, 1279 "Network Time Protocol Version 4: Protocol and Algorithms 1280 Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, 1281 . 1283 [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., 1284 Morris, J., Hansen, M., and R. Smith, "Privacy 1285 Considerations for Internet Protocols", RFC 6973, 1286 DOI 10.17487/RFC6973, July 2013, 1287 . 1289 [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an 1290 Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 1291 2014, . 1293 [RFC7498] Quinn, P., Ed. and T. Nadeau, Ed., "Problem Statement for 1294 Service Function Chaining", RFC 7498, 1295 DOI 10.17487/RFC7498, April 2015, 1296 . 1298 [RFC7635] Reddy, T., Patil, P., Ravindranath, R., and J. Uberti, 1299 "Session Traversal Utilities for NAT (STUN) Extension for 1300 Third-Party Authorization", RFC 7635, 1301 DOI 10.17487/RFC7635, August 2015, 1302 . 1304 [RFC8165] Hardie, T., "Design Considerations for Metadata 1305 Insertion", RFC 8165, DOI 10.17487/RFC8165, May 2017, 1306 . 1308 [RFC8459] Dolson, D., Homma, S., Lopez, D., and M. Boucadair, 1309 "Hierarchical Service Function Chaining (hSFC)", RFC 8459, 1310 DOI 10.17487/RFC8459, September 2018, 1311 . 1313 [RFC8633] Reilly, D., Stenn, H., and D. Sibold, "Network Time 1314 Protocol Best Current Practices", BCP 223, RFC 8633, 1315 DOI 10.17487/RFC8633, July 2019, 1316 . 1318 [RFC8877] Mizrahi, T., Fabini, J., and A. Morton, "Guidelines for 1319 Defining Packet Timestamps", RFC 8877, 1320 DOI 10.17487/RFC8877, September 2020, 1321 . 1323 [RFC8915] Franke, D., Sibold, D., Teichel, K., Dansarie, M., and R. 1324 Sundblad, "Network Time Security for the Network Time 1325 Protocol", RFC 8915, DOI 10.17487/RFC8915, September 2020, 1326 . 1328 Authors' Addresses 1330 Mohamed Boucadair 1331 Orange 1332 Rennes 35000 1333 France 1335 Email: mohamed.boucadair@orange.com 1337 Tirumaleswar Reddy 1338 Akamai 1339 Embassy Golf Link Business Park 1340 Bangalore, Karnataka 560071 1341 India 1343 Email: kondtir@gmail.com 1345 Dan Wing 1346 Citrix Systems, Inc. 1347 USA 1349 Email: dwing-ietf@fuggles.com