idnits 2.17.1 draft-farrel-sfc-convent-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 (June 29, 2017) is 2493 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: A later version (-28) exists of draft-ietf-sfc-nsh-12 == Outdated reference: A later version (-15) exists of draft-ietf-sfc-oam-framework-01 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: December 31, 2017 June 29, 2017 7 Operating the Network Service Header (NSH) with Next Protocol "None" 8 draft-farrel-sfc-convent-02 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 Requirements Language 26 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 27 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 28 document are to be interpreted as described in [RFC2119]. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at http://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on December 31, 2017. 47 Copyright Notice 49 Copyright (c) 2017 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 65 2. The Network Service Header . . . . . . . . . . . . . . . . . 3 66 2.1. Next Protocol 'None' . . . . . . . . . . . . . . . . . . 4 67 3. Processing Rules . . . . . . . . . . . . . . . . . . . . . . 4 68 4. Backward Compatibility . . . . . . . . . . . . . . . . . . . 5 69 5. Overview of Use Cases . . . . . . . . . . . . . . . . . . . . 6 70 5.1. Per-SFP Metadata . . . . . . . . . . . . . . . . . . . . 6 71 5.2. Per-Flow Metadata . . . . . . . . . . . . . . . . . . . . 6 72 5.3. Coordination Between SFC-Aware SFIs . . . . . . . . . . . 6 73 5.4. Operations, Administration, and Maintenance (OAM) . . . . 7 74 5.5. Control Plane and Management Plane Uses . . . . . . . . . 8 75 5.6. Non-Applicable Use Cases . . . . . . . . . . . . . . . . 8 76 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 77 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 78 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 9 79 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 80 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 81 10.1. Normative References . . . . . . . . . . . . . . . . . . 9 82 10.2. Informative References . . . . . . . . . . . . . . . . . 10 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 85 1. Introduction 87 An architecture for Service Function Chaining (SFC) is presented in 88 [RFC7665]. That architecture enables packets to be forwarded along 89 Service Function Paths (SFPs) to pass through various Service 90 Functions (SFs) that act on the packets. Each packet is encapsulated 91 with a Network Service Header (NSH) [I-D.ietf-sfc-nsh] identify the 92 SFP that the packet travels along (by means of a Service Path 93 Identifier - SPI) and the hop (i.e., the next SF to be executed) 94 along the SFP that the packet has reached (by means of a Service 95 Index - SI). The SPI and SI are fields encoded in the NSH. 97 Packets are classified at the SFC ingress boundaries (section 4.4 of 98 [RFC7665]) and have an NSH applied to them. Such packets are 99 forwarded between Service Function Forwarders (SFFs) using tunnels 100 across the underlay network, and each SFF may hand the packet off to 101 one or more Service Function Instances (SFIs) according to the 102 definition of the SFP. 104 The SFC classifier or any SFC-aware SFI may wish to share information 105 (possibly state information) about the SFP, the traffic flow, or a 106 specific packet, and they may do this by adding "metadata" to packets 107 as part of the NSH. Metadata may be used to enhance or enable the 108 function preformed by SFC-aware SFs, may enable coordination and data 109 exchange between SFIs, or may be used to assist a network operator in 110 the diagnosis and monitoring of an SFP. The nature of metadata to be 111 supplied and consumed is implementation- and deployment-specific. 113 This document defines a mechanism for metadata to be carried on an 114 SFP without the need for payload data. This may enable diagnosis and 115 monitoring of SFPs, and coordination between SFC-aware SFIs, without 116 the need for traffic to be flowing, and without the need to rewrite 117 data packets to insert what might be substantial amounts of metadata. 119 This function is achieved by defining a new value for the NSH "Next 120 Protocol" field to indicate "None". Such packets are contained 121 within the SFC-enabled domain. 123 This document illustrates some of the functions that may be achieved 124 or enhanced by this mechanism, but it does not provide an exhaustive 125 list of use cases, nor is it intended to be definitive about the 126 functions it describes. It is expected that other documents will 127 describe specific use cases in more detail and will define the 128 protocol mechanics for each use case. 130 2. The Network Service Header 132 The NSH is defined in [I-D.ietf-sfc-nsh]. It includes a field called 133 "Next Protocol" that is used to indicate the nature of the payload 134 data that follows the NSH. The field can be used by any component 135 that processes the NSH (for example, to understand how to interpret 136 and parse the payload) and by nodes at the end of the SFP that remove 137 the NSH and forward the payload data. 139 2.1. Next Protocol 'None' 141 This document defines a new value for the "Next Protocol" field. 142 When set to TBD1, the field indicates that the next protocol is 143 "None" meaning that there is no user/payload data following the NSH. 145 When the next protocol is "None" the rest of the NSH still has 146 meaning and, in particular, the metadata carried in the NSH may still 147 be present. 149 3. Processing Rules 151 An SFC-aware node wishing to send metadata without a data packet: 153 o MUST create a packet carrying an NSH and the desired metadata 155 o MUST set the "Next Protocol" field to TBD1 157 o SHOULD ensure that there are no bytes following the end of the NSH 158 (i.e., that there is no payload data) 160 o MUST encapsulate and send the packet as normal for tunneling to 161 the next hop on the SFP as normal for an NSH packet. 163 A packet with no payload data may be simply inserted at the head end 164 of an SFP (such as a Classifier) and may be easily forwarded by an 165 SFF or SFI on the SFP using the normal processing rules defined in 166 [I-D.ietf-sfc-nsh]. 168 A packet with no payload may also be generated by an SFC-aware SFI as 169 a result of processing an incoming packet (i.e., triggered by a 170 condition arising from processing a normal NSH packet with a 171 payload). In such cases, the SPI/SI can be inherited from the 172 original packet or can be set according to information supplied 173 through the control plane or management plane. This document does 174 not further specify the triggers to generate an NSH packet with a 175 "Next Protocol" set to "None". 177 A transit node (SFF, SFI, or classifier) receiving a packet with 178 "Next Protocol" indicating "None" MUST NOT attempt to parse or 179 process beyond the end of the NSH, but can process the NSH and 180 especially the metadata as normal. 182 A node that is the egress of an SFP would normally strip the NSH and 183 forward the payload according to the setting of the "Next Protocol" 184 field. Such nodes MUST NOT forward packets with "Next Protocol" 185 indicating "None" even if there some bytes after the NSH. 187 4. Backward Compatibility 189 This section describes procedures for default handling on unknown 190 "Next Protocol" field values. This material updates the procedures 191 described in [I-D.ietf-sfc-nsh] and may be transferred to that 192 document. 194 SFC-aware nodes that do not understand the meaning of a value 195 contained in the "Next Protocol" field of the NSH are unable to parse 196 the payload. Such nodes are not obliged to discard the packet unless 197 they are specifically called upon to be able to examine the payload. 199 Thus: 201 o Transit SFFs will normally not inspect the "Next Protocol" field 202 or the packet payload and will forward the packets based solely on 203 the SPI/SI 205 o An SFC Proxy must not pass to an SFI a packet of type where it 206 cannot indicate the packet type to the SFI 208 o An SFC Proxy must not pass to an SFI a packet of type that the SFI 209 does not support 211 o An SFC Proxy should not return to the SFF a packet it has not 212 passed to the SFI 214 o An SFI should not return to the SFF a packet it hasn't processed 215 unless local policy defines "process" for this SF to mean "do not 216 process" in this case. 218 o Reclassifiers would normally require to understand the payload 219 packet type, but it is possible to imagine reclassifiers that take 220 action based on unknown values of the "Next Protocol" field or 221 that perform protocol-independent actions (such as hashing the 222 whole packet). 224 All this means that legacy SFC-aware nodes that are unaware of the 225 meaning of the "Next Protocol" value "None" will act as follows: 227 o SFFs will forward the packets 229 o SFC Proxies will drop the packets 231 o SFIs will most likely drop the packets 233 o Reclassifiers will most likely drop the packets 234 SFC-aware nodes at the end of an SFP possibly forward packets with no 235 knowledge of the payload in a "pop and forward" form of processing 236 where the NSH is removed and the packet is simply put on an interface 237 and the payload protocol is known a priori (or assumed). It is a 238 general processing rule for all forwarders that they SHOULD NOT 239 attempt to send packets with zero length, and since packets with the 240 NSH "Next Protocol" set "None" are expected to have zero payload 241 length. 243 5. Overview of Use Cases 245 5.1. Per-SFP Metadata 247 Per-SFP metadata is metadata that applies to an SFP and any data 248 packets on that SFP. It does not need to be transmitted with every 249 packet, but can be installed at the SFIs on the SFP and applied to 250 all packets on the SFP. 252 Per-SFP metadata may be sent along the path of an SFP simply by 253 setting the correct SPI in the NSH, and setting the SI to the correct 254 value for the hop of the SFP at which the metadata is to be 255 introduced. Classifiers and reclassifiers will know the correct SI 256 values to used from information supplied by the control or management 257 plane as is the case for NSH packets with payload data. 259 5.2. Per-Flow Metadata 261 Per-flow metadata is metadata that applies to a subset of the packets 262 on an SFP, such as packets matching a particular 5 tuple of source 263 address, destination address, source port, destination port, and 264 payload protocol. This metadata also does not need to be transmitted 265 with every packet, but can be installed at the SFIs on the SFP and 266 applied to the packets that match the flow description. 268 If there is just one flow on an SFP then there is no difference 269 between per-flow metadata and per-SFP metadata as described in . 271 In normal processing, the flow to which per-flow metadata applies can 272 be deduced by looking at the payload data in the context of the value 273 of the "Next Protocol" field. However, when "Next Protocol" 274 indicates "None" this cannot be done. In this case the identity of 275 the flow is carried in the metadata. 277 5.3. Coordination Between SFC-Aware SFIs 279 A pair of SFC-aware SFIs (adjacent or not) on an SFP may desire to 280 coordinate state and may do this by sending information encoded in 281 metadata. 283 To do this using the mechanisms defined in this document: 285 o There must be an SFP that passes through the two SFIs in the 286 direction of sender to receiver 288 o The sender must know the correct SPI to use 290 o The sender must know the correct SI to use for the point at which 291 it resides on the SFP 293 o Ideally the receiver will know to remove the packet from the SFP 294 and not forward it further as this might share metadata wider than 295 desirable and would cause unnecessary packets in the network. 296 Note, however, that continued forwarding of such packets would not 297 be substantially harmful in its own right. 299 Note that technically (according to the SFC architecture) the process 300 of inserting a packet into an SFP is performed by a Classifier. 301 However, a Classifier may be co-resident with an SFI so an 302 implementation of an SF may also be able to generate NSH packets as 303 described in this document. 305 Note also that a system with SFIs that need to coordinate between 306 each other may be configured so that there is a specific, dedicated 307 SFP between those service functions that is used solely for this 308 purpose. Thus, such an SFI does not need to insert NSH packets onto 309 SFPs used to carry payload data, but can use (and know the SPI of) 310 this special, dedicated SFP. 312 5.4. Operations, Administration, and Maintenance (OAM) 314 Requirements for Operations, Administration, and Maintenance (OAM) in 315 SFC networks are discussed in [I-D.ietf-sfc-oam-framework]. The NSH 316 definition in [I-D.ietf-sfc-nsh] includes an O-bit that indicates 317 that packet contains OAM information. 319 Since OAM information will be carried in packets that also include 320 payload data, that information must be carried in metadata. 321 Therefore, the mechanism defined in this document can be used to 322 carry OAM information independent of payload data. 324 Sending OAM separate from (but interleaved with) packets that carry 325 payload data may have several advantages including: 327 o Sending OAM when there is no other traffic flowing. 329 o Sending OAM at predictable intervals. 331 o Measuring path qualities distinct from behavior of SFIs. 333 o Sending OAM without needing to rewrite payload data buffers. 335 o Keeping OAM processing components separate from other processing 336 components. 338 5.5. Control Plane and Management Plane Uses 340 As described in Section 5.3, SFPs can be established specifically to 341 carry metadata-only packets. And as described in Section 5.1, 342 metadata-only packets can be sent down existing SFPs. This means 343 that metadata-only packets can be used to carry control plane and 344 management plane messages used to control and manage the SFC network. 346 In effect, SFPs can be established to serve as a Data Control Network 347 (DCN) or Management Control Network (MCN). Further details of this 348 process are out of scope of this document, but it should be 349 understood that, just as for OAM, an essential feature of using a 350 control channel is that the various speakers are assigned identifiers 351 (i.e., addresses). In this case, those identifiers could be SPI/SI 352 pairs, or could be IP addresses as used in the normal control and 353 management plane of the SFC network. 355 5.6. Non-Applicable Use Cases 357 Per-packt metadata is metadata that applies specifically to a payload 358 packet. It informs an SFI how to handle the payload packet, and does 359 not apply to any other packets. 361 The mechanisms described in this document are not applicable to per- 362 packet metadata because, by definition, if the "Next Protocol" 363 indicates "None" then there is no packet following the NSH for the 364 metadata to be associated with. 366 6. Security Considerations 368 Metadata-only packets as enabled by this document provide a covert 369 channel. However, this is only different from the metadata feature 370 in the normal NSH in that it can be sent without the presence of a 371 data flow. 373 Metadata may, of course, contain sensitive data and may also contain 374 information used to control the behavior of SFIs in the network. As 375 such, this data needs to be protected according to its value and 376 according to the perceived vulnerabilities of the network. 377 Protection of metadata may be achieved by using encrypted transport 378 between SFC entities or by encrypting the metadata in its own right. 380 The need to protect the metadata is not modified by this document and 381 forms part of the NSH definition found in [I-D.ietf-sfc-nsh]. 383 The mechanism described in this document might possibly be used to 384 introduce packets into the SFC overlay network. Therefore measures 385 SHOULD be taken to ensure authorization of sources of such packets, 386 and tunneling of such packets into the network SHOULD be prevented. 387 The amount of packets with "Next Protocol" set to "None" on an SFP 388 MAY be rate limited at any point on the SFP to provide additional 389 security. 391 Further discussion of NSH security is presented in 392 [I-D.ietf-sfc-nsh]. 394 7. IANA Considerations 396 IANA has been requested to create a registry of "Next Protocol" 397 values in [I-D.ietf-sfc-nsh]. This document requests IANA to 398 allocate a value from that registry to indicate "None" (TBD1 in this 399 document). 401 It is strongly suggested that a value of 0 (zero) be assigned. 403 8. Contributors 405 Lucy Yong 406 Retired 408 9. Acknowledgements 410 Thanks to the attendees at the SFC interim meeting in Westford in 411 January 2017 for discussions that suggested the value of this 412 document. 414 Thanks to Eric Rosen and Med Boucadair for valuable review comments. 416 10. References 418 10.1. Normative References 420 [I-D.ietf-sfc-nsh] 421 Quinn, P. and U. Elzur, "Network Service Header", draft- 422 ietf-sfc-nsh-12 (work in progress), February 2017. 424 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 425 Requirement Levels", BCP 14, RFC 2119, 426 DOI 10.17487/RFC2119, March 1997, 427 . 429 10.2. Informative References 431 [I-D.ietf-sfc-oam-framework] 432 Aldrin, S., Krishnan, R., Akiya, N., Pignataro, C., and A. 433 Ghanwani, "Service Function Chaining Operation, 434 Administration and Maintenance Framework", draft-ietf-sfc- 435 oam-framework-01 (work in progress), February 2016. 437 [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function 438 Chaining (SFC) Architecture", RFC 7665, 439 DOI 10.17487/RFC7665, October 2015, 440 . 442 Authors' Addresses 444 Adrian Farrel 445 Juniper Networks 447 Email: afarrel@juniper.net 449 John Drake 450 Juniper Networks 452 Email: jdrake@juniper.net