idnits 2.17.1 draft-farrel-sfc-convent-06.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 -- Couldn't find a document date in the document -- date freshness check skipped. 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: A later version (-15) exists of draft-ietf-sfc-oam-framework-03 == Outdated reference: A later version (-12) exists of draft-wang-sfc-multi-layer-oam-10 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SFC Working Group A. Farrel 3 Internet-Draft J. Drake 4 Intended status: Standards Track Juniper Networks 5 Expires: August 20, 2018 2 16, 2018 7 Operating the Network Service Header (NSH) with Next Protocol "None" 8 draft-farrel-sfc-convent-06 10 Abstract 12 This document describes the use of the Network Service Header (NSH) 13 in a Service Function Chaining (SFC) enabled network with no payload 14 data and carrying only metadata. This is achieved by defining a new 15 NSH "Next Protocol" type value of "None". 17 This document illustrates some of the functions that may be achieved 18 or enhanced by this mechanism, but it does not provide an exhaustive 19 list of use cases, nor is it intended to be definitive about the 20 functions it describes. It is expected that other documents will 21 describe specific use cases in more detail and will define the 22 protocol mechanics for each use case. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at https://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on August 20, 2018. 41 Copyright Notice 43 Copyright (c) 2018 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (https://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 60 3. The Network Service Header . . . . . . . . . . . . . . . . . 3 61 3.1. Next Protocol 'None' . . . . . . . . . . . . . . . . . . 4 62 4. Processing Rules . . . . . . . . . . . . . . . . . . . . . . 4 63 5. Backward Compatibility . . . . . . . . . . . . . . . . . . . 5 64 6. Overview of Use Cases . . . . . . . . . . . . . . . . . . . . 6 65 6.1. Per-SFP Metadata . . . . . . . . . . . . . . . . . . . . 6 66 6.2. Per-Flow Metadata . . . . . . . . . . . . . . . . . . . . 6 67 6.3. Coordination Between SFC-Aware SFIs . . . . . . . . . . . 6 68 6.4. Operations, Administration, and Maintenance (OAM) . . . . 7 69 6.5. Control Plane and Management Plane Uses . . . . . . . . . 8 70 6.6. Non-Applicable Use Cases . . . . . . . . . . . . . . . . 8 71 7. Management and Congestion Control Considerations . . . . . . 8 72 8. Security Considerations . . . . . . . . . . . . . . . . . . . 10 73 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 74 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 11 75 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 76 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 77 12.1. Normative References . . . . . . . . . . . . . . . . . . 11 78 12.2. Informative References . . . . . . . . . . . . . . . . . 11 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 81 1. Introduction 83 An architecture for Service Function Chaining (SFC) is presented in 84 [RFC7665]. That architecture enables packets to be forwarded along 85 Service Function Paths (SFPs) to pass through various Service 86 Functions (SFs) that act on the packets. Each packet is encapsulated 87 with a Network Service Header (NSH) [RFC8300] that identifies the 88 SFP that the packet travels along (by means of a Service Path 89 Identifier - SPI) and the hop (i.e., the next SF to be executed) 90 along the SFP that the packet has reached (by means of a Service 91 Index - SI). The SPI and SI are fields encoded in the NSH. 93 Packets are classified at the SFC network ingress boundaries by 94 Classifiers (section 4.4 of [RFC7665]) and have an NSH applied to 95 them. Such packets are forwarded between Service Function Forwarders 96 (SFFs) using tunnels across the underlay network, and each SFF may 97 hand the packet off to one or more Service Function Instances (SFIs) 98 according to the definition of the SFP. 100 The SFC Classifier or any SFC-aware SFI may wish to share information 101 (possibly state information) about the SFP, the traffic flow, or a 102 specific packet, and they may do this by adding "metadata" to packets 103 as part of the NSH. Metadata may be used to enhance or enable the 104 function performed by SFC-aware SFs, may enable coordination and data 105 exchange between SFIs, or may be used to assist a network operator in 106 the diagnosis and monitoring of an SFP. The nature of metadata to be 107 supplied and consumed is implementation- and deployment-specific. 109 This document defines a mechanism for metadata to be carried on an 110 SFP without the need for payload data. This mechanism enables 111 diagnosis and monitoring of SFPs, and coordination between SFC-aware 112 SFIs. The mechanism can be applied without the need for traffic to 113 be flowing, and if traffic is flowing it can be applied without the 114 need to insert what might be substantial amounts of metadata into 115 data packets (an operation that may be costly in some hardware). 117 This document describes how this function is achieved through the use 118 of a new value for the NSH "Next Protocol" field to indicate "None". 119 Like any NSH packets, such packets are contained within the SFC- 120 enabled domain. 122 This document illustrates some of the functions that may be achieved 123 or enhanced by this mechanism, but it does not provide an exhaustive 124 list of use cases, nor is it intended to be definitive about the 125 functions it describes (see Section 6). 127 This document uses the terms defined in [RFC7665] and [RFC8300]. 129 2. Requirements Language 131 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 132 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 133 "OPTIONAL" in this document are to be interpreted as described in BCP 134 14 [RFC2119] [RFC8174] when, and only when, they appear in all 135 capitals, as shown here. 137 3. The Network Service Header 139 The NSH includes a field called "Next Protocol" that is used to 140 indicate the nature of the payload data that follows the NSH. The 141 field can be used by any component that processes the NSH (for 142 example, to understand how to interpret and parse the payload) and by 143 nodes at the end of the SFP that remove the NSH and forward the 144 payload data. 146 3.1. Next Protocol 'None' 148 This document defines a new value (TBD1) for the "Next Protocol" 149 field to indicate that the next protocol is "None" meaning that there 150 is no user/payload data following the NSH. 152 When the next protocol is "None" the rest of the NSH still has 153 meaning and, in particular, the metadata carried in the NSH may still 154 be present. It is not intended that a packet with next protocol set 155 to "None" is sent with no metadata (see Section 4). Thus, an SFC- 156 aware node SHOULD NOT create a packet with next protocol set to 157 "None", Metadata Type set to 0x2, and with NSH Length of 0x2. 159 4. Processing Rules 161 A packet with no payload data may be inserted at the head end of an 162 SFP (such as at a Classifier) and may be easily forwarded by an SFF 163 or SFI on the SFP using the processing rules defined in [RFC8300]. 165 A packet with no payload may also be generated by an SFC-aware SFI as 166 a result of processing an incoming packet (i.e., triggered by a 167 condition arising from processing a normal NSH packet with a 168 payload). In such cases, the SPI/SI can be inherited from the 169 original packet or can be set according to information supplied 170 through the control plane, or management plane, or indicated by 171 information carried in the metadata of the data packet. This 172 document does not further specify the triggers to generate an NSH 173 packet with a "Next Protocol" set to "None". 175 An SFC-aware node wishing to send metadata without a data packet 176 (i.e., a node that conforms to this specification): 178 o MUST create a packet carrying an NSH and the desired metadata 180 o MUST set the "Next Protocol" field to TBD1 182 o SHOULD ensure that there are no bytes following the end of the NSH 183 (i.e., that there is no payload data) 185 o MUST encapsulate and send the packet as normal for tunneling to 186 the next hop on the SFP as would be done for any NSH packet (i.e., 187 for a data packet following the SFP). 189 A transit node (SFF, SFI, or Classifier) that conforms to this 190 specification and that receives a packet with "Next Protocol" 191 indicating "None" MUST NOT attempt to parse or process beyond the end 192 of the NSH, but SHOULD process the NSH and the metadata as normal. 193 Processing for nodes that do not support "Next Protocol" set to 194 "None" is described in Section 5. Note, however, that an 195 intermediate node that is instructed to strip all metadata from 196 packets will create a packet with an NSH but no metadata and no 197 payload. Such packets SHOULD NOT continue to be forwarded along the 198 SFP. 200 A node that is the egress of an SFP would normally strip the NSH and 201 forward the payload according to the setting of the "Next Protocol" 202 field. Such nodes MUST NOT forward packets with "Next Protocol" 203 indicating "None" even if there are some bytes after the NSH. 205 In deployments where use of Next-Protocol "None" is not desired, 206 administrators SHOULD instruct SFC-aware nodes to not create such 207 packets and to discard packets with Next-Protocol "None". 209 5. Backward Compatibility 211 SFC-aware nodes that do not understand the meaning of a value 212 contained in the "Next Protocol" field of the NSH are unable to parse 213 the payload. Such nodes silently drop packets with unknown "Next 214 Protocol" values unless explicitly configured to forward them 215 (Section 2.2 of [RFC8300]). 217 This means that legacy SFC-aware nodes that are unaware of the 218 meaning of the "Next Protocol" value "None" will act as follows: 220 o SFFs can be configured to forward the packets 222 o SFC Proxies will drop the packets 224 o SFIs will most likely drop the packets 226 o Classifiers (i.e., nodes performing reclassification) will most 227 likely drop the packets 229 SFC-aware nodes at the end of an SFP possibly forward packets with no 230 knowledge of the payload in a "pop and forward" form of processing 231 where the NSH is removed and the packet is simply put on an interface 232 and the payload protocol is known a priori (or assumed). It is a 233 general processing rule for all packet forwarding engines that they 234 should not attempt to send packets with zero length. Packets with 235 the NSH "Next Protocol" field set to "None" are expected to have zero 236 payload length and so should not be forwarded once the NSH has been 237 stripped. In any case, as noted in Section 4, SFC-aware nodes at the 238 end of an SFP do not forward packets with "Next Protocol" set to 239 "None". 241 6. Overview of Use Cases 243 6.1. Per-SFP Metadata 245 Per-SFP metadata is metadata that applies to an SFP and any data 246 packets on that SFP. It does not need to be transmitted with every 247 packet, but can be installed at the points of consumption SFP (such 248 as at SFIs) and applied to all packets on the SFP as they pass 249 through this point. It could be installed by inclusion in the NSH of 250 a data packet sent on the SFP, by out of band control or management 251 plane mechanisms, or by separate metadata-only packets using "Next 252 Protocol" set to "None" as described in this document. 254 Per-SFP metadata-only packets may be sent along the path of an SFP 255 simply by setting the correct SPI in the NSH, and setting the SI to 256 the correct value for the hop of the SFP at which the metadata is to 257 be introduced. SFC-aware nodes (e.g., Classifiers) will know the 258 correct SI values to be used from information supplied by the control 259 or management plane as is the case for NSH packets with payload data. 261 6.2. Per-Flow Metadata 263 Per-flow metadata is metadata that applies to a subset of the packets 264 on an SFP, such as packets matching a particular 5 tuple of source 265 address, destination address, source port, destination port, and 266 payload protocol. This metadata also does not need to be transmitted 267 with every packet, but can be installed at the SFIs on the SFP and 268 applied to the packets that match the flow description. 270 If there is just one flow on an SFP then there is no difference 271 between per-flow metadata and per-SFP metadata as described in 272 Section 6.1. 274 In normal processing, the flow to which per-flow metadata applies can 275 be deduced by looking at the payload data in the context of the value 276 of the "Next Protocol" field. However, when "Next Protocol" 277 indicates "None" this cannot be done. In this case the identity of 278 the flow is carried in the metadata itself. 280 6.3. Coordination Between SFC-Aware SFIs 282 A pair of SFC-aware SFIs (adjacent or not) on an SFP may desire to 283 coordinate state and may do this by sending information encoded in 284 metadata. 286 To do this using the mechanisms defined in this document: 288 o There must be an SFP that passes through the two SFIs in the 289 direction of sender to receiver. 291 o The sender must know the correct SPI to use. 293 o The sender must know the correct SI to use for the point at which 294 it resides on the SFP. 296 o Ideally the receiver will know to remove the packet from the SFP 297 and not forward it further as this might share metadata wider than 298 desirable and would cause unnecessary packets in the network. 299 Note, however, that continued forwarding of such packets would not 300 be substantially harmful in its own right. 302 Note that technically (according to the SFC architecture) the process 303 of inserting a packet into an SFP is performed by a Classifier. 304 However, a Classifier may be co-resident with an SFI so an 305 implementation of an SF may also be able to generate NSH packets as 306 described in this document. 308 Note also that a system with SFIs that need to coordinate between 309 each other may be configured so that there is a specific, dedicated 310 SFP between those service functions that is used solely for this 311 purpose. Thus, such an SFI does not need to insert NSH packets onto 312 SFPs used to carry payload data, but can use (and know the SPI of) 313 this special, dedicated SFP. 315 6.4. Operations, Administration, and Maintenance (OAM) 317 Requirements for Operations, Administration, and Maintenance (OAM) in 318 SFC networks are discussed in [I-D.ietf-sfc-oam-framework]. The NSH 319 definition in [RFC8300] includes an O-bit that indicates that packet 320 contains OAM information. 322 If OAM information is carried in packets that also include payload 323 data, that information might be carried between the NSH and the 324 payload. Therefore, the mechanism defined in this document can also 325 be used to carry OAM information independent of payload data. 327 Sending OAM separate from (but interleaved with) packets that carry 328 payload data may have several advantages including: 330 o Sending OAM when there is no other traffic flowing. 332 o Sending OAM at predictable intervals. 334 o Measuring path qualities distinct from behavior of SFIs. 336 o Sending OAM without needing to rewrite payload data buffers. 338 o Keeping OAM processing components separate from other processing 339 components. 341 Mechanisms for providing active OAM ([RFC7799]) in an SFC network 342 have been proposed [I-D.wang-sfc-multi-layer-oam]. This use case is 343 not intended to define another mechanism for active OAM, but does 344 illustrate a further option for discussion by the working group. 346 6.5. Control Plane and Management Plane Uses 348 As described in Section 6.3, SFPs can be established specifically to 349 carry metadata-only packets. And as described in Section 6.1, 350 metadata-only packets can be sent down existing SFPs. This means 351 that metadata-only packets can be used to carry control plane and 352 management plane messages used to control and manage the SFC network. 354 In effect, SFPs can be established to serve as a Data Control Network 355 (DCN) or Management Control Network (MCN). Further details of this 356 process are out of scope of this document, but it should be 357 understood that, just as for OAM, an essential feature of using a 358 control channel is that the various speakers are assigned identifiers 359 (i.e., addresses). In this case, those identifiers could be SPI/SI 360 pairs, or could be IP addresses as used in the normal control and 361 management plane of the SFC network. 363 6.6. Non-Applicable Use Cases 365 Per-packet metadata is metadata that applies specifically to a single 366 payload packet. It informs an SFI how to handle the payload packet, 367 and does not apply to any other packet. 369 The mechanisms described in this document are not applicable to per- 370 packet metadata because, by definition, if the "Next Protocol" 371 indicates "None" then there is no packet following the NSH for the 372 metadata to be associated with. 374 7. Management and Congestion Control Considerations 376 The mechanisms described in this document allow SFC-aware nodes in an 377 SFC network to generate additional packets. These are not intended 378 to be sent frequently for any flow, but there is still a risk that 379 they might flood the network. For example, if an attempt is made to 380 use this mechanism for "per-packet metadata" Section 6.6 then this 381 might double the number of packets in the network. Similarly, if 382 this mechanism is used for a form of aliveness detection OAM that 383 requires very frequent test messages, then the number of additional 384 messages may be very high. Such additional messages risk causing 385 congestion in the network. 387 The underlay network (that is the tunnels across the underlay between 388 SFC nodes) will not distinguish between data-carrying packets and 389 those packets with "Next Protocol" set to "None". All packets will 390 be treated the same and will need to fall within the capabilities of 391 the underlay network to process and forward packets. 393 Nodes in the SFC overlay network will need to perform special 394 processing on the additional packets according to their roles and 395 according to the application for the metadata. For example, an SFF 396 will likely only have to forward per-SFP metadata, while an SF will 397 need to extract it and process it as it would if the metadata was 398 carried in a packet with user data. On the other hand, metadata 399 might also be used to cause actions at all nodes (see Section 6.3, 400 Section 6.4, and Section 6.5) and could increase the processing load. 402 In view of these potential issues, all implementations SHOULD 403 implement rate limits on the generation of per-SFP packets with "Next 404 Protocol" set to "None". Furthermore, these rate limits SHOULD be 405 configurable and applied per SFP and per application so that one 406 application on one SFP does not encumber a different application on 407 this or a different SFP. When an implementation finds that it is 408 unable to generate or send a packet it SHOULD increment a counter 409 that is accessible by the operator, and MAY raise an alert (although 410 such alerts SHOULD, themselves, be rate limited). 412 Additionally, an SFC node needs to protect itself against another 413 node in the network not applying suitable rate limits. Therefore, 414 implementations SHOULD apply incoming rate limits for SFC packets 415 with "Next Protocol" set to "None". Such rate limits MAY be 416 application-aware, per SFC or interface, and SHOULD be configurable, 417 but implementations MAY be more subtle if they are aware of internal 418 processing loads and have access to queues/buffers. In any case, 419 when an implementation drops a received packed because of these rate 420 limits it SHOULD increment a counter that is accessible by the 421 operator, and MAY raise an alert (although such alerts SHOULD, 422 themselves, be rate limited). 424 Suitable default rate limits are to not send more than one packet 425 with "Next Protocol" set to "None" per ten data packets on any flow 426 in a unit of time equal to the end to end delivery time on the flow. 428 8. Security Considerations 430 Metadata-only packets as enabled by this document provide a covert 431 channel. However, this is only different from the metadata feature 432 in the normal NSH in that it can be sent without the presence of a 433 data flow. 435 Metadata may, of course, contain sensitive data and may also contain 436 information used to control the behavior of SFIs in the network. As 437 such, this data needs to be protected according to its value and 438 according to the perceived vulnerabilities of the network. 439 Protection of metadata may be achieved by using encrypted transport 440 between SFC entities or by encrypting the metadata in its own right, 441 and by authenticating the sender of the metadata. The need to 442 protect the metadata is not modified by this document and forms part 443 of the NSH definition found in [RFC8300]. 445 The mechanism described in this document might be used to introduce 446 packets into the SFC overlay network and might be used to 447 illegitimately introduce false metadata to the nodes on an SFC. 448 Therefore, measures SHOULD be taken to ensure authorization of 449 sources of such packets, and tunneling of such packets into the 450 network SHOULD be prevented. 452 The amount of packets with "Next Protocol" set to "None" on an SFP 453 SHOULD be rate limited at each point on the SFP to provide additional 454 network security. 456 Further discussion of NSH security is presented in [RFC8300]. 458 9. IANA Considerations 460 IANA maintains a registry called "Network Service Header (NSH) 461 Parameters" with a sub-registry called "NSH Next Protocol". This 462 document requests IANA to allocate a new value as follows: 464 Next Protocol | Description | Reference 465 ---------------+---------------+------------- 466 TBD1 | None | [This.I-D] 468 It is strongly suggested that a value of 0 (zero) be assigned. 470 10. Contributors 472 Lucy Yong 473 Retired 475 11. Acknowledgements 477 Thanks to the attendees at the SFC interim meeting in Westford in 478 January 2017 for discussions that suggested the value of this 479 document. 481 Thanks to Eric Rosen, Med Boucadair, Greg Mirsky, Dave Dolson, Tal 482 Mizrahi, and Mirja Kuehlewind for valuable review comments. 484 12. References 486 12.1. Normative References 488 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 489 Requirement Levels", BCP 14, RFC 2119, 490 DOI 10.17487/RFC2119, March 1997, 491 . 493 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 494 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 495 May 2017, . 497 [RFC8300] Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed., 498 "Network Service Header (NSH)", RFC 8300, 499 DOI 10.17487/RFC8300, January 2018, 500 . 502 12.2. Informative References 504 [I-D.ietf-sfc-oam-framework] 505 Aldrin, S., Pignataro, C., Kumar, N., Akiya, N., Krishnan, 506 R., and A. Ghanwani, "Service Function Chaining (SFC) 507 Operation, Administration and Maintenance (OAM) 508 Framework", draft-ietf-sfc-oam-framework-03 (work in 509 progress), September 2017. 511 [I-D.wang-sfc-multi-layer-oam] 512 Mirsky, G., Meng, W., Khasnabish, B., and C. Wang, "Multi- 513 Layer Active OAM for Service Function Chains in Networks", 514 draft-wang-sfc-multi-layer-oam-10 (work in progress), 515 September 2017. 517 [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function 518 Chaining (SFC) Architecture", RFC 7665, 519 DOI 10.17487/RFC7665, October 2015, 520 . 522 [RFC7799] Morton, A., "Active and Passive Metrics and Methods (with 523 Hybrid Types In-Between)", RFC 7799, DOI 10.17487/RFC7799, 524 May 2016, . 526 Authors' Addresses 528 Adrian Farrel 529 Juniper Networks 531 Email: afarrel@juniper.net 533 John Drake 534 Juniper Networks 536 Email: jdrake@juniper.net