idnits 2.17.1 draft-ietf-sfc-nsh-integrity-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 1, 2021) is 1023 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 1143, but not defined ** Downref: Normative reference to an Informational RFC: RFC 7665 == Outdated reference: A later version (-13) exists of draft-ietf-intarea-tunnels-10 Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). 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 2, 2022 McAfee 6 D. Wing 7 Citrix 8 July 1, 2021 10 Integrity Protection for the Network Service Header (NSH) and Encryption 11 of Sensitive Context Headers 12 draft-ietf-sfc-nsh-integrity-06 14 Abstract 16 This specification adds integrity protection directly to the Network 17 Service Header (NSH) used for Service Function Chaining (SFC). Also, 18 this specification allows to encrypt sensitive metadata that is 19 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 2, 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 . . . . . . . . . . . . . 4 58 4. Design Overview . . . . . . . . . . . . . . . . . . . . . . . 6 59 4.1. Supported Security Services . . . . . . . . . . . . . . . 6 60 4.1.1. Encrypt All or a Subset of Context Headers . . . . . 6 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 . . . . . . . . . . . . . . . . . . . . . 10 66 4.5. New NSH Variable-Length Context Headers . . . . . . . . . 11 67 4.6. Encapsulation of NSH within NSH . . . . . . . . . . . . . 11 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 . . . . . . . . . . . . . . . 21 77 7.5. NSH Data Validation . . . . . . . . . . . . . . . . . . . 22 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 . . . . . . . . . . . . . . . . . . . . . . . 28 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 master their 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 [RFC8300], forcing a 116 service topology that requires security and privacy to use a 117 transport encapsulation that supports such features. Note that some 118 transport encapsulations (e.g., IPsec) only provide hop-by-hop 119 security between two SFC data plane elements (e.g., two Service 120 Function Forwarders (SFFs), SFF to SF) and do not provide SF-to-SF 121 security of NSH metadata. For example, if IPsec is used, SFFs or SFs 122 within a Service Function Path (SFP) that are not authorized to 123 access the privacy-sensitive metadata will have access to the 124 metadata. As a reminder, the metadata referred to is an 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. Concretely, this document adds 135 integrity protection and optional encryption of sensitive metadata 136 directly to the NSH (Section 4); integrity protects the packet 137 payload and provides replay protection (Section 7.4). Thus, the NSH 138 does not have to rely upon an underlying transport encapsulation for 139 security and confidentiality. 141 This specification introduces new Variable-Length Context Headers to 142 carry fields necessary for integrity-protected NSH headers and 143 encrypted Context Headers (Section 5). This specification is only 144 applicable to NSH MD Type 0x02 (Section 2.5 of [RFC8300]). MTU 145 considerations are discussed in Section 8. 147 This specification limits thus access to NSH-supplied information 148 along an SFP to entities that have a need to interpret it. 150 It is out of the scope of this document to specify an NSH-aware 151 control plane solution. 153 2. Terminology 155 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 156 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 157 "OPTIONAL" in this document are to be interpreted as described in BCP 158 14 [RFC2119] [RFC8174] when, and only when, they appear in all 159 capitals, as shown here. 161 This document makes use of the terms defined in [RFC7665] and 162 [RFC8300]. 164 The document defines the following terms: 166 SFC data plane element: Refers to NSH-aware SF, SFF, SFC Proxy, or 167 Classifier as defined in the SFC data plane architecture [RFC7665] 168 and further refined in [RFC8300]. 170 SFC control element: Is a logical entity that instructs one or more 171 SFC data plane elements on how to process NSH packets within an 172 SFC-enabled domain. 174 Key Identifier: Is used to identify and deliver keys to authorized 175 entities. See, for example, 'kid' usage in [RFC7635]. 177 NSH data: The NSH is composed of a Base Header, a Service Path 178 Header, and optional Context Headers. NSH data refers to all the 179 above headers and the packet or frame on which the NSH is imposed 180 to realize an SFP. 182 NSH imposer: Refers to an SFC data plane element that is entitled to 183 impose the NSH with the Context Headers defined in this document. 185 3. Assumptions and Basic Requirements 187 Section 2 of [RFC8300] specifies that the NSH data can be spread over 188 three headers: 190 o Base Header: Provides information about the service header and the 191 payload protocol. 193 o Service Path Header: Provides path identification and location 194 within an SFP. 196 o Context Header(s): Carries metadata (i.e., context data) along a 197 service path. 199 The NSH allows to share context information (a.k.a., metadata) with 200 downstream NSH-aware data plane elements on a per SFC/SFP basis. To 201 that aim: 203 The Classifier is instructed about the set of context information 204 to be supplied for a given service function chain. 206 An NSH-aware SF is instructed about any metadata it needs to 207 attach to packets for a given service function chain. This 208 instruction may occur any time during the validity lifetime of an 209 SFC/SFP. For a given service function chain, the NSH-aware SF is 210 also provided with an order for consuming a set of contexts 211 supplied in a packet. 213 An NSH-aware SF can also be instructed about the behavior it 214 should adopt after consuming context information that was supplied 215 in the NSH. For example, the context information can be 216 maintained, updated, or stripped. 218 An SFC Proxy may be instructed about the behavior it should adopt 219 to process the context information that was supplied in the NSH on 220 behalf of an NSH-unaware SF (e.g., the context information can be 221 maintained or stripped). The SFC Proxy may also be instructed to 222 add some new context information into the NSH on behalf of an NSH- 223 unaware SF. 225 In reference to Figure 1, 227 o Classifiers, NSH-aware SFs, and SFC proxies are entitled to update 228 the Context Header(s). 230 o Only NSH-aware SFs and SFC proxies are entitled to update the 231 Service Path Header. 233 o SFFs are entitled to modify the Base Header (TTL value, for 234 example). Nevertheless, SFFs are not supposed to act on the 235 Context Headers or look into the content of the Context Headers. 237 Thus, the following requirements: 239 o Only Classifiers, NSH-aware SFs, and SFC proxies MUST be able to 240 encrypt and decrypt a given Context Header. 242 o Both encrypted and unencrypted Context Headers MAY be included in 243 the same NSH. That is, some Context Headers may be protected 244 while others do not need to be protected. 246 o The solution MUST provide integrity protection for the Service 247 Path Header. 249 o The solution MAY provide integrity protection for the Base Header. 250 The implications of disabling such checks are discussed in 251 Section 9.1. 253 +----------------+-----------------------------+-------------------+ 254 | | Insert, remove, or replace | Update the NSH | 255 | | the NSH | | 256 | | | | 257 | SFC Data Plane +---------+---------+---------+---------+---------+ 258 | Element | | | |Decrement| Update | 259 | | Insert | Remove | Replace | Service | Context | 260 | | | | | Index |Header(s)| 261 +================+=========+=========+=========+=========+=========+ 262 | | + | | + | | + | 263 | Classifier | | | | | | 264 +----------------+---------+---------+---------+---------+---------+ 265 |Service Function| | + | | | | 266 |Forwarder (SFF) | | | | | | 267 +----------------+---------+---------+---------+---------+---------+ 268 |Service Function| | | | + | + | 269 | (SF) | | | | | | 270 +----------------+---------+---------+---------+---------+---------+ 271 | | + | + | | + | + | 272 | SFC Proxy | | | | | | 273 +----------------+---------+---------+---------+---------+---------+ 275 Figure 1: Summary of NSH Actions 277 4. Design Overview 279 4.1. Supported Security Services 281 This specification provides the functions described in the following 282 subsections. 284 4.1.1. Encrypt All or a Subset of Context Headers 286 The solution allows to encrypt all or a subset of NSH Context Headers 287 by Classifiers, NSH-aware SFs, and SFC proxies. 289 As depicted in Table 1, SFFs are not involved in data encryption. 291 +-----------------+------------------------------+------------------+ 292 | Data Plane | Base and Service Headers | Metadata | 293 | Element | Encryption | Encryption | 294 +-----------------+------------------------------+------------------+ 295 | Classifier | No | Yes | 296 | SFF | No | No | 297 | NSH-aware SF | No | Yes | 298 | SFC Proxy | No | Yes | 299 | NSH-unaware SF | No | No | 300 +-----------------+------------------------------+------------------+ 302 Table 1: Encryption Function Supported by SFC Data Plane Elements 304 Classifier(s), NSH-aware SFs, and SFC proxies are instructed with the 305 set of Context Headers (privacy-sensitive metadata, typically) that 306 must be encrypted. Encryption keying material is only provided to 307 these SFC data plane elements. 309 The control plane may indicate the set of SFC data plane elements 310 that are entitled to supply a given Context Header (e.g., in 311 reference to their identifiers as assigned within the SFC-enabled 312 domain). It is out of the scope of this document to elaborate on how 313 such instructions are provided to the appropriate SFC data plane 314 elements, nor to detail the structure used to store the instructions. 316 The Service Path Header (Section 2 of [RFC8300]) is not encrypted 317 because SFFs use Service Index (SI) in conjunction with Service Path 318 Identifier (SPI) for determining the next SF in the path. 320 4.1.2. Integrity Protection 322 The solution provides integrity protection for the NSH data. Two 323 levels of assurance (LoAs) are supported. 325 The first level of assurance where all NSH data except the Base 326 Header are integrity protected (Figure 2). In this case, the NSH 327 imposer may be a Classifier, an NSH-aware SF, or an SFC Proxy. SFFs 328 are not thus provided with authentication material. Further details 329 are discussed in Section 5.1. 331 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 332 | Transport Encapsulation | 333 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+... 334 | Base Header | | 335 +->+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ N 336 | | Service Path Header | S 337 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ H 338 | | Context Header(s) | | 339 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+... 340 | | Original Packet | 341 +->+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 342 | 343 +------Scope of integrity protected data 345 Figure 2: First Level of Assurance 347 The second level of assurance where all NSH data, including the Base 348 Header, are integrity protected (Figure 3). In this case, the NSH 349 imposer may be a Classifier, an NSH-aware SF, an SFF, or an SFC 350 Proxy. Further details are provided in Section 5.2. 352 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 353 | Transport Encapsulation | 354 +->+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+... 355 | | Base Header | | 356 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ N 357 | | Service Path Header | S 358 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ H 359 | | Context Header(s) | | 360 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+... 361 | | Original Packet | 362 +->+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 363 | 364 +----Scope of integrity protected data 366 Figure 3: Second Level of Assurance 368 The integrity protection scope is explicitly signaled to NSH-aware 369 SFs and SFC proxies in the NSH by means of a dedicated MD Type 370 (Section 5). 372 In both levels of assurance, the unencrypted Context Headers and the 373 packet on which the NSH is imposed are subject to integrity 374 protection. 376 Table 2 lists the roles of SFC data plane elements in providing 377 integrity protection for the NSH. 379 +--------------------+----------------------------------+ 380 | Data Plane Element | Integrity Protection | 381 +--------------------+----------------------------------+ 382 | Classifier | Yes | 383 | SFF | No (first LoA); Yes (second LoA) | 384 | NSH-aware SF | Yes | 385 | SFC Proxy | Yes | 386 | NSH-unaware SF | No | 387 +--------------------+----------------------------------+ 389 Table 2: Integrity Protection Supported by SFC Data Plane Elements 391 4.2. One Secret Key, Two Security Services 393 The authenticated encryption algorithm defined in [RFC7518] is used 394 to provide NSH data integrity and to encrypt the Context Headers that 395 carry privacy-sensitive metadata. 397 The authenticated encryption algorithm provides a unified encryption 398 and authentication operation which turns plaintext into authenticated 399 ciphertext and vice versa. The generation of secondary keys MAC_KEY 400 and ENC_KEY from the secret key (K) is discussed in Section 5.2.2.1 401 of [RFC7518]: 403 o The ENC_KEY is used for encrypting the Context Headers and the 404 message integrity of the NSH data is calculated using the MAC_KEY. 406 o If the Context Headers are not encrypted, the Hashed Message 407 Authentication Mode (HMAC) algorithm discussed in [RFC4868] is 408 used to protect the integrity of the NSH data. 410 The advantage of using the authenticated encryption algorithm is that 411 NSH-aware SFs and SFC proxies only need to re-compute the message 412 integrity of the NSH data after decrementing the Service Index (SI) 413 and do not have to re-compute the ciphertext. The other advantage is 414 that SFFs do not have access to the ENC_KEY and cannot act on the 415 encrypted Context Headers and, only in case of the second level of 416 assurance, SFFs do have access to the MAC_KEY. Similarly, an NSH- 417 aware SF or SFC Proxy not allowed to decrypt the Context Headers will 418 not have access to the ENC_KEY. 420 The authenticated encryption algorithm or HMAC algorithm to be used 421 by SFC data plane elements is typically controlled using the SFC 422 control plane. Mandatory to implement authenticated encryption and 423 HMAC algorithms are listed in Section 4.3. 425 The authenticated encryption process takes as input four-octet 426 strings: a secret key (K), a plaintext (P), Additional Authenticated 427 Data (A) (which contains the data to be authenticated, but not 428 encrypted), and an Initialization Vector (IV). The ciphertext value 429 (E) and the Authentication Tag value (T) are provided as outputs. 431 In order to decrypt and verify, the cipher takes as input K, IV, A, 432 T, and E. The output is either the plaintext or an error indicating 433 that the decryption failed as described in Section 5.2.2.2 of 434 [RFC7518]. 436 4.3. Mandatory-to-Implement Authenticated Encryption and HMAC 437 Algorithms 439 Classifiers, NSH-aware SFs, and SFC proxies MUST implement the 440 AES_128_CBC_HMAC_SHA_256 algorithm and SHOULD implement the 441 AES_192_CBC_HMAC_SHA_384 and AES_256_CBC_HMAC_SHA_512 algorithms. 443 Classifiers, NSH-aware SFs, and SFC proxies MUST implement the HMAC- 444 SHA-256-128 algorithm and SHOULD implement the HMAC-SHA-384-192 and 445 HMAC-SHA-512-256 algorithms. 447 SFFs MAY implement the aforementioned cipher suites and HMAC 448 algorithms. 450 Note: The use of Advanced Encryption Standard (AES) in Galois/ 451 Counter Mode (GCM) + HMAC may have CPU and packet size 452 implications (need for a second 128-bit authentication tag). 454 4.4. Key Management 456 The procedure for the allocation/provisioning of secret keys (K) and 457 authenticated encryption algorithm or MAC_KEY and HMAC algorithm is 458 outside the scope of this specification. As such, this specification 459 does not mandate the support of any specific mechanism. 461 The document does not assume nor preclude the following: 463 o The same keying material is used for all the service functions 464 used within an SFC-enabled domain. 466 o Distinct keying material is used per SFP by all involved SFC data 467 path elements. 469 o Per-tenant keys are used. 471 In order to accommodate deployments relying upon keying material per 472 SFC/SFP and also the need to update keys after encrypting NSH data 473 for a certain amount of time, this document uses key identifiers to 474 unambiguously identify the appropriate keying material. Doing so 475 allows to address the problem of synchronization of keying material. 477 Additional information on manual vs. automated key management and 478 when one should be used over the other can be found in [RFC4107]. 480 4.5. New NSH Variable-Length Context Headers 482 New NSH Variable-Length Context Headers are defined in Section 5 for 483 NSH data integrity protection and, optionally, encryption of Context 484 Headers carrying privacy-sensitive metadata. Concretely, an NSH 485 imposer includes (1) the key identifier to identify the keying 486 material, (2) the timestamp to protect against replay attacks 487 (Section 7.4), and (3) the Message Authentication Code (MAC) for the 488 target NSH data (depending on the integrity protection scope) 489 calculated using the MAC_KEY and optionally Context Headers encrypted 490 using ENC_KEY. 492 An SFC data plane element that needs to check the integrity of the 493 NSH data uses MAC_KEY and the HMAC algorithm for the key identifier 494 being carried in the NSH. 496 An NSH-aware SF or SFC Proxy that needs to decrypt some Context 497 Headers uses ENC_Key and the decryption algorithm for the key 498 identifier being carried in the NSH. 500 Section 7 specifies the detailed procedure. 502 4.6. Encapsulation of NSH within NSH 504 As discussed in [RFC8459], an SFC-enabled domain (called, upper-level 505 domain) may be decomposed into many sub-domains (called, lower-level 506 domains). In order to avoid maintaining state to restore back upper- 507 lower NSH information at the boundaries of lower-level domains, two 508 NSH levels are used: an Upper-NSH which is imposed at the boundaries 509 of the upper-level domain and a Lower-NSH that is pushed by the 510 Classifier of a lower-level domain in front of the original NSH 511 (Figure 4). As such, the Upper-NSH information is carried along the 512 lower-level chain without modification. The packet is forwarded in 513 the top-level domain according to the Upper-NSH, while it is 514 forwarded according to the Lower-NSH in a lower-level domain. 516 +---------------------------------+ 517 | Transport Encapsulation | 518 +->+---------------------------------+ 519 | | Lower-NSH Header | 520 | +---------------------------------+ 521 | | Upper-NSH Header | 522 | +---------------------------------+ 523 | | Original Packet | 524 +->+---------------------------------+ 525 | 526 | 527 +----Scope of NSH security protection 528 provided by a lower-level domain 530 Figure 4: Encapsulation of NSH within NSH 532 SFC data plane elements of a lower-level domain include the Upper-NSH 533 when computing the MAC. 535 Keying material used at the upper-level domain SHOULD NOT be the same 536 as the one used by a lower-level domain. 538 5. New NSH Variable-Length Context Headers 540 This section specifies the format of new Variable-Length Context 541 headers that are used for NSH integrity protection and, optionally, 542 Context Headers encryption. 544 In particular, this section defines two "MAC and Encrypted Metadata" 545 Context Headers; each having specific deployment constraints. Unlike 546 Section 5.1, the level of assurance provided in Section 5.2 requires 547 sharing MAC_KEY with SFFs. Both Context headers have the same format 548 as shown in Figure 5. 550 0 1 2 3 551 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 552 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 553 | Metadata Class | Type |U| Length | 554 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 555 | Key Length | Key Identifier (Variable) ~ 556 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 557 ~ Timestamp (8 bytes) ~ 558 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 559 | IV Length | Initialization Vector (Variable) ~ 560 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 561 | Message Authentication Code and optional Encrypted | 562 ~ Context Headers (Variable) ~ 563 | | 564 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 566 Figure 5: MAC and Encrypted Metadata Context Header 568 The "MAC and Encrypted Metadata" Context Headers are padded out to a 569 multiple of 4 bytes as per Section 2.2 of [RFC8300]. 571 5.1. MAC#1 Context Header 573 MAC#1 Context Header is a variable-length Context Header that carries 574 the Message Authentication Code (MAC) for the Service Path Header, 575 Context Headers, and the inner packet on which NSH is imposed, 576 calculated using MAC_KEY and optionally Context Headers encrypted 577 using ENC_KEY. The scope of the integrity protection provided by 578 this Context Header is depicted in Figure 6. 580 This MAC scheme does not require sharing MAC_KEY with SFFs. It does 581 not require to re-compute the MAC by each SFF because of TTL 582 processing. Section 9.1 discusses the possible threat associated 583 with this level of assurance. 585 0 1 2 3 586 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 587 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 588 |Ver|O|U| TTL | Length |U|U|U|U|MD Type| Next Protocol | 589 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<--+ 590 | Service Path Identifier | Service Index | | 591 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 592 ~ Variable-Length Unencrypted Context Headers (opt.) ~ | 593 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 594 | Metadata Class | Type |U| Length | | 595 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 596 | Key Length | Key Identifier (Variable) ~ | 597 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 598 ~ Timestamp (8 bytes) ~ | 599 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 600 | IV Length | Initialization Vector (Variable) ~ | 601 +->+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 602 | ~ Encrypted Context Headers (opt.) ~ | 603 +->+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 604 | ~ Message Authentication Code ~ | 605 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 606 | | | | 607 | ~ Inner Packet on which NSH is imposed ~ | 608 | | | | 609 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<--| 610 | | 611 | Integrity Protection Scope ----+ 612 +----Encrypted Data 614 Figure 6: Scope of MAC#1 616 In reference to Figure 5, the description of the fields is as 617 follows: 619 Metadata Class: MUST be set to 0x0 (Section 2.5.1 of [RFC8300]). 621 Type: TBD1 (See Section 10) 623 U: Unassigned bit (Section 2.5.1 of [RFC8300]). 625 Length: Variable. Padding considerations are discussed in 626 Section 2.5.1 of [RFC8300]. 628 Key Length: Variable. Carries the length of the key identifier. 630 Key Identifier: Carries a variable-length Key Identifier object used 631 to identify and deliver keys to SFC data plane elements. This 632 identifier is helpful to accommodate deployments relying upon 633 keying material per SFC/SFP. The key identifier helps in 634 resolving the problem of synchronization of keying material. 636 Timestamp: Carries an unsigned 64-bit integer value that is 637 expressed in seconds relative to 1970-01-01T00:00Z in UTC time. 638 See Section 6 for more details. 640 IV Length: Carries the length of the IV (Section 5.2 of [RFC7518]). 641 If encryption is not used, IV length is set to zero (that is, no 642 "Initialization Vector" is included). 644 Initialization Vector: Carries the IV for authenticated encryption 645 algorithm as discussed in Section 5.2 of [RFC7518]. 647 Encrypted Context Headers: Carries the optional encrypted Context 648 Headers. 650 Message Authentication Code: Covers the entire NSH data, excluding 651 the Base header. The Additional Authenticated Data (defined in 652 [RFC7518]) MUST be the Service Path header, the unencrypted 653 Context headers, and the inner packet on which the NSH is imposed. 655 5.2. MAC#2 Context Header 657 MAC#2 Context Header is a variable-length Context Header that carries 658 the MAC for the entire NSH data calculated using MAC_KEY and 659 optionally Context Headers encrypted using ENC_KEY. The scope of the 660 integrity protection provided by this Context Header is depicted in 661 Figure 7. 663 0 1 2 3 664 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 665 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<--+ 666 |Ver|O|U| TTL | Length |U|U|U|U|MD Type| Next Protocol | | 667 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 668 | Service Path Identifier | Service Index | | 669 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 670 ~ Variable-Length Unencrypted Context Headers (opt.) ~ | 671 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 672 | Metadata Class | Type |U| Length | | 673 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 674 | Key Length | Key Identifier (Variable) ~ | 675 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 676 ~ Timestamp (8 bytes) ~ | 677 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 678 | IV Length | Initialization Vector (Variable) ~ | 679 +->+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 680 | ~ Encrypted Context Headers (opt.) ~ | 681 +->+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 682 | ~ Message Authentication Code ~ | 683 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 684 | | | | 685 | ~ Inner Packet on which NSH is imposed ~ | 686 | | | | 687 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<--| 688 | | 689 | Integrity Protection Scope ----+ 690 +----Encrypted Data 692 Figure 7: Scope of MAC#2 694 In reference to Figure 5, the description of the fields is as 695 follows: 697 Metadata Class: MUST be set to 0x0 (Section 2.5.1 of [RFC8300]). 699 Type: TBD2 (See Section 10) 701 U: Unassigned bit (Section 2.5.1 of [RFC8300]). 703 Length: Variable. Padding considerations are discussed in 704 Section 2.5.1 of [RFC8300]. 706 Key Length: See Section 5.1. 708 Key Identifier: See Section 5.1. 710 Timestamp: See Section 6. 712 IV Length: See Section 5.1. 714 Initialization Vector: See Section 5.1. 716 Encrypted Context Headers: Carries the optional encrypted Context 717 Headers. 719 Message Authentication Code: Coves the entire NSH data. The 720 Additional Authenticated Data (defined in [RFC7518]) MUST be the 721 entire NSH data (i.e., including the Base Header) excluding the 722 Context Headers to be encrypted. 724 6. Timestamp Format 726 This section follows the template provided in Section 3 of [RFC8877]. 728 The format of the Timestamp field introduced in Section 5 is depicted 729 in Figure 8. 731 0 1 2 3 732 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 733 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 734 | Seconds | 735 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 736 | Fraction | 737 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 739 Figure 8: Timestamp Field Format 741 Timestamp field format: 743 Seconds: specifies the integer portion of the number of seconds 744 since the epoch. 746 + Size: 32 bits. 748 + Units: seconds. 750 Fraction: specifies the fractional portion of the number of 751 seconds since the epoch. 753 + Size: 32 bits. 755 + Units: the unit is 2^(-32) seconds, which is roughly equal to 756 233 picoseconds. 758 Epoch: 760 The epoch is 1970-01-01T00:00Z in UTC time. Note this epoch value 761 is different from the one used in Section 6 of [RFC5905]. 763 Leap seconds: 765 This timestamp format is affected by leap seconds. The timestamp 766 represents the number of seconds elapsed since the epoch minus the 767 number of leap seconds. 769 Resolution: 771 The resolution is 2^(-32) seconds. 773 Wraparound: 775 This time format wraps around every 2^32 seconds, which is roughly 776 136 years. The next wraparound will occur in the year 2106. 778 Synchronization aspects: 780 It is assumed that SFC data plane elements are synchronized to UTC 781 using a synchronization mechanism that is outside the scope of 782 this document. In typical deployments, SFC data plane elements 783 use NTP [RFC5905] for synchronization. Thus, the timestamp may be 784 derived from the NTP-synchronized clock, allowing the timestamp to 785 be measured with respect to the clock of an NTP server. Since the 786 NTP time format is affected by leap seconds, the current timestamp 787 format is similarly affected. Therefore, the value of a timestamp 788 during or slightly after a leap second may be temporarily 789 inaccurate. 791 7. Processing Rules 793 The following subsections describe the processing rules for integrity 794 protected NSH and optionally encrypted Context Headers. 796 7.1. Generic Behavior 798 This document adheres to the recommendations in [RFC8300] for 799 handling the Context Headers at both ingress and egress SFC boundary 800 nodes (i.e., to strip the entire NSH, including Context Headers). 802 Failures of a classifier to inject the Context Headers defined in 803 this document SHOULD be logged locally while a notification alarm MAY 804 be sent to an SFC control element. Failures of an NSH-aware node to 805 validate the integrity of the NSH data MUST cause that packet to be 806 discarded while a notification alarm MAY be sent to an SFC control 807 element. The details of sending notification alarms (i.e., the 808 parameters affecting the transmission of the notification alarms 809 depend on the information in the context header such as frequency, 810 thresholds, and content in the alarm) SHOULD be configurable. 812 NSH-aware SFs and SFC proxies MAY be instructed to strip some 813 encrypted Context Headers from the packet or to pass the data to the 814 next SF in the service function chain after processing the content of 815 the Context Headers. If no instruction is provided, the default 816 behavior for intermediary NSH-aware nodes is to maintain such Context 817 Headers so that the information can be passed to next NSH-aware hops. 818 NSH-aware SFs and SFC proxies MUST re-apply the integrity protection 819 if any modification is made to the Context Headers (strip a Context 820 Header, update the content of an existing Context Header, insert a 821 new Context Header). 823 An NSH-aware SF or SFC Proxy that is not allowed to decrypt any 824 Context Headers MUST NOT be given access to the ENC_KEY. 826 Otherwise, an NSH-aware SF or SFC Proxy that receives encrypted 827 Context Headers, for which it is not allowed to consume a specific 828 Context Header it decrypts (but consumes others), MUST keep that 829 Context Header unaltered when forwarding the packet upstream. 831 Only one instance of "MAC and Encrypted Metadata" Context Header 832 (Section 5) is allowed. If multiple instances of "MAC and Encrypted 833 Metadata" Context Header are included in an NSH packet, the SFC data 834 plane element MUST process the first instance and ignore subsequent 835 instances, and MAY log or increase a counter for this event as per 836 Section 2.5.1 of [RFC8300]. 838 MTU and fragmentation considerations are discussed in Section 8. 840 7.2. MAC NSH Data Generation 842 If the Context Headers are not encrypted, the HMAC algorithm 843 discussed in [RFC4868] is used to integrity protect the target NSH 844 data. An NSH imposer inserts a "MAC and Encrypted Metadata" Context 845 Header for integrity protection (Section 5). 847 The NSH imposer computes the message integrity for the target NSH 848 data (depending on the integrity protection scope discussed in 849 Section 5) using MAC_KEY and HMAC algorithm. It inserts the MAC in 850 the "MAC and Encrypted Metadata" Context Header. The length of the 851 MAC is decided by the HMAC algorithm adopted for the particular key 852 identifier. 854 The Message Authentication Code (T) computation process can be 855 illustrated as follows: 857 T = HMAC-SHA-256-128(MAC_KEY, A) 859 An entity in the SFP that intends to update the NSH MUST follow the 860 above behavior to maintain message integrity of the NSH for 861 subsequent validations. 863 7.3. Encrypted NSH Metadata Generation 865 An NSH imposer can encrypt Context Headers carrying privacy-sensitive 866 metadata, i.e., encrypted and unencrypted metadata may be carried 867 simultaneously in the same NSH packet (Sections 6 and 7). 869 In an SFC-enabled domain where pervasive monitoring [RFC7258] is 870 possible, all Context Headers carrying privacy-sensitive metadata 871 MUST be encrypted; doing so, privacy-sensitive metadata is not 872 revealed to attackers. Privacy specific threats are discussed in 873 Section 5.2 of [RFC6973]. 875 Using the secret key (K) and authenticated encryption algorithm, the 876 NSH imposer encrypts the Context Headers (as set, for example, in 877 Section 3), computes the message integrity for the target NSH data, 878 and inserts the resulting payload in the "MAC and Encrypted Metadata" 879 Context Header (Section 5). The entire Context Header carrying a 880 privacy-sensitive metadata is encrypted (that is, including the MD 881 Class, Type, Length, and associated metadata of each Context Header). 883 The message Authentication Tag (T) and ciphertext (E) computation 884 process can be illustrated as follows: 886 MAC_KEY = initial MAC_KEY_LEN octets of K, 887 ENC_KEY = final ENC_KEY_LEN octets of K, 888 E = CBC-PKCS7-ENC(ENC_KEY, P), 889 M = MAC(MAC_KEY, A || IV || E || AL), 890 T = initial T_LEN octets of M. 891 MAC and Encrypted Metadata = E || T 893 Note that "||" denotes the concatenation of two values. 895 As specified in [RFC7518], the octet string (AL) is equal to the 896 number of bits in the Additional Authenticated Data (A) expressed as 897 a 64-bit unsigned big-endian integer. 899 An authorized entity in the SFP that intends to update the content of 900 an encrypted Context Header or needs to add a new encrypted Context 901 Header MUST also follow the aforementioned behavior. 903 An SFF or NSH-aware SF or SFC Proxy that only has access to the 904 MAC_KEY, but not the ENC_KEY, computes the message Authentication Tag 905 (T) after decrementing the TTL (by the SFF) or SI (by an SF or SFC 906 Proxy) and replaces the Authentication Tag in the NSH with the 907 computed Authentication Tag. Similarly, an NSH-aware SF (or SFC 908 Proxy) that does not modify the encrypted Context headers also 909 follows the aforementioned behavior. 911 The message Authentication Tag (T) computation process can be 912 illustrated as follows: 914 M = MAC(MAC_KEY, A || IV || E || AL), 915 T = initial T_LEN octets of M. 917 7.4. Timestamp for Replay Attack 919 The Timestamp imposed by an initial Classifier is left untouched 920 along an SFP. However, it can be updated when reclassification 921 occurs (Section 4.8 of [RFC7665]). The same considerations for 922 setting the Timestamp are followed in both initial classification and 923 reclassification (Section 6). 925 The received NSH is accepted by an NSH-aware node if the Timestamp 926 (TS) in the NSH is recent enough to the reception time of the NSH 927 (TSrt). The following formula is used for this check: 929 -Delta < (TSrt - TS) < +Delta 931 The Delta interval is a configurable parameter. The default value 932 for the allowed Delta is 2 seconds. Special care should be taken 933 when setting very low Delta values as this may lead to dropping 934 legitimate traffic. If the timestamp is not within the boundaries, 935 then the SFC data plane element receiving such packet MUST discard 936 the NSH message. 938 Replay attacks within the Delta window may be detected by an NSH- 939 aware node by recording a unique value derived, for example, from the 940 NSH data and Original packet (e.g., using SHA2). Such NSH-aware node 941 will detect and reject duplicates. If for legitimate service 942 reasons, some flows have to be duplicated but still share portion of 943 an SFP with the original flow, legitimate duplicate packets will be 944 tagged by NSH-aware nodes involved in that segment as replay packets 945 unless sufficient entropy is added to the duplicate packet. 947 Note: Within the timestamp delta window, defining a sequence 948 number to protect against replay attacks may be considered. In 949 such mode, NSH-aware nodes must discard packets with duplicate 950 sequence numbers within the timestamp delta window. However, in 951 deployments with several instances of the same SF (e.g., cluster 952 or load-balanced SFs), a mechanism to coordinate among those 953 instances to discard duplicate sequence numbers is required. 954 Because the coordination mechanism to comply with this requirement 955 is service-specific, this document does not include this 956 protection. 958 All SFC data plane elements must be synchronized among themselves. 959 These elements may be synchronized to a global reference time. 961 7.5. NSH Data Validation 963 When an SFC data plane element receives an NSH packet, it MUST first 964 ensure that a "MAC and Encrypted Metadata" Context Header is 965 included. It MUST silently discard the message if the timestamp is 966 invalid (Section 7.4). It MUST log an error at least once per the 967 SPI for which the "MAC and Encrypted Metadata" Context Header is 968 missing. 970 If the timestamp check is successfully passed, the SFC data plane 971 element proceeds with NSH data integrity validation. The SFC data 972 plane element computes the message integrity for the target NSH data 973 (depending on the integrity protection scope discussed in Section 5) 974 using the MAC_KEY and HMAC algorithm for the key identifier. If the 975 value of the newly generated digest is identical to the one enclosed 976 in the NSH, the SFC data plane element is certain that the NSH data 977 has not been tampered and validation is therefore successful. 978 Otherwise, the NSH packet MUST be discarded. 980 7.6. Decryption of NSH Metadata 982 If entitled to consume a supplied encrypted Context Header, an NSH- 983 aware SF or SFC Proxy decrypts metadata using (K) and decryption 984 algorithm for the key identifier in the NSH. 986 Authenticated encryption algorithm has only a single output, either a 987 plaintext or a special symbol (FAIL) that indicates that the inputs 988 are not authentic (Section 5.2.2.2 of [RFC7518]). 990 8. MTU Considerations 992 The SFC architecture prescribes that additional information be added 993 to packets to: 995 o Identify SFPs: this is typically the NSH Base Header and Service 996 Path Header. 998 o Carry metadata such as those defined in Section 5. 1000 o Steer the traffic along the SFPs: transport encapsulation. 1002 This added information increases the size of the packet to be carried 1003 along an SFP. 1005 Aligned with Section 5 of [RFC8300], it is RECOMMENDED for network 1006 operators to increase the underlying MTU so that NSH traffic is 1007 forwarded within an SFC-enabled domain without fragmentation. The 1008 available underlying MTU should be taken into account by network 1009 operators when providing SFs with the required Context Headers to be 1010 injected per SFP and the size of the data to be carried in these 1011 Context Headers. 1013 If the underlying MTU cannot be increased to accommodate the NSH 1014 overhead, network operators may rely upon a transport encapsulation 1015 protocol with the required fragmentation handling. The impact of 1016 activating such feature on SFFs should be carefully assessed by 1017 network operators (Section 5.6 of [RFC7665]). 1019 When dealing with MTU issues, network operators should consider the 1020 limitations of various transport encapsulations such as those 1021 discussed in [I-D.ietf-intarea-tunnels]. 1023 9. Security Considerations 1025 Data plane SFC-related security considerations, including privacy, 1026 are discussed in Section 6 of [RFC7665] and Section 8 of [RFC8300]. 1027 In particular, Section 8.2.2 of [RFC8300] states that attached 1028 metadata (i.e., Context Headers) should be limited to that necessary 1029 for correct operation of the SFP. Also, that section indicates that 1030 [RFC8165] discusses metadata considerations that operators can take 1031 into account when using NSH. 1033 The guidelines for cryptographic key management are discussed in 1034 [RFC4107]. 1036 The interaction between the SFC data plane elements and a key 1037 management system MUST NOT be transmitted in clear since this would 1038 completely destroy the security benefits of the integrity protection 1039 solution defined in this document. The secret key (K) must have an 1040 expiration time assigned as the latest point in time before which the 1041 key may be used for integrity protection of NSH data and encryption 1042 of Context Headers. Prior to the expiration of the secret key, all 1043 participating NSH-aware nodes SHOULD have the control plane 1044 distribute a new key identifier and associated keying material so 1045 that when the secret key is expired, those nodes are prepared with 1046 the new secret key. This allows the NSH imposer to switch to the new 1047 key identifier as soon as necessary. It is RECOMMENDED that the next 1048 key identifier and associated keying material be distributed by the 1049 control plane well prior to the secret key expiration time. 1051 NSH data are exposed to several threats: 1053 o A man-in-the-middle attacker modifying the NSH data. 1055 o Attacker spoofing the NSH data. 1057 o Attacker capturing and replaying the NSH data. 1059 o Data carried in Context Headers revealing privacy-sensitive 1060 information to attackers. 1062 o Attacker replacing the packet on which the NSH is imposed with a 1063 bogus packet. 1065 In an SFC-enabled domain where the above attacks are possible, (1) 1066 NSH data MUST be integrity-protected and replay-protected, and (2) 1067 privacy-sensitive NSH metadata MUST be encrypted for confidentiality 1068 preservation purposes. The Base and Service Path headers are not 1069 encrypted. 1071 MACs with two levels of assurance are defined in Section 5. 1072 Considerations specific to each level of assurance are discussed in 1073 Sections 9.1 and 9.2. 1075 The attacks discussed in [I-D.nguyen-sfc-security-architecture] are 1076 handled owing to the solution specified in this document, except for 1077 attacks dropping packets. Such attacks can be detected relying upon 1078 statistical analysis; such analysis is out of the scope of this 1079 document. Also, if SFFs are not involved in the integrity checks, a 1080 misbehaving SFF which decrements SI while this should be done by an 1081 SF (SF bypass attack) will be detected by an upstream SF because the 1082 integrity check will fail. 1084 Some events are logged locally with notification alerts sent by NSH- 1085 aware nodes to a Control Element. These events SHOULD be rate- 1086 limited. 1088 The solution specified in this document does not provide data origin 1089 authentication. 1091 In order to detect compromised nodes, it is assumed that appropriate 1092 mechanisms to monitor and audit an SFC-enabled domain to detect 1093 misbehavior and to deter misuse are in place. Compromised nodes can 1094 thus be withdrawn from active service function chains using 1095 appropriate control plane mechanisms. 1097 9.1. MAC#1 1099 An active attacker can potentially modify the Base header (e.g., 1100 decrement the TTL so the next SFF in the SFP discards the NSH 1101 packet). In the meantime, an active attacker can also drop NSH 1102 packets. As such, this attack is not considered an attack against 1103 the security mechanism specified in the document. 1105 No device other than the NSH-aware SFs in the SFC-enabled domain 1106 should be able to update the integrity protected NSH data. 1107 Similarly, no device other than the NSH-aware SFs and SFC proxies in 1108 the SFC-enabled domain should be able to decrypt and update the 1109 Context Headers carrying privacy-sensitive metadata. In other words, 1110 if the NSH-aware SFs and SFC proxies in the SFC-enabled domain are 1111 considered fully trusted to act on the NSH data, only these elements 1112 can have access to privacy-sensitive NSH metadata and the keying 1113 material used to integrity protect NSH data and encrypt Context 1114 Headers. 1116 9.2. MAC#2 1118 SFFs can detect whether an illegitimate node has altered the content 1119 of the Base header. Such messages must be discarded with appropriate 1120 logs and alarms generated (see Section 7.1). 1122 9.3. Time Synchronization 1124 Section 5.6 of [RFC8633] describes best current practices to be 1125 considered in deployments where SFC data plane elements use NTP for 1126 time synchronization purposes. 1128 Also, a mechanism to provide cryptographic security for NTP is 1129 specified in [RFC8915]. 1131 10. IANA Considerations 1133 This document requests IANA to assign the following types from the 1134 "NSH IETF-Assigned Optional Variable-Length Metadata Types" (0x0000 1135 IETF Base NSH MD Class) registry available at: 1136 https://www.iana.org/assignments/nsh/nsh.xhtml#optional-variable- 1137 length-metadata-types. 1139 +-------+-------------------------------+----------------+ 1140 | Value | Description | Reference | 1141 +=======+===============================+================+ 1142 | TBD1 | MAC and Encrypted Metadata #1 | [ThisDocument] | 1143 | TBD2 | MAC and Encrypted Metadata #2 | [ThisDocument] | 1144 +-------+-------------------------------+----------------+ 1146 11. Acknowledgements 1148 This document was edited as a follow up to the discussion in 1149 IETF#104: https://datatracker.ietf.org/meeting/104/materials/slides- 1150 104-sfc-sfc-chair-slides-01 (slide 7). 1152 Thanks to Joel Halpern, Christian Jacquenet, Dirk von Hugo, Tal 1153 Mizrahi, Daniel Migault, Diego Lopez, Greg Mirsky, and Dhruv Dhody 1154 for the comments. 1156 Many thanks to Steve Hanna for the valuable secdir review and Juergen 1157 Schoenwaelder for the opsdir review. 1159 Thanks to Greg Mirsky for the Shepherd review. 1161 12. References 1163 12.1. Normative References 1165 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1166 Requirement Levels", BCP 14, RFC 2119, 1167 DOI 10.17487/RFC2119, March 1997, 1168 . 1170 [RFC4107] Bellovin, S. and R. Housley, "Guidelines for Cryptographic 1171 Key Management", BCP 107, RFC 4107, DOI 10.17487/RFC4107, 1172 June 2005, . 1174 [RFC4868] Kelly, S. and S. Frankel, "Using HMAC-SHA-256, HMAC-SHA- 1175 384, and HMAC-SHA-512 with IPsec", RFC 4868, 1176 DOI 10.17487/RFC4868, May 2007, 1177 . 1179 [RFC7518] Jones, M., "JSON Web Algorithms (JWA)", RFC 7518, 1180 DOI 10.17487/RFC7518, May 2015, 1181 . 1183 [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function 1184 Chaining (SFC) Architecture", RFC 7665, 1185 DOI 10.17487/RFC7665, October 2015, 1186 . 1188 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1189 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1190 May 2017, . 1192 [RFC8300] Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed., 1193 "Network Service Header (NSH)", RFC 8300, 1194 DOI 10.17487/RFC8300, January 2018, 1195 . 1197 12.2. Informative References 1199 [I-D.arkko-farrell-arch-model-t] 1200 Arkko, J. and S. Farrell, "Challenges and Changes in the 1201 Internet Threat Model", draft-arkko-farrell-arch-model- 1202 t-04 (work in progress), July 2020. 1204 [I-D.ietf-intarea-tunnels] 1205 Touch, J. and M. Townsley, "IP Tunnels in the Internet 1206 Architecture", draft-ietf-intarea-tunnels-10 (work in 1207 progress), September 2019. 1209 [I-D.nguyen-sfc-security-architecture] 1210 THANG, N. C. and M. Park, "A Security Architecture Against 1211 Service Function Chaining Threats", draft-nguyen-sfc- 1212 security-architecture-00 (work in progress), November 1213 2019. 1215 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, 1216 "Network Time Protocol Version 4: Protocol and Algorithms 1217 Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, 1218 . 1220 [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., 1221 Morris, J., Hansen, M., and R. Smith, "Privacy 1222 Considerations for Internet Protocols", RFC 6973, 1223 DOI 10.17487/RFC6973, July 2013, 1224 . 1226 [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an 1227 Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 1228 2014, . 1230 [RFC7498] Quinn, P., Ed. and T. Nadeau, Ed., "Problem Statement for 1231 Service Function Chaining", RFC 7498, 1232 DOI 10.17487/RFC7498, April 2015, 1233 . 1235 [RFC7635] Reddy, T., Patil, P., Ravindranath, R., and J. Uberti, 1236 "Session Traversal Utilities for NAT (STUN) Extension for 1237 Third-Party Authorization", RFC 7635, 1238 DOI 10.17487/RFC7635, August 2015, 1239 . 1241 [RFC8165] Hardie, T., "Design Considerations for Metadata 1242 Insertion", RFC 8165, DOI 10.17487/RFC8165, May 2017, 1243 . 1245 [RFC8459] Dolson, D., Homma, S., Lopez, D., and M. Boucadair, 1246 "Hierarchical Service Function Chaining (hSFC)", RFC 8459, 1247 DOI 10.17487/RFC8459, September 2018, 1248 . 1250 [RFC8633] Reilly, D., Stenn, H., and D. Sibold, "Network Time 1251 Protocol Best Current Practices", BCP 223, RFC 8633, 1252 DOI 10.17487/RFC8633, July 2019, 1253 . 1255 [RFC8877] Mizrahi, T., Fabini, J., and A. Morton, "Guidelines for 1256 Defining Packet Timestamps", RFC 8877, 1257 DOI 10.17487/RFC8877, September 2020, 1258 . 1260 [RFC8915] Franke, D., Sibold, D., Teichel, K., Dansarie, M., and R. 1261 Sundblad, "Network Time Security for the Network Time 1262 Protocol", RFC 8915, DOI 10.17487/RFC8915, September 2020, 1263 . 1265 Authors' Addresses 1267 Mohamed Boucadair 1268 Orange 1269 Rennes 35000 1270 France 1272 Email: mohamed.boucadair@orange.com 1274 Tirumaleswar Reddy 1275 McAfee, Inc. 1276 Embassy Golf Link Business Park 1277 Bangalore, Karnataka 560071 1278 India 1280 Email: TirumaleswarReddy_Konda@McAfee.com 1282 Dan Wing 1283 Citrix Systems, Inc. 1284 USA 1286 Email: dwing-ietf@fuggles.com