idnits 2.17.1 draft-ietf-mboned-dorms-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 : ---------------------------------------------------------------------------- == There are 1 instance of lines with multicast IPv4 addresses in the document. If these are generic example addresses, they should be changed to use the 233.252.0.x range defined in RFC 5771 Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 430 has weird spacing: '...address ine...' == Line 432 has weird spacing: '...address rt-...' == Line 434 has weird spacing: '...rw port ine...' -- The document date (March 10, 2020) is 1500 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) == Unused Reference: 'RFC6991' is defined on line 686, but no explicit reference was found in the text == Unused Reference: 'RFC8294' is defined on line 702, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 2845 (Obsoleted by RFC 8945) Summary: 0 errors (**), 0 flaws (~~), 7 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Mboned J. Holland 3 Internet-Draft Akamai Technologies, Inc. 4 Intended status: Standards Track March 10, 2020 5 Expires: September 11, 2020 7 Discovery Of Restconf Metadata for Source-specific multicast 8 draft-ietf-mboned-dorms-00 10 Abstract 12 This document defines DORMS (Discovery Of Restconf Metadata for 13 Source-specific multicast), a method to discover and retrieve 14 extensible metadata about source-specific multicast channels using 15 RESTCONF. The reverse IP DNS zone for a multicast sender's IP 16 address is configured to use SRV resource records to advertise the 17 hostname of a RESTCONF server that publishes metadata according to a 18 new YANG module with support for extensions. A new service name and 19 the new YANG module are defined. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at https://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on September 11, 2020. 38 Copyright Notice 40 Copyright (c) 2020 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (https://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 1.1. Background . . . . . . . . . . . . . . . . . . . . . . . 3 57 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Discovery and Metdata Retrieval . . . . . . . . . . . . . . . 4 59 2.1. DNS Bootstrap . . . . . . . . . . . . . . . . . . . . . . 4 60 2.2. RESTCONF Bootstrap . . . . . . . . . . . . . . . . . . . 5 61 2.2.1. Root Resource Discovery . . . . . . . . . . . . . . . 5 62 2.2.2. Yang Library Version . . . . . . . . . . . . . . . . 6 63 2.2.3. Yang Library Contents . . . . . . . . . . . . . . . . 6 64 2.2.4. Metadata Retrieval . . . . . . . . . . . . . . . . . 7 65 2.2.5. Cross Origin Resource Sharing (CORS) . . . . . . . . 8 66 3. Scalability Considerations . . . . . . . . . . . . . . . . . 9 67 3.1. Provisioning . . . . . . . . . . . . . . . . . . . . . . 9 68 3.2. Data Scoping . . . . . . . . . . . . . . . . . . . . . . 9 69 4. YANG Model . . . . . . . . . . . . . . . . . . . . . . . . . 9 70 4.1. Yang Tree . . . . . . . . . . . . . . . . . . . . . . . . 10 71 4.2. Yang Module . . . . . . . . . . . . . . . . . . . . . . . 10 72 5. Privacy Considerations . . . . . . . . . . . . . . . . . . . 12 73 5.1. Linking Content to Traffic Streams . . . . . . . . . . . 12 74 5.2. Linking Multicast Subscribers to Unicast Connections . . 12 75 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 76 6.1. The YANG Module Names Registry . . . . . . . . . . . . . 13 77 6.2. The Service Name and Transport Protocol Port Number 78 Registry . . . . . . . . . . . . . . . . . . . . . . . . 13 79 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 80 7.1. Secure Communications . . . . . . . . . . . . . . . . . . 13 81 7.2. Exposure of Metadata . . . . . . . . . . . . . . . . . . 14 82 7.3. DNS Bootstrapping . . . . . . . . . . . . . . . . . . . . 14 83 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 84 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 85 9.1. Normative References . . . . . . . . . . . . . . . . . . 15 86 9.2. Informative References . . . . . . . . . . . . . . . . . 16 87 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 17 89 1. Introduction 91 This document defines DORMS (Discovery Of Restconf Metadata for 92 Source-specific multicast). 94 A DORMS service is a RESTCONF [RFC8040] service that provides read 95 access to data in the "ietf-dorms" YANG [RFC7950] model defined in 96 Section 4. This model, along with optional extensions defined in 97 other documents, provide an extensible set of information about 98 multicast data streams. 100 This document defines the "dorms" service name for use with the SRV 101 DNS Resource Record (RR) type [RFC2782]. A sender offering a DORMS 102 service to publish metadata SHOULD configure at least one SRV RR for 103 the "_dorms._tcp" subdomain in the reverse IP DNS zone for the source 104 IP of its multicast channel to advertise a hostname for a DORMS 105 server that can provide metadata for the sender's source-specific 106 multicast traffic. Doing so enables receivers and middleboxes to 107 discover and query a DORMS server as described in Section 2. 109 The goal is to provide an extensible framework for attaching 110 information necessary for the correct processing of multicast data 111 channels, both for middle boxes forwarding the traffic, and for 112 receivers subscribing to traffic (hereafter called "clients"). 114 1.1. Background 116 The reader is assumed to be familiar with the basic DNS concepts 117 described in [RFC1034], [RFC1035], and the subsequent documents that 118 update them, as well as the use of the SRV Resource Record type as 119 described in [RFC2782]. 121 The reader is also assumed to be familiar with the concepts and 122 terminology regarding source-specific multicast as described in 123 [RFC4607] and the use of IGMPv3 [RFC3376] and MLDv2 [RFC3810] for 124 group management of source-specific multicast channels, as described 125 in [RFC4604]. 127 The reader is also assumed to be familiar with the concepts and 128 terminology for RESTCONF [RFC8040] and YANG [RFC7950]. 130 1.2. Terminology 132 +--------+----------------------------------------------------------+ 133 | Term | Definition | 134 +--------+----------------------------------------------------------+ 135 | (S,G) | A source-specific multicast channel, as described in | 136 | | [RFC4607]. A pair of IP addresses with a source host IP | 137 | | and destination group IP. | 138 | | | 139 | RR | A DNS Resource Record, as described in [RFC1034] | 140 | | | 141 | RRType | A DNS Resource Record Type, as described in [RFC1034] | 142 | | | 143 | SSM | Source-specific multicast, as described in [RFC4607] | 144 +--------+----------------------------------------------------------+ 145 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 146 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 147 "OPTIONAL" in this document are to be interpreted as described in 148 [RFC2119] and [RFC8174] when, and only when, they appear in all 149 capitals, as shown here. 151 2. Discovery and Metdata Retrieval 153 A client that needs metadata about a (S,G) MAY attempt to discover 154 metadata for the (S,G) using the mechanisms defined here, and MAY use 155 the metadata received to manage the forwarding or processing of the 156 packets in the channel. 158 2.1. DNS Bootstrap 160 The DNS Bootstrap step is how a client discovers an appropriate 161 RESTCONF server, given the source address of an (S,G). Use of the 162 DNS Bootstrap is OPTIONAL for clients with an alternate method of 163 obtaining a RESTCONF hostname for a DORMS server with metadata for an 164 (S,G). 166 This mechanism only works for source-specific multicast (SSM) 167 channels. The source address of the (S,G) is reversed and used as an 168 index into one of the reverse mapping trees (in-addr.arpa for IPv4, 169 as described in Section 3.5 of [RFC1035], or ip6.arpa for IPv6, as 170 described in Section 2.5 of [RFC3596]). 172 When a receiver or middle box needs metadata for an (S,G), for 173 example when handling a new join for that (S,G) and looking up 174 authentication methods available, a receiver or middlebox can issue a 175 DNS query for a SRV RR using the "dorms" service name with the domain 176 from the reverse mapping tree, combining them as described in 177 [RFC2782]. 179 For example, while handling a join for (203.0.113.15, 232.1.1.1), a 180 receiver would perform a DNS query for the SRV RRType for the domain: 182 _dorms._tcp.15.113.0.203.in-addr.arpa. 184 The DNS response for this domain might return a record such as: 186 SRV 0 1 443 dorms-restconf.example.com. 188 This response informs the receiver that a DORMS server SHOULD be 189 reachable at dorms-restconf.example.com on port 443. Multiple SRV 190 records are handled as described by [RFC2782]. 192 A sender providing DORMS discovery SHOULD publish at least one SRV 193 record in the reverse DNS zone for each source address of the 194 multicast channels it is sending, in order to advertise the hostname 195 of the DORMS server to receivers and middle boxes. The DORMS servers 196 advertised SHOULD be configured with metadata for all the groups sent 197 from the same source IP address that have metadata published with 198 DORMS. 200 2.2. RESTCONF Bootstrap 202 Once a DORMS host has been chosen (whether via an SRV RR from a DNS 203 response or via some other method), RESTCONF provides all the 204 information necessary to determine the versions and url paths for 205 metadata from the server. A walkthrough is provided here for a 206 sequence of example requests and responses from a receiver connecting 207 to a new DORMS server. 209 2.2.1. Root Resource Discovery 211 As described in Section 3.1 of [RFC8040] and [RFC6415], the RESTCONF 212 server provides the link to the RESTCONF api entry point via the 213 "/.well-known/host-meta" or "/.well-known/host-meta.json" resource. 215 Example: 217 The receiver might send: 219 GET /.well-known/host-meta.json HTTP/1.1 220 Host: dorms-restconf.example.com 221 Accept: application/json 223 The server might respond as follows: 225 HTTP/1.1 200 OK 226 Date: Tue, 27 Aug 2019 20:56:00 GMT 227 Server: example-server 228 Cache-Control: no-cache 229 Content-Type: application/json 231 { 232 "links":[ 233 { 234 "rel":"restconf", 235 "href":"/top/restconf" 236 } 237 ] 238 } 240 2.2.2. Yang Library Version 242 As described in Section 3.3.3 of [RFC8040], the yang-library-version 243 leaf is required by RESTCONF, and can be used to determine the schema 244 of the ietf-yang-library module: 246 Example: 248 The receiver might send: 250 GET /top/restconf/yang-library-version HTTP/1.1 251 Host: dorms-restconf.example.com 252 Accept: application/yang-data+json 254 The server might respond as follows: 256 HTTP/1.1 200 OK 257 Date: Tue, 27 Aug 2019 20:56:01 GMT 258 Server: example-server 259 Cache-Control: no-cache 260 Content-Type: application/yang-data+json 262 { 263 "ietf-restconf:yang-library-version": "2016-06-21" 264 } 266 TBD: We might need a method for learning a specific restconf server 267 or resource path that supports a version the client knows how to use, 268 in the case the client is older than the server after a new yang- 269 library version is released... Can this be just retry with a hold- 270 down on specific hostnames, so that you can find a lower priority 271 older server from the SRV records, or is signaling that can find or 272 negotiate an explicit version as part of the lookup going to be 273 necessary? -jake 2019-08-26 275 2.2.3. Yang Library Contents 277 After checking that the version of the yang-library module will be 278 understood by the receiver, the client can check that the desired 279 metadata module is available on the DORMS server by fetching the 280 module-state resource from the ietf-yang-library module. 282 Example: 284 The receiver might send: 286 GET /top/restconf/data/ietf-yang-library:modules-state/\ 287 module=ietf-dorms,2016-08-15 288 Host: dorms-restconf.example.com 289 Accept: application/yang-data+json 291 The server might respond as follows: 293 HTTP/1.1 200 OK 294 Date: Tue, 27 Aug 2019 20:56:02 GMT 295 Server: example-server 296 Cache-Control: no-cache 297 Content-Type: application/yang-data+json 299 { 300 "ietf-yang-library:module": [ 301 { 302 "conformance-type": "implement", 303 "name": "ietf-dorms", 304 "namespace": "urn:ietf:params:xml:ns:yang:ietf-dorms", 305 "revision": "2019-08-25", 306 "schema": 307 "https://example.com/yang/ietf-dorms@2019-08-25.yang" 308 } 309 ] 310 } 312 Other modules required or desired by the client also can be checked 313 in a similar way, or the full set of available modules can be 314 retrieved by not providing a key for the "module" list. 316 2.2.4. Metadata Retrieval 318 Once the expected DORMS version is confirmed, the client can retrieve 319 the metadata specific to the desired (S,G). 321 Example: 323 The receiver might send: 325 GET /top/restconf/data/ietf-dorms:metadata/\ 326 sender=203.0.113.15/group=232.1.1.1 327 Host: dorms-restconf.example.com 328 Accept: application/yang-data+json 330 The server might respond as follows: 332 HTTP/1.1 200 OK 333 Date: Tue, 27 Aug 2019 20:56:02 GMT 334 Server: example-server 335 Cache-Control: no-cache 336 Content-Type: application/yang-data+json 338 { 339 "ietf-dorms:group": [ 340 { 341 "group-address":"232.1.1.1", 342 "udp-stream":[ 343 { 344 "port":"5001" 345 } 346 ] 347 } 348 ] 349 } 351 Note that when other modules are installed on the DORMS server that 352 extend the ietf-dorms module, other fields MAY appear inside the 353 response. This is the primary mechanism for providing extensible 354 metadata for an (S,G), so clients SHOULD ignore fields they do not 355 understand. 357 As mentioned in Section 3.2, most clients SHOULD use data resource 358 identifiers in the request URI as in the above example, in order to 359 retrieve metadata for only the targeted (S,G)s. 361 2.2.5. Cross Origin Resource Sharing (CORS) 363 It is RECOMMENDED that DORMS servers use the Access-Control-Allow- 364 Origin header field, as specified by [W3C.REC-cors-20140116], and 365 that they respond appropriately to Preflight requests. 367 Providing '*' for the allowed origins exposes the DORMS-based 368 metadata to all web pages. When access to the metadata is used as a 369 prerequisite to permitting the joining of the multicast flows, this 370 would permit scripts from arbitrary web pages to issue joins for the 371 multicast flows, which could allow e.g. malicious advertisements to 372 participate in overjoining attacks (see Appendix A of 373 [I-D.draft-jholland-cb-assisted-cc-01]) using multicast flows not 374 controlled by the ad's senders. Therefore the use of '*' for allowed 375 origins is NOT RECOMMENDED. (TBD: this probably deserves a security 376 considerations section.) 378 3. Scalability Considerations 380 3.1. Provisioning 382 In contrast to many common RESTCONF deployments that are intended to 383 provide configuration management for a service to a narrow set of 384 authenticated administrators, DORMS servers often provide read-only 385 metadata for public access, or for a very large set of end receivers, 386 since it provides metadata in support of multicast data streams and 387 multicast can scale to very large audiences. 389 Operators are advised to provision the DORMS service in a way that 390 will scale appropriately to the size of the expected audience. 391 Specific advice on such scaling is out of scope for this document, 392 but some of the mechanisms outlined in [RFC3040] or other online 393 resources might be useful, depending on the expected number of 394 receivers. 396 3.2. Data Scoping 398 In the absence of contextual information, clients SHOULD issue 399 narrowed requests for DORMS resources by following the format from 400 Section 3.5.3 of [RFC8040] to encode data resource identifiers in the 401 request URI. This avoids downloading excessive data, since the DORMS 402 server may provide metadata for many (S,G)s, possibly from many 403 different senders. 405 However, clients MAY use heuristics or out of band information about 406 the service to issue requests for (S,G) metadata narrowed only by the 407 source-address, or not narrowed at all. Depending on the request 408 patterns and the contents of the data store, this may result in fewer 409 round trips or less overhead, and can therefore be helpful behavior 410 for scaling purposes. Servers MAY restrict or throttle client access 411 based on the client certificate presented (if any), or based on 412 heuristics that take note of client request patterns. 414 A complete description of the heuristics for clients and servers to 415 meet their scalability goals is out of scope for this document. 417 4. YANG Model 419 The primary purpose of the YANG model defined here is to serve as a 420 scaffold for the more useful metadata that will extend it. Currently 421 known use cases include providing authentication information and bit- 422 rate information for use by receivers and middle boxes, but more use 423 cases are anticipated. 425 4.1. Yang Tree 427 module: ietf-dorms 428 +--rw metadata 429 +--rw sender* [source-address] 430 +--rw source-address inet:ip-address 431 +--rw group* [group-address] 432 +--rw group-address rt-types:ip-multicast-group-address 433 +--rw udp-stream* [port] 434 +--rw port inet:port-number 436 DORMS Tree Diagram 438 4.2. Yang Module 440 file ietf-dorms@2020-03-10.yang 441 module ietf-dorms { 442 yang-version 1.1; 444 namespace "urn:ietf:params:xml:ns:yang:ietf-dorms"; 445 prefix "dorms"; 447 import ietf-inet-types { 448 prefix "inet"; 449 reference "RFC 6991 Section 4"; 450 } 452 import ietf-routing-types { 453 prefix "rt-types"; 454 reference "RFC 8294"; 455 } 457 organization "IETF"; 459 contact 460 "Author: Jake Holland 461 462 "; 464 description 465 "Copyright (c) 2019 IETF Trust and the persons identified as 466 authors of the code. All rights reserved. 468 Redistribution and use in source and binary forms, with or 469 without modification, is permitted pursuant to, and subject to 470 the license terms contained in, the Simplified BSD License set 471 forth in Section 4.c of the IETF Trust's Legal Provisions 472 Relating to IETF Documents 473 (https://trustee.ietf.org/license-info). 475 This version of this YANG module is part of RFC XXXX 476 (https://www.rfc-editor.org/info/rfcXXXX); see the RFC itself 477 for full legal notices. 479 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL 480 NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED', 481 'MAY', and 'OPTIONAL' in this document are to be interpreted as 482 described in BCP 14 (RFC 2119) (RFC 8174) when, and only when, 483 they appear in all capitals, as shown here. 485 This module contains the definition for the DORMS data type. 486 It provides out of band metadata about SSM channels."; 488 revision 2019-08-25 { 489 description "Initial revision."; 490 reference 491 ""; 492 // "I-D.draft-jholland-mboned-dorms"; 493 } 495 container metadata { 496 description "Metadata scaffold for source-specific multicast 497 channels."; 498 list sender { 499 key source-address; 500 description "Sender for DORMS"; 502 leaf source-address { 503 type inet:ip-address; 504 mandatory true; 505 description 506 "The source IP address of a multicast sender."; 507 } 509 list group { 510 key group-address; 511 description "Metadata for a DORMS (S,G)."; 513 leaf group-address { 514 type rt-types:ip-multicast-group-address; 515 mandatory true; 516 description "The group IP address for an (S,G)."; 517 } 519 list udp-stream { 520 key "port"; 521 description 522 "Metadata for UDP traffic on a specific port."; 523 leaf port { 524 type inet:port-number; 525 mandatory true; 526 description 527 "The UDP port of a data stream in an (S,G)."; 528 } 529 } 530 } 531 } 532 } 533 } 534 536 5. Privacy Considerations 538 5.1. Linking Content to Traffic Streams 540 In the typical case, the mechanisms defined in this document provide 541 a standardized way to discover information that is already available 542 in other ways. 544 However, depending on the metadata provided by the server, observers 545 may be able to more easily associate traffic from an (S,G) with the 546 content contained within the (S,G). At the subscriber edge of a 547 multicast-capable network, where the network operator has the 548 capability to localize an IGMP [RFC3376] or MLD [RFC3810] channel 549 subscription to a specific user or location by MAC address or source 550 IP address, the structured publishing of metadata may make it easier 551 to automate collection of data about the content a receiver is 552 consuming. 554 5.2. Linking Multicast Subscribers to Unicast Connections 556 Subscription to a multicast channel generally only exposes the IGMP 557 or MLD membership report to others on the same LAN, and as the 558 membership propagates through a multicast-capable network, it 559 ordinarily gets aggregated with other end users. 561 However, a RESTCONF connection is a unicast connection, and exposes a 562 different set of information to the operator of the RESTCONF server, 563 including IP address and timing about the requests made. Where DORMS 564 access becomes required to succeed a multicast join, as expected in a 565 browser deployment, this can expose new information about end users 566 relative to services based solely on multicast streams. 568 In some deployments it may be possible to use a proxy that aggregates 569 many end users when the aggregate privacy characteristics are needed 570 by end users. 572 6. IANA Considerations 574 6.1. The YANG Module Names Registry 576 This document adds one YANG module to the "YANG Module Names" 577 registry maintained at . The following registrations are made, per the format in 579 Section 14 of [RFC6020]: 581 name: ietf-dorms 582 namespace: urn:ietf:params:xml:ns:yang:ietf-dorms 583 prefix: dorms 584 reference: I-D.draft-jholland-mboned-dorms 586 6.2. The Service Name and Transport Protocol Port Number Registry 588 This document adds one service name to the "Service Name and 589 Transport Protocol Port Number Registry" maintained at 590 . The 591 following registrations are made, per the format in Section 8.1.1 of 592 [RFC6335]: 594 Service Name: dorms 595 Transport Protocol(s): TCP 596 Assignee: IESG 597 Contact: IETF Chair 598 Description: This service name is used to construct the 599 SRV service label "_dorms" for discovering 600 DORMS servers. 601 Reference: I-D.draft-jholland-mboned-dorms 602 Port Number: N/A 603 Service Code: N/A 604 Known Unauthorized Uses: N/A 605 Assignment Notes: This protocol uses HTTPS as a substrate. 607 7. Security Considerations 609 7.1. Secure Communications 611 It is intended that security related metadata about the SSM channels 612 will be delivered over the RESTCONF connection, and that information 613 available from this connection can be used as a trust anchor. 615 The provisions of Section 2 of [RFC8040] provide secure communication 616 requirements that are already required of DORMS servers, since they 617 are RESTCONF servers. All RESTCONF requirements and security 618 considerations remain in force for DORMS servers. 620 7.2. Exposure of Metadata 622 Although some DORMS servers MAY restrict access based on client 623 identity, as described in Section 2.5 of [RFC8040], many DORMS 624 servers will use the ietf-dorms YANG model to publish information 625 without restriction, and even DORMS servers requiring client 626 authentication will inherently, because of the purpose of DORMS, be 627 providing the DORMS metadata to potentially many receivers. 629 Accordingly, future YANG modules that augment data paths under "ietf- 630 dorms:metadata" MUST NOT include any sensitive data unsuitable for 631 public dissemination in those data paths. Because of the possibility 632 that scalable read-only access might be necessary to fulfill the 633 scalability goals for a DORMS server, data under these paths MAY be 634 cached or replicated by numerous external entities, so owners of such 635 data SHOULD NOT assume it can be kept secret when provided by DORMS 636 servers anywhere under the "ietf-dorms:metadata" path, even if they 637 are authenticating clients. 639 7.3. DNS Bootstrapping 641 The DNS bootstrap phase relies on DNS for the reverse IP tree. When 642 using DNS to discover a DORMS server's domain name, there must be a 643 trust relationship between the end consumer of this resource record 644 and the DNS server. This relationship may be end-to-end DNSSEC 645 validation, a TSIG [RFC2845] or SIG(0) [RFC2931] channel to another 646 secure source, a secure local channel on the host, DNS over TLS 647 [RFC7858] or HTTPS [RFC8484], or some other secure mechanism. 649 If the SRV Resource Record cannot be authenticated, it may be 650 possible for an attacker who can spoof the resource record to perform 651 a denial of service for the receiver by providing wrong or missing 652 authentication metadata. An attacker who can also inject traffic for 653 (S,G)s, would also be able to provide false content in the data 654 stream, so an attacker who can perform both could provide 655 authenticated false content by authenticating with a trust anchor 656 from an attacker-controlled DORMS server. 658 Clients MAY use other secure methods to explicitly associate an (S,G) 659 with a set of DORMS server hostnames, such as a configured mapping or 660 an alternative trusted lookup service. 662 8. Acknowledgements 664 Thanks to Christian Worm Mortensen for some very helpful comments and 665 review. 667 9. References 669 9.1. Normative References 671 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 672 Requirement Levels", BCP 14, RFC 2119, 673 DOI 10.17487/RFC2119, March 1997, 674 . 676 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 677 specifying the location of services (DNS SRV)", RFC 2782, 678 DOI 10.17487/RFC2782, February 2000, 679 . 681 [RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, 682 "DNS Extensions to Support IP Version 6", STD 88, 683 RFC 3596, DOI 10.17487/RFC3596, October 2003, 684 . 686 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", 687 RFC 6991, DOI 10.17487/RFC6991, July 2013, 688 . 690 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 691 RFC 7950, DOI 10.17487/RFC7950, August 2016, 692 . 694 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 695 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 696 . 698 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 699 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 700 May 2017, . 702 [RFC8294] Liu, X., Qu, Y., Lindem, A., Hopps, C., and L. Berger, 703 "Common YANG Data Types for the Routing Area", RFC 8294, 704 DOI 10.17487/RFC8294, December 2017, 705 . 707 [W3C.REC-cors-20140116] 708 Kesteren, A., "Cross-Origin Resource Sharing", World Wide 709 Web Consortium Recommendation REC-cors-20140116, January 710 2014, . 712 9.2. Informative References 714 [I-D.draft-jholland-cb-assisted-cc-01] 715 Holland, J., "Circuit Breaker Assisted Congestion Control 716 (CBACC): Protocol Specification", draft-jholland-cb- 717 assisted-cc-01 (work in progress), April 2017. 719 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 720 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 721 . 723 [RFC1035] Mockapetris, P., "Domain names - implementation and 724 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 725 November 1987, . 727 [RFC2845] Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B. 728 Wellington, "Secret Key Transaction Authentication for DNS 729 (TSIG)", RFC 2845, DOI 10.17487/RFC2845, May 2000, 730 . 732 [RFC2931] Eastlake 3rd, D., "DNS Request and Transaction Signatures 733 ( SIG(0)s )", RFC 2931, DOI 10.17487/RFC2931, September 734 2000, . 736 [RFC3040] Cooper, I., Melve, I., and G. Tomlinson, "Internet Web 737 Replication and Caching Taxonomy", RFC 3040, 738 DOI 10.17487/RFC3040, January 2001, 739 . 741 [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. 742 Thyagarajan, "Internet Group Management Protocol, Version 743 3", RFC 3376, DOI 10.17487/RFC3376, October 2002, 744 . 746 [RFC3810] Vida, R., Ed. and L. Costa, Ed., "Multicast Listener 747 Discovery Version 2 (MLDv2) for IPv6", RFC 3810, 748 DOI 10.17487/RFC3810, June 2004, 749 . 751 [RFC4604] Holbrook, H., Cain, B., and B. Haberman, "Using Internet 752 Group Management Protocol Version 3 (IGMPv3) and Multicast 753 Listener Discovery Protocol Version 2 (MLDv2) for Source- 754 Specific Multicast", RFC 4604, DOI 10.17487/RFC4604, 755 August 2006, . 757 [RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for 758 IP", RFC 4607, DOI 10.17487/RFC4607, August 2006, 759 . 761 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 762 the Network Configuration Protocol (NETCONF)", RFC 6020, 763 DOI 10.17487/RFC6020, October 2010, 764 . 766 [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. 767 Cheshire, "Internet Assigned Numbers Authority (IANA) 768 Procedures for the Management of the Service Name and 769 Transport Protocol Port Number Registry", BCP 165, 770 RFC 6335, DOI 10.17487/RFC6335, August 2011, 771 . 773 [RFC6415] Hammer-Lahav, E., Ed. and B. Cook, "Web Host Metadata", 774 RFC 6415, DOI 10.17487/RFC6415, October 2011, 775 . 777 [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., 778 and P. Hoffman, "Specification for DNS over Transport 779 Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 780 2016, . 782 [RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS 783 (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, 784 . 786 [whatwg-fetch] 787 Kesteren, A., "WHATWG Fetch Living Standard", August 2019, 788 . 790 Author's Address 792 Jake Holland 793 Akamai Technologies, Inc. 794 150 Broadway 795 Cambridge, MA 02144 796 United States of America 798 Email: jakeholland.net@gmail.com