idnits 2.17.1 draft-rebo-sfc-nsh-integrity-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 20, 2019) is 1591 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 1061, but not defined ** Downref: Normative reference to an Informational RFC: RFC 7665 Summary: 1 error (**), 0 flaws (~~), 2 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: May 23, 2020 McAfee 6 D. Wing 7 Citrix 8 November 20, 2019 10 Integrity Protection for Network Service Header (NSH) and Encryption of 11 Sensitive Context Headers 12 draft-rebo-sfc-nsh-integrity-02 14 Abstract 16 This specification adds integrity protection and optional encryption 17 of sensitive metadata directly to Network Service Headers (NSH) used 18 for Service Function Chaining (SFC). 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at https://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on May 23, 2020. 37 Copyright Notice 39 Copyright (c) 2019 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (https://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 3. Assumptions & Basic Requirements . . . . . . . . . . . . . . 4 57 4. Design Overview . . . . . . . . . . . . . . . . . . . . . . . 7 58 4.1. Supported Security Services . . . . . . . . . . . . . . . 7 59 4.1.1. Encrypt All or a Subset of Context Headers . . . . . 7 60 4.1.2. Integrity Protection . . . . . . . . . . . . . . . . 8 61 4.2. One Secret Key, Two Security Services . . . . . . . . . . 9 62 4.3. Mandatory-to-Implement Authenticated Encryption and HMAC 63 Algorithms . . . . . . . . . . . . . . . . . . . . . . . 10 64 4.4. Key Management . . . . . . . . . . . . . . . . . . . . . 11 65 4.5. New NSH Variable-Length Context Headers . . . . . . . . . 11 66 4.6. Encapsulation of NSH within NSH . . . . . . . . . . . . . 12 67 5. New NSH Variable-Length Context Headers . . . . . . . . . . . 12 68 5.1. Key Identifier Context Header . . . . . . . . . . . . . . 12 69 5.2. Timestamp Context Header . . . . . . . . . . . . . . . . 13 70 5.3. MAC and Encrypted Metadata Context Header . . . . . . . . 14 71 5.3.1. MAC#1 Context Header . . . . . . . . . . . . . . . . 14 72 5.3.2. MAC#2 Context Header . . . . . . . . . . . . . . . . 16 73 6. Processing Rules . . . . . . . . . . . . . . . . . . . . . . 18 74 6.1. Generic Behavior . . . . . . . . . . . . . . . . . . . . 18 75 6.2. MAC NSH Data Generation . . . . . . . . . . . . . . . . . 19 76 6.3. Encrypted NSH Metadata Generation . . . . . . . . . . . . 19 77 6.4. Timestamp for Replay Attack . . . . . . . . . . . . . . . 21 78 6.5. NSH Data Validation . . . . . . . . . . . . . . . . . . . 21 79 6.6. Decryption of NSH Metadata . . . . . . . . . . . . . . . 22 80 7. Security Considerations . . . . . . . . . . . . . . . . . . . 22 81 7.1. MAC#1 . . . . . . . . . . . . . . . . . . . . . . . . . . 23 82 7.2. MAC#2 . . . . . . . . . . . . . . . . . . . . . . . . . . 23 83 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 84 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 24 85 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 86 10.1. Normative References . . . . . . . . . . . . . . . . . . 24 87 10.2. Informative References . . . . . . . . . . . . . . . . . 25 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 90 1. Introduction 92 Many advanced Service Functions (e.g., Performance Enhancement 93 Proxies, NATs, firewalls, etc.) are invoked for the delivery of 94 value-added services, particularly to meet various service objectives 95 such as IP address sharing, avoiding covert channels, detecting 96 Denial-of-Service (DoS) attacks and protecting network 97 infrastructures against them, network slicing, etc. Because of the 98 proliferation of such advanced SFs together with complex service 99 deployment constraints that demand more agile service delivery 100 procedures, operators need to rationalize their service delivery 101 logics and master their complexity while optimising service 102 activation time cycles. The overall problem space is described in 103 [RFC7498]. 105 [RFC7665] presents an architecture addressing the problematic aspects 106 of existing service deployments, including topological dependence and 107 configuration complexity. It also describes an architecture for the 108 specification, creation, and maintenance of Service Function Chains 109 (SFC) within a network. That is, how to define an ordered set of SFs 110 and ordering constraints that must be applied to packets/flows 111 selected as a result of traffic classification. [RFC8300] specifies 112 the SFC encapsulation: Network Service Header (NSH). 114 NSH data is unauthenticated and unencrypted [RFC8300], forcing a 115 service topology that requires security and privacy to use a 116 transport encapsulation that supports such features (e.g., IPsec). 117 The lack of such capability was reported during the development of 118 [RFC8300] and [RFC8459]. The reader may refer to Section 4.2.1 of 119 [I-D.arkko-arch-internet-threat-model] for a discussion on the need 120 for more awareness about attacks from within closed domains. 122 This specification fills that gap. Concretely, this document adds 123 integrity protection and optional encryption of sensitive metadata 124 directly to NSH (Section 4); integrity protects the packet payload, 125 and provides relay protection. Thus, the NSH do not have to rely 126 upon an underlying transport encapsulation for security and 127 confidentiality. 129 This specification introduces new Variable-Length Context Headers to 130 carry fields necessary for integrity protected NSH headers and 131 encrypted Context Headers (Section 5), and is therefore only 132 applicable to NSH MD Type 0x02, as defined in Section 2.5 of 133 [RFC8300]. 135 2. Terminology 137 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 138 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 139 "OPTIONAL" in this document are to be interpreted as described in BCP 140 14 [RFC2119][RFC8174] when, and only when, they appear in all 141 capitals, as shown here. 143 This document makes use of the terms defined in [RFC7665] and 144 [RFC8300]. 146 The document defines the following terms: 148 o SFC data plane element: Refers to SFC-aware Service Function, 149 Service Function Forwarder (SFF), SFC proxy, or classifier as 150 defined in the SFC data plane architecture [RFC7665]. 152 o SFC Control Element: A logical entity that instructs one or more 153 SFC data plane functional elements on how to process NSH packets 154 within an SFC-enabled domain. 156 o Key Identifier: A key identifier or kerberos-like object used to 157 identify and deliver keys to authorized entities. 159 o NSH data: The NSH is composed of a Base Header, a Service Path 160 Header, and optional Context Headers. NSH data refers to all the 161 above headers and the packet or frame on which NSH is imposed to 162 realize a Service Function Path (SFP). 164 o NSH imposer: Refers to the SFC data plane element that is entitled 165 to impose NSH with the Context Headers defined in this document. 167 3. Assumptions & Basic Requirements 169 The NSH format is defined in Section 2 of [RFC8300]; the NSH data can 170 be spread over three headers: 172 o Base Header: Provides information about the service header and the 173 payload protocol. 175 o Service Path Header: Provides path identification and location 176 within a Service Function Path (SFP). 178 o Context Header(s): Carries metadata (i.e., context data) along a 179 service path. 181 NSH allows to share context information (a.k.a., metadata) with 182 upstream SFC-aware data elements on a per SFC/SFP basis. To that 183 aim: 185 The control plane is used to instruct the SFC classifier about the 186 set of context information to be supplied in the context of a 187 given chain. 189 The control plane is also used to instruct an SFC-aware SF about 190 any metadata it needs to attach to packets for a given SFC. This 191 instruction may occur any time during the validity lifetime of an 192 SFC/SFP. The control plane may indicate, for a given service 193 function chain, an order for consuming a set of contexts supplied 194 in a packet. 196 An SFC-aware SF can also be instructed about the behavior it 197 should adopt after consuming a context information that was 198 supplied in the NSH header. For example, the context can be 199 maintained, updated, or stripped. 201 An SFC proxy may be instructed about the behavior it should adopt 202 to process the context information that was supplied in the NSH 203 header on behalf of an SFC-unaware SF, e.g., the context can be 204 maintained or stripped. 206 The SFC proxy may also be instructed to add some new context 207 information into the NSH header on behalf of an SFC-unaware SF. 209 In reference to Figure 1, 211 o Classifiers, SFC-aware SFs, and SFC proxies are entitled to update 212 the Context Header(s). 214 Only these elements MUST be able to encrypt and decrypt a supplied 215 Context Header. 217 o Only SFC-aware SFs and SFC proxies are entitled to update the 218 Service Path Header. 220 The solution MUST provide integrity protection for this header. 222 o SFFs are entitled to modify the Base Path header (TTL value, for 223 example). Nevertheless, SFFs are not supposed to act on the 224 Context Headers or look into the content of the Context Headers. 226 The solution MAY provide integrity protection for the Base Header. 227 The implications of disabling such checks are discussed in 228 Section 7.1. 230 Discussion Note: This design decision should be discussed with 231 the working group. 233 +---------------+-----------------------+---------------+ 234 | | Insert, remove, or | Update | 235 | | replace the NSH | the NSH | 236 | | | | 237 |SFC Data Plane +-------+-------+-------+-------+-------+ 238 | Element | | | |Dec. |Update | 239 | |Insert |Remove |Replace|Service|Context| 240 | | | | |Index |Header | 241 +---------------+-------+-------+-------+-------+-------+ 242 | | + | | + | | + | 243 |Classifier | | | | | | 244 +---------------+-------+-------+-------+-------+-------+ 245 |Service | | + | | | | 246 |Function | | | | | | 247 |Forwarder (SFF)| | | | | | 248 +---------------+-------+-------+-------+-------+-------+ 249 |Service | | | | + | + | 250 |Function (SF) | | | | | | 251 +---------------+-------+-------+-------+-------+-------+ 252 | | + | + | | + | + | 253 |SFC Proxy | | | | | | 254 +---------------+-------+-------+-------+-------+-------+ 256 Figure 1: NSH Actions 258 This document does not make any assumption about the service function 259 chains to be instantiated nor adds any constraint about how NSH can 260 be used within a domain. For example, in reference to Figure 2, the 261 solution accommodates deployment schemes such as: no Context Header 262 is inserted by the Classifier, a first SF inserts two Context Headers 263 that it encrypts, a second SF is entitled to access that encrypted 264 data but it is instructed to strip one particular Context Header, and 265 a third SF is instructed to strip the remaining Context Header. The 266 following behavior will thus be observed: 268 o No Context Header is inserted by the Classifier: it only proceeds 269 with the NSH integrity protection. The NSH encapsulated packet is 270 then forwarded to the next hop following [RFC7665]. 272 o Once the packet is received by SF1, and assuming integrity checks 273 succeed, SF1 inserts two Context Headers M1 and M2 that it 274 encrypts and recomputes the message integrity for the NSH data. 276 o Once the packet is received by SF2, and assuming integrity checks 277 succeed, SF2 decrypts M1 and M2, strips M2 (because its instructed 278 to do so via the SFC control plane), and then encrypts M1 and 279 recomputes the message integrity for the NSH data. 281 o Once the packet is received by SF3, and assuming integrity checks 282 succeed, SF3 decrypts M1, consumes the decrypted M1 data, and then 283 strips it from the NSH. The packet is then forwarded back to SFF3 284 by SF3 after recomputing the message integrity for the NSH data. 286 SF1 SF3 287 | | 288 Classifier---SFF1----SFF2---SFF3 289 | 290 SF2 292 Figure 2: SFC-enabled Domain Example 294 4. Design Overview 296 4.1. Supported Security Services 298 This specification provides the functions described in the following 299 sub-sections: 301 4.1.1. Encrypt All or a Subset of Context Headers 303 The solution allows to encrypt all or a subset of metadata (that is 304 carried in NSH Context Headers) by Classifiers, SFC-aware SFs, and 305 SFC proxies. As depicted in Table 1, SFFs are not involved in data 306 encryption. This memo enforces this design approach by encrypting 307 the Context Header with keys that are not supplied to SFFs, thus 308 enforcing this limitation by protocol (rather than requirements 309 language). 311 +-----------------+------------------------------+------------------+ 312 | Data Plane | Base and Service Headers | Metadata | 313 | Element | Encryption | Encryption | 314 +-----------------+------------------------------+------------------+ 315 | Classifier | No | Yes | 316 | SFF | No | No | 317 | SFC-aware SF | No | Yes | 318 | SFC Proxy | No | Yes | 319 | SFC-unaware SF | No | No | 320 +-----------------+------------------------------+------------------+ 322 Table 1: Encryption Function Supported by SFC Data Plane Elements 324 The control plane is assumed to instruct the Classifier, SFC-aware 325 SFs, and SFC proxy with the set of Context Headers (privacy-sensitive 326 metadata, typically) that must be encrypted. Encryption keying 327 material is only provided to these SFC data elements. 329 The control plane may also indicate the set of SFC data plane 330 elements that are entitled to supply a given context header (e.g., in 331 reference to their identifiers as assigned within the SFC-enabled 332 domain). It is out of the scope of this document to elaborate on how 333 such instructions are provided to the appropriate SFC data plane 334 elements, nor to detail the structure used to store the instructions. 336 The Service Path Header is not encrypted because SFFs use Service 337 Index (SI) in conjunction with Service Path Identifier (SPI) for 338 determining the next SF in the path. 340 4.1.2. Integrity Protection 342 The solution provides integrity protection for NSH data. Two flavors 343 are supported. 345 A first flavor where all NSH data except the Base Header are 346 integrity protected (Figure 3). In this case, the NSH imposer may be 347 a Classifier, an SFC-aware SF, or an SFC proxy. SFFs are not thus 348 provided with authentication material. Further details are discussed 349 in Section 5.3.1. 351 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 352 | Transport Encapsulation | 353 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+... 354 | Base Header | | 355 +->+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ N 356 | | Service Path Header | S 357 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ H 358 | | Context Header(s) | | 359 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+... 360 | | Original Packet | 361 +->+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 362 | 363 +------Scope of integrity protected data 365 Figure 3: First Integrity Flavor 367 A second flavor where all NSH data, including the Base Header, are 368 integrity protected (Figure 4). In this case, the NSH imposer may be 369 a Classifier, an SFC-aware SF, an SFF, or an SFC proxy. Further 370 details are discussed in Section 5.3.2. 372 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 373 | Transport Encapsulation | 374 +->+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+... 375 | | Base Header | | 376 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ N 377 | | Service Path Header | S 378 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ H 379 | | Context Header(s) | | 380 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+... 381 | | Original Packet | 382 +->+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 383 | 384 +----Scope of integrity protected data 386 Figure 4: Second Integrity Flavor 388 The integrity protection scope is explicitly signaled to SFC-aware 389 SFs and SFC proxies in the NSH by means of a dedicated MD Type 390 (Section 5.3). 392 In both flavors, the unencrypted metadata and the packet on which NSH 393 is imposed are subject to integrity protection. 395 Table 2 lists the roles of SFC data plane elements in providing 396 integrity protection for the NSH. 398 +--------------------+----------------------------------------+ 399 | Data Plane Element | Integrity Protection | 400 +--------------------+----------------------------------------+ 401 | Classifier | Yes | 402 | SFF | No (first flavor); Yes (second flavor) | 403 | SFC-aware SF | Yes | 404 | SFC Proxy | Yes | 405 | SFC-unaware SF | No | 406 +--------------------+----------------------------------------+ 408 Table 2: Integrity Protection Supported by SFC Data Plane Elements 410 4.2. One Secret Key, Two Security Services 412 The authenticated encryption algorithm defined in [RFC7518] is used 413 to provide NSH data integrity and to encrypt Context Headers carrying 414 privacy-sensitive metadata. 416 The authenticated encryption algorithm provides a unified encryption 417 and authentication operation which turns plaintext into authenticated 418 ciphertext and vice versa. The generation of secondary keys MAC_KEY 419 and ENC_KEY from the secret key K is discussed in Section 5.2.2.1 of 420 [RFC7518]. The ENC_KEY is used for encrypting the Context Headers 421 and the message integrity of the NSH data is calculated using the 422 MAC_KEY. If the Context Headers are not encrypted, the Hashed 423 Message Authentication Mode (HMAC) algorithm discussed in [RFC4868] 424 is used to integrity protect the NSH data. 426 The advantage of using the authenticated encryption algorithm is that 427 SFC-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 in both the flavors discussed above is SFFs do not have access to the 431 ENC_KEY and cannot act on the encrypted Context Headers and, only in 432 case of the second flavor, SFFs do have access to the MAC_KEY. 433 Similarly, an SFC-aware SF or SFC proxy not allowed to decrypt the 434 Context Headers will 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 as input four octet 442 strings: a secret key (K), a plaintext (P), Additional Authenticated 443 Data (A) (which contains the data to be authenticated, but not 444 encrypted), and an Initialization Vector (IV). The ciphertext value 445 (E) and the Authentication Tag value (T) are provided as outputs. 447 In order to decrypt and verify, the cipher takes as input K, IV, A, 448 T, and E. The output is either the plaintext or an error indicating 449 that the decryption failed as described in Section 5.2.2.2 of 450 [RFC7518]. 452 4.3. Mandatory-to-Implement Authenticated Encryption and HMAC 453 Algorithms 455 Classifiers, SFC-aware SFs, and SFC proxies MUST implement the 456 AES_128_CBC_HMAC_SHA_256 algorithm and SHOULD implement the 457 AES_192_CBC_HMAC_SHA_384 and AES_256_CBC_HMAC_SHA_512 algorithms. 459 Classifiers, SFC-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 4.4. Key Management 468 The procedure for the allocation/provisioning of secret keys (K) and 469 authenticated encryption algorithm or MAC_KEY and HMAC algorithm is 470 outside the scope of this specification. As such, this specification 471 does not mandate the support of any specific mechanism. 473 The documents does not assume nor preclude the following: 475 o The same keying material is used for all the service functions 476 used within an SFC-enabled domain. 478 o Distinct keying material is used per SFP. 480 o Per-tenant keys are used. 482 In order to accommodate deployments relying upon keying material per 483 SFC/SFP and also the need to update keys after encrypting NSH data 484 for certain amount of time, this document uses key identifier (kid) 485 to unambiguously identify the appropriate keying material. Doing so 486 allows to address the problem of synchronization of keying material. 488 Additional information on manual vs. automated key management and 489 when one should be used over the other can be found in [RFC4107]. 491 4.5. New NSH Variable-Length Context Headers 493 New NSH Variable-Length Context Headers are defined in Section 5 for 494 NSH data integrity protection and, optionally, encryption of Context 495 Headers carrying privacy-sensitive metadata. Concretely, an NSH 496 imposer includes (1) the key identifier in NSH using the Key 497 Identifier Context Header (Section 5.1), (2) the timestamp in 498 Timestamp Context Header to protect against replay attacks 499 (Section 6.4), and (3) the Message Authentication Code (MAC) for the 500 target NSH data (depending on the integrity protection scope) 501 calculated using the MAC_KEY and optionally Context Headers encrypted 502 using ENC_KEY in 'MAC and Encrypted Metadata Context' Header 503 (Section 5.3). 505 An NSH data plane element that needs to check the integrity of the 506 NSH data uses the MAC_KEY and the HMAC algorithm for the key 507 identifier being carried in the NSH. 509 An SFC-aware SF or SFC proxy that needs to decrypt the metadata uses 510 ENC_Key and the decryption algorithm for the key identifier being 511 carried in the NSH. 513 Section 6 specifies the detailed procedure. 515 4.6. Encapsulation of NSH within NSH 517 As discussed in [RFC8459], an SFC-enabled domain (called, upper-level 518 domain) may be decomposed into many sub-domains (called, lower-level 519 domains). In order to avoid maintaining state to restore back upper- 520 lower NSH information at the boundaries of lower-level domains, two 521 NSH levels are used: an Upper-NSH which imposed at the boundaries of 522 the upper-level domain, and a Lower-NSH that is pushed by the 523 Classifier of a lower-level domain in front of the original NSH 524 (Figure 5). As such, the Upper-NSH information is carried along the 525 lower-level chain without modification. The packet is forwarded in 526 the top-level domain according to the Upper-NSH, while it is 527 forwarded according to the Lower-NSH in a lower-level SFC domain. 529 +---------------------------------+ 530 | Transport Encapsulation | 531 +->+---------------------------------+ 532 | | Lower-NSH Header | 533 | +---------------------------------+ 534 | | Upper-NSH Header | 535 | +---------------------------------+ 536 | | Original Packet | 537 +->+---------------------------------+ 538 | 539 | 540 +----Scope of NSH security protection 541 provided by a lower-level domain 543 Figure 5: Encapsulation of NSH within NSH 545 SFC data plane elements of a lower-level domain includes the Upper- 546 NSH when computing the MAC. 548 Keying material used at the upper-level domain should not the same as 549 the one used by a lower-level domain. 551 5. New NSH Variable-Length Context Headers 553 This section specifies the format of new Variable-Length Context 554 headers that are used for NSH integrity protection and, optionally, 555 Context Headers encryption. 557 5.1. Key Identifier Context Header 559 The Key Identifier Context Header (Figure 6) is a variable length Key 560 Identifier object used to identify and deliver keys to SFC data plane 561 elements. Sending this Context Header is REQUIRED for compliance 562 with this specification. 564 This Context Header is helpful to accommodate deployments relying 565 upon keying material per SFC/SFP. The key identifier helps in 566 resolving the problem of synchronization of keying material. 568 0 1 2 3 569 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 570 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 571 | Metadata Class | Type |U| Length | 572 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 573 | Key Identifier | 574 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 576 Figure 6: Key Identifier Context Header 578 The description of the fields is as follows: 580 o Metadata Class: MUST be set to 0x0 [RFC8300]. 582 o Type: TBD1 (See Section 8) 584 o U: Unassigned bit [RFC8300]. 586 o Length: Variable. 588 o Key Identifier: Carries the key identifier. 590 5.2. Timestamp Context Header 592 The Timestamp Context Header (Figure 7) conveys a 64-bit timestamp 593 value. Sending this Context Header is REQUIRED for compliance with 594 this specification. 596 0 1 2 3 597 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 598 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 599 | Metadata Class | Type |U| Length | 600 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 601 | Timestamp | 602 | | 603 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 605 Figure 7: Timestamp Context Header 607 The description of the fields is as follows: 609 o Metadata Class: MUST be set to 0x0 [RFC8300]. 611 o Type: TBD2 (See Section 8) 612 o U: Unassigned bit [RFC8300]. 614 o Length: 8 bytes 616 o Timestamp: Carries an unsigned 64-bit integer value that is 617 expressed in seconds relative to 1970-01-01T00:00Z in UTC time. 619 5.3. MAC and Encrypted Metadata Context Header 621 This section defines two MAC and Encrypted Metadata Context Headers; 622 each having specific deployment constraints. Unlike the flavor 623 discussed in Section 5.3.1, the flavor sketched in Section 5.3.2 624 requires sharing MAC_KEY with SFFs. Both TLVs have the same format 625 as shown in Section 5.3. 627 0 1 2 3 628 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 629 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 630 | Metadata Class | Type |U| Length | 631 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 632 | IV Length | | 633 +-+-+-+-+-+-+-+-+ Initialization Vector ~ 634 ~ | 635 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 636 | | 637 | Message Authentication Code and optional Encrypted | 638 ~ Context Headers ~ 639 | | 640 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 642 Figure 8: MAC and Encrypted Metadata Context Header 644 The description of the fields is provided in the following sub- 645 sections. 647 5.3.1. MAC#1 Context Header 649 MAC#1 Context Header is a variable-length TLV that carries the 650 Message Authentication Code (MAC) for the Service Path Header, 651 Context Headers, and the inner packet on which NSH is imposed, 652 calculated using MAC_KEY and optionally Context Headers encrypted 653 using ENC_KEY. The scope of this TLV is depicted in Figure 9. 655 This MAC flavor does not require sharing MAC_KEY with SFFs. It does 656 not require to re-compute the MAC by each SFF because of TTL 657 processing. Section 7.1 discusses the possible threat associated 658 with this flavor. 660 0 1 2 3 661 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 662 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 663 |Ver|O|U| TTL | Length |U|U|U|U|MD Type| Next Protocol | 664 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<--+ 665 | Service Path Identifier | Service Index | | 666 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 667 ~ Key Identifier ~ | 668 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 669 ~ Timestamp ~ | 670 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 671 | | | 672 ~ Variable-Length Unencrypted Context Headers (opt.) ~ | 673 | | | 674 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 675 | Metadata Class | Type |U| Length | | 676 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 677 | IV Length | Initialization Vector | | 678 +->+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 679 | ~ Context Header TLVs to encrypt ~ | 680 +->+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 681 | | | | 682 | ~ Inner Packet on which NSH is imposed ~ | 683 | | | | 684 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<--| 685 | | 686 | | 687 | | 688 | Integrity protected Portion----+ 689 +----Encrypted Portion 691 Figure 9: Scope of MAC#1 693 In reference to Figure 8, the description of the fields is as 694 follows: 696 o Metadata Class: MUST be set to 0x0 [RFC8300]. 698 o Type: TBD3 (See Section 8) 700 o U: Unassigned bit [RFC8300]. 702 o Length: Variable. 704 o IV Length: Carries the length of the IV (Section 5.2 of 705 [RFC7518]). If HMAC algorithm is used, IV length is set to zero. 707 o Initialization Vector: Carries the IV for authenticated encryption 708 algorithm as discussed in Section 5.2 of [RFC7518]. 710 o The Additional Authenticated Data (defined in [RFC7518]) MUST be 711 the Service Path header, the unencrypted Context headers, and the 712 inner packet on which NSH is imposed . 714 o Message Authentication Code covering the entire NSH data excluding 715 the Base header. 717 5.3.2. MAC#2 Context Header 719 MAC#2 Context Header is a variable-length TLV that carries the MAC 720 for the entire NSH data calculated using MAC_KEY and optionally 721 Context Headers encrypted using ENC_KEY. The scope of this TLV is 722 depicted in Figure 10. 724 0 1 2 3 725 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 726 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<--+ 727 |Ver|O|U| TTL | Length |U|U|U|U|MD Type| Next Protocol | | 728 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 729 | Service Path Identifier | Service Index | | 730 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 731 ~ Key Identifier ~ | 732 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 733 ~ Timestamp ~ | 734 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 735 | | | 736 ~ Variable-Length Unencrypted Context Headers (opt.) ~ | 737 | | | 738 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 739 | Metadata Class | Type |U| Length | | 740 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 741 | IV Length | Initialization Vector | | 742 +->+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 743 | ~ Context Header TLVs to encrypt ~ | 744 +->+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 745 | | | | 746 | ~ Inner Packet on which NSH is imposed ~ | 747 | | | | 748 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<--| 749 | | 750 | | 751 | | 752 | Integrity protected Portion----+ 753 +----Encrypted Portion 755 Figure 10: Scope of MAC#2 757 In reference to Figure 8, the description of the fields is as 758 follows: 760 o Metadata Class: MUST be set to 0x0 [RFC8300]. 762 o Type: TBD4 (See Section 8) 764 o U: Unassigned bit [RFC8300]. 766 o Length: Variable. 768 o IV Length: Carries the length of the IV (Section 5.2 of 769 [RFC7518]). If HMAC algorithm is used, IV length is set to zero. 771 o Initialization Vector: Carries the IV for authenticated encryption 772 algorithms as discussed in Section 5.2 of [RFC7518]. 774 o The Additional Authenticated Data (defined in [RFC7518]) MUST be 775 the entire NSH data (i.e., including the Base Header) excluding 776 the Context Headers to be encrypted. 778 o Message Authentication Code covering the entire NSH data and 779 optional encrypted Context Headers. 781 6. Processing Rules 783 The following sub-sections describe the processing rules for 784 integrity protected NSH and optionally encrypted Context Headers. 786 6.1. Generic Behavior 788 This document adheres to the recommendations in [RFC8300] for 789 handling the Context Headers at both ingress and egress SFC boundary 790 nodes. That is, to strip such context headers. 792 Failures to inject or validate the Context Headers defined in this 793 document SHOULD be logged locally while a notification alarm MAY be 794 sent to an SFC Control Element. Similarly, failure to validate the 795 integrity of the NSH data MUST cause that packet to be discarded 796 while a notification alarm MAY be sent to an SFC Control Element. 797 The details of sending notification alarms (i.e., the parameters 798 affecting the transmission of the notification alarms depend on the 799 information in the context header such as frequency, thresholds, and 800 content in the alarm) SHOULD be configurable by the SFC control 801 plane. 803 SFC-aware SFs and SFC proxies MAY be instructed to strip some 804 encrypted Context Headers from the packet or to pass the data to the 805 next SF in the service function chain after processing the content of 806 the Context Headers. If no instruction is provided, the default 807 behavior for intermediary SFC-aware nodes is to maintain such Context 808 Headers so that the information can be passed to next SFC-aware hops. 809 SFC-aware SFs and SFC proxies must re-apply the integrity protection 810 if any modification is made to the Context Headers (strip a Context 811 Header, update the content of an existing Context Header, insert a 812 new Context Header). 814 An SFC-aware SF or SFC proxy that is not allowed to decrypt any 815 Context Headers MUST NOT be given access to the ENC_KEY. 817 Otherwise, an SFC-aware SF or SFC proxy that receives encrypted 818 Context Headers, for which it is not allowed to consume a specific 819 Context Header it decrypts (but consumes others), MUST keep that 820 Context Header unaltered when forwarding the packet upstream. 822 Only one instance of Key Identifier (or Timestamp, MAC and Encrypted 823 Metadata) Context Header is allowed. If multiple instances of Key 824 Identifier (or Timestamp, MAC and Encrypted Metadata) Context Header 825 are included in an NSH packet, the SFC data element must process the 826 first instance and ignore subsequent instances, and may log or 827 increase a counter for this event as per Section 2.5.1 of [RFC8300]. 829 MTU and fragmentation considerations are discussed in Section 5 of 830 [RFC8300]. Those considerations are not reiterated here. 832 6.2. MAC NSH Data Generation 834 If the Context Headers are not encrypted, the HMAC algorithm 835 discussed in [RFC4868] is used to integrity protect the target NSH 836 data. An NSH imposer inserts a "MAC and Encrypted Metadata" Context 837 Header for integrity protection (Section 5.3). 839 The NSH imposer computes the message integrity for the target NSH 840 data (depending on the integrity protection scope discussed in 841 Section 5.3) using MAC_KEY and HMAC algorithm. It inserts the MAC in 842 the "MAC and Encrypted Metadata" Context Header. The length of the 843 MAC is decided by the HMAC algorithm adopted for the particular key 844 identifier. 846 The Message Authentication Code T computation process can be 847 illustrated as follows: 849 T = HMAC-SHA-256-128(MAC_KEY, A) 851 An entity in the SFP that intends to update NSH MUST follow the above 852 behavior to maintain message integrity of the NSH for subsequent 853 validations. 855 6.3. Encrypted NSH Metadata Generation 857 An NSH imposer can encrypt Context Headers carrying privacy-sensitive 858 metadata, i.e., encrypted and unencrypted metadata may be carried 859 simultaneously (Figure 11). 861 0 1 2 3 862 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 863 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 864 |Ver|O|U| TTL | Length |U|U|U|U|MD Type| Next Protocol | 865 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 866 | Service Path Identifier | Service Index | 867 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 868 ~ Key Identifier ~ 869 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 870 ~ Timestamp ~ 871 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 872 | | 873 ~ Variable-Length Unencrypted Context Headers (opt.) ~ 874 | | 875 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 876 | | 877 ~ MAC and Encrypted Metadata ~ 878 | | 879 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 881 Figure 11: NSH with Encrypted and Unencrypted Metadata 883 In an SFC-enabled domain where pervasive monitoring [RFC7258] is 884 possible, Context Headers carrying privacy-sensitive metadata MUST be 885 encrypted and MUST NOT reveal privacy-sensitive metadata to 886 attackers. Privacy specific threats are discussed in Section 5.2 of 887 [RFC6973]. 889 Using K and authenticated encryption algorithm, the NSH imposer 890 encrypts the Context Headers (as set by the control plane Section 3), 891 computes the message integrity for the target NSH data and inserts 892 the resulting payload in the "MAC and Encrypted Metadata" Context 893 Header (Section 5.3). The entire TLV carrying the privacy-sensitive 894 metadata is encrypted (that is, including the MD Class, Type, Length, 895 and associated metadata). 897 The message Authentication Tag (T) and ciphertext (E) computation 898 process can be illustrated as follows: 900 MAC_KEY = initial MAC_KEY_LEN octets of K, 901 ENC_KEY = final ENC_KEY_LEN octets of K, 902 E = CBC-PKCS7-ENC(ENC_KEY, P), 903 M = MAC(MAC_KEY, A || IV || E || AL), 904 T = initial T_LEN octets of M. 905 MAC and Encrypted Metadata = E || T 907 As specified in [RFC7518], the octet string (AL) is equal to the 908 number of bits in the Additional Authenticated Data (A) expressed as 909 a 64-bit unsigned big-endian integer. 911 An authorized entity in the SFP that intends to update the content of 912 an encrypted Context Header or needs to add a new encrypted Context 913 Header MUST also follow the aforementioned behavior. 915 An SFF or SFC-aware SF or SFC proxy that only has access to the 916 MAC_KEY but not the ENC_KEY computes the message Authentication Tag 917 (T) after decrementing the TTL (by the SFF) or SI (SF or SFC proxy) 918 and replaces the authentication tag in the NSH with the computed 919 authentication tag. Similarly, an SFC-aware SF or SFC proxy that 920 does not modify the encrypted Context headers also follows the 921 aforementioned behavior. 923 The message Authentication Tag (T) computation process can be 924 illustrated as follows: 926 M = MAC(MAC_KEY, A || IV || E || AL), 927 T = initial T_LEN octets of M. 929 6.4. Timestamp for Replay Attack 931 A Timestamp is an unsigned 64-bit integer value and is expressed in 932 seconds relative to 1970-01-01T00:00Z in UTC time. The information 933 MUST always be present. The received NSH is accepted if the 934 Timestamp (TS) in the NSH is recent enough to the reception time of 935 the NSH (TSrt). The following formula is used for this check: 937 -Delta < (TSrt ? TS) < +Delta 939 The RECOMMENDED value for the allowed Delta is 2 seconds. If the 940 timestamp is not within the boundaries, then the SFC data plane 941 element receiving such packet MUST discard the NSH message. 943 All SFC data plane elements must be synchronized among themselves. 944 These elements may be synchronized to a global reference time. 946 o TODO: timestamp validation on the receiver needs further text 947 refinement. 949 6.5. NSH Data Validation 951 When an SFC data plane element receives an NSH packet, it MUST first 952 ensure that all mandatory Context Headers required for NSH data 953 integrity are included. It MUST silently discard the message if one 954 of these mandatory Context Headers is missing or if the timestamp is 955 invalid (described in Section 6.4). It MUST log an error at least 956 once per the SPI for which the mandatory metadata is missing. 958 If all mandatory Context Headers are present, the SFC data plane 959 element should then proceed with NSH data integrity validation. The 960 SFC data plane element computes the message integrity for the target 961 NSH data (depending on the integrity protection scope discussed in 962 Section 5.3) using the MAC_KEY and HMAC algorithm for the key 963 identifier. If the value of the newly generated digest is identical 964 to the one enclosed in NSH, the SFC data plane element is certain 965 that the NSH data has not been tampered and validation is therefore 966 successful. Otherwise, the NSH packet MUST be discarded. 968 6.6. Decryption of NSH Metadata 970 If entitled to consume a supplied encrypted Context Header, an SFC- 971 aware SF or SFC proxy decrypts metadata using K and decryption 972 algorithm for the key identifier in NSH. 974 Authenticated encryption algorithm has only a single output, either a 975 plaintext or a special symbol FAIL that indicates that the inputs are 976 not authentic (Section 5.2.2.2 of [RFC7518]). 978 7. Security Considerations 980 NSH security considerations are discussed in Section 8 of [RFC8300]. 981 The guidelines for cryptographic key management are discussed in 982 [RFC4107]. 984 The interaction between the SFC-aware data plane elements and a key 985 management system MUST NOT be transmitted in clear since this would 986 completely destroy the security benefits of the integrity protection 987 solution defined in this document. The secret key K must have an 988 expiration time assigned as the latest point in time before which the 989 key may be used for integrity protection of NSH data and encryption 990 of Context Headers. Prior to the expiration of the secret key, all 991 participating service function nodes SHOULD have the control plane 992 distribute an new key identifier and associated keying material, so 993 that when the secret key is expired those nodes are prepared with the 994 new secret key. This allows the NSH Imposer to switch to the new key 995 identifier as soon as necessary. It is RECOMMENDED that the next key 996 identifier be distributed by the control plane well prior to the 997 secret key expiration time. 999 NSH data are exposed to several threats: 1001 o A man-in-the-middle attacker modifying NSH data. 1003 o Attacker spoofing NSH data. 1005 o Attacker capturing and replaying NSH data. 1007 o Metadata in Context Headers revealing privacy-sensitive 1008 information to attackers. 1010 o Attacker replacing the packet on which NSH is imposed with a bogus 1011 or malicious packet. 1013 In an SFC-enabled domain where the above attacks are possible, NSH 1014 data MUST be integrity-protected and replay-protected, and privacy- 1015 sensitive NSH metadata MUST be encrypted for confidentiality 1016 preservation purposes. The Base and Service Path headers are not 1017 encrypted. 1019 Two MAC flavors are defined in Section 5.3. Considerations specific 1020 to each flavor are discussed in the following sub-sections. 1022 7.1. MAC#1 1024 An active attacker can potentially modify the Base header (e.g., 1025 decrement the TTL so the next SFF in the SFP discards the NSH 1026 packet). In the meantime, an active attacker can also drop NSH 1027 packets. As such, this attack is not considered an attack against 1028 the security mechanism specified in the document. 1030 No device other than the SFC-aware SFs in the SFC-enabled domain 1031 should be able to update the integrity protected NSH data. 1032 Similarly, no device other than the SFC-aware SFs and SFC proxies in 1033 the SFC-enabled domain be able to decrypt and update the Context 1034 Headers carrying privacy-sensitive metadata. In other words, if the 1035 SFC-aware SFs and SFC proxies in the SFC-enabled domain are 1036 considered fully trusted to act on the NSH data, only they can have 1037 access to privacy-sensitive NSH metadata and the keying material used 1038 to integrity protect NSH data and encrypt Context Headers. 1040 7.2. MAC#2 1042 SFFs can detect whether an illegitimate node has altered the content 1043 of the Base header. Such messages MUST be discarded with appropriate 1044 logs and alarms generated. 1046 8. IANA Considerations 1048 This document requests IANA to assign the following types from the 1049 "NSH IETF-Assigned Optional Variable-Length Metadata Types" (0x0000 1050 IETF Base NSH MD Class) registry available at: 1052 https://www.iana.org/assignments/nsh/nsh.xhtml#optional-variable- 1053 length-metadata-types. 1055 +-------+-------------------------------+----------------+ 1056 | Value | Description | Reference | 1057 +-------+-------------------------------+----------------+ 1058 | TBD1 | Key Identifier | [ThisDocument] | 1059 | TBD2 | Timestamp | [ThisDocument] | 1060 | TBD3 | MAC and Encrypted Metadata#1 | [ThisDocument] | 1061 | TBD4 | MAC and Encrypted Metadata#2 | [ThisDocument] | 1062 +-------+-------------------------------+----------------+ 1064 9. Acknowledgements 1066 This document was edited as a follow up to the discussion in 1067 IETF#104: https://datatracker.ietf.org/meeting/104/materials/slides- 1068 104-sfc-sfc-chair-slides-01 (slide 7). 1070 Thanks to Joel Halpern, Christian Jacquenet, and Dirk von Hugo for 1071 the comments. 1073 10. References 1075 10.1. Normative References 1077 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1078 Requirement Levels", BCP 14, RFC 2119, 1079 DOI 10.17487/RFC2119, March 1997, 1080 . 1082 [RFC4107] Bellovin, S. and R. Housley, "Guidelines for Cryptographic 1083 Key Management", BCP 107, RFC 4107, DOI 10.17487/RFC4107, 1084 June 2005, . 1086 [RFC4868] Kelly, S. and S. Frankel, "Using HMAC-SHA-256, HMAC-SHA- 1087 384, and HMAC-SHA-512 with IPsec", RFC 4868, 1088 DOI 10.17487/RFC4868, May 2007, 1089 . 1091 [RFC7518] Jones, M., "JSON Web Algorithms (JWA)", RFC 7518, 1092 DOI 10.17487/RFC7518, May 2015, 1093 . 1095 [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function 1096 Chaining (SFC) Architecture", RFC 7665, 1097 DOI 10.17487/RFC7665, October 2015, 1098 . 1100 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1101 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1102 May 2017, . 1104 [RFC8300] Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed., 1105 "Network Service Header (NSH)", RFC 8300, 1106 DOI 10.17487/RFC8300, January 2018, 1107 . 1109 10.2. Informative References 1111 [I-D.arkko-arch-internet-threat-model] 1112 Arkko, J., "Changes in the Internet Threat Model", draft- 1113 arkko-arch-internet-threat-model-01 (work in progress), 1114 July 2019. 1116 [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., 1117 Morris, J., Hansen, M., and R. Smith, "Privacy 1118 Considerations for Internet Protocols", RFC 6973, 1119 DOI 10.17487/RFC6973, July 2013, 1120 . 1122 [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an 1123 Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 1124 2014, . 1126 [RFC7498] Quinn, P., Ed. and T. Nadeau, Ed., "Problem Statement for 1127 Service Function Chaining", RFC 7498, 1128 DOI 10.17487/RFC7498, April 2015, 1129 . 1131 [RFC8459] Dolson, D., Homma, S., Lopez, D., and M. Boucadair, 1132 "Hierarchical Service Function Chaining (hSFC)", RFC 8459, 1133 DOI 10.17487/RFC8459, September 2018, 1134 . 1136 Authors' Addresses 1138 Mohamed Boucadair 1139 Orange 1140 Rennes 35000 1141 France 1143 Email: mohamed.boucadair@orange.com 1144 Tirumaleswar Reddy 1145 McAfee, Inc. 1146 Embassy Golf Link Business Park 1147 Bangalore, Karnataka 560071 1148 India 1150 Email: TirumaleswarReddy_Konda@McAfee.com 1152 Dan Wing 1153 Citrix Systems, Inc. 1154 USA 1156 Email: dwing-ietf@fuggles.com