idnits 2.17.1 draft-ietf-ippm-ioam-flags-01.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 (January 26, 2020) is 1549 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-08 == Outdated reference: A later version (-13) exists of draft-ietf-sfc-ioam-nsh-02 == Outdated reference: A later version (-07) exists of draft-spiegel-ippm-ioam-rawexport-02 Summary: 0 errors (**), 0 flaws (~~), 4 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: July 29, 2020 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 January 26, 2020 18 In-situ OAM Flags 19 draft-ietf-ippm-ioam-flags-01 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 July 29, 2020. 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 205 [I-D.ioametal-ippm-6man-ioam-ipv6-options]. 207 +--------+ +--------+ +--------+ +--------+ +--------+ 208 | | | IOAM |.....| IOAM |.....| IOAM | | | 209 +--------+ +--------+ +--------+ +--------+ +--------+ 210 | L2/L3 |<===>| L2/L3 |<===>| L2/L3 |<===>| L2/L3 |<===>| L2/L3 | 211 +--------+ +--------+ +--------+ +--------+ +--------+ 212 Source Encapsulating Transit Decapsulating Destination 213 Node Node Node 215 <------------ IOAM domain -----------> 217 Figure 1: Network using IOAM. 219 This draft focuses on three possible use cases of active measurement 220 using IOAM. These use cases are described using the example of 221 Figure 1. 223 o Endpoint active measurement: synthetic probe packets are sent 224 between the source and destination, traversing the IOAM domain. 225 Since the probe packets are sent between the endpoints, these 226 packets are treated as data packets by the IOAM domain, and do not 227 require special treatment at the IOAM layer. Specifically, the 228 active flag is not used in this case, and the IOAM layer needs not 229 be aware that an active measurement mechanism is used at a higher 230 layer. 232 o IOAM active measurement using probe packets within the IOAM 233 domain: probe packets are generated and transmitted by the IOAM 234 encapsulating node, and are expected to be terminated by the 235 decapsulating node. IOAM data related to probe packets may be 236 exported by one or more nodes along its path, by an exporting 237 protocol that is outside the scope of this document (e.g., 238 [I-D.spiegel-ippm-ioam-rawexport]). Probe packets include a Trace 239 Option which has its Active flag set, indicating that the 240 decapsulating node must terminate them. 242 o IOAM active measurement using replicated data packets: probe 243 packets are created by the encapsulating node by selecting some or 244 all of the en route data packets and replicating them. A selected 245 data packet that is replicated, and its (possibly truncated) copy 246 is forwarded with one or more IOAM option, while the original 247 packet is forwarded normally, without IOAM options. To the extent 248 possible, the original data packet and its replica are forwarded 249 through the same path. The replica includes a Trace Option that 250 has its Active flag set, indicating that the decapsulating node 251 should terminate it. It should be noted that the current document 252 defines the role of the active flag in allowing the decapsulating 253 node to terminate the packet, but the replication functionality in 254 this context is outside the scope of this document. 256 6. IANA Considerations 258 IANA is requested to allocate the following bits in the "IOAM Trace 259 Flags Registry" as follows: 261 Bit 1 "Loopback" (L-bit) 263 Bit 2 "Active" (A-bit) 265 Note that bit 0 is the most significant bit in the Flags Registry. 267 7. Performance Considerations 269 Each of the flags that are defined in this document may have 270 performance implications. When using the loopback mechanism a copy 271 of the data packet is sent back to the sender, thus generating more 272 traffic than originally sent by the endpoints. Using active 273 measurement with the active flag requires the use of synthetic 274 (overhead) traffic. 276 Each of the mechanisms that use the flags above has a cost in terms 277 of the network bandwidth, and may potentially load the node that 278 analyzes the data. Therefore, it MUST be possible to use each of the 279 mechanisms on a subset of the data traffic; an encapsulating node 280 needs to be able to set the Loopback and Active flag selectively, in 281 a way that considers the effect on the network performance. 283 Similarly, transit and decapsulating nodes need to be able to 284 selectively loop back packets with the Loopback flag, and to 285 selectively export packets. Specifically, rate limiting may be 286 enabled so as to ensure that the mechanisms are used at a rate that 287 does not significantly affect the network bandwidth, and does not 288 overload the receiving entity (or the source node in the case of 289 loopback). 291 8. Security Considerations 293 The security considerations of IOAM in general are discussed in 294 [I-D.ietf-ippm-ioam-data]. Specifically, an attacker may try to use 295 the functionality that is defined in this document to attack the 296 network. 298 An attacker may attempt to overload network devices by injecting 299 synthetic packets that include an IOAM Trace Option with one or more 300 of the flags defined in this document. Similarly, an on-path 301 attacker may maliciously set one or more of the flags of transit 302 packets. 304 o Loopback flag: an attacker that sets this flag, either in 305 synthetic packets or transit packet, can potentially cause an 306 amplification, since each device along the path creates a copy of 307 the data packet and sends it back to the source. The attacker can 308 potentially leverage the loopback flag for a Distributed Denial of 309 Service (DDoS) attack, as multiple devices send looped-back copies 310 of a packet to a single source. 312 o Active flag: the impact of synthetic packets with the active flag 313 is no worse than synthetic data packets in which the Active flag 314 is not set. By setting the active flag in en route packets an 315 attacker can prevent these packets from reaching their 316 destination, since the packet is terminated by the decapsulating 317 device; however, note that an on-path attacker may achieve the 318 same goal by changing the destination address of a packet. 319 Another potential threat is amplification; if an attacker causes 320 transit switches to replicate more packets than they are intended 321 to replicate, either by setting the Active flag or by sending 322 synthetic packets, then traffic is amplified, causing bandwidth 323 degredation. As mentioned in Section 5, the specification of the 324 replication mechanism is not within the scope of this document. A 325 specification that defines the replication functionality should 326 also address the security aspects of this mechanism. 328 In order to mitigate the attacks described above, as described in 329 Section 7 it should be possible for IOAM-enabled devices to 330 selectively apply the mechanisms that use the flags defined in this 331 document to a subset of the traffic, and to limit the performance of 332 synthetically generated packets to a configurable rate; specifically, 333 network devices should be able to limit the rate of: (i) looped-back 334 traffic (at transit nodes), (ii) replicated active packets (at 335 encapsulating nodes), (iii) packets that are exported to a collector 336 (from either encapsulating nodes or transit nodes), and (iv) 337 synthetically generated packets (at encapsulating nodes). 339 Furthermore, as defined in Section 4, transit nodes that process a 340 packet with the Loopback flag only add a single data field, and 341 truncate any payload that follows the IOAM option(s), thus 342 significanly limiting the possible impact of an amplification attack. 344 IOAM is assumed to be deployed in a restricted administrative domain, 345 thus limiting the scope of the threats above and their affect. This 346 is a fundamental assumtion with respect to the security aspects of 347 IOAM, as further discussed in [I-D.ietf-ippm-ioam-data]. 349 9. References 351 9.1. Normative References 353 [I-D.ietf-ippm-ioam-data] 354 Brockners, F., Bhandari, S., Pignataro, C., Gredler, H., 355 Leddy, J., Youell, S., Mizrahi, T., Mozes, D., Lapukhov, 356 P., remy@barefootnetworks.com, r., daniel.bernier@bell.ca, 357 d., and J. Lemon, "Data Fields for In-situ OAM", draft- 358 ietf-ippm-ioam-data-08 (work in progress), October 2019. 360 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 361 Requirement Levels", BCP 14, RFC 2119, 362 DOI 10.17487/RFC2119, March 1997, 363 . 365 9.2. Informative References 367 [I-D.ietf-sfc-ioam-nsh] 368 Brockners, F. and S. Bhandari, "Network Service Header 369 (NSH) Encapsulation for In-situ OAM (IOAM) Data", draft- 370 ietf-sfc-ioam-nsh-02 (work in progress), September 2019. 372 [I-D.ioametal-ippm-6man-ioam-ipv6-options] 373 Bhandari, S., Brockners, F., Pignataro, C., Gredler, H., 374 Leddy, J., Youell, S., Mizrahi, T., Kfir, A., Gafni, B., 375 Lapukhov, P., Spiegel, M., Krishnan, S., and R. Asati, 376 "In-situ OAM IPv6 Options", draft-ioametal-ippm-6man-ioam- 377 ipv6-options-02 (work in progress), March 2019. 379 [I-D.spiegel-ippm-ioam-rawexport] 380 Spiegel, M., Brockners, F., Bhandari, S., and R. 381 Sivakolundu, "In-situ OAM raw data export with IPFIX", 382 draft-spiegel-ippm-ioam-rawexport-02 (work in progress), 383 July 2019. 385 [RFC7799] Morton, A., "Active and Passive Metrics and Methods (with 386 Hybrid Types In-Between)", RFC 7799, DOI 10.17487/RFC7799, 387 May 2016, . 389 Authors' Addresses 391 Tal Mizrahi 392 Huawei Smart Platforms iLab 393 Israel 395 Email: tal.mizrahi.phd@gmail.com 397 Frank Brockners 398 Cisco Systems, Inc. 399 Hansaallee 249, 3rd Floor 400 DUESSELDORF, NORDRHEIN-WESTFALEN 40549 401 Germany 403 Email: fbrockne@cisco.com 405 Shwetha Bhandari 406 Cisco Systems, Inc. 407 Cessna Business Park, Sarjapura Marathalli Outer Ring Road 408 Bangalore, KARNATAKA 560 087 409 India 411 Email: shwethab@cisco.com 413 Ramesh Sivakolundu 414 Cisco Systems, Inc. 415 170 West Tasman Dr. 416 SAN JOSE, CA 95134 417 U.S.A. 419 Email: sramesh@cisco.com 420 Carlos Pignataro 421 Cisco Systems, Inc. 422 7200-11 Kit Creek Road 423 Research Triangle Park, NC 27709 424 United States 426 Email: cpignata@cisco.com 428 Aviv Kfir 429 Mellanox Technologies, Inc. 430 350 Oakmead Parkway, Suite 100 431 Sunnyvale, CA 94085 432 U.S.A. 434 Email: avivk@mellanox.com 436 Barak Gafni 437 Mellanox Technologies, Inc. 438 350 Oakmead Parkway, Suite 100 439 Sunnyvale, CA 94085 440 U.S.A. 442 Email: gbarak@mellanox.com 444 Mickey Spiegel 445 Barefoot Networks 446 4750 Patrick Henry Drive 447 Santa Clara, CA 95054 448 US 450 Email: mspiegel@barefootnetworks.com 452 Jennifer Lemon 453 Broadcom 454 270 Innovation Drive 455 San Jose, CA 95134 456 US 458 Email: jennifer.lemon@broadcom.com