idnits 2.17.1 draft-ietf-mboned-cbacc-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 == Line 391 has weird spacing: '...-second uin...' -- The document date (March 10, 2020) is 1479 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) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Mboned J. Holland 3 Internet-Draft Akamai Technologies, Inc. 4 Intended status: Standards Track March 10, 2020 5 Expires: September 11, 2020 7 Circuit Breaker Assisted Congestion Control 8 draft-ietf-mboned-cbacc-00 10 Abstract 12 This document specifies Circuit Breaker Assisted Congestion Control 13 (CBACC). CBACC enables fast-trip Circuit Breakers by publishing rate 14 metadata about multicast channels from senders to intermediate 15 network nodes or receivers. The circuit breaker behavior is defined 16 as a supplement to receiver driven congestion control systems, to 17 preserve network health if receivers subscribe to a volume of traffic 18 that exceeds capacity policies or capability for a network or 19 receiver. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at https://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on September 11, 2020. 38 Copyright Notice 40 Copyright (c) 2020 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (https://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 1.1. Background and Terminology . . . . . . . . . . . . . . . 3 57 2. Circuit Breaker Behavior . . . . . . . . . . . . . . . . . . 4 58 2.1. Functional Components . . . . . . . . . . . . . . . . . . 4 59 2.1.1. Ingress Meter . . . . . . . . . . . . . . . . . . . . 4 60 2.1.2. Egress Meter . . . . . . . . . . . . . . . . . . . . 4 61 2.1.3. Communication Method . . . . . . . . . . . . . . . . 5 62 2.1.4. Measurement Function . . . . . . . . . . . . . . . . 5 63 2.1.5. Trigger Function . . . . . . . . . . . . . . . . . . 6 64 2.1.6. Reaction . . . . . . . . . . . . . . . . . . . . . . 7 65 2.1.7. Feedback Control Mechanism . . . . . . . . . . . . . 7 66 2.2. States . . . . . . . . . . . . . . . . . . . . . . . . . 7 67 2.2.1. Interface State . . . . . . . . . . . . . . . . . . . 7 68 2.2.2. Flow State . . . . . . . . . . . . . . . . . . . . . 8 69 2.3. Implementation Design Considerations . . . . . . . . . . 8 70 2.3.1. Oversubscription Thresholds . . . . . . . . . . . . . 8 71 2.3.2. Fairness Functions . . . . . . . . . . . . . . . . . 9 72 3. YANG Module . . . . . . . . . . . . . . . . . . . . . . . . . 9 73 3.1. Tree Diagram . . . . . . . . . . . . . . . . . . . . . . 9 74 3.2. Module . . . . . . . . . . . . . . . . . . . . . . . . . 9 75 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 76 4.1. YANG Module Names Registry . . . . . . . . . . . . . . . 11 77 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 78 5.1. Metadata Security . . . . . . . . . . . . . . . . . . . . 11 79 5.2. Denial of Service . . . . . . . . . . . . . . . . . . . . 11 80 5.2.1. State Overload . . . . . . . . . . . . . . . . . . . 11 81 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 82 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 83 7.1. Normative References . . . . . . . . . . . . . . . . . . 12 84 7.2. Informative References . . . . . . . . . . . . . . . . . 13 85 Appendix A. Overjoining . . . . . . . . . . . . . . . . . . . . 14 86 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 15 88 1. Introduction 90 This document defines Circuit Breaker Assisted Congestion Control 91 (CBACC). CBACC defines a Network Transport Circuit Breaker (CB), as 92 described by [RFC8084]. 94 The CB behavior defined in this document uses bit-rate metadata about 95 multicast data streams, coupled with policy, capacity, and load 96 information at a network node, to prune multicast channels so that 97 the node's aggregate capacity is not exceeded by the subscribed 98 channels. 100 To communicate the required metadata, this document defines a YANG 101 [RFC7950] module that augments the DORMS 102 [I-D.draft-jholland-mboned-dorms-02] YANG module. DORMS provides a 103 mechanism for senders to publish metadata about the multicast streams 104 they're sending through a RESTCONF service, so that receivers or 105 forwarding nodes can discover and consume the metadata with a set of 106 standard methods. The metadata MAY be communicated to receivers or 107 forwarding nodes by some other method, but the definition of any 108 alternative methods is out of scope for this document. 110 The CB behavior defined in this document matches the description 111 provided in Section 3.2.3 of [RFC8084] of a unidirectional CB over a 112 controlled path. The control messages from that description are 113 composed of the messages containing the metadata required for 114 operation of the CB. 116 CBACC is designed to supplement protocols that use multicast IP and 117 rely on well-behaved receivers to achieve congestion control. 118 Examples of congestion control systems fitting this description 119 include [PLM], [RLM], [RLC], [FLID-DL], [SMCC], and WEBRC [RFC3738]. 121 CBACC addresses a problem with "overjoining" by untrusted receivers. 123 In an overjoining condition, receivers (either malicious, 124 misconfigured, or with implementation errors) subscribe to multicast 125 channels but do not respond appropriately to congestion. When 126 sufficient multicast traffic is available for subscription by such 127 receivers, this can overload any network. 129 The overjoining problem is relevant to misbehaving receivers for both 130 receiver-driven and feedback-driven congestion control strategies, as 131 described in Section 4.1 of [RFC8085]. 133 Overjoining attacks and the challenges they present are discussed in 134 more detail in Appendix A. 136 CBACC offers a solution for the recommendation in Section 4 of 137 [RFC8085] that circuit breaker solutions be used even where 138 congestion control is optional. 140 1.1. Background and Terminology 142 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 143 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 144 "OPTIONAL" in this document are to be interpreted as described in BCP 145 14 [RFC2119] [RFC8174] when, and only when, they appear in all 146 capitals, as shown here. 148 2. Circuit Breaker Behavior 150 2.1. Functional Components 152 This section maps the functional components described in Section 3.1 153 of [RFC8084] to the operational components of the CBACC CB defined by 154 this document. 156 2.1.1. Ingress Meter 158 The metadata provides an ingress meter in the form of an advertised 159 maximum data bit-rate, namely the "max-bits-per-second" field in the 160 YANG model in Section 3. This is a self-report by the sender about 161 the maximum amount of traffic a sender will send within the interval 162 given by the "data-rate-window" field, which is the measurement 163 interval. 165 The sender MUST NOT send more data for a data stream than the amount 166 of data implied by its advertised data rate within any measurement 167 window, and it's RECOMMENDED for the sender to provide some margin to 168 account for forwarding bursts. If an egress node observes a higher 169 data rate within any measurement window, it MAY circuit-break that 170 flow immediately. 172 2.1.2. Egress Meter 174 The node implementing the CB behavior has access to several pieces of 175 information that can be used as relevant egress metrics: 177 1. Physical capacity limits on each interface. 179 2. Configured capacity limits for multicast traffic for each 180 interface, if any. 182 3. The observed received data rates of subscribed multicast channels 183 with CBACC metadata. 185 4. The observed received data rates of subscribed multicast channels 186 without CBACC metadata. 188 5. The observed received data rates of competing non-multicast 189 traffic. 191 6. The loss rate for subscribed multicast channels, when available. 192 The loss rate is only sometimes observable at an egress node; for 193 example, when using AMBI [I-D.draft-jholland-mboned-ambi-05], or 194 when the data stream carries a protocol that is known to the 195 egress node by some out of band means, and whose traffic can be 196 monitored for loss. When available, the loss rates may be used. 198 Note that any on-path router can be considered an egress node for 199 purposes of this CB, even though it may be forwarding traffic 200 downstream, and even though other egress points may also be operating 201 a downstream CB that covers the same data stream. Components in the 202 receiving devices, such as an operating system or browser can also 203 act as an egress node, as can a receiving application. 205 2.1.3. Communication Method 207 CBACC operates at an egress node, so the egress metrics in 208 Section 2.1.2 are available through system calls, or by communication 209 with various locally deployable system monitoring applications. Any 210 suitable application that provides the necessary egress meter is 211 appropriate. 213 The communication path defined in this document for the information 214 from the ingress meter is the use of DORMS 215 [I-D.draft-jholland-mboned-dorms-02]. Other methods MAY be used as 216 well, but are out of scope for this document. 218 2.1.4. Measurement Function 220 The measurement function maintains a few values for each interface, 221 computed from the egress and ingress meter values: 223 1. The aggregate advertised maximum bit-rate capacity consumed by 224 CBACC data streams. This is the sum of the max-bit-rate values 225 in the CBACC metadata for all data streams subscribed through an 226 interface 228 2. An oversubscription threshold for each interface. The 229 oversubscription threshold will be determined differently for CBs 230 in different contexts. In some network devices, it might be as 231 simple as an administratively configured absolute value or 232 proportion of an interface's capacity. For other situations, 233 like a CB operating in a context with loss visibility, it could 234 be a dynamically changing value that grows when data streams are 235 successfully subscribed and receiving data without loss, and 236 shrinks as loss is observed across subscribed data streams. The 237 oversubscription threshold calculation could also incorporate 238 other information like out-of-band path capacity measurements 239 with [PathChirp], if available. 241 This document covers some non-normative examples of valid 242 oversubscription threshold functions in Section 2.3.1, but in 243 general, the oversubscription threshold is the primary parameter 244 that different CBs in different contexts can tune to provide the 245 safety guarantees necessary for their context. 247 2.1.5. Trigger Function 249 The trigger function fires when the aggregate advertised maximum bit- 250 rate exceeds the oversubscription threshold for any interface. 252 When oversubscribed, the trigger function changes the states of 253 subscribed channels to "blocked" until the aggregate subscribed bit- 254 rate is below the oversubscription threshold again. 256 2.1.5.1. Fairness and Inter-flow Ordering 258 The trigger function orders the monitored flows according to a 259 fairness function, and blocks flows in order as needed to ensure that 260 only a safe level of bandwidth can be consumed by subscribed flows. 261 The fairness function can be different for CBs in different contexts. 263 Flows from a single sender MUST be ordered according to their 264 priority field from the CBACC metadata when compared with each other. 265 Between-sender flows and flows from the same sender with the same 266 priority are ordered according to the fairness function. Where flows 267 from the same sender have a priority order that conflicts with the 268 ordering the fairness function would use, it's appropriate to treat 269 those out of order flows from the sender as an aggregate flow for 270 between-sender flow comparisons. (TBD: the aggregation algorithm 271 probably needs more explaining and good examples.) 273 A CB implementation SHOULD provide mechanisms for administrative 274 controls to configure explicit biases, as this may be necessary to 275 support Service Level Agreements for specific events or providers, or 276 to blacklist or de-prioritize channels with historically known 277 misbehavior. 279 Subject to the above constraints, where possible the default fairness 280 behavior SHOULD favor streams with many receivers over streams with 281 few receivers, and streams with a low bit-rate over streams with a 282 high bit-rate. For example, when receiver count is known, a good 283 fairness metric is max-bandwidth divided by receiver-count. 284 (Receiver count in some networks can be known through technologies 285 such as the experimental PIM extension for population count described 286 in [RFC6807], or other custom signaling methods.) 287 An overview of some other approaches to appropriate fairness metrics 288 is given in Section 2.3 of [RFC5166]. 290 2.1.6. Reaction 292 When the trigger function fires and a subscribed channel becomes 293 blocked, the reaction depends on whether it's an upstream interface 294 or a downstream interface. 296 If a channel is blocked on one downstream interface, it may still be 297 unblocked on other downstream interfaces. When this is the case, 298 traffic is simply not forwarded along blocked interfaces, even though 299 clients might still be joined. 301 When a channel is blocked on all downstream interfaces, or when the 302 upstream interface is oversubscribed, the channel is pruned so that 303 data no longer arrives from the network on the upstream interface, by 304 a PIM prune (Section 3.5 of [RFC7761]), or a "leave" operation with 305 IGMP, MLD, or another multicast signaling mechanism. 307 Once initially circuit-broken, a flow SHOULD remain circuit-broken 308 for no less than 3 minutes, even if space clears up, to ensure 309 downstream subscriptions will notice and respond. (3 minutes is 310 chosen to exceed the default maximum lifetime of 2 minutes that can 311 occur if an IGMP responder suddenly stops operation, and ceases 312 responding to IGMP queries with membership reports.) 314 When enough capacity is available for a circuit-broken stream to be 315 unblocked and the circuit-breaker hold-down time is expired, the 316 flows SHOULD be unblocked according to the priority order. 318 2.1.7. Feedback Control Mechanism 320 The metadata should be refreshed as needed to maintain up to date 321 values. When using DORMS and RESTCONF, the HTTP Cache Control 322 headers provide valid refresh time properties from the server, and 323 SHOULD be used if present. If No-Cache is used, the default refresh 324 timing SHOULD be 30 seconds plus a random value between 0 and 10 325 seconds. 327 2.2. States 329 2.2.1. Interface State 331 A CB holds the following state for each interface, for both the 332 inbound and outbound directions on that interface: 334 o aggregate bandwidth: The sum of the bandwidths of all non- 335 circuit-broken CBACC flows which transit this interface in this 336 direction. 338 o bandwidth limit: The maximum aggregate CBACC advertised bandwidth 339 allowed, not including circuit-broken flows. 341 When reducing the bandwidth limit due to congestion, the circuit 342 breaker SHOULD NOT reduce the limit by more than half its value in 343 10 seconds, and SHOULD use a smoothing function to reduce the 344 limit gradually over time. 346 It is RECOMMENDED that no more than half the capacity for a link 347 be allocated to CBACC flows if the link might be shared with TCP 348 or other traffic that is responsive to congestion. 350 2.2.2. Flow State 352 Data streams with CBACC metadata have a state for the upstream 353 interface through which the stream is joined: 355 o 'subscribed' Indicates that the circuit breaker is subscribed 356 upstream to the flow and forwarding packets through zero or more 357 egress interfaces. 359 o 'pruned' Indicates that the flow has been circuit-broken. A 360 request to unsubscribe from the flow has been sent upstream, e.g. 361 a PIM prune (Section 3.5 of [RFC7761]) or a "leave" operation via 362 IGMP, MLD, or another group membership management mechanism. 364 Data streams also have a per-interface state for downstream 365 interfaces with subscribers, where the data is being forwarded. It's 366 one of: 368 o 'forwarding' Indicates that the flow is a non-circuit-broken flow 369 in steady state, forwarding packets downstream. 371 o 'blocked' Indicates that data packets for this flow are NOT 372 forwarded downstream via this interface. 374 2.3. Implementation Design Considerations 376 2.3.1. Oversubscription Thresholds 378 TBD. 380 2.3.2. Fairness Functions 382 TBD. 384 3. YANG Module 386 3.1. Tree Diagram 388 module: ietf-cbacc 389 augment /dorms:metadata/dorms:sender/dorms:group/dorms:udp-stream: 390 +--rw cbacc! 391 +--rw max-bits-per-second uint32 392 +--rw max-mss? uint16 393 +--rw data-rate-window? uint32 394 +--rw priority? uint16 396 3.2. Module 398 file ietf-cbacc@2020-03-10.yang 399 module ietf-cbacc { 400 yang-version 1.1; 402 namespace "urn:ietf:params:xml:ns:yang:ietf-cbacc"; 403 prefix "ambi"; 405 import ietf-dorms { 406 prefix "dorms"; 407 reference "I-D.jholland-mboned-dorms"; 408 } 410 organization "IETF"; 412 contact 413 "Author: Jake Holland 414 415 "; 417 description 418 "Copyright (c) 2019 IETF Trust and the persons identified as 419 authors of the code. All rights reserved. 421 Redistribution and use in source and binary forms, with or 422 without modification, is permitted pursuant to, and subject to 423 the license terms contained in, the Simplified BSD License set 424 forth in Section 4.c of the IETF Trust's Legal Provisions 425 Relating to IETF Documents 426 (https://trustee.ietf.org/license-info). 428 This version of this YANG module is part of 429 draft-jholland-mboned-cbacc. See the internet draft for full 430 legal notices. 432 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL 433 NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED', 434 'MAY', and 'OPTIONAL' in this document are to be interpreted as 435 described in BCP 14 (RFC 2119) (RFC 8174) when, and only when, 436 they appear in all capitals, as shown here. 438 This module contains the definition for bandwidth consumption 439 metadata for SSM channels, as an extension to DORMS 440 (draft-jholland-mboned-dorms)."; 442 revision 2019-09-26 { 443 description "Initial revision as an extension."; 444 reference 445 ""; 446 } 448 augment 449 "/dorms:metadata/dorms:sender/dorms:group/dorms:udp-stream" { 450 description "Definition of the manifest stream providing 451 integrity info for the data stream"; 453 container cbacc { 454 presence "cbacc-enabled flow"; 455 description "Information to enable fast-trip circuit breakers"; 456 leaf max-bits-per-second { 457 type uint32; 458 mandatory true; 459 description "Maximum bitrate for this stream, in Kilobits 460 of IP packet data (including headers) of native 461 multicast traffic per second"; 462 } 463 leaf max-mss { 464 type uint16; 465 default 1400; 466 description "Maximum payload size, in bytes"; 467 } 468 leaf data-rate-window { 469 type uint32; 470 default 2000; 471 description "Time window over which data rate is guaranteed, 472 in milliseconds."; 473 /* TBD: range limits? */ 474 } 475 leaf priority { 476 type uint16; 477 default 256; 478 description "The relative preference level for keeping this 479 flow compared to other flows from this sender (higher 480 value is more preferred to keep)"; 481 } 482 } 483 } 484 } 486 488 4. IANA Considerations 490 4.1. YANG Module Names Registry 492 This document adds one YANG module to the "YANG Module Names" 493 registry maintained at . The following registrations are made, per the format in 495 Section 14 of [RFC6020]: 497 name: ietf-cbacc 498 namespace: urn:ietf:params:xml:ns:yang:ietf-cbacc 499 prefix: cbacc 500 reference: I-D.draft-jholland-mboned-cbacc 502 5. Security Considerations 504 5.1. Metadata Security 506 Be sure to authenticate the metadata. See DORMS security 507 considerations, and don't accept unauthenticated metadata if using an 508 alternative means. 510 5.2. Denial of Service 512 5.2.1. State Overload 514 Since CBACC flows require state, it may be possible for a set of 515 receivers and/or senders, possibly acting in concert, to generate 516 many flows in an attempt to overflow the circuit breakers' state 517 tables. 519 It is permissible for a network node to behave as a CBACC circuit 520 breaker for some CBACC flows while treating other CBACC flows as non- 521 CBACC, as part of a load balancing strategy for the network as a 522 whole, or simply as defense against this concern when the number of 523 monitored flows exceeds some threshold. 525 The same techniques described in Section 3.1 of [RFC4609] can be used 526 to help mitigate this attack, for much the same reasons. It is 527 RECOMMENDED that network operators implement measures to mitigate 528 such attacks. 530 6. Acknowledgements 532 Many thanks to Devin Anderson, Ben Kaduk, Cheng Jin, Scott Brown, 533 Miroslav Ponec, Bob Briscoe, Lenny Giuliani, and Christian Worm 534 Mortensen for their thoughtful comments and contributions. 536 7. References 538 7.1. Normative References 540 [I-D.draft-jholland-mboned-ambi-05] 541 Holland, J. and K. Rose, "Asymmetric Manifest Based 542 Integrity", draft-jholland-mboned-ambi-05 (work in 543 progress), March 2020. 545 [I-D.draft-jholland-mboned-dorms-02] 546 Holland, J., "Discovery Of Restconf Metadata for Source- 547 specific multicast", draft-jholland-mboned-dorms-02 (work 548 in progress), March 2020. 550 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 551 Requirement Levels", BCP 14, RFC 2119, 552 DOI 10.17487/RFC2119, March 1997, 553 . 555 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 556 RFC 7950, DOI 10.17487/RFC7950, August 2016, 557 . 559 [RFC8084] Fairhurst, G., "Network Transport Circuit Breakers", 560 BCP 208, RFC 8084, DOI 10.17487/RFC8084, March 2017, 561 . 563 [RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage 564 Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, 565 March 2017, . 567 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 568 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 569 May 2017, . 571 7.2. Informative References 573 [FLID-DL] Byers, J., Horn, G., Luby, M., Mitzenmacher, M., Shaver, 574 W., and IEEE, "FLID-DL: congestion control for layered 575 multicast", DOI 10.1109/JSAC.2002.803998, n.d., 576 . 578 [PathChirp] 579 Ribeiro, V., Riedi, R., Baraniuk, R., Navratil, J., 580 Cottrell, L., Department of Electrical and Computer 581 Engineering Rice University, and SLAC/SCS-Network 582 Monitoring, Stanford University, "pathChirp: Efficient 583 Available Bandwidth Estimation for Network Paths", 2003. 585 [PLM] Biersack, Institut EURECOM, A., "PLM: Fast Convergence for 586 Cumulative Layered Multicast Transmission Schemes", 1999. 588 [RFC3738] Luby, M. and V. Goyal, "Wave and Equation Based Rate 589 Control (WEBRC) Building Block", RFC 3738, 590 DOI 10.17487/RFC3738, April 2004, 591 . 593 [RFC4609] Savola, P., Lehtonen, R., and D. Meyer, "Protocol 594 Independent Multicast - Sparse Mode (PIM-SM) Multicast 595 Routing Security Issues and Enhancements", RFC 4609, 596 DOI 10.17487/RFC4609, October 2006, 597 . 599 [RFC5166] Floyd, S., Ed., "Metrics for the Evaluation of Congestion 600 Control Mechanisms", RFC 5166, DOI 10.17487/RFC5166, March 601 2008, . 603 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 604 the Network Configuration Protocol (NETCONF)", RFC 6020, 605 DOI 10.17487/RFC6020, October 2010, 606 . 608 [RFC6807] Farinacci, D., Shepherd, G., Venaas, S., and Y. Cai, 609 "Population Count Extensions to Protocol Independent 610 Multicast (PIM)", RFC 6807, DOI 10.17487/RFC6807, December 611 2012, . 613 [RFC7761] Fenner, B., Handley, M., Holbrook, H., Kouvelas, I., 614 Parekh, R., Zhang, Z., and L. Zheng, "Protocol Independent 615 Multicast - Sparse Mode (PIM-SM): Protocol Specification 616 (Revised)", STD 83, RFC 7761, DOI 10.17487/RFC7761, March 617 2016, . 619 [RLC] Rizzo, L., Vicisano, L., and J. Crowcroft, "The RLC 620 multicast congestion control algorithm", 1999. 622 [RLM] McCanne, S., Jacobson, V., Vetterli, M., University of 623 California, Berkeley, and Lawrence Berkeley National 624 Laboratory, "Receiver-driven Layered Multicast", 1995. 626 [SMCC] Kwon, G., Byers, J., and Computer Science Department, 627 Boston University, "Smooth Multirate Multicast Congestion 628 Control", 2002. 630 Appendix A. Overjoining 632 [RFC8085] describes several remedies for unicast congestion control 633 under UDP, even though UDP does not itself provide congestion 634 control. In general, any network node under congestion could in 635 theory collect evidence that a unicast flow's sending rate is not 636 responding to congestion, and would then be justified in circuit- 637 breaking it. 639 With multicast IP, the situation is different, especially in the 640 presence of malicious receivers. A well-behaved sender using a 641 receiver-controlled congestion scheme such as WEBRC does not reduce 642 its send rate in response to congestion, instead relying on receivers 643 to leave the appropriate multicast groups. 645 This leads to a situation where, when a network accepts inter-domain 646 multicast traffic, as long as there are senders somewhere in the 647 world with aggregate bandwidth that exceeds a network's capacity, 648 receivers in that network can join the flows and overflow the network 649 capacity. A receiver controlled by an attacker could do this at the 650 IGMP/MLD level without running the application layer protocol that 651 participates in the receiver-controlled congestion control. 653 A network might be able to detect and defend against the most naive 654 version of such an attack by blocking end users that try to join too 655 many flows at once. However, an attacker can achieve the same effect 656 by joining a few high-bandwidth flows, if those exist anywhere, and 657 an attacker that controls a few machines in a network can coordinate 658 the receivers so they join disjoint sets of non-responsive sending 659 flows. 661 This scenario will produce congestion in a middle node in the network 662 that can't be easily detected at the edge where the IGMP/MLD join is 663 accepted. Thus, an attacker with a small set of machines in a target 664 network can always trip a circuit breaker if present, or can induce 665 excessive congestion among the bandwidth allocated to multicast. 666 This problem gets worse as more multicast flows become available. 668 Although the same can apply to non-responsive unicast traffic, 669 network operators can assume that non-responsive sending flows are in 670 violation of congestion control best practices, and can therefore cut 671 off flows associated with the misbehaving senders. By contrast, non- 672 responsive multicast senders are likely to be well-behaved 673 participants in receiver-controlled congestion control schemes. 675 However, receiver controlled congestion control schemes also show the 676 most promise for efficient massive scale content distribution via 677 multicast, provided network health can be ensured. Therefore, 678 mechanisms to mitigate overjoining attacks while still permitting 679 receiver-controlled congestion control are necessary. 681 Author's Address 683 Jake Holland 684 Akamai Technologies, Inc. 685 150 Broadway 686 Cambridge, MA 02144 687 United States of America 689 Email: jakeholland.net@gmail.com