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