idnits 2.17.1 draft-mizrahi-ippm-ioam-flags-00.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 04, 2019) is 1755 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-05 == Outdated reference: A later version (-13) exists of draft-ietf-sfc-ioam-nsh-01 == Outdated reference: A later version (-07) exists of draft-spiegel-ippm-ioam-rawexport-01 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 Network.IO Innovation Lab 4 Intended status: Standards Track F. Brockners 5 Expires: January 5, 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 July 04, 2019 18 In-situ OAM Flags 19 draft-mizrahi-ippm-ioam-flags-00 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, Active, and Immediate Export 28 flags. 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 https://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 January 5, 2020. 47 Copyright Notice 49 Copyright (c) 2019 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 (https://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. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 66 2.1. Requirement Language . . . . . . . . . . . . . . . . . . 3 67 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 68 3. New IOAM Trace Option Flags . . . . . . . . . . . . . . . . . 3 69 4. Loopback in IOAM . . . . . . . . . . . . . . . . . . . . . . 3 70 5. Active Measurement with IOAM . . . . . . . . . . . . . . . . 4 71 6. Immediate Exporting . . . . . . . . . . . . . . . . . . . . . 5 72 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 73 8. Performance Considerations . . . . . . . . . . . . . . . . . 6 74 9. Security Considerations . . . . . . . . . . . . . . . . . . . 7 75 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 76 10.1. Normative References . . . . . . . . . . . . . . . . . . 8 77 10.2. Informative References . . . . . . . . . . . . . . . . . 8 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 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 three new flags in the Pre-allocated and Incremental Trace options: 90 the Loopback, Active, and Immediate Export flags. 92 2. Conventions 94 2.1. Requirement Language 96 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 97 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 98 document are to be interpreted as described in [RFC2119]. 100 2.2. Terminology 102 Abbreviations used in this document: 104 IOAM: In-situ Operations, Administration, and Maintenance 106 OAM: Operations, Administration, and Maintenance 108 3. New IOAM Trace Option Flags 110 This document defines three new flags in the Pre-allocated and 111 Incremental Trace options: 113 Bit 1 "Loopback" (L-bit). Loopback mode is used to send a copy of a 114 packet back towards the source, as further described in Section 4. 116 Bit 2 "Active" (A-bit). When set, this indicates that this is an 117 active IOAM packet, where "active" is used in the sense defined in 118 [RFC7799], rather than a data packet. The packet may be an IOAM 119 probe packet, or a replicated data packet (the second and third 120 use cases of Section 5). 122 Bit 3 "Immediate Export" (I-bit). Immediate export mode is used to 123 export IOAM data fields immediately at every IOAM supported 124 network node, instead of adding the IOAM data fields to the packet 125 traversing the network. Further details are provided in 126 Section 6. 128 4. Loopback in IOAM 130 Loopback is used for trigerring each transit device along the path to 131 loop back a copy of the data packet. Loopback mode assumes that a 132 return path from transit nodes and destination nodes towards the 133 source exists. The encapsulating node decides (e.g., using a filter) 134 which packets loopback mode is enabled for by setting the loopback 135 bit. The encapsulating node also needs to ensure that sufficient 136 space is available in the IOAM header for loopback operation, which 137 includes intermediate nodes adding trace data on the original path 138 and then again on the return path. A loopback bit that is set 139 indicates to the transit nodes processing this option that they are 140 to create a copy of the received packet and send the copy back to the 141 source of the packet. The copy has its metadata added after being 142 copied in order to allow any egress-dependent information to be set 143 based on the egress of the copy rather than the original. The 144 original packet continues towards its destination. The source 145 address of the original packet is used as the destination address in 146 the copied packet. The address of the node performing the copy 147 operation is used as the source address. The L-bit MUST be cleared 148 in the copy of the packet that a node sends back towards the source. 149 On its way back towards the source, the copied packet is processed 150 like any other packet with IOAM information, including adding any 151 requested data at each transit node (assuming there is sufficient 152 space). Once the return packet reaches the IOAM domain boundary, 153 IOAM decapsulation occurs as with any other packet containing IOAM 154 information. Because any intermediate node receiving such a packet 155 would not know how to process the original packet, and because there 156 would be a risk of the original packet leaking past the initiator of 157 the IOAM loopback, the initiator of an IOAM loopback MUST be the 158 initiator of the packet. Once a loopback packet is received back at 159 the initiator, it is a local matter how it is recognized as a 160 loopback packet. 162 5. Active Measurement with IOAM 164 Active measurement methods [RFC7799] make use of synthetically 165 generated packets in order to facilitate the measurement. This 166 section presents use cases of active measurement using the IOAM 167 Active flag. 169 The active flag indicates that a packet is used for active 170 measurement. An IOAM decapsulating node that receives a packet with 171 the Active flag set in one of its Trace options must terminate the 172 packet. 174 An example of an IOAM deployment scenario is illustrated in Figure 1. 175 The figure depicts two endpoints, a source and a destination. The 176 data traffic from the source to the destination is forwarded through 177 a set of network devices, including an IOAM encapsulating node, which 178 incorporates one or more IOAM option, a decapsulating node, which 179 removes the IOAM options, optionally one or more transit nodes. The 180 IOAM options are encapsulated in one of the IOAM encapsulation types, 181 e.g., [I-D.ietf-sfc-ioam-nsh], or 182 [I-D.ioametal-ippm-6man-ioam-ipv6-options]. 184 +--------+ +--------+ +--------+ +--------+ +--------+ 185 | | | IOAM |.....| IOAM |.....| IOAM | | | 186 +--------+ +--------+ +--------+ +--------+ +--------+ 187 | L2/L3 |<===>| L2/L3 |<===>| L2/L3 |<===>| L2/L3 |<===>| L2/L3 | 188 +--------+ +--------+ +--------+ +--------+ +--------+ 189 Source Encapsulating Transit Decapsulating Destination 190 Node Node Node 192 Figure 1: Network using IOAM. 194 This draft focuses on three possible use cases of active measurement 195 using IOAM. These use cases are described using the example of 196 Figure 1. 198 o Endpoint active measurement: synthetic probe packets are sent 199 between the source and destination, traversing the IOAM domain. 200 Since the probe packets are sent between the endpoints, these 201 packets are treated as data packets by the IOAM domain, and do not 202 require special treatment at the IOAM layer. 204 o IOAM active measurement using probe packets: probe packets are 205 generated and transmitted by the IOAM encapsulating node, and are 206 expected to be terminated by the decapsulating node. IOAM data 207 related to probe packets may be exported by one or more nodes 208 along its path, by an exporting protocol that is outside the scope 209 of this document (e.g., [I-D.spiegel-ippm-ioam-rawexport]). Probe 210 packets include a Trace Option which has its Active flag set, 211 indicating that the decapsulating node must terminate them. 213 o IOAM active measurement using replicated data packets: probe 214 packets are created by the encapsulating node by selecting some or 215 all of the en route data packets and replicating them. A selected 216 data packet that is replicated, and its (possibly truncated) copy 217 is forwarded with one or more IOAM option, while the original 218 packet is forwarded normally, without IOAM options. To the extent 219 possible, the original data packet and its replica are forwarded 220 through the same path. The replica includes a Trace Option that 221 has its Active flag set, indicating that the decapsulating node 222 should terminate it. 224 6. Immediate Exporting 226 Immediate exporting can be used to export IOAM data to a collector 227 instead of incorporating this data into en route data packets. The 228 various types of IOAM nodes MUST process packets with the I-bit set 229 as follows: 231 1. An encapsulating IOAM node configured to set the I-bit 232 encapsulates the packet with the IOAM header and sets the I-bit, 233 leaving the IOAM header without locally collected data, and 234 exports the requested IOAM data immediately. The encapsulating 235 IOAM node is the only type of node allowed to set the I-bit. 237 2. A transit node that processes a packet with the I-bit set is 238 expected to export the requested IOAM data, and not incorporate 239 it into the IOAM header. 241 3. A decapsulating IOAM node that processes a packet with the I-bit 242 set is expected to export the requested IOAM data, and 243 decapsulate the IOAM header. 245 Note that in case of "Immediate Export" being employed, no IOAM trace 246 data is added to the packets traversing the network. As a means to 247 support correlation of exported IOAM data different nodes in the 248 network, a deployment could consider attaching an IOAM E2E option in 249 addition to the trace option, that includes a sequence number. See 250 Bit 1 in the IOAM-E2E-Types. Please refer to 251 [I-D.ietf-ippm-ioam-data] for a discussion of IOAM data export and 252 associated formats. 254 7. IANA Considerations 256 IANA is requested to allocate the following bits in the "IOAM Trace 257 Flags Registry" as follows: 259 Bit 1 "Loopback" (L-bit) 261 Bit 2 "Active" (A-bit) 263 Bit 3 "Immediate Export" (I-bit) 265 Note that bit 0 is the most significant bit in the Flags Registry. 267 8. Performance Considerations 269 Each of the three 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. The Immediate Export flag triggers exported 275 packets to be exported to a collector, which in some cases may impact 276 the collector's performance, or the performance along the paths 277 leading to the collector. 279 Each of the three mechanisms has a cost in terms of the network 280 bandwidth, and may potentially load the node that analyzes the data. 281 Therefore, rate limiting may be enabled so as to ensure that the 282 three mechanisms are used at a rate that does not significantly 283 affect the network bandwidth, and does not overload the collector (or 284 the source node in the case of loopback). It should be possible to 285 use each of the three mechanisms on a subset of the data traffic. 287 9. Security Considerations 289 The security considerations of IOAM in general are discussed in 290 [I-D.ietf-ippm-ioam-data]. Specifically, an attacker may try to use 291 the functionality that is defined in this document to attack the 292 network. 294 An attacker may attempt to overload network devices by injecting 295 synthetic packets that include an IOAM Trace Option with one or more 296 of the flags defined in this document. Similarly, an on-path 297 attacker may maliciously set one or more of the flags of transit 298 packets. 300 o Loopback flag: an attacker that sets this flag, either in 301 synthetic packets or transit packet, can potentially cause an 302 amplification, since each device along the path creates a copy of 303 the data packet and sends it back to the source. The attacker can 304 potentially leverage the loopback flag for a Distributed Denial of 305 Service (DDoS) attack, as multiple devices send looped-back copies 306 of a packet to a single source. 308 o Active flag: the impact of synthetic packets with the active flag 309 is no worse than synthetic data packets in which the Active flag 310 is not set. By setting the active flag in en route packets an 311 attacker can prevent these packets from reaching their 312 destination, since the packet is terminated by the decapsulating 313 device; however, note that an on-path attacker may achieve the 314 same goal by changing the destination address of a packet. 315 Another potential threat is amplification; if an attacker causes 316 transit switches to replicate more packets than they are intended 317 to replicate, either by setting the Active flag or by sending 318 synthetic packets, then traffic is amplified, causing bandwidth 319 degredation. 321 o Immediate Export flag: setting this flag, either in synthetic 322 packets or in transit packets may overload the collector or 323 analyzer devices. Since this flag affects multiple devices along 324 the network path, it potentially amplifies the effect on the 325 network bandwidth and on the collector's load. 327 In order to mitigate the attacks described above, it should be 328 possible for IOAM-enabled devices to limit each of the three 329 mechanisms to a configurable rate; Network devices should be able to 330 limit the rate of: (i) looped-back traffic, (ii) replicated active 331 packets, and (iii) exported packets. 333 IOAM is assumed to be deployed in a restricted administrative domain, 334 thus limiting the scope of the threats above and their affect. This 335 is a fundamental assumtion with respect to the security aspects of 336 IOAM, as further discussed in [I-D.ietf-ippm-ioam-data]. 338 10. References 340 10.1. Normative References 342 [I-D.ietf-ippm-ioam-data] 343 Brockners, F., Bhandari, S., Pignataro, C., Gredler, H., 344 Leddy, J., Youell, S., Mizrahi, T., Mozes, D., Lapukhov, 345 P., Chang, R., daniel.bernier@bell.ca, d., and J. Lemon, 346 "Data Fields for In-situ OAM", draft-ietf-ippm-ioam- 347 data-05 (work in progress), March 2019. 349 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 350 Requirement Levels", BCP 14, RFC 2119, 351 DOI 10.17487/RFC2119, March 1997, 352 . 354 10.2. Informative References 356 [I-D.ietf-sfc-ioam-nsh] 357 Brockners, F., Bhandari, S., Govindan, V., Pignataro, C., 358 Gredler, H., Leddy, J., Youell, S., Mizrahi, T., Mozes, 359 D., Lapukhov, P., and R. Chang, "Network Service Header 360 (NSH) Encapsulation for In-situ OAM (IOAM) Data", draft- 361 ietf-sfc-ioam-nsh-01 (work in progress), March 2019. 363 [I-D.ioametal-ippm-6man-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-ioametal-ippm-6man-ioam- 368 ipv6-options-02 (work in progress), March 2019. 370 [I-D.spiegel-ippm-ioam-rawexport] 371 Spiegel, M., Brockners, F., Bhandari, S., and R. 372 Sivakolundu, "In-situ OAM raw data export with IPFIX", 373 draft-spiegel-ippm-ioam-rawexport-01 (work in progress), 374 October 2018. 376 [RFC7799] Morton, A., "Active and Passive Metrics and Methods (with 377 Hybrid Types In-Between)", RFC 7799, DOI 10.17487/RFC7799, 378 May 2016, . 380 Authors' Addresses 382 Tal Mizrahi 383 Huawei Network.IO Innovation Lab 384 Israel 386 Email: tal.mizrahi.phd@gmail.com 388 Frank Brockners 389 Cisco Systems, Inc. 390 Hansaallee 249, 3rd Floor 391 DUESSELDORF, NORDRHEIN-WESTFALEN 40549 392 Germany 394 Email: fbrockne@cisco.com 396 Shwetha Bhandari 397 Cisco Systems, Inc. 398 Cessna Business Park, Sarjapura Marathalli Outer Ring Road 399 Bangalore, KARNATAKA 560 087 400 India 402 Email: shwethab@cisco.com 404 Ramesh Sivakolundu 405 Cisco Systems, Inc. 406 170 West Tasman Dr. 407 SAN JOSE, CA 95134 408 U.S.A. 410 Email: sramesh@cisco.com 412 Carlos Pignataro 413 Cisco Systems, Inc. 414 7200-11 Kit Creek Road 415 Research Triangle Park, NC 27709 416 United States 418 Email: cpignata@cisco.com 419 Aviv Kfir 420 Mellanox Technologies, Inc. 421 350 Oakmead Parkway, Suite 100 422 Sunnyvale, CA 94085 423 U.S.A. 425 Email: avivk@mellanox.com 427 Barak Gafni 428 Mellanox Technologies, Inc. 429 350 Oakmead Parkway, Suite 100 430 Sunnyvale, CA 94085 431 U.S.A. 433 Email: gbarak@mellanox.com 435 Mickey Spiegel 436 Barefoot Networks 437 4750 Patrick Henry Drive 438 Santa Clara, CA 95054 439 US 441 Email: mspiegel@barefootnetworks.com 443 John Lemon 444 Broadcom 445 270 Innovation Drive 446 San Jose, CA 95134 447 US 449 Email: john.lemon@broadcom.com