idnits 2.17.00 (12 Aug 2021) /tmp/idnits32617/draft-ietf-sfc-nsh-tlv-15.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 document date (20 April 2022) is 24 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) == Outdated reference: draft-ietf-sfc-nsh-integrity has been published as RFC 9145 -- Possible downref: Non-RFC (?) normative reference: ref. 'IANA-NSH-MD2' Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Service Function Chaining Working Group Yuehua. Wei, Ed. 3 Internet-Draft ZTE Corporation 4 Intended status: Standards Track U. Elzur 5 Expires: 22 October 2022 Intel 6 S. Majee 7 Individual contributor 8 C. Pignataro 9 Cisco 10 D. Eastlake 11 Futurewei Technologies 12 20 April 2022 14 Network Service Header (NSH) Metadata Type 2 Variable-Length Context 15 Headers 16 draft-ietf-sfc-nsh-tlv-15 18 Abstract 20 Service Function Chaining (SFC) uses the Network Service Header (NSH) 21 (RFC 8300) to steer and provide context Metadata (MD) with each 22 packet. Such Metadata can be of various Types including MD Type 2 23 consisting of variable length context headers. This document 24 specifies several such context headers that can be used within a 25 service function path. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at https://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on 22 October 2022. 44 Copyright Notice 46 Copyright (c) 2022 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 51 license-info) in effect on the date of publication of this document. 52 Please review these documents carefully, as they describe your rights 53 and restrictions with respect to this document. Code Components 54 extracted from this document must include Revised BSD License text as 55 described in Section 4.e of the Trust Legal Provisions and are 56 provided without warranty as described in the Revised BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 2. Conventions used in this document . . . . . . . . . . . . . . 3 62 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 63 2.2. Requirements Language . . . . . . . . . . . . . . . . . . 3 64 3. NSH MD Type 2 format . . . . . . . . . . . . . . . . . . . . 3 65 4. NSH MD Type 2 Context Headers . . . . . . . . . . . . . . . . 4 66 4.1. Forwarding Context . . . . . . . . . . . . . . . . . . . 4 67 4.2. Tenant Identifier . . . . . . . . . . . . . . . . . . . . 6 68 4.3. Ingress Network Node Information . . . . . . . . . . . . 7 69 4.4. Ingress Network Source Interface . . . . . . . . . . . . 8 70 4.5. Flow ID . . . . . . . . . . . . . . . . . . . . . . . . . 8 71 4.6. Source and/or Destination Groups . . . . . . . . . . . . 9 72 4.7. Policy Identifier . . . . . . . . . . . . . . . . . . . . 10 73 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 74 5.1. Forwarding Context . . . . . . . . . . . . . . . . . . . 11 75 5.2. Tenant Identifier . . . . . . . . . . . . . . . . . . . . 12 76 5.3. Ingress Network Node Information . . . . . . . . . . . . 12 77 5.4. Ingress Node Source Interface . . . . . . . . . . . . . . 12 78 5.5. Flow ID . . . . . . . . . . . . . . . . . . . . . . . . . 12 79 5.6. Source and/or Destination Groups . . . . . . . . . . . . 13 80 5.7. Policy Identifier . . . . . . . . . . . . . . . . . . . . 13 81 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 82 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 83 7.1. MD Type 2 Context Types . . . . . . . . . . . . . . . . . 13 84 7.2. Forwarding Context Types . . . . . . . . . . . . . . . . 14 85 7.3. Flow ID Context Types . . . . . . . . . . . . . . . . . . 15 86 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 87 8.1. Normative References . . . . . . . . . . . . . . . . . . 15 88 8.2. Informative References . . . . . . . . . . . . . . . . . 16 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 91 1. Introduction 93 The Network Service Header (NSH) [RFC8300] is the Service Function 94 Chaining (SFC) encapsulation that supports the SFC architecture 95 [RFC7665]. As such, the NSH provides following key elements: 97 1. Service Function Path (SFP) identification. 99 2. Indication of location within a Service Function Path. 101 3. Optional, per-packet metadata (fixed-length or variable-length). 103 [RFC8300] further defines two metadata formats (MD Types): 1 and 2. 104 MD Type 1 defines the fixed-length, 16-octet long metadata, whereas 105 MD Type 2 defines a variable-length context format for metadata. 106 This document defines several common metadata context headers for use 107 within NSH MD Type 2. These supplement the Subscriber Identity and 108 Performance Policy MD Type 2 metadata context headers specified in 109 [RFC8979]. 111 This document does not address metadata usage, updating/chaining of 112 metadata, or other SFP functions. Those topics are described in 113 [RFC8300]. 115 2. Conventions used in this document 117 2.1. Terminology 119 This document uses the terminology defined in the SFC Architecture 120 [RFC7665] and the Network Service Header [RFC8300]. 122 2.2. Requirements Language 124 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 125 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 126 "OPTIONAL" in this document are to be interpreted as described in BCP 127 14 [RFC2119] [RFC8174] when, and only when, they appear in all 128 capitals, as shown here. 130 3. NSH MD Type 2 format 132 An NSH is composed of a 4-octet Base Header, a 4-octet Service Path 133 Header and optional Context Headers. The Base Header identifies the 134 MD-Type in use: 136 0 1 2 3 137 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 138 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 139 |Ver|O|U| TTL | Length |U|U|U|U|MD Type| Next Protocol | 140 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 142 Figure 1: NSH Base Header 144 Please refer to NSH [RFC8300] for a detailed header description. 146 When the base header specifies MD Type = 0x2, zero or more Variable 147 Length Context Headers MAY be added, immediately following the 148 Service Path Header. Figure 2 below depicts the format of the 149 Context Header as defined in Section 2.5.1 of [RFC8300]. 151 0 1 2 3 152 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 153 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 154 | Metadata Class | Type |U| Length | 155 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 156 | Variable-Length Metadata | 157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 159 Figure 2: NSH Variable-Length Context Headers 161 4. NSH MD Type 2 Context Headers 163 [RFC8300] specifies Metadata Class 0x0000 as IETF Base NSH MD Class. 164 In this document, metadata types are defined for the IETF Base NSH MD 165 Class. The Context Headers specified in the subsections below are as 166 follows: 168 1. Forwarding Context 170 2. Tenant Identifier 172 3. Ingress Network Node Information 174 4. Ingress Node Source Interface 176 5. Flow ID 178 6. Source and/or Destination Groups 180 7. Policy Identifier 182 4.1. Forwarding Context 184 This metadata context carries a network forwarding context, used for 185 segregation and forwarding scope. Forwarding context can take 186 several forms depending on the network environment. For example, 187 VXLAN/VXLAN-GPE VNID, VRF identification, or VLAN. 189 0 1 2 3 190 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 191 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 192 | Metadata Class = 0x0000 | Type = TBA1 |U| Length = 4 | 193 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 194 |CT=0x0 | Reserved | VLAN ID | 195 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 197 Figure 3: VLAN Forwarding Context 199 0 1 2 3 200 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 201 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 202 | Metadata Class = 0x0000 | Type = TBA1 |U| Length = 4 | 203 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 204 |CT=0x1 |Resv | Service VLAN ID | Customer VLAN ID | 205 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 207 Figure 4: QinQ Forwarding Context 209 0 1 2 3 210 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 211 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 212 | Metadata Class = 0x0000 | Type = TBA1 |U| Length = 4 | 213 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 214 |CT=0x2 | Reserved | MPLS VPN Label | 215 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 217 Figure 5: MPLS VPN Forwarding Context 219 0 1 2 3 220 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 221 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 222 | Metadata Class = 0x0000 | Type = TBA1 |U| Length = 4 | 223 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 224 |CT=0x3 | Resv | Virtual Network Identifier | 225 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 227 Figure 6: VNI Forwarding Context 229 0 1 2 3 230 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 231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 232 | Metadata Class = 0x0000 | Type = TBA1 |U| Length = 8 | 233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 234 |CT=0x4 | Reserved | 235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 236 | Session ID | 237 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 239 Figure 7: Session ID Forwarding Context 241 where: 243 Context Type (CT) is four bits-long field that defines the 244 interpretation of the Forwarding Context field. Please see the 245 IANA Considerations in Section 7.2. This document defines these 246 CT values: 248 - 0x0 - 12 bits VLAN identifier [IEEE.802.1Q_2018]. See 249 Figure 3. 251 - 0x1 - 24 bits double tagging identifiers. A service VLAN tag 252 followed by a customer VLAN tag [IEEE.802.1Q_2018]. The two 253 VLAN IDs are concatenated and appear in the same order that 254 they appeared in the payload. See Figure 4. 256 - 0x2 - 20 bits MPLS VPN label([RFC3032])([RFC4364]). See 257 Figure 5. 259 - 0x3 - 24 bits virtual network identifier (VNI)[RFC8926]. See 260 Figure 6. 262 - 0x4 - 32 bits Session ID ([RFC3931]). This is called Key in 263 GRE [RFC2890]. See Figure 7. 265 Reserved (Resv) bits in the context fields MUST be sent as zero 266 and ignored on receipt. 268 4.2. Tenant Identifier 270 Tenant identification is often used for segregation within a multi- 271 tenant environment. Orchestration system-generated tenant IDs are an 272 example of such data. This context header carries the value of the 273 Tenant identifier. [OpenDaylight-VTN] Virtual Tenant Network (VTN) 274 is an application that provides multi-tenant virtual network on an 275 SDN controller. 277 0 1 2 3 278 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 279 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 280 | Metadata Class = 0x0000 | Type = TBA2 |U| Length | 281 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 282 ~ Tenant ID ~ 283 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 285 Figure 8: Tenant Identifier List 287 The fields are described as follows: 289 Length: Indicates the length of the Tenant ID in octets (see 290 Section 2.5.1 of [RFC8300]). 292 Tenant ID: Represents an opaque value pointing to Orchestration 293 system-generated tenant identifier. The structure and semantics 294 of this field are specific to the operator's deployment across its 295 operational domain, and are specified and assigned by an 296 orchestration function. The specifics of that orchestration-based 297 assignment are outside the scope of this document. 299 4.3. Ingress Network Node Information 301 This context header carries a Node ID of the network node at which 302 the packet entered the SFC-enabled domain. This node will 303 necessarily be a Classifier [RFC7665]. In cases where the SPI 304 identifies the ingress node, this context header is superfluous. 306 0 1 2 3 307 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 308 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 309 | Metadata Class = 0x0000 | Type = TBA3 |U| Length | 310 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 311 ~ Node ID ~ 312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 314 Figure 9: Ingress Network Node ID 316 The fields are described as follows: 318 Length: Indicates the length of the Node ID in octets (see 319 Section 2.5.1 of [RFC8300]). 321 Node ID: Represents an opaque value of the ingress network node 322 ID. The structure and semantics of this field are deployment 323 specific. For example, Node ID may be a 4 octets IPv4 address 324 Node ID, or a 16 octets IPv6 address Node ID, or a 6 octets MAC 325 address, or 8 octets MAC address (EUI-64), etc. 327 4.4. Ingress Network Source Interface 329 This context identifies the ingress interface of the ingress network 330 node. The l2vlan (135), l3ipvlan (136), ipForward (142), mpls (166) 331 in [IANAifType] are examples of source interfaces. 333 0 1 2 3 334 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 335 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 336 | Metadata Class = 0x0000 | Type = TBA4 |U| Length | 337 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 338 ~ Source Interface ~ 339 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 341 Figure 10: Ingress Network Source Interface 343 The fields are described as follows: 345 Length: Indicates the length of the Source Interface in octets 346 (see Section 2.5.1 of [RFC8300]). 348 Source Interface: Represents an opaque value of identifier of the 349 ingress interface of the ingress network node. 351 4.5. Flow ID 353 Flow ID provides a field in the NSH MD Type 2 to label packets 354 belonging to the same flow. For example, [RFC8200] defined IPv6 Flow 355 Label as Flow ID, [RFC6790] defined an entropy label which is 356 generated based on flow information in the MPLS network is another 357 example of Flow ID. Absence of this field, or a value of zero 358 denotes that packets have not been labeled with a Flow ID. 360 0 1 2 3 361 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 362 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 363 | Metadata Class = 0x0000 | Type = TBA5 |U| Length = 4 | 364 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 365 |CT=0x0 | Reserved | IPv6 Flow ID | 366 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 367 Figure 11: IPv6 Flow ID 369 0 1 2 3 370 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 371 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 372 | Metadata Class = 0x0000 | Type = TBA5 |U| Length = 4 | 373 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 374 |CT=0x1 | Reserved | MPLS entropy label | 375 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 377 Figure 12: MPLS entropy label 379 The fields are described as follows: 381 Length: Indicates the length of the Flow ID in octets (see 382 Section 2.5.1 of [RFC8300]). For example, IPv6 Flow Label in 383 [RFC8200] is 20-bit long. An entropy label in the MPLS network in 384 [RFC6790] is also 20-bit long. 386 Context Type (CT) is four bits-long field that defines the 387 interpretation of the Flow ID field. Please see the IANA 388 Considerations in Section 7.3. This document defines these CT 389 values: 391 - 0x0 - 20 bits IPv6 Flow Label in [RFC8200]. See Figure 11. 393 - 0x1 - 20 bits entropy label in the MPLS network in [RFC6790]. 394 See Figure 12. 396 Reserved bits in the context fields MUST be sent as zero and 397 ignored on receipt. 399 4.6. Source and/or Destination Groups 401 Intent-based systems can use this data to express the logical 402 grouping of source and/or destination objects. [OpenStack] and 403 [OpenDaylight] provide examples of such a system. Each is expressed 404 as a 32-bit opaque object. 406 0 1 2 3 407 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 408 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 409 | Metadata Class = 0x0000 | Type = TBA6 |U| Length=8 | 410 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 411 | Source Group | 412 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 413 | Destination Group | 414 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 416 Figure 13: Source/Destination Groups 418 If there is no group information specified for the source group or 419 destination group field, the field MUST be sent as zero and ignored 420 on receipt. 422 4.7. Policy Identifier 424 Traffic handling policies are often referred to by a system-generated 425 identifier, which is then used by the devices to look up the policy's 426 content locally. For example, this identifier could be an index to 427 an array, a lookup key, a database Id. The identifier allows 428 enforcement agents or services to look up the content of their part 429 of the policy. 431 0 1 2 3 432 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 433 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 434 | Metadata Class = 0x0000 | Type = TBA7 |U| Length | 435 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 436 ~ Policy ID ~ 437 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 439 Figure 14: Policy ID 441 The fields are described as follows: 443 Length: Indicates the length of the Policy ID in octets (see 444 Section 2.5.1 of [RFC8300]). 446 Policy ID: Represents an opaque value of the Policy ID. 448 This policy identifier is a general policy ID, essentially a key to 449 allow Service Functions to know which policies to apply to packets. 450 Those policies generally will not have much to do with performance, 451 but rather with what specific treatment to apply. It may for example 452 select a URL filter data set for a URL filter, or select a video 453 transcoding policy in a transcoding SF. The Performance Policy 454 Identifier in [RFC8979] is described there as having very specific 455 use, and for example says that fully controlled SFPs would not use 456 it. The Policy ID in this document is for cases not covered by 457 [RFC8979]. 459 5. Security Considerations 461 A misbehaving node from within the SFC-enabled domain may alter the 462 content of the Context Headers, which may lead to service disruption. 463 Such an attack is not unique to the Context Headers defined in this 464 document. Measures discussed in Section 8 of [RFC8300] describes the 465 general security considerations for protecting NSH. 466 [I-D.ietf-sfc-nsh-integrity] specifies methods of protecting the 467 integrity of the NSH metadata. If the NSH includes the MAC and 468 Encrypted Metadata Context Header [RFC9145], the authentication of 469 the packet MUST be verified before using any data. If the 470 verification fails, the receiver MUST stop processing the variable 471 length context headers and notify an operator. 473 The security and privacy considerations for the 7 types of context 474 header specified above are discussed below. Since NSH ignorant SFs 475 will never see the NSH, then even if they are malign, they cannot 476 compromise security or privacy based on the NSH or any of these 477 context headers, although they could cause compromise based on the 478 rest of the packet. To the extent that any of these headers is 479 included when it would be unneeded or have no effect, they provide a 480 covert channel for the entity adding the context header to 481 communicate a limited amount of arbitrary information to downstream 482 entities within the SFC-enabled domain. 484 5.1. Forwarding Context 486 All of the Forwarding Context variants specified in this document 487 (those with CT values between 0 and 4) merely repeat a field that is 488 available in the packet encapsulated by the NSH. These variants 489 repeat that field in the NSH for convenience. Thus, there are no 490 special security or privacy considerations in these cases. Any 491 future new values of CT for the Forwarding Context must specify the 492 security and privacy considerations for those extensions. 494 5.2. Tenant Identifier 496 The Tenant ID indicates the tenant to which traffic belongs and might 497 be used to tie together and correlate packets for a tenant that some 498 monitoring function could not otherwise group especially if other 499 possible identifiers were being randomized. As such, it may reduce 500 security by facilitating traffic analysis but only within the SFC- 501 enabled domain where this context header is present in packets. 503 5.3. Ingress Network Node Information 505 The SFC-enabled domain manager normally operates the initial ingress 506 / classifier node and is thus potentially aware of the information 507 provided by this context header. Furthermore, in many cases the SPI 508 that will be present in the NSH identifies or closely constrains the 509 ingress node. Also, in most cases, it is anticipated that many 510 entities will be sending packets into an SFC-enabled domain through 511 the same ingress node. Thus, under most circumstances, this context 512 header is expected to weaken security and privacy to only a minor 513 extent and only within the SFC-enabled domain. 515 5.4. Ingress Node Source Interface 517 This context header is likely to be meaningless unless the Ingress 518 Network Node Information context header is also present. When that 519 node information header is present, this source interface header 520 provides a more fine-grained view of the source by identifying not 521 just the initial ingress / classifier node but also the port of that 522 node on which the data arrived. Thus, it is more likely to identify 523 a specific source entity or at least to more tightly constrain the 524 set of possible source entities, than just the node information 525 header. As a result, inclusion of this context header with the node 526 information context header is potentially a greater threat to 527 security and privacy than the node information header alone but this 528 threat is still constrained to the SFC-enabled domain. 530 5.5. Flow ID 532 The variations of this context header specified in this document 533 simply repeat fields already available in the packet and thus have no 534 special security or privacy considerations. Any future new values of 535 CT for the Flow ID must specify the security and privacy 536 considerations for those extensions. 538 5.6. Source and/or Destination Groups 540 This context header provides additional information that might help 541 identify the source and/or destination of packets. Depending on the 542 granularity of the groups, it could either (1) distinguish packets as 543 part of flows from and/or to objects where those flows could not 544 otherwise be easily distinguished but appear to be part of one or 545 fewer flows or (2) group packet flows that are from and/or to an 546 object where those flows could not otherwise be easily grouped for 547 analysis or whatever. Thus, the presence of this context header with 548 non-zero source and/or destination groups can, within the SFC-enabled 549 domain, erode security and privacy to an extent that depends on the 550 details of the grouping. 552 5.7. Policy Identifier 554 This context header carries an identifier that nodes in the SFC- 555 enabled domain can use to look up policy to potentially influence 556 their actions with regard to the packet carrying this header. If 557 there are no such action decisions, then the header should not be 558 included. If are such decisions, the information on which they are 559 to be based needs to be included somewhere in the packet. There is 560 no reason for inclusion in this context header to have any security 561 or privacy considerations that would not apply to any other plaintext 562 way of including such information. It may provide additional 563 information to help identify a flow of data for analysis. 565 6. Acknowledgments 567 The authors would like to thank Paul Quinn, Behcet Sarikaya, Dirk von 568 Hugo, Mohamed Boucadair, Gregory Mirsky, and Joel Halpern for 569 providing invaluable concepts and content for this document. 571 7. IANA Considerations 573 7.1. MD Type 2 Context Types 575 IANA is requested to assign the following types (Table 1) from the 576 "NSH IETF-Assigned Optional Variable-Length Metadata Types" registry 577 available at [IANA-NSH-MD2]. 579 +=======+==================================+===============+ 580 | Value | Description | Reference | 581 +=======+==================================+===============+ 582 | TBA1 | Forwarding Context | This document | 583 +-------+----------------------------------+---------------+ 584 | TBA2 | Tenant Identifier | This document | 585 +-------+----------------------------------+---------------+ 586 | TBA3 | Ingress Network NodeID | This document | 587 +-------+----------------------------------+---------------+ 588 | TBA4 | Ingress Network Interface | This document | 589 +-------+----------------------------------+---------------+ 590 | TBA5 | Flow ID | This document | 591 +-------+----------------------------------+---------------+ 592 | TBA6 | Source and/or Destination Groups | This document | 593 +-------+----------------------------------+---------------+ 594 | TBA7 | Policy Identifier | This document | 595 +-------+----------------------------------+---------------+ 597 Table 1: Type Values 599 7.2. Forwarding Context Types 601 IANA is requested to create a new sub-registry for "Forwarding 602 Context" context types at [IANA-NSH-MD2] as follows: 604 The Registration Policy is IETF Review 606 +=========+=========================================+===============+ 607 | Value | Forwarding Context Header Types | Reference | 608 +=========+=========================================+===============+ 609 | 0x0 | 12-bit VLAN identifier | This document | 610 +---------+-----------------------------------------+---------------+ 611 | 0x1 | 24-bit double tagging identifiers | This document | 612 +---------+-----------------------------------------+---------------+ 613 | 0x2 | 20-bit MPLS VPN label | This document | 614 +---------+-----------------------------------------+---------------+ 615 | 0x3 | 24-bit virtual network identifier | This document | 616 | | (VNI) | | 617 +---------+-----------------------------------------+---------------+ 618 | 0x4 | 32-bit Session ID | This document | 619 +---------+-----------------------------------------+---------------+ 620 | 0x5-0xE | Unassigned | | 621 +---------+-----------------------------------------+---------------+ 622 | 0xF | Reserved | This document | 623 +---------+-----------------------------------------+---------------+ 625 Table 2: Forwarding Context Types 627 7.3. Flow ID Context Types 629 IANA is requested to create a new sub-registry for "Flow ID Context" 630 context types at [IANA-NSH-MD2] as follows: 632 The Registration Policy is IETF Review 634 +=========+==============================+===============+ 635 | Value | Flow ID Context Header Types | Reference | 636 +=========+==============================+===============+ 637 | 0x0 | 20-bit IPv6 Flow Label | This document | 638 +---------+------------------------------+---------------+ 639 | 0x1 | 20-bit entropy label in the | This document | 640 | | MPLS network | | 641 +---------+------------------------------+---------------+ 642 | 0x2-0xE | Unassigned | | 643 +---------+------------------------------+---------------+ 644 | 0xF | Reserved | This document | 645 +---------+------------------------------+---------------+ 647 Table 3: Flow ID Context Types 649 8. References 651 8.1. Normative References 653 [I-D.ietf-sfc-nsh-integrity] 654 Boucadair, M., Reddy, T., and D. Wing, "Integrity 655 Protection for the Network Service Header (NSH) and 656 Encryption of Sensitive Context Headers", Work in 657 Progress, Internet-Draft, draft-ietf-sfc-nsh-integrity-09, 658 20 September 2021, . 661 [IANA-NSH-MD2] 662 IANA, "NSH IETF-Assigned Optional Variable-Length Metadata 663 Types", . 666 [IEEE.802.1Q_2018] 667 IEEE, "IEEE Standard for Local and Metropolitan Area 668 Networks--Bridges and Bridged Networks", July 2018, 669 . 672 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 673 Requirement Levels", BCP 14, RFC 2119, 674 DOI 10.17487/RFC2119, March 1997, 675 . 677 [RFC3931] Lau, J., Ed., Townsley, M., Ed., and I. Goyret, Ed., 678 "Layer Two Tunneling Protocol - Version 3 (L2TPv3)", 679 RFC 3931, DOI 10.17487/RFC3931, March 2005, 680 . 682 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 683 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 684 May 2017, . 686 [RFC8300] Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed., 687 "Network Service Header (NSH)", RFC 8300, 688 DOI 10.17487/RFC8300, January 2018, 689 . 691 [RFC9145] Boucadair, M., Reddy.K, T., and D. Wing, "Integrity 692 Protection for the Network Service Header (NSH) and 693 Encryption of Sensitive Context Headers", RFC 9145, 694 DOI 10.17487/RFC9145, December 2021, 695 . 697 8.2. Informative References 699 [IANAifType] 700 IANA, "IANAifType", 2021, 701 . 704 [OpenDaylight] 705 OpenDaylight, "Group Based Policy", 2021, 706 . 710 [OpenDaylight-VTN] 711 OpenDaylight, "OpenDaylight VTN", 2021, . 716 [OpenStack] 717 OpenStack, "Group Based Policy", 2021, 718 . 720 [RFC2890] Dommety, G., "Key and Sequence Number Extensions to GRE", 721 RFC 2890, DOI 10.17487/RFC2890, September 2000, 722 . 724 [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., 725 Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack 726 Encoding", RFC 3032, DOI 10.17487/RFC3032, January 2001, 727 . 729 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 730 Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 731 2006, . 733 [RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and 734 L. Yong, "The Use of Entropy Labels in MPLS Forwarding", 735 RFC 6790, DOI 10.17487/RFC6790, November 2012, 736 . 738 [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function 739 Chaining (SFC) Architecture", RFC 7665, 740 DOI 10.17487/RFC7665, October 2015, 741 . 743 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 744 (IPv6) Specification", STD 86, RFC 8200, 745 DOI 10.17487/RFC8200, July 2017, 746 . 748 [RFC8926] Gross, J., Ed., Ganga, I., Ed., and T. Sridhar, Ed., 749 "Geneve: Generic Network Virtualization Encapsulation", 750 RFC 8926, DOI 10.17487/RFC8926, November 2020, 751 . 753 [RFC8979] Sarikaya, B., von Hugo, D., and M. Boucadair, "Subscriber 754 and Performance Policy Identifier Context Headers in the 755 Network Service Header (NSH)", RFC 8979, 756 DOI 10.17487/RFC8979, February 2021, 757 . 759 Authors' Addresses 761 Yuehua Wei (editor) 762 ZTE Corporation 763 No.50, Software Avenue 764 Nanjing 765 210012 766 China 767 Email: wei.yuehua@zte.com.cn 768 Uri Elzur 769 Intel 770 Email: uri.elzur@intel.com 772 Sumandra Majee 773 Individual contributor 774 Email: Sum.majee@gmail.com 776 Carlos Pignataro 777 Cisco 778 Email: cpignata@cisco.com 780 Donald E. Eastlake 781 Futurewei Technologies 782 2386 Panoramic Circle 783 Apopka, FL 32703 784 United States of America 785 Email: d3e3e3@gmail.com