idnits 2.17.1 draft-ietf-sfc-nsh-integrity-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 26, 2021) is 1002 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 1172, 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 (-13) exists of draft-ietf-intarea-tunnels-10 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: January 27, 2022 McAfee 6 D. Wing 7 Citrix 8 July 26, 2021 10 Integrity Protection for the Network Service Header (NSH) and Encryption 11 of Sensitive Context Headers 12 draft-ietf-sfc-nsh-integrity-07 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 January 27, 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 . . . . . . . . . . . . . . . . 7 62 4.2. One Secret Key, Two Security Services . . . . . . . . . . 9 63 4.3. Mandatory-to-Implement Authenticated Encryption and HMAC 64 Algorithms . . . . . . . . . . . . . . . . . . . . . . . 10 65 4.4. Key Management . . . . . . . . . . . . . . . . . . . . . 11 66 4.5. New NSH Variable-Length Context Headers . . . . . . . . . 11 67 4.6. Encapsulation of NSH within NSH . . . . . . . . . . . . . 12 68 5. New NSH Variable-Length Context Headers . . . . . . . . . . . 12 69 5.1. MAC#1 Context Header . . . . . . . . . . . . . . . . . . 13 70 5.2. MAC#2 Context Header . . . . . . . . . . . . . . . . . . 15 71 6. Timestamp Format . . . . . . . . . . . . . . . . . . . . . . 17 72 7. Processing Rules . . . . . . . . . . . . . . . . . . . . . . 18 73 7.1. Generic Behavior . . . . . . . . . . . . . . . . . . . . 18 74 7.2. MAC NSH Data Generation . . . . . . . . . . . . . . . . . 19 75 7.3. Encrypted NSH Metadata Generation . . . . . . . . . . . . 20 76 7.4. Timestamp for Replay Attack Prevention . . . . . . . . . 20 77 7.5. NSH Data Validation . . . . . . . . . . . . . . . . . . . 21 78 7.6. Decryption of NSH Metadata . . . . . . . . . . . . . . . 22 79 8. MTU Considerations . . . . . . . . . . . . . . . . . . . . . 22 80 9. Security Considerations . . . . . . . . . . . . . . . . . . . 23 81 9.1. MAC#1 . . . . . . . . . . . . . . . . . . . . . . . . . . 25 82 9.2. MAC#2 . . . . . . . . . . . . . . . . . . . . . . . . . . 25 83 9.3. Time Synchronization . . . . . . . . . . . . . . . . . . 25 84 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 85 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26 86 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 26 87 12.1. Normative References . . . . . . . . . . . . . . . . . . 26 88 12.2. Informative References . . . . . . . . . . . . . . . . . 27 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29 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 logics 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]). 118 Note that some transport encapsulations (e.g., IPsec) only provide 119 hop-by-hop security between two SFC data plane elements (e.g., two 120 Service Function Forwarders (SFFs), SFF to SF) and do not provide SF- 121 to-SF security of NSH metadata. For example, if IPsec is used, SFFs 122 or SFs within a Service Function Path (SFP) that are not authorized 123 to access the sensitive metadata (e.g., privacy) will have access to 124 the metadata. As a reminder, the metadata referred to is information 125 that is inserted by Classifiers or intermediate SFs and shared with 126 downstream SFs; such information is not visible to the communication 127 endpoints (Section 4.9 of [RFC7665]). 129 The lack of such capability was reported during the development of 130 [RFC8300] and [RFC8459]. The reader may refer to Section 3.2.1 of 131 [I-D.arkko-farrell-arch-model-t] for a discussion on the need for 132 more awareness about attacks from within closed domains. 134 This specification fills that gap for SFC (that is, define the "NSH 135 Variable Header-Based Integrity" option mentioned in Section 8.2.1 of 136 [RFC8300]). Concretely, this document adds integrity protection and 137 optional encryption of sensitive metadata directly to the NSH 138 (Section 4). The integrity protection covers the packet payload and 139 provides replay protection (Section 7.4). Thus, the NSH does not 140 have to rely upon an underlying transport encapsulation for security. 142 This specification introduces new Variable-Length Context Headers to 143 carry fields necessary for integrity-protected NSH headers and 144 encrypted Context Headers (Section 5). This specification is only 145 applicable to NSH MD Type 0x02 (Section 2.5 of [RFC8300]). MTU 146 considerations are discussed in Section 8. This specification is not 147 applicable to NSH MD Type 0x01 (Section TBD of RFC8300) because it 148 only allows a Fixed-Length Context Header whose size is 16-bytes and 149 is not sufficient to accommodate both the metadata and message 150 integrity of the NSH data. 152 This specification limits access to NSH-supplied information along an 153 SFP to entities that have a need to interpret it. 155 The mechanism specified in this document does not preclude the use of 156 transport security. Such considerations are deployment-specific. 158 It is out of the scope of this document to specify an NSH-aware 159 control plane solution. 161 2. Terminology 163 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 164 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 165 "OPTIONAL" in this document are to be interpreted as described in BCP 166 14 [RFC2119] [RFC8174] when, and only when, they appear in all 167 capitals, as shown here. 169 This document makes use of the terms defined in [RFC7665] and 170 [RFC8300]. 172 The document defines the following terms: 174 SFC data plane element: Refers to NSH-aware SF, SFF, SFC Proxy, or 175 Classifier as defined in the SFC data plane architecture [RFC7665] 176 and further refined in [RFC8300]. 178 SFC control element: Is a logical entity that instructs one or more 179 SFC data plane elements on how to process NSH packets within an 180 SFC-enabled domain. 182 Key Identifier: Is used to identify keys to authorized entities. 183 See, for example, 'kid' usage in [RFC7635]. 185 NSH data: The NSH is composed of a Base Header, a Service Path 186 Header, and optional Context Headers. NSH data refers to all the 187 above headers and the packet or frame on which the NSH is imposed 188 to realize an SFP. 190 NSH imposer: Refers to an SFC data plane element that is entitled to 191 impose the NSH with the Context Headers defined in this document. 193 3. Assumptions and Basic Requirements 195 Section 2 of [RFC8300] specifies that the NSH data can be spread over 196 three headers: 198 o Base Header: Provides information about the service header and the 199 payload protocol. 201 o Service Path Header: Provides path identification and location 202 within an SFP. 204 o Context Header(s): Carries metadata (i.e., context data) along a 205 service path. 207 The NSH allows sharing context information (a.k.a., metadata) with 208 downstream NSH-aware data plane elements on a per SFC/SFP basis. To 209 that aim: 211 The Classifier is instructed by an SFC control element about the 212 set of context information to be supplied for a given service 213 function chain. 215 An NSH-aware SF is instructed by an SFC control element about any 216 metadata it needs to attach to packets for a given service 217 function chain. This instruction may occur any time during the 218 validity lifetime of an SFC/SFP. For a given service function 219 chain, the NSH-aware SF is also provided with an order for 220 consuming a set of contexts supplied in a packet. 222 An NSH-aware SF can also be instructed by an SFC control element 223 about the behavior it should adopt after consuming context 224 information that was supplied in the NSH. For example, the 225 context information can be maintained, updated, or stripped. 227 An SFC Proxy may be instructed by an SFC control element about the 228 behavior it should adopt to process the context information that 229 was supplied in the NSH on behalf of an NSH-unaware SF (e.g., the 230 context information can be maintained or stripped). The SFC Proxy 231 may also be instructed to add some new context information into 232 the NSH on behalf of an NSH-unaware SF. 234 In reference to Table 1, 236 o Classifiers, NSH-aware SFs, and SFC proxies are entitled to update 237 the Context Header(s). 239 o Only NSH-aware SFs and SFC proxies are entitled to update the 240 Service Path Header. 242 o SFFs are entitled to modify the Base Header (TTL value, for 243 example). Nevertheless, SFFs are not supposed to act on the 244 Context Headers or look into the content of the Context Headers 245 (Section 4.3 of [RFC7665]). 247 Thus, the following requirements: 249 o Only Classifiers, NSH-aware SFs, and SFC proxies must be able to 250 encrypt and decrypt a given Context Header. 252 o Both encrypted and unencrypted Context Headers may be included in 253 the same NSH. 255 o The solution must provide integrity protection for the Service 256 Path Header. 258 o The solution must provide optional integrity protection for the 259 Base Header. The implications of disabling such checks are 260 discussed in Section 9.1. 262 +----------------+-----------------------------+-------------------+ 263 | | Insert, remove, or replace | Update the NSH | 264 | | the NSH | | 265 | | | | 266 | SFC Data Plane +---------+---------+---------+---------+---------+ 267 | Element | | | |Decrement| Update | 268 | | Insert | Remove | Replace | Service | Context | 269 | | | | | Index |Header(s)| 270 +================+=========+=========+=========+=========+=========+ 271 | | + | | + | | + | 272 | Classifier | | | | | | 273 +----------------+---------+---------+---------+---------+---------+ 274 |Service Function| | + | | | | 275 |Forwarder (SFF) | | | | | | 276 +----------------+---------+---------+---------+---------+---------+ 277 |Service Function| | | | + | + | 278 | (SF) | | | | | | 279 +----------------+---------+---------+---------+---------+---------+ 280 | | + | + | | + | + | 281 | SFC Proxy | | | | | | 282 +----------------+---------+---------+---------+---------+---------+ 284 Table 1: Summary of NSH Actions 286 4. Design Overview 288 4.1. Supported Security Services 290 This specification provides the functions described in the following 291 subsections. 293 4.1.1. Encrypt All or a Subset of Context Headers 295 The solution allows encrypting all or a subset of NSH Context Headers 296 by Classifiers, NSH-aware SFs, and SFC proxies. 298 As depicted in Table 2, SFFs are not involved in data encryption. 300 +-----------------+------------------------------+------------------+ 301 | Data Plane | Base and Service Path | Context Header | 302 | Element | Headers Encryption | Encryption | 303 +-----------------+------------------------------+------------------+ 304 | Classifier | No | Yes | 305 | SFF | No | No | 306 | NSH-aware SF | No | Yes | 307 | SFC Proxy | No | Yes | 308 | NSH-unaware SF | No | No | 309 +-----------------+------------------------------+------------------+ 311 Table 2: Encryption Function Supported by SFC Data Plane Elements 313 Classifier(s), NSH-aware SFs, and SFC proxies are instructed with the 314 set of Context Headers (privacy-sensitive metadata, typically) that 315 must be encrypted. Encryption keying material is only provided to 316 these SFC data plane elements. 318 The control plane may indicate the set of SFC data plane elements 319 that are entitled to supply a given Context Header (e.g., in 320 reference to their identifiers as assigned within the SFC-enabled 321 domain). It is out of the scope of this document to elaborate on how 322 such instructions are provided to the appropriate SFC data plane 323 elements, nor to detail the structure used to store the instructions. 325 The Service Path Header (Section 2 of [RFC8300]) is not encrypted 326 because SFFs use Service Index (SI) in conjunction with Service Path 327 Identifier (SPI) for determining the next SF in the path. 329 4.1.2. Integrity Protection 331 The solution provides integrity protection for the NSH data. Two 332 levels of assurance (LoAs) are supported. 334 The first level of assurance is where all NSH data except the Base 335 Header are integrity protected (Figure 1). In this case, the NSH 336 imposer may be a Classifier, an NSH-aware SF, or an SFC Proxy. SFFs 337 are not provided with authentication material. Further details are 338 discussed in Section 5.1. 340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 341 | Transport Encapsulation | 342 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+... 343 | Base Header | | 344 +->+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ N 345 | | Service Path Header | S 346 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ H 347 | | Context Header(s) | | 348 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+... 349 | | Original Packet | 350 +->+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 351 | 352 +------Scope of integrity protected data 354 Figure 1: First Level of Assurance 356 The second level of assurance is where all NSH data, including the 357 Base Header, are integrity protected (Figure 2). In this case, the 358 NSH imposer may be a Classifier, an NSH-aware SF, an SFF, or an SFC 359 Proxy. Further details are provided in Section 5.2. 361 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 362 | Transport Encapsulation | 363 +->+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+... 364 | | Base Header | | 365 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ N 366 | | Service Path Header | S 367 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ H 368 | | Context Header(s) | | 369 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+... 370 | | Original Packet | 371 +->+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 372 | 373 +----Scope of integrity protected data 375 Figure 2: Second Level of Assurance 377 The integrity protection scope is explicitly signaled to NSH-aware 378 SFs, SFFs, and SFC proxies in the NSH by means of a dedicated MD Type 379 (Section 5). 381 In both levels of assurance, the unencrypted Context Headers and the 382 packet on which the NSH is imposed are subject to integrity 383 protection. 385 Table 3 lists the roles of SFC data plane elements in providing 386 integrity protection for the NSH. 388 +--------------------+----------------------------------+ 389 | Data Plane Element | Integrity Protection | 390 +--------------------+----------------------------------+ 391 | Classifier | Yes | 392 | SFF | No (first LoA); Yes (second LoA) | 393 | NSH-aware SF | Yes | 394 | SFC Proxy | Yes | 395 | NSH-unaware SF | No | 396 +--------------------+----------------------------------+ 398 Table 3: Integrity Protection Supported by SFC Data Plane Elements 400 4.2. One Secret Key, Two Security Services 402 The Authenticated Encryption with Associated Data (AEAD) defined in 403 Section 5 of [RFC5116] is used to encrypt the Context Headers that 404 carry sensitive metadata and to provide integrity for the Context 405 Headers. 407 The secondary keys MAC_KEY and ENC_KEY are generated from the input 408 secret key (K) as follows, each of these two keys is an octet string: 410 MAC_KEY: consists of the initial MAC_KEY_LEN octets of K, in order. 411 The MAC_KEY is used for calculating the message integrity of the 412 NSH data. In other words, the integrity protection provided by 413 the cryptographic mechanism is extended to also provide protection 414 for the unencrypted Context Headers and the packet on which the 415 NSH is imposed. 417 ENC_KEY: consists of the final ENC_KEY_LEN octets of K, in order. 418 The ENC_KEY is used as the symmetric encryption key for encrypting 419 the Context Headers. 421 The Hashed Message Authentication Mode (HMAC) algorithm discussed in 422 [RFC4868] is used to protect the integrity of the NSH data. The 423 algorithm for implementing and validating HMACs is provided in 424 [RFC2104]. 426 The advantage of using both AEAD and HMAC algorithms is that NSH- 427 aware SFs and SFC proxies only need to re-compute the message 428 integrity of the NSH data after decrementing the Service Index (SI) 429 and do not have to re-compute the ciphertext. The other advantage is 430 that SFFs do not have access to the ENC_KEY and cannot act on the 431 encrypted Context Headers and, only in case of the second level of 432 assurance, SFFs do have access to the MAC_KEY. Similarly, an NSH- 433 aware SF or SFC Proxy not allowed to decrypt the Context Headers will 434 not have access to the ENC_KEY. 436 The authenticated encryption algorithm or HMAC algorithm to be used 437 by SFC data plane elements is typically controlled using the SFC 438 control plane. Mandatory to implement authenticated encryption and 439 HMAC algorithms are listed in Section 4.3. 441 The authenticated encryption process takes four inputs, each of which 442 is an octet string: a secret key (ENC_KEY, referred to as K in 443 [RFC5116]), a plaintext (P), associated data (A) (which contains the 444 data to be authenticated, but not encrypted), and a nonce (N). A 445 ciphertext (C) is generated as an output as discussed in Section 2.1 446 of [RFC5116]. 448 In order to decrypt and verify, the cipher takes as input ENC_KEY, N, 449 A, and C. The output is either the plaintext or an error indicating 450 that the decryption failed as described in Section 2.2 of [RFC5116]. 452 4.3. Mandatory-to-Implement Authenticated Encryption and HMAC 453 Algorithms 455 Classifiers, NSH-aware SFs, and SFC proxies MUST implement the 456 AES_128_GCM [GCM][RFC5116] algorithm and SHOULD implement the 457 AES_192_GCM and AES_256_GCM algorithms. 459 Classifiers, NSH-aware SFs, and SFC proxies MUST implement the HMAC- 460 SHA-256-128 algorithm and SHOULD implement the HMAC-SHA-384-192 and 461 HMAC-SHA-512-256 algorithms. 463 SFFs MAY implement the aforementioned cipher suites and HMAC 464 algorithms. 466 Note: The use of AES_128_CBC_HMAC_SHA_256 algorithm would have 467 avoided the need for a second 128-bit authentication tag, but due 468 to the nature of how Cipher Block Chaining (CBC) mode operates, 469 AES_128_CBC_HMAC_SHA_256 allows for malleability of plaintexts. 470 This malleability allows for attackers to make changes in the 471 ciphertext and, if parts of the plaintext are known, create 472 arbitrary blocks of plaintext. This specification mandates the 473 use of AES-GCM to prevent this type of attack. 475 4.4. Key Management 477 The procedure for the allocation/provisioning of secret keys (K) and 478 authenticated encryption algorithm or MAC_KEY and HMAC algorithm is 479 outside the scope of this specification. As such, this specification 480 does not mandate the support of any specific mechanism. 482 The document does not assume nor preclude the following: 484 o The same keying material is used for all the service functions 485 used within an SFC-enabled domain. 487 o Distinct keying material is used per SFP by all involved SFC data 488 path elements. 490 o Per-tenant keys are used. 492 In order to accommodate deployments relying upon keying material per 493 SFC/SFP and also the need to update keys after encrypting NSH data 494 for a certain amount of time, this document uses key identifiers to 495 unambiguously identify the appropriate keying material. Doing so 496 addresses the problem of synchronization of keying material. 498 Additional information on manual vs. automated key management and 499 when one should be used over the other can be found in [RFC4107]. 501 The risk involved in using a group-shared symmetric key increases 502 with the size of the group to which it is shared. Additional 503 security issues are discussed in Section 9. 505 4.5. New NSH Variable-Length Context Headers 507 New NSH Variable-Length Context Headers are defined in Section 5 for 508 NSH data integrity protection and, optionally, encryption of Context 509 Headers carrying sensitive metadata. Concretely, an NSH imposer 510 includes (1) the key identifier to identify the keying material, (2) 511 the timestamp to protect against replay attacks (Section 7.4), and 512 (3) the Message Authentication Code (MAC) for the target NSH data 513 (depending on the integrity protection scope) calculated using the 514 MAC_KEY and optionally Context Headers encrypted using ENC_KEY. 516 An SFC data plane element that needs to check the integrity of the 517 NSH data uses MAC_KEY and the HMAC algorithm for the key identifier 518 being carried in the NSH. 520 An NSH-aware SF or SFC Proxy that needs to decrypt some Context 521 Headers uses ENC_KEY and the decryption algorithm for the key 522 identifier being carried in the NSH. 524 Section 7 specifies the detailed procedure. 526 4.6. Encapsulation of NSH within NSH 528 As discussed in Section 3 of [RFC8459], an SFC-enabled domain 529 (called, upper-level domain) may be decomposed into many sub-domains 530 (called, lower-level domains). In order to avoid maintaining state 531 to restore back upper-level NSH information at the boundaries of 532 lower-level domains, two NSH levels are used: an Upper-NSH which is 533 imposed at the boundaries of the upper-level domain and a Lower-NSH 534 that is pushed by the Classifier of a lower-level domain in front of 535 the original NSH (Figure 3). As such, the Upper-NSH information is 536 carried along the lower-level chain without modification. The packet 537 is forwarded in the top-level domain according to the Upper-NSH, 538 while it is forwarded according to the Lower-NSH in a lower-level 539 domain. 541 +---------------------------------+ 542 | Transport Encapsulation | 543 +->+---------------------------------+ 544 | | Lower-NSH Header | 545 | +---------------------------------+ 546 | | Upper-NSH Header | 547 | +---------------------------------+ 548 | | Original Packet | 549 +->+---------------------------------+ 550 | 551 | 552 +----Scope of NSH security protection 553 provided by a lower-level domain 555 Figure 3: Encapsulation of NSH within NSH 557 SFC data plane elements of a lower-level domain include the Upper-NSH 558 when computing the MAC. 560 Keying material used at the upper-level domain SHOULD NOT be the same 561 as the one used by a lower-level domain. 563 5. New NSH Variable-Length Context Headers 565 This section specifies the format of new Variable-Length Context 566 headers that are used for NSH integrity protection and, optionally, 567 Context Headers encryption. 569 In particular, this section defines two "MAC and Encrypted Metadata" 570 Context Headers; each having specific deployment constraints. Unlike 571 Section 5.1, the level of assurance provided in Section 5.2 requires 572 sharing MAC_KEY with SFFs. Both Context headers have the same format 573 as shown in Figure 4. 575 0 1 2 3 576 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 577 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 578 | Metadata Class | Type |U| Length | 579 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 580 | Key Id Len | Key Identifier (Variable) ~ 581 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 582 ~ Timestamp (8 bytes) ~ 583 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 584 | Nonce Length | Nonce (Variable) ~ 585 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 586 | Message Authentication Code and optional Encrypted | 587 ~ Context Headers (Variable) ~ 588 | | 589 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 591 Figure 4: MAC and Encrypted Metadata Context Header 593 The "MAC and Encrypted Metadata" Context Headers are padded out to a 594 multiple of 4 bytes as per Section 2.2 of [RFC8300]. The "MAC and 595 Encrypted Metadata" Context Header, if included, MUST always be the 596 last Context Header. 598 5.1. MAC#1 Context Header 600 MAC#1 Context Header is a variable-length Context Header that carries 601 the Message Authentication Code (MAC) for the Service Path Header, 602 Context Headers, and the inner packet on which NSH is imposed, 603 calculated using MAC_KEY, and optionally Context Headers encrypted 604 using ENC_KEY. The scope of the integrity protection provided by 605 this Context Header is depicted in Figure 5. 607 This MAC scheme does not require sharing MAC_KEY with SFFs. It does 608 not require to re-compute the MAC by each SFF because of TTL 609 processing. Section 9.1 discusses the possible threat associated 610 with this level of assurance. 612 0 1 2 3 613 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 614 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 615 |Ver|O|U| TTL | Length |U|U|U|U|MD Type| Next Protocol | 616 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<--+ 617 | Service Path Identifier | Service Index | | 618 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 619 ~ Variable-Length Unencrypted Context Headers (opt.) ~ | 620 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 621 | Metadata Class | Type |U| Length | | 622 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 623 | Key Id Len | Key Identifier (Variable) ~ | 624 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 625 ~ Timestamp (8 bytes) ~ | 626 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 627 | Nonce Length | Nonce (Variable) ~ | 628 +->+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 629 | ~ Encrypted Context Headers (opt.) ~ | 630 +->+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 631 | ~ Message Authentication Code ~ | 632 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 633 | | | | 634 | ~ Inner Packet on which NSH is imposed ~ | 635 | | | | 636 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<--| 637 | | 638 | Integrity Protection Scope ----+ 639 +----Encrypted Data 641 Figure 5: Scope of MAC#1 643 In reference to Figure 4, the description of the fields is as 644 follows: 646 Metadata Class: MUST be set to 0x0 (Section 2.5.1 of [RFC8300]). 648 Type: TBD1 (See Section 10) 650 U: Unassigned bit (Section 2.5.1 of [RFC8300]). 652 Length: Indicates the length of the variable-length metadata, in 653 bytes. Padding considerations are discussed in Section 2.5.1 of 654 [RFC8300]. 656 Key Id Len: Variable. Carries the length of the key identifier, in 657 octets. 659 Key Identifier: Carries a variable-length Key Identifier object used 660 to identify and deliver keys to SFC data plane elements. This 661 identifier is helpful to accommodate deployments relying upon 662 keying material per SFC/SFP. The key identifier helps in 663 resolving the problem of synchronization of keying material. A 664 single key identifier is used to lookup both the ENC_KEY and the 665 MAC_KEY associated with a key. 667 Timestamp: Refer to Section 6 for more details about the structure 668 of this field. 670 Nonce Length: Carries the length of the Nonce. If the Context 671 Headers are only integrity protected, "Nonce Length" is set to 672 zero (that is, no "Nonce" is included). The "Nonce Length" can be 673 set to zero depending on the encryption algorithm used to encrypt 674 the Context Headers. 676 Nonce: Carries the Nonce for the authentication encryption operation 677 (Section 3.1 of [RFC5116]). 679 Encrypted Context Headers: Carries the optional encrypted Context 680 Headers. 682 Message Authentication Code: Covers the entire NSH data, excluding 683 the Base header. 685 5.2. MAC#2 Context Header 687 MAC#2 Context Header is a variable-length Context Header that carries 688 the MAC for the entire NSH data calculated using MAC_KEY and 689 optionally Context Headers encrypted using ENC_KEY. The scope of the 690 integrity protection provided by this Context Header is depicted in 691 Figure 6. 693 0 1 2 3 694 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 695 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<--+ 696 |Ver|O|U| TTL | Length |U|U|U|U|MD Type| Next Protocol | | 697 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 698 | Service Path Identifier | Service Index | | 699 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 700 ~ Variable-Length Unencrypted Context Headers (opt.) ~ | 701 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 702 | Metadata Class | Type |U| Length | | 703 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 704 | Key Id Len | Key Identifier (Variable) ~ | 705 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 706 ~ Timestamp (8 bytes) ~ | 707 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 708 | Nonce Length | Nonce (Variable) ~ | 709 +->+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 710 | ~ Encrypted Context Headers (opt.) ~ | 711 +->+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 712 | ~ Message Authentication Code ~ | 713 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 714 | | | | 715 | ~ Inner Packet on which NSH is imposed ~ | 716 | | | | 717 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<--| 718 | | 719 | Integrity Protection Scope ----+ 720 +----Encrypted Data 722 Figure 6: Scope of MAC#2 724 In reference to Figure 4, the description of the fields is as 725 follows: 727 Metadata Class: MUST be set to 0x0 (Section 2.5.1 of [RFC8300]). 729 Type: TBD2 (See Section 10) 731 U: Unassigned bit (Section 2.5.1 of [RFC8300]). 733 Length: Indicates the length of the variable-length metadata, in 734 bytes. Padding considerations are discussed in Section 2.5.1 of 735 [RFC8300]. 737 Key Id Len: See Section 5.1. 739 Key Identifier: See Section 5.1. 741 Timestamp: See Section 6. 743 Nonce Length: See Section 5.1. 745 Nonce: See Section 5.1. 747 Encrypted Context Headers: Carries the optional encrypted Context 748 Headers. 750 Message Authentication Code: Covers the entire NSH data. 752 6. Timestamp Format 754 This section follows the template provided in Section 3 of [RFC8877]. 756 The format of the Timestamp field introduced in Section 5 is depicted 757 in Figure 7. 759 0 1 2 3 760 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 761 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 762 | Seconds | 763 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 764 | Fraction | 765 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 767 Figure 7: Timestamp Field Format 769 Timestamp field format: 771 Seconds: specifies the integer portion of the number of seconds 772 since the epoch. 774 + Size: 32 bits. 776 + Units: seconds. 778 Fraction: specifies the fractional portion of the number of 779 seconds since the epoch. 781 + Size: 32 bits. 783 + Units: the unit is 2^(-32) seconds, which is roughly equal to 784 233 picoseconds. 786 Epoch: 788 The epoch is 1970-01-01T00:00 in UTC time. Note this epoch value 789 is different from the one used in Section 6 of [RFC5905] 790 (wraparound 2036). 792 Leap seconds: 794 This timestamp format is affected by leap seconds. The timestamp 795 represents the number of seconds elapsed since the epoch minus the 796 number of leap seconds. 798 Resolution: 800 The resolution is 2^(-32) seconds. 802 Wraparound: 804 This time format wraps around every 2^32 seconds, which is roughly 805 136 years. The next wraparound will occur in the year 2106. 807 Synchronization aspects: 809 It is assumed that SFC data plane elements are synchronized to UTC 810 using a synchronization mechanism that is outside the scope of 811 this document. In typical deployments, SFC data plane elements 812 use NTP [RFC5905] for synchronization. Thus, the timestamp may be 813 derived from the NTP-synchronized clock, allowing the timestamp to 814 be measured with respect to the clock of an NTP server. Since the 815 NTP time format is affected by leap seconds, the current timestamp 816 format is similarly affected. Therefore, the value of a timestamp 817 during or slightly after a leap second may be temporarily 818 inaccurate. 820 7. Processing Rules 822 The following subsections describe the processing rules for integrity 823 protected NSH and optionally encrypted Context Headers. 825 7.1. Generic Behavior 827 This document adheres to the recommendations in Section 8.1 of 828 [RFC8300] for handling the Context Headers at both ingress and egress 829 SFC boundary nodes (i.e., to strip the entire NSH, including Context 830 Headers). 832 Failures of a classifier to inject the Context Headers defined in 833 this document SHOULD be logged locally while a notification alarm MAY 834 be sent to an SFC control element. Failures of an NSH-aware node to 835 validate the integrity of the NSH data MUST cause that packet to be 836 discarded while a notification alarm MAY be sent to an SFC control 837 element. The details of sending notification alarms (i.e., the 838 parameters that affect the transmission of the notification alarms 839 depending on the information in the context header such as frequency, 840 thresholds, and content in the alarm) SHOULD be configurable. 842 NSH-aware SFs and SFC proxies MAY be instructed to strip some 843 encrypted Context Headers from the packet or to pass the data to the 844 next SF in the service function chain after processing the content of 845 the Context Headers. If no instruction is provided, the default 846 behavior for intermediary NSH-aware nodes is to maintain such Context 847 Headers so that the information can be passed to next NSH-aware hops. 848 NSH-aware SFs and SFC proxies MUST re-apply the integrity protection 849 if any modification is made to the Context Headers (e.g., strip a 850 Context Header, update the content of an existing Context Header, 851 insert a new Context Header). 853 An NSH-aware SF or SFC Proxy that is not allowed to decrypt any 854 Context Headers MUST NOT be given access to the ENC_KEY. 856 Otherwise, an NSH-aware SF or SFC Proxy that receives encrypted 857 Context Headers, for which it is not allowed to consume a specific 858 Context Header it decrypts (but consumes others), MUST keep that 859 Context Header unaltered when forwarding the packet upstream. 861 Only one instance of "MAC and Encrypted Metadata" Context Header 862 (Section 5) is allowed in an NSH level. If multiple instances of 863 "MAC and Encrypted Metadata" Context Header are included in an NSH 864 level, the SFC data plane element MUST process the first instance and 865 ignore subsequent instances, and MAY log or increase a counter for 866 this event as per Section 2.5.1 of [RFC8300]. If NSH-in-NSH is used 867 (Section 4.6), distinct LoAs may be used for each NSH level. 869 MTU and fragmentation considerations are discussed in Section 8. 871 7.2. MAC NSH Data Generation 873 If the Context Headers are not encrypted, the HMAC algorithm 874 discussed in [RFC4868] is used to integrity protect the target NSH 875 data. An NSH imposer inserts a "MAC and Encrypted Metadata" Context 876 Header for integrity protection (Section 5). 878 The NSH imposer sets the MAC field to zero and then computes the 879 message integrity for the target NSH data (depending on the integrity 880 protection scope discussed in Section 5) using MAC_KEY and HMAC 881 algorithm. It inserts the computed digest in the MAC field of the 882 "MAC and Encrypted Metadata" Context Header. The length of the MAC 883 is decided by the HMAC algorithm adopted for the particular key 884 identifier. 886 The Message Authentication Code (T) computation process for the 887 target NSH data with HMAC-SHA-256-128() can be illustrated as 888 follows: 890 T = HMAC-SHA-256-128(MAC_KEY, target NSH data) 892 An entity in the SFP that updates the NSH MUST follow the above 893 behavior to maintain message integrity of the NSH for subsequent 894 validations. 896 7.3. Encrypted NSH Metadata Generation 898 An NSH imposer can encrypt Context Headers carrying sensitive 899 metadata, i.e., encrypted and unencrypted metadata may be carried 900 simultaneously in the same NSH packet (Sections 5 and 6). 902 In order to prevent pervasive monitoring [RFC7258], it is RECOMMENDED 903 to encrypt all Context Headers. All Context Headers carrying 904 privacy-sensitive metadata MUST be encrypted; doing so, privacy- 905 sensitive metadata is not revealed to attackers. Privacy specific 906 threats are discussed in Section 5.2 of [RFC6973]. 908 Using the secret key (ENC_KEY) and authenticated encryption 909 algorithm, the NSH imposer encrypts the Context Headers (as set, for 910 example, in Section 3) and inserts the resulting payload in the "MAC 911 and Encrypted Metadata" Context Header (Section 5). The entire 912 Context Header carrying a sensitive metadata is encrypted (that is, 913 including the MD Class, Type, Length, and associated metadata of each 914 Context Header). 916 More details about the exact encryption procedure are provided in 917 Section 2.1 of [RFC5116]. In this case, the associated data (A) 918 input is zero for AES-GCM. 920 An authorized entity in the SFP that updates the content of an 921 encrypted Context Header or needs to add a new encrypted Context 922 Header MUST also follow the aforementioned behavior. 924 7.4. Timestamp for Replay Attack Prevention 926 The Timestamp imposed by an initial Classifier is left untouched 927 along an SFP. However, it can be updated when reclassification 928 occurs (Section 4.8 of [RFC7665]). The same considerations for 929 setting the Timestamp are followed in both initial classification and 930 reclassification (Section 6). 932 The received NSH is accepted by an NSH-aware node if the Timestamp 933 (TS) in the NSH is recent enough to the reception time of the NSH 934 (TSrt). The following formula is used for this check: 936 -Delta < (TSrt - TS) < +Delta 938 The Delta interval is a configurable parameter. The default value 939 for the allowed Delta is 2 seconds. Special care should be taken 940 when setting very low Delta values as this may lead to dropping 941 legitimate traffic. If the timestamp is not within the boundaries, 942 then the SFC data plane element receiving such packet MUST discard 943 the NSH message. 945 Replay attacks within the Delta window may be detected by an NSH- 946 aware node by recording a unique value derived, for example, to 947 record a unique value derived from the MAC field value. Such an NSH- 948 aware node will detect and reject duplicates. If for legitimate 949 service reasons, some flows have to be duplicated but still share 950 portion of an SFP with the original flow, legitimate duplicate 951 packets will be tagged by NSH-aware nodes involved in that segment as 952 replay packets unless sufficient entropy is added to the duplicate 953 packet. How such an entropy is added is implementation-specific. 955 Note: Within the timestamp delta window, defining a sequence 956 number to protect against replay attacks may be considered. In 957 such mode, NSH-aware nodes must discard packets with duplicate 958 sequence numbers within the timestamp delta window. However, in 959 deployments with several instances of the same SF (e.g., cluster 960 or load-balanced SFs), a mechanism to coordinate among those 961 instances to discard duplicate sequence numbers is required. 962 Because the coordination mechanism to comply with this requirement 963 is service-specific, this document does not include this 964 protection. 966 All SFC data plane elements must be synchronized among themselves. 967 These elements may be synchronized to a global reference time. 969 7.5. NSH Data Validation 971 When an SFC data plane element conforms to this specification, it 972 MUST ensure that a "MAC and Encrypted Metadata" Context Header is 973 included in a received NSH packet. The imposer MUST silently discard 974 the packet and MUST log an error at least once per the SPI if at 975 least one of the following is observed: 977 o the "MAC and Encrypted Metadata" Context Header is missing, 978 o the enclosed key identifier is unknown or invalid (e.g., the 979 corresponding key expired), 981 o the timestamp is invalid (Section 7.4). 983 If the timestamp check is successfully passed, the SFC data plane 984 element proceeds with NSH data integrity validation. After storing 985 the value of the MAC field in the "MAC and Encrypted Metadata" 986 Context Header, the SFC data plane element fills the MAC field with 987 zeros. Then, the SFC data plane element generates the message 988 integrity for the target NSH data (depending on the integrity 989 protection scope discussed in Section 5) using MAC_KEY and HMAC 990 algorithm. If the value of the newly generated digest is identical 991 to the stored one, the SFC data plane element is certain that the NSH 992 data has not been tampered and validation is therefore successful. 993 Otherwise, the NSH packet MUST be discarded. The comparison of the 994 computed HMAC value to the stored value MUST be done in a constant- 995 time manner to thwart timing attacks. 997 7.6. Decryption of NSH Metadata 999 If entitled to consume a supplied encrypted Context Header, an NSH- 1000 aware SF or SFC Proxy decrypts metadata using (K) and decryption 1001 algorithm for the key identifier in the NSH. 1003 Authenticated encryption algorithm has only a single output, either a 1004 plaintext or a special symbol (FAIL) that indicates that the inputs 1005 are not authentic (Section 2.2 of [RFC5116]). 1007 8. MTU Considerations 1009 The SFC architecture prescribes that additional information be added 1010 to packets to: 1012 o Identify SFPs: this is typically the NSH Base Header and Service 1013 Path Header. 1015 o Carry metadata such as those defined in Section 5. 1017 o Steer the traffic along the SFPs: transport encapsulation. 1019 This added information increases the size of the packet to be carried 1020 along an SFP. 1022 Aligned with Section 5 of [RFC8300], it is RECOMMENDED for network 1023 operators to increase the underlying MTU so that NSH traffic is 1024 forwarded within an SFC-enabled domain without fragmentation. The 1025 available underlying MTU should be taken into account by network 1026 operators when providing SFs with the required Context Headers to be 1027 injected per SFP and the size of the data to be carried in these 1028 Context Headers. 1030 If the underlying MTU cannot be increased to accommodate the NSH 1031 overhead, network operators may rely upon a transport encapsulation 1032 protocol with the required fragmentation handling. The impact of 1033 activating such feature on SFFs should be carefully assessed by 1034 network operators (Section 5.6 of [RFC7665]). 1036 When dealing with MTU issues, network operators should consider the 1037 limitations of various transport encapsulations such as those 1038 discussed in [I-D.ietf-intarea-tunnels]. 1040 9. Security Considerations 1042 Data plane SFC-related security considerations, including privacy, 1043 are discussed in Section 6 of [RFC7665] and Section 8 of [RFC8300]. 1044 In particular, Section 8.2.2 of [RFC8300] states that attached 1045 metadata (i.e., Context Headers) should be limited to that necessary 1046 for correct operation of the SFP. Also, that section indicates that 1047 [RFC8165] discusses metadata considerations that operators can take 1048 into account when using NSH. 1050 The guidelines for cryptographic key management are discussed in 1051 [RFC4107]. The group key management protocol related security 1052 considerations discussed in Section 8 of [RFC4046] needs to be taken 1053 into consideration. 1055 The interaction between the SFC data plane elements and a key 1056 management system MUST NOT be transmitted in clear since this would 1057 completely destroy the security benefits of the integrity protection 1058 solution defined in this document. 1060 The secret key (K) must have an expiration time assigned as the 1061 latest point in time before which the key may be used for integrity 1062 protection of NSH data and encryption of Context Headers. Prior to 1063 the expiration of the secret key, all participating NSH-aware nodes 1064 SHOULD have the control plane distribute a new key identifier and 1065 associated keying material so that when the secret key is expired, 1066 those nodes are prepared with the new secret key. This allows the 1067 NSH imposer to switch to the new key identifier as soon as necessary. 1068 It is RECOMMENDED that the next key identifier and associated keying 1069 material be distributed by the control plane well prior to the secret 1070 key expiration time. 1072 The security and integrity of the key-distribution mechanism is vital 1073 to the security of the SFC system as a whole. 1075 NSH data are exposed to several threats: 1077 o A on-path attacker modifying the NSH data. 1079 o Attacker spoofing the NSH data. 1081 o Attacker capturing and replaying the NSH data. 1083 o Data carried in Context Headers revealing privacy-sensitive 1084 information to attackers. 1086 o Attacker replacing the packet on which the NSH is imposed with a 1087 modified or bogus packet. 1089 In an SFC-enabled domain where the above attacks are possible, (1) 1090 NSH data MUST be integrity-protected and replay-protected, and (2) 1091 privacy-sensitive NSH metadata MUST be encrypted for confidentiality 1092 preservation purposes. The Base and Service Path headers are not 1093 encrypted. 1095 MACs with two levels of assurance are defined in Section 5. 1096 Considerations specific to each level of assurance are discussed in 1097 Sections 9.1 and 9.2. 1099 The attacks discussed in [I-D.nguyen-sfc-security-architecture] are 1100 handled owing to the solution specified in this document, except for 1101 attacks dropping packets. Such attacks can be detected relying upon 1102 statistical analysis; such analysis is out of the scope of this 1103 document. Also, if SFFs are not involved in the integrity checks, a 1104 misbehaving SFF which decrements SI while this should be done by an 1105 SF (SF bypass attack) will be detected by an upstream SF because the 1106 integrity check will fail. 1108 Some events are logged locally with notification alerts sent by NSH- 1109 aware nodes to a Control Element. These events SHOULD be rate- 1110 limited. 1112 The solution specified in this document does not provide data origin 1113 authentication. 1115 In order to detect compromised nodes, it is assumed that appropriate 1116 mechanisms to monitor and audit an SFC-enabled domain to detect 1117 misbehavior and to deter misuse are in place. Compromised nodes can 1118 thus be withdrawn from active service function chains using 1119 appropriate control plane mechanisms. 1121 9.1. MAC#1 1123 An active attacker can potentially modify the Base header (e.g., 1124 decrement the TTL so the next SFF in the SFP discards the NSH 1125 packet). An active attacker can also drop NSH packets. As such, 1126 this attack is not considered an attack against the security 1127 mechanism specified in the document. 1129 It is expected that specific devices in the SFC-enabled domain will 1130 be configured such that no device other than the classifiers (when 1131 reclassification is enabled), NSH-aware SFs, and SFC proxies will be 1132 able to update the integrity protected NSH data (Section 7.1), and 1133 also such that no device other than the NSH-aware SFs and SFC proxies 1134 will be able to decrypt and update the Context Headers carrying 1135 sensitive metadata (Section 7.1). In other words, if the NSH-aware 1136 SFs and SFC proxies in the SFC-enabled domain are considered fully 1137 trusted to act on the NSH data, only these elements can have access 1138 to sensitive NSH metadata and the keying material used to integrity 1139 protect NSH data and encrypt Context Headers. 1141 9.2. MAC#2 1143 SFFs can detect whether an illegitimate node has altered the content 1144 of the Base header. Such messages must be discarded with appropriate 1145 logs and alarms generated (see Section 7.1). 1147 Similar to Section 9.1, no device other than the NSH-aware SFs and 1148 SFC proxies in the SFC-enabled domain should be able to decrypt and 1149 update the Context Headers carrying sensitive metadata. 1151 9.3. Time Synchronization 1153 [RFC8633] describes best current practices to be considered in 1154 deployments where SFC data plane elements use NTP for time 1155 synchronization purposes. 1157 Also, a mechanism to provide cryptographic security for NTP is 1158 specified in [RFC8915]. 1160 10. IANA Considerations 1162 This document requests IANA to assign the following types from the 1163 "NSH IETF-Assigned Optional Variable-Length Metadata Types" (0x0000 1164 IETF Base NSH MD Class) registry available at: 1165 https://www.iana.org/assignments/nsh/nsh.xhtml#optional-variable- 1166 length-metadata-types. 1168 +-------+-------------------------------+----------------+ 1169 | Value | Description | Reference | 1170 +=======+===============================+================+ 1171 | TBD1 | MAC and Encrypted Metadata #1 | [ThisDocument] | 1172 | TBD2 | MAC and Encrypted Metadata #2 | [ThisDocument] | 1173 +-------+-------------------------------+----------------+ 1175 11. Acknowledgements 1177 This document was edited as a follow-up to the discussion in 1178 IETF#104: https://datatracker.ietf.org/meeting/104/materials/slides- 1179 104-sfc-sfc-chair-slides-01 (slide 7). 1181 Thanks to Joel Halpern, Christian Jacquenet, Dirk von Hugo, Tal 1182 Mizrahi, Daniel Migault, Diego Lopez, Greg Mirsky, and Dhruv Dhody 1183 for the comments. 1185 Many thanks to Steve Hanna for the valuable secdir review and Juergen 1186 Schoenwaelder for the opsdir review. 1188 Thanks to Greg Mirsky for the Shepherd review. 1190 Thanks to Alvaro Retana, Lars Eggert, Martin Duke, Erik Kline, 1191 Zaheduzzaman Sarker, Eric Vyncke, Roman Danyliw, Murray Kucherawy, 1192 John Scudder, and Benjamin Kaduk for the IESG review. 1194 12. References 1196 12.1. Normative References 1198 [GCM] Dworkin, M., "Recommendation for Block Cipher Modes of 1199 Operation: Galois/Counter Mode (GCM) and GMAC", 1200 NIST Special Publication 800-38D, November 2007. 1202 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 1203 Hashing for Message Authentication", RFC 2104, 1204 DOI 10.17487/RFC2104, February 1997, 1205 . 1207 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1208 Requirement Levels", BCP 14, RFC 2119, 1209 DOI 10.17487/RFC2119, March 1997, 1210 . 1212 [RFC4107] Bellovin, S. and R. Housley, "Guidelines for Cryptographic 1213 Key Management", BCP 107, RFC 4107, DOI 10.17487/RFC4107, 1214 June 2005, . 1216 [RFC4868] Kelly, S. and S. Frankel, "Using HMAC-SHA-256, HMAC-SHA- 1217 384, and HMAC-SHA-512 with IPsec", RFC 4868, 1218 DOI 10.17487/RFC4868, May 2007, 1219 . 1221 [RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated 1222 Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008, 1223 . 1225 [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function 1226 Chaining (SFC) Architecture", RFC 7665, 1227 DOI 10.17487/RFC7665, October 2015, 1228 . 1230 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1231 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1232 May 2017, . 1234 [RFC8300] Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed., 1235 "Network Service Header (NSH)", RFC 8300, 1236 DOI 10.17487/RFC8300, January 2018, 1237 . 1239 12.2. Informative References 1241 [I-D.arkko-farrell-arch-model-t] 1242 Arkko, J. and S. Farrell, "Challenges and Changes in the 1243 Internet Threat Model", draft-arkko-farrell-arch-model- 1244 t-04 (work in progress), July 2020. 1246 [I-D.ietf-intarea-tunnels] 1247 Touch, J. and M. Townsley, "IP Tunnels in the Internet 1248 Architecture", draft-ietf-intarea-tunnels-10 (work in 1249 progress), September 2019. 1251 [I-D.nguyen-sfc-security-architecture] 1252 THANG, N. C. and M. Park, "A Security Architecture Against 1253 Service Function Chaining Threats", draft-nguyen-sfc- 1254 security-architecture-00 (work in progress), November 1255 2019. 1257 [RFC4046] Baugher, M., Canetti, R., Dondeti, L., and F. Lindholm, 1258 "Multicast Security (MSEC) Group Key Management 1259 Architecture", RFC 4046, DOI 10.17487/RFC4046, April 2005, 1260 . 1262 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, 1263 "Network Time Protocol Version 4: Protocol and Algorithms 1264 Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, 1265 . 1267 [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., 1268 Morris, J., Hansen, M., and R. Smith, "Privacy 1269 Considerations for Internet Protocols", RFC 6973, 1270 DOI 10.17487/RFC6973, July 2013, 1271 . 1273 [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an 1274 Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 1275 2014, . 1277 [RFC7498] Quinn, P., Ed. and T. Nadeau, Ed., "Problem Statement for 1278 Service Function Chaining", RFC 7498, 1279 DOI 10.17487/RFC7498, April 2015, 1280 . 1282 [RFC7635] Reddy, T., Patil, P., Ravindranath, R., and J. Uberti, 1283 "Session Traversal Utilities for NAT (STUN) Extension for 1284 Third-Party Authorization", RFC 7635, 1285 DOI 10.17487/RFC7635, August 2015, 1286 . 1288 [RFC8165] Hardie, T., "Design Considerations for Metadata 1289 Insertion", RFC 8165, DOI 10.17487/RFC8165, May 2017, 1290 . 1292 [RFC8459] Dolson, D., Homma, S., Lopez, D., and M. Boucadair, 1293 "Hierarchical Service Function Chaining (hSFC)", RFC 8459, 1294 DOI 10.17487/RFC8459, September 2018, 1295 . 1297 [RFC8633] Reilly, D., Stenn, H., and D. Sibold, "Network Time 1298 Protocol Best Current Practices", BCP 223, RFC 8633, 1299 DOI 10.17487/RFC8633, July 2019, 1300 . 1302 [RFC8877] Mizrahi, T., Fabini, J., and A. Morton, "Guidelines for 1303 Defining Packet Timestamps", RFC 8877, 1304 DOI 10.17487/RFC8877, September 2020, 1305 . 1307 [RFC8915] Franke, D., Sibold, D., Teichel, K., Dansarie, M., and R. 1308 Sundblad, "Network Time Security for the Network Time 1309 Protocol", RFC 8915, DOI 10.17487/RFC8915, September 2020, 1310 . 1312 Authors' Addresses 1314 Mohamed Boucadair 1315 Orange 1316 Rennes 35000 1317 France 1319 Email: mohamed.boucadair@orange.com 1321 Tirumaleswar Reddy 1322 McAfee, Inc. 1323 Embassy Golf Link Business Park 1324 Bangalore, Karnataka 560071 1325 India 1327 Email: kondtir@gmail.com 1329 Dan Wing 1330 Citrix Systems, Inc. 1331 USA 1333 Email: dwing-ietf@fuggles.com