idnits 2.17.1 draft-rebo-sfc-nsh-integrity-03.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 (January 31, 2020) is 1547 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 1108, but not defined ** Downref: Normative reference to an Informational RFC: RFC 7665 == Outdated reference: A later version (-04) exists of draft-arkko-farrell-arch-model-t-01 == Outdated reference: A later version (-09) exists of draft-ietf-ntp-packet-timestamps-07 Summary: 1 error (**), 0 flaws (~~), 4 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: August 3, 2020 McAfee 6 D. Wing 7 Citrix 8 January 31, 2020 10 Integrity Protection for Network Service Header (NSH) and Encryption of 11 Sensitive Context Headers 12 draft-rebo-sfc-nsh-integrity-03 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 August 3, 2020. 37 Copyright Notice 39 Copyright (c) 2020 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 . . . . . . . . . . . . . . . . . . . . . . . . . 4 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 . . . . . . . . . . 10 62 4.3. Mandatory-to-Implement Authenticated Encryption and HMAC 63 Algorithms . . . . . . . . . . . . . . . . . . . . . . . 11 64 4.4. Key Management . . . . . . . . . . . . . . . . . . . . . 11 65 4.5. New NSH Variable-Length Context Headers . . . . . . . . . 12 66 4.6. Encapsulation of NSH within NSH . . . . . . . . . . . . . 12 67 5. New NSH Variable-Length Context Headers . . . . . . . . . . . 13 68 5.1. MAC#1 Context Header . . . . . . . . . . . . . . . . . . 14 69 5.2. MAC#2 Context Header . . . . . . . . . . . . . . . . . . 16 70 6. Timestamp Format . . . . . . . . . . . . . . . . . . . . . . 18 71 7. Processing Rules . . . . . . . . . . . . . . . . . . . . . . 19 72 7.1. Generic Behavior . . . . . . . . . . . . . . . . . . . . 19 73 7.2. MAC NSH Data Generation . . . . . . . . . . . . . . . . . 20 74 7.3. Encrypted NSH Metadata Generation . . . . . . . . . . . . 21 75 7.4. Timestamp for Replay Attack . . . . . . . . . . . . . . . 22 76 7.5. NSH Data Validation . . . . . . . . . . . . . . . . . . . 23 77 7.6. Decryption of NSH Metadata . . . . . . . . . . . . . . . 23 78 8. Security Considerations . . . . . . . . . . . . . . . . . . . 23 79 8.1. MAC#1 . . . . . . . . . . . . . . . . . . . . . . . . . . 24 80 8.2. MAC#2 . . . . . . . . . . . . . . . . . . . . . . . . . . 25 81 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 82 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25 83 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 84 11.1. Normative References . . . . . . . . . . . . . . . . . . 25 85 11.2. Informative References . . . . . . . . . . . . . . . . . 26 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 88 1. Introduction 90 Many advanced Service Functions (e.g., Performance Enhancement 91 Proxies, NATs, firewalls, etc.) are invoked for the delivery of 92 value-added services, particularly to meet various service objectives 93 such as IP address sharing, avoiding covert channels, detecting 94 Denial-of-Service (DoS) attacks and protecting network 95 infrastructures against them, network slicing, etc. Because of the 96 proliferation of such advanced SFs together with complex service 97 deployment constraints that demand more agile service delivery 98 procedures, operators need to rationalize their service delivery 99 logics and master their complexity while optimising service 100 activation time cycles. The overall problem space is described in 101 [RFC7498]. 103 [RFC7665] presents an architecture addressing the problematic aspects 104 of existing service deployments, including topological dependence and 105 configuration complexity. It also describes an architecture for the 106 specification, creation, and maintenance of Service Function Chains 107 (SFC) within a network. That is, how to define an ordered set of SFs 108 and ordering constraints that must be applied to packets/flows 109 selected as a result of traffic classification. [RFC8300] specifies 110 the SFC encapsulation: Network Service Header (NSH). 112 NSH data is unauthenticated and unencrypted [RFC8300], forcing a 113 service topology that requires security and privacy to use a 114 transport encapsulation that supports such features. Note that some 115 transport encapsulation (e.g., IPsec) only provide hop-by-hop 116 security between two SFC data plane elements (e.g., two service 117 function forwarders (SFFs), SFF to SF) and do not provide SF-to-SF 118 security of NSH metadata. For example, if IPsec is used, SFFs or SFs 119 within a Service Function Path (SFP) not authorized to access the 120 privacy-sensitive metadata will have access to the metadata. As a 121 reminder, the metadata referred to is an information that is inserted 122 by intermediate SFs and which is not visible to the communication 123 endpoints (Section 4.9 of [RFC7665]). 125 The lack of such capability was reported during the development of 126 [RFC8300] and [RFC8459]. The reader may refer to Section 3.2.1 of 127 [I-D.arkko-farrell-arch-model-t] for a discussion on the need for 128 more awareness about attacks from within closed domains. 130 This specification fills that gap. Concretely, this document adds 131 integrity protection and optional encryption of sensitive metadata 132 directly to NSH (Section 4); integrity protects the packet payload, 133 and provides relay protection (Section 7.4). Thus, the NSH do not 134 have to rely upon an underlying transport encapsulation for security 135 and confidentiality. 137 This specification introduces new Variable-Length Context Headers to 138 carry fields necessary for integrity protected NSH headers and 139 encrypted Context Headers (Section 5), and is therefore only 140 applicable to NSH MD Type 0x02, as defined in Section 2.5 of 141 [RFC8300]. 143 This specification limits thus access to an information within an SFP 144 to entities that have a need to interpret it. Typically, SFF should 145 not act or process the context headers. 147 2. Terminology 149 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 150 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 151 "OPTIONAL" in this document are to be interpreted as described in BCP 152 14 [RFC2119][RFC8174] when, and only when, they appear in all 153 capitals, as shown here. 155 This document makes use of the terms defined in [RFC7665] and 156 [RFC8300]. 158 The document defines the following terms: 160 o SFC data plane element: Refers to SFC-aware Service Function, 161 Service Function Forwarder (SFF), SFC proxy, or classifier as 162 defined in the SFC data plane architecture [RFC7665]. 164 o SFC Control Element: A logical entity that instructs one or more 165 SFC data plane functional elements on how to process NSH packets 166 within an SFC-enabled domain. 168 o Key Identifier: A key identifier or kerberos-like object used to 169 identify and deliver keys to authorized entities. See for 170 example, 'kid' usage in [RFC7635]. 172 o NSH data: The NSH is composed of a Base Header, a Service Path 173 Header, and optional Context Headers. NSH data refers to all the 174 above headers and the packet or frame on which NSH is imposed to 175 realize a Service Function Path (SFP). 177 o NSH imposer: Refers to the SFC data plane element that is entitled 178 to impose NSH with the Context Headers defined in this document. 180 3. Assumptions & Basic Requirements 182 The NSH format is defined in Section 2 of [RFC8300]; the NSH data can 183 be spread over three headers: 185 o Base Header: Provides information about the service header and the 186 payload protocol. 188 o Service Path Header: Provides path identification and location 189 within a Service Function Path (SFP). 191 o Context Header(s): Carries metadata (i.e., context data) along a 192 service path. 194 NSH allows to share context information (a.k.a., metadata) with 195 upstream SFC-aware data elements on a per SFC/SFP basis. To that 196 aim: 198 The control plane is used to instruct the SFC classifier about the 199 set of context information to be supplied in the context of a 200 given chain. 202 The control plane is also used to instruct an SFC-aware SF about 203 any metadata it needs to attach to packets for a given SFC. This 204 instruction may occur any time during the validity lifetime of an 205 SFC/SFP. The control plane may indicate, for a given service 206 function chain, an order for consuming a set of contexts supplied 207 in a packet. 209 An SFC-aware SF can also be instructed about the behavior it 210 should adopt after consuming a context information that was 211 supplied in the NSH header. For example, the context can be 212 maintained, updated, or stripped. 214 An SFC proxy may be instructed about the behavior it should adopt 215 to process the context information that was supplied in the NSH 216 header on behalf of an SFC-unaware SF, e.g., the context can be 217 maintained or stripped. 219 The SFC proxy may also be instructed to add some new context 220 information into the NSH header on behalf of an SFC-unaware SF. 222 In reference to Figure 1, 224 o Classifiers, SFC-aware SFs, and SFC proxies are entitled to update 225 the Context Header(s). 227 o Only SFC-aware SFs and SFC proxies are entitled to update the 228 Service Path Header. 230 o SFFs are entitled to modify the Base Path header (TTL value, for 231 example). Nevertheless, SFFs are not supposed to act on the 232 Context Headers or look into the content of the Context Headers. 234 Discussion Note: This design decision should be discussed with 235 the working group. 237 Thus, the following requirements: 239 o Only Classifiers, SFC-aware SFs, and SFC proxies MUST be able to 240 encrypt and decrypt a given Context Header. 242 o Both encrypted and unecrypted Context Headers MAY be included in 243 the same NSH. That is, some Context Headers (TLVs) may be 244 protected while others do not. 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 8.1. 253 +---------------+-----------------------+---------------+ 254 | | Insert, remove, or | Update | 255 | | replace the NSH | the NSH | 256 | | | | 257 |SFC Data Plane +-------+-------+-------+-------+-------+ 258 | Element | | | |Dec. |Update | 259 | |Insert |Remove |Replace|Service|Context| 260 | | | | |Index |Header | 261 +---------------+-------+-------+-------+-------+-------+ 262 | | + | | + | | + | 263 |Classifier | | | | | | 264 +---------------+-------+-------+-------+-------+-------+ 265 |Service | | + | | | | 266 |Function | | | | | | 267 |Forwarder (SFF)| | | | | | 268 +---------------+-------+-------+-------+-------+-------+ 269 |Service | | | | + | + | 270 |Function (SF) | | | | | | 271 +---------------+-------+-------+-------+-------+-------+ 272 | | + | + | | + | + | 273 |SFC Proxy | | | | | | 274 +---------------+-------+-------+-------+-------+-------+ 276 Figure 1: NSH Actions 278 This document does not make any assumption about the service function 279 chains to be instantiated nor adds any constraint about how NSH can 280 be used within a domain. For example, in reference to Figure 2, the 281 solution accommodates deployment schemes such as: no Context Header 282 is inserted by the Classifier, a first SF inserts two Context Headers 283 that it encrypts, a second SF is entitled to access that encrypted 284 data but it is instructed to strip one particular Context Header, and 285 a third SF is instructed to strip the remaining Context Header. The 286 following behavior will thus be observed: 288 o No Context Header is inserted by the Classifier: it only proceeds 289 with the NSH integrity protection. The NSH encapsulated packet is 290 then forwarded to the next hop following [RFC7665]. 292 o Once the packet is received by SF1, and assuming integrity checks 293 succeed, SF1 inserts two Context Headers M1 and M2 that it 294 encrypts and recomputes the message integrity for the NSH data. 296 o Once the packet is received by SF2, and assuming integrity checks 297 succeed, SF2 decrypts M1 and M2, strips M2 (because its instructed 298 to do so via the SFC control plane), and then encrypts M1 and 299 recomputes the message integrity for the NSH data. 301 o Once the packet is received by SF3, and assuming integrity checks 302 succeed, SF3 decrypts M1, consumes the decrypted M1 data, and then 303 strips it from the NSH. The packet is then forwarded back to SFF3 304 by SF3 after recomputing the message integrity for the NSH data. 306 SF1 SF3 307 | | 308 Classifier---SFF1----SFF2---SFF3 309 | 310 SF2 312 Figure 2: SFC-enabled Domain Example 314 4. Design Overview 316 4.1. Supported Security Services 318 This specification provides the functions described in the following 319 sub-sections: 321 4.1.1. Encrypt All or a Subset of Context Headers 323 The solution allows to encrypt all or a subset of NSH Context Headers 324 by Classifiers, SFC-aware SFs, and SFC proxies. As depicted in 325 Table 1, SFFs are not involved in data encryption. This memo 326 enforces this design approach by encrypting a Context Header with 327 keys that are not supplied to SFFs, thus enforcing this limitation by 328 protocol (rather than requirements language). 330 +-----------------+------------------------------+------------------+ 331 | Data Plane | Base and Service Headers | Metadata | 332 | Element | Encryption | Encryption | 333 +-----------------+------------------------------+------------------+ 334 | Classifier | No | Yes | 335 | SFF | No | No | 336 | SFC-aware SF | No | Yes | 337 | SFC Proxy | No | Yes | 338 | SFC-unaware SF | No | No | 339 +-----------------+------------------------------+------------------+ 341 Table 1: Encryption Function Supported by SFC Data Plane Elements 343 The SFC control plane is assumed to instruct the Classifier(s), SFC- 344 aware SFs, and SFC proxies with the set of Context Headers (privacy- 345 sensitive metadata, typically) that must be encrypted. Encryption 346 keying material is only provided to these SFC data elements. 348 The control plane may also indicate the set of SFC data plane 349 elements that are entitled to supply a given context header (e.g., in 350 reference to their identifiers as assigned within the SFC-enabled 351 domain). It is out of the scope of this document to elaborate on how 352 such instructions are provided to the appropriate SFC data plane 353 elements, nor to detail the structure used to store the instructions. 355 The Service Path Header (Section 2 of [RFC8300]) is not encrypted 356 because SFFs use Service Index (SI) in conjunction with Service Path 357 Identifier (SPI) for determining the next SF in the path. 359 4.1.2. Integrity Protection 361 The solution provides integrity protection for NSH data. Two flavors 362 are supported. 364 A first flavor where all NSH data except the Base Header are 365 integrity protected (Figure 3). In this case, the NSH imposer may be 366 a Classifier, an SFC-aware SF, or an SFC proxy. SFFs are not thus 367 provided with authentication material. Further details are discussed 368 in Section 5.1. 370 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 371 | Transport Encapsulation | 372 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+... 373 | Base Header | | 374 +->+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ N 375 | | Service Path Header | S 376 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ H 377 | | Context Header(s) | | 378 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+... 379 | | Original Packet | 380 +->+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 381 | 382 +------Scope of integrity protected data 384 Figure 3: First Integrity Flavor 386 A second flavor where all NSH data, including the Base Header, are 387 integrity protected (Figure 4). In this case, the NSH imposer may be 388 a Classifier, an SFC-aware SF, an SFF, or an SFC proxy. Further 389 details are provided in Section 5.2. 391 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 392 | Transport Encapsulation | 393 +->+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+... 394 | | Base Header | | 395 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ N 396 | | Service Path Header | S 397 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ H 398 | | Context Header(s) | | 399 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+... 400 | | Original Packet | 401 +->+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 402 | 403 +----Scope of integrity protected data 405 Figure 4: Second Integrity Flavor 407 The integrity protection scope is explicitly signaled to SFC-aware 408 SFs and SFC proxies in the NSH by means of a dedicated MD Type 409 (Section 5). 411 In both flavors, the unencrypted Context Headers and the packet on 412 which NSH is imposed are subject to integrity protection. 414 Table 2 lists the roles of SFC data plane elements in providing 415 integrity protection for the NSH. 417 +--------------------+----------------------------------------+ 418 | Data Plane Element | Integrity Protection | 419 +--------------------+----------------------------------------+ 420 | Classifier | Yes | 421 | SFF | No (first flavor); Yes (second flavor) | 422 | SFC-aware SF | Yes | 423 | SFC Proxy | Yes | 424 | SFC-unaware SF | No | 425 +--------------------+----------------------------------------+ 427 Table 2: Integrity Protection Supported by SFC Data Plane Elements 429 4.2. One Secret Key, Two Security Services 431 The authenticated encryption algorithm defined in [RFC7518] is used 432 to provide NSH data integrity and to encrypt the Context Headers 433 carrying privacy-sensitive metadata. 435 The authenticated encryption algorithm provides a unified encryption 436 and authentication operation which turns plaintext into authenticated 437 ciphertext and vice versa. The generation of secondary keys MAC_KEY 438 and ENC_KEY from the secret key (K) is discussed in Section 5.2.2.1 439 of [RFC7518]: 441 o The ENC_KEY is used for encrypting the Context Headers and the 442 message integrity of the NSH data is calculated using the MAC_KEY. 444 o If the Context Headers are not encrypted, the Hashed Message 445 Authentication Mode (HMAC) algorithm discussed in [RFC4868] is 446 used to integrity protect the NSH data. 448 The advantage of using the authenticated encryption algorithm is that 449 SFC-aware SFs and SFC proxies only need to re-compute the message 450 integrity of the NSH data after decrementing the Service Index (SI) 451 and do not have to re-compute the ciphertext. The other advantage is 452 in both the flavors discussed above is that SFFs do not have access 453 to the ENC_KEY and cannot act on the encrypted Context Headers and, 454 only in case of the second flavor, SFFs do have access to the 455 MAC_KEY. Similarly, an SFC-aware SF or SFC proxy not allowed to 456 decrypt the Context Headers will not have access to the ENC_KEY. 458 The authenticated encryption algorithm or HMAC algorithm to be used 459 by SFC data plane elements is typically controlled using the SFC 460 control plane. Mandatory to implement authenticated encryption and 461 HMAC algorithms are listed in Section 4.3. 463 The authenticated encryption process takes as input four octet 464 strings: a secret key (K), a plaintext (P), Additional Authenticated 465 Data (A) (which contains the data to be authenticated, but not 466 encrypted), and an Initialization Vector (IV). The ciphertext value 467 (E) and the Authentication Tag value (T) are provided as outputs. 469 In order to decrypt and verify, the cipher takes as input K, IV, A, 470 T, and E. The output is either the plaintext or an error indicating 471 that the decryption failed as described in Section 5.2.2.2 of 472 [RFC7518]. 474 4.3. Mandatory-to-Implement Authenticated Encryption and HMAC 475 Algorithms 477 Classifiers, SFC-aware SFs, and SFC proxies MUST implement the 478 AES_128_CBC_HMAC_SHA_256 algorithm and SHOULD implement the 479 AES_192_CBC_HMAC_SHA_384 and AES_256_CBC_HMAC_SHA_512 algorithms. 481 Classifiers, SFC-aware SFs, and SFC proxies MUST implement the HMAC- 482 SHA-256-128 algorithm and SHOULD implement the HMAC-SHA-384-192 and 483 HMAC-SHA-512-256 algorithms. 485 SFFs MAY implement the aforementioned cipher suites and HMAC 486 algorithms. 488 o Note: The use of AES-GCM + HMAC may have CPU and packet size 489 implications (need for a second 128-bit authentication tag). 491 4.4. Key Management 493 The procedure for the allocation/provisioning of secret keys (K) and 494 authenticated encryption algorithm or MAC_KEY and HMAC algorithm is 495 outside the scope of this specification. As such, this specification 496 does not mandate the support of any specific mechanism. 498 The documents does not assume nor preclude the following: 500 o The same keying material is used for all the service functions 501 used within an SFC-enabled domain. 503 o Distinct keying material is used per SFP by all involved SFC data 504 path elements. 506 o Per-tenant keys are used. 508 In order to accommodate deployments relying upon keying material per 509 SFC/SFP and also the need to update keys after encrypting NSH data 510 for certain amount of time, this document uses key identifier (kid) 511 to unambiguously identify the appropriate keying material. Doing so 512 allows to address the problem of synchronization of keying material. 514 Additional information on manual vs. automated key management and 515 when one should be used over the other can be found in [RFC4107]. 517 4.5. New NSH Variable-Length Context Headers 519 New NSH Variable-Length Context Headers are defined in Section 5 for 520 NSH data integrity protection and, optionally, encryption of Context 521 Headers carrying privacy-sensitive metadata. Concretely, an NSH 522 imposer includes (1) the key identifier to identify the keying 523 material, (2) the timestamp to protect against replay attacks 524 (Section 7.4), and (3) the Message Authentication Code (MAC) for the 525 target NSH data (depending on the integrity protection scope) 526 calculated using the MAC_KEY and optionally Context Headers encrypted 527 using ENC_KEY. 529 An NSH data plane element that needs to check the integrity of the 530 NSH data uses the MAC_KEY and the HMAC algorithm for the key 531 identifier being carried in the NSH. 533 An SFC-aware SF or SFC proxy that needs to decrypt some Context 534 Headers uses ENC_Key and the decryption algorithm for the key 535 identifier being carried in the NSH. 537 Section 7 specifies the detailed procedure. 539 4.6. Encapsulation of NSH within NSH 541 As discussed in [RFC8459], an SFC-enabled domain (called, upper-level 542 domain) may be decomposed into many sub-domains (called, lower-level 543 domains). In order to avoid maintaining state to restore back upper- 544 lower NSH information at the boundaries of lower-level domains, two 545 NSH levels are used: an Upper-NSH which imposed at the boundaries of 546 the upper-level domain, and a Lower-NSH that is pushed by the 547 Classifier of a lower-level domain in front of the original NSH 548 (Figure 5). As such, the Upper-NSH information is carried along the 549 lower-level chain without modification. The packet is forwarded in 550 the top-level domain according to the Upper-NSH, while it is 551 forwarded according to the Lower-NSH in a lower-level SFC domain. 553 +---------------------------------+ 554 | Transport Encapsulation | 555 +->+---------------------------------+ 556 | | Lower-NSH Header | 557 | +---------------------------------+ 558 | | Upper-NSH Header | 559 | +---------------------------------+ 560 | | Original Packet | 561 +->+---------------------------------+ 562 | 563 | 564 +----Scope of NSH security protection 565 provided by a lower-level domain 567 Figure 5: Encapsulation of NSH within NSH 569 SFC data plane elements of a lower-level domain includes the Upper- 570 NSH when computing the MAC. 572 Keying material used at the upper-level domain should not the same as 573 the one used by a lower-level domain. 575 5. New NSH Variable-Length Context Headers 577 This section specifies the format of new Variable-Length Context 578 headers that are used for NSH integrity protection and, optionally, 579 Context Headers encryption. 581 In particular, this section defines two MAC and Encrypted Metadata 582 Context Headers; each having specific deployment constraints. Unlike 583 the flavor discussed in Section 5.1, the flavor sketched in 584 Section 5.2 requires sharing MAC_KEY with SFFs. Both TLVs have the 585 same format as shown in Section 5. 587 0 1 2 3 588 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 589 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 590 | Metadata Class | Type |U| Length | 591 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 592 | Key Length | Key Identifier (Variable) ~ 593 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 594 ~ Timestamp (8 bytes) ~ 595 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 596 | IV Length | Initialization Vector (Variable) ~ 597 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 598 | | 599 | Message Authentication Code and optional Encrypted | 600 ~ Context Headers ~ 601 | | 602 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 604 Figure 6: MAC and Encrypted Metadata Context Header 606 5.1. MAC#1 Context Header 608 MAC#1 Context Header is a variable-length TLV that carries the 609 Message Authentication Code (MAC) for the Service Path Header, 610 Context Headers, and the inner packet on which NSH is imposed, 611 calculated using MAC_KEY and optionally Context Headers encrypted 612 using ENC_KEY. The scope of this TLV is depicted in Figure 7. 614 This MAC flavor does not require sharing MAC_KEY with SFFs. It does 615 not require to re-compute the MAC by each SFF because of TTL 616 processing. Section 8.1 discusses the possible threat associated 617 with this flavor. 619 0 1 2 3 620 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 621 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 622 |Ver|O|U| TTL | Length |U|U|U|U|MD Type| Next Protocol | 623 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<--+ 624 | Service Path Identifier | Service Index | | 625 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 626 | | | 627 ~ Variable-Length Unencrypted Context Headers (opt.) ~ | 628 | | | 629 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 630 | Metadata Class | Type |U| Length | | 631 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 632 | Key Length | Key Identifier ~ | 633 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 634 ~ Timestamp (8 bytes) ~ | 635 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 636 | IV Length | Initialization Vector ~ | 637 +->+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 638 | ~ Context Header TLVs to encrypt ~ | 639 +->+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 640 | | | | 641 | ~ Inner Packet on which NSH is imposed ~ | 642 | | | | 643 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<--| 644 | | 645 | | 646 | | 647 | Integrity protected Portion----+ 648 +----Encrypted Portion 650 Figure 7: Scope of MAC#1 652 In reference to Figure 6, the description of the fields is as 653 follows: 655 o Metadata Class: MUST be set to 0x0 [RFC8300]. 657 o Type: TBD1 (See Section 9) 659 o U: Unassigned bit [RFC8300]. 661 o Length: Variable. 663 o Key Length: Variable. Carries the length of the key identifier. 665 o Key Identifier: Carries a variable length Key Identifier object 666 used to identify and deliver keys to SFC data plane elements. 668 This identifier is helpful to accommodate deployments relying upon 669 keying material per SFC/SFP. The key identifier helps in 670 resolving the problem of synchronization of keying material. 672 o Timestamp: Carries an unsigned 64-bit integer value that is 673 expressed in seconds relative to 1970-01-01T00:00Z in UTC time. 674 See Section 6 for more details. 676 o IV Length: Carries the length of the IV (Section 5.2 of 677 [RFC7518]). If HMAC algorithm is used, IV length is set to zero. 679 o Initialization Vector: Carries the IV for authenticated encryption 680 algorithm as discussed in Section 5.2 of [RFC7518]. 682 o The Additional Authenticated Data (defined in [RFC7518]) MUST be 683 the Service Path header, the unencrypted Context headers, and the 684 inner packet on which NSH is imposed . 686 o Message Authentication Code covering the entire NSH data excluding 687 the Base header. 689 5.2. MAC#2 Context Header 691 MAC#2 Context Header is a variable-length TLV that carries the MAC 692 for the entire NSH data calculated using MAC_KEY and optionally 693 Context Headers encrypted using ENC_KEY. The scope of this TLV is 694 depicted in Figure 8. 696 0 1 2 3 697 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 698 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<--+ 699 |Ver|O|U| TTL | Length |U|U|U|U|MD Type| Next Protocol | | 700 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 701 | Service Path Identifier | Service Index | | 702 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 703 | | | 704 ~ Variable-Length Unencrypted Context Headers (opt.) ~ | 705 | | | 706 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 707 | Metadata Class | Type |U| Length | | 708 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 709 | Key Length | Key Identifier ~ | 710 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 711 ~ Timestamp (8 bytes) ~ | 712 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 713 | IV Length | Initialization Vector | | 714 +->+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 715 | ~ Context Header TLVs to encrypt ~ | 716 +->+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 717 | | | | 718 | ~ Inner Packet on which NSH is imposed ~ | 719 | | | | 720 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<--| 721 | | 722 | | 723 | | 724 | Integrity protected Portion----+ 725 +----Encrypted Portion 727 Figure 8: Scope of MAC#2 729 In reference to Figure 6, the description of the fields is as 730 follows: 732 o Metadata Class: MUST be set to 0x0 [RFC8300]. 734 o Type: TBD2 (See Section 9) 736 o U: Unassigned bit [RFC8300]. 738 o Length: Variable. 740 o Key Length: See Section 5.1. 742 o Key Identifier: See Section 5.1. 744 o Timestamp: See Section 5.1. 746 o IV Length: See Section 5.1. 748 o Initialization Vector: See Section 5.1. 750 o The Additional Authenticated Data (defined in [RFC7518]) MUST be 751 the entire NSH data (i.e., including the Base Header) excluding 752 the Context Headers to be encrypted. 754 o Message Authentication Code covering the entire NSH data and 755 optional encrypted Context Headers. 757 6. Timestamp Format 759 This section follows the template provided in 760 [I-D.ietf-ntp-packet-timestamps]. 762 The format of the Timestamp field introduced in Section 5 is depicted 763 in Figure 9. 765 0 1 2 3 766 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 767 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 768 | Seconds | 769 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 770 | Fraction | 771 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 773 Figure 9: Timestamp Field Format 775 Timestamp field format: 777 Seconds: specifies the integer portion of the number of seconds 778 since the epoch. 780 + Size: 32 bits. 782 + Units: seconds. 784 Fraction: specifies the fractional portion of the number of 785 seconds since the epoch. 787 + Size: 32 bits. 789 + Units: the unit is 2^(-32) seconds, which is roughly equal to 790 233 picoseconds. 792 Epoch: 794 The epoch is 1970-01-01T00:00Z in UTC time. 796 Leap seconds: 798 This timestamp format is affected by leap seconds. The timestamp 799 represents the number of seconds elapsed since the epoch minus the 800 number of leap seconds. 802 Resolution: 804 The resolution is 2^(-32) seconds. 806 Wraparound: 808 This time format wraps around every 2^32 seconds, which is roughly 809 136 years. The next wraparound will occur in the year 2106. 811 Synchronization aspects: 813 It is assumed that SFC data plane elements are synchronized to UTC 814 using a synchronization mechanism that is outside the scope of 815 this document. In typical deployments SFC data plane elements use 816 NTP [RFC5905] for synchronization. Thus, the timestamp may be 817 derived from the NTP-synchronized clock, allowing the timestamp to 818 be measured with respect to the clock of an NTP server. Since the 819 NTP time format is affected by leap seconds, the current timestamp 820 format is similarly affected. Therefore, the value of a timestamp 821 during or slightly after a leap second may be temporarily 822 inaccurate. 824 7. Processing Rules 826 The following sub-sections describe the processing rules for 827 integrity protected NSH and optionally encrypted Context Headers. 829 7.1. Generic Behavior 831 This document adheres to the recommendations in [RFC8300] for 832 handling the Context Headers at both ingress and egress SFC boundary 833 nodes. That is, to strip such context headers. 835 Failures to inject or validate the Context Headers defined in this 836 document SHOULD be logged locally while a notification alarm MAY be 837 sent to an SFC Control Element. Similarly, failure to validate the 838 integrity of the NSH data MUST cause that packet to be discarded 839 while a notification alarm MAY be sent to an SFC Control Element. 841 The details of sending notification alarms (i.e., the parameters 842 affecting the transmission of the notification alarms depend on the 843 information in the context header such as frequency, thresholds, and 844 content in the alarm) SHOULD be configurable by the SFC control 845 plane. 847 SFC-aware SFs and SFC proxies MAY be instructed to strip some 848 encrypted Context Headers from the packet or to pass the data to the 849 next SF in the service function chain after processing the content of 850 the Context Headers. If no instruction is provided, the default 851 behavior for intermediary SFC-aware nodes is to maintain such Context 852 Headers so that the information can be passed to next SFC-aware hops. 853 SFC-aware SFs and SFC proxies must re-apply the integrity protection 854 if any modification is made to the Context Headers (strip a Context 855 Header, update the content of an existing Context Header, insert a 856 new Context Header). 858 An SFC-aware SF or SFC proxy that is not allowed to decrypt any 859 Context Headers MUST NOT be given access to the ENC_KEY. 861 Otherwise, an SFC-aware SF or SFC proxy that receives encrypted 862 Context Headers, for which it is not allowed to consume a specific 863 Context Header it decrypts (but consumes others), MUST keep that 864 Context Header unaltered when forwarding the packet upstream. 866 Only one instance of MAC and Encrypted Metadata Context Header is 867 allowed. If multiple instances of MAC and Encrypted Metadata Context 868 Header are included in an NSH packet, the SFC data element must 869 process the first instance and ignore subsequent instances, and may 870 log or increase a counter for this event as per Section 2.5.1 of 871 [RFC8300]. 873 MTU and fragmentation considerations are discussed in Section 5 of 874 [RFC8300]. Those considerations are not reiterated here. 876 7.2. MAC NSH Data Generation 878 If the Context Headers are not encrypted, the HMAC algorithm 879 discussed in [RFC4868] is used to integrity protect the target NSH 880 data. An NSH imposer inserts a "MAC and Encrypted Metadata" Context 881 Header for integrity protection (Section 5). 883 The NSH imposer computes the message integrity for the target NSH 884 data (depending on the integrity protection scope discussed in 885 Section 5) using MAC_KEY and HMAC algorithm. It inserts the MAC in 886 the "MAC and Encrypted Metadata" Context Header. The length of the 887 MAC is decided by the HMAC algorithm adopted for the particular key 888 identifier. 890 The Message Authentication Code (T) computation process can be 891 illustrated as follows: 893 T = HMAC-SHA-256-128(MAC_KEY, A) 895 An entity in the SFP that intends to update NSH MUST follow the above 896 behavior to maintain message integrity of the NSH for subsequent 897 validations. 899 7.3. Encrypted NSH Metadata Generation 901 An NSH imposer can encrypt Context Headers carrying privacy-sensitive 902 metadata, i.e., encrypted and unencrypted metadata may be carried 903 simultaneously in the same NSH packet (Figure 10). 905 0 1 2 3 906 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 907 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 908 |Ver|O|U| TTL | Length |U|U|U|U|MD Type| Next Protocol | 909 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 910 | Service Path Identifier | Service Index | 911 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 912 | | 913 ~ Variable-Length Unencrypted Context Headers (opt.) ~ 914 | | 915 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 916 ~ Key Identifier ~ 917 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 918 ~ Timestamp ~ 919 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 920 | | 921 ~ MAC and Encrypted Context Headers ~ 922 | | 923 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 925 Figure 10: NSH with Encrypted and Unencrypted Metadata 927 In an SFC-enabled domain where pervasive monitoring [RFC7258] is 928 possible, all Context Headers carrying privacy-sensitive metadata 929 MUST be encrypted; doing so privacy-sensitive metadata is not 930 revealed to attackers. Privacy specific threats are discussed in 931 Section 5.2 of [RFC6973]. 933 Using K and authenticated encryption algorithm, the NSH imposer 934 encrypts the Context Headers (as set by the control plane Section 3), 935 computes the message integrity for the target NSH data and inserts 936 the resulting payload in the "MAC and Encrypted Metadata" Context 937 Header (Section 5). The entire TLV carrying a privacy-sensitive 938 metadata is encrypted (that is, including the MD Class, Type, Length, 939 and associated metadata of each Context Header). 941 The message Authentication Tag (T) and ciphertext (E) computation 942 process can be illustrated as follows: 944 MAC_KEY = initial MAC_KEY_LEN octets of K, 945 ENC_KEY = final ENC_KEY_LEN octets of K, 946 E = CBC-PKCS7-ENC(ENC_KEY, P), 947 M = MAC(MAC_KEY, A || IV || E || AL), 948 T = initial T_LEN octets of M. 949 MAC and Encrypted Metadata = E || T 951 As specified in [RFC7518], the octet string (AL) is equal to the 952 number of bits in the Additional Authenticated Data (A) expressed as 953 a 64-bit unsigned big-endian integer. 955 An authorized entity in the SFP that intends to update the content of 956 an encrypted Context Header or needs to add a new encrypted Context 957 Header MUST also follow the aforementioned behavior. 959 An SFF or SFC-aware SF or SFC proxy that only has access to the 960 MAC_KEY, but not the ENC_KEY, computes the message Authentication Tag 961 (T) after decrementing the TTL (by the SFF) or SI (by an SF or SFC 962 proxy) and replaces the Authentication Tag in the NSH with the 963 computed Authentication Tag. Similarly, an SFC-aware SF (or SFC 964 proxy) that does not modify the encrypted Context headers also 965 follows the aforementioned behavior. 967 The message Authentication Tag (T) computation process can be 968 illustrated as follows: 970 M = MAC(MAC_KEY, A || IV || E || AL), 971 T = initial T_LEN octets of M. 973 7.4. Timestamp for Replay Attack 975 The received NSH is accepted if the Timestamp (TS) in the NSH is 976 recent enough to the reception time of the NSH (TSrt). The following 977 formula is used for this check: 979 -Delta < (TSrt ? TS) < +Delta 981 The RECOMMENDED value for the allowed Delta is 2 seconds. If the 982 timestamp is not within the boundaries, then the SFC data plane 983 element receiving such packet MUST discard the NSH message. 985 All SFC data plane elements must be synchronized among themselves. 986 These elements may be synchronized to a global reference time. 988 o TODO: timestamp validation on the receiver needs further text 989 refinement. 991 7.5. NSH Data Validation 993 When an SFC data plane element receives an NSH packet, it MUST first 994 ensure that a MAC Context Header is included. It MUST silently 995 discard the message if the timestamp is invalid (described in 996 Section 7.4). It MUST log an error at least once per the SPI for 997 which the MAC Context Header is missing. 999 If the timestamp check is successfuly passed, the SFC data plane 1000 element should then proceed with NSH data integrity validation. The 1001 SFC data plane element computes the message integrity for the target 1002 NSH data (depending on the integrity protection scope discussed in 1003 Section 5) using the MAC_KEY and HMAC algorithm for the key 1004 identifier. If the value of the newly generated digest is identical 1005 to the one enclosed in NSH, the SFC data plane element is certain 1006 that the NSH data has not been tampered and validation is therefore 1007 successful. Otherwise, the NSH packet MUST be discarded. 1009 7.6. Decryption of NSH Metadata 1011 If entitled to consume a supplied encrypted Context Header, an SFC- 1012 aware SF or SFC proxy decrypts metadata using (K) and decryption 1013 algorithm for the key identifier in NSH. 1015 Authenticated encryption algorithm has only a single output, either a 1016 plaintext or a special symbol (FAIL) that indicates that the inputs 1017 are not authentic (Section 5.2.2.2 of [RFC7518]). 1019 8. Security Considerations 1021 NSH security considerations are discussed in Section 8 of [RFC8300]. 1022 The guidelines for cryptographic key management are discussed in 1023 [RFC4107]. 1025 The interaction between the SFC-aware data plane elements and a key 1026 management system MUST NOT be transmitted in clear since this would 1027 completely destroy the security benefits of the integrity protection 1028 solution defined in this document. The secret key (K) must have an 1029 expiration time assigned as the latest point in time before which the 1030 key may be used for integrity protection of NSH data and encryption 1031 of Context Headers. Prior to the expiration of the secret key, all 1032 participating service function nodes SHOULD have the control plane 1033 distribute an new key identifier and associated keying material, so 1034 that when the secret key is expired those nodes are prepared with the 1035 new secret key. This allows the NSH Imposer to switch to the new key 1036 identifier as soon as necessary. It is RECOMMENDED that the next key 1037 identifier be distributed by the control plane well prior to the 1038 secret key expiration time. 1040 NSH data are exposed to several threats: 1042 o A man-in-the-middle attacker modifying NSH data. 1044 o Attacker spoofing NSH data. 1046 o Attacker capturing and replaying NSH data. 1048 o Metadata in Context Headers revealing privacy-sensitive 1049 information to attackers. 1051 o Attacker replacing the packet on which NSH is imposed with a bogus 1052 or malicious packet. 1054 In an SFC-enabled domain where the above attacks are possible, NSH 1055 data MUST be integrity-protected and replay-protected, and privacy- 1056 sensitive NSH metadata MUST be encrypted for confidentiality 1057 preservation purposes. The Base and Service Path headers are not 1058 encrypted. 1060 Two MAC flavors are defined in Section 5. Considerations specific to 1061 each flavor are discussed in the following sub-sections. 1063 The attacks discussed in [I-D.nguyen-sfc-security-architecture] are 1064 handled owing to the solution specified in this document, except for 1065 attacks dropping packets. Such attacks can be detected relying upon 1066 statistical analysis; such analysis is out of scope of this document. 1067 Also, if SFFs are not involved in the integrity checks, a misbehaving 1068 SFF which decrements SI while this should be done by an SF (SF bypass 1069 attack) will be detected by an upstream SF because the integrity 1070 check will fail. 1072 8.1. MAC#1 1074 An active attacker can potentially modify the Base header (e.g., 1075 decrement the TTL so the next SFF in the SFP discards the NSH 1076 packet). In the meantime, an active attacker can also drop NSH 1077 packets. As such, this attack is not considered an attack against 1078 the security mechanism specified in the document. 1080 No device other than the SFC-aware SFs in the SFC-enabled domain 1081 should be able to update the integrity protected NSH data. 1082 Similarly, no device other than the SFC-aware SFs and SFC proxies in 1083 the SFC-enabled domain be able to decrypt and update the Context 1084 Headers carrying privacy-sensitive metadata. In other words, if the 1085 SFC-aware SFs and SFC proxies in the SFC-enabled domain are 1086 considered fully trusted to act on the NSH data, only they can have 1087 access to privacy-sensitive NSH metadata and the keying material used 1088 to integrity protect NSH data and encrypt Context Headers. 1090 8.2. MAC#2 1092 SFFs can detect whether an illegitimate node has altered the content 1093 of the Base header. Such messages MUST be discarded with appropriate 1094 logs and alarms generated. 1096 9. IANA Considerations 1098 This document requests IANA to assign the following types from the 1099 "NSH IETF-Assigned Optional Variable-Length Metadata Types" (0x0000 1100 IETF Base NSH MD Class) registry available at: 1101 https://www.iana.org/assignments/nsh/nsh.xhtml#optional-variable- 1102 length-metadata-types. 1104 +-------+-------------------------------+----------------+ 1105 | Value | Description | Reference | 1106 +-------+-------------------------------+----------------+ 1107 | TBD1 | MAC and Encrypted Metadata#1 | [ThisDocument] | 1108 | TBD2 | MAC and Encrypted Metadata#2 | [ThisDocument] | 1109 +-------+-------------------------------+----------------+ 1111 10. Acknowledgements 1113 This document was edited as a follow up to the discussion in 1114 IETF#104: https://datatracker.ietf.org/meeting/104/materials/slides- 1115 104-sfc-sfc-chair-slides-01 (slide 7). 1117 Thanks to Joel Halpern, Christian Jacquenet, Dirk von Hugo, Tal 1118 Mizrahi, and Daniel Migault for the comments. 1120 11. References 1122 11.1. Normative References 1124 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1125 Requirement Levels", BCP 14, RFC 2119, 1126 DOI 10.17487/RFC2119, March 1997, 1127 . 1129 [RFC4107] Bellovin, S. and R. Housley, "Guidelines for Cryptographic 1130 Key Management", BCP 107, RFC 4107, DOI 10.17487/RFC4107, 1131 June 2005, . 1133 [RFC4868] Kelly, S. and S. Frankel, "Using HMAC-SHA-256, HMAC-SHA- 1134 384, and HMAC-SHA-512 with IPsec", RFC 4868, 1135 DOI 10.17487/RFC4868, May 2007, 1136 . 1138 [RFC7518] Jones, M., "JSON Web Algorithms (JWA)", RFC 7518, 1139 DOI 10.17487/RFC7518, May 2015, 1140 . 1142 [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function 1143 Chaining (SFC) Architecture", RFC 7665, 1144 DOI 10.17487/RFC7665, October 2015, 1145 . 1147 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1148 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1149 May 2017, . 1151 [RFC8300] Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed., 1152 "Network Service Header (NSH)", RFC 8300, 1153 DOI 10.17487/RFC8300, January 2018, 1154 . 1156 11.2. Informative References 1158 [I-D.arkko-farrell-arch-model-t] 1159 Arkko, J. and S. Farrell, "Challenges and Changes in the 1160 Internet Threat Model", draft-arkko-farrell-arch-model- 1161 t-01 (work in progress), December 2019. 1163 [I-D.ietf-ntp-packet-timestamps] 1164 Mizrahi, T., Fabini, J., and A. Morton, "Guidelines for 1165 Defining Packet Timestamps", draft-ietf-ntp-packet- 1166 timestamps-07 (work in progress), August 2019. 1168 [I-D.nguyen-sfc-security-architecture] 1169 Nguyen, T. and M. Park, "A Security Architecture Against 1170 Service Function Chaining Threats", draft-nguyen-sfc- 1171 security-architecture-00 (work in progress), November 1172 2019. 1174 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, 1175 "Network Time Protocol Version 4: Protocol and Algorithms 1176 Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, 1177 . 1179 [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., 1180 Morris, J., Hansen, M., and R. Smith, "Privacy 1181 Considerations for Internet Protocols", RFC 6973, 1182 DOI 10.17487/RFC6973, July 2013, 1183 . 1185 [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an 1186 Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 1187 2014, . 1189 [RFC7498] Quinn, P., Ed. and T. Nadeau, Ed., "Problem Statement for 1190 Service Function Chaining", RFC 7498, 1191 DOI 10.17487/RFC7498, April 2015, 1192 . 1194 [RFC7635] Reddy, T., Patil, P., Ravindranath, R., and J. Uberti, 1195 "Session Traversal Utilities for NAT (STUN) Extension for 1196 Third-Party Authorization", RFC 7635, 1197 DOI 10.17487/RFC7635, August 2015, 1198 . 1200 [RFC8459] Dolson, D., Homma, S., Lopez, D., and M. Boucadair, 1201 "Hierarchical Service Function Chaining (hSFC)", RFC 8459, 1202 DOI 10.17487/RFC8459, September 2018, 1203 . 1205 Authors' Addresses 1207 Mohamed Boucadair 1208 Orange 1209 Rennes 35000 1210 France 1212 Email: mohamed.boucadair@orange.com 1214 Tirumaleswar Reddy 1215 McAfee, Inc. 1216 Embassy Golf Link Business Park 1217 Bangalore, Karnataka 560071 1218 India 1220 Email: TirumaleswarReddy_Konda@McAfee.com 1221 Dan Wing 1222 Citrix Systems, Inc. 1223 USA 1225 Email: dwing-ietf@fuggles.com