idnits 2.17.1 draft-jholland-mboned-ambi-00.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 (June 29, 2018) is 2128 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Unused Reference: 'DIGSIGN' is defined on line 787, but no explicit reference was found in the text == Outdated reference: A later version (-32) exists of draft-ietf-tsvwg-udp-options-02 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: December 31, 2018 June 29, 2018 7 Asymmetric Manifest Based Integrity 8 draft-jholland-mboned-ambi-00 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 passing cryptographically verifiable manifests for 16 the data packets, over out-of-band communication channels. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at https://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on December 31, 2018. 35 Copyright Notice 37 Copyright (c) 2018 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (https://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 1.1. Comparison with TESLA . . . . . . . . . . . . . . . . . . 4 54 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 55 2. Protocol Specification . . . . . . . . . . . . . . . . . . . 4 56 2.1. Packet Identifiers . . . . . . . . . . . . . . . . . . . 4 57 2.1.1. Overview . . . . . . . . . . . . . . . . . . . . . . 4 58 2.1.2. RTP Sequence Number . . . . . . . . . . . . . . . . . 5 59 2.1.3. SRTP Sequence Number . . . . . . . . . . . . . . . . 5 60 2.1.4. UDP Option . . . . . . . . . . . . . . . . . . . . . 5 61 2.2. Anchor Message . . . . . . . . . . . . . . . . . . . . . 6 62 2.2.1. Overview . . . . . . . . . . . . . . . . . . . . . . 6 63 2.2.2. DNS-based Anchor URI Bootstrap . . . . . . . . . . . 6 64 2.2.3. Anchor Message YANG model . . . . . . . . . . . . . . 6 65 2.2.4. Example Anchor Message . . . . . . . . . . . . . . . 13 66 2.3. Manifests . . . . . . . . . . . . . . . . . . . . . . . . 15 67 2.3.1. Overview . . . . . . . . . . . . . . . . . . . . . . 15 68 2.3.2. Manifest Layout . . . . . . . . . . . . . . . . . . . 15 69 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 70 4. Security Considerations . . . . . . . . . . . . . . . . . . . 17 71 4.1. Packet Identifiers . . . . . . . . . . . . . . . . . . . 17 72 5. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 73 5.1. Normative References . . . . . . . . . . . . . . . . . . 17 74 5.2. Informative References . . . . . . . . . . . . . . . . . 17 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 77 1. Introduction 79 Multicast transport poses security problems that are not easily 80 addressed by the same security mechanisms used for unicast transport. 82 The "Introduction" sections of the documents describing TESLA 83 [RFC4082], and TESLA in SRTP [RFC4383], and TESLA with ALC and NORM 84 [RFC5776] present excellent overviews of the challenges unique to 85 multicast authentication, briefly summarized here: 87 o A MAC based on a symmetric shared secret cannot be used because 88 each packet has multiple receivers that do not trust each other. 90 o Asymmetric per-packet signatures can handle only very low bit- 91 rates because of the computational overhead. 93 o An asymmetric signature of a larger message comprising multiple 94 packets requires reliable receipt of all such packets, something 95 that cannot be guaranteed in a timely manner even for protocols 96 that do provide reliable delivery, and the retransmission of which 97 may anyway exceed the useful lifetime for data formats that can 98 otherwise tolerate some degree of loss. 100 Aymmetric Manifest-Based Integrity (AMBI) specifies a method for 101 receivers or middle boxes to cryptographically authenticate and 102 verify the integrity of a stream of packets, by communicating packet 103 "manifests" (described in Section 2.3) via an out-of-band 104 communication channel that provides authentication and verifiable 105 integrity. 107 Each manifest contains cryptographic hashes of packet payloads 108 corresponding to specific packets in the authenticated data stream. 110 Three ways to authenticate a manifest are defined: 112 o Asymmetric signature of a message containing the manifest. 114 o Authenticated unicast stream providing a sequence of manifests. 116 o Using one of the prior two constructions to bootstrap a root 117 manifest containing authentication information for further 118 manifests. This we term "recursive authentication". 120 When using asymmetric signatures, recursive authentication allows the 121 sender to amortize the computational overhead for a single asymmetric 122 signature across enough data packets to sustain high data rates. 123 When using a secure unicast stream, the recursive verification allows 124 for scaling the authenticated data stream to more receivers than can 125 otherwise be sustained with a limited set of trusted servers. 127 Upon successful verification of the contents of a manifest and 128 receipt of any subset of the corresponding data packets, the receiver 129 has proof of the integrity of the contents of the data packets listed 130 in the manifest. 132 An "anchor message", described in Section 2.2, provides the link 133 between an authenticated data stream and the out-of-band channel of 134 manifests that authenticates it. 136 Authenticating the integrity of the data packets depends on: 138 o authentication of the anchor message that provides the linkage 139 between the manifest channel and the data stream; and 141 o the secrecy and cryptographic strength of private keys used for 142 signing manifests, or the authentication of the secure unicast 143 streams used for transmitting manifests; and 145 o the difficulty of generating a collision for the packet hashes in 146 the manifest. 148 1.1. Comparison with TESLA 150 AMBI and TESLA [RFC4082] and [RFC5776] attempt to achieve a similar 151 goal of authenticating the integrity of streams of multicast packets. 152 AMBI imposes a higher overhead, as measured in the amount of extra 153 data required, than TESLA imposes. In exchange, AMBI provides non- 154 repudiation (which TESLA does not), and relaxes the requirement for 155 establishing an upper bound on clock synchronization between sender 156 and receiver. 158 This tradeoff enables new capabilities for AMBI, relative to TESLA. 159 In particular, when receiving multicast traffic from an untrusted 160 transit network, AMBI can be used by a middle box to authenticate 161 packets from a trusted source before forwarding traffic through the 162 network, and the receiver also can separately authenticate the 163 packets. (This use case is not possible with TESLA because the data 164 packets can't be authenticated until a key is disclosed, so either 165 the middlebox has to forward data packets without first 166 authenticating so that the receiver has them prior to key disclosure, 167 or the middlebox has to hold packets until the key is disclosed, at 168 which point the receiver can no longer establish their authenticity.) 170 1.2. Terminology 172 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 173 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 174 document are to be interpreted as described in [RFC2119]. 176 2. Protocol Specification 178 2.1. Packet Identifiers 180 2.1.1. Overview 182 Packet identifiers are a sequence number contained within the 183 authenticated payload of the packet. This sequence number is used 184 inside a manifest to associate each packet hash with a specific 185 packet. Each authenticated packet MUST contain a packet identifier. 186 See Section 4.1 for a discussion of the security implications. 188 This document defines a new UDP option in Section 2.1.4 for use as a 189 packet identifier. 191 Some multicast-capable transport protocols have a sequence number 192 embedded in data packets in the protocol. The sequence numbers in 193 these protocols MAY be used instead of the new UDP option, to avoid 194 introducing extra overhead in the authenticated data packets. 196 In Section 2.1.2, Section 2.1.3, and Section 2.1.4, this document 197 defines some sample ways to specify packet identifiers based on such 198 sequence numbers embedded in existing protocols. 200 Other appropriate sequence number systems may exist, such as the 201 anti-replay Sequence Number field in Section 3.1 of [RFC6584], when 202 NORM or FLUTE operates with an authentication profile that uses it 203 (however, since that example already provides authentication, it is 204 not added as an option in this document). The AMBI anchor message 205 format can be extended in future documents to support those or other 206 suitable schemes by adding values to the registry defined in 207 Section 3. 209 In some deployments, in contrast to using the new UDP option, the 210 approach of using an existing sequence number may carry a benefit 211 because it requires no change to the stream of packets being 212 authenticated, possibly enabling interoperability with legacy 213 receivers. 215 2.1.2. RTP Sequence Number 217 Sequence number from Section 5.1 of [RFC3550]. 219 TBD: discussion of security consequences of using 16 bits- recommend 220 a bigger hash in manifests for this case? 222 2.1.3. SRTP Sequence Number 224 Packet Index from Section 3.3.1 of [RFC3711]. 226 2.1.4. UDP Option 228 Define a new UDP option [I-D.ietf-tsvwg-udp-options] (TBD2). 230 0 1 2 3 231 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 232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 233 | UDP Kind=TBD2 | Length=6 | 32-bit sequence number | 234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 235 | | 236 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 238 2.2. Anchor Message 240 2.2.1. Overview 242 An anchor message provides the information that makes it possible to 243 associate the manifests with the data packets they authenticate. ID 244 values that appear as text integers in the anchor message also appear 245 in the manifest binary data, with the anchor message providing 246 context on how to interpret the values. 248 An anchor message MAY be discovered and transmitted by any means 249 which provides adequate source authentication and data integrity to 250 meet the security needs of the receiver. 252 In order to support middle-box authentication, it is RECOMMENDED that 253 senders arrange to distribute anchor messages according to the method 254 outlined in Section 2.2.2. 256 2.2.2. DNS-based Anchor URI Bootstrap 258 When a middle box tries to process a join for a specific source, if 259 it is configured to perform authentication on SSM multicast channels 260 it can forward, it SHOULD make a DNS request for ambi.(reverse- 261 source-ip).ip6.arpa or ambi.(reverse-source-ip).in-addr.arpa, for 262 IPv6 or IPv4 source addresses. 264 When AMBI is provided to authenticate traffic from this source IP, 265 this domain name SHOULD be configured with a TXT field which contains 266 a URI that can be used to securely fetch an anchor message that 267 describes all the AMBI- authenticatable traffic from this source IP. 269 Other methods MAY be used to discover and transfer an anchor message. 270 The description of alternate methods is out of scope for this 271 document. 273 TBD: consider breaking up anchor message to avoid large, frequently 274 changing anchors for sources with many groups. 276 TBD: consider graceful rollover for anchors, instead of synchronized 277 update of anchor hash. 279 2.2.3. Anchor Message YANG model 281 file "ietf-ambi-anchor.yang" 282 module ietf-ambi-anchor { 283 yang-version 1.1; 285 namespace "urn:ietf:params:xml:ns:yang:ietf-ambi-anchor"; 286 prefix "ambi"; 288 import ietf-yang-types { 289 prefix "yang"; 290 reference "RFC6991 Section 3"; 291 } 293 import ietf-inet-types { 294 prefix "inet"; 295 reference "RFC6991 Section 4"; 296 } 298 import ietf-routing-types { 299 prefix "rt-types"; 300 reference "RFC8294"; 301 } 303 organization "IETF"; 305 contact 306 "Author: Jake Holland 307 308 Author: Kyle Rose 309 310 "; 312 description 313 "This module contains the definition for the AMBI anchor 314 message data type. 316 Copyright (c) 2018 IETF Trust and the persons identified as 317 authors of the code. All rights reserved. 319 Redistribution and use in source and binary forms, with or 320 without modification, is permitted pursuant to, and subject 321 to the license terms contained in, the Simplified BSD License 322 set forth in Section 4.c of the IETF Trust's Legal Provisions 323 Relating to IETF Documents 324 (http://trustee.ietf.org/license-info). 326 This version of this YANG module is part of 327 draft-jholland-mboned-ambi, 328 see the internet draft itself for full legal notices."; 330 revision 2018-06-27 { 331 description "Initial revision."; 332 reference 333 ""; 335 } 337 /* TBD: copied some from https://tools.ietf.org/html/rfc8177, 338 but the model doesn't seem to match what I want. is there another 339 I can import instead of making these here? Or a registry 340 to reference? */ 341 identity crypto-hash { 342 description 343 "Base identity of cryptographic hash options. "; 344 } 346 identity sha-256 { 347 base crypto-hash; 348 description 349 "The SHA-256 algorithm."; 350 } 352 identity blake2b { 353 base crypto-hash; 354 description 355 "The BLAKE2b algorithm."; 356 } 358 identity crypto-signature { 359 description 360 "Base identity of cryptographic asymmetric signature 361 options."; 362 } 364 identity ed25519 { 365 base crypto-signature; 366 description 367 "The Ed25519 algorithm."; 368 } 370 identity rsa { 371 base crypto-signature; 372 description 373 "The RSA algorithm."; 374 } 376 identity sequence-type { 377 description 378 "Base identity for sequence number type options."; 379 } 381 identity rtp { 382 base sequence-type; 383 description 384 "The sequence number from RTP."; 385 } 387 identity srtp { 388 base sequence-type; 389 description 390 "The sequence number from SRTP."; 391 } 393 identity udp { 394 base sequence-type; 395 description 396 "The sequence number from UDP."; 397 } 398 typedef key-identifier { 399 type uint16 { 400 range 1..65535; 401 } 402 description "Key identifier within a manifest"; 403 } 405 typedef bitrate { 406 type string { 407 pattern '[1-9][0-9]*[GMK]?bps'; 408 } 409 description "Bit-rate of a data stream"; 410 } 412 typedef packetrate { 413 type string { 414 pattern '[1-9][0-9]*[GMK]?pps'; 415 } 416 description "Packet rate of a data stream"; 417 } 419 typedef manifest-transport { 420 type union { 421 type leafref { 422 path "/anchor/data_stream/id"; 423 } 424 type inet:uri; 425 } 426 description "Transport method for a manifest stream"; 427 } 429 container anchor { 430 container self { 431 presence "An anchor message exists"; 432 description 433 "Self-referential properties about the anchor message"; 434 leaf uri { 435 type inet:uri; 436 mandatory true; 437 description 438 "The canonical URI for this anchor message."; 439 } 440 leaf version { 441 type uint16; 442 mandatory true; 443 description 444 "The version number for this anchor message."; 445 } 446 leaf hash_algorithm { 447 type identityref { 448 base crypto-hash; 449 } 450 mandatory true; 451 description 452 "The algorithm for the anchor message hash provided 453 in a manifest."; 454 } 455 leaf hash_bits { 456 type uint16; 457 mandatory true; 458 description 459 "The number of bits for the anchor's hash provided 460 in a manifest."; 461 } 462 leaf expires { 463 type yang:date-and-time; 464 mandatory true; 465 description 466 "The expiration time for this anchor message."; 467 } 468 } 469 description "Anchor message for AMBI"; 471 list public_key { 472 key id; 473 description "Public key for non-recursive manifest"; 474 leaf id { 475 type key-identifier; 476 mandatory true; 477 description 478 "The key identifier referenced in a manifest."; 480 } 481 leaf algorithm { 482 type identityref { 483 base crypto-signature; 484 } 485 mandatory true; 486 description 487 "The signature algorithm for use with this key."; 488 } 489 leaf signature_bits { 490 type uint16; 491 mandatory true; 492 description 493 "The length of the signature provided in manifests 494 signed with this key."; 495 } 496 leaf value { 497 type string; 498 mandatory true; 499 description 500 "The base64-encoded value of the public key."; 501 } 502 } 504 list data_stream { 505 key id; 506 unique "source destination port"; 507 description "Stream of data packets to be authenticated"; 508 leaf id { 509 type uint16; 510 mandatory true; 511 description 512 "The datastream_id referenced by a 513 manifest_stream."; 514 } 515 leaf source { 516 type inet:ip-address; 517 mandatory true; 518 description 519 "The source IP address of the authenticated data 520 stream."; 521 } 522 leaf destination { 523 type rt-types:ip-multicast-group-address; 524 mandatory true; 525 description 526 "The destination group IP address of the 527 authenticated data stream."; 529 } 530 leaf port { 531 type uint16; 532 mandatory true; 533 description 534 "The destination UDP port of the authenticated data 535 stream."; 536 } 537 leaf max_bitrate { 538 type bitrate; 539 mandatory true; 540 description 541 "The maximum bitrate expected for this data 542 stream."; 543 } 544 leaf max_packetrate { 545 type packetrate; 546 mandatory true; 547 description 548 "The maximum packetrate expected for this data 549 stream."; 550 } 551 list authenticator { 552 key manifest_id; 553 description 554 "A manifest stream that authenticates this data"; 555 leaf manifest_id { 556 type leafref { 557 path "/anchor/manifest_stream/id"; 558 } 559 mandatory true; 560 description 561 "The ID of a manifest stream that provides 562 authentication for this data stream."; 563 } 564 } 565 } 567 list manifest_stream { 568 key id; 569 description "Stream of manifests"; 570 leaf id { 571 type uint16; 572 mandatory true; 573 description "The Manifest ID referenced in a manifest."; 574 } 575 leaf transport { 576 type manifest-transport; 577 mandatory true; 578 description 579 "The ID of the data stream that carries this 580 manifest stream or a uri that provides a websocket 581 with the stream of manifests."; 582 } 583 leaf hash_algorithm { 584 type identityref { 585 base crypto-hash; 586 } 587 mandatory true; 588 description 589 "The hash algorithm for the packet hashes within 590 manifests in this stream."; 591 } 592 leaf hash_bits { 593 type uint16; 594 mandatory true; 595 description 596 "The number of bits of hash provided for packet 597 hashes."; 598 } 599 leaf sequence_type { 600 type identityref { 601 base sequence-type; 602 } 603 mandatory true; 604 description 605 "The linkage to the data packet sequence numbers in 606 the manifest."; 607 } 608 } 609 } 610 } 611 613 Figure 1: Anchor Message YANG model 615 2.2.4. Example Anchor Message 617 { 618 "ietf-ambi-anchor:anchor": { 619 "self": { 620 "uri": "https://example.com/ambi/anchor/example_1.json", 621 "version": 1, 622 "hash_algorithm": "blake2b", 623 "hash_bits": 256, 624 "expires": "2018-03-05T23:59:59Z" 626 }, 627 "public_key": [ 628 { 629 "id": 1, 630 "algorithm": "ed25519", 631 "signature_bits": 256, 632 "value": "VGhpcyBpcyBub3QgYSBnb29kIGtleSB0byB1c2UuLi4NCg==" 633 } 634 ], 635 "data_stream": [ 636 { 637 "id": 10, 638 "source": "192.0.2.10", 639 "destination": "232.10.10.1", 640 "port": 18001, 641 "max_bitrate": "10Mbps", 642 "max_packetrate": "1Kpps", 643 "authenticator": [ 644 { 645 "manifest_id": 1 646 } 647 ] 648 }, 649 { 650 "id": 20, 651 "source": "192.0.2.10", 652 "destination": "232.10.10.1", 653 "port": 18002, 654 "max_bitrate": "400Kbps", 655 "max_packetrate": "40pps", 656 "authenticator": [ 657 { 658 "manifest_id": 2 659 } 660 ] 661 } 662 ], 663 "manifest_stream": [ 664 { 665 "id": 1, 666 "transport": 20, 667 "hash_algorithm": "blake2b", 668 "hash_bits": 80, 669 "sequence_type": "udp" 670 }, 671 { 672 "id": 2, 673 "transport": "https://example.com/ambi/manifest_stream/3", 674 "hash_algorithm": "blake2b", 675 "hash_bits": 80, 676 "sequence_type": "udp" 677 } 678 ] 679 } 680 } 682 Figure 2: Example Anchor Message 684 2.3. Manifests 686 2.3.1. Overview 688 A manifest cannot be interpreted except in context of a known anchor 689 message. In order for a manifest to be considered as potentially 690 authenticating a set of packets, the anchor version MUST match the 691 value in a known unexpired anchor message, and the hash MUST match 692 the hash of the contents of that anchor message, according to the 693 /anchor/self/hash_algorithm and /anchor/self/hash_bits fields, in 694 order for a manifest to be accepted for use as evidence of 695 authenticity and integrity. 697 2.3.2. Manifest Layout 698 0 1 2 3 699 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 700 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 701 | Ver=0 | Reserved=0 |S| Anchor Version | 702 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 703 | Anchor Hash (variable length, 4-byte aligned, 0-padded) | 704 | ... | 705 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 706 | Key ID | Manifest ID | 707 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 708 | First Packet Hash Identifier | 709 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 710 | Packet Identifier Step (if S-bit set) | 711 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 712 | Packet Hash Count | | 713 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 714 | | 715 | Cryptographic Signature (if Key ID nonzero) | 716 | | 717 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 718 | | 719 | ... Packet Hashes ... | 720 | | 721 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 723 3. IANA Considerations 725 TBD1: Request a "Specification Required" registry for Packet 726 identifier methods, from https://tools.ietf.org/html/rfc5226#section- 727 4.1 . Reserve anything beginning with "experimental:"? 729 TBD2: Add a new entry to the "UDP Option Kind" numbers registry: 730 https://tools.ietf.org/html/draft-ietf-tsvwg-udp-options- 731 02#section-14 733 TBD: check guidelines in https://tools.ietf.org/html/rfc5226 and 734 remove this paragraph 736 Example from: https://tools.ietf.org/html/rfc5226#section-5.1 738 [TO BE REMOVED: Please add the yang model in Section 2.2.3 to: 739 https://www.iana.org/assignments/yang-parameters/yang- 740 parameters.xhtml 742 Name:ietf-ambi-anchor Maintained by IANA: N Namespace: 743 urn:ietf:params:xml:ns:yang:ietf-ambi-anchor Prefix: anchor 744 Reference: I-D.draft-jholland-mboned-ambi Notes: ] 746 4. Security Considerations 748 4.1. Packet Identifiers 750 TBD: explain attack from generating malicious packets and then 751 looking for collisions, as opposed to having to generate a collision 752 including a sequence number and then hitting a match 754 TBD: DNSSEC vis-a-vis anchor url discovery. (we need a diagram about 755 for middle-box handling of a revers-path propagated join?) Explain 756 why malicious DNS could deny service, but cannot cause accepting 757 attack packets. 759 TBD: follow the rest of the guidelines: https://tools.ietf.org/html/ 760 rfc3552 762 5. References 764 5.1. Normative References 766 [I-D.ietf-tsvwg-udp-options] 767 Touch, J., "Transport Options for UDP", draft-ietf-tsvwg- 768 udp-options-02 (work in progress), January 2018. 770 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 771 Requirement Levels", BCP 14, RFC 2119, 772 DOI 10.17487/RFC2119, March 1997, 773 . 775 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 776 Jacobson, "RTP: A Transport Protocol for Real-Time 777 Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, 778 July 2003, . 780 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 781 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 782 RFC 3711, DOI 10.17487/RFC3711, March 2004, 783 . 785 5.2. Informative References 787 [DIGSIGN] Rohatgi, P., "How to Sign Digital Streams", 1997, 788 . 791 Published in CRYPTO '97 "Proceedings of the 17th Annual 792 International Cryptology Conference on Advances in 793 Cryptology", Pages 180-197 795 [RFC4082] Perrig, A., Song, D., Canetti, R., Tygar, J., and B. 796 Briscoe, "Timed Efficient Stream Loss-Tolerant 797 Authentication (TESLA): Multicast Source Authentication 798 Transform Introduction", RFC 4082, DOI 10.17487/RFC4082, 799 June 2005, . 801 [RFC4383] Baugher, M. and E. Carrara, "The Use of Timed Efficient 802 Stream Loss-Tolerant Authentication (TESLA) in the Secure 803 Real-time Transport Protocol (SRTP)", RFC 4383, 804 DOI 10.17487/RFC4383, February 2006, 805 . 807 [RFC5776] Roca, V., Francillon, A., and S. Faurite, "Use of Timed 808 Efficient Stream Loss-Tolerant Authentication (TESLA) in 809 the Asynchronous Layered Coding (ALC) and NACK-Oriented 810 Reliable Multicast (NORM) Protocols", RFC 5776, 811 DOI 10.17487/RFC5776, April 2010, 812 . 814 [RFC6584] Roca, V., "Simple Authentication Schemes for the 815 Asynchronous Layered Coding (ALC) and NACK-Oriented 816 Reliable Multicast (NORM) Protocols", RFC 6584, 817 DOI 10.17487/RFC6584, April 2012, 818 . 820 Authors' Addresses 822 Jake Holland 823 Akamai Technologies, Inc. 824 150 Broadway 825 Cambridge, MA 02144 826 United States of America 828 Email: jakeholland.net@gmail.com 830 Kyle Rose 831 Akamai Technologies, Inc. 832 150 Broadway 833 Cambridge, MA 02144 834 United States of America 836 Email: krose@krose.org