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