idnits 2.17.1 draft-ietf-mboned-ambi-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 30, 2020) is 1272 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 974 == Outdated reference: A later version (-04) exists of draft-ietf-mboned-dorms-00 ** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147) == Outdated reference: A later version (-32) exists of draft-ietf-tsvwg-udp-options-08 Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 2 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: May 3, 2021 October 30, 2020 7 Asymmetric Manifest Based Integrity 8 draft-ietf-mboned-ambi-01 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 May 3, 2021. 36 Copyright Notice 38 Copyright (c) 2020 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 54 1.1. Comparison with TESLA . . . . . . . . . . . . . . . . . . 4 55 1.2. Threat Model . . . . . . . . . . . . . . . . . . . . . . 4 56 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 57 1.4. Notes for Contributors and Reviewers . . . . . . . . . . 5 58 1.4.1. Venues for Contribution and Discussion . . . . . . . 5 59 2. Protocol Operation . . . . . . . . . . . . . . . . . . . . . 5 60 2.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 5 61 2.2. Buffering and Validation Windows . . . . . . . . . . . . 6 62 2.2.1. Inter-packet Gap . . . . . . . . . . . . . . . . . . 8 63 2.3. Packet Digests . . . . . . . . . . . . . . . . . . . . . 8 64 2.3.1. Digest Profile . . . . . . . . . . . . . . . . . . . 8 65 2.3.2. Pseudoheader . . . . . . . . . . . . . . . . . . . . 10 66 2.4. Manifests . . . . . . . . . . . . . . . . . . . . . . . . 12 67 2.4.1. Manifest Layout . . . . . . . . . . . . . . . . . . . 12 68 2.5. Transitioning to Other Manifest Streams . . . . . . . . . 13 69 3. Transport Considerations . . . . . . . . . . . . . . . . . . 14 70 3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 14 71 3.2. HTTPS . . . . . . . . . . . . . . . . . . . . . . . . . . 14 72 3.3. DTLS . . . . . . . . . . . . . . . . . . . . . . . . . . 14 73 3.4. DTLS + FECFRAME . . . . . . . . . . . . . . . . . . . . . 15 74 4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 15 75 5. YANG Module . . . . . . . . . . . . . . . . . . . . . . . . . 15 76 5.1. Tree Diagram . . . . . . . . . . . . . . . . . . . . . . 15 77 5.2. Module . . . . . . . . . . . . . . . . . . . . . . . . . 15 78 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 79 6.1. The YANG Module Names Registry . . . . . . . . . . . . . 18 80 6.2. The XML Registry . . . . . . . . . . . . . . . . . . . . 18 81 6.3. Media Type . . . . . . . . . . . . . . . . . . . . . . . 18 82 7. Security Considerations . . . . . . . . . . . . . . . . . . . 19 83 7.1. Predictable Packets . . . . . . . . . . . . . . . . . . . 19 84 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19 85 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 86 9.1. Normative References . . . . . . . . . . . . . . . . . . 19 87 9.2. Informative References . . . . . . . . . . . . . . . . . 20 88 9.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 21 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 91 1. Introduction 93 Multicast transport poses security problems that are not easily 94 addressed by the same security mechanisms used for unicast transport. 96 The "Introduction" sections of the documents describing TESLA 97 [RFC4082], and TESLA in SRTP [RFC4383], and TESLA with ALC and NORM 98 [RFC5776] present excellent overviews of the challenges unique to 99 multicast authentication, briefly summarized here: 101 o A MAC based on a symmetric shared secret cannot be used because 102 each packet has multiple receivers that do not trust each other, 103 and using a symmetric shared secret exposes the same secret to 104 each receiver. 106 o Asymmetric per-packet signatures can handle only very low bit- 107 rates because of the computational overhead. 109 o An asymmetric signature of a larger message comprising multiple 110 packets requires reliable receipt of all such packets, something 111 that cannot be guaranteed in a timely manner even for protocols 112 that do provide reliable delivery, and the retransmission of which 113 may anyway exceed the useful lifetime for data formats that can 114 otherwise tolerate some degree of loss. 116 Aymmetric Manifest-Based Integrity (AMBI) defines a method for 117 receivers or middle boxes to cryptographically authenticate and 118 verify the integrity of a stream of packets, by communicating packet 119 "manifests" (described in Section 2.4) via an out-of-band 120 communication channel that provides authentication and verifiable 121 integrity. 123 Each manifest contains a message digest (described in Section 2.3) 124 for each packet in a sequence of packets from the data stream, 125 hereafter called a "packet digest". The packet digest incorporates a 126 cryptographic hash of the packet contents and some identifying data 127 from the packet, according to a defined digest profile for the data 128 stream. 130 Each manifest MUST be delivered in a way that provides cryptographic 131 integrity guarantees of the authenticity of the manifest. For 132 example, TLS could be used to deliver a stream of manifests over a 133 unicast data stream from a set of trusted senders to each receiver, 134 or a protocol that asymmetrically signs each message could be used to 135 transport authenticated manifests over a multicast channel. Note 136 that a UDP-based protocol might drop or reorder manifests while still 137 providing authentication. 139 Upon successful verification of a manifest and receipt of any subset 140 of the corresponding data packets, the receiver has proof of the 141 integrity of the contents of the data packets that are listed in the 142 manifest. 144 Authenticating the integrity of the data packets depends on: 146 o the authenticity of the manifests 148 o the authenticity of the digest profile used for construction of 149 the packet digests 151 o the difficulty of generating a collision for the packet digests 152 contained in the manifest. 154 This document defines a YANG [RFC7950] module that augments the DORMS 155 [I-D.draft-ietf-mboned-dorms-00] YANG module to provide a way to 156 communicate a digest profile, described in Section 2.3.1, for 157 construction of the packet digests, described in Section 2.3. When 158 obtaining the digest profile by using DORMS, the authenticity of the 159 data stream relies on a trust relationship with the DORMS server, 160 since that anchors the authenticity of the digest profile for 161 constructing packet digests. 163 1.1. Comparison with TESLA 165 AMBI and TESLA [RFC4082] and [RFC5776] attempt to achieve a similar 166 goal of authenticating the integrity of streams of multicast packets. 167 AMBI imposes a higher overhead, as measured in the amount of extra 168 data required, than TESLA imposes. In exchange, AMBI relaxes the 169 requirement for establishing an upper bound on clock synchronization 170 between sender and receiver, and allows for the use case of 171 authenticating multicast traffic before forwarding it through the 172 network, while also allowing receivers to authenticate the same 173 traffic. By contrast, this is not possible with TESLA because the 174 data packets can't be authenticated until a key is disclosed, so 175 either the middlebox has to forward data packets without first 176 authenticating them so that the receiver has them prior to key 177 disclosure, or the middlebox has to hold packets until the key is 178 disclosed, at which point the receiver can no longer establish their 179 authenticity. 181 The other new capability is that because AMBI provides authentication 182 information out of band, authentication can be retrofitted into some 183 pre-existing deployments without changing the protocol of the data 184 packets, under some restrictions outlined in Section 7. By contrast, 185 TESLA requires a MAC to be added to each authenticated message. 187 1.2. Threat Model 189 TBD: Summarize the applicable threat model this protects against. A 190 diagram plus a cleaned-up version of the on-list explanation here is 191 probably appropriate: https://mailarchive.ietf.org/arch/msg/mboned/ 192 CG9FLjPwuno3MtvYvgNcD5p69I4/ 194 Reference [RFC3552] https://tools.ietf.org/html/rfc3552#section-3 196 1.3. Terminology 198 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 199 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 200 "OPTIONAL" in this document are to be interpreted as described in 201 [RFC2119] and [RFC8174] when, and only when, they appear in all 202 capitals, as shown here. 204 1.4. Notes for Contributors and Reviewers 206 Note to RFC Editor: Please remove this section and its subsections 207 before publication. 209 This section is to provide references to make it easier to review the 210 development and discussion on the draft so far. 212 1.4.1. Venues for Contribution and Discussion 214 This document is in the Github repository at: 216 https://github.com/GrumpyOldTroll/ietf-dorms-cluster 218 Readers are welcome to open issues and send pull requests for this 219 document. 221 Please note that contributions may be merged and substantially 222 edited, and as a reminder, please carefully consider the Note Well 223 before contributing: https://datatracker.ietf.org/submit/note-well/ 225 Substantial discussion of this document should take place on the 226 MBONED working group mailing list (mboned@ietf.org). 228 o Join: https://www.ietf.org/mailman/listinfo/mboned 230 o Search: https://mailarchive.ietf.org/arch/browse/mboned/ 232 2. Protocol Operation 234 2.1. Overview 236 In order to authenticate a data packet, AMBI receivers need to hold 237 these three pieces of information at the same time: 239 o the data packet 241 o an authenticated manifest containing the packet digest for the 242 data packet 244 o a digest profile defining the transformation from the data packet 245 to its packet digest 247 The manifests are delivered as a stream of manifests over an 248 authenticated data channel. Manifest contents MUST be authenticated 249 before they can be used to authenticate data packets. 251 The manifest stream is composed of an ordered sequence of manifests 252 that each contain an ordered sequence of packet digests, 253 corresponding to the original packets as sent from their origin, in 254 the same order. 256 Note that a manifest contains potentially many packet digests, and 257 its size can be tuned to fit within a convenient PDU (Protocol Data 258 Unit) of the manifest transport stream. By doing so, many packet 259 digests for the multicast data stream can be delivered per packet of 260 the manifest transport. The intent is that even with unicast-based 261 manifest transport, multicast-style efficiencies of scale can still 262 be realized with only a relatively small unicast overhead, when 263 manifests use a unicast transport. 265 2.2. Buffering and Validation Windows 267 Using different communication channels for the manifest stream and 268 the data stream introduces a possibility of desynchronization in the 269 timing of the received data between the different channels, so 270 receivers hold data packets and packet digests from the manifest 271 stream in buffers for some duration while awaiting the arrival of 272 their counterparts. 274 While holding a data packet, if the corresponding packet digest for 275 that packet arrives in the manifest stream and can be authenticated, 276 the data packet is authenticated. 278 While holding an authenticated packet digest, if the corresponding 279 data packet arrives with a matching packet digest, the data packet is 280 authenticated. 282 Once a data packet is authenticated, the corresponding packet digest 283 can be discarded and the data packet can be further processed by the 284 receiving application or forwarded through the receiving network. 285 Authenticating a data packet consumes one packet digest and prevents 286 re-learning, with a hold-down time equal to the hold time for packet 287 digests. A different manifest might provide the same packet digest 288 with the same packet sequence number, but the digest remains consumed 289 if it has been used to authenticate a data packet. 291 If the receiver's hold duration for a data packet expires without 292 authenticating the packet, the packet SHOULD be dropped as 293 unauthenticated. If the hold duration of a manifest expires, packet 294 digests last received in that manifest SHOULD be discarded. (Note 295 that in some cases, packet digests can be sent redundantly in more 296 than one manifest. In such cases, the latest received time for an 297 authenticated packet digest should be used for the expiration time.) 299 Since packet digests are usually smaller than the data packets, it's 300 RECOMMENDED that senders generate and send manifests with timing such 301 that the packet digests in a manifest will typically be received by 302 subscribed receivers before the data packets corresponding to those 303 digests are received. 305 This strategy reduces the buffering requirements at receivers at, the 306 cost of introducing some buffering of data packets at the sender, 307 since data packets are generated before their packet digests can be 308 added to manifests. 310 The RECOMMENDED default hold times at receivers are: 312 o 2 seconds for data packets 314 o 10 seconds for packet digests 316 The sender MAY recommend different values for specific data streams, 317 in order to tune different data streams for different performance 318 goals. The YANG model in Section 5 provides a mechanism for senders 319 to communicate the sender's recommendation for buffering durations, 320 when using DORMS. 322 Receivers SHOULD follow the recommendations for hold times provided 323 by the sender, subject to their capabilities and any administratively 324 configured limits on buffer sizes at the receiver. 326 However receivers MAY deviate from the values recommended by the 327 sender for a variety of reasons. Decreasing the buffering durations 328 recommended by the server increases the risk of losing packets, but 329 can be an appropriate tradeoff for specific network conditions and 330 hardware constraints on some devices. 332 2.2.1. Inter-packet Gap 334 It's RECOMMENDED that middle boxes forwarding buffered data packets 335 preserve the inter-packet gap between packets in the same data 336 stream, and that receiving libraries that perform AMBI-based 337 authentication provide mechanisms to expose the network arrival times 338 of packets to applications. 340 The purpose for this recommendation is to preserve the capability of 341 receivers to use techniques for available bandwidth detection or 342 network congestion based on observation of packet times. Examples of 343 such techniques include paced chirping and pathrate. 345 Note that this recommendation SHOULD NOT prevent the transmission of 346 an authenticated packet because the prior packet is unauthenticated. 347 This recommendation only asks implementations to delay the 348 transmission of an authenticated packet to correspond to the 349 interpacket gap if an authenticated packet was previously transmitted 350 and the authentication of the subsequent packet would otherwise burst 351 the packets more quickly. 353 This does not prevent the transmission of packets out of order 354 according to their order of authentication, only the timing of 355 packets that are transmitted, after authentication, in the same order 356 they were received. 358 For receiver applications, the time that the original packet was 359 received from the network SHOULD be made available to the receiving 360 application. 362 2.3. Packet Digests 364 2.3.1. Digest Profile 366 A packet digest is a message digest for a data packet, built 367 according to a digest profile defined by the sender. 369 The digest profile is defined by the sender, and specifies: 371 1. A cryptographically secure hash algorithm (REQUIRED) 373 2. A manifest stream identifier 375 3. Whether to hash the IP payload or the UDP payload. (see 376 Section 2.3.1.1) 378 The hash algorithm is applied to a pseudoheader followed by the 379 packet payload, as determined by the digest profile. The computed 380 hash value is the packet digest. 382 TBD: there should also be a way to specify that only packets to a 383 specific UDP port are applicable. I think this is not quite right 384 today and probably should be done with a grouping in the yang model, 385 so that the profile appears either inside a "protocol" container 386 inside the (S,G) or inside the udp-stream inside the "protocol", but 387 am not sure. Follow-up on this after the first reference 388 implementation... 390 TBD: As recommended by https://tools.ietf.org/html/rfc7696#section- 391 2.2 [1], a companion document containing the mandatory-to-implement 392 cipher suite should also be published separately and referenced by 393 this document. 395 2.3.1.1. Payload Type 397 2.3.1.1.1. UDP vs. IP payload validation 399 When the digest profile indicates that UDP payloads are validated, 400 the IP protocol for the packets MUST be UDP (0x11) and the payload 401 used for calculating the packet digest includes only the UDP payload, 402 with length as the number of UDP payload octets, as calculated by 403 subtracting the size of the UDP header from the UDP payload length. 405 When the digest profile indicates that IP payloads are validated, the 406 IP payload of the packet is used, using the outermost IP layer that 407 contains the (S,G) corresponding to the (S,G) protected by the 408 manifest. There is no restriction on the IP protocols that can be 409 authenticated. The length field in the pseudoheader is calculated by 410 subtracting the IP Header Length from the IP length, and is equal to 411 the number of octets in the payload for the digest calculation. 413 2.3.1.1.2. Motivation 415 Full IP payloads often aren't available to receivers without extra 416 privileges on end user operating systems, so it's useful to provide a 417 way to authenticate only the UDP payload, which is often the only 418 portion of the packet available to many receiving applications. 420 However, for some use cases a full IP payload is appropriate. For 421 example, when retrofitting some existing protocols, some packets may 422 be predictable or frequently repeated. Use of an IPSec 423 Authentication Header [RFC4302] is one way to disambiguate such 424 packets. Even though the shared secret means the Authentication 425 Header can't itself be used to authenticate the packet contents, the 426 sequence number in the Authentication Header can ensure that specific 427 packets are not repeated at the IP layer, and so it's useful for AMBI 428 to have the capability to authenticate such packets. 430 Another example: some services might need to authenticate the UDP 431 options [I-D.ietf-tsvwg-udp-options]. When using the UDP payload, 432 the UDP options would not be part of the authenticated payload, but 433 would be included when using the IP payload type. 435 Lastly, since (S,G) subscription operates at the IP layer, it's 436 possible that some non-UDP protocols will need to be authenticated. 438 2.3.2. Pseudoheader 440 When calculating the hash for the packet digest, the hash algorithm 441 is applied to a pseudoheader followed by the payload from the packet. 442 The complete sequence of octets used to calculate the hash is 443 structured as follows: 445 0 1 2 3 446 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 447 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 448 | Source Address (32 bits IPv4/128 bits IPv6) | 449 | ... | 450 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 451 | Destination Address (32 bits IPv4/128 bits IPv6) | 452 | ... | 453 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 454 | Zeroes | Protocol | Length | 455 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 456 | Source Port | Destination Port | 457 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 458 | Manifest Identifier | 459 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 460 | Payload Data | 461 | ... | 462 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 464 2.3.2.1. Source Address 466 The IPv4 or IPv6 source address of the packet. 468 2.3.2.2. Destination Address 470 The IPv4 or IPv6 destination address of the packet. 472 2.3.2.3. Zeroes 474 All bits set to 0. 476 2.3.2.4. Protocol 478 The IP Protocol field from IPv4, or the Next Header field for IPv6. 479 When UDP payload is indicated, this value MUST be UDP (0x11). 481 2.3.2.5. Length 483 The length in octets of the Payload Data field, expressed as an 484 unsigned 16-bit integer. 486 2.3.2.6. Source Port 488 The source port of the packet. Zeroes if using a protocol that does 489 not use source ports. 491 2.3.2.7. Destination Port 493 The destination port of the packet. Zeroes if using a protocol that 494 does not use destination ports. 496 TBD: there's something I hate about the source and destination ports. 497 Maybe it should only be active in UDP-payload mode, instead of zeroes 498 when not UDP? But I suspect there's a better approach than UDP-or- 499 not, so it's this way for now, with hopes of finding something better 500 in the next version. 502 2.3.2.8. Manifest Identifier 504 The 32-bit identifier for the manifest stream. 506 2.3.2.9. Payload Data 508 The payload data includes either the IP payload or the UDP payload, 509 as indicated by the digest profile. 511 The payload type is configurable because when sending UDP, some 512 legacy networks may strip the UDP option space, and it's necessary to 513 provide a manifest stream capable of authentication that can 514 interoperate with these networks. However, for non-UDP traffic or in 515 order to authenticate the UDP options, some use cases may require 516 support for authenticating the full IP payload. 518 2.4. Manifests 520 2.4.1. Manifest Layout 522 0 1 2 3 523 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 524 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 525 | Manifest Stream Identifier | 526 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 527 | Manifest sequence number | 528 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 529 | First packet sequence number | 530 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 531 | Refresh Deadline | Packet Digest Count | 532 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 533 | ... Packet Content Expansions ... | 534 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 535 | ... Packet Digests ... | 536 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 538 2.4.1.1. Manifest Stream Identifier 540 A 32-bit unsigned integer chosen by the sender. 542 2.4.1.2. Manifest Sequence Number 544 A monotonically increasing 32-bit unsigned integer. Each manifest 545 sent by the sender increases this value by 1. On overflow it wraps 546 to 0. 548 It's RECOMMENDED to expire the manifest stream and start a new stream 549 for the data packets before a sequence number wrap is necessary. 551 2.4.1.3. First Packet Sequence Number 553 A monotonically increasing 32-bit unsigned integer. Each packet in 554 the data stream increases this value by 1. 556 It's RECOMMENDED to expire the manifest stream and start a new stream 557 for the data packets before a sequence number wrap is necessary. 559 Note: for redundancy, especially if using a manifest stream with 560 unreliable transport, successive manifests MAY provide duplicates of 561 the same packet digest with the same packet sequence number, using 562 overapping sets of packet sequence numbers. When received, these 563 reset the hold timer for the listed packet digests. 565 2.4.1.4. Refresh Deadline 567 A 16-bit unsigned integer number of seconds. 569 A zero value means the current digest profile for the current 570 manifest stream is stable. 572 A nonzero value means that the authentication is transitioning to a 573 new manifest stream, and the set of digest profiles SHOULD be 574 refreshed by receivers that might stay joined longer than this 575 duration, and a different manifest stream SHOULD be selected, before 576 this many seconds have elapsed, in order to avoid a disruption. See 577 Section 2.5. 579 2.4.1.5. Packet Digest Count 581 The count of packet digests in the manifest. 583 2.4.1.6. Packet Digests 585 Packet digests appended one after the other, aligned to 8-bit 586 boundaries with zero padding (if the bit length of the digests are 587 not multiples of 8 bits). 589 2.5. Transitioning to Other Manifest Streams 591 It's possible for multiple manifest streams authenticating the same 592 data stream to be active at the same time. The different manifest 593 streams can have different hash algorithms, manifest ids, and current 594 packet sequence numbers for the same data stream. These result in 595 different sets of packet digests for the same data packets, one 596 digest per packet per digest profile. 598 It's necessary sometimes to transition gracefully from one manifest 599 stream to another. The Refresh Deadline field from the manifest is 600 used to signal to receivers the need to transition. 602 When a receiver gets a nonzero refresh deadline in a manifest the 603 sender SHOULD have an alternate manifest stream ready and available, 604 and the receiver SHOULD learn the alternate manifest stream, join the 605 new one, and leave the old one before the number of seconds given in 606 the refresh deadline. After the refresh deadline has expired, a 607 manifest stream MAY end. 609 The receivers SHOULD use a random value between now and one half the 610 number of seconds in the deadline field, to spread the spike of load 611 on the DORMS server during a large multicast event. 613 3. Transport Considerations 615 3.1. Overview 617 AMBI manifests MUST be authenticated, but any transport protocol 618 providing authentication can be used. This section discusses several 619 viable options for the use of an authenticating transport, and some 620 associated design considerations. 622 TBD: extend the 'manifest-transport' in the YANG model to make an 623 extensible mechanism to advertise different transport options for 624 receiving manifest streams. 626 TBD: add ALTA to the list when and if it gets further along 627 [I-D.draft-krose-mboned-alta-01]. Sending an authenticatable 628 multicast stream (instead of the below unicast-based proposals) is a 629 worthwhile goal, else a 1% unicast authentication overhead becomes a 630 new unicast limit to the scalability. 632 TBD: add a recommendation about scalability, like with DORMS, when 633 using a unicast hash stream. CDN or other kind of fanout solution 634 that can scale the delivery, and still generally hit the time window. 636 3.2. HTTPS 638 This document defines a new media type 'application/ambi' for use 639 with HTTPS. 641 An HTTPS stream carrying the 'application/ambi' media type is 642 composed of a sequence of binary AMBI manifests. It is RECOMMENDED 643 to use Chunked encoding. 645 Complete packet Digests from partially received manifests MAY be used 646 by the receiver for authentication, even if the full manifest is not 647 yet delivered. 649 3.3. DTLS 651 TBD: DTLS [RFC6347] can provide authentication for datagrams, so if 652 manifests can be constructed to fit within datagrams, it is an 653 appropriate choice. (IPSec is similar-worth adding as an option?). 655 This option provides no native redundancy or retransmission, but 656 packet digests can be repeated in different manifests to provide some 657 resilience to loss. Lost manifests that result in the loss of blocks 658 of packet digests can be expensive, since they would make received 659 data packets unauthenticatable. TBD: should we therefore not support 660 this case? (probably still worthwhile-the manifests can still contain 661 redundant hashes) 663 3.4. DTLS + FECFRAME 665 DTLS for manifests that do not fit into single-packet payloads can 666 still be delivered by using FECFRAME [RFC6363], particularly Reed- 667 Solomon [RFC6865] or possibly Raptor [RFC6681]. This has some 668 advantages compared to HTTPS because of the absence of HOL-blocking, 669 while providing for tunable redundancy. This has some advantages 670 relative to DTLS because of overhead reduction and non-integer 671 redundancy tunability (e.g. 1.5 becomes a viable redundancy factor). 673 TBD: define this method, possibly in another RFC. 675 4. Examples 677 TBD: walk through some examples as soon as we have a build running. 678 Likely to need some touching up. 680 5. YANG Module 682 5.1. Tree Diagram 684 The tree diagram below follows the notation defined in [RFC8340]. 686 module: ietf-ambi 687 augment /dorms:metadata/dorms:sender/dorms:group/dorms:udp-stream: 688 +--rw manifest-stream* [id] 689 +--rw id uint32 690 +--rw manifest-transport* inet:uri 691 +--rw hash-algorithm iha:hash-algorithm-type 692 +--rw payload-type enumeration 693 +--rw data-hold-time-ms? uint32 694 +--rw digest-hold-time-ms? uint32 696 5.2. Module 698 file ietf-ambi@2020-10-31.yang 699 module ietf-ambi { 700 yang-version 1.1; 702 namespace "urn:ietf:params:xml:ns:yang:ietf-ambi"; 703 prefix "ambi"; 705 import ietf-dorms { 706 prefix "dorms"; 707 reference "I-D.jholland-mboned-dorms"; 708 } 710 import ietf-inet-types { 711 prefix "inet"; 712 reference "RFC6991 Section 4"; 713 } 715 import iana-hash-algs { 716 prefix "iha"; 717 reference "draft-ietf-netconf-crypto-types"; 718 } 720 organization "IETF"; 722 contact 723 "Author: Jake Holland 724 725 "; 727 description 728 "Copyright (c) 2019 IETF Trust and the persons identified as 729 authors of the code. All rights reserved. 731 Redistribution and use in source and binary forms, with or 732 without modification, is permitted pursuant to, and subject to 733 the license terms contained in, the Simplified BSD License set 734 forth in Section 4.c of the IETF Trust's Legal Provisions 735 Relating to IETF Documents 736 (https://trustee.ietf.org/license-info). 738 This version of this YANG module is part of RFC XXXX 739 (https://www.rfc-editor.org/info/rfcXXXX); see the RFC itself 740 for full legal notices. 742 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL 743 NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED', 744 'MAY', and 'OPTIONAL' in this document are to be interpreted as 745 described in BCP 14 (RFC 2119) (RFC 8174) when, and only when, 746 they appear in all capitals, as shown here. 748 This module contains the definition for the AMBI data types. 749 It provides metadata for authenticating SSM channels as an 750 augmentation to DORMS."; 752 revision 2019-08-25 { 753 description "Initial revision as an extension."; 754 reference 755 ""; 756 } 758 augment 759 "/dorms:metadata/dorms:sender/dorms:group/dorms:udp-stream" { 760 description "Definition of the manifest stream providing 761 integrity info for the data stream"; 763 list manifest-stream { 764 key id; 765 description "Definition of a manifest stream."; 766 leaf id { 767 type uint32; 768 mandatory true; 769 description 770 "The Manifest ID referenced in a manifest."; 771 } 772 leaf-list manifest-transport { 773 type inet:uri; 774 description "A URI that provides a location for the 775 manifest stream"; 776 } 777 leaf hash-algorithm { 778 type iha:hash-algorithm-type; 779 mandatory true; 780 description 781 "The hash algorithm for the packet hashes within 782 manifests in this stream."; 783 } 784 leaf payload-type { 785 type enumeration { 786 enum udp { 787 description "The hash includes only the UDP 788 payload."; 789 } 790 enum ip { 791 description "The hash includes the full IP 792 payload."; 793 } 794 } 795 mandatory true; 796 description "The contents of the payload for the 797 digest profile"; 798 } 799 leaf data-hold-time-ms { 800 type uint32; 801 default 2000; 802 description 803 "The number of milliseconds to hold data 804 packets waiting for a corresponding digest before 805 discarding"; 806 } 807 leaf digest-hold-time-ms { 808 type uint32; 809 default 10000; 810 description 811 "The number of milliseconds to hold packet 812 digests waiting for a corresponding data packet 813 before discarding"; 814 } 815 } 816 } 817 } 819 821 6. IANA Considerations 823 6.1. The YANG Module Names Registry 825 This document adds one YANG module to the "YANG Module Names" 826 registry maintained at . The following registrations are made, per the format in 828 Section 14 of [RFC6020]: 830 name: ietf-ambi 831 namespace: urn:ietf:params:xml:ns:yang:ietf-ambi 832 prefix: ambi 833 reference: I-D.draft-jholland-mboned-ambi 835 6.2. The XML Registry 837 This document adds the following registration to the "ns" subregistry 838 of the "IETF XML Registry" defined in [RFC3688], referencing this 839 document. 841 URI: urn:ietf:params:xml:ns:yang:ietf-ambi 842 Registrant Contact: The IESG. 843 XML: N/A, the requested URI is an XML namespace. 845 6.3. Media Type 847 TBD: Register 'application/ambi' according to advice from: 848 https://www.iana.org/form/media-types 850 TBD: check guidelines in https://tools.ietf.org/html/rfc5226 852 7. Security Considerations 854 7.1. Predictable Packets 856 Protocols that have predictable packets run the risk of offline 857 attacks for hash collisions against those packets. When 858 authenticating a protocol that might have predictable packets, it's 859 RECOMMENDED to use a hash function secure against such attacks or to 860 add content to the packets to make them unpredictable, such as an 861 Authentication Header ([RFC4302]), or the addition of an ignored 862 field with random content to the packet payload. 864 TBD: explain attack from generating malicious packets and then 865 looking for collisions, as opposed to having to generate a collision 866 on packet contents that include a sequence number and then hitting a 867 match. 869 TBD: follow the rest of the guidelines: https://tools.ietf.org/html/ 870 rfc3552 872 8. Acknowledgements 874 Many thanks to Daniel Franke, Eric Rescorla, Christian Worm 875 Mortensen, Max Franke, and Albert Manfredi for their very helpful 876 comments and suggestions. 878 9. References 880 9.1. Normative References 882 [I-D.draft-ietf-mboned-dorms-00] 883 Holland, J., "Discovery Of Restconf Metadata for Source- 884 specific multicast", draft-ietf-mboned-dorms-00 (work in 885 progress), March 2020. 887 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 888 Requirement Levels", BCP 14, RFC 2119, 889 DOI 10.17487/RFC2119, March 1997, 890 . 892 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 893 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 894 January 2012, . 896 [RFC6363] Watson, M., Begen, A., and V. Roca, "Forward Error 897 Correction (FEC) Framework", RFC 6363, 898 DOI 10.17487/RFC6363, October 2011, 899 . 901 [RFC6681] Watson, M., Stockhammer, T., and M. Luby, "Raptor Forward 902 Error Correction (FEC) Schemes for FECFRAME", RFC 6681, 903 DOI 10.17487/RFC6681, August 2012, 904 . 906 [RFC6865] Roca, V., Cunche, M., Lacan, J., Bouabdallah, A., and K. 907 Matsuzono, "Simple Reed-Solomon Forward Error Correction 908 (FEC) Scheme for FECFRAME", RFC 6865, 909 DOI 10.17487/RFC6865, February 2013, 910 . 912 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 913 RFC 7950, DOI 10.17487/RFC7950, August 2016, 914 . 916 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 917 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 918 May 2017, . 920 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 921 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 922 . 924 9.2. Informative References 926 [I-D.draft-krose-mboned-alta-01] 927 Rose, K. and J. Holland, "Asymmetric Loss-Tolerant 928 Authentication", draft-krose-mboned-alta-01 (work in 929 progress), July 2019. 931 [I-D.ietf-tsvwg-udp-options] 932 Touch, J., "Transport Options for UDP", draft-ietf-tsvwg- 933 udp-options-08 (work in progress), September 2019. 935 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 936 Text on Security Considerations", BCP 72, RFC 3552, 937 DOI 10.17487/RFC3552, July 2003, 938 . 940 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 941 DOI 10.17487/RFC3688, January 2004, 942 . 944 [RFC4082] Perrig, A., Song, D., Canetti, R., Tygar, J., and B. 945 Briscoe, "Timed Efficient Stream Loss-Tolerant 946 Authentication (TESLA): Multicast Source Authentication 947 Transform Introduction", RFC 4082, DOI 10.17487/RFC4082, 948 June 2005, . 950 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, 951 DOI 10.17487/RFC4302, December 2005, 952 . 954 [RFC4383] Baugher, M. and E. Carrara, "The Use of Timed Efficient 955 Stream Loss-Tolerant Authentication (TESLA) in the Secure 956 Real-time Transport Protocol (SRTP)", RFC 4383, 957 DOI 10.17487/RFC4383, February 2006, 958 . 960 [RFC5776] Roca, V., Francillon, A., and S. Faurite, "Use of Timed 961 Efficient Stream Loss-Tolerant Authentication (TESLA) in 962 the Asynchronous Layered Coding (ALC) and NACK-Oriented 963 Reliable Multicast (NORM) Protocols", RFC 5776, 964 DOI 10.17487/RFC5776, April 2010, 965 . 967 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 968 the Network Configuration Protocol (NETCONF)", RFC 6020, 969 DOI 10.17487/RFC6020, October 2010, 970 . 972 9.3. URIs 974 [1] https://tools.ietf.org/html/rfc7696#section-2.2 976 Authors' Addresses 978 Jake Holland 979 Akamai Technologies, Inc. 980 150 Broadway 981 Cambridge, MA 02144 982 United States of America 984 Email: jakeholland.net@gmail.com 986 Kyle Rose 987 Akamai Technologies, Inc. 988 150 Broadway 989 Cambridge, MA 02144 990 United States of America 992 Email: krose@krose.org