idnits 2.17.1 draft-ietf-ippm-ioam-flags-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 (July 27, 2020) is 1362 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-02 == 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: January 28, 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 July 27, 2020 18 In-situ OAM Flags 19 draft-ietf-ippm-ioam-flags-02 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 January 28, 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 . . . . . . . . . . . . . . . . 4 70 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 71 7. Performance Considerations . . . . . . . . . . . . . . . . . 6 72 8. Security Considerations . . . . . . . . . . . . . . . . . . . 7 73 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 74 9.1. Normative References . . . . . . . . . . . . . . . . . . 8 75 9.2. Informative References . . . . . . . . . . . . . . . . . 8 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. 131 Loopback mode assumes that 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 generates synthetic packets with an IOAM trace 140 option that has the loopback flag set. These packets are generated 141 either proactively or on-demand, i.e., when a failure is detected. 142 The encapsulating node also needs to ensure that sufficient space is 143 available in the IOAM header for loopback operation, which includes 144 transit nodes adding trace data on the original path and then again 145 on the return path. An IOAM trace option that has the loopback bit 146 set MUST have the value '1' in the most significant bit of IOAM- 147 Trace-Type, and '0' in the rest of the bits of IOAM-Trace-Type. 148 Thus, every transit node that processes this trace option only adds a 149 single data field, which is the Hop_Lim and node_id data field. The 150 reason for allowing a single data field per hop is to minimize the 151 impact of amplification attacks. 153 A loopback bit that is set indicates to the transit nodes processing 154 this option that they are to create a copy of the received packet and 155 send the copy back to the source of the packet. The copy has its 156 data fields added after being copied in order to allow any egress- 157 dependent information to be set based on the egress of the copy 158 rather than the original. The copy is also truncated, i.e., any 159 payload that resides after the IOAM option(s) is removed before 160 transmitting the looped back packet back towards the encapsulating 161 node. The original packet continues towards its destination. The 162 source address of the original packet is used as the destination 163 address in the copied packet. The address of the node performing the 164 copy operation is used as the source address. The L-bit MUST be 165 cleared in the copy of the packet that a node sends back towards the 166 source. On its way back towards the source, the copied packet is 167 processed like any other packet with IOAM information, including 168 adding any requested data at each transit node (assuming there is 169 sufficient space). 171 Once the return packet reaches the IOAM domain boundary, IOAM 172 decapsulation occurs as with any other packet containing IOAM 173 information. Because any intermediate node receiving such a packet 174 would not know how to process the original packet, and because there 175 would be a risk of the original packet leaking past the initiator of 176 the IOAM loopback, the initiator of an IOAM loopback MUST be the 177 initiator of the packet. Once a loopback packet is received back at 178 the initiator, it is a local matter how it is recognized as a 179 loopback packet. 181 5. Active Measurement with IOAM 183 Active measurement methods [RFC7799] make use of synthetically 184 generated packets in order to facilitate the measurement. This 185 section presents use cases of active measurement using the IOAM 186 Active flag. 188 The active flag indicates that a packet is used for active 189 measurement. An IOAM decapsulating node that receives a packet with 190 the Active flag set in one of its Trace options must terminate the 191 packet. The active flag is intended to simplify the implementation 192 of decapsulating nodes by indicating that the packet should not be 193 forwarded further. It is not intended as a replacement for existing 194 active OAM protocols, which may run in higher layers and make use of 195 the active flag. 197 An example of an IOAM deployment scenario is illustrated in Figure 1. 198 The figure depicts two endpoints, a source and a destination. The 199 data traffic from the source to the destination is forwarded through 200 a set of network devices, including an IOAM encapsulating node, which 201 incorporates one or more IOAM options, a decapsulating node, which 202 removes the IOAM options, optionally one or more transit nodes. The 203 IOAM options are encapsulated in one of the IOAM encapsulation types, 204 e.g., [I-D.ietf-sfc-ioam-nsh], or [I-D.ietf-ippm-ioam-ipv6-options]. 206 +--------+ +--------+ +--------+ +--------+ +--------+ 207 | | | IOAM |.....| IOAM |.....| IOAM | | | 208 +--------+ +--------+ +--------+ +--------+ +--------+ 209 | L2/L3 |<===>| L2/L3 |<===>| L2/L3 |<===>| L2/L3 |<===>| L2/L3 | 210 +--------+ +--------+ +--------+ +--------+ +--------+ 211 Source Encapsulating Transit Decapsulating Destination 212 Node Node Node 214 <------------ IOAM domain -----------> 216 Figure 1: Network using IOAM. 218 This draft focuses on three possible use cases of active measurement 219 using IOAM. These use cases are described using the example of 220 Figure 1. 222 o Endpoint active measurement: synthetic probe packets are sent 223 between the source and destination, traversing the IOAM domain. 224 Since the probe packets are sent between the endpoints, these 225 packets are treated as data packets by the IOAM domain, and do not 226 require special treatment at the IOAM layer. Specifically, the 227 active flag is not used in this case, and the IOAM layer needs not 228 be aware that an active measurement mechanism is used at a higher 229 layer. 231 o IOAM active measurement using probe packets within the IOAM 232 domain: probe packets are generated and transmitted by the IOAM 233 encapsulating node, and are expected to be terminated by the 234 decapsulating node. IOAM data related to probe packets may be 235 exported by one or more nodes along its path, by an exporting 236 protocol that is outside the scope of this document (e.g., 237 [I-D.spiegel-ippm-ioam-rawexport]). Probe packets include a Trace 238 Option which has its Active flag set, indicating that the 239 decapsulating node must terminate them. 241 o IOAM active measurement using replicated data packets: probe 242 packets are created by the encapsulating node by selecting some or 243 all of the en route data packets and replicating them. A selected 244 data packet that is replicated, and its (possibly truncated) copy 245 is forwarded with one or more IOAM option, while the original 246 packet is forwarded normally, without IOAM options. To the extent 247 possible, the original data packet and its replica are forwarded 248 through the same path. The replica includes a Trace Option that 249 has its Active flag set, indicating that the decapsulating node 250 should terminate it. It should be noted that the current document 251 defines the role of the active flag in allowing the decapsulating 252 node to terminate the packet, but the replication functionality in 253 this context is outside the scope of this document. 255 6. IANA Considerations 257 IANA is requested to allocate the following bits in the "IOAM Trace 258 Flags Registry" as follows: 260 Bit 1 "Loopback" (L-bit) 262 Bit 2 "Active" (A-bit) 264 Note that bit 0 is the most significant bit in the Flags Registry. 266 7. Performance Considerations 268 Each of the flags that are defined in this document may have 269 performance implications. When using the loopback mechanism a copy 270 of the data packet is sent back to the sender, thus generating more 271 traffic than originally sent by the endpoints. Using active 272 measurement with the active flag requires the use of synthetic 273 (overhead) traffic. 275 Each of the mechanisms that use the flags above has a cost in terms 276 of the network bandwidth, and may potentially load the node that 277 analyzes the data. Therefore, it MUST be possible to use each of the 278 mechanisms on a subset of the data traffic; an encapsulating node 279 needs to be able to set the Loopback and Active flag selectively, in 280 a way that considers the effect on the network performance. 281 Similarly, transit and decapsulating nodes need to be able to 282 selectively loop back packets with the Loopback flag, and to 283 selectively export packets. Specifically, rate limiting may be 284 enabled so as to ensure that the mechanisms are used at a rate that 285 does not significantly affect the network bandwidth, and does not 286 overload the receiving entity (or the source node in the case of 287 loopback). 289 8. Security Considerations 291 The security considerations of IOAM in general are discussed in 292 [I-D.ietf-ippm-ioam-data]. Specifically, an attacker may try to use 293 the functionality that is defined in this document to attack the 294 network. 296 An attacker may attempt to overload network devices by injecting 297 synthetic packets that include an IOAM Trace Option with one or more 298 of the flags defined in this document. Similarly, an on-path 299 attacker may maliciously set one or more of the flags of transit 300 packets. 302 o Loopback flag: an attacker that sets this flag, either in 303 synthetic packets or transit packet, can potentially cause an 304 amplification, since each device along the path creates a copy of 305 the data packet and sends it back to the source. The attacker can 306 potentially leverage the loopback flag for a Distributed Denial of 307 Service (DDoS) attack, as multiple devices send looped-back copies 308 of a packet to a single source. 310 o Active flag: the impact of synthetic packets with the active flag 311 is no worse than synthetic data packets in which the Active flag 312 is not set. By setting the active flag in en route packets an 313 attacker can prevent these packets from reaching their 314 destination, since the packet is terminated by the decapsulating 315 device; however, note that an on-path attacker may achieve the 316 same goal by changing the destination address of a packet. 317 Another potential threat is amplification; if an attacker causes 318 transit switches to replicate more packets than they are intended 319 to replicate, either by setting the Active flag or by sending 320 synthetic packets, then traffic is amplified, causing bandwidth 321 degredation. As mentioned in Section 5, the specification of the 322 replication mechanism is not within the scope of this document. A 323 specification that defines the replication functionality should 324 also address the security aspects of this mechanism. 326 In order to mitigate the attacks described above, as described in 327 Section 7 it should be possible for IOAM-enabled devices to 328 selectively apply the mechanisms that use the flags defined in this 329 document to a subset of the traffic, and to limit the performance of 330 synthetically generated packets to a configurable rate; specifically, 331 network devices should be able to limit the rate of: (i) looped-back 332 traffic (at transit nodes), (ii) replicated active packets (at 333 encapsulating nodes), (iii) packets that are exported to a collector 334 (from either encapsulating nodes or transit nodes), and (iv) 335 synthetically generated packets (at encapsulating nodes). 337 Furthermore, as defined in Section 4, transit nodes that process a 338 packet with the Loopback flag only add a single data field, and 339 truncate any payload that follows the IOAM option(s), thus 340 significanly limiting the possible impact of an amplification attack. 342 IOAM is assumed to be deployed in a restricted administrative domain, 343 thus limiting the scope of the threats above and their affect. This 344 is a fundamental assumtion with respect to the security aspects of 345 IOAM, as further discussed in [I-D.ietf-ippm-ioam-data]. 347 9. References 349 9.1. Normative References 351 [I-D.ietf-ippm-ioam-data] 352 Brockners, F., Bhandari, S., and T. Mizrahi, "Data Fields 353 for In-situ OAM", draft-ietf-ippm-ioam-data-10 (work in 354 progress), July 2020. 356 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 357 Requirement Levels", BCP 14, RFC 2119, 358 DOI 10.17487/RFC2119, March 1997, 359 . 361 9.2. Informative References 363 [I-D.ietf-ippm-ioam-ipv6-options] 364 Bhandari, S., Brockners, F., Pignataro, C., Gredler, H., 365 Leddy, J., Youell, S., Mizrahi, T., Kfir, A., Gafni, B., 366 Lapukhov, P., Spiegel, M., Krishnan, S., and R. Asati, 367 "In-situ OAM IPv6 Options", draft-ietf-ippm-ioam- 368 ipv6-options-02 (work in progress), July 2020. 370 [I-D.ietf-sfc-ioam-nsh] 371 Brockners, F. and S. Bhandari, "Network Service Header 372 (NSH) Encapsulation for In-situ OAM (IOAM) Data", draft- 373 ietf-sfc-ioam-nsh-04 (work in progress), June 2020. 375 [I-D.spiegel-ippm-ioam-rawexport] 376 Spiegel, M., Brockners, F., Bhandari, S., and R. 377 Sivakolundu, "In-situ OAM raw data export with IPFIX", 378 draft-spiegel-ippm-ioam-rawexport-03 (work in progress), 379 March 2020. 381 [RFC7799] Morton, A., "Active and Passive Metrics and Methods (with 382 Hybrid Types In-Between)", RFC 7799, DOI 10.17487/RFC7799, 383 May 2016, . 385 Authors' Addresses 387 Tal Mizrahi 388 Huawei Smart Platforms iLab 389 Israel 391 Email: tal.mizrahi.phd@gmail.com 393 Frank Brockners 394 Cisco Systems, Inc. 395 Hansaallee 249, 3rd Floor 396 DUESSELDORF, NORDRHEIN-WESTFALEN 40549 397 Germany 399 Email: fbrockne@cisco.com 401 Shwetha Bhandari 402 Cisco Systems, Inc. 403 Cessna Business Park, Sarjapura Marathalli Outer Ring Road 404 Bangalore, KARNATAKA 560 087 405 India 407 Email: shwethab@cisco.com 409 Ramesh Sivakolundu 410 Cisco Systems, Inc. 411 170 West Tasman Dr. 412 SAN JOSE, CA 95134 413 U.S.A. 415 Email: sramesh@cisco.com 416 Carlos Pignataro 417 Cisco Systems, Inc. 418 7200-11 Kit Creek Road 419 Research Triangle Park, NC 27709 420 United States 422 Email: cpignata@cisco.com 424 Aviv Kfir 425 Mellanox Technologies, Inc. 426 350 Oakmead Parkway, Suite 100 427 Sunnyvale, CA 94085 428 U.S.A. 430 Email: avivk@mellanox.com 432 Barak Gafni 433 Mellanox Technologies, Inc. 434 350 Oakmead Parkway, Suite 100 435 Sunnyvale, CA 94085 436 U.S.A. 438 Email: gbarak@mellanox.com 440 Mickey Spiegel 441 Barefoot Networks 442 4750 Patrick Henry Drive 443 Santa Clara, CA 95054 444 US 446 Email: mspiegel@barefootnetworks.com 448 Jennifer Lemon 449 Broadcom 450 270 Innovation Drive 451 San Jose, CA 95134 452 US 454 Email: jennifer.lemon@broadcom.com