idnits 2.17.1 draft-ietf-ippm-ioam-flags-04.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 (February 17, 2021) is 1158 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 (-17) exists of draft-ietf-ippm-ioam-data-11 == Outdated reference: A later version (-12) exists of draft-ietf-ippm-ioam-ipv6-options-04 == Outdated reference: A later version (-13) exists of draft-ietf-sfc-ioam-nsh-05 == Outdated reference: A later version (-07) exists of draft-spiegel-ippm-ioam-rawexport-04 Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPPM T. Mizrahi 3 Internet-Draft Huawei 4 Intended status: Standards Track F. Brockners 5 Expires: August 21, 2021 Cisco 6 S. Bhandari, Ed. 7 Thoughtspot 8 R. Sivakolundu 9 C. Pignataro 10 Cisco 11 A. Kfir 12 B. Gafni 13 Nvidia 14 M. Spiegel 15 Barefoot Networks 16 J. Lemon 17 Broadcom 18 February 17, 2021 20 In-situ OAM Flags 21 draft-ietf-ippm-ioam-flags-04 23 Abstract 25 In-situ Operations, Administration, and Maintenance (IOAM) records 26 operational and telemetry information in the packet while the packet 27 traverses a path between two points in the network. This document 28 presents new flags in the IOAM Trace Option headers. Specifically, 29 the document defines the Loopback and Active flags. 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at https://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on August 21, 2021. 48 Copyright Notice 50 Copyright (c) 2021 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (https://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 66 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 67 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 68 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 69 3. New IOAM Trace Option Flags . . . . . . . . . . . . . . . . . 3 70 4. Loopback in IOAM . . . . . . . . . . . . . . . . . . . . . . 3 71 5. Active Measurement with IOAM . . . . . . . . . . . . . . . . 5 72 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 73 7. Performance Considerations . . . . . . . . . . . . . . . . . 7 74 8. Security Considerations . . . . . . . . . . . . . . . . . . . 7 75 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 76 9.1. Normative References . . . . . . . . . . . . . . . . . . 9 77 9.2. Informative References . . . . . . . . . . . . . . . . . 9 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 80 1. Introduction 82 IOAM [I-D.ietf-ippm-ioam-data] is used for monitoring traffic in the 83 network by incorporating IOAM data fields into in-flight data 84 packets. 86 IOAM data may be represented in one of four possible IOAM options: 87 Pre-allocated Trace Option, Incremental Trace Option, Proof of 88 Transit (POT) Option, and Edge-to-Edge Option. This document defines 89 two new flags in the Pre-allocated and Incremental Trace options: the 90 Loopback and Active flags. 92 2. Conventions 94 2.1. Requirements Language 96 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 97 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 98 "OPTIONAL" in this document are to be interpreted as described in BCP 99 14 [RFC2119] [RFC8174] when, and only when, they appear in all 100 capitals, as shown here. 102 2.2. Terminology 104 Abbreviations used in this document: 106 IOAM: In-situ Operations, Administration, and Maintenance 108 OAM: Operations, Administration, and Maintenance 110 3. New IOAM Trace Option Flags 112 This document defines two new flags in the Pre-allocated and 113 Incremental Trace options: 115 Bit 1 "Loopback" (L-bit). Loopback mode is used to send a copy of a 116 packet back towards the source, as further described in Section 4. 118 Bit 2 "Active" (A-bit). When set, this indicates that this is an 119 active IOAM packet, where "active" is used in the sense defined in 120 [RFC7799], rather than a data packet. The packet may be an IOAM 121 probe packet, or a replicated data packet (the second and third 122 use cases of Section 5). 124 4. Loopback in IOAM 126 Loopback is used for triggering each transit device along the path to 127 loop back a copy of the data packet. Loopback allows an IOAM 128 encapsulating node to trace the path to a given destination, and to 129 receive per-hop data about both the forward and the return path. 130 Loopback is intended to provide an accelerated alternative to 131 Traceroute, that allows the encapsulating node to receive responses 132 from multiple transit nodes along the path in less then one round- 133 trip-time, and by sending a single packet. 135 Loopback can be used only if a return path from transit nodes and 136 destination nodes towards the source (encapsulating node) exists. 137 Specifically, loopback is only applicable in encapsulations in which 138 the identity of the encapsulating node is available in the 139 encapsulation header. If an encapsulating node receives a looped 140 back packet that was not originated from the current encapsulating 141 node, the packet is dropped. 143 The encapsulating node either generates synthetic packets with an 144 IOAM trace option that has the loopback flag set, or sets the loopack 145 flag in a subset of the in-transit data packets. Loopback is used 146 either proactively or on-demand, i.e., when a failure is detected. 147 The encapsulating node also needs to ensure that sufficient space is 148 available in the IOAM header for loopback operation, which includes 149 transit nodes adding trace data on the original path and then again 150 on the return path. 152 An IOAM trace option that has the loopback bit set MUST have the 153 value '1' in the most significant bit of IOAM-Trace-Type, and '0' in 154 the rest of the bits of IOAM-Trace-Type. Thus, every transit node 155 that processes this trace option only adds a single data field, which 156 is the Hop_Lim and node_id data field. The reason for allowing a 157 single data field per hop is to minimize the impact of amplification 158 attacks. 160 A loopback bit that is set indicates to the transit nodes processing 161 this option that they are to create a copy of the received packet and 162 send the copy back to the source of the packet. In this context the 163 source is the IOAM encapsulating node, and it is assumed that the 164 source address is available in the encapsulation header. Thus, the 165 source address of the original packet is used as the destination 166 address in the copied packet. The address of the node performing the 167 copy operation is used as the source address. The IOAM transit node 168 pushes the required data field *after* creating the copy of the 169 packet, in order to allow any egress-dependent information to be set 170 based on the egress of the copy rather than the original packet. The 171 copy is also truncated, i.e., any payload that resides after the IOAM 172 option(s) is removed before transmitting the looped back packet back 173 towards the encapsulating node. The original packet continues 174 towards its destination. The L-bit MUST be cleared in the copy of 175 the packet that a node sends back towards the source. 177 On its way back towards the source, the copied packet is processed 178 like any other packet with IOAM information, including adding any 179 requested data at each transit node (assuming there is sufficient 180 space). 182 Once the return packet reaches the IOAM domain boundary, IOAM 183 decapsulation occurs as with any other packet containing IOAM 184 information. Note that the looped back packet does not have the 185 L-bit set. The IOAM encapsulating node that initiated the original 186 loopback packet recognizes a received packet as an IOAM looped-back 187 packet by checking the Node ID in the Hop_Lim/node_id field that 188 corresponds to the first hop. If the Node ID matches the current 189 IOAM node, it indicates that this is a looped back packet that was 190 initiated by the current IOAM node, and processed accordingly. If 191 there is no match in the Node ID, the packet is processed like a 192 conventional IOAM-encapsulated packet. 194 Note that an IOAM encapsulating node may either be an endpoint (such 195 as an IPv6 host), or a switch/router that pushes a tunnel 196 encapsulation onto data packets. In both cases, the functionality 197 that was described above avoids IOAM data leaks from the IOAM domain. 198 Specificallly, if an IOAM looped-back packet reaches an IOAM boundary 199 node that is not the IOAM node that initiated the loopback, the node 200 does not process the packet as a loopback; the IOAM encapsulation is 201 removed, and since the packet does not have any payload it is 202 terminated. In either case, when the packet reaches the IOAM 203 boundary its IOAM encapsulation is removed, preventing IOAM 204 information from leaking out from the IOAM domain. 206 5. Active Measurement with IOAM 208 Active measurement methods [RFC7799] make use of synthetically 209 generated packets in order to facilitate the measurement. This 210 section presents use cases of active measurement using the IOAM 211 Active flag. 213 The active flag indicates that a packet is used for active 214 measurement. An IOAM decapsulating node that receives a packet with 215 the Active flag set in one of its Trace options must terminate the 216 packet. The active flag is intended to simplify the implementation 217 of decapsulating nodes by indicating that the packet should not be 218 forwarded further. It is not intended as a replacement for existing 219 active OAM protocols, which may run in higher layers and make use of 220 the active flag. 222 An example of an IOAM deployment scenario is illustrated in Figure 1. 223 The figure depicts two endpoints, a source and a destination. The 224 data traffic from the source to the destination is forwarded through 225 a set of network devices, including an IOAM encapsulating node, which 226 incorporates one or more IOAM options, a decapsulating node, which 227 removes the IOAM options, optionally one or more transit nodes. The 228 IOAM options are encapsulated in one of the IOAM encapsulation types, 229 e.g., [I-D.ietf-sfc-ioam-nsh], or [I-D.ietf-ippm-ioam-ipv6-options]. 231 +--------+ +--------+ +--------+ +--------+ +--------+ 232 | | | IOAM |.....| IOAM |.....| IOAM | | | 233 +--------+ +--------+ +--------+ +--------+ +--------+ 234 | L2/L3 |<===>| L2/L3 |<===>| L2/L3 |<===>| L2/L3 |<===>| L2/L3 | 235 +--------+ +--------+ +--------+ +--------+ +--------+ 236 Source Encapsulating Transit Decapsulating Destination 237 Node Node Node 239 <------------ IOAM domain -----------> 241 Figure 1: Network using IOAM. 243 This draft focuses on three possible use cases of active measurement 244 using IOAM. These use cases are described using the example of 245 Figure 1. 247 o Endpoint active measurement: synthetic probe packets are sent 248 between the source and destination, traversing the IOAM domain. 249 Since the probe packets are sent between the endpoints, these 250 packets are treated as data packets by the IOAM domain, and do not 251 require special treatment at the IOAM layer. Specifically, the 252 active flag is not used in this case, and the IOAM layer needs not 253 be aware that an active measurement mechanism is used at a higher 254 layer. 256 o IOAM active measurement using probe packets within the IOAM 257 domain: probe packets are generated and transmitted by the IOAM 258 encapsulating node, and are expected to be terminated by the 259 decapsulating node. IOAM data related to probe packets may be 260 exported by one or more nodes along its path, by an exporting 261 protocol that is outside the scope of this document (e.g., 262 [I-D.spiegel-ippm-ioam-rawexport]). Probe packets include a Trace 263 Option which has its Active flag set, indicating that the 264 decapsulating node must terminate them. 266 o IOAM active measurement using replicated data packets: probe 267 packets are created by the encapsulating node by selecting some or 268 all of the en route data packets and replicating them. A selected 269 data packet that is replicated, and its (possibly truncated) copy 270 is forwarded with one or more IOAM option, while the original 271 packet is forwarded normally, without IOAM options. To the extent 272 possible, the original data packet and its replica are forwarded 273 through the same path. The replica includes a Trace Option that 274 has its Active flag set, indicating that the decapsulating node 275 should terminate it. It should be noted that the current document 276 defines the role of the active flag in allowing the decapsulating 277 node to terminate the packet, but the replication functionality in 278 this context is outside the scope of this document. 280 6. IANA Considerations 282 IANA is requested to allocate the following bits in the "IOAM Trace 283 Flags Registry" as follows: 285 Bit 1 "Loopback" (L-bit) 287 Bit 2 "Active" (A-bit) 289 Note that bit 0 is the most significant bit in the Flags Registry. 291 7. Performance Considerations 293 Each of the flags that are defined in this document may have 294 performance implications. When using the loopback mechanism a copy 295 of the data packet is sent back to the sender, thus generating more 296 traffic than originally sent by the endpoints. Using active 297 measurement with the active flag requires the use of synthetic 298 (overhead) traffic. 300 Each of the mechanisms that use the flags above has a cost in terms 301 of the network bandwidth, and may potentially load the node that 302 analyzes the data. Therefore, it MUST be possible to use each of the 303 mechanisms on a subset of the data traffic; an encapsulating node 304 needs to be able to set the Loopback and Active flag selectively, in 305 a way that considers the effect on the network performance. 306 Similarly, transit and decapsulating nodes need to be able to 307 selectively loop back packets with the Loopback flag, and to 308 selectively export packets. Specifically, rate limiting can be 309 enabled so as to ensure that the mechanisms are used at a rate that 310 does not significantly affect the network bandwidth, and does not 311 overload the receiving entity (or the source node in the case of 312 loopback). 314 8. Security Considerations 316 The security considerations of IOAM in general are discussed in 317 [I-D.ietf-ippm-ioam-data]. Specifically, an attacker may try to use 318 the functionality that is defined in this document to attack the 319 network. 321 An attacker may attempt to overload network devices by injecting 322 synthetic packets that include an IOAM Trace Option with one or more 323 of the flags defined in this document. Similarly, an on-path 324 attacker may maliciously set one or more of the flags of transit 325 packets. 327 o Loopback flag: an attacker that sets this flag, either in 328 synthetic packets or transit packet, can potentially cause an 329 amplification, since each device along the path creates a copy of 330 the data packet and sends it back to the source. The attacker can 331 potentially leverage the loopback flag for a Distributed Denial of 332 Service (DDoS) attack, as multiple devices send looped-back copies 333 of a packet to a single source. 335 o Active flag: the impact of synthetic packets with the active flag 336 is no worse than synthetic data packets in which the Active flag 337 is not set. By setting the active flag in en route packets an 338 attacker can prevent these packets from reaching their 339 destination, since the packet is terminated by the decapsulating 340 device; however, note that an on-path attacker may achieve the 341 same goal by changing the destination address of a packet. 342 Another potential threat is amplification; if an attacker causes 343 transit switches to replicate more packets than they are intended 344 to replicate, either by setting the Active flag or by sending 345 synthetic packets, then traffic is amplified, causing bandwidth 346 degredation. As mentioned in Section 5, the specification of the 347 replication mechanism is not within the scope of this document. A 348 specification that defines the replication functionality should 349 also address the security aspects of this mechanism. 351 Some of the security threats that were discussed in this document may 352 be worse in a wide area network in which there are nested IOAM 353 domains. For example, if there are two nested IOAM domains that use 354 loopback, then a looped-back copy in the outer IOAM domain may be 355 forwarded through another (inner) IOAM domain and may be subject to 356 loopback in that (inner) IOAM domain, causing the amplification to be 357 worse than in the conventional case. 359 In order to mitigate the attacks described above, as described in 360 Section 7 it should be possible for IOAM-enabled devices to 361 selectively apply the mechanisms that use the flags defined in this 362 document to a subset of the traffic, and to limit the performance of 363 synthetically generated packets to a configurable rate; specifically, 364 network devices should be able to limit the rate of: (i) looped-back 365 traffic (at transit nodes), (ii) replicated active packets (at 366 encapsulating nodes), (iii) packets that are exported to a collector 367 (from either encapsulating nodes or transit nodes), and (iv) 368 synthetically generated packets (at encapsulating nodes). 370 Furthermore, as defined in Section 4, transit nodes that process a 371 packet with the Loopback flag only add a single data field, and 372 truncate any payload that follows the IOAM option(s), thus 373 significanly limiting the possible impact of an amplification attack. 375 IOAM is assumed to be deployed in a restricted administrative domain, 376 thus limiting the scope of the threats above and their affect. This 377 is a fundamental assumtion with respect to the security aspects of 378 IOAM, as further discussed in [I-D.ietf-ippm-ioam-data]. 380 9. References 382 9.1. Normative References 384 [I-D.ietf-ippm-ioam-data] 385 Brockners, F., Bhandari, S., and T. Mizrahi, "Data Fields 386 for In-situ OAM", draft-ietf-ippm-ioam-data-11 (work in 387 progress), November 2020. 389 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 390 Requirement Levels", BCP 14, RFC 2119, 391 DOI 10.17487/RFC2119, March 1997, 392 . 394 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 395 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 396 May 2017, . 398 9.2. Informative References 400 [I-D.ietf-ippm-ioam-ipv6-options] 401 Bhandari, S., Brockners, F., Pignataro, C., Gredler, H., 402 Leddy, J., Youell, S., Mizrahi, T., Kfir, A., Gafni, B., 403 Lapukhov, P., Spiegel, M., Krishnan, S., Asati, R., and M. 404 Smith, "In-situ OAM IPv6 Options", draft-ietf-ippm-ioam- 405 ipv6-options-04 (work in progress), November 2020. 407 [I-D.ietf-sfc-ioam-nsh] 408 Brockners, F. and S. Bhandari, "Network Service Header 409 (NSH) Encapsulation for In-situ OAM (IOAM) Data", draft- 410 ietf-sfc-ioam-nsh-05 (work in progress), December 2020. 412 [I-D.spiegel-ippm-ioam-rawexport] 413 Spiegel, M., Brockners, F., Bhandari, S., and R. 414 Sivakolundu, "In-situ OAM raw data export with IPFIX", 415 draft-spiegel-ippm-ioam-rawexport-04 (work in progress), 416 November 2020. 418 [RFC7799] Morton, A., "Active and Passive Metrics and Methods (with 419 Hybrid Types In-Between)", RFC 7799, DOI 10.17487/RFC7799, 420 May 2016, . 422 Authors' Addresses 424 Tal Mizrahi 425 Huawei 426 Israel 428 Email: tal.mizrahi.phd@gmail.com 430 Frank Brockners 431 Cisco Systems, Inc. 432 Hansaallee 249, 3rd Floor 433 DUESSELDORF, NORDRHEIN-WESTFALEN 40549 434 Germany 436 Email: fbrockne@cisco.com 438 Shwetha Bhandari (editor) 439 Thoughtspot 440 3rd Floor, Indiqube Orion, 24th Main Rd, Garden Layout, HSR Layout 441 Bangalore, KARNATAKA 560 102 442 India 444 Email: shwetha.bhandari@thoughtspot.com 446 Ramesh Sivakolundu 447 Cisco Systems, Inc. 448 170 West Tasman Dr. 449 SAN JOSE, CA 95134 450 U.S.A. 452 Email: sramesh@cisco.com 454 Carlos Pignataro 455 Cisco Systems, Inc. 456 7200-11 Kit Creek Road 457 Research Triangle Park, NC 27709 458 United States 460 Email: cpignata@cisco.com 461 Aviv Kfir 462 Nvidia 464 Email: avivk@nvidia.com 466 Barak Gafni 467 Nvidia 468 350 Oakmead Parkway, Suite 100 469 Sunnyvale, CA 94085 470 U.S.A. 472 Email: gbarak@nvidia.com 474 Mickey Spiegel 475 Barefoot Networks 476 4750 Patrick Henry Drive 477 Santa Clara, CA 95054 478 US 480 Email: mspiegel@barefootnetworks.com 482 Jennifer Lemon 483 Broadcom 484 270 Innovation Drive 485 San Jose, CA 95134 486 US 488 Email: jennifer.lemon@broadcom.com