idnits 2.17.1 draft-jholland-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 23, 2018) is 1984 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Unused Reference: 'DIGSIGN' is defined on line 834, but no explicit reference was found in the text == Outdated reference: A later version (-32) exists of draft-ietf-tsvwg-udp-options-05 Summary: 0 errors (**), 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: Experimental Akamai Technologies, Inc. 5 Expires: April 26, 2019 October 23, 2018 7 Asymmetric Manifest-Based Integrity 8 draft-jholland-mboned-ambi-01 10 Abstract 12 This document introduces Asymmetric Manifest-Based Integrity (AMBI). 13 AMBI allows each receiver of a stream of multicast packets to check 14 the integrity of the contents of each packet in the data stream. 15 AMBI operates by employing a cryptographically-verifiable, loss- 16 resilient sequence of manifests containing integrity information for 17 both data and integrity packet payloads. 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 April 26, 2019. 36 Copyright Notice 38 Copyright (c) 2018 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 . . . . . . . . . . . . . . . . . . . . . . . 4 56 2. Protocol Specification . . . . . . . . . . . . . . . . . . . 4 57 2.1. Packet Identifiers . . . . . . . . . . . . . . . . . . . 4 58 2.1.1. Overview . . . . . . . . . . . . . . . . . . . . . . 5 59 2.1.2. RTP Sequence Number . . . . . . . . . . . . . . . . . 5 60 2.1.3. SRTP Sequence Number . . . . . . . . . . . . . . . . 6 61 2.1.4. UDP Option . . . . . . . . . . . . . . . . . . . . . 6 62 2.2. Anchor Message . . . . . . . . . . . . . . . . . . . . . 6 63 2.2.1. Overview . . . . . . . . . . . . . . . . . . . . . . 6 64 2.2.2. DNS-based Anchor URI Bootstrap . . . . . . . . . . . 6 65 2.2.3. Anchor Message YANG model . . . . . . . . . . . . . . 7 66 2.2.4. Example Anchor Message . . . . . . . . . . . . . . . 14 67 2.3. Manifests . . . . . . . . . . . . . . . . . . . . . . . . 15 68 2.3.1. Overview . . . . . . . . . . . . . . . . . . . . . . 15 69 2.3.2. Example Manifest Layout . . . . . . . . . . . . . . . 16 70 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 71 4. Security Considerations . . . . . . . . . . . . . . . . . . . 18 72 4.1. Packet Identifiers . . . . . . . . . . . . . . . . . . . 18 73 5. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 74 5.1. Normative References . . . . . . . . . . . . . . . . . . 18 75 5.2. Informative References . . . . . . . . . . . . . . . . . 18 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 78 1. Introduction 80 Multicast transport poses security problems that are not easily 81 addressed by the same security mechanisms used for unicast transport. 83 The "Introduction" sections of the documents describing TESLA 84 [RFC4082], and TESLA in SRTP [RFC4383], and TESLA with ALC and NORM 85 [RFC5776] present excellent overviews of the challenges unique to 86 multicast authentication, briefly summarized here: 88 o A MAC based on a symmetric shared secret cannot be used because 89 each packet has multiple receivers that do not trust each other. 91 o Asymmetric per-packet signatures can handle only very low bit- 92 rates because of the computational overhead. 94 o An asymmetric signature of a larger message comprising multiple 95 packets requires reliable receipt of all such packets, something 96 that cannot be guaranteed in a timely manner even for protocols 97 that do provide reliable delivery, and the retransmission of which 98 may anyway exceed the useful lifetime for data formats that can 99 otherwise tolerate some degree of loss. 101 Aymmetric Manifest-Based Integrity (AMBI) specifies a method for 102 receivers or middle boxes to cryptographically authenticate and 103 verify the integrity of a stream of data packets by communicating 104 integrity-protecting hashes chained from an asymmetrically-signed 105 root in a way that is robust to packet loss. 107 Integrity-protecting hashes are assembled into discrete "manifests" 108 that are 1:1 with data packets and have a fixed maximum size that is 109 a function only of the hash output size, packet identifier size, and 110 (for the root manifest) asymmetric signature length. Each hash is 111 computed over the contents of a specific data payload and associated 112 manifest. Manifests may be communicated either in-band (e.g., 113 appended to or otherwise incorporated into the payload of the 114 associated data packet) or out-of-band (in an associated channel with 115 similar or better reliability characteristics). 117 TBD: It would be really nice if the signature were not in the root 118 manifest itself, as that potentially complicates in-band integrity 119 protection. 121 To achieve robustness of integrity information in the face of packet 122 loss, we employ a variant of the scheme described in [STRAUTH] to 123 structure the manifests. Manifests are described in more detail in 124 Section 2.3. 126 A root manifest is authenticated by a signature in an "anchor 127 message", itself authenticated using some pre-established trust 128 relationship. Anchor messages are described in greater detail in 129 Section 2.2. 131 The use of a single signature to authenticate a large sequence of 132 data packets allows the sender and receiver to amortize the 133 computational overhead of asymmetric authentication across enough 134 data packets to sustain high data rates. Furthermore, the use of 135 asymmetric authentication allows for asynchronous distribution of 136 authentication information, something not possible with TESLA. 138 Upon successful authentication of a root manifest and verification of 139 the chain of hashes required to establish the integrity of a 140 particular data payload, the corresponding payload may be delivered 141 to the application (in the case of a client) or relayed to the next 142 hop (in the case of a middle box). 144 Authenticating the integrity of the data packets depends on: 146 o authentication of the anchor message that provides the linkage 147 between the data stream, the manifest channel, and the root 148 manifest authentication key; 150 o the secrecy and cryptographic strength of private keys used for 151 signing the root manifests; and 153 o the difficulty of generating a collision for the hashes in the 154 manifests. 156 1.1. Comparison with TESLA 158 AMBI and TESLA [RFC4082] and [RFC5776] attempt to achieve a similar 159 goal of authenticating the integrity of streams of multicast packets. 160 AMBI imposes a higher overhead, as measured in the amount of extra 161 data required, than TESLA imposes. In exchange, AMBI provides non- 162 repudiation (which TESLA does not), and relaxes the requirement for 163 establishing an upper bound on clock synchronization between sender 164 and receiver. 166 This tradeoff enables new capabilities for AMBI, relative to TESLA. 167 In particular, when receiving multicast traffic from an untrusted 168 transit network, AMBI can be used by a middle box to authenticate 169 packets from a trusted source before forwarding traffic through the 170 network, and the receiver also can separately authenticate the 171 packets. This use case is not possible with TESLA because the data 172 packets can't be authenticated until a key is disclosed, so either 173 the middlebox has to forward data packets without first 174 authenticating so that the receiver has them prior to key disclosure, 175 or the middlebox has to hold packets until the key is disclosed, at 176 which point the receiver can no longer establish their authenticity. 178 1.2. Terminology 180 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 181 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 182 document are to be interpreted as described in [RFC2119]. 184 2. Protocol Specification 186 2.1. Packet Identifiers 187 2.1.1. Overview 189 A packet identifier is a sequence number contained within the 190 authenticated payload of a packet. The packet identifier is used in 191 a manifest to associate each integrity-protecting hash with a 192 specific data payload and integrity manifest. 194 Every packet containing either data or manifest MUST contain a packet 195 identifier. If a data payload and its associated manifest are 196 contained in separate packets, this packet identifier MUST be the 197 same in both packets. 199 This document defines a new UDP option in Section 2.1.4 for use as a 200 packet identifier. 202 Some multicast-capable transport protocols have a sequence number 203 embedded in data packets in the protocol. The sequence numbers in 204 these protocols MAY be used instead of the new UDP option, to avoid 205 introducing extra overhead in the authenticated data packets. 207 In Section 2.1.2, Section 2.1.3, and Section 2.1.4, this document 208 defines some sample ways to specify packet identifiers based on such 209 sequence numbers embedded in existing protocols. 211 Other appropriate sequence number systems may exist, such as the 212 anti-replay Sequence Number field in Section 3.1 of [RFC6584], when 213 NORM or FLUTE operates with an authentication profile that uses it 214 (however, since that example already provides authentication, it is 215 not added as an option in this document). The AMBI anchor message 216 format can be extended in future documents to support those or other 217 suitable schemes by adding values to the registry defined in 218 Section 3. 220 In some deployments, in contrast to using the new UDP option, the 221 approach of using an existing sequence number as packet identifier 222 may carry a benefit because, in combination with out-of-band 223 manifests, it requires no change to the data stream, possibly 224 enabling interoperability with legacy receivers. 226 2.1.2. RTP Sequence Number 228 Sequence number from Section 5.1 of [RFC3550]. 230 TBD: discussion of security consequences of using 16 bits- recommend 231 a bigger hash in manifests for this case? 233 2.1.3. SRTP Sequence Number 235 Packet Index from Section 3.3.1 of [RFC3711]. 237 2.1.4. UDP Option 239 Define a new UDP option [I-D.ietf-tsvwg-udp-options] (TBD2). 241 0 1 2 3 242 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 243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 244 | UDP Kind=TBD2 | Length=6 | 32-bit packet identifier | 245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 246 | | 247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 249 2.2. Anchor Message 251 2.2.1. Overview 253 An anchor message provides the information that makes it possible to 254 authenticate root manifests for a stream. An anchor message MAY be 255 discovered and transmitted by any means providing adequate source 256 authentication and data integrity to meet the security needs of the 257 receiver. 259 In order to support middle-box authentication, it is RECOMMENDED that 260 senders arrange to distribute anchor messages according to the method 261 outlined in Section 2.2.2. 263 2.2.2. DNS-based Anchor URI Bootstrap 265 TBD: This section needs to be updated for [STRAUTH]. 267 When a middle box tries to process a join for a specific source, if 268 it is configured to perform authentication on SSM multicast channels 269 it can forward, it SHOULD make a DNS request for ambi.(reverse- 270 source-ip).ip6.arpa or ambi.(reverse-source-ip).in-addr.arpa, for 271 IPv6 or IPv4 source addresses. 273 When AMBI is provided to authenticate traffic from this source IP, 274 this domain name SHOULD be configured with a TXT field which contains 275 a URI that can be used to securely fetch an anchor message that 276 describes all the AMBI- authenticatable traffic from this source IP. 278 Other methods MAY be used to discover and transfer an anchor message. 279 The description of alternate methods is out of scope for this 280 document. 282 TBD: consider breaking up anchor message to avoid large, frequently 283 changing anchors for sources with many groups. 285 TBD: consider graceful rollover for anchors, instead of synchronized 286 update of anchor hash. 288 2.2.3. Anchor Message YANG model 290 TBD: This section needs to be updated for [STRAUTH]. 292 file "ietf-ambi-anchor.yang" 293 module ietf-ambi-anchor { 294 yang-version 1.1; 296 namespace "urn:ietf:params:xml:ns:yang:ietf-ambi-anchor"; 297 prefix "ambi"; 299 import ietf-yang-types { 300 prefix "yang"; 301 reference "RFC6991 Section 3"; 302 } 304 import ietf-inet-types { 305 prefix "inet"; 306 reference "RFC6991 Section 4"; 307 } 309 import ietf-routing-types { 310 prefix "rt-types"; 311 reference "RFC8294"; 312 } 314 organization "IETF"; 316 contact 317 "Author: Jake Holland 318 319 Author: Kyle Rose 320 321 "; 323 description 324 "This module contains the definition for the AMBI anchor 325 message data type. 327 Copyright (c) 2018 IETF Trust and the persons identified as 328 authors of the code. All rights reserved. 330 Redistribution and use in source and binary forms, with or 331 without modification, is permitted pursuant to, and subject 332 to the license terms contained in, the Simplified BSD License 333 set forth in Section 4.c of the IETF Trust's Legal Provisions 334 Relating to IETF Documents 335 (http://trustee.ietf.org/license-info). 337 This version of this YANG module is part of 338 draft-jholland-mboned-ambi, 339 see the internet draft itself for full legal notices."; 341 revision 2018-06-27 { 342 description "Initial revision."; 343 reference 344 ""; 345 } 347 /* TBD: copied some from https://tools.ietf.org/html/rfc8177, 348 but the model doesn't seem to match what I want. is there another 349 I can import instead of making these here? Or a registry 350 to reference? */ 351 identity crypto-hash { 352 description 353 "Base identity of cryptographic hash options. "; 354 } 356 identity sha-256 { 357 base crypto-hash; 358 description 359 "The SHA-256 algorithm."; 360 } 362 identity blake2b { 363 base crypto-hash; 364 description 365 "The BLAKE2b algorithm."; 366 } 368 identity crypto-signature { 369 description 370 "Base identity of cryptographic asymmetric signature 371 options."; 372 } 374 identity ed25519 { 375 base crypto-signature; 376 description 377 "The Ed25519 algorithm."; 379 } 381 identity rsa { 382 base crypto-signature; 383 description 384 "The RSA algorithm."; 385 } 387 identity sequence-type { 388 description 389 "Base identity for sequence number type options."; 390 } 392 identity rtp { 393 base sequence-type; 394 description 395 "The sequence number from RTP."; 396 } 398 identity srtp { 399 base sequence-type; 400 description 401 "The sequence number from SRTP."; 402 } 404 identity udp { 405 base sequence-type; 406 description 407 "The sequence number from UDP."; 408 } 409 typedef key-identifier { 410 type uint16 { 411 range 1..65535; 412 } 413 description "Key identifier within a manifest"; 414 } 416 typedef bitrate { 417 type string { 418 pattern '[1-9][0-9]*[GMK]?bps'; 419 } 420 description "Bit-rate of a data stream"; 421 } 423 typedef packetrate { 424 type string { 425 pattern '[1-9][0-9]*[GMK]?pps'; 426 } 427 description "Packet rate of a data stream"; 428 } 430 typedef manifest-transport { 431 type union { 432 type leafref { 433 path "/anchor/data_stream/id"; 434 } 435 type inet:uri; 436 } 437 description "Transport method for a manifest stream"; 438 } 440 container anchor { 441 container self { 442 presence "An anchor message exists"; 443 description 444 "Self-referential properties about the anchor message"; 445 leaf uri { 446 type inet:uri; 447 mandatory true; 448 description 449 "The canonical URI for this anchor message."; 450 } 451 leaf version { 452 type uint16; 453 mandatory true; 454 description 455 "The version number for this anchor message."; 456 } 457 leaf hash_algorithm { 458 type identityref { 459 base crypto-hash; 460 } 461 mandatory true; 462 description 463 "The algorithm for the anchor message hash provided 464 in a manifest."; 465 } 466 leaf hash_bits { 467 type uint16; 468 mandatory true; 469 description 470 "The number of bits for the anchor's hash provided 471 in a manifest."; 472 } 473 leaf expires { 474 type yang:date-and-time; 475 mandatory true; 476 description 477 "The expiration time for this anchor message."; 478 } 479 } 480 description "Anchor message for AMBI"; 482 list public_key { 483 key id; 484 description "Public key for non-recursive manifest"; 485 leaf id { 486 type key-identifier; 487 mandatory true; 488 description 489 "The key identifier referenced in a manifest."; 490 } 491 leaf algorithm { 492 type identityref { 493 base crypto-signature; 494 } 495 mandatory true; 496 description 497 "The signature algorithm for use with this key."; 498 } 499 leaf signature_bits { 500 type uint16; 501 mandatory true; 502 description 503 "The length of the signature provided in manifests 504 signed with this key."; 505 } 506 leaf value { 507 type string; 508 mandatory true; 509 description 510 "The base64-encoded value of the public key."; 511 } 512 } 514 list data_stream { 515 key id; 516 unique "source destination port"; 517 description "Stream of data packets to be authenticated"; 518 leaf id { 519 type uint16; 520 mandatory true; 521 description 522 "The datastream_id referenced by a 523 manifest_stream."; 524 } 525 leaf source { 526 type inet:ip-address; 527 mandatory true; 528 description 529 "The source IP address of the authenticated data 530 stream."; 531 } 532 leaf destination { 533 type rt-types:ip-multicast-group-address; 534 mandatory true; 535 description 536 "The destination group IP address of the 537 authenticated data stream."; 538 } 539 leaf port { 540 type uint16; 541 mandatory true; 542 description 543 "The destination UDP port of the authenticated data 544 stream."; 545 } 546 leaf max_bitrate { 547 type bitrate; 548 mandatory true; 549 description 550 "The maximum bitrate expected for this data 551 stream."; 552 } 553 leaf max_packetrate { 554 type packetrate; 555 mandatory true; 556 description 557 "The maximum packetrate expected for this data 558 stream."; 559 } 560 list authenticator { 561 key manifest_id; 562 description 563 "A manifest stream that authenticates this data"; 564 leaf manifest_id { 565 type leafref { 566 path "/anchor/manifest_stream/id"; 567 } 568 mandatory true; 569 description 570 "The ID of a manifest stream that provides 571 authentication for this data stream."; 572 } 573 } 574 } 576 list manifest_stream { 577 key id; 578 description "Stream of manifests"; 579 leaf id { 580 type uint16; 581 mandatory true; 582 description "The Manifest ID referenced in a manifest."; 583 } 584 leaf transport { 585 type manifest-transport; 586 mandatory true; 587 description 588 "The ID of the data stream that carries this 589 manifest stream or a uri that provides a websocket 590 with the stream of manifests."; 591 } 592 leaf hash_algorithm { 593 type identityref { 594 base crypto-hash; 595 } 596 mandatory true; 597 description 598 "The hash algorithm for the packet hashes within 599 manifests in this stream."; 600 } 601 leaf hash_bits { 602 type uint16; 603 mandatory true; 604 description 605 "The number of bits of hash provided for packet 606 hashes."; 607 } 608 leaf sequence_type { 609 type identityref { 610 base sequence-type; 611 } 612 mandatory true; 613 description 614 "The linkage to the data packet sequence numbers in 615 the manifest."; 616 } 617 } 618 } 620 } 621 623 Figure 1: Anchor Message YANG model 625 2.2.4. Example Anchor Message 627 TBD: This section needs to be updated for [STRAUTH]. 629 { 630 "ietf-ambi-anchor:anchor": { 631 "self": { 632 "uri": "https://example.com/ambi/anchor/example_1.json", 633 "version": 1, 634 "hash_algorithm": "blake2b", 635 "hash_bits": 256, 636 "expires": "2018-03-05T23:59:59Z" 637 }, 638 "public_key": [ 639 { 640 "id": 1, 641 "algorithm": "ed25519", 642 "signature_bits": 256, 643 "value": "VGhpcyBpcyBub3QgYSBnb29kIGtleSB0byB1c2UuLi4NCg==" 644 } 645 ], 646 "data_stream": [ 647 { 648 "id": 10, 649 "source": "192.0.2.10", 650 "destination": "232.10.10.1", 651 "port": 18001, 652 "max_bitrate": "10Mbps", 653 "max_packetrate": "1Kpps", 654 "authenticator": [ 655 { 656 "manifest_id": 1 657 } 658 ] 659 }, 660 { 661 "id": 20, 662 "source": "192.0.2.10", 663 "destination": "232.10.10.1", 664 "port": 18002, 665 "max_bitrate": "400Kbps", 666 "max_packetrate": "40pps", 667 "authenticator": [ 668 { 669 "manifest_id": 2 670 } 671 ] 672 } 673 ], 674 "manifest_stream": [ 675 { 676 "id": 1, 677 "transport": 20, 678 "hash_algorithm": "blake2b", 679 "hash_bits": 80, 680 "sequence_type": "udp" 681 }, 682 { 683 "id": 2, 684 "transport": "https://example.com/ambi/manifest_stream/3", 685 "hash_algorithm": "blake2b", 686 "hash_bits": 80, 687 "sequence_type": "udp" 688 } 689 ] 690 } 691 } 693 Figure 2: Example Anchor Message 695 2.3. Manifests 697 2.3.1. Overview 699 A manifest contains a sequence of hashes of data and corresponding 700 manifest payloads according to the DAG schema defined in section 3 of 701 [STRAUTH]. Additionally, a root manifest contains a public key 702 signature to allow for authentication against an anchor message. 704 o TBD: insert more details about the construction here 706 * Constructive description of scheme for p=1 and p>1 708 * How to choose the packets according to different settings of p 710 * Hash construction H(data,manifest) 712 * Possible hash algorithms and truncation 714 A manifest M_j cannot be interpreted except in the context of a known 715 anchor message authenticating a root manifest M_0, and a sequence of 716 hashes h_i, manifests M_i, and data payloads D_i for 1 <= i <= j such 717 that h_i is contained in the manifest M_{i-1} and such that 718 h_i=H(D_i,M_i). 720 For a root manifest to be considered authentic, the anchor version in 721 the manifest MUST match the value in a known unexpired anchor message 722 and the signature of the root manifest MUST be authentic according to 723 the public key in the anchor message. 725 A manifest MAY omit the packet identifier associated with a 726 particular hash if the underlying packet stream employs packet 727 identifiers that are implicit from the structure of the integrity DAG 728 scheme and from the offset within the augmented chain. For example, 729 packet identifiers that increment by exactly one in successive data 730 packets and which overflow to zero would have this property. 732 2.3.2. Example Manifest Layout 734 The following describes the manifest layout for an integrity scheme 735 employing a hash with an output of 256 bits and an explicit packet 736 identifier space of 32 bits. This can be extended to other hash 737 ranges and packet identifier spaces in the obvious way. With a 738 sufficiently-strong hash function, the packet identifier may also be 739 safely truncated to the maximum possible window size for useful in- 740 flight data to save bits while avoiding trial hash comparison. 742 Given: * Manifest packet identifier i_0 * Augmented chain offset f * 743 k <= 5 * k is implicit from the chosen DAG scheme and from offset f 744 0 1 2 3 745 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 746 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 747 | Ver=0 | Reserved | f | Anchor Version | 748 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 749 | Packet Identifier i_1 | 750 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 751 | | 752 | Hash H(D_{i_1},M_{i_1}) | 753 | | 754 | | 755 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 756 | ... | 757 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 758 | Packet Identifier i_k | 759 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 760 | | 761 | Hash H(D_{i_k},M_{i_k}) | 762 | | 763 | | 764 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 765 | | 766 | Cryptographic Signature (if a root manifest) | 767 | | 768 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 770 3. IANA Considerations 772 TBD1: Request a "Specification Required" registry for Packet 773 identifier methods, from https://tools.ietf.org/html/rfc5226#section- 774 4.1 . Reserve anything beginning with "experimental:"? 776 TBD2: Add a new entry to the "UDP Option Kind" numbers registry: 777 https://tools.ietf.org/html/draft-ietf-tsvwg-udp-options- 778 02#section-14 780 TBD: check guidelines in https://tools.ietf.org/html/rfc5226 and 781 remove this paragraph 783 Example from: https://tools.ietf.org/html/rfc5226#section-5.1 785 [TO BE REMOVED: Please add the yang model in Section 2.2.3 to: 786 https://www.iana.org/assignments/yang-parameters/yang- 787 parameters.xhtml 789 Name:ietf-ambi-anchor Maintained by IANA: N Namespace: 790 urn:ietf:params:xml:ns:yang:ietf-ambi-anchor Prefix: anchor 791 Reference: I-D.draft-jholland-mboned-ambi Notes: ] 793 4. Security Considerations 795 4.1. Packet Identifiers 797 TBD: explain attack from generating malicious packets and then 798 looking for collisions, as opposed to having to generate a collision 799 including a packet identifier and then hitting a match 801 TBD: DNSSEC vis-a-vis anchor url discovery. (we need a diagram about 802 for middle-box handling of a revers-path propagated join?) Explain 803 why malicious DNS could deny service, but cannot cause accepting 804 attack packets. 806 TBD: follow the rest of the guidelines: https://tools.ietf.org/html/ 807 rfc3552 809 5. References 811 5.1. Normative References 813 [I-D.ietf-tsvwg-udp-options] 814 Touch, J., "Transport Options for UDP", draft-ietf-tsvwg- 815 udp-options-05 (work in progress), July 2018. 817 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 818 Requirement Levels", BCP 14, RFC 2119, 819 DOI 10.17487/RFC2119, March 1997, 820 . 822 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 823 Jacobson, "RTP: A Transport Protocol for Real-Time 824 Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, 825 July 2003, . 827 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 828 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 829 RFC 3711, DOI 10.17487/RFC3711, March 2004, 830 . 832 5.2. Informative References 834 [DIGSIGN] Rohatgi, P., "How to Sign Digital Streams", 1997, 835 . 838 Published in CRYPTO '97 "Proceedings of the 17th Annual 839 International Cryptology Conference on Advances in 840 Cryptology", Pages 180-197 842 [RFC4082] Perrig, A., Song, D., Canetti, R., Tygar, J., and B. 843 Briscoe, "Timed Efficient Stream Loss-Tolerant 844 Authentication (TESLA): Multicast Source Authentication 845 Transform Introduction", RFC 4082, DOI 10.17487/RFC4082, 846 June 2005, . 848 [RFC4383] Baugher, M. and E. Carrara, "The Use of Timed Efficient 849 Stream Loss-Tolerant Authentication (TESLA) in the Secure 850 Real-time Transport Protocol (SRTP)", RFC 4383, 851 DOI 10.17487/RFC4383, February 2006, 852 . 854 [RFC5776] Roca, V., Francillon, A., and S. Faurite, "Use of Timed 855 Efficient Stream Loss-Tolerant Authentication (TESLA) in 856 the Asynchronous Layered Coding (ALC) and NACK-Oriented 857 Reliable Multicast (NORM) Protocols", RFC 5776, 858 DOI 10.17487/RFC5776, April 2010, 859 . 861 [RFC6584] Roca, V., "Simple Authentication Schemes for the 862 Asynchronous Layered Coding (ALC) and NACK-Oriented 863 Reliable Multicast (NORM) Protocols", RFC 6584, 864 DOI 10.17487/RFC6584, April 2012, 865 . 867 [STRAUTH] Modadugu, N., "Authenticating Streamed Data in the 868 Presence of Random Packet Loss", 2001, 869 . 871 ISOC Network and Distributed System Security Symposium 873 Authors' Addresses 875 Jake Holland 876 Akamai Technologies, Inc. 877 150 Broadway 878 Cambridge, MA 02144 879 United States of America 881 Email: jakeholland.net@gmail.com 882 Kyle Rose 883 Akamai Technologies, Inc. 884 150 Broadway 885 Cambridge, MA 02144 886 United States of America 888 Email: krose@krose.org