idnits 2.17.1 draft-ietf-mboned-ambi-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 906 has weird spacing: '...-rw uri ine...' == Line 916 has weird spacing: '...-rw uri ine...' -- The document date (7 March 2022) is 775 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 (-04) exists of draft-ietf-mboned-dorms-01 ** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147) ** Obsolete normative reference: RFC 7230 (Obsoleted by RFC 9110, RFC 9112) == Outdated reference: A later version (-32) exists of draft-ietf-tsvwg-udp-options-15 Summary: 2 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Mboned J. Holland 3 Internet-Draft K. Rose 4 Intended status: Standards Track Akamai Technologies, Inc. 5 Expires: 8 September 2022 7 March 2022 7 Asymmetric Manifest Based Integrity 8 draft-ietf-mboned-ambi-03 10 Abstract 12 This document defines Asymmetric Manifest-Based Integrity (AMBI). 13 AMBI allows each receiver or forwarder of a stream of multicast 14 packets to check the integrity of the contents of each packet in the 15 data stream. AMBI operates by passing cryptographically verifiable 16 hashes of the data packets inside manifest messages, and sending the 17 manifests over authenticated out-of-band communication channels. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at https://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on 8 September 2022. 36 Copyright Notice 38 Copyright (c) 2022 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 43 license-info) in effect on the date of publication of this document. 44 Please review these documents carefully, as they describe your rights 45 and restrictions with respect to this document. Code Components 46 extracted from this document must include Revised BSD License text as 47 described in Section 4.e of the Trust Legal Provisions and are 48 provided without warranty as described in the Revised BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 53 1.1. Comparison with TESLA . . . . . . . . . . . . . . . . . . 4 54 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 55 1.3. Notes for Contributors and Reviewers . . . . . . . . . . 4 56 1.3.1. Venues for Contribution and Discussion . . . . . . . 5 57 1.3.2. Non-obvious doc choices . . . . . . . . . . . . . . . 5 58 2. Threat Model . . . . . . . . . . . . . . . . . . . . . . . . 6 59 2.1. Security Anchors . . . . . . . . . . . . . . . . . . . . 6 60 2.1.1. Alternatives and Their Requirements . . . . . . . . . 7 61 2.2. System Security . . . . . . . . . . . . . . . . . . . . . 8 62 3. Protocol Operation . . . . . . . . . . . . . . . . . . . . . 8 63 3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 8 64 3.2. Buffering of Packets and Digests . . . . . . . . . . . . 9 65 3.2.1. Validation Windows . . . . . . . . . . . . . . . . . 10 66 3.2.2. Preserving Inter-packet Gap . . . . . . . . . . . . . 11 67 3.3. Packet Digests . . . . . . . . . . . . . . . . . . . . . 11 68 3.3.1. Digest Profile . . . . . . . . . . . . . . . . . . . 11 69 3.3.2. Pseudoheader . . . . . . . . . . . . . . . . . . . . 13 70 3.4. Manifests . . . . . . . . . . . . . . . . . . . . . . . . 14 71 3.4.1. Manifest Layout . . . . . . . . . . . . . . . . . . . 14 72 3.5. Transitioning to Other Manifest Streams . . . . . . . . . 18 73 4. Transport Considerations . . . . . . . . . . . . . . . . . . 18 74 4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 18 75 4.2. HTTPS . . . . . . . . . . . . . . . . . . . . . . . . . . 19 76 4.3. TLS . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 77 4.4. DTLS . . . . . . . . . . . . . . . . . . . . . . . . . . 19 78 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 20 79 6. YANG Module . . . . . . . . . . . . . . . . . . . . . . . . . 20 80 6.1. Tree Diagram . . . . . . . . . . . . . . . . . . . . . . 20 81 6.2. Module . . . . . . . . . . . . . . . . . . . . . . . . . 20 82 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 83 7.1. The YANG Module Names Registry . . . . . . . . . . . . . 24 84 7.2. The XML Registry . . . . . . . . . . . . . . . . . . . . 24 85 7.3. Media Type . . . . . . . . . . . . . . . . . . . . . . . 24 86 7.4. URI Schemes . . . . . . . . . . . . . . . . . . . . . . . 25 87 7.4.1. TLS . . . . . . . . . . . . . . . . . . . . . . . . . 25 88 7.4.2. DTLS . . . . . . . . . . . . . . . . . . . . . . . . 25 89 8. Security Considerations . . . . . . . . . . . . . . . . . . . 25 90 8.1. Predictable Packets . . . . . . . . . . . . . . . . . . . 25 91 8.2. Attacks on Side Applications . . . . . . . . . . . . . . 25 92 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26 93 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 26 94 10.1. Normative References . . . . . . . . . . . . . . . . . . 26 95 10.2. Informative References . . . . . . . . . . . . . . . . . 27 96 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29 98 1. Introduction 100 Multicast transport poses security problems that are not easily 101 addressed by the same security mechanisms used for unicast transport. 103 The "Introduction" sections of the documents describing TESLA 104 [RFC4082], and TESLA in SRTP [RFC4383], and TESLA with ALC and NORM 105 [RFC5776] present excellent overviews of the challenges unique to 106 multicast authentication for use cases like wide scale software or 107 video distribution with a high data transfer rate. The challenges 108 are briefly summarized here: 110 * A MAC based on a symmetric shared secret cannot be used because 111 each packet has multiple receivers that do not trust each other, 112 and using a symmetric shared secret exposes the same secret to 113 each receiver. 115 * Asymmetric per-packet signatures can handle only very low bit- 116 rates because of the transport and computational overhead 117 associated with signature transmission and verification. 119 * An asymmetric signature of a larger message comprising multiple 120 packets requires reliable receipt of all such packets, something 121 that cannot be guaranteed in a timely manner even for protocols 122 that do provide reliable delivery, and the retransmission of which 123 may anyway exceed the useful lifetime for data formats that can 124 otherwise tolerate some degree of loss. 126 Aymmetric Manifest-Based Integrity (AMBI) defines a method for 127 receivers or middle boxes to cryptographically authenticate and 128 verify the integrity of a stream of packets by comparing the data 129 packets to a stream of packet "manifests" (described in Section 3.4) 130 received via an out-of-band communication channel that provides 131 authentication and verifiable integrity. 133 Each manifest contains a message digest (described in Section 3.3) 134 for each packet in a sequence of packets from the data stream, 135 hereafter called a "packet digest". The packet digest incorporates a 136 cryptographic hash of the packet contents and some identifying data 137 from the packet, according to a defined digest profile for the data 138 stream. 140 Upon receipt of a packet digest inside a manifest conveyed in a 141 secure channel and verification that the packet digest of a received 142 data packet matches, the receiver has proof of the integrity of the 143 contents of the data packet corresponding to that digest. 145 This document defines the "ietf-ambi" YANG [RFC7950] model in 146 Section 6 as an extension of the "ietf-dorms" model defined in 147 [I-D.draft-ietf-mboned-dorms]. Also defined are new URI schemes for 148 transport of manifests over TLS or DTLS, and a new media type for 149 transport of manifests over HTTPS. The encodings for these are 150 defined in Section 4. 152 1.1. Comparison with TESLA 154 AMBI and TESLA [RFC4082] and [RFC5776] attempt to achieve a similar 155 goal of authenticating the integrity of streams of multicast packets. 156 AMBI imposes a higher overhead than TESLA imposes, as measured in the 157 amount of extra data required. In exchange, AMBI relaxes the 158 requirement for establishing an upper bound on clock synchronization 159 between sender and receiver, and allows for the use case of 160 authenticating multicast traffic before forwarding it through the 161 network, while also allowing receivers to authenticate the same 162 traffic. By contrast, this is not possible with TESLA because the 163 data packets can't be authenticated until a key is disclosed, so 164 either the middlebox has to forward data packets without first 165 authenticating them so that the receiver has them prior to key 166 disclosure, or the middlebox has to hold packets until the key is 167 disclosed, at which point the receiver can no longer establish their 168 authenticity. 170 The other new capability is that because AMBI provides authentication 171 information out of band, authentication can be retrofitted into some 172 pre-existing deployments without changing the protocol of the data 173 packets under some restrictions outlined in Section 8. By contrast, 174 TESLA requires a MAC to be added to each authenticated message. 176 1.2. Terminology 178 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 179 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 180 "OPTIONAL" in this document are to be interpreted as described in 181 [RFC2119] and [RFC8174] when, and only when, they appear in all 182 capitals, as shown here. 184 1.3. Notes for Contributors and Reviewers 186 Note to RFC Editor: Please remove this section and its subsections 187 before publication. 189 This section is to provide references to make it easier to review the 190 development and discussion on the draft so far. 192 1.3.1. Venues for Contribution and Discussion 194 This document is in the Github repository at: 196 https://github.com/GrumpyOldTroll/ietf-dorms-cluster 197 (https://github.com/GrumpyOldTroll/ietf-dorms-cluster) 199 Readers are welcome to open issues and send pull requests for this 200 document. 202 Please note that contributions may be merged and substantially 203 edited, and as a reminder, please carefully consider the Note Well 204 before contributing: https://datatracker.ietf.org/submit/note-well/ 205 (https://datatracker.ietf.org/submit/note-well/) 207 Substantial discussion of this document should take place on the 208 MBONED working group mailing list (mboned@ietf.org). 210 * Join: https://www.ietf.org/mailman/listinfo/mboned 211 (https://www.ietf.org/mailman/listinfo/mboned) 213 * Search: https://mailarchive.ietf.org/arch/browse/mboned/ 214 (https://mailarchive.ietf.org/arch/browse/mboned/) 216 1.3.2. Non-obvious doc choices 218 * TBD: we need a way to assert that we provide the full set of 219 packets for an (S,G) on all UDP ports and non-UDP protocols. 220 Naively authenticating UDP for specified ports and ignoring other 221 ports means that an attacker could attack a separate UDP port by 222 injecting traffic directed at it, potentially hitting a different 223 application that listens on 0.0.0.0, so an (S,G) with legitimately 224 authenticated UDP traffic on one port could be used to transport 225 UDP-based attacks to apps on another port or protocol unless they 226 are firewalled. Passing traffic for an (S,G) subscription would 227 open a new channel to such targets that otherwise would not be 228 reachable from the internet for users behind e.g. a CPE with nat 229 or connection-state-based firewalling. 231 * Dropped intent to support DTLS+FECFRAME in this spec because RFC 232 6363 seems incomprehensible on a few points, most notably demux 233 strategy between repair and source ADUs, which as written seems to 234 require specifying another layer. So support for this will have 235 to be a later separate RFC. However, for future extensibility 236 made manifest-stream into a list instead of a leaf-list so that it 237 can be an augment target for a later YANG extension with FEC 238 selection from the likewise-very-confusing semi-overlapping 239 registries at https://www.iana.org/assignments/rmt-fec-parameters/ 240 rmt-fec-parameters.xhtml (https://www.iana.org/assignments/rmt- 241 fec-parameters/rmt-fec-parameters.xhtml) defined by RFCs 5052 and 242 6363. See also RFC 6363, RFC 6681, and RFC 6865 244 2. Threat Model 246 AMBI is designed to operate over the internet, under the Internet 247 Threat Model described in [RFC3552]. 249 AMBI aims to provide Data Integrity for a multicast data stream, 250 building on the security anchors described in Section 2.1 to do so. 251 The aim is to enable receivers to subscribe to and receive multicast 252 packets from a trusted sender without damage to the Systems Security 253 (Section 2.3 of [RFC3552]) for those receivers or other entities. 255 Thus, we assume there might be attackers on-path or off-path with the 256 capability to inject or modify packets, but that the attackers have 257 not compromised the sender or discovered any of the sender's secret 258 keys. We assume that an attacker may have compromised some receivers 259 of the multicast traffic, but still aim to provide the above security 260 properties for receivers that have not been compromised. 262 Those sending multicast traffic to receivers that include untrusted 263 receivers should avoid transmitting sensitive information that 264 requires strong confidentiality guarantees, due to the risk of 265 compromise from those receivers. Since multicast transmits the same 266 packets to potentially many receivers, in the presence of potentially 267 compromised receivers confidentiality of the content cannot be 268 assured. 270 However, any protocol that provides encryption of the packet data 271 before generating the packet digest can provide confidentiality 272 against on-path passive observers who do not possess the decryption 273 key. This level of confidentiality can be provided by any such 274 protocols without impact on AMBI's operation. 276 2.1. Security Anchors 278 Establishing the desired security properties for the multicast data 279 packets relies on secure delivery of some other information: 281 * Secured unicast connections (providing Data Integrity) to one or 282 more trusted DORMS [I-D.draft-ietf-mboned-dorms] servers that use 283 the AMBI extensions to the DORMS YANG model as defined in 284 Section 6 286 * Secure delivery (providing Data Integrity) of a stream of 287 manifests (Section 3.4) 289 The secured unicast connection to the DORMS server provides the Peer 290 Entity authentication of the DORMS server that's needed to establish 291 the Data Integrity of the data it sends. 293 Note that DORMS provides a method for using DNS to bootstrap 294 discovery of the DORMS server. In contexts where secure DNS lookup 295 cannot be provided, it's still possible to establish a secure 296 connection to a trusted DORMS server as long as the trusted DORMS 297 server's hostname is known to the receivers (removing the need to use 298 DNS for that discovery). Once the server name is known, the ordinary 299 certificate verification of that hostname while establishing a secure 300 https connection provides the needed security properties to anchor 301 the rest. 303 Receiving unauthenticated data packets and knowing how to generate 304 packet digests from the manifest profile provided by the AMBI 305 extensions in the DORMS metadata allows the receiver to generate 306 packet digests based on the contents of the received packet, which 307 can be compared against the packet digests that were securely 308 received. 310 Comparing the digests and finding the same answer then provides Data 311 Integrity for the data packets that relies on one more property of 312 the digest generation algorithm: 314 * the difficulty of generating a collision for the packet digests 315 contained in the manifest. 317 Taken together, successful validation of the multicast data packets 318 proves within the above constraints that someone with control of the 319 manifest URI streams provided by the DORMS server has verified the 320 sending of the packets corresponding to the digests sent in that 321 stream of manifests. 323 2.1.1. Alternatives and Their Requirements 325 Other protocols that can provide authentication could also be used 326 for manifest delivery if defined later in another specification. For 327 example a protocol that asymmetrically signs each packet, as the one 328 defined in Section 3 of [RFC6584] does, would be a viable candidate 329 for a delivery protocol for manifests that could be delivered over a 330 multicast transport, which could have some important scalability 331 benefits. 333 Other methods of securely transmitting metadata equivalent to the 334 metadata provided by the "ietf-ambi" YANG model could also be used to 335 provide the same security guarantees with the manifest channels. 336 Defining other such possibilities is out of scope for this document. 338 2.2. System Security 340 By providing the means to authenticate multicast packets, AMBI aims 341 to avoid giving attackers who can inject or modify packets the 342 ability to attack application vulnerabilities that might be possible 343 to exercise if those applications process the attack traffic. Many 344 of the entries in the Common Vulnerabilities and Exposures (CVE) list 345 at [CVE] (an extensive industry-wide database of software 346 vulnerabilities) have documented a variety of system security 347 problems that can result from maliciously generated UDP packets. 349 TBD: Fold in a mention of how off-path attacks are possible from most 350 places on the internet for interdomain multicast over AMT at an 351 ingest point, and how the multicast fanout downstream of that can 352 make it a good target if multicast sees more use. A diagram plus a 353 cleaned-up version of the on-list explanation here is probably 354 appropriate: https://mailarchive.ietf.org/arch/msg/mboned/ 355 CG9FLjPwuno3MtvYvgNcD5p69I4/ 356 (https://mailarchive.ietf.org/arch/msg/mboned/ 357 CG9FLjPwuno3MtvYvgNcD5p69I4/). Nightmare scenario is zero-day RCE by 358 off-path attacker that takes over a significant number of the devices 359 watching a major sports event. 361 See also work-in-progress: https://squarooticus.github.io/draft- 362 krose-multicast-security/draft-krose-multicast-security.html 363 (https://squarooticus.github.io/draft-krose-multicast-security/draft- 364 krose-multicast-security.html) 366 3. Protocol Operation 368 3.1. Overview 370 In order to authenticate a data packet, AMBI receivers need to hold 371 these three pieces of information at the same time: 373 * the data packet 375 * an authenticated manifest containing the packet digest for the 376 data packet 378 * a digest profile defining the transformation from the data packet 379 to its packet digest 381 The manifests are delivered as a stream of manifests over an 382 authenticated data channel. Manifest contents MUST be authenticated 383 before they can be used to authenticate data packets. 385 The manifest stream is composed of an ordered sequence of manifests 386 that each contain an ordered sequence of packet digests, 387 corresponding to the original packets as sent from their origin, in 388 the same order. 390 Note that a manifest contains potentially many packet digests, and 391 its size can be tuned to fit within a convenient PDU (Protocol Data 392 Unit) of the manifest transport stream. By doing so, many packet 393 digests for the multicast data stream can be delivered per packet of 394 the manifest transport. The intent is that even with unicast-based 395 manifest transport, multicast-style efficiencies of scale can still 396 be realized with only a relatively small unicast overhead, when 397 manifests use a unicast transport. 399 3.2. Buffering of Packets and Digests 401 Using different communication channels for the manifest stream and 402 the data stream introduces a possibility of desynchronization in the 403 timing of the received data between the different channels, so 404 receivers hold data packets and packet digests from the manifest 405 stream in buffers for some duration while awaiting the arrival of 406 their counterparts. 408 While holding a data packet, if the corresponding packet digest for 409 that packet arrives in the secured manifest stream, the data packet 410 is authenticated. 412 While holding an authenticated packet digest, if the corresponding 413 data packet arrives with a matching packet digest, the data packet is 414 authenticated. 416 Authenticating a data packet consumes one packet digest and prevents 417 re-learning a digest for the same sequence number with a hold-down 418 time equal to the hold time for packet digests. The hold-down is 419 necessary because a different manifest can send a duplicate packet 420 digest for the same packet sequence number, either when repeating of 421 packet digests is used for resilience to loss or when rotating 422 authentication keys, so re-learning the packet digest could allow a 423 replay of a data packet. After authenticating a packet, the digest 424 and any future digests for the same data packet remain consumed if it 425 has been used to authenticate a data packet, ignoring repeated 426 digests for the same sequence number until after the holddown timer 427 expires. 429 Once the data packet is authenticated it can be further processed by 430 the receiving application or forwarded through the receiving network. 432 If the receiver's hold duration for a data packet expires without 433 authenticating the packet, the packet SHOULD be dropped as 434 unauthenticated. If the hold duration of a manifest expires, packet 435 digests last received in that manifest MUST be discarded. 437 When multiple digests for the same packet sequence number are 438 received, the latest received time for an authenticated packet digest 439 should be used for the expiration time. 441 3.2.1. Validation Windows 443 Since packet digests are usually smaller than the data packets, it's 444 RECOMMENDED that senders generate and send manifests with timing such 445 that the packet digests in a manifest will typically be received by 446 subscribed receivers before the data packets corresponding to those 447 digests are received. 449 This strategy reduces the buffering requirements at receivers, at the 450 cost of introducing some buffering of data packets at the sender, 451 since data packets are generated before their packet digests can be 452 added to manifests. 454 The RECOMMENDED default hold times at receivers are: 456 * 2 seconds for data packets 458 * 10 seconds for packet digests 460 The sender MAY recommend different values for specific data streams, 461 in order to tune different data streams for different performance 462 goals. The YANG model in Section 6 provides a mechanism for senders 463 to communicate the sender's recommendation for buffering durations. 464 These parameters are "data-hold-time" and "digest-hold-time", 465 expressed in milliseconds. 467 Receivers MAY deviate from the values recommended by the sender for a 468 variety of reasons, including their own memory constraints or local 469 administrative configuration (for example, it might improve user 470 experience in some situations to hold packets longer than the server 471 recommended when there are receiver-specific delays in the manifest 472 stream that exceed the server's expectations). Decreasing the 473 buffering durations recommended by the server increases the risk of 474 losing packets, but can be an appropriate tradeoff for specific 475 network conditions and hardware or memory constraints on some 476 devices. 478 Receivers SHOULD follow the recommendations for hold times provided 479 by the sender (including the default values from the YANG model when 480 unspecified), subject to their capabilities and any administratively 481 configured overrides at the receiver. 483 3.2.2. Preserving Inter-packet Gap 485 It's RECOMMENDED that middle boxes forwarding buffered data packets 486 preserve the inter-packet gap between packets in the same data 487 stream, and that receiving libraries that perform AMBI-based 488 authentication provide mechanisms to expose the network arrival times 489 of packets to applications. 491 The purpose for this recommendation is to preserve the capability of 492 receivers to use techniques for available bandwidth detection or 493 network congestion based on observation of packet times and packet 494 dispersal, making use of known patterns in the sending. Examples of 495 such techniques include those described in [PathChirp], [PathRate], 496 and [WEBRC]. 498 Note that this recommendation SHOULD NOT prevent the transmission of 499 an authenticated packet because the prior packet is unauthenticated. 500 This recommendation only asks implementations to delay the 501 transmission of an authenticated packet to correspond to the 502 interpacket gap if an authenticated packet was previously transmitted 503 and the authentication of the subsequent packet would otherwise burst 504 the packets more quickly. 506 This does not prevent the transmission of packets out of order 507 according to their order of authentication, only the timing of 508 packets that are transmitted, after authentication, in the same order 509 they were received. 511 For receiver applications, the time that the original packet was 512 received from the network SHOULD be made available to the receiving 513 application. 515 3.3. Packet Digests 517 3.3.1. Digest Profile 519 A packet digest is a message digest for a data packet, built 520 according to a digest profile defined by the sender. 522 The digest profile is defined by the sender, and specifies: 524 1. A cryptographically secure hash algorithm (REQUIRED) 525 2. A manifest stream identifier 527 3. Whether to hash the IP payload or the UDP payload. (see 528 Section 3.3.1.1) 530 The hash algorithm is applied to a pseudoheader followed by the 531 packet payload, as determined by the digest profile. The computed 532 hash value is the packet digest. 534 TBD: As recommended by https://tools.ietf.org/html/rfc7696#section- 535 2.2 (https://tools.ietf.org/html/rfc7696#section-2.2), a companion 536 document containing the mandatory-to-implement cipher suite should 537 also be published separately and referenced by this document. 539 3.3.1.1. Payload Type 541 3.3.1.1.1. UDP vs. IP payload validation 543 When the manifest definition is at the UDP layer, it applies only to 544 packets with IP protocol of UDP (0x11) and the payload used for 545 calculating the packet digest includes only the UDP payload with 546 length as the number of UDP payload octets, as calculated by 547 subtracting the size of the UDP header from the UDP payload length. 549 When the manifest definition is at the IP layer, the payload used for 550 calculating the packet digest includes the full IP payload of the 551 data packets in the (S,G). There is no restriction on the IP 552 protocols that can be authenticated. The length field in the 553 pseudoheader is calculated by subtracting the IP Header Length from 554 the IP length, and is equal to the number of octets in the payload 555 for the digest calculation. 557 3.3.1.1.2. Motivation 559 Full IP payloads often aren't available to receivers without extra 560 privileges on end user operating systems, so it's useful to provide a 561 way to authenticate only the UDP payload, which is often the only 562 portion of the packet available to many receiving applications. 564 However, for some use cases a full IP payload is appropriate. For 565 example, when retrofitting some existing protocols, some packets may 566 be predictable or frequently repeated. Use of an IPSec 567 Authentication Header [RFC4302] is one way to disambiguate such 568 packets. Even though the shared secret means the Authentication 569 Header can't itself be used to authenticate the packet contents, the 570 sequence number in the Authentication Header can ensure that specific 571 packets are not repeated at the IP layer, and so it's useful for AMBI 572 to have the capability to authenticate such packets. 574 Another example: some services might need to authenticate the UDP 575 options [I-D.ietf-tsvwg-udp-options]. When using the UDP payload, 576 the UDP options would not be part of the authenticated payload, but 577 would be included when using the IP payload type. 579 Lastly, since (S,G) subscription operates at the IP layer, it's 580 possible that some non-UDP protocols will need to be authenticated, 581 and the IP layer allows for this. However, most user-space transport 582 applications are expected to use the UDP layer authentication. 584 3.3.2. Pseudoheader 586 When calculating the hash for the packet digest, the hash algorithm 587 is applied to a pseudoheader followed by the payload from the packet. 588 The complete sequence of octets used to calculate the hash is 589 structured as follows: 591 0 1 2 3 592 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 593 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 594 | Source Address (32 bits IPv4/128 bits IPv6) | 595 | ... | 596 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 597 | Destination Address (32 bits IPv4/128 bits IPv6) | 598 | ... | 599 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 600 | Zeroes | Protocol | Length | 601 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 602 | Source Port | Destination Port | 603 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 604 | Manifest Identifier | 605 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 606 | Payload Data | 607 | ... | 608 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 610 3.3.2.1. Source Address 612 The IPv4 or IPv6 source address of the packet. 614 3.3.2.2. Destination Address 616 The IPv4 or IPv6 destination address of the packet. 618 3.3.2.3. Zeroes 620 All bits set to 0. 622 3.3.2.4. Protocol 624 The IP Protocol field from IPv4, or the Next Header field for IPv6. 625 When using UDP-layer authentication, this value is always UDP (0x11) 626 but for IP-layer authentication it can vary per-packet. 628 3.3.2.5. Length 630 The length in octets of the Payload Data field, expressed as an 631 unsigned 16-bit integer. 633 3.3.2.6. Source Port 635 The source port of the packet. Zeroes if using IP-layer 636 authentication for a non-UDP protocol. 638 3.3.2.7. Destination Port 640 The UDP destination port of the packet. Zeroes if using IP-layer 641 authentication for a non-UDP protocol. 643 3.3.2.8. Manifest Identifier 645 The 32-bit identifier for the manifest stream. 647 3.3.2.9. Payload Data 649 The payload data includes either the IP payload or the UDP payload, 650 as indicated by the digest profile. 652 3.4. Manifests 654 3.4.1. Manifest Layout 655 0 1 2 3 656 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 657 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 658 | Manifest Stream Identifier | 659 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 660 | Manifest sequence number | 661 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 662 | First packet sequence number | 663 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 664 |T| Packet Digest Count | TLV Space (present iff T set) | 665 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 666 | ... TLVs (Length=TLV Space or 0 if T unset) ... | 667 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 668 | ... Packet Digests ... | 669 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 671 3.4.1.1. Manifest Stream Identifier 673 A 32-bit unsigned integer chosen by the sender. This value MUST be 674 equal to the "id" field in the manifest-stream in the "ietf-ambi" 675 model. If a manifest is seen that does not have the expected value 676 from the metadata provided for the manifest, the receiver MUST stop 677 processing this manifest and disconnect from this manifest stream. 678 It MAY reconnect with an exponential backoff starting at 1s, or it 679 MAY connect to an alternative manifest stream if one is known. 681 3.4.1.2. Manifest Sequence Number 683 A monotonically increasing 32-bit unsigned integer. Each manifest 684 sent by the sender increases this value by 1. On overflow it wraps 685 to 0. 687 It's RECOMMENDED to expire the manifest stream and start a new stream 688 for the data packets before a sequence number wrap is necessary. 690 3.4.1.3. First Packet Sequence Number 692 A monotonically increasing 32-bit unsigned integer. Each packet in 693 the data stream increases this value by 1. 695 It's RECOMMENDED to expire the manifest stream and start a new stream 696 for the data packets before a sequence number wrap is necessary. 698 Note: for redundancy, especially if using a manifest stream with 699 unreliable transport, successive manifests MAY provide duplicates of 700 the same packet digest with the same packet sequence number, using 701 overapping sets of packet sequence numbers. When received, these 702 reset the hold timer for the listed packet digests. 704 3.4.1.4. T bit (TLVs Present) 706 If 1, this indicates the TLV Length and TLV space fields are present. 707 If 0, this indicates neither field is present. 709 3.4.1.5. Packet Digest Count 711 A 15-bit unsigned integer equal to the count of packet digests in the 712 manifest. 714 3.4.1.6. TLV Space 716 A 16-bit unsigned integer with the length of the TLVs section. 718 3.4.1.7. TLVs 720 These are Type-Length-Value blocks, back to back. These may be 721 extended by future specifications. 723 These are composed of 3 fields: 725 * Type: an 8-bit unsigned integer indicating the type. Type values 726 in 0-127 have an 8-bit length, and type values in 128-255 have a 727 16-bit length. 729 * Length: a 8-bit or 16-bit unsigned integer indicating the length 730 of the value 732 * Value: a value with semantics defined by the Type field. 734 Defined values: 736 +======+==========+==============================================+ 737 | Type | Name | Value | 738 +======+==========+==============================================+ 739 | 0 | Pad | Length can be 0-255. Value is filled with 0 | 740 | | | and ignored by receiver. | 741 +------+----------+----------------------------------------------+ 742 | 128 | Refresh | Length MUST be 2. Value is a 16-bit | 743 | | Deadline | unsigned integer number of seconds. When | 744 | | | this field is absent or zero, it means the | 745 | | | current digest profile for the current | 746 | | | manifest stream is stable. A nonzero value | 747 | | | means the authentication is transitioning to | 748 | | | a new manifest stream, and the set of digest | 749 | | | profiles SHOULD be refreshed by receivers | 750 | | | before this much time has elapsed in order | 751 | | | to avoid a disruption. See Section 3.5. | 752 +------+----------+----------------------------------------------+ 754 Table 1 756 1-120 and 129-248 are unassigned 121-127 and 249-255 are reserved for 757 experiments 759 Any unknown values MUST be skipped and ignored by the receiver, using 760 the Length field to skip. 762 The total size of the manifest in octets is exactly equal to: 764 Size of digests * packet count + 14 if T is 0 Size of digests * 765 packet count + 16 + TLV Length if T is 1 767 The total size of the TLV space is exactly equal to: 769 (2 + Length) summed for each TLV 771 The total size of the TLV space MUST exactly equal TLV Length. If 772 the TLV space exceeds the TLV Length, the receiver MUST disconnect, 773 and behave as if the Manifest Stream Identifier was wrong. This 774 state indicates a failed decoding of the TLV space. 776 3.4.1.8. Packet Digests 778 Packet digests appended one after the other, aligned to 8-bit 779 boundaries with 0-bit padding at the end if the bit length of the 780 digests are not multiples of 8 bits. 782 3.5. Transitioning to Other Manifest Streams 784 It's possible for multiple manifest streams authenticating the same 785 data stream to be active at the same time. The different manifest 786 streams can have different hash algorithms, manifest ids, and current 787 packet sequence numbers for the same data stream. These result in 788 different sets of packet digests for the same data packets, one 789 digest per packet per digest profile. 791 It's necessary sometimes to transition gracefully from one manifest 792 stream to another. The Refresh Deadline TLV from the manifest is 793 used to signal to receivers the need to transition. 795 When a receiver gets a nonzero refresh deadline in a manifest the 796 sender SHOULD have an alternate manifest stream ready and available, 797 and the receiver SHOULD learn the alternate manifest stream, join the 798 new one, and leave the old one before the number of seconds given in 799 the refresh deadline. After the refresh deadline has expired, a 800 manifest stream MAY stop transmitting and close connections from the 801 server side. When multiple manifest-streams are provided in the 802 metadata, all or all but one SHOULD contain an expire-time, and new 803 or refreshing receivers SHOULD choose a manifest stream without an 804 expire-time, or with the latest expire-time if all manifests have an 805 expire-time. 807 The receivers SHOULD start the refresh after a random time delay 808 between now and one half the number of seconds in the deadline field 809 after the first manifest they receive containing a nonzero refresh 810 deadline. This time delay is to desynchronize the refresh attempts 811 in order to spread the spike of load on the DORMS server while 812 changing manifest profiles during a large multicast event. 814 4. Transport Considerations 816 4.1. Overview 818 AMBI manifests MUST be authenticated, but any transport protocol 819 providing authentication can be used. This section discusses several 820 viable options for the use of an authenticating transport, and some 821 associated design considerations. 823 TBD: add ALTA to the list when and if it gets further along 824 [I-D.draft-krose-mboned-alta]. Sending an authenticatable multicast 825 stream (instead of the below unicast-based proposals) is a worthwhile 826 goal, else a 1% unicast authentication overhead becomes a new unicast 827 limit to the scalability. 829 TBD: probably should add quic also? Or maybe https is sufficient? 830 TBD: add a recommendation about scalability, like with DORMS, when 831 using a unicast hash stream. CDN or other kind of fanout solution 832 that can scale the delivery, and still generally hit the time window. 834 4.2. HTTPS 836 This document defines a new media type 'application/ambi' for use 837 with HTTPS. URIs in the manifest-transport list with the scheme 838 'https' use this transport. 840 An HTTPS stream carrying the 'application/ambi' media type is 841 composed of a sequence of binary AMBI manifests, sent back to back in 842 the payload body (payload body is defined in Section 3.3 of 843 [RFC7230]). 845 Complete packet digests from partially received manifests MAY be used 846 by the receiver for authentication of data packets from the multicast 847 channel, even if the full manifest is not yet delivered. 849 4.3. TLS 851 This document defines the new uri scheme 'ambi+tls' for use with TLS 852 [RFC8446]. URIs in the manifest-transport list with the scheme 853 'ambi+tls' use this transport. 855 A TLS stream carrying AMBI manifests is composed of a sequence of 856 binary AMBI manifests, transmitted back to back. 858 Complete packet Digests from partially received manifests MAY be used 859 by the receiver for authentication, even if the full manifest is not 860 yet delivered. 862 4.4. DTLS 864 This document defines the new uri scheme 'ambi+dtls' for use with 865 DTLS [RFC6347]. 867 Manifests transported with DTLS have the tradeoff (relative to TLS or 868 HTTPS) that they might be lost and not retransmitted or reordered, 869 but they will not cause head-of-line blocking or delay in processing 870 data packets that arrived later. For some applications this is a 871 worthwhile tradeoff. 873 Note that loss of a single DTLS packet can result in the loss of 874 multiple packet digests, which can mean failure to authenticate 875 multiple data packets. 877 DTLS transport for manifests supports one manifest per packet. It's 878 OPTIONAL to provides for some redundancy in packet digests by 879 providing overlap in the packet sequence numbers across different 880 manifests, thereby sending some or all packet digests multiple times 881 to avoid loss. 883 Future extensions might define extensions that can provide more 884 efficient redundancy via FEC. Those future extensions will require a 885 different URI scheme. 887 5. Examples 889 TBD: walk through some examples as soon as we have a build running. 890 Likely to need some touching up of the spec along the way... 892 6. YANG Module 894 6.1. Tree Diagram 896 The tree diagram below follows the notation defined in [RFC8340]. 898 module: ietf-ambi 900 augment /dorms:dorms/dorms:metadata/dorms:sender/dorms:group 901 /dorms:udp-stream: 902 +--rw ambi 903 +--rw manifest-stream* [id] 904 +--rw id uint32 905 +--rw manifest-stream* [uri] 906 | +--rw uri inet:uri 907 +--rw hash-algorithm iha:hash-algorithm-type 908 +--rw data-hold-time? uint32 909 +--rw digest-hold-time? uint32 910 +--rw expiration? yang:date-and-time 911 augment /dorms:dorms/dorms:metadata/dorms:sender/dorms:group: 912 +--rw ambi 913 +--rw manifest-stream* [id] 914 +--rw id uint32 915 +--rw manifest-stream* [uri] 916 | +--rw uri inet:uri 917 +--rw hash-algorithm iha:hash-algorithm-type 918 +--rw data-hold-time? uint32 919 +--rw digest-hold-time? uint32 920 +--rw expiration? yang:date-and-time 922 6.2. Module 923 924 file ietf-ambi@2022-03-07.yang 925 module ietf-ambi { 926 yang-version 1.1; 928 namespace "urn:ietf:params:xml:ns:yang:ietf-ambi"; 929 prefix "ambi"; 931 import ietf-dorms { 932 prefix "dorms"; 933 reference "I-D.jholland-mboned-dorms"; 934 } 936 import ietf-inet-types { 937 prefix "inet"; 938 reference "RFC6991 Section 4"; 939 } 941 import iana-hash-algs { 942 prefix "iha"; 943 reference "draft-ietf-netconf-crypto-types"; 944 } 946 import ietf-yang-types { 947 prefix "yang"; 948 reference "RFC 6991: Common YANG Data Types"; 949 } 951 organization "IETF"; 953 contact 954 "Author: Jake Holland 955 956 "; 958 description 959 "Copyright (c) 2019 IETF Trust and the persons identified as 960 authors of the code. All rights reserved. 962 Redistribution and use in source and binary forms, with or 963 without modification, is permitted pursuant to, and subject to 964 the license terms contained in, the Simplified BSD License set 965 forth in Section 4.c of the IETF Trust's Legal Provisions 966 Relating to IETF Documents 967 (https://trustee.ietf.org/license-info). 969 This version of this YANG module is part of RFC XXXX 970 (https://www.rfc-editor.org/info/rfcXXXX); see the RFC itself 971 for full legal notices. 973 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL 974 NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED', 975 'MAY', and 'OPTIONAL' in this document are to be interpreted as 976 described in BCP 14 (RFC 2119) (RFC 8174) when, and only when, 977 they appear in all capitals, as shown here. 979 This module contains the definition for the AMBI data types. 980 It provides metadata for authenticating SSM channels as an 981 augmentation to DORMS."; 983 revision 2021-07-08 { 984 description "Draft version."; 985 reference 986 "draft-ietf-mboned-ambi"; 987 } 989 grouping manifest-stream-definition { 990 description 991 "This grouping specifies a manifest stream for 992 authenticating a multicast data stream with AMBI"; 993 leaf id { 994 type uint32; 995 mandatory true; 996 description 997 "The Manifest ID referenced in a manifest."; 998 } 999 list manifest-stream { 1000 key uri; 1001 leaf uri { 1002 type inet:uri; 1003 mandatory true; 1004 description 1005 "The URI for a stream of manifests."; 1006 } 1007 description "A URI that provides a location for the 1008 manifest stream"; 1009 } 1010 leaf hash-algorithm { 1011 type iha:hash-algorithm-type; 1012 mandatory true; 1013 description 1014 "The hash algorithm for the packet hashes within 1015 manifests in this stream."; 1016 } 1017 leaf data-hold-time { 1018 type uint32; 1019 default 2000; 1020 units "milliseconds"; 1021 description 1022 "The number of milliseconds to hold data packets 1023 waiting for a corresponding digest before 1024 discarding"; 1025 } 1026 leaf digest-hold-time { 1027 type uint32; 1028 default 10000; 1029 units "milliseconds"; 1030 description 1031 "The number of milliseconds to hold packet 1032 digests waiting for a corresponding data packet 1033 before discarding"; 1034 } 1035 leaf expiration { 1036 type yang:date-and-time; 1037 description 1038 "The time after which this manifest stream may 1039 stop providing authentication for the data stream. 1040 When not present or empty there is no known expiration."; 1041 } 1042 } 1044 augment 1045 "/dorms:dorms/dorms:metadata/dorms:sender/dorms:group/"+ 1046 "dorms:udp-stream" { 1047 description "AMBI extensions for securing UDP multicast."; 1049 container ambi { 1050 description "UDP-layer AMBI container for DORMS extension."; 1051 list manifest-stream { 1052 key id; 1053 description "Manifest stream definition list."; 1054 uses manifest-stream-definition; 1055 } 1056 } 1057 } 1059 augment 1060 "/dorms:dorms/dorms:metadata/dorms:sender/dorms:group" { 1061 description "AMBI extensions for securing IP multicast."; 1063 container ambi { 1064 description "IP-layer AMBI container for DORMS extension."; 1065 list manifest-stream { 1066 key id; 1067 description "Definition of a manifest stream."; 1068 uses manifest-stream-definition; 1069 } 1070 } 1071 } 1072 } 1073 1075 7. IANA Considerations 1077 7.1. The YANG Module Names Registry 1079 This document adds one YANG module to the "YANG Module Names" 1080 registry maintained at . The following registrations are made, per the format in 1082 Section 14 of [RFC6020]: 1084 name: ietf-ambi 1085 namespace: urn:ietf:params:xml:ns:yang:ietf-ambi 1086 prefix: ambi 1087 reference: I-D.draft-jholland-mboned-ambi 1089 7.2. The XML Registry 1091 This document adds the following registration to the "ns" subregistry 1092 of the "IETF XML Registry" defined in [RFC3688], referencing this 1093 document. 1095 URI: urn:ietf:params:xml:ns:yang:ietf-ambi 1096 Registrant Contact: The IESG. 1097 XML: N/A, the requested URI is an XML namespace. 1099 7.3. Media Type 1101 TBD: Register 'application/ambi' according to advice from: 1102 https://www.iana.org/form/media-types (https://www.iana.org/form/ 1103 media-types) 1105 TBD: check guidelines in https://tools.ietf.org/html/rfc8126 1106 (https://tools.ietf.org/html/rfc8126) 1108 TBD: comments from Amanda: The first is that the current IANA 1109 Considerations RFC is RFC 8126 rather than 5226. The other point, 1110 which you may be aware of, is that while https://www.iana.org/form/ 1111 media-types provides guidance, standards-tree registrations submitted 1112 through RFCs shouldn't be submitted through that form and (unlike 1113 vendor-tree subtypes and standards-tree subtypes documented in other 1114 standards organization specs) won't need to be explicitly approved by 1115 the IESG-designated experts. Instead, the advice in RFC 6838 is that 1116 media type registrations requested by IETF-stream I-Ds be informally 1117 reviewed on the media-types@iana.org mailing list, which the IESG- 1118 designated experts participate in. 1120 7.4. URI Schemes 1122 7.4.1. TLS 1124 TBD: register 'ambi+tls' as a uri scheme according to advice from: 1125 https://datatracker.ietf.org/doc/html/rfc7595 1126 (https://datatracker.ietf.org/doc/html/rfc7595) 1128 7.4.2. DTLS 1130 TBD: register 'ambi+dtls' as a uri scheme according to advice from: 1131 https://datatracker.ietf.org/doc/html/rfc7595 1132 (https://datatracker.ietf.org/doc/html/rfc7595) 1134 8. Security Considerations 1136 8.1. Predictable Packets 1138 Protocols that have predictable packets run the risk of offline 1139 attacks for hash collisions against those packets. When 1140 authenticating a protocol that might have predictable packets, it's 1141 RECOMMENDED to use a hash function secure against such attacks or to 1142 add content to the packets to make them unpredictable, such as an 1143 Authentication Header ([RFC4302]), or the addition of an ignored 1144 field with random content to the packet payload. 1146 TBD: explain attack from generating malicious packets and then 1147 looking for collisions, as opposed to having to generate a collision 1148 on packet contents that include a sequence number and then hitting a 1149 match. 1151 TBD: follow the rest of the guidelines: https://tools.ietf.org/html/ 1152 rfc3552 1154 8.2. Attacks on Side Applications 1156 A multicast receiver subscribes to an (S,G) and if it's a UDP 1157 application, listens on a socket with a port number for packets to 1158 arrive. 1160 UDP applications sometimes bind to an "unspecified" address ("::" or 1161 "0.0.0.0") for a particular UDP port, which will make the appliction 1162 receive and process any packet that arrives on said port. 1164 Forwarding multicast traffic opens a new practical attack surface 1165 against receivers that have bound sockets using the "unspecified" 1166 address and were operating behind a firewall and/or NAT. Such 1167 applications will receive traffic from the internet only after 1168 sending an outbound packet, and usually only for return packets with 1169 the reversed source and destination port and IP addresses. 1171 Multicast subscription and routing operates at the IP layer, so when 1172 a multicst receive application subscribes to a channel, traffic with 1173 the IP addresses for that channel will start arriving. There is no 1174 selection for the UDP port at the routing layer that prevents 1175 multicast IP traffic from arriving. 1177 When an insecure application with a vulnerability is listening to a 1178 UDP port on an unspecified address, it will receive multicast packets 1179 arriving at the device and with that destination UDP port. Although 1180 the primary problem lies in the insecure application, accepting 1181 multicast subscriptions increases the attack scope against those 1182 applications to include attackers who can inject a packet into a 1183 properly subscribed multicast stream. 1185 It's RECOMMENDED that senders using AMBI to secure their traffic 1186 include all IP traffic that they send in their DORMS metadata 1187 information, and that firewalls using AMBI to provide secure access 1188 to multicast traffic block multicast traffic destined to unsecured 1189 UDP ports on (S,G)s that have AMBI-based security for any traffic. 1190 This mitigation prevents new forwarding of multicast traffic from 1191 providing attackers with a packet inject capability access to new 1192 attack surfaces from pre-existing insecure apps. 1194 9. Acknowledgements 1196 Many thanks to Daniel Franke, Eric Rescorla, Christian Worm 1197 Mortensen, Max Franke, Albert Manfredi, and Amanda Baber for their 1198 very helpful comments and suggestions. 1200 10. References 1202 10.1. Normative References 1204 [I-D.draft-ietf-mboned-dorms] 1205 Holland, J., "Discovery Of Restconf Metadata for Source- 1206 specific multicast", Work in Progress, Internet-Draft, 1207 draft-ietf-mboned-dorms-01, 31 October 2020, 1208 . 1211 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1212 Requirement Levels", BCP 14, RFC 2119, 1213 DOI 10.17487/RFC2119, March 1997, 1214 . 1216 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 1217 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 1218 January 2012, . 1220 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 1221 Protocol (HTTP/1.1): Message Syntax and Routing", 1222 RFC 7230, DOI 10.17487/RFC7230, June 2014, 1223 . 1225 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 1226 RFC 7950, DOI 10.17487/RFC7950, August 2016, 1227 . 1229 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1230 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1231 May 2017, . 1233 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 1234 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 1235 . 1237 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 1238 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 1239 . 1241 10.2. Informative References 1243 [CVE] MITRE, "Common Vulnerabilities and Exposures", September 1244 1999, . 1246 [I-D.draft-krose-mboned-alta] 1247 Rose, K. and J. Holland, "Asymmetric Loss-Tolerant 1248 Authentication", Work in Progress, Internet-Draft, draft- 1249 krose-mboned-alta-01, 8 July 2019, 1250 . 1253 [I-D.ietf-tsvwg-udp-options] 1254 Touch, J., "Transport Options for UDP", Work in Progress, 1255 Internet-Draft, draft-ietf-tsvwg-udp-options-15, 3 March 1256 2022, . 1259 [PathChirp] 1260 Ribeiro, V.J., Riedi, R.H., Baraniuk, R.G., Navratil, J., 1261 Cottrell, L., Department of Electrical and Computer 1262 Engineering Rice University, and SLAC/SCS-Network 1263 Monitoring, Stanford University, "pathChirp: Efficient 1264 Available Bandwidth Estimation for Network Paths", 2003. 1266 [PathRate] Dovrolis, C., Ramanathan, P., and D. Moore, "Packet 1267 dispersion techniques and a capacity estimation 1268 methodology", IEEE/ACM Transactions on Networking, Volume 1269 12, Issue 6, pp. 963-977. , December 2004. 1271 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 1272 Text on Security Considerations", BCP 72, RFC 3552, 1273 DOI 10.17487/RFC3552, July 2003, 1274 . 1276 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1277 DOI 10.17487/RFC3688, January 2004, 1278 . 1280 [RFC4082] Perrig, A., Song, D., Canetti, R., Tygar, J. D., and B. 1281 Briscoe, "Timed Efficient Stream Loss-Tolerant 1282 Authentication (TESLA): Multicast Source Authentication 1283 Transform Introduction", RFC 4082, DOI 10.17487/RFC4082, 1284 June 2005, . 1286 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, 1287 DOI 10.17487/RFC4302, December 2005, 1288 . 1290 [RFC4383] Baugher, M. and E. Carrara, "The Use of Timed Efficient 1291 Stream Loss-Tolerant Authentication (TESLA) in the Secure 1292 Real-time Transport Protocol (SRTP)", RFC 4383, 1293 DOI 10.17487/RFC4383, February 2006, 1294 . 1296 [RFC5776] Roca, V., Francillon, A., and S. Faurite, "Use of Timed 1297 Efficient Stream Loss-Tolerant Authentication (TESLA) in 1298 the Asynchronous Layered Coding (ALC) and NACK-Oriented 1299 Reliable Multicast (NORM) Protocols", RFC 5776, 1300 DOI 10.17487/RFC5776, April 2010, 1301 . 1303 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 1304 the Network Configuration Protocol (NETCONF)", RFC 6020, 1305 DOI 10.17487/RFC6020, October 2010, 1306 . 1308 [RFC6584] Roca, V., "Simple Authentication Schemes for the 1309 Asynchronous Layered Coding (ALC) and NACK-Oriented 1310 Reliable Multicast (NORM) Protocols", RFC 6584, 1311 DOI 10.17487/RFC6584, April 2012, 1312 . 1314 [WEBRC] Luby, M. and V. Goyal, "Wave and Equation Based Rate 1315 Control Using Multicast Round Trip Time: Extended Report", 1316 Digital Fountain Technical Report no. DF2002-07-001 , 1317 September 2002. 1319 Authors' Addresses 1321 Jake Holland 1322 Akamai Technologies, Inc. 1323 150 Broadway 1324 Cambridge, MA 02144, 1325 United States of America 1326 Email: jakeholland.net@gmail.com 1328 Kyle Rose 1329 Akamai Technologies, Inc. 1330 150 Broadway 1331 Cambridge, MA 02144, 1332 United States of America 1333 Email: krose@krose.org