idnits 2.17.1 draft-ietf-sfc-nsh-integrity-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 7, 2021) is 1205 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 1165, 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: July 11, 2021 McAfee 6 D. Wing 7 Citrix 8 January 7, 2021 10 Integrity Protection for the Network Service Header (NSH) and Encryption 11 of Sensitive Context Headers 12 draft-ietf-sfc-nsh-integrity-02 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 July 11, 2021. 37 Copyright Notice 39 Copyright (c) 2021 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 . . . . . . . . . . . . . . . 23 78 8. MTU Considerations . . . . . . . . . . . . . . . . . . . . . 23 79 9. Security Considerations . . . . . . . . . . . . . . . . . . . 24 80 9.1. MAC#1 . . . . . . . . . . . . . . . . . . . . . . . . . . 25 81 9.2. MAC#2 . . . . . . . . . . . . . . . . . . . . . . . . . . 26 82 9.3. Time Synchronization . . . . . . . . . . . . . . . . . . 26 83 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 84 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26 85 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 26 86 12.1. Normative References . . . . . . . . . . . . . . . . . . 26 87 12.2. Informative References . . . . . . . . . . . . . . . . . 27 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29 90 1. Introduction 92 Many advanced Service Functions (SFs) are enabled for the delivery of 93 value-added services. Typically, SFs are used to meet various 94 service objectives such as IP address sharing, avoiding covert 95 channels, detecting Denial-of-Service (DoS) attacks and protecting 96 network infrastructures against them, network slicing, etc. Because 97 of the proliferation of such advanced SFs together with complex 98 service deployment constraints that demand more agile service 99 delivery procedures, operators need to rationalize their service 100 delivery logics and master their complexity while optimising service 101 activation time cycles. The overall problem space is described in 102 [RFC7498]. 104 [RFC7665] presents a data plane architecture addressing the 105 problematic aspects of existing service deployments, including 106 topological dependence and configuration complexity. It also 107 describes an architecture for the specification, creation, and 108 maintenance of Service Function Chains (SFCs) within a network. That 109 is, how to define an ordered set of SFs and ordering constraints that 110 must be applied to packets/flows selected as a result of traffic 111 classification. [RFC8300] specifies the SFC encapsulation: Network 112 Service Header (NSH). 114 The NSH data is unauthenticated and unencrypted [RFC8300], forcing a 115 service topology that requires security and privacy to use a 116 transport encapsulation that supports such features. Note that some 117 transport encapsulation (e.g., IPsec) only provide hop-by-hop 118 security between two SFC data plane elements (e.g., two Service 119 Function Forwarders (SFFs), SFF to SF) and do not provide SF-to-SF 120 security of NSH metadata. For example, if IPsec is used, SFFs or SFs 121 within a Service Function Path (SFP) not authorized to access the 122 privacy-sensitive metadata will have access to the metadata. As a 123 reminder, the metadata referred to is an information that is inserted 124 by Classifiers or intermediate SFs and shared with downstream SFs; 125 such information is not visible to the communication endpoints 126 (Section 4.9 of [RFC7665]). 128 The lack of such capability was reported during the development of 129 [RFC8300] and [RFC8459]. The reader may refer to Section 3.2.1 of 130 [I-D.arkko-farrell-arch-model-t] for a discussion on the need for 131 more awareness about attacks from within closed domains. 133 This specification fills that gap. Concretely, this document adds 134 integrity protection and optional encryption of sensitive metadata 135 directly to the NSH (Section 4); integrity protects the packet 136 payload and provides replay protection (Section 7.4). Thus, the NSH 137 does not have to rely upon an underlying transport encapsulation for 138 security and confidentiality. 140 This specification introduces new Variable-Length Context Headers to 141 carry fields necessary for integrity protected NSH headers and 142 encrypted Context Headers (Section 5). This specification is only 143 applicable to NSH MD Type 0x02 (Section 2.5 of [RFC8300]). MTU 144 considerations are discussed in Section 8. 146 This specification limits thus access to an information within an SFP 147 to entities that have a need to interpret it. 149 2. Terminology 151 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 152 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 153 "OPTIONAL" in this document are to be interpreted as described in BCP 154 14 [RFC2119] [RFC8174] when, and only when, they appear in all 155 capitals, as shown here. 157 This document makes use of the terms defined in [RFC7665] and 158 [RFC8300]. 160 The document defines the following terms: 162 o SFC data plane element: Refers to NSH-aware SF, SFF, SFC Proxy, or 163 Classifier as defined in the SFC data plane architecture [RFC7665] 164 and further refined in [RFC8300]. 166 o SFC control element: A logical entity that instructs one or more 167 SFC data plane elements on how to process NSH packets within an 168 SFC-enabled domain. 170 o Key Identifier: A key identifier used to identify and deliver keys 171 to authorized entities. See for example, 'kid' usage in 172 [RFC7635]. 174 o NSH data: The NSH is composed of a Base Header, a Service Path 175 Header, and optional Context Headers. NSH data refers to all the 176 above headers and the packet or frame on which the NSH is imposed 177 to realize an SFP. 179 o NSH imposer: Refers to an SFC data plane element that is entitled 180 to impose the NSH with the Context Headers defined in this 181 document. 183 3. Assumptions and Basic Requirements 185 Section 2 of [RFC8300] specifies that the NSH data can be spread over 186 three headers: 188 o Base Header: Provides information about the service header and the 189 payload protocol. 191 o Service Path Header: Provides path identification and location 192 within an SFP. 194 o Context Header(s): Carries metadata (i.e., context data) along a 195 service path. 197 The NSH allows to share context information (a.k.a., metadata) with 198 downstream NSH-aware data elements on a per SFC/SFP basis. To that 199 aim: 201 The control plane is used to instruct the Classifier about the set 202 of context information to be supplied for a given service function 203 chain. 205 The control plane is also used to instruct an NSH-aware SF about 206 any metadata it needs to attach to packets for a given service 207 function chain. This instruction may occur any time during the 208 validity lifetime of an SFC/SFP. The control plane may indicate, 209 for a given service function chain, an order for consuming a set 210 of contexts supplied in a packet. 212 An NSH-aware SF can also be instructed about the behavior it 213 should adopt after consuming a context information that was 214 supplied in the NSH. For example, the context can be maintained, 215 updated, or stripped. 217 An SFC Proxy may be instructed about the behavior it should adopt 218 to process the context information that was supplied in the NSH on 219 behalf of an NSH-unaware SF (e.g., the context can be maintained 220 or stripped). The SFC Proxy may also be instructed to add some 221 new context information into the NSH on behalf of an NSH-unaware 222 SF. 224 In reference to Figure 1, 226 o Classifiers, NSH-aware SFs, and SFC proxies are entitled to update 227 the Context Header(s). 229 o Only NSH-aware SFs and SFC proxies are entitled to update the 230 Service Path Header. 232 o SFFs are entitled to modify the Base Path header (TTL value, for 233 example). Nevertheless, SFFs are not supposed to act on the 234 Context Headers or look into the content of the Context Headers. 236 Thus, the following requirements: 238 o Only Classifiers, NSH-aware SFs, and SFC proxies MUST be able to 239 encrypt and decrypt a given Context Header. 241 o Both encrypted and unencrypted Context Headers MAY be included in 242 the same NSH. That is, some Context Headers (TLVs) may be 243 protected while others do not need to be protected. 245 o The solution MUST provide integrity protection for the Service 246 Path Header. 248 o The solution MAY provide integrity protection for the Base Header. 249 The implications of disabling such checks are discussed in 250 Section 9.1. 252 +----------------+-----------------------------+-------------------+ 253 | | Insert, remove, or replace | Update the NSH | 254 | | the NSH | | 255 | | | | 256 | SFC Data Plane +---------+---------+---------+---------+---------+ 257 | Element | | | |Decrement| Update | 258 | | Insert | Remove | Replace | Service | Context | 259 | | | | | Index |Header(s)| 260 +================+=========+=========+=========+=========+=========+ 261 | | + | | + | | + | 262 | Classifier | | | | | | 263 +----------------+---------+---------+---------+---------+---------+ 264 |Service Function| | + | | | | 265 |Forwarder (SFF) | | | | | | 266 +----------------+---------+---------+---------+---------+---------+ 267 |Service Function| | | | + | + | 268 | (SF) | | | | | | 269 +----------------+---------+---------+---------+---------+---------+ 270 | | + | + | | + | + | 271 | SFC Proxy | | | | | | 272 +----------------+---------+---------+---------+---------+---------+ 274 Figure 1: Summary of NSH Actions 276 4. Design Overview 278 4.1. Supported Security Services 280 This specification provides the functions described in the following 281 subsections. 283 4.1.1. Encrypt All or a Subset of Context Headers 285 The solution allows to encrypt all or a subset of NSH Context Headers 286 by Classifiers, NSH-aware SFs, and SFC proxies. 288 As depicted in Table 1, SFFs are not involved in data encryption. 289 This document enforces this design approach by encrypting Context 290 Headers with keys that are not supplied to SFFs, thus enforcing this 291 limitation by protocol (rather than requirements language). 293 +-----------------+------------------------------+------------------+ 294 | Data Plane | Base and Service Headers | Metadata | 295 | Element | Encryption | Encryption | 296 +-----------------+------------------------------+------------------+ 297 | Classifier | No | Yes | 298 | SFF | No | No | 299 | NSH-aware SF | No | Yes | 300 | SFC Proxy | No | Yes | 301 | NSH-unaware SF | No | No | 302 +-----------------+------------------------------+------------------+ 304 Table 1: Encryption Function Supported by SFC Data Plane Elements 306 The SFC control plane is assumed to instruct the Classifier(s), NSH- 307 aware SFs, and SFC proxies with the set of Context Headers (privacy- 308 sensitive metadata, typically) that must be encrypted. Encryption 309 keying material is only provided to these SFC data elements. 311 The control plane may also indicate the set of SFC data plane 312 elements that are entitled to supply a given Context Header (e.g., in 313 reference to their identifiers as assigned within the SFC-enabled 314 domain). It is out of the scope of this document to elaborate on how 315 such instructions are provided to the appropriate SFC data plane 316 elements, nor to detail the structure used to store the instructions. 318 The Service Path Header (Section 2 of [RFC8300]) is not encrypted 319 because SFFs use Service Index (SI) in conjunction with Service Path 320 Identifier (SPI) for determining the next SF in the path. 322 4.1.2. Integrity Protection 324 The solution provides integrity protection for the NSH data. Two 325 levels of assurance (LoAs) are supported. 327 A first level of assurance where all NSH data except the Base Header 328 are integrity protected (Figure 2). In this case, the NSH imposer 329 may be a Classifier, an NSH-aware SF, or an SFC Proxy. SFFs are not 330 thus provided with authentication material. Further details are 331 discussed in Section 5.1. 333 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 334 | Transport Encapsulation | 335 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+... 336 | Base Header | | 337 +->+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ N 338 | | Service Path Header | S 339 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ H 340 | | Context Header(s) | | 341 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+... 342 | | Original Packet | 343 +->+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 344 | 345 +------Scope of integrity protected data 347 Figure 2: First Level of Assurance 349 A second level of assurance where all NSH data, including the Base 350 Header, are integrity protected (Figure 3). In this case, the NSH 351 imposer may be a Classifier, an NSH-aware SF, an SFF, or an SFC 352 Proxy. Further details are provided in Section 5.2. 354 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 355 | Transport Encapsulation | 356 +->+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+... 357 | | Base Header | | 358 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ N 359 | | Service Path Header | S 360 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ H 361 | | Context Header(s) | | 362 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+... 363 | | Original Packet | 364 +->+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 365 | 366 +----Scope of integrity protected data 368 Figure 3: Second Level of Assurance 370 The integrity protection scope is explicitly signaled to NSH-aware 371 SFs and SFC proxies in the NSH by means of a dedicated MD Type 372 (Section 5). 374 In both levels of assurance, the unencrypted Context Headers and the 375 packet on which the NSH is imposed are subject to integrity 376 protection. 378 Table 2 lists the roles of SFC data plane elements in providing 379 integrity protection for the NSH. 381 +--------------------+----------------------------------+ 382 | Data Plane Element | Integrity Protection | 383 +--------------------+----------------------------------+ 384 | Classifier | Yes | 385 | SFF | No (first LoA); Yes (second LoA) | 386 | NSH-aware SF | Yes | 387 | SFC Proxy | Yes | 388 | NSH-unaware SF | No | 389 +--------------------+----------------------------------+ 391 Table 2: Integrity Protection Supported by SFC Data Plane Elements 393 4.2. One Secret Key, Two Security Services 395 The authenticated encryption algorithm defined in [RFC7518] is used 396 to provide NSH data integrity and to encrypt the Context Headers that 397 carry privacy-sensitive metadata. 399 The authenticated encryption algorithm provides a unified encryption 400 and authentication operation which turns plaintext into authenticated 401 ciphertext and vice versa. The generation of secondary keys MAC_KEY 402 and ENC_KEY from the secret key (K) is discussed in Section 5.2.2.1 403 of [RFC7518]: 405 o The ENC_KEY is used for encrypting the Context Headers and the 406 message integrity of the NSH data is calculated using the MAC_KEY. 408 o If the Context Headers are not encrypted, the Hashed Message 409 Authentication Mode (HMAC) algorithm discussed in [RFC4868] is 410 used to integrity protect the NSH data. 412 The advantage of using the authenticated encryption algorithm is that 413 NSH-aware SFs and SFC proxies only need to re-compute the message 414 integrity of the NSH data after decrementing the Service Index (SI) 415 and do not have to re-compute the ciphertext. The other advantage is 416 that SFFs do not have access to the ENC_KEY and cannot act on the 417 encrypted Context Headers and, only in case of the second level of 418 assurance, SFFs do have access to the MAC_KEY. Similarly, an NSH- 419 aware SF or SFC Proxy not allowed to decrypt the Context Headers will 420 not have access to the ENC_KEY. 422 The authenticated encryption algorithm or HMAC algorithm to be used 423 by SFC data plane elements is typically controlled using the SFC 424 control plane. Mandatory to implement authenticated encryption and 425 HMAC algorithms are listed in Section 4.3. 427 The authenticated encryption process takes as input four octet 428 strings: a secret key (K), a plaintext (P), Additional Authenticated 429 Data (A) (which contains the data to be authenticated, but not 430 encrypted), and an Initialization Vector (IV). The ciphertext value 431 (E) and the Authentication Tag value (T) are provided as outputs. 433 In order to decrypt and verify, the cipher takes as input K, IV, A, 434 T, and E. The output is either the plaintext or an error indicating 435 that the decryption failed as described in Section 5.2.2.2 of 436 [RFC7518]. 438 4.3. Mandatory-to-Implement Authenticated Encryption and HMAC 439 Algorithms 441 Classifiers, NSH-aware SFs, and SFC proxies MUST implement the 442 AES_128_CBC_HMAC_SHA_256 algorithm and SHOULD implement the 443 AES_192_CBC_HMAC_SHA_384 and AES_256_CBC_HMAC_SHA_512 algorithms. 445 Classifiers, NSH-aware SFs, and SFC proxies MUST implement the HMAC- 446 SHA-256-128 algorithm and SHOULD implement the HMAC-SHA-384-192 and 447 HMAC-SHA-512-256 algorithms. 449 SFFs MAY implement the aforementioned cipher suites and HMAC 450 algorithms. 452 o Note: The use of AES-GCM + HMAC may have CPU and packet size 453 implications (need for a second 128-bit authentication tag). 455 4.4. Key Management 457 The procedure for the allocation/provisioning of secret keys (K) and 458 authenticated encryption algorithm or MAC_KEY and HMAC algorithm is 459 outside the scope of this specification. As such, this specification 460 does not mandate the support of any specific mechanism. 462 The documents does not assume nor preclude the following: 464 o The same keying material is used for all the service functions 465 used within an SFC-enabled domain. 467 o Distinct keying material is used per SFP by all involved SFC data 468 path elements. 470 o Per-tenant keys are used. 472 In order to accommodate deployments relying upon keying material per 473 SFC/SFP and also the need to update keys after encrypting NSH data 474 for certain amount of time, this document uses key identifier (kid) 475 to unambiguously identify the appropriate keying material. Doing so 476 allows to address the problem of synchronization of keying material. 478 Additional information on manual vs. automated key management and 479 when one should be used over the other can be found in [RFC4107]. 481 4.5. New NSH Variable-Length Context Headers 483 New NSH Variable-Length Context Headers are defined in Section 5 for 484 NSH data integrity protection and, optionally, encryption of Context 485 Headers carrying privacy-sensitive metadata. Concretely, an NSH 486 imposer includes (1) the key identifier to identify the keying 487 material, (2) the timestamp to protect against replay attacks 488 (Section 7.4), and (3) the Message Authentication Code (MAC) for the 489 target NSH data (depending on the integrity protection scope) 490 calculated using the MAC_KEY and optionally Context Headers encrypted 491 using ENC_KEY. 493 An SFC data plane element that needs to check the integrity of the 494 NSH data uses MAC_KEY and the HMAC algorithm for the key identifier 495 being carried in the NSH. 497 An NSH-aware SF or SFC Proxy that needs to decrypt some Context 498 Headers uses ENC_Key and the decryption algorithm for the key 499 identifier being carried in the NSH. 501 Section 7 specifies the detailed procedure. 503 4.6. Encapsulation of NSH within NSH 505 As discussed in [RFC8459], an SFC-enabled domain (called, upper-level 506 domain) may be decomposed into many sub-domains (called, lower-level 507 domains). In order to avoid maintaining state to restore back upper- 508 lower NSH information at the boundaries of lower-level domains, two 509 NSH levels are used: an Upper-NSH which is imposed at the boundaries 510 of the upper-level domain and a Lower-NSH that is pushed by the 511 Classifier of a lower-level domain in front of the original NSH 512 (Figure 4). As such, the Upper-NSH information is carried along the 513 lower-level chain without modification. The packet is forwarded in 514 the top-level domain according to the Upper-NSH, while it is 515 forwarded according to the Lower-NSH in a lower-level domain. 517 +---------------------------------+ 518 | Transport Encapsulation | 519 +->+---------------------------------+ 520 | | Lower-NSH Header | 521 | +---------------------------------+ 522 | | Upper-NSH Header | 523 | +---------------------------------+ 524 | | Original Packet | 525 +->+---------------------------------+ 526 | 527 | 528 +----Scope of NSH security protection 529 provided by a lower-level domain 531 Figure 4: Encapsulation of NSH within NSH 533 SFC data plane elements of a lower-level domain includes the Upper- 534 NSH when computing the MAC. 536 Keying material used at the upper-level domain SHOULD NOT be the same 537 as the one used by a lower-level domain. 539 5. New NSH Variable-Length Context Headers 541 This section specifies the format of new Variable-Length Context 542 headers that are used for NSH integrity protection and, optionally, 543 Context Headers encryption. 545 In particular, this section defines two "MAC and Encrypted Metadata" 546 Context Headers; each having specific deployment constraints. Unlike 547 Section 5.1, the level of assurance provided in Section 5.2 requires 548 sharing MAC_KEY with SFFs. Both Context headers have the same format 549 as shown in Section 5. 551 0 1 2 3 552 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 553 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 554 | Metadata Class | Type |U| Length | 555 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 556 | Key Length | Key Identifier (Variable) ~ 557 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 558 ~ Timestamp (8 bytes) ~ 559 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 560 | IV Length | Initialization Vector (Variable) ~ 561 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 562 | | 563 | Message Authentication Code and optional Encrypted | 564 ~ Context Headers ~ 565 | | 566 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 568 Figure 5: MAC and Encrypted Metadata Context Header 570 5.1. MAC#1 Context Header 572 MAC#1 Context Header is a variable-length TLV that carries the 573 Message Authentication Code (MAC) for the Service Path Header, 574 Context Headers, and the inner packet on which NSH is imposed, 575 calculated using MAC_KEY and optionally Context Headers encrypted 576 using ENC_KEY. The scope of the integrity protection provided by 577 this TLV is depicted in Figure 6. 579 This MAC scheme does not require sharing MAC_KEY with SFFs. It does 580 not require to re-compute the MAC by each SFF because of TTL 581 processing. Section 9.1 discusses the possible threat associated 582 with this level of assurance. 584 0 1 2 3 585 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 586 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 587 |Ver|O|U| TTL | Length |U|U|U|U|MD Type| Next Protocol | 588 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<--+ 589 | Service Path Identifier | Service Index | | 590 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 591 | | | 592 ~ Variable-Length Unencrypted Context Headers (opt.) ~ | 593 | | | 594 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 595 | Metadata Class | Type |U| Length | | 596 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 597 | Key Length | Key Identifier ~ | 598 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 599 ~ Timestamp (8 bytes) ~ | 600 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 601 | IV Length | Initialization Vector ~ | 602 +->+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 603 | ~ Context Header TLVs to encrypt (opt.) ~ | 604 +->+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 605 | | | | 606 | ~ Inner Packet on which NSH is imposed ~ | 607 | | | | 608 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<--| 609 | | 610 | | 611 | | 612 | Integrity Protection Scope ----+ 613 +----Encrypted Data 615 Figure 6: Scope of MAC#1 617 In reference to Figure 5, the description of the fields is as 618 follows: 620 o Metadata Class: MUST be set to 0x0 (Section 2.5.1 of [RFC8300]). 622 o Type: TBD1 (See Section 10) 624 o U: Unassigned bit (Section 2.5.1 of [RFC8300]). 626 o Length: Variable. 628 o Key Length: Variable. Carries the length of the key identifier. 630 o Key Identifier: Carries a variable length Key Identifier object 631 used to identify and deliver keys to SFC data plane elements. 633 This identifier is helpful to accommodate deployments relying upon 634 keying material per SFC/SFP. The key identifier helps in 635 resolving the problem of synchronization of keying material. 637 o Timestamp: Carries an unsigned 64-bit integer value that is 638 expressed in seconds relative to 1970-01-01T00:00Z in UTC time. 639 See Section 6 for more details. 641 o IV Length: Carries the length of the IV (Section 5.2 of 642 [RFC7518]). If encryption is not used, IV length is set to zero. 644 o Initialization Vector: Carries the IV for authenticated encryption 645 algorithm as discussed in Section 5.2 of [RFC7518]. 647 o The Additional Authenticated Data (defined in [RFC7518]) MUST be 648 the Service Path header, the unencrypted Context headers, and the 649 inner packet on which the NSH is imposed . 651 o Message Authentication Code covering the entire NSH data excluding 652 the Base header. 654 5.2. MAC#2 Context Header 656 MAC#2 Context Header is a variable-length TLV that carries the MAC 657 for the entire NSH data calculated using MAC_KEY and optionally 658 Context Headers encrypted using ENC_KEY. The scope of the integrity 659 protection provided by this TLV is depicted in Figure 7. 661 0 1 2 3 662 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 663 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<--+ 664 |Ver|O|U| TTL | Length |U|U|U|U|MD Type| Next Protocol | | 665 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 666 | Service Path Identifier | Service Index | | 667 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 668 | | | 669 ~ Variable-Length Unencrypted Context Headers (opt.) ~ | 670 | | | 671 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 672 | Metadata Class | Type |U| Length | | 673 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 674 | Key Length | Key Identifier ~ | 675 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 676 ~ Timestamp (8 bytes) ~ | 677 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 678 | IV Length | Initialization Vector | | 679 +->+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 680 | ~ Context Header TLVs to encrypt (opt.) ~ | 681 +->+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 682 | | | | 683 | ~ Inner Packet on which NSH is imposed ~ | 684 | | | | 685 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<--| 686 | | 687 | | 688 | | 689 | Integrity Protection Scope ----+ 690 +----Encrypted Data 692 Figure 7: Scope of MAC#2 694 In reference to Figure 5, the description of the fields is as 695 follows: 697 o Metadata Class: MUST be set to 0x0 (Section 2.5.1 of [RFC8300]). 699 o Type: TBD2 (See Section 10) 701 o U: Unassigned bit (Section 2.5.1 of [RFC8300]). 703 o Length: Variable. 705 o Key Length: See Section 5.1. 707 o Key Identifier: See Section 5.1. 709 o Timestamp: See Section 6. 711 o IV Length: See Section 5.1. 713 o Initialization Vector: See Section 5.1. 715 o The Additional Authenticated Data (defined in [RFC7518]) MUST be 716 the entire NSH data (i.e., including the Base Header) excluding 717 the Context Headers to be encrypted. 719 o Message Authentication Code covering the entire NSH data and 720 optional encrypted Context Headers. 722 6. Timestamp Format 724 This section follows the template provided in Section 3 of [RFC8877]. 726 The format of the Timestamp field introduced in Section 5 is depicted 727 in Figure 8. 729 0 1 2 3 730 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 731 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 732 | Seconds | 733 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 734 | Fraction | 735 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 737 Figure 8: Timestamp Field Format 739 Timestamp field format: 741 Seconds: specifies the integer portion of the number of seconds 742 since the epoch. 744 + Size: 32 bits. 746 + Units: seconds. 748 Fraction: specifies the fractional portion of the number of 749 seconds since the epoch. 751 + Size: 32 bits. 753 + Units: the unit is 2^(-32) seconds, which is roughly equal to 754 233 picoseconds. 756 Epoch: 758 The epoch is 1970-01-01T00:00Z in UTC time. 760 Leap seconds: 762 This timestamp format is affected by leap seconds. The timestamp 763 represents the number of seconds elapsed since the epoch minus the 764 number of leap seconds. 766 Resolution: 768 The resolution is 2^(-32) seconds. 770 Wraparound: 772 This time format wraps around every 2^32 seconds, which is roughly 773 136 years. The next wraparound will occur in the year 2106. 775 Synchronization aspects: 777 It is assumed that SFC data plane elements are synchronized to UTC 778 using a synchronization mechanism that is outside the scope of 779 this document. In typical deployments SFC data plane elements use 780 NTP [RFC5905] for synchronization. Thus, the timestamp may be 781 derived from the NTP-synchronized clock, allowing the timestamp to 782 be measured with respect to the clock of an NTP server. Since the 783 NTP time format is affected by leap seconds, the current timestamp 784 format is similarly affected. Therefore, the value of a timestamp 785 during or slightly after a leap second may be temporarily 786 inaccurate. 788 7. Processing Rules 790 The following subsections describe the processing rules for integrity 791 protected NSH and optionally encrypted Context Headers. 793 7.1. Generic Behavior 795 This document adheres to the recommendations in [RFC8300] for 796 handling the Context Headers at both ingress and egress SFC boundary 797 nodes (i.e., to strip the entire NSH, including Context Headers). 799 Failures of a classifier to inject the Context Headers defined in 800 this document SHOULD be logged locally while a notification alarm MAY 801 be sent to an SFC control element. Failures of an NSH-aware node to 802 validate the integrity of the NSH data MUST cause that packet to be 803 discarded while a notification alarm MAY be sent to an SFC control 804 element. The details of sending notification alarms (i.e., the 805 parameters affecting the transmission of the notification alarms 806 depend on the information in the context header such as frequency, 807 thresholds, and content in the alarm) SHOULD be configurable by the 808 SFC control plane. 810 NSH-aware SFs and SFC proxies MAY be instructed to strip some 811 encrypted Context Headers from the packet or to pass the data to the 812 next SF in the service function chain after processing the content of 813 the Context Headers. If no instruction is provided, the default 814 behavior for intermediary NSH-aware nodes is to maintain such Context 815 Headers so that the information can be passed to next NSH-aware hops. 816 NSH-aware SFs and SFC proxies MUST re-apply the integrity protection 817 if any modification is made to the Context Headers (strip a Context 818 Header, update the content of an existing Context Header, insert a 819 new Context Header). 821 An NSH-aware SF or SFC Proxy that is not allowed to decrypt any 822 Context Headers MUST NOT be given access to the ENC_KEY. 824 Otherwise, an NSH-aware SF or SFC Proxy that receives encrypted 825 Context Headers, for which it is not allowed to consume a specific 826 Context Header it decrypts (but consumes others), MUST keep that 827 Context Header unaltered when forwarding the packet upstream. 829 Only one instance of "MAC and Encrypted Metadata" Context Header 830 (Section 5) is allowed. If multiple instances of "MAC and Encrypted 831 Metadata" Context Header are included in an NSH packet, the SFC data 832 element MUST process the first instance and ignore subsequent 833 instances, and MAY log or increase a counter for this event as per 834 Section 2.5.1 of [RFC8300]. 836 MTU and fragmentation considerations are discussed in Section 8. 838 7.2. MAC NSH Data Generation 840 If the Context Headers are not encrypted, the HMAC algorithm 841 discussed in [RFC4868] is used to integrity protect the target NSH 842 data. An NSH imposer inserts a "MAC and Encrypted Metadata" Context 843 Header for integrity protection (Section 5). 845 The NSH imposer computes the message integrity for the target NSH 846 data (depending on the integrity protection scope discussed in 847 Section 5) using MAC_KEY and HMAC algorithm. It inserts the MAC in 848 the "MAC and Encrypted Metadata" Context Header. The length of the 849 MAC is decided by the HMAC algorithm adopted for the particular key 850 identifier. 852 The Message Authentication Code (T) computation process can be 853 illustrated as follows: 855 T = HMAC-SHA-256-128(MAC_KEY, A) 857 An entity in the SFP that intends to update the NSH MUST follow the 858 above behavior to maintain message integrity of the NSH for 859 subsequent validations. 861 7.3. Encrypted NSH Metadata Generation 863 An NSH imposer can encrypt Context Headers carrying privacy-sensitive 864 metadata, i.e., encrypted and unencrypted metadata may be carried 865 simultaneously in the same NSH packet (Figure 9). 867 0 1 2 3 868 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 869 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 870 |Ver|O|U| TTL | Length |U|U|U|U|MD Type| Next Protocol | 871 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 872 | Service Path Identifier | Service Index | 873 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 874 | | 875 ~ Variable-Length Unencrypted Context Headers (opt.) ~ 876 | | 877 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 878 ~ Key Identifier ~ 879 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 880 ~ Timestamp ~ 881 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 882 | | 883 ~ MAC and Encrypted Context Headers ~ 884 | | 885 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 887 Figure 9: NSH with Encrypted and Unencrypted Metadata 889 In an SFC-enabled domain where pervasive monitoring [RFC7258] is 890 possible, all Context Headers carrying privacy-sensitive metadata 891 MUST be encrypted; doing so, privacy-sensitive metadata is not 892 revealed to attackers. Privacy specific threats are discussed in 893 Section 5.2 of [RFC6973]. 895 Using K and authenticated encryption algorithm, the NSH imposer 896 encrypts the Context Headers (as set by the control plane Section 3), 897 computes the message integrity for the target NSH data, and inserts 898 the resulting payload in the "MAC and Encrypted Metadata" Context 899 Header (Section 5). The entire TLV carrying a privacy-sensitive 900 metadata is encrypted (that is, including the MD Class, Type, Length, 901 and associated metadata of each Context Header). 903 The message Authentication Tag (T) and ciphertext (E) computation 904 process can be illustrated as follows: 906 MAC_KEY = initial MAC_KEY_LEN octets of K, 907 ENC_KEY = final ENC_KEY_LEN octets of K, 908 E = CBC-PKCS7-ENC(ENC_KEY, P), 909 M = MAC(MAC_KEY, A || IV || E || AL), 910 T = initial T_LEN octets of M. 911 MAC and Encrypted Metadata = E || T 913 As specified in [RFC7518], the octet string (AL) is equal to the 914 number of bits in the Additional Authenticated Data (A) expressed as 915 a 64-bit unsigned big-endian integer. 917 An authorized entity in the SFP that intends to update the content of 918 an encrypted Context Header or needs to add a new encrypted Context 919 Header MUST also follow the aforementioned behavior. 921 An SFF or NSH-aware SF or SFC Proxy that only has access to the 922 MAC_KEY, but not the ENC_KEY, computes the message Authentication Tag 923 (T) after decrementing the TTL (by the SFF) or SI (by an SF or SFC 924 Proxy) and replaces the Authentication Tag in the NSH with the 925 computed Authentication Tag. Similarly, an NSH-aware SF (or SFC 926 Proxy) that does not modify the encrypted Context headers also 927 follows the aforementioned behavior. 929 The message Authentication Tag (T) computation process can be 930 illustrated as follows: 932 M = MAC(MAC_KEY, A || IV || E || AL), 933 T = initial T_LEN octets of M. 935 7.4. Timestamp for Replay Attack 937 The Timestamp imposed by an initial Classifier is left untouched 938 along an SFP. However, it can be updated when reclassification 939 occurs (Section 4.8 of [RFC7665]). The same considerations for 940 setting the Timestamp are followed in both initial classification and 941 reclassification (Section 6). 943 The received NSH is accepted by an NSH-aware node if the Timestamp 944 (TS) in the NSH is recent enough to the reception time of the NSH 945 (TSrt). The following formula is used for this check: 947 -Delta < (TSrt - TS) < +Delta 949 The Delta interval is a configurable parameter. The RECOMMENDED 950 value for the allowed Delta is 2 seconds. If the timestamp is not 951 within the boundaries, then the SFC data plane element receiving such 952 packet MUST discard the NSH message. 954 Replay attacks are still possible within the Delta window, but that 955 is an acceptable risk. Lowering the Delta interval may soften this 956 risk, but special care should be taken when setting very low values 957 as this may lead to dropping legitimate traffic. 959 Note 1: Replay attacks within the Delta window may be detected by 960 an NSH-aware node by recording a unique value derived, for 961 example, from the NSH data and Original packet (e.g., using SHA2). 962 Such NSH-aware node will reject duplicates when the count of a 963 given derived value exceeds a particular threshold. The SF has to 964 maintain the unique values only for the time of Delta interval 965 seconds. The complexity of such approach is to be weighted 966 against other methods (e.g., set a lower acceptable Delta value) 967 and actual risks specific to each deployment. 969 Note 2: Within the timestamp delta window, defining a sequence 970 number to protect against replay attacks may be considered. In 971 such mode, NSH-aware nodes must discard packets with duplicate 972 sequence numbers within the timestamp delta window. However, in 973 deployments with several instances of the same SF (e.g., cluster 974 or load-balanced SFs), a mechanism to coordinate among those 975 instances to discard duplicate sequence numbers is required. 976 Because the coordination mechanism to comply with this requirement 977 is service-specific, this document does not include this 978 protection. 980 All SFC data plane elements must be synchronized among themselves. 981 These elements may be synchronized to a global reference time. 983 7.5. NSH Data Validation 985 When an SFC data plane element receives an NSH packet, it MUST first 986 ensure that a "MAC and Encrypted Metadata" Context Header is 987 included. It MUST silently discard the message if the timestamp is 988 invalid (Section 7.4). It MUST log an error at least once per the 989 SPI for which the "MAC and Encrypted Metadata" Context Header is 990 missing. 992 If the timestamp check is successfully passed, the SFC data plane 993 element proceeds then with NSH data integrity validation. The SFC 994 data plane element computes the message integrity for the target NSH 995 data (depending on the integrity protection scope discussed in 996 Section 5) using the MAC_KEY and HMAC algorithm for the key 997 identifier. If the value of the newly generated digest is identical 998 to the one enclosed in the NSH, the SFC data plane element is certain 999 that the NSH data has not been tampered and validation is therefore 1000 successful. Otherwise, the NSH packet MUST be discarded. 1002 7.6. Decryption of NSH Metadata 1004 If entitled to consume a supplied encrypted Context Header, an NSH- 1005 aware SF or SFC Proxy decrypts metadata using (K) and decryption 1006 algorithm for the key identifier in the NSH. 1008 Authenticated encryption algorithm has only a single output, either a 1009 plaintext or a special symbol (FAIL) that indicates that the inputs 1010 are not authentic (Section 5.2.2.2 of [RFC7518]). 1012 8. MTU Considerations 1014 The SFC architecture prescribes that additional information be added 1015 to packets to: 1017 o Identify SFPs: this is typically the NSH Base Header and Service 1018 Path Header. 1020 o Carry metadata such those defined in Section 5. 1022 o Steer the traffic along the SFPs: transport encapsulation. 1024 This added information increases the size of the packet to be carried 1025 along an SFP. 1027 Aligned with Section 5 of [RFC8300], it is RECOMMENDED for network 1028 operators to increase the underlying MTU so that NSH traffic is 1029 forwarded within an SFC-enabled domain without fragmentation. The 1030 available underlying MTU should be taken into account by network 1031 operators when providing SFs with the required Context Headers to be 1032 injected per SFP and the size of the data to be carried in these 1033 Context Headers. 1035 If the underlying MTU cannot be increased to accommodate the NSH 1036 overhead, network operators may rely upon a transport encapsulation 1037 protocol with the required fragmentation handling. The impact of 1038 activating such feature on SFFs should be carefully assessed by 1039 network operators (Section 5.6 of [RFC7665]). 1041 When dealing with MTU issues, network operators should consider the 1042 limitations of various transport encapsulations such as those 1043 discussed in [I-D.ietf-intarea-tunnels]. 1045 9. Security Considerations 1047 Data plane SFC-related security considerations, including privacy, 1048 are discussed in Section 6 of [RFC7665] and Section 8 of [RFC8300]. 1049 In particular, Section 8.2.2 of [RFC8300] states that attached 1050 metadata (i.e., Context Headers) should be limited to that necessary 1051 for correct operation of the SFP. Also, that section indicates that 1052 [RFC8165] discusses metadata considerations that operators can take 1053 into account when using NSH. 1055 The guidelines for cryptographic key management are discussed in 1056 [RFC4107]. 1058 The interaction between the SFC data plane elements and a key 1059 management system MUST NOT be transmitted in clear since this would 1060 completely destroy the security benefits of the integrity protection 1061 solution defined in this document. The secret key (K) must have an 1062 expiration time assigned as the latest point in time before which the 1063 key may be used for integrity protection of NSH data and encryption 1064 of Context Headers. Prior to the expiration of the secret key, all 1065 participating NSH-aware nodes SHOULD have the control plane 1066 distribute a new key identifier and associated keying material so 1067 that when the secret key is expired, those nodes are prepared with 1068 the new secret key. This allows the NSH imposer to switch to the new 1069 key identifier as soon as necessary. It is RECOMMENDED that the next 1070 key identifier and associated keying material be distributed by the 1071 control plane well prior to the secret key expiration time. 1073 NSH data are exposed to several threats: 1075 o A man-in-the-middle attacker modifying the NSH data. 1077 o Attacker spoofing the NSH data. 1079 o Attacker capturing and replaying the NSH data. 1081 o Data carried in Context Headers revealing privacy-sensitive 1082 information to attackers. 1084 o Attacker replacing the packet on which the NSH is imposed with a 1085 bogus packet. 1087 In an SFC-enabled domain where the above attacks are possible, (1) 1088 NSH data MUST be integrity-protected and replay-protected, and (2) 1089 privacy-sensitive NSH metadata MUST be encrypted for confidentiality 1090 preservation purposes. The Base and Service Path headers are not 1091 encrypted. 1093 MACs with two levels of assurance are defined in Section 5. 1094 Considerations specific to each level of assurance are discussed in 1095 Sections 9.1 and 9.2. 1097 The attacks discussed in [I-D.nguyen-sfc-security-architecture] are 1098 handled owing to the solution specified in this document, except for 1099 attacks dropping packets. Such attacks can be detected relying upon 1100 statistical analysis; such analysis is out of scope of this document. 1101 Also, if SFFs are not involved in the integrity checks, a misbehaving 1102 SFF which decrements SI while this should be done by an SF (SF bypass 1103 attack) will be detected by an upstream SF because the integrity 1104 check will fail. 1106 Some events are logged locally with notification alerts sent by NSH- 1107 aware nodes to a Control Element. These events SHOULD be rate 1108 limited. 1110 The solution specified in this document does not provide data origin 1111 authentication. 1113 In order to detect compromised nodes, it is assumed that appropriate 1114 mechanisms to monitor and audit an SFC-enabled domain to detect 1115 misbehavior and to deter misuse are in place. Compromised nodes can 1116 thus be withdrawn from active service function chains using 1117 appropriate control plane mechanisms. 1119 9.1. MAC#1 1121 An active attacker can potentially modify the Base header (e.g., 1122 decrement the TTL so the next SFF in the SFP discards the NSH 1123 packet). In the meantime, an active attacker can also drop NSH 1124 packets. As such, this attack is not considered an attack against 1125 the security mechanism specified in the document. 1127 No device other than the NSH-aware SFs in the SFC-enabled domain 1128 should be able to update the integrity protected NSH data. 1129 Similarly, no device other than the NSH-aware SFs and SFC proxies in 1130 the SFC-enabled domain should be able to decrypt and update the 1131 Context Headers carrying privacy-sensitive metadata. In other words, 1132 if the NSH-aware SFs and SFC proxies in the SFC-enabled domain are 1133 considered fully trusted to act on the NSH data, only these elements 1134 can have access to privacy-sensitive NSH metadata and the keying 1135 material used to integrity protect NSH data and encrypt Context 1136 Headers. 1138 9.2. MAC#2 1140 SFFs can detect whether an illegitimate node has altered the content 1141 of the Base header. Such messages must be discarded with appropriate 1142 logs and alarms generated (see Section 7.1). 1144 9.3. Time Synchronization 1146 Section 5.6 of [RFC8633] describes best current practices to be 1147 considered in deployments where SFC data plane elements use NTP for 1148 time synchronization purposes. 1150 Also, a mechanism to provide cryptographic security for NTP is 1151 specified in [RFC8915]. 1153 10. IANA Considerations 1155 This document requests IANA to assign the following types from the 1156 "NSH IETF-Assigned Optional Variable-Length Metadata Types" (0x0000 1157 IETF Base NSH MD Class) registry available at: 1158 https://www.iana.org/assignments/nsh/nsh.xhtml#optional-variable- 1159 length-metadata-types. 1161 +-------+-------------------------------+----------------+ 1162 | Value | Description | Reference | 1163 +=======+===============================+================+ 1164 | TBD1 | MAC and Encrypted Metadata #1 | [ThisDocument] | 1165 | TBD2 | MAC and Encrypted Metadata #2 | [ThisDocument] | 1166 +-------+-------------------------------+----------------+ 1168 11. Acknowledgements 1170 This document was edited as a follow up to the discussion in 1171 IETF#104: https://datatracker.ietf.org/meeting/104/materials/slides- 1172 104-sfc-sfc-chair-slides-01 (slide 7). 1174 Thanks to Joel Halpern, Christian Jacquenet, Dirk von Hugo, Tal 1175 Mizrahi, Daniel Migault, and Diego Lopez for the comments. 1177 Many thanks to Steve Hanna for the valuable secdir review. 1179 12. References 1181 12.1. Normative References 1183 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1184 Requirement Levels", BCP 14, RFC 2119, 1185 DOI 10.17487/RFC2119, March 1997, 1186 . 1188 [RFC4107] Bellovin, S. and R. Housley, "Guidelines for Cryptographic 1189 Key Management", BCP 107, RFC 4107, DOI 10.17487/RFC4107, 1190 June 2005, . 1192 [RFC4868] Kelly, S. and S. Frankel, "Using HMAC-SHA-256, HMAC-SHA- 1193 384, and HMAC-SHA-512 with IPsec", RFC 4868, 1194 DOI 10.17487/RFC4868, May 2007, 1195 . 1197 [RFC7518] Jones, M., "JSON Web Algorithms (JWA)", RFC 7518, 1198 DOI 10.17487/RFC7518, May 2015, 1199 . 1201 [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function 1202 Chaining (SFC) Architecture", RFC 7665, 1203 DOI 10.17487/RFC7665, October 2015, 1204 . 1206 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1207 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1208 May 2017, . 1210 [RFC8300] Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed., 1211 "Network Service Header (NSH)", RFC 8300, 1212 DOI 10.17487/RFC8300, January 2018, 1213 . 1215 [RFC8877] Mizrahi, T., Fabini, J., and A. Morton, "Guidelines for 1216 Defining Packet Timestamps", RFC 8877, 1217 DOI 10.17487/RFC8877, September 2020, 1218 . 1220 12.2. Informative References 1222 [I-D.arkko-farrell-arch-model-t] 1223 Arkko, J. and S. Farrell, "Challenges and Changes in the 1224 Internet Threat Model", draft-arkko-farrell-arch-model- 1225 t-04 (work in progress), July 2020. 1227 [I-D.ietf-intarea-tunnels] 1228 Touch, J. and M. Townsley, "IP Tunnels in the Internet 1229 Architecture", draft-ietf-intarea-tunnels-10 (work in 1230 progress), September 2019. 1232 [I-D.nguyen-sfc-security-architecture] 1233 Nguyen, T. and M. Park, "A Security Architecture Against 1234 Service Function Chaining Threats", draft-nguyen-sfc- 1235 security-architecture-00 (work in progress), November 1236 2019. 1238 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, 1239 "Network Time Protocol Version 4: Protocol and Algorithms 1240 Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, 1241 . 1243 [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., 1244 Morris, J., Hansen, M., and R. Smith, "Privacy 1245 Considerations for Internet Protocols", RFC 6973, 1246 DOI 10.17487/RFC6973, July 2013, 1247 . 1249 [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an 1250 Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 1251 2014, . 1253 [RFC7498] Quinn, P., Ed. and T. Nadeau, Ed., "Problem Statement for 1254 Service Function Chaining", RFC 7498, 1255 DOI 10.17487/RFC7498, April 2015, 1256 . 1258 [RFC7635] Reddy, T., Patil, P., Ravindranath, R., and J. Uberti, 1259 "Session Traversal Utilities for NAT (STUN) Extension for 1260 Third-Party Authorization", RFC 7635, 1261 DOI 10.17487/RFC7635, August 2015, 1262 . 1264 [RFC8165] Hardie, T., "Design Considerations for Metadata 1265 Insertion", RFC 8165, DOI 10.17487/RFC8165, May 2017, 1266 . 1268 [RFC8459] Dolson, D., Homma, S., Lopez, D., and M. Boucadair, 1269 "Hierarchical Service Function Chaining (hSFC)", RFC 8459, 1270 DOI 10.17487/RFC8459, September 2018, 1271 . 1273 [RFC8633] Reilly, D., Stenn, H., and D. Sibold, "Network Time 1274 Protocol Best Current Practices", BCP 223, RFC 8633, 1275 DOI 10.17487/RFC8633, July 2019, 1276 . 1278 [RFC8915] Franke, D., Sibold, D., Teichel, K., Dansarie, M., and R. 1279 Sundblad, "Network Time Security for the Network Time 1280 Protocol", RFC 8915, DOI 10.17487/RFC8915, September 2020, 1281 . 1283 Authors' Addresses 1285 Mohamed Boucadair 1286 Orange 1287 Rennes 35000 1288 France 1290 Email: mohamed.boucadair@orange.com 1292 Tirumaleswar Reddy 1293 McAfee, Inc. 1294 Embassy Golf Link Business Park 1295 Bangalore, Karnataka 560071 1296 India 1298 Email: TirumaleswarReddy_Konda@McAfee.com 1300 Dan Wing 1301 Citrix Systems, Inc. 1302 USA 1304 Email: dwing-ietf@fuggles.com