idnits 2.17.1 draft-ietf-sfc-nsh-integrity-01.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 16, 2020) is 1256 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 1113, but not defined ** Downref: Normative reference to an Informational RFC: RFC 7665 ** Downref: Normative reference to an Informational RFC: RFC 8877 == Outdated reference: A later version (-13) exists of draft-ietf-intarea-tunnels-10 Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SFC M. Boucadair 3 Internet-Draft Orange 4 Intended status: Standards Track T. Reddy 5 Expires: May 20, 2021 McAfee 6 D. Wing 7 Citrix 8 November 16, 2020 10 Integrity Protection for the Network Service Header (NSH) and Encryption 11 of Sensitive Context Headers 12 draft-ietf-sfc-nsh-integrity-01 14 Abstract 16 This specification adds integrity protection and optional encryption 17 of sensitive metadata directly to the Network Service Header (NSH) 18 used 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 20, 2021. 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 and Basic Requirements . . . . . . . . . . . . . 4 57 4. Design Overview . . . . . . . . . . . . . . . . . . . . . . . 6 58 4.1. Supported Security Services . . . . . . . . . . . . . . . 6 59 4.1.1. Encrypt All or a Subset of Context Headers . . . . . 6 60 4.1.2. Integrity Protection . . . . . . . . . . . . . . . . 7 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 . . . . . . . . . . . . . . . . . . . . . 10 65 4.5. New NSH Variable-Length Context Headers . . . . . . . . . 11 66 4.6. Encapsulation of NSH within NSH . . . . . . . . . . . . . 11 67 5. New NSH Variable-Length Context Headers . . . . . . . . . . . 12 68 5.1. MAC#1 Context Header . . . . . . . . . . . . . . . . . . 13 69 5.2. MAC#2 Context Header . . . . . . . . . . . . . . . . . . 15 70 6. Timestamp Format . . . . . . . . . . . . . . . . . . . . . . 17 71 7. Processing Rules . . . . . . . . . . . . . . . . . . . . . . 18 72 7.1. Generic Behavior . . . . . . . . . . . . . . . . . . . . 18 73 7.2. MAC NSH Data Generation . . . . . . . . . . . . . . . . . 19 74 7.3. Encrypted NSH Metadata Generation . . . . . . . . . . . . 20 75 7.4. Timestamp for Replay Attack . . . . . . . . . . . . . . . 21 76 7.5. NSH Data Validation . . . . . . . . . . . . . . . . . . . 22 77 7.6. Decryption of NSH Metadata . . . . . . . . . . . . . . . 22 78 8. MTU Considerations . . . . . . . . . . . . . . . . . . . . . 22 79 9. Security Considerations . . . . . . . . . . . . . . . . . . . 23 80 9.1. MAC#1 . . . . . . . . . . . . . . . . . . . . . . . . . . 24 81 9.2. MAC#2 . . . . . . . . . . . . . . . . . . . . . . . . . . 25 82 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 83 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25 84 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 85 12.1. Normative References . . . . . . . . . . . . . . . . . . 25 86 12.2. Informative References . . . . . . . . . . . . . . . . . 26 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 89 1. Introduction 91 Many advanced Service Functions (SFs) are enabled for the delivery of 92 value-added services. Typically, SFs are used to meet various 93 service objectives such as IP address sharing, avoiding covert 94 channels, detecting Denial-of-Service (DoS) attacks and protecting 95 network infrastructures against them, network slicing, etc. Because 96 of the proliferation of such advanced SFs together with complex 97 service deployment constraints that demand more agile service 98 delivery procedures, operators need to rationalize their service 99 delivery logics and master their complexity while optimising service 100 activation time cycles. The overall problem space is described in 101 [RFC7498]. 103 [RFC7665] presents a data plane architecture addressing the 104 problematic aspects of existing service deployments, including 105 topological dependence and configuration complexity. It also 106 describes an architecture for the specification, creation, and 107 maintenance of Service Function Chains (SFCs) within a network. That 108 is, how to define an ordered set of SFs and ordering constraints that 109 must be applied to packets/flows selected as a result of traffic 110 classification. [RFC8300] specifies the SFC encapsulation: Network 111 Service Header (NSH). 113 The NSH data is unauthenticated and unencrypted [RFC8300], forcing a 114 service topology that requires security and privacy to use a 115 transport encapsulation that supports such features. Note that some 116 transport encapsulation (e.g., IPsec) only provide hop-by-hop 117 security between two SFC data plane elements (e.g., two Service 118 Function Forwarders (SFFs), SFF to SF) and do not provide SF-to-SF 119 security of NSH metadata. For example, if IPsec is used, SFFs or SFs 120 within a Service Function Path (SFP) not authorized to access the 121 privacy-sensitive metadata will have access to the metadata. As a 122 reminder, the metadata referred to is an information that is inserted 123 by Classifiers or intermediate SFs and shared with downstream SFs; 124 such information is not visible to the communication endpoints 125 (Section 4.9 of [RFC7665]). 127 The lack of such capability was reported during the development of 128 [RFC8300] and [RFC8459]. The reader may refer to Section 3.2.1 of 129 [I-D.arkko-farrell-arch-model-t] for a discussion on the need for 130 more awareness about attacks from within closed domains. 132 This specification fills that gap. Concretely, this document adds 133 integrity protection and optional encryption of sensitive metadata 134 directly to the NSH (Section 4); integrity protects the packet 135 payload and provides replay protection (Section 7.4). Thus, the NSH 136 does not have to rely upon an underlying transport encapsulation for 137 security and confidentiality. 139 This specification introduces new Variable-Length Context Headers to 140 carry fields necessary for integrity protected NSH headers and 141 encrypted Context Headers (Section 5), and is therefore only 142 applicable to NSH MD Type 0x02 (Section 2.5 of [RFC8300]). MTU 143 considerations are discussed in Section 8. 145 This specification limits thus access to an information within an SFP 146 to entities that have a need to interpret it. 148 2. Terminology 150 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 151 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 152 "OPTIONAL" in this document are to be interpreted as described in BCP 153 14 [RFC2119][RFC8174] when, and only when, they appear in all 154 capitals, as shown here. 156 This document makes use of the terms defined in [RFC7665] and 157 [RFC8300]. 159 The document defines the following terms: 161 o SFC data plane element: Refers to NSH-aware SF, SFF, SFC Proxy, or 162 Classifier as defined in the SFC data plane architecture [RFC7665] 163 and further refined in [RFC8300]. 165 o SFC control element: A logical entity that instructs one or more 166 SFC data plane elements on how to process NSH packets within an 167 SFC-enabled domain. 169 o Key Identifier: A key identifier used to identify and deliver keys 170 to authorized entities. See for example, 'kid' usage in 171 [RFC7635]. 173 o NSH data: The NSH is composed of a Base Header, a Service Path 174 Header, and optional Context Headers. NSH data refers to all the 175 above headers and the packet or frame on which the NSH is imposed 176 to realize an SFP. 178 o NSH imposer: Refers to the SFC data plane element that is entitled 179 to impose the NSH with the Context Headers defined in this 180 document. 182 3. Assumptions and Basic Requirements 184 Section 2 of [RFC8300] specifies that the NSH data can be spread over 185 three headers: 187 o Base Header: Provides information about the service header and the 188 payload protocol. 190 o Service Path Header: Provides path identification and location 191 within an SFP. 193 o Context Header(s): Carries metadata (i.e., context data) along a 194 service path. 196 The NSH allows to share context information (a.k.a., metadata) with 197 downstream NSH-aware data elements on a per SFC/SFP basis. To that 198 aim: 200 The control plane is used to instruct the Classifier about the set 201 of context information to be supplied for a given service function 202 chain. 204 The control plane is also used to instruct an NSH-aware SF about 205 any metadata it needs to attach to packets for a given service 206 function chain. This instruction may occur any time during the 207 validity lifetime of an SFC/SFP. The control plane may indicate, 208 for a given service function chain, an order for consuming a set 209 of contexts supplied in a packet. 211 An NSH-aware SF can also be instructed about the behavior it 212 should adopt after consuming a context information that was 213 supplied in the NSH. For example, the context can be maintained, 214 updated, or stripped. 216 An SFC Proxy may be instructed about the behavior it should adopt 217 to process the context information that was supplied in the NSH on 218 behalf of an NSH-unaware SF (e.g., the context can be maintained 219 or stripped). The SFC Proxy may also be instructed to add some 220 new context information into the NSH on behalf of an NSH-unaware 221 SF. 223 In reference to Figure 1, 225 o Classifiers, NSH-aware SFs, and SFC proxies are entitled to update 226 the Context Header(s). 228 o Only NSH-aware SFs and SFC proxies are entitled to update the 229 Service Path Header. 231 o SFFs are entitled to modify the Base Path header (TTL value, for 232 example). Nevertheless, SFFs are not supposed to act on the 233 Context Headers or look into the content of the Context Headers. 235 Thus, the following requirements: 237 o Only Classifiers, NSH-aware SFs, and SFC proxies MUST be able to 238 encrypt and decrypt a given Context Header. 240 o Both encrypted and unecrypted Context Headers MAY be included in 241 the same NSH. That is, some Context Headers (TLVs) may be 242 protected while others do not. 244 o The solution MUST provide integrity protection for the Service 245 Path Header. 247 o The solution MAY provide integrity protection for the Base Header. 248 The implications of disabling such checks are discussed in 249 Section 9.1. 251 +----------------+-----------------------------+-------------------+ 252 | | Insert, remove, or replace | Update the NSH | 253 | | the NSH | | 254 | | | | 255 | SFC Data Plane +---------+---------+---------+---------+---------+ 256 | Element | | | |Decrement| Update | 257 | | Insert | Remove | Replace | Service | Context | 258 | | | | | Index |Header(s)| 259 +================+=========+=========+=========+=========+=========+ 260 | | + | | + | | + | 261 | Classifier | | | | | | 262 +----------------+---------+---------+---------+---------+---------+ 263 |Service Function| | + | | | | 264 |Forwarder (SFF) | | | | | | 265 +----------------+---------+---------+---------+---------+---------+ 266 |Service Function| | | | + | + | 267 | (SF) | | | | | | 268 +----------------+---------+---------+---------+---------+---------+ 269 | | + | + | | + | + | 270 | SFC Proxy | | | | | | 271 +----------------+---------+---------+---------+---------+---------+ 273 Figure 1: Summary of NSH Actions 275 4. Design Overview 277 4.1. Supported Security Services 279 This specification provides the functions described in the following 280 subsections: 282 4.1.1. Encrypt All or a Subset of Context Headers 284 The solution allows to encrypt all or a subset of NSH Context Headers 285 by Classifiers, NSH-aware SFs, and SFC proxies. 287 As depicted in Table 1, SFFs are not involved in data encryption. 288 This document enforces this design approach by encrypting Context 289 Headers with keys that are not supplied to SFFs, thus enforcing this 290 limitation by protocol (rather than requirements language). 292 +-----------------+------------------------------+------------------+ 293 | Data Plane | Base and Service Headers | Metadata | 294 | Element | Encryption | Encryption | 295 +-----------------+------------------------------+------------------+ 296 | Classifier | No | Yes | 297 | SFF | No | No | 298 | NSH-aware SF | No | Yes | 299 | SFC Proxy | No | Yes | 300 | NSH-unaware SF | No | No | 301 +-----------------+------------------------------+------------------+ 303 Table 1: Encryption Function Supported by SFC Data Plane Elements 305 The SFC control plane is assumed to instruct the Classifier(s), NSH- 306 aware SFs, and SFC proxies with the set of Context Headers (privacy- 307 sensitive metadata, typically) that must be encrypted. Encryption 308 keying material is only provided to these SFC data elements. 310 The control plane may also indicate the set of SFC data plane 311 elements that are entitled to supply a given Context Header (e.g., in 312 reference to their identifiers as assigned within the SFC-enabled 313 domain). It is out of the scope of this document to elaborate on how 314 such instructions are provided to the appropriate SFC data plane 315 elements, nor to detail the structure used to store the instructions. 317 The Service Path Header (Section 2 of [RFC8300]) is not encrypted 318 because SFFs use Service Index (SI) in conjunction with Service Path 319 Identifier (SPI) for determining the next SF in the path. 321 4.1.2. Integrity Protection 323 The solution provides integrity protection for the NSH data. Two 324 levels of assurance (LoAs) are supported. 326 A first level of assurance where all NSH data except the Base Header 327 are integrity protected (Figure 2). In this case, the NSH imposer 328 may be a Classifier, an NSH-aware SF, or an SFC Proxy. SFFs are not 329 thus provided with authentication material. Further details are 330 discussed in Section 5.1. 332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 333 | Transport Encapsulation | 334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+... 335 | Base Header | | 336 +->+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ N 337 | | Service Path Header | S 338 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ H 339 | | Context Header(s) | | 340 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+... 341 | | Original Packet | 342 +->+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 343 | 344 +------Scope of integrity protected data 346 Figure 2: First Level of Assurance 348 A second level of assurance where all NSH data, including the Base 349 Header, are integrity protected (Figure 3). In this case, the NSH 350 imposer may be a Classifier, an NSH-aware SF, an SFF, or an SFC 351 Proxy. Further details are provided in Section 5.2. 353 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 354 | Transport Encapsulation | 355 +->+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+... 356 | | Base Header | | 357 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ N 358 | | Service Path Header | S 359 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ H 360 | | Context Header(s) | | 361 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+... 362 | | Original Packet | 363 +->+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 364 | 365 +----Scope of integrity protected data 367 Figure 3: Second Level of Assurance 369 The integrity protection scope is explicitly signaled to NSH-aware 370 SFs and SFC proxies in the NSH by means of a dedicated MD Type 371 (Section 5). 373 In both levels of assurance, the unencrypted Context Headers and the 374 packet on which the NSH is imposed are subject to integrity 375 protection. 377 Table 2 lists the roles of SFC data plane elements in providing 378 integrity protection for the NSH. 380 +--------------------+----------------------------------+ 381 | Data Plane Element | Integrity Protection | 382 +--------------------+----------------------------------+ 383 | Classifier | Yes | 384 | SFF | No (first LoA); Yes (second LoA) | 385 | NSH-aware SF | Yes | 386 | SFC Proxy | Yes | 387 | NSH-unaware SF | No | 388 +--------------------+----------------------------------+ 390 Table 2: Integrity Protection Supported by SFC Data Plane Elements 392 4.2. One Secret Key, Two Security Services 394 The authenticated encryption algorithm defined in [RFC7518] is used 395 to provide NSH data integrity and to encrypt the Context Headers that 396 carry privacy-sensitive metadata. 398 The authenticated encryption algorithm provides a unified encryption 399 and authentication operation which turns plaintext into authenticated 400 ciphertext and vice versa. The generation of secondary keys MAC_KEY 401 and ENC_KEY from the secret key (K) is discussed in Section 5.2.2.1 402 of [RFC7518]: 404 o The ENC_KEY is used for encrypting the Context Headers and the 405 message integrity of the NSH data is calculated using the MAC_KEY. 407 o If the Context Headers are not encrypted, the Hashed Message 408 Authentication Mode (HMAC) algorithm discussed in [RFC4868] is 409 used to integrity protect the NSH data. 411 The advantage of using the authenticated encryption algorithm is that 412 NSH-aware SFs and SFC proxies only need to re-compute the message 413 integrity of the NSH data after decrementing the Service Index (SI) 414 and do not have to re-compute the ciphertext. The other advantage is 415 that SFFs do not have access to the ENC_KEY and cannot act on the 416 encrypted Context Headers and, only in case of the second level of 417 assurance, SFFs do have access to the MAC_KEY. Similarly, an NSH- 418 aware SF or SFC Proxy not allowed to decrypt the Context Headers will 419 not have access to the ENC_KEY. 421 The authenticated encryption algorithm or HMAC algorithm to be used 422 by SFC data plane elements is typically controlled using the SFC 423 control plane. Mandatory to implement authenticated encryption and 424 HMAC algorithms are listed in Section 4.3. 426 The authenticated encryption process takes as input four octet 427 strings: a secret key (K), a plaintext (P), Additional Authenticated 428 Data (A) (which contains the data to be authenticated, but not 429 encrypted), and an Initialization Vector (IV). The ciphertext value 430 (E) and the Authentication Tag value (T) are provided as outputs. 432 In order to decrypt and verify, the cipher takes as input K, IV, A, 433 T, and E. The output is either the plaintext or an error indicating 434 that the decryption failed as described in Section 5.2.2.2 of 435 [RFC7518]. 437 4.3. Mandatory-to-Implement Authenticated Encryption and HMAC 438 Algorithms 440 Classifiers, NSH-aware SFs, and SFC proxies MUST implement the 441 AES_128_CBC_HMAC_SHA_256 algorithm and SHOULD implement the 442 AES_192_CBC_HMAC_SHA_384 and AES_256_CBC_HMAC_SHA_512 algorithms. 444 Classifiers, NSH-aware SFs, and SFC proxies MUST implement the HMAC- 445 SHA-256-128 algorithm and SHOULD implement the HMAC-SHA-384-192 and 446 HMAC-SHA-512-256 algorithms. 448 SFFs MAY implement the aforementioned cipher suites and HMAC 449 algorithms. 451 o Note: The use of AES-GCM + HMAC may have CPU and packet size 452 implications (need for a second 128-bit authentication tag). 454 4.4. Key Management 456 The procedure for the allocation/provisioning of secret keys (K) and 457 authenticated encryption algorithm or MAC_KEY and HMAC algorithm is 458 outside the scope of this specification. As such, this specification 459 does not mandate the support of any specific mechanism. 461 The documents does not assume nor preclude the following: 463 o The same keying material is used for all the service functions 464 used within an SFC-enabled domain. 466 o Distinct keying material is used per SFP by all involved SFC data 467 path elements. 469 o Per-tenant keys are used. 471 In order to accommodate deployments relying upon keying material per 472 SFC/SFP and also the need to update keys after encrypting NSH data 473 for certain amount of time, this document uses key identifier (kid) 474 to unambiguously identify the appropriate keying material. Doing so 475 allows to address the problem of synchronization of keying material. 477 Additional information on manual vs. automated key management and 478 when one should be used over the other can be found in [RFC4107]. 480 4.5. New NSH Variable-Length Context Headers 482 New NSH Variable-Length Context Headers are defined in Section 5 for 483 NSH data integrity protection and, optionally, encryption of Context 484 Headers carrying privacy-sensitive metadata. Concretely, an NSH 485 imposer includes (1) the key identifier to identify the keying 486 material, (2) the timestamp to protect against replay attacks 487 (Section 7.4), and (3) the Message Authentication Code (MAC) for the 488 target NSH data (depending on the integrity protection scope) 489 calculated using the MAC_KEY and optionally Context Headers encrypted 490 using ENC_KEY. 492 An SFC data plane element that needs to check the integrity of the 493 NSH data uses MAC_KEY and the HMAC algorithm for the key identifier 494 being carried in the NSH. 496 An NSH-aware SF or SFC Proxy that needs to decrypt some Context 497 Headers uses ENC_Key and the decryption algorithm for the key 498 identifier being carried in the NSH. 500 Section 7 specifies the detailed procedure. 502 4.6. Encapsulation of NSH within NSH 504 As discussed in [RFC8459], an SFC-enabled domain (called, upper-level 505 domain) may be decomposed into many sub-domains (called, lower-level 506 domains). In order to avoid maintaining state to restore back upper- 507 lower NSH information at the boundaries of lower-level domains, two 508 NSH levels are used: an Upper-NSH which is imposed at the boundaries 509 of the upper-level domain and a Lower-NSH that is pushed by the 510 Classifier of a lower-level domain in front of the original NSH 511 (Figure 4). As such, the Upper-NSH information is carried along the 512 lower-level chain without modification. The packet is forwarded in 513 the top-level domain according to the Upper-NSH, while it is 514 forwarded according to the Lower-NSH in a lower-level domain. 516 +---------------------------------+ 517 | Transport Encapsulation | 518 +->+---------------------------------+ 519 | | Lower-NSH Header | 520 | +---------------------------------+ 521 | | Upper-NSH Header | 522 | +---------------------------------+ 523 | | Original Packet | 524 +->+---------------------------------+ 525 | 526 | 527 +----Scope of NSH security protection 528 provided by a lower-level domain 530 Figure 4: Encapsulation of NSH within NSH 532 SFC data plane elements of a lower-level domain includes the Upper- 533 NSH when computing the MAC. 535 Keying material used at the upper-level domain SHOULD NOT be the same 536 as the one used by a lower-level domain. 538 5. New NSH Variable-Length Context Headers 540 This section specifies the format of new Variable-Length Context 541 headers that are used for NSH integrity protection and, optionally, 542 Context Headers encryption. 544 In particular, this section defines two "MAC and Encrypted Metadata" 545 Context Headers; each having specific deployment constraints. Unlike 546 Section 5.1, the level of assurance provided in Section 5.2 requires 547 sharing MAC_KEY with SFFs. Both Context headers have the same format 548 as shown in Section 5. 550 0 1 2 3 551 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 552 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 553 | Metadata Class | Type |U| Length | 554 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 555 | Key Length | Key Identifier (Variable) ~ 556 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 557 ~ Timestamp (8 bytes) ~ 558 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 559 | IV Length | Initialization Vector (Variable) ~ 560 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 561 | | 562 | Message Authentication Code and optional Encrypted | 563 ~ Context Headers ~ 564 | | 565 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 567 Figure 5: MAC and Encrypted Metadata Context Header 569 5.1. MAC#1 Context Header 571 MAC#1 Context Header is a variable-length TLV that carries the 572 Message Authentication Code (MAC) for the Service Path Header, 573 Context Headers, and the inner packet on which NSH is imposed, 574 calculated using MAC_KEY and optionally Context Headers encrypted 575 using ENC_KEY. The scope of the integrity protection provided by 576 this TLV is depicted in Figure 6. 578 This MAC scheme does not require sharing MAC_KEY with SFFs. It does 579 not require to re-compute the MAC by each SFF because of TTL 580 processing. Section 9.1 discusses the possible threat associated 581 with this level of assurance. 583 0 1 2 3 584 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 585 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 586 |Ver|O|U| TTL | Length |U|U|U|U|MD Type| Next Protocol | 587 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<--+ 588 | Service Path Identifier | Service Index | | 589 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 590 | | | 591 ~ Variable-Length Unencrypted Context Headers (opt.) ~ | 592 | | | 593 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 594 | Metadata Class | Type |U| Length | | 595 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 596 | Key Length | Key Identifier ~ | 597 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 598 ~ Timestamp (8 bytes) ~ | 599 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 600 | IV Length | Initialization Vector ~ | 601 +->+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 602 | ~ Context Header TLVs to encrypt (opt.) ~ | 603 +->+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 604 | | | | 605 | ~ Inner Packet on which NSH is imposed ~ | 606 | | | | 607 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<--| 608 | | 609 | | 610 | | 611 | Integrity Protection Scope ----+ 612 +----Encrypted Data 614 Figure 6: Scope of MAC#1 616 In reference to Figure 5, the description of the fields is as 617 follows: 619 o Metadata Class: MUST be set to 0x0 (Section 2.5.1 of [RFC8300]). 621 o Type: TBD1 (See Section 10) 623 o U: Unassigned bit (Section 2.5.1 of [RFC8300]). 625 o Length: Variable. 627 o Key Length: Variable. Carries the length of the key identifier. 629 o Key Identifier: Carries a variable length Key Identifier object 630 used to identify and deliver keys to SFC data plane elements. 632 This identifier is helpful to accommodate deployments relying upon 633 keying material per SFC/SFP. The key identifier helps in 634 resolving the problem of synchronization of keying material. 636 o Timestamp: Carries an unsigned 64-bit integer value that is 637 expressed in seconds relative to 1970-01-01T00:00Z in UTC time. 638 See Section 6 for more details. 640 o IV Length: Carries the length of the IV (Section 5.2 of 641 [RFC7518]). If HMAC algorithm is used, IV length is set to zero. 643 o Initialization Vector: Carries the IV for authenticated encryption 644 algorithm as discussed in Section 5.2 of [RFC7518]. 646 o The Additional Authenticated Data (defined in [RFC7518]) MUST be 647 the Service Path header, the unencrypted Context headers, and the 648 inner packet on which the NSH is imposed . 650 o Message Authentication Code covering the entire NSH data excluding 651 the Base header. 653 5.2. MAC#2 Context Header 655 MAC#2 Context Header is a variable-length TLV that carries the MAC 656 for the entire NSH data calculated using MAC_KEY and optionally 657 Context Headers encrypted using ENC_KEY. The scope of the integrity 658 protection provided by this TLV is depicted in Figure 7. 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 | | | 668 ~ Variable-Length Unencrypted Context Headers (opt.) ~ | 669 | | | 670 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 671 | Metadata Class | Type |U| Length | | 672 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 673 | Key Length | Key Identifier ~ | 674 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 675 ~ Timestamp (8 bytes) ~ | 676 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 677 | IV Length | Initialization Vector | | 678 +->+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 679 | ~ Context Header TLVs to encrypt (opt.) ~ | 680 +->+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 681 | | | | 682 | ~ Inner Packet on which NSH is imposed ~ | 683 | | | | 684 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<--| 685 | | 686 | | 687 | | 688 | Integrity Protection Scope ----+ 689 +----Encrypted Data 691 Figure 7: Scope of MAC#2 693 In reference to Figure 5, the description of the fields is as 694 follows: 696 o Metadata Class: MUST be set to 0x0 (Section 2.5.1 of [RFC8300]). 698 o Type: TBD2 (See Section 10) 700 o U: Unassigned bit (Section 2.5.1 of [RFC8300]). 702 o Length: Variable. 704 o Key Length: See Section 5.1. 706 o Key Identifier: See Section 5.1. 708 o Timestamp: See Section 6. 710 o IV Length: See Section 5.1. 712 o Initialization Vector: See Section 5.1. 714 o The Additional Authenticated Data (defined in [RFC7518]) MUST be 715 the entire NSH data (i.e., including the Base Header) excluding 716 the Context Headers to be encrypted. 718 o Message Authentication Code covering the entire NSH data and 719 optional encrypted Context Headers. 721 6. Timestamp Format 723 This section follows the template provided in Section 3 of [RFC8877]. 725 The format of the Timestamp field introduced in Section 5 is depicted 726 in Figure 8. 728 0 1 2 3 729 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 730 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 731 | Seconds | 732 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 733 | Fraction | 734 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 736 Figure 8: Timestamp Field Format 738 Timestamp field format: 740 Seconds: specifies the integer portion of the number of seconds 741 since the epoch. 743 + Size: 32 bits. 745 + Units: seconds. 747 Fraction: specifies the fractional portion of the number of 748 seconds since the epoch. 750 + Size: 32 bits. 752 + Units: the unit is 2^(-32) seconds, which is roughly equal to 753 233 picoseconds. 755 Epoch: 757 The epoch is 1970-01-01T00:00Z in UTC time. 759 Leap seconds: 761 This timestamp format is affected by leap seconds. The timestamp 762 represents the number of seconds elapsed since the epoch minus the 763 number of leap seconds. 765 Resolution: 767 The resolution is 2^(-32) seconds. 769 Wraparound: 771 This time format wraps around every 2^32 seconds, which is roughly 772 136 years. The next wraparound will occur in the year 2106. 774 Synchronization aspects: 776 It is assumed that SFC data plane elements are synchronized to UTC 777 using a synchronization mechanism that is outside the scope of 778 this document. In typical deployments SFC data plane elements use 779 NTP [RFC5905] for synchronization. Thus, the timestamp may be 780 derived from the NTP-synchronized clock, allowing the timestamp to 781 be measured with respect to the clock of an NTP server. Since the 782 NTP time format is affected by leap seconds, the current timestamp 783 format is similarly affected. Therefore, the value of a timestamp 784 during or slightly after a leap second may be temporarily 785 inaccurate. 787 7. Processing Rules 789 The following subsections describe the processing rules for integrity 790 protected NSH and optionally encrypted Context Headers. 792 7.1. Generic Behavior 794 This document adheres to the recommendations in [RFC8300] for 795 handling the Context Headers at both ingress and egress SFC boundary 796 nodes (i.e., to strip the entire NSH, including Context Headers). 798 Failures to inject or validate the Context Headers defined in this 799 document SHOULD be logged locally while a notification alarm MAY be 800 sent to an SFC control element. Similarly, failure to validate the 801 integrity of the NSH data MUST cause that packet to be discarded 802 while a notification alarm MAY be sent to an SFC control element. 803 The details of sending notification alarms (i.e., the parameters 804 affecting the transmission of the notification alarms depend on the 805 information in the context header such as frequency, thresholds, and 806 content in the alarm) SHOULD be configurable by the SFC control 807 plane. 809 NSH-aware SFs and SFC proxies MAY be instructed to strip some 810 encrypted Context Headers from the packet or to pass the data to the 811 next SF in the service function chain after processing the content of 812 the Context Headers. If no instruction is provided, the default 813 behavior for intermediary NSH-aware nodes is to maintain such Context 814 Headers so that the information can be passed to next NSH-aware hops. 815 NSH-aware SFs and SFC proxies MUST re-apply the integrity protection 816 if any modification is made to the Context Headers (strip a Context 817 Header, update the content of an existing Context Header, insert a 818 new Context Header). 820 An NSH-aware SF or SFC Proxy that is not allowed to decrypt any 821 Context Headers MUST NOT be given access to the ENC_KEY. 823 Otherwise, an NSH-aware SF or SFC Proxy that receives encrypted 824 Context Headers, for which it is not allowed to consume a specific 825 Context Header it decrypts (but consumes others), MUST keep that 826 Context Header unaltered when forwarding the packet upstream. 828 Only one instance of "MAC and Encrypted Metadata" Context Header 829 (Section 5) is allowed. If multiple instances of "MAC and Encrypted 830 Metadata" Context Header are included in an NSH packet, the SFC data 831 element MUST process the first instance and ignore subsequent 832 instances, and MAY log or increase a counter for this event as per 833 Section 2.5.1 of [RFC8300]. 835 MTU and fragmentation considerations are discussed in Section 8. 837 7.2. MAC NSH Data Generation 839 If the Context Headers are not encrypted, the HMAC algorithm 840 discussed in [RFC4868] is used to integrity protect the target NSH 841 data. An NSH imposer inserts a "MAC and Encrypted Metadata" Context 842 Header for integrity protection (Section 5). 844 The NSH imposer computes the message integrity for the target NSH 845 data (depending on the integrity protection scope discussed in 846 Section 5) using MAC_KEY and HMAC algorithm. It inserts the MAC in 847 the "MAC and Encrypted Metadata" Context Header. The length of the 848 MAC is decided by the HMAC algorithm adopted for the particular key 849 identifier. 851 The Message Authentication Code (T) computation process can be 852 illustrated as follows: 854 T = HMAC-SHA-256-128(MAC_KEY, A) 856 An entity in the SFP that intends to update the NSH MUST follow the 857 above behavior to maintain message integrity of the NSH for 858 subsequent validations. 860 7.3. Encrypted NSH Metadata Generation 862 An NSH imposer can encrypt Context Headers carrying privacy-sensitive 863 metadata, i.e., encrypted and unencrypted metadata may be carried 864 simultaneously in the same NSH packet (Figure 9). 866 0 1 2 3 867 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 868 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 869 |Ver|O|U| TTL | Length |U|U|U|U|MD Type| Next Protocol | 870 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 871 | Service Path Identifier | Service Index | 872 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 873 | | 874 ~ Variable-Length Unencrypted Context Headers (opt.) ~ 875 | | 876 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 877 ~ Key Identifier ~ 878 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 879 ~ Timestamp ~ 880 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 881 | | 882 ~ MAC and Encrypted Context Headers ~ 883 | | 884 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 886 Figure 9: NSH with Encrypted and Unencrypted Metadata 888 In an SFC-enabled domain where pervasive monitoring [RFC7258] is 889 possible, all Context Headers carrying privacy-sensitive metadata 890 MUST be encrypted; doing so privacy-sensitive metadata is not 891 revealed to attackers. Privacy specific threats are discussed in 892 Section 5.2 of [RFC6973]. 894 Using K and authenticated encryption algorithm, the NSH imposer 895 encrypts the Context Headers (as set by the control plane Section 3), 896 computes the message integrity for the target NSH data, and inserts 897 the resulting payload in the "MAC and Encrypted Metadata" Context 898 Header (Section 5). The entire TLV carrying a privacy-sensitive 899 metadata is encrypted (that is, including the MD Class, Type, Length, 900 and associated metadata of each Context Header). 902 The message Authentication Tag (T) and ciphertext (E) computation 903 process can be illustrated as follows: 905 MAC_KEY = initial MAC_KEY_LEN octets of K, 906 ENC_KEY = final ENC_KEY_LEN octets of K, 907 E = CBC-PKCS7-ENC(ENC_KEY, P), 908 M = MAC(MAC_KEY, A || IV || E || AL), 909 T = initial T_LEN octets of M. 910 MAC and Encrypted Metadata = E || T 912 As specified in [RFC7518], the octet string (AL) is equal to the 913 number of bits in the Additional Authenticated Data (A) expressed as 914 a 64-bit unsigned big-endian integer. 916 An authorized entity in the SFP that intends to update the content of 917 an encrypted Context Header or needs to add a new encrypted Context 918 Header MUST also follow the aforementioned behavior. 920 An SFF or NSH-aware SF or SFC Proxy that only has access to the 921 MAC_KEY, but not the ENC_KEY, computes the message Authentication Tag 922 (T) after decrementing the TTL (by the SFF) or SI (by an SF or SFC 923 Proxy) and replaces the Authentication Tag in the NSH with the 924 computed Authentication Tag. Similarly, an NSH-aware SF (or SFC 925 Proxy) that does not modify the encrypted Context headers also 926 follows the aforementioned behavior. 928 The message Authentication Tag (T) computation process can be 929 illustrated as follows: 931 M = MAC(MAC_KEY, A || IV || E || AL), 932 T = initial T_LEN octets of M. 934 7.4. Timestamp for Replay Attack 936 The received NSH is accepted if the Timestamp (TS) in the NSH is 937 recent enough to the reception time of the NSH (TSrt). The following 938 formula is used for this check: 940 -Delta < (TSrt ? TS) < +Delta 942 The RECOMMENDED value for the allowed Delta is 2 seconds. If the 943 timestamp is not within the boundaries, then the SFC data plane 944 element receiving such packet MUST discard the NSH message. 946 All SFC data plane elements must be synchronized among themselves. 947 These elements may be synchronized to a global reference time. 949 7.5. NSH Data Validation 951 When an SFC data plane element receives an NSH packet, it MUST first 952 ensure that a "MAC and Encrypted Metadata" Context Header is 953 included. It MUST silently discard the message if the timestamp is 954 invalid (Section 7.4). It MUST log an error at least once per the 955 SPI for which the "MAC and Encrypted Metadata" Context Header is 956 missing. 958 If the timestamp check is successfuly passed, the SFC data plane 959 element proceeds then with NSH data integrity validation. The SFC 960 data plane element computes the message integrity for the target NSH 961 data (depending on the integrity protection scope discussed in 962 Section 5) 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 the 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 7.6. Decryption of NSH Metadata 970 If entitled to consume a supplied encrypted Context Header, an NSH- 971 aware SF or SFC Proxy decrypts metadata using (K) and decryption 972 algorithm for the key identifier in the NSH. 974 Authenticated encryption algorithm has only a single output, either a 975 plaintext or a special symbol (FAIL) that indicates that the inputs 976 are not authentic (Section 5.2.2.2 of [RFC7518]). 978 8. MTU Considerations 980 The SFC architecture prescribes that additional information be added 981 to packets to: 983 o Identify SFPs: this is typically the NSH Base Header and Service 984 Path Header. 986 o Carry metadata such those defined in Section Section 5. 988 o Steer the traffic along the SFPs: transport encapsulation. 990 This added information increases the size of the packet to be carried 991 along an SFP. 993 Aligned with Section 5 of [RFC8300], it is RECOMMENDED for network 994 operators to increase the underlying MTU so that NSH traffic is 995 forwarded within an SFC-enabled domain without fragmentation. The 996 available underlying MTU should be taken into account by network 997 operators when providing SFs with the required Context Headers to be 998 injected per SFP and the size of the data to be carried in these 999 Context Headers. 1001 If the underlying MTU cannot be increased to accommodate the NSH 1002 overhead, network operators may rely upon a transport encapsulation 1003 protocol with the required fragmentation handling. The impact of 1004 activating such feature on SFFs should be carefully assessed by 1005 network operators (Section 5.6 of [RFC7665]). 1007 When dealing with MTU issues, network operators should consider the 1008 limitations of various transport encapsulations such as those 1009 discussed in [I-D.ietf-intarea-tunnels]. 1011 9. Security Considerations 1013 Data plane SFC-related security considerations, including privacy, 1014 are discussed in Section 6 of [RFC7665] and Section 8 of [RFC8300]. 1015 In particular, Section 8.2.2 of [RFC8300] states that attached 1016 metadata (i.e., Context Headers) should be limited to that necessary 1017 for correct operation of the SFP. Also, that section indicates that 1018 metadata considerations that operators can take into account when 1019 using NSH are discussed in [RFC8165]. 1021 The guidelines for cryptographic key management are discussed in 1022 [RFC4107]. 1024 The interaction between the SFC data plane elements and a key 1025 management system MUST NOT be transmitted in clear since this would 1026 completely destroy the security benefits of the integrity protection 1027 solution defined in this document. The secret key (K) must have an 1028 expiration time assigned as the latest point in time before which the 1029 key may be used for integrity protection of NSH data and encryption 1030 of Context Headers. Prior to the expiration of the secret key, all 1031 participating service function nodes SHOULD have the control plane 1032 distribute a new key identifier and associated keying material so 1033 that when the secret key is expired, those nodes are prepared with 1034 the new secret key. This allows the NSH Imposer to switch to the new 1035 key identifier as soon as necessary. It is RECOMMENDED that the next 1036 key identifier be distributed by the control plane well prior to the 1037 secret key expiration time. 1039 NSH data are exposed to several threats: 1041 o A man-in-the-middle attacker modifying the NSH data. 1043 o Attacker spoofing the NSH data. 1045 o Attacker capturing and replaying the NSH data. 1047 o Data carried in Context Headers revealing privacy-sensitive 1048 information to attackers. 1050 o Attacker replacing the packet on which the NSH is imposed with a 1051 bogus packet. 1053 In an SFC-enabled domain where the above attacks are possible, NSH 1054 data MUST be integrity-protected and replay-protected, and privacy- 1055 sensitive NSH metadata MUST be encrypted for confidentiality 1056 preservation purposes. The Base and Service Path headers are not 1057 encrypted. 1059 MACs with two levels of assurance are defined in Section 5. 1060 Considerations specific to each level of assurance are discussed in 1061 the following subsections. 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 Some events are logged locally with notification alerts sent by NSH- 1073 aware nodes to a Control Element. These events SHOULD be rate 1074 limited. 1076 9.1. MAC#1 1078 An active attacker can potentially modify the Base header (e.g., 1079 decrement the TTL so the next SFF in the SFP discards the NSH 1080 packet). In the meantime, an active attacker can also drop NSH 1081 packets. As such, this attack is not considered an attack against 1082 the security mechanism specified in the document. 1084 No device other than the NSH-aware SFs in the SFC-enabled domain 1085 should be able to update the integrity protected NSH data. 1086 Similarly, no device other than the NSH-aware SFs and SFC proxies in 1087 the SFC-enabled domain be able to decrypt and update the Context 1088 Headers carrying privacy-sensitive metadata. In other words, if the 1089 NSH-aware SFs and SFC proxies in the SFC-enabled domain are 1090 considered fully trusted to act on the NSH data, only these elements 1091 can have access to privacy-sensitive NSH metadata and the keying 1092 material used to integrity protect NSH data and encrypt Context 1093 Headers. 1095 9.2. MAC#2 1097 SFFs can detect whether an illegitimate node has altered the content 1098 of the Base header. Such messages MUST be discarded with appropriate 1099 logs and alarms generated. 1101 10. IANA Considerations 1103 This document requests IANA to assign the following types from the 1104 "NSH IETF-Assigned Optional Variable-Length Metadata Types" (0x0000 1105 IETF Base NSH MD Class) registry available at: 1106 https://www.iana.org/assignments/nsh/nsh.xhtml#optional-variable- 1107 length-metadata-types. 1109 +-------+-------------------------------+----------------+ 1110 | Value | Description | Reference | 1111 +=======+===============================+================+ 1112 | TBD1 | MAC and Encrypted Metadata #1 | [ThisDocument] | 1113 | TBD2 | MAC and Encrypted Metadata #2 | [ThisDocument] | 1114 +-------+-------------------------------+----------------+ 1116 11. Acknowledgements 1118 This document was edited as a follow up to the discussion in 1119 IETF#104: https://datatracker.ietf.org/meeting/104/materials/slides- 1120 104-sfc-sfc-chair-slides-01 (slide 7). 1122 Thanks to Joel Halpern, Christian Jacquenet, Dirk von Hugo, Tal 1123 Mizrahi, Daniel Migault, and Diego Lopez for the comments. 1125 12. References 1127 12.1. Normative References 1129 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1130 Requirement Levels", BCP 14, RFC 2119, 1131 DOI 10.17487/RFC2119, March 1997, 1132 . 1134 [RFC4107] Bellovin, S. and R. Housley, "Guidelines for Cryptographic 1135 Key Management", BCP 107, RFC 4107, DOI 10.17487/RFC4107, 1136 June 2005, . 1138 [RFC4868] Kelly, S. and S. Frankel, "Using HMAC-SHA-256, HMAC-SHA- 1139 384, and HMAC-SHA-512 with IPsec", RFC 4868, 1140 DOI 10.17487/RFC4868, May 2007, 1141 . 1143 [RFC7518] Jones, M., "JSON Web Algorithms (JWA)", RFC 7518, 1144 DOI 10.17487/RFC7518, May 2015, 1145 . 1147 [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function 1148 Chaining (SFC) Architecture", RFC 7665, 1149 DOI 10.17487/RFC7665, October 2015, 1150 . 1152 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1153 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1154 May 2017, . 1156 [RFC8300] Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed., 1157 "Network Service Header (NSH)", RFC 8300, 1158 DOI 10.17487/RFC8300, January 2018, 1159 . 1161 [RFC8877] Mizrahi, T., Fabini, J., and A. Morton, "Guidelines for 1162 Defining Packet Timestamps", RFC 8877, 1163 DOI 10.17487/RFC8877, September 2020, 1164 . 1166 12.2. Informative References 1168 [I-D.arkko-farrell-arch-model-t] 1169 Arkko, J. and S. Farrell, "Challenges and Changes in the 1170 Internet Threat Model", draft-arkko-farrell-arch-model- 1171 t-04 (work in progress), July 2020. 1173 [I-D.ietf-intarea-tunnels] 1174 Touch, J. and M. Townsley, "IP Tunnels in the Internet 1175 Architecture", draft-ietf-intarea-tunnels-10 (work in 1176 progress), September 2019. 1178 [I-D.nguyen-sfc-security-architecture] 1179 Nguyen, T. and M. Park, "A Security Architecture Against 1180 Service Function Chaining Threats", draft-nguyen-sfc- 1181 security-architecture-00 (work in progress), November 1182 2019. 1184 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, 1185 "Network Time Protocol Version 4: Protocol and Algorithms 1186 Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, 1187 . 1189 [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., 1190 Morris, J., Hansen, M., and R. Smith, "Privacy 1191 Considerations for Internet Protocols", RFC 6973, 1192 DOI 10.17487/RFC6973, July 2013, 1193 . 1195 [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an 1196 Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 1197 2014, . 1199 [RFC7498] Quinn, P., Ed. and T. Nadeau, Ed., "Problem Statement for 1200 Service Function Chaining", RFC 7498, 1201 DOI 10.17487/RFC7498, April 2015, 1202 . 1204 [RFC7635] Reddy, T., Patil, P., Ravindranath, R., and J. Uberti, 1205 "Session Traversal Utilities for NAT (STUN) Extension for 1206 Third-Party Authorization", RFC 7635, 1207 DOI 10.17487/RFC7635, August 2015, 1208 . 1210 [RFC8165] Hardie, T., "Design Considerations for Metadata 1211 Insertion", RFC 8165, DOI 10.17487/RFC8165, May 2017, 1212 . 1214 [RFC8459] Dolson, D., Homma, S., Lopez, D., and M. Boucadair, 1215 "Hierarchical Service Function Chaining (hSFC)", RFC 8459, 1216 DOI 10.17487/RFC8459, September 2018, 1217 . 1219 Authors' Addresses 1221 Mohamed Boucadair 1222 Orange 1223 Rennes 35000 1224 France 1226 Email: mohamed.boucadair@orange.com 1227 Tirumaleswar Reddy 1228 McAfee, Inc. 1229 Embassy Golf Link Business Park 1230 Bangalore, Karnataka 560071 1231 India 1233 Email: TirumaleswarReddy_Konda@McAfee.com 1235 Dan Wing 1236 Citrix Systems, Inc. 1237 USA 1239 Email: dwing-ietf@fuggles.com