idnits 2.17.1 draft-jholland-mboned-ambi-05.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 (March 09, 2020) is 1499 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-02) exists of draft-jholland-mboned-dorms-01 ** 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 (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Mboned J. Holland 3 Internet-Draft K. Rose 4 Intended status: Standards Track Akamai Technologies, Inc. 5 Expires: September 10, 2020 March 09, 2020 7 Asymmetric Manifest Based Integrity 8 draft-jholland-mboned-ambi-05 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 September 10, 2020. 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 . . . . . . . . . . . . . . . . . . . . . . 5 56 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 57 2. Protocol Operation . . . . . . . . . . . . . . . . . . . . . 5 58 2.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 5 59 2.2. Buffering and Validation Windows . . . . . . . . . . . . 6 60 2.2.1. Inter-packet Gap . . . . . . . . . . . . . . . . . . 7 61 2.3. Packet Digests . . . . . . . . . . . . . . . . . . . . . 8 62 2.3.1. Digest Profile . . . . . . . . . . . . . . . . . . . 8 63 2.3.2. Pseudoheader . . . . . . . . . . . . . . . . . . . . 11 64 2.4. Manifests . . . . . . . . . . . . . . . . . . . . . . . . 12 65 2.4.1. Manifest Layout . . . . . . . . . . . . . . . . . . . 13 66 2.5. Transitioning to Other Manifest Streams . . . . . . . . . 14 67 3. Transport Considerations . . . . . . . . . . . . . . . . . . 15 68 3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 15 69 3.2. HTTPS . . . . . . . . . . . . . . . . . . . . . . . . . . 15 70 3.3. DTLS . . . . . . . . . . . . . . . . . . . . . . . . . . 15 71 3.4. DTLS + FECFRAME . . . . . . . . . . . . . . . . . . . . . 16 72 4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 16 73 5. YANG Module . . . . . . . . . . . . . . . . . . . . . . . . . 16 74 5.1. Tree Diagram . . . . . . . . . . . . . . . . . . . . . . 16 75 5.2. Module . . . . . . . . . . . . . . . . . . . . . . . . . 16 76 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 77 6.1. The YANG Module Names Registry . . . . . . . . . . . . . 19 78 6.2. Media Type . . . . . . . . . . . . . . . . . . . . . . . 19 79 7. Security Considerations . . . . . . . . . . . . . . . . . . . 19 80 7.1. Predictable Packets . . . . . . . . . . . . . . . . . . . 19 81 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20 82 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 83 9.1. Normative References . . . . . . . . . . . . . . . . . . 20 84 9.2. Informative References . . . . . . . . . . . . . . . . . 21 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 87 1. Introduction 89 Multicast transport poses security problems that are not easily 90 addressed by the same security mechanisms used for unicast transport. 92 The "Introduction" sections of the documents describing TESLA 93 [RFC4082], and TESLA in SRTP [RFC4383], and TESLA with ALC and NORM 94 [RFC5776] present excellent overviews of the challenges unique to 95 multicast authentication, briefly summarized here: 97 o A MAC based on a symmetric shared secret cannot be used because 98 each packet has multiple receivers that do not trust each other, 99 and using a symmetric shared secret exposes the same secret to 100 each receiver. 102 o Asymmetric per-packet signatures can handle only very low bit- 103 rates because of the computational overhead. 105 o An asymmetric signature of a larger message comprising multiple 106 packets requires reliable receipt of all such packets, something 107 that cannot be guaranteed in a timely manner even for protocols 108 that do provide reliable delivery, and the retransmission of which 109 may anyway exceed the useful lifetime for data formats that can 110 otherwise tolerate some degree of loss. 112 Aymmetric Manifest-Based Integrity (AMBI) defines a method for 113 receivers or middle boxes to cryptographically authenticate and 114 verify the integrity of a stream of packets, by communicating packet 115 "manifests" (described in Section 2.4) via an out-of-band 116 communication channel that provides authentication and verifiable 117 integrity. 119 Each manifest contains a message digest (described in Section 2.3) 120 for each packet in a sequence of packets from the data stream, 121 hereafter called a "packet digest". The packet digest incorporates a 122 cryptographic hash of the packet contents and some identifying data 123 from the packet, according to a defined digest profile for the data 124 stream. 126 Each manifest MUST be delivered in a way that provides cryptographic 127 integrity guarantees of the authenticity of the manifest. For 128 example, TLS could be used to deliver a stream of manifests over a 129 unicast data stream from a set of trusted senders to each receiver, 130 or a protocol that asymmetrically signs each message could be used to 131 transport authenticated manifests over a multicast channel. Note 132 that a UDP-based protocol might drop or reorder manifests while still 133 providing authentication. 135 Upon successful verification of a manifest and receipt of any subset 136 of the corresponding data packets, the receiver has proof of the 137 integrity of the contents of the data packets that are listed in the 138 manifest. 140 Authenticating the integrity of the data packets depends on: 142 o the authenticity of the manifests; and 143 o the authenticity of the digest profile used for construction of 144 the packet digests; and 146 o the difficulty of generating a collision for the packet digests 147 contained in the manifest. 149 This document defines a YANG [RFC7950] module that augments the DORMS 150 [I-D.draft-jholland-mboned-dorms-01] YANG module to provide a way to 151 communicate a digest profile, described in Section 2.3.1, for 152 construction of the packet digests, described in Section 2.3. When 153 obtaining the digest profile by using DORMS, the authenticity of the 154 data stream relies on a trust relationship with the DORMS server, 155 since that anchors the authenticity of the digest profile for 156 constructing packet digests. 158 1.1. Comparison with TESLA 160 AMBI and TESLA [RFC4082] and [RFC5776] attempt to achieve a similar 161 goal of authenticating the integrity of streams of multicast packets. 162 AMBI imposes a higher overhead, as measured in the amount of extra 163 data required, than TESLA imposes. In exchange, AMBI provides non- 164 repudiation (which TESLA does not), and relaxes the requirement for 165 establishing an upper bound on clock synchronization between sender 166 and receiver. 168 This tradeoff enables new capabilities for AMBI, relative to TESLA. 169 In particular, when receiving multicast traffic from an untrusted 170 transit network, AMBI can be used by a middle box to authenticate 171 packets from a trusted source before forwarding traffic through the 172 network, and the receiver also can separately authenticate the 173 packets it receives. 175 This use case is not possible with TESLA because the data packets 176 can't be authenticated until a key is disclosed, so either the 177 middlebox has to forward data packets without first authenticating 178 them, so that the receiver has them prior to key disclosure, or the 179 middlebox has to hold packets until the key is disclosed, at which 180 point the receiver can no longer establish their authenticity. 182 The other new capability is that because AMBI provides authentication 183 information out of band, authentication can be retrofitted into some 184 pre-existing deployments without changing the protocol of the data 185 packets, under some restrictions outlined in Section 7. By contrast, 186 TESLA requires a MAC to be added to each authenticated message. 188 1.2. Threat Model 190 TBD: Summarize the applicable threat model this protects against. A 191 diagram plus a cleaned-up version of the on-list explanation here is 192 probably appropriate: https://mailarchive.ietf.org/arch/msg/mboned/ 193 CG9FLjPwuno3MtvYvgNcD5p69I4/ 195 1.3. Terminology 197 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 198 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 199 "OPTIONAL" in this document are to be interpreted as described in 200 [RFC2119] and [RFC8174] when, and only when, they appear in all 201 capitals, as shown here. 203 2. Protocol Operation 205 2.1. Overview 207 In order to authenticate a data packet, AMBI receivers need to hold 208 these three pieces of information at the same time: 210 o the data packet; and 212 o an authenticated manifest containing the packet digest for the 213 data packet; and 215 o a digest profile defining the transformation from the data packet 216 to its packet digest. 218 The manifests are delivered as a stream of manifests over an 219 authenticated data channel. Manifest contents MUST be authenticated 220 before they can be used to authenticate data packets. 222 The manifest stream is composed of an ordered sequence of manifests 223 that each contain an ordered sequence of packet digests, 224 corresponding to the original packets as sent from their origin, in 225 the same order. 227 Note that a manifest contains potentially many packet digests, and 228 its size can be tuned to fit within a convenient PDU (Protocol Data 229 Unit) of the manifest transport stream, so that usually, many packet 230 digests for the multicast data stream can be delivered per packet of 231 the manifest transport. The intent is that even with unicast-based 232 manifest transport, multicast-style efficiencies of scale can still 233 be realized, with only a relatively small unicast overhead, when 234 manifests use a unicast transport. 236 2.2. Buffering and Validation Windows 238 Using different communication channels for the manifest stream and 239 the data stream introduces a possibility of desynchronization in the 240 timing of the received data between the different channels, so 241 receivers hold data packets and packet digests from the manifest 242 stream in buffers for some duration while awaiting the arrival of 243 their counterparts. 245 While holding a data packet, if the corresponding packet digest for 246 that packet arrives in the manifest stream and can be authenticated, 247 the data packet is authenticated. 249 While holding an authenticated packet digest, if the corresponding 250 data packet arrives with a matching packet digest, the data packet is 251 authenticated. 253 Once a data packet is authenticated, the corresponding packet digest 254 can be discarded and the data packet can be further processed by the 255 receiving application or forwarded through the receiving network. 256 Authenticating a data packet consumes one packet digest and prevents 257 re-learning, with a hold-down time equal to the hold time for packet 258 digests. A different manifest might provide the same packet digest 259 with the same packet sequence number, but the digest remains consumed 260 if it has been used to authenticate a data packet. 262 If the receiver's hold duration for a data packet expires without 263 authenticating the packet, the packet SHOULD be dropped as 264 unauthenticated. If the hold duration of a manifest expires, packet 265 digests last received in that manifest SHOULD be discarded. (Note 266 that in some cases, packet digests can be sent redundantly in more 267 than one manifest. In such cases, the latest received time for an 268 authenticated packet digest should be used for the expiration time.) 270 Since packet digests are usually smaller than the data packets, it's 271 RECOMMENDED that senders generate and send manifests with timing such 272 that the packet digests in a manifest will typically be received by 273 subscribed receivers before the data packets corresponding to those 274 digests are received. 276 This strategy reduces the buffering requirements at receivers at, the 277 cost of introducing some buffering of data packets at the sender, 278 since data packets are generated before their packet digests can be 279 added to manifests. 281 The RECOMMENDED default hold times at receivers are: 283 o 2 seconds for data packets 284 o 10 seconds for packet digests 286 The sender MAY recommend different values for specific data streams, 287 in order to tune different data streams for different performance 288 goals. The YANG model in Section 5 provides a mechanism for senders 289 to communicate the sender's recommendation for buffering durations, 290 when using DORMS. 292 Receivers SHOULD follow the recommendations for hold times provided 293 by the sender, subject to their capabilities and any administratively 294 configured limits on buffer sizes at the receiver. 296 However receivers MAY deviate from the values recommended by the 297 sender for a variety of reasons. Decreasing the buffering durations 298 recommended by the server increases the risk of losing packets, but 299 can be an appropriate tradeoff for specific network conditions and 300 hardware constraints on some devices. 302 TBD: should there be any reordering restrictions above and beyond the 303 timing constraints? 305 2.2.1. Inter-packet Gap 307 It's RECOMMENDED that middle boxes forwarding buffered data packets 308 preserve the inter-packet gap between packets, and that receiving 309 libraries provide mechanisms to expose the network arrival times of 310 packets to applications. 312 The purpose for this recommendation is to preserve the capability of 313 receivers to use techniques for available bandwidth detection or 314 network congestion based on observation of packet times. Examples of 315 such techniques include paced chirping and pathrate. 317 Note that this recommendation SHOULD NOT prevent the transmission of 318 an authenticated packet because the prior packet is unauthenticated. 319 This recommendation only asks implementations to delay the 320 transmission of an authenticated packet to correspond to the 321 interpacket gap if an authenticated packet was previously transmitted 322 and the authentication of the subsequent packet would otherwise burst 323 the packets more quickly. 325 This does not prevent the transmission of packets out of order 326 according to their order of authentication, only the timing of 327 packets that are transmitted, after authentication, in the same order 328 they were received. 330 For receiver applications, the time that the original packet was 331 received from the network SHOULD be made available to the receiving 332 application. 334 2.3. Packet Digests 336 2.3.1. Digest Profile 338 A packet digest is a message digest for a data packet, built 339 according to a digest profile defined by the sender. 341 The digest profile is defined by the sender, and specifies: 343 1. A cryptographically secure hash algorithm (REQUIRED) 345 2. A manifest stream identifier 347 3. Whether to hash the IP payload or the UDP payload. (see 348 Section 2.3.1.1) 350 The hash algorithm is applied to a pseudoheader followed by the 351 packet payload, as determined by the digest profile. The computed 352 hash value is the packet digest. 354 TBD: there should also be a way to specify that only packets to a 355 specific UDP port are applicable. I think this is not quite right 356 today and probably should be done with a grouping in the yang model, 357 so that the profile appears either inside a "protocol" container 358 inside the (S,G) or inside the udp-stream inside the "protocol", but 359 am not sure. Follow-up on this after the first reference 360 implementation... 362 2.3.1.1. Payload Type 364 2.3.1.1.1. UDP vs. IP payload validation 366 When the digest profile indicates that UDP payloads are validated, 367 the IP protocol for the packets MUST be UDP (0x11) and the payload 368 used for calculating the packet digest includes only the UDP payload, 369 with length as the number of UDP payload octets, as calculated by 370 subtracting the size of the UDP header from the UDP payload length. 372 When the digest profile indicates that IP payloads are validated, the 373 IP payload of the packet is used, using the outermost IP layer that 374 contains the (S,G) corresponding to the (S,G) protected by the 375 manifest. There is no restriction on the IP protocols that can be 376 authenticated. The length field in the pseudoheader is calculated by 377 subtracting the IP Header Length from the IP length, and is equal to 378 the number of octets in the payload for the digest calculation. 380 2.3.1.1.2. Motivation 382 Full IP payloads often aren't available to receivers without extra 383 privileges on end user operating systems, so it's useful to provide a 384 way to authenticate only the UDP payload, which is often the only 385 portion of the packet available to many receiving applications. 387 However, for some use cases a full IP payload is appropriate. For 388 example, when retrofitting some existing protocols, some packets may 389 be predictable or frequently repeated. Use of an IPSec 390 Authentication Header [RFC4302] is one way to disambiguate such 391 packets. Even though the shared secret means the Authentication 392 Header can't itself be used to authenticate the packet contents, the 393 sequence number in the Authentication Header can ensure that specific 394 packets are not repeated at the IP layer, and so it's useful for AMBI 395 to have the capability to authenticate such packets. 397 Another example: some services might need to authenticate the UDP 398 options [I-D.ietf-tsvwg-udp-options]. When using the UDP payload, 399 the UDP options would not be part of the authenticated payload, but 400 would be included when using the IP payload type. 402 Lastly, since (S,G) subscription operates at the IP layer, it's 403 possible that some non-UDP protocols will need to be authenticated. 405 2.3.1.2. TBD: Packet contents? 407 TBD: Determine whether we need to support packet contents in the 408 packet digest. If so, add to above list in Section 2.3.1: 410 o A set of bits from the packet contents (potentially empty) 412 The packet contents are a sequence of bits composed from a sequence 413 of fixed bit (offset, length) pairs, as specified in xxxxxx. A 414 useful choice for packet contents is to use sequence numbers in the 415 application level protocol, such as with RTP [RFC3550], but any 416 contents from the packet with a fixed bit offset and length can be 417 used. 419 Providing variable packet contents in the packet digest increases the 420 difficulty of attacking the hash by limiting the scope of legitimate 421 data packets that can be matched when attempting to generate a hash 422 collision. 424 The basic idea is to put an encoding here so that for example the RTP 425 sequence number or the sequence number in an Authentication Header 426 can be provided here in bulk (you give "value starts at bit 80 and is 427 16 bits long unsigned and increases by 1 per packet for the packets 428 in the manifest with starting value 10", indicating that the 100 429 packets in the manifest have values 10-110 in their contents at the 430 given location. Now those contents are prepended to the packet 431 digest, and can be verified against the packets, as well as the hash 432 of the contents). 434 For packet streams without a sequence number, we can instead 435 incorporate a few high-entropy bits from the packet contents and NOT 436 provide the value as a sequence number, but rather incorporate it in 437 the digest values themselves. (Is this useful?) 439 Before defining this, I want to calculate how much overhead it buys 440 us- how much can we truncate a good hash algorithm if we use this to 441 add collision resistance? Might not be worthwhile, it's a 442 significant increase in complexity. -jake 2019-08-31 444 If we need it, tentative addition to yang for the data profile looks 445 like: 447 list packet-contents { 448 key offset; 449 description "contents from the packet for the packet 450 digest"; 451 leaf offset { 452 type uint16; 453 mandatory true; 454 description "offset of the contents, in number of bits"; 455 } 456 leaf length { 457 type uint16; 458 mandatory true; 459 description "length of the contents, in number of bits"; 460 } 461 leaf manifest-delivery { 462 type enumeration { 463 enum sequence; 464 enum digest; 465 } 466 mandatory true; 467 description "the way these content bits are delivered in 468 the manifest"; 469 } 470 } 472 The manifest-delivery would indicate whether the bits are a sequence 473 number (in which case a section for a manifest with a start+step 474 would be added ahead of the digests), or digest (indicating the bits 475 appear inside each digest, ahead of the hash), and they would prepend 476 in order to the packet digest, with sequence number bits inserted at 477 the right bit location for the digest, based on earlier-appearing 478 values, if any. 480 2.3.2. Pseudoheader 482 When calculating the hash for the packet digest, the hash algorithm 483 is applied to a pseudoheader followed by the payload from the packet. 484 The complete sequence of octets used to calculate the hash is 485 structured as follows: 487 0 1 2 3 488 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 489 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 490 | Source Address (32 bits IPv4/128 bits IPv6) | 491 | ... | 492 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 493 | Destination Address (32 bits IPv4/128 bits IPv6) | 494 | ... | 495 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 496 | Zeroes | Protocol | Length | 497 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 498 | Source Port | Destination Port | 499 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 500 | Manifest Identifier | 501 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 502 | Payload Data | 503 | ... | 504 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 506 2.3.2.1. Source Address 508 The IPv4 or IPv6 source address of the packet. 510 2.3.2.2. Destination Address 512 The IPv4 or IPv6 destination address of the packet. 514 2.3.2.3. Zeroes 516 All bits set to 0. 518 2.3.2.4. Protocol 520 The IP Protocol field from IPv4, or the Next Header field for IPv6. 521 When UDP payload is indicated, this value MUST be UDP (0x11). 523 2.3.2.5. Length 525 The length in octets of the Payload Data field, expressed as an 526 unsigned 16-bit integer. 528 2.3.2.6. Source Port 530 The source port of the packet. Zeroes if using a protocol that does 531 not use source ports. 533 2.3.2.7. Destination Port 535 The destination port of the packet. Zeroes if using a protocol that 536 does not use destination ports. 538 TBD: there's something I hate about the source and destination ports. 539 Maybe it should only be active in UDP-payload mode, instead of zeroes 540 when not UDP? But I suspect there's a better approach than UDP-or- 541 not, so it's this way for now, with hopes of finding something better 542 in the next version. 544 2.3.2.8. Manifest Identifier 546 The 32-bit identifier for the manifest stream. 548 2.3.2.9. Payload Data 550 The payload data includes either the IP payload or the UDP payload, 551 as indicated by the digest profile. 553 The payload type is configurable because when sending UDP, some 554 legacy networks may strip the UDP option space, and it's necessary to 555 provide a manifest stream capable of authentication that can 556 interoperate with these networks. However, for non-UDP traffic or in 557 order to authenticate the UDP options, some use cases may require 558 support for authenticating the full IP payload. 560 2.4. Manifests 561 2.4.1. Manifest Layout 563 0 1 2 3 564 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 565 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 566 | Manifest Stream Identifier | 567 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 568 | Manifest sequence number | 569 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 570 | First packet sequence number | 571 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 572 | Refresh Deadline | Packet Digest Count | 573 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 574 | ... Packet Content Expansions ... | 575 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 576 | ... Packet Digests ... | 577 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 579 2.4.1.1. Manifest Stream Identifier 581 A 32-bit unsigned integer chosen by the sender. 583 2.4.1.2. Manifest Sequence Number 585 A monotonically increasing 32-bit unsigned integer. Each manifest 586 sent by the sender increases this value by 1. On overflow it wraps 587 to 0. 589 It's RECOMMENDED to expire the manifest stream and start a new stream 590 for the data packets before a sequence number wrap is necessary. 592 2.4.1.3. First Packet Sequence Number 594 A monotonically increasing 32-bit unsigned integer. Each packet in 595 the data stream increases this value by 1. 597 It's RECOMMENDED to expire the manifest stream and start a new stream 598 for the data packets before a sequence number wrap is necessary. 600 Note: for redundancy, especially if using a manifest stream with 601 unreliable transport, successive manifests MAY provide duplicates of 602 the same packet digest with the same packet sequence number, using 603 overapping sets of packet sequence numbers. When received, these 604 reset the hold timer for the listed packet digests. 606 2.4.1.4. Refresh Deadline 608 A 16-bit unsigned integer number of seconds. 610 A zero value means the current digest profile for the current 611 manifest stream is stable. 613 A nonzero value means that the authentication is transitioning to a 614 new manifest stream, and the set of digest profiles SHOULD be 615 refreshed by receivers that might stay joined longer than this 616 duration, and a different manifest stream SHOULD be selected, before 617 this many seconds have elapsed, in order to avoid a disruption. See 618 Section 2.5. 620 2.4.1.5. Packet Digest Count 622 The count of packet digests in the manifest. 624 2.4.1.6. Packet Digests 626 Packet digests appended one after the other, aligned to 8-bit 627 boundaries with zero padding (if the bit length of the digests are 628 not multiples of 8 bits). 630 2.5. Transitioning to Other Manifest Streams 632 It's possible for multiple manifest streams authenticating the same 633 data stream to be active at the same time. The different manifest 634 streams can have different hash algorithms, manifest ids, and current 635 packet sequence numbers for the same data stream. These result in 636 different sets of packet digests for the same data packets, one 637 digest per packet per digest profile. 639 It's necessary sometimes to transition gracefully from one manifest 640 stream to another. The Refresh Deadline field from the manifest is 641 used to signal to receivers the need to transition. 643 When a receiver gets a nonzero refresh deadline in a manifest the 644 sender SHOULD have an alternate manifest stream ready and available, 645 and the receiver SHOULD learn the alternate manifest stream, join the 646 new one, and leave the old one before the number of seconds given in 647 the refresh deadline. After the refresh deadline has expired, a 648 manifest stream MAY end. 650 The receivers SHOULD use a random value between now and one half the 651 number of seconds in the deadline field, to spread the spike of load 652 on the DORMS server during a large multicast event. 654 3. Transport Considerations 656 3.1. Overview 658 AMBI manifests MUST be authenticated, but any transport protocol 659 providing authentication can be used. This section discusses several 660 viable options for the use of an authenticating transport, and some 661 associated design considerations. 663 TBD: extend the 'manifest-transport' in the YANG model to make an 664 extensible mechanism to advertise different transport options for 665 receiving manifest streams. 667 TBD: add ALTA to the list when and if it gets further along 668 [I-D.draft-krose-mboned-alta-01]. Sending an authenticatable 669 multicast stream (instead of the below unicast-based proposals) is a 670 worthwhile goal, else a 1% unicast authentication overhead becomes a 671 new unicast limit to the scalability. 673 3.2. HTTPS 675 This document defines a new media type 'application/ambi' for use 676 with HTTPS. 678 An HTTPS stream carrying the 'application/ambi' media type is 679 composed of a sequence of binary AMBI manifests. It is RECOMMENDED 680 to use Chunked encoding. 682 Complete packet Digests from partially received manifests MAY be used 683 by the receiver for authentication, even if the full manifest is not 684 yet delivered. 686 3.3. DTLS 688 TBD: DTLS [RFC6347] can provide authentication for datagrams, so if 689 manifests can be constructed to fit within datagrams, it is an 690 appropriate choice. (IPSec is similar-worth adding as an option?). 692 This option provides no native redundancy or retransmission, but 693 packet digests can be repeated in different manifests to provide some 694 resilience to loss. Lost manifests that result in the loss of blocks 695 of packet digests can be expensive, since they would make received 696 data packets unauthenticatable. TBD: should we therefore not support 697 this case? 699 3.4. DTLS + FECFRAME 701 DTLS for manifests that do not fit into single-packet payloads can 702 still be delivered by using FECFRAME [RFC6363], particularly Reed- 703 Solomon [RFC6865] or possibly Raptor [RFC6681]. This has some 704 advantages compared to HTTPS because of the absence of HOL-blocking, 705 while providing for tunable redundancy. This has some advantages 706 relative to DTLS because of overhead reduction and non-integer 707 redundancy tunability (e.g. 1.5 becomes a viable redundancy factor). 709 TBD: define this method, possibly in another RFC. 711 4. Examples 713 TBD: walk through some examples as soon as we have a build running. 714 Likely to need some touching up. 716 5. YANG Module 718 5.1. Tree Diagram 720 module: ietf-ambi 721 augment /dorms:metadata/dorms:sender/dorms:group/dorms:udp-stream: 722 +--rw manifest-stream* [id] 723 +--rw id uint32 724 +--rw manifest-transport* inet:uri 725 +--rw hash-algorithm ct:asymmetric-key-algorithm-t 726 +--rw payload-type enumeration 727 +--rw data-hold-time-ms? uint32 728 +--rw digest-hold-time-ms? uint32 730 5.2. Module 732 file ietf-ambi@2020-03-09.yang 733 module ietf-ambi { 734 yang-version 1.1; 736 namespace "urn:ietf:params:xml:ns:yang:ietf-ambi"; 737 prefix "ambi"; 739 import ietf-dorms { 740 prefix "dorms"; 741 reference "I-D.jholland-mboned-dorms"; 742 } 744 import ietf-inet-types { 745 prefix "inet"; 746 reference "RFC6991 Section 4"; 747 } 749 import ietf-crypto-types { 750 prefix "ct"; 751 reference "draft-ietf-netconf-crypto-types"; 752 } 754 organization "IETF"; 756 contact 757 "Author: Jake Holland 758 759 "; 761 description 762 "Copyright (c) 2019 IETF Trust and the persons identified as 763 authors of the code. All rights reserved. 765 Redistribution and use in source and binary forms, with or 766 without modification, is permitted pursuant to, and subject to 767 the license terms contained in, the Simplified BSD License set 768 forth in Section 4.c of the IETF Trust's Legal Provisions 769 Relating to IETF Documents 770 (https://trustee.ietf.org/license-info). 772 This version of this YANG module is part of RFC XXXX 773 (https://www.rfc-editor.org/info/rfcXXXX); see the RFC itself 774 for full legal notices. 776 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL 777 NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED', 778 'MAY', and 'OPTIONAL' in this document are to be interpreted as 779 described in BCP 14 (RFC 2119) (RFC 8174) when, and only when, 780 they appear in all capitals, as shown here. 782 This module contains the definition for the AMBI data types. 783 It provides metadata for authenticating SSM channels as an 784 augmentation to DORMS."; 786 revision 2019-08-25 { 787 description "Initial revision as an extension."; 788 reference 789 ""; 790 } 792 augment 793 "/dorms:metadata/dorms:sender/dorms:group/dorms:udp-stream" { 794 description "Definition of the manifest stream providing 795 integrity info for the data stream"; 797 list manifest-stream { 798 key id; 799 description "Definition of a manifest stream."; 800 leaf id { 801 type uint32; 802 mandatory true; 803 description "The Manifest ID referenced in a manifest."; 804 } 805 leaf-list manifest-transport { 806 type inet:uri; 807 description "A URI that provides a location for the 808 manifest stream"; 809 } 810 leaf hash-algorithm { 811 type ct:asymmetric-key-algorithm-t; 812 mandatory true; 813 description 814 "The hash algorithm for the packet hashes within 815 manifests in this stream."; 816 } 817 leaf payload-type { 818 type enumeration { 819 enum udp { 820 description "The hash includes only the UDP 821 payload."; 822 } 823 enum ip { 824 description "The hash includes the full IP 825 payload."; 826 } 827 } 828 mandatory true; 829 description "The contents of the payload for the 830 digest profile"; 831 } 832 leaf data-hold-time-ms { 833 type uint32; 834 default 2000; 835 description "The number of milliseconds to hold data 836 packets waiting for a corresponding digest before 837 discarding"; 838 } 839 leaf digest-hold-time-ms { 840 type uint32; 841 default 10000; 842 description "The number of milliseconds to hold packet 843 digests waiting for a corresponding data packet 844 before discarding"; 845 } 846 } 847 } 848 } 850 852 6. IANA Considerations 854 6.1. The YANG Module Names Registry 856 This document adds one YANG module to the "YANG Module Names" 857 registry maintained at . The following registrations are made, per the format in 859 Section 14 of [RFC6020]: 861 name: ietf-ambi 862 namespace: urn:ietf:params:xml:ns:yang:ietf-ambi 863 prefix: ambi 864 reference: I-D.draft-jholland-mboned-ambi 866 6.2. Media Type 868 TBD: Register 'application/ambi' according to advice from: 869 https://www.iana.org/form/media-types 871 TBD: check guidelines in https://tools.ietf.org/html/rfc5226 873 7. Security Considerations 875 7.1. Predictable Packets 877 Protocols that have predictable packets run the risk of offline 878 attacks for hash collisions against those packets. When 879 authenticating a protocol that might have predictable packets, it's 880 RECOMMENDED to use a hash function secure against such attacks or to 881 add content to the packets to make them unpredictable, such as an 882 Authentication Header ([RFC4302]), or the addition of an ignored 883 field with random content to the packet payload. 885 TBD: explain attack from generating malicious packets and then 886 looking for collisions, as opposed to having to generate a collision 887 on packet contents that include a sequence number and then hitting a 888 match (especially expand on this if we do add Section 2.3.1.2). 890 TBD: follow the rest of the guidelines: https://tools.ietf.org/html/ 891 rfc3552 893 8. Acknowledgements 895 Many thanks to Daniel Franke, Eric Rescorla, Christian Worm 896 Mortensen, Max Franke, and Albert Manfredi for their very helpful 897 comments and suggestions. 899 9. References 901 9.1. Normative References 903 [I-D.draft-jholland-mboned-dorms-01] 904 Holland, J., "Discovery Of Restconf Metadata for Source- 905 specific multicast", draft-jholland-mboned-dorms-01 (work 906 in progress), September 2019. 908 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 909 Requirement Levels", BCP 14, RFC 2119, 910 DOI 10.17487/RFC2119, March 1997, 911 . 913 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 914 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 915 January 2012, . 917 [RFC6363] Watson, M., Begen, A., and V. Roca, "Forward Error 918 Correction (FEC) Framework", RFC 6363, 919 DOI 10.17487/RFC6363, October 2011, 920 . 922 [RFC6681] Watson, M., Stockhammer, T., and M. Luby, "Raptor Forward 923 Error Correction (FEC) Schemes for FECFRAME", RFC 6681, 924 DOI 10.17487/RFC6681, August 2012, 925 . 927 [RFC6865] Roca, V., Cunche, M., Lacan, J., Bouabdallah, A., and K. 928 Matsuzono, "Simple Reed-Solomon Forward Error Correction 929 (FEC) Scheme for FECFRAME", RFC 6865, 930 DOI 10.17487/RFC6865, February 2013, 931 . 933 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 934 RFC 7950, DOI 10.17487/RFC7950, August 2016, 935 . 937 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 938 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 939 May 2017, . 941 9.2. Informative References 943 [I-D.draft-krose-mboned-alta-01] 944 Rose, K. and J. Holland, "Asymmetric Loss-Tolerant 945 Authentication", draft-krose-mboned-alta-01 (work in 946 progress), July 2019. 948 [I-D.ietf-tsvwg-udp-options] 949 Touch, J., "Transport Options for UDP", draft-ietf-tsvwg- 950 udp-options-08 (work in progress), September 2019. 952 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 953 Jacobson, "RTP: A Transport Protocol for Real-Time 954 Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, 955 July 2003, . 957 [RFC4082] Perrig, A., Song, D., Canetti, R., Tygar, J., and B. 958 Briscoe, "Timed Efficient Stream Loss-Tolerant 959 Authentication (TESLA): Multicast Source Authentication 960 Transform Introduction", RFC 4082, DOI 10.17487/RFC4082, 961 June 2005, . 963 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, 964 DOI 10.17487/RFC4302, December 2005, 965 . 967 [RFC4383] Baugher, M. and E. Carrara, "The Use of Timed Efficient 968 Stream Loss-Tolerant Authentication (TESLA) in the Secure 969 Real-time Transport Protocol (SRTP)", RFC 4383, 970 DOI 10.17487/RFC4383, February 2006, 971 . 973 [RFC5776] Roca, V., Francillon, A., and S. Faurite, "Use of Timed 974 Efficient Stream Loss-Tolerant Authentication (TESLA) in 975 the Asynchronous Layered Coding (ALC) and NACK-Oriented 976 Reliable Multicast (NORM) Protocols", RFC 5776, 977 DOI 10.17487/RFC5776, April 2010, 978 . 980 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 981 the Network Configuration Protocol (NETCONF)", RFC 6020, 982 DOI 10.17487/RFC6020, October 2010, 983 . 985 Authors' Addresses 987 Jake Holland 988 Akamai Technologies, Inc. 989 150 Broadway 990 Cambridge, MA 02144 991 United States of America 993 Email: jakeholland.net@gmail.com 995 Kyle Rose 996 Akamai Technologies, Inc. 997 150 Broadway 998 Cambridge, MA 02144 999 United States of America 1001 Email: krose@krose.org