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