idnits 2.17.1 draft-jholland-mboned-dorms-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 : ---------------------------------------------------------------------------- == 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 429 has weird spacing: '...address ine...' == Line 431 has weird spacing: '...address rt-...' == Line 433 has weird spacing: '...rw port ine...' -- 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) == Unused Reference: 'RFC6991' is defined on line 670, but no explicit reference was found in the text == Unused Reference: 'RFC8294' is defined on line 686, 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 September 26, 2019 5 Expires: March 29, 2020 7 Discovery Of Restconf Metadata for Source-specific multicast 8 draft-jholland-mboned-dorms-01 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 March 29, 2020. 38 Copyright Notice 40 Copyright (c) 2019 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 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 74 6.1. The YANG Module Names Registry . . . . . . . . . . . . . 12 75 6.2. The Service Name and Transport Protocol Port Number 76 Registry . . . . . . . . . . . . . . . . . . . . . . . . 13 77 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 78 7.1. Secure Communications . . . . . . . . . . . . . . . . . . 13 79 7.2. Exposure of Metadata . . . . . . . . . . . . . . . . . . 13 80 7.3. DNS Bootstrapping . . . . . . . . . . . . . . . . . . . . 14 81 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 82 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 83 9.1. Normative References . . . . . . . . . . . . . . . . . . 14 84 9.2. Informative References . . . . . . . . . . . . . . . . . 15 85 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 17 87 1. Introduction 89 This document defines DORMS (Discovery Of Restconf Metadata for 90 Source-specific multicast). 92 A DORMS service is a RESTCONF [RFC8040] service that provides read 93 access to data in the "ietf-dorms" YANG [RFC7950] model defined in 94 Section 4. This model, along with optional extensions defined in 95 other documents, provide an extensible set of information about 96 multicast data streams. 98 This document defines the "dorms" service name for use with the SRV 99 DNS Resource Record (RR) type [RFC2782]. A sender offering a DORMS 100 service to publish metadata SHOULD configure at least one SRV RR for 101 the "_dorms._tcp" subdomain in the reverse IP DNS zone for the source 102 IP of its multicast channel to advertise a hostname for a DORMS 103 server that can provide metadata for the sender's source-specific 104 multicast traffic. Doing so enables receivers and middleboxes to 105 discover and query a DORMS server as described in Section 2. 107 The goal is to provide an extensible framework for attaching 108 information necessary for the correct processing of multicast data 109 channels, both for middle boxes forwarding the traffic, and for 110 receivers subscribing to traffic (hereafter called "clients"). 112 1.1. Background 114 The reader is assumed to be familiar with the basic DNS concepts 115 described in [RFC1034], [RFC1035], and the subsequent documents that 116 update them, as well as the use of the SRV Resource Record type as 117 described in [RFC2782]. 119 The reader is also assumed to be familiar with the concepts and 120 terminology regarding source-specific multicast as described in 121 [RFC4607] and the use of IGMPv3 [RFC3376] and MLDv2 [RFC3810] for 122 group management of source-specific multicast channels, as described 123 in [RFC4604]. 125 The reader is also assumed to be familiar with the concepts and 126 terminology for RESTCONF [RFC8040] and YANG [RFC7950]. 128 1.2. Terminology 130 +--------+----------------------------------------------------------+ 131 | Term | Definition | 132 +--------+----------------------------------------------------------+ 133 | (S,G) | A source-specific multicast channel, as described in | 134 | | [RFC4607]. A pair of IP addresses with a source host IP | 135 | | and destination group IP. | 136 | | | 137 | RR | A DNS Resource Record, as described in [RFC1034] | 138 | | | 139 | RRType | A DNS Resource Record Type, as described in [RFC1034] | 140 | | | 141 | SSM | Source-specific multicast, as described in [RFC4607] | 142 +--------+----------------------------------------------------------+ 144 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 145 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 146 "OPTIONAL" in this document are to be interpreted as described in 147 [RFC2119] and [RFC8174] when, and only when, they appear in all 148 capitals, as shown here. 150 2. Discovery and Metdata Retrieval 152 A client that needs metadata about a (S,G) MAY attempt to discover 153 metadata for the (S,G) using the mechanisms defined here, and MAY use 154 the metadata received to manage the forwarding or processing of the 155 packets in the channel. 157 2.1. DNS Bootstrap 159 The DNS Bootstrap step is how a client discovers an appropriate 160 RESTCONF server, given the source address of an (S,G). Use of the 161 DNS Bootstrap is OPTIONAL for clients with an alternate method of 162 obtaining a RESTCONF hostname for a DORMS server with metadata for an 163 (S,G). 165 This mechanism only works for source-specific multicast (SSM) 166 channels. The source address of the (S,G) is reversed and used as an 167 index into one of the reverse mapping trees (in-addr.arpa for IPv4, 168 as described in Section 3.5 of [RFC1035], or ip6.arpa for IPv6, as 169 described in Section 2.5 of [RFC3596]). 171 When a receiver or middle box needs metadata for an (S,G), for 172 example when handling a new join for that (S,G) and looking up 173 authentication methods available, a receiver or middlebox can issue a 174 DNS query for a SRV RR using the "dorms" service name with the domain 175 from the reverse mapping tree, combining them as described in 176 [RFC2782]. 178 For example, while handling a join for (203.0.113.15, 232.1.1.1), a 179 receiver would perform a DNS query for the SRV RRType for the domain: 181 _dorms._tcp.15.113.0.203.in-addr.arpa. 183 The DNS response for this domain might return a record such as: 185 SRV 0 1 443 dorms-restconf.example.com. 187 This response informs the receiver that a DORMS server SHOULD be 188 reachable at dorms-restconf.example.com on port 443. Multiple SRV 189 records are handled as described by [RFC2782]. 191 A sender providing DORMS discovery SHOULD publish at least one SRV 192 record in the reverse DNS zone for each source address of the 193 multicast channels it is sending, in order to advertise the hostname 194 of the DORMS server to receivers and middle boxes. The DORMS servers 195 advertised SHOULD be configured with metadata for all the groups sent 196 from the same source IP address that have metadata published with 197 DORMS. 199 2.2. RESTCONF Bootstrap 201 Once a DORMS host has been chosen (whether via an SRV RR from a DNS 202 response or via some other method), RESTCONF provides all the 203 information necessary to determine the versions and url paths for 204 metadata from the server. A walkthrough is provided here for a 205 sequence of example requests and responses from a receiver connecting 206 to a new DORMS server. 208 2.2.1. Root Resource Discovery 210 As described in Section 3.1 of [RFC8040] and [RFC6415], the RESTCONF 211 server provides the link to the RESTCONF api entry point via the 212 "/.well-known/host-meta" or "/.well-known/host-meta.json" resource. 214 Example: 216 The receiver might send: 218 GET /.well-known/host-meta.json HTTP/1.1 219 Host: dorms-restconf.example.com 220 Accept: application/json 222 The server might respond as follows: 224 HTTP/1.1 200 OK 225 Date: Tue, 27 Aug 2019 20:56:00 GMT 226 Server: example-server 227 Cache-Control: no-cache 228 Content-Type: application/json 230 { 231 "links":[ 232 { 233 "rel":"restconf", 234 "href":"/top/restconf" 235 } 236 ] 237 } 239 2.2.2. Yang Library Version 241 As described in Section 3.3.3 of [RFC8040], the yang-library-version 242 leaf is required by RESTCONF, and can be used to determine the schema 243 of the ietf-yang-library module: 245 Example: 247 The receiver might send: 249 GET /top/restconf/yang-library-version HTTP/1.1 250 Host: dorms-restconf.example.com 251 Accept: application/yang-data+json 253 The server might respond as follows: 255 HTTP/1.1 200 OK 256 Date: Tue, 27 Aug 2019 20:56:01 GMT 257 Server: example-server 258 Cache-Control: no-cache 259 Content-Type: application/yang-data+json 261 { 262 "ietf-restconf:yang-library-version": "2016-06-21" 263 } 265 TBD: We might need a method for learning a specific restconf server 266 or resource path that supports a version the client knows how to use, 267 in the case the client is older than the server after a new yang- 268 library version is released... Can this be just retry with a hold- 269 down on specific hostnames, so that you can find a lower priority 270 older server from the SRV records, or is signaling that can find or 271 negotiate an explicit version as part of the lookup going to be 272 necessary? -jake 2019-08-26 274 2.2.3. Yang Library Contents 276 After checking that the version of the yang-library module will be 277 understood by the receiver, the client can check that the desired 278 metadata module is available on the DORMS server by fetching the 279 module-state resource from the ietf-yang-library module. 281 Example: 283 The receiver might send: 285 GET /top/restconf/data/ietf-yang-library:modules-state/\ 286 module=ietf-dorms,2016-08-15 287 Host: dorms-restconf.example.com 288 Accept: application/yang-data+json 290 The server might respond as follows: 292 HTTP/1.1 200 OK 293 Date: Tue, 27 Aug 2019 20:56:02 GMT 294 Server: example-server 295 Cache-Control: no-cache 296 Content-Type: application/yang-data+json 298 { 299 "ietf-yang-library:module": [ 300 { 301 "conformance-type": "implement", 302 "name": "ietf-dorms", 303 "namespace": "urn:ietf:params:xml:ns:yang:ietf-dorms", 304 "revision": "2019-08-25", 305 "schema": 306 "https://example.com/yang/ietf-dorms@2019-08-25.yang" 307 } 308 ] 309 } 311 Other modules required or desired by the client also can be checked 312 in a similar way, or the full set of available modules can be 313 retrieved by not providing a key for the "module" list. 315 2.2.4. Metadata Retrieval 317 Once the expected DORMS version is confirmed, the client can retrieve 318 the metadata specific to the desired (S,G). 320 Example: 322 The receiver might send: 324 GET /top/restconf/data/ietf-dorms:metadata/\ 325 sender=203.0.113.15/group=232.1.1.1 326 Host: dorms-restconf.example.com 327 Accept: application/yang-data+json 329 The server might respond as follows: 331 HTTP/1.1 200 OK 332 Date: Tue, 27 Aug 2019 20:56:02 GMT 333 Server: example-server 334 Cache-Control: no-cache 335 Content-Type: application/yang-data+json 337 { 338 "ietf-dorms:group": [ 339 { 340 "group-address":"232.1.1.1", 341 "udp-stream":[ 342 { 343 "port":"5001" 344 } 345 ] 346 } 347 ] 348 } 350 Note that when other modules are installed on the DORMS server that 351 extend the ietf-dorms module, other fields MAY appear inside the 352 response. This is the primary mechanism for providing extensible 353 metadata for an (S,G), so clients SHOULD ignore fields they do not 354 understand. 356 As mentioned in Section 3.2, most clients SHOULD use data resource 357 identifiers in the request URI as in the above example, in order to 358 retrieve metadata for only the targeted (S,G)s. 360 2.2.5. Cross Origin Resource Sharing (CORS) 362 It is RECOMMENDED that DORMS servers use the Access-Control-Allow- 363 Origin header field, as specified by [W3C.REC-cors-20140116], and 364 that they respond appropriately to Preflight requests. 366 Providing '*' for the allowed origins exposes the DORMS-based 367 metadata to all web pages. When access to the metadata is used as a 368 prerequisite to permitting the joining of the multicast flows, this 369 would permit scripts from arbitrary web pages to issue joins for the 370 multicast flows, which could allow e.g. malicious advertisements to 371 participate in overjoining attacks (see Appendix A of 372 [I-D.draft-jholland-cb-assisted-cc-01]) using multicast flows not 373 controlled by the ad's senders. Therefore the use of '*' for allowed 374 origins is NOT RECOMMENDED. (TBD: this probably deserves a security 375 considerations section.) 377 3. Scalability Considerations 379 3.1. Provisioning 381 In contrast to many common RESTCONF deployments that are intended to 382 provide configuration management for a service to a narrow set of 383 authenticated administrators, DORMS servers often provide read-only 384 metadata for public access, or for a very large set of end receivers, 385 since it provides metadata in support of multicast data streams and 386 multicast can scale to very large audiences. 388 Operators are advised to provision the DORMS service in a way that 389 will scale appropriately to the size of the expected audience. 390 Specific advice on such scaling is out of scope for this document, 391 but some of the mechanisms outlined in [RFC3040] or other online 392 resources might be useful, depending on the expected number of 393 receivers. 395 3.2. Data Scoping 397 In the absence of contextual information, clients SHOULD issue 398 narrowed requests for DORMS resources by following the format from 399 Section 3.5.3 of [RFC8040] to encode data resource identifiers in the 400 request URI. This avoids downloading excessive data, since the DORMS 401 server may provide metadata for many (S,G)s, possibly from many 402 different senders. 404 However, clients MAY use heuristics or out of band information about 405 the service to issue requests for (S,G) metadata narrowed only by the 406 source-address, or not narrowed at all. Depending on the request 407 patterns and the contents of the data store, this may result in fewer 408 round trips or less overhead, and can therefore be helpful behavior 409 for scaling purposes. Servers MAY restrict or throttle client access 410 based on the client certificate presented (if any), or based on 411 heuristics that take note of client request patterns. 413 A complete description of the heuristics for clients and servers to 414 meet their scalability goals is out of scope for this document. 416 4. YANG Model 418 The primary purpose of the YANG model defined here is to serve as a 419 scaffold for the more useful metadata that will extend it. Currently 420 known use cases include providing authentication information and bit- 421 rate information for use by receivers and middle boxes, but more use 422 cases are anticipated. 424 4.1. Yang Tree 426 module: ietf-dorms 427 +--rw metadata 428 +--rw sender* [source-address] 429 +--rw source-address inet:ip-address 430 +--rw group* [group-address] 431 +--rw group-address rt-types:ip-multicast-group-address 432 +--rw udp-stream* [port] 433 +--rw port inet:port-number 435 DORMS Tree Diagram 437 4.2. Yang Module 439 file ietf-dorms@2019-09-26.yang 440 module ietf-dorms { 441 yang-version 1.1; 443 namespace "urn:ietf:params:xml:ns:yang:ietf-dorms"; 444 prefix "dorms"; 446 import ietf-inet-types { 447 prefix "inet"; 448 reference "RFC 6991 Section 4"; 449 } 451 import ietf-routing-types { 452 prefix "rt-types"; 453 reference "RFC 8294"; 454 } 456 organization "IETF"; 458 contact 459 "Author: Jake Holland 460 461 "; 463 description 464 "Copyright (c) 2019 IETF Trust and the persons identified as 465 authors of the code. All rights reserved. 467 Redistribution and use in source and binary forms, with or 468 without modification, is permitted pursuant to, and subject to 469 the license terms contained in, the Simplified BSD License set 470 forth in Section 4.c of the IETF Trust's Legal Provisions 471 Relating to IETF Documents 472 (https://trustee.ietf.org/license-info). 474 This version of this YANG module is part of RFC XXXX 475 (https://www.rfc-editor.org/info/rfcXXXX); see the RFC itself 476 for full legal notices. 478 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL 479 NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED', 480 'MAY', and 'OPTIONAL' in this document are to be interpreted as 481 described in BCP 14 (RFC 2119) (RFC 8174) when, and only when, 482 they appear in all capitals, as shown here. 484 This module contains the definition for the DORMS data type. 485 It provides out of band metadata about SSM channels."; 487 revision 2019-08-25 { 488 description "Initial revision."; 489 reference 490 ""; 491 // "I-D.draft-jholland-mboned-dorms"; 492 } 494 container metadata { 495 description "Metadata scaffold for source-specific multicast 496 channels."; 497 list sender { 498 key source-address; 499 description "Sender for DORMS"; 501 leaf source-address { 502 type inet:ip-address; 503 mandatory true; 504 description 505 "The source IP address of a multicast sender."; 506 } 508 list group { 509 key group-address; 510 description "Metadata for a DORMS (S,G)."; 512 leaf group-address { 513 type rt-types:ip-multicast-group-address; 514 mandatory true; 515 description "The group IP address for an (S,G)."; 516 } 518 list udp-stream { 519 key "port"; 520 description 521 "Metadata for UDP traffic on a specific port."; 522 leaf port { 523 type inet:port-number; 524 mandatory true; 525 description 526 "The UDP port of a data stream in an (S,G)."; 527 } 528 } 529 } 530 } 531 } 532 } 533 535 5. Privacy Considerations 537 In the typical case, the mechanisms defined in this document provide 538 a standardized way to discover information that is already available 539 in other ways. 541 However, depending on the metadata provided by the server, observers 542 may be able to more easily associate traffic from an (S,G) with the 543 content contained within the (S,G). At the subscriber edge of a 544 multicast-capable network, where the network operator has the 545 capability to localize a IGMP [RFC3376] or MLD [RFC3810] channel 546 subscription to a specific user or location by MAC address or source 547 IP address, the structured publishing of metadata may make it easier 548 to automate collection of data about the content a receiver is 549 consuming. 551 RESTCONF communication will expose to the controller of the RESTCONF 552 server information about the consumers of content that is not 553 otherwise available from multicast subscription to a channel, such as 554 the remote IP address and timing information. 556 6. IANA Considerations 558 6.1. The YANG Module Names Registry 560 This document adds one YANG module to the "YANG Module Names" 561 registry maintained at . The following registrations are made, per the format in 563 Section 14 of [RFC6020]: 565 name: ietf-dorms 566 namespace: urn:ietf:params:xml:ns:yang:ietf-dorms 567 prefix: dorms 568 reference: I-D.draft-jholland-mboned-dorms 570 6.2. The Service Name and Transport Protocol Port Number Registry 572 This document adds one service name to the "Service Name and 573 Transport Protocol Port Number Registry" maintained at 574 . The 575 following registrations are made, per the format in Section 8.1.1 of 576 [RFC6335]: 578 Service Name: dorms 579 Transport Protocol(s): TCP 580 Assignee: IESG 581 Contact: IETF Chair 582 Description: This service name is used to construct the 583 SRV service label "_dorms" for discovering 584 DORMS servers. 585 Reference: I-D.draft-jholland-mboned-dorms 586 Port Number: N/A 587 Service Code: N/A 588 Known Unauthorized Uses: N/A 589 Assignment Notes: This protocol uses HTTPS as a substrate. 591 7. Security Considerations 593 7.1. Secure Communications 595 It is intended that security related metadata about the SSM channels 596 will be delivered over the RESTCONF connection, and that information 597 available from this connection can be used as a trust anchor. 599 The provisions of Section 2 of [RFC8040] provide secure communication 600 requirements that are already required of DORMS servers, since they 601 are RESTCONF servers. All RESTCONF requirements and security 602 considerations remain in force for DORMS servers. 604 7.2. Exposure of Metadata 606 Although some DORMS servers MAY restrict access based on client 607 identity, as described in Section 2.5 of [RFC8040], many DORMS 608 servers will use the ietf-dorms YANG model to publish information 609 without restriction, and even DORMS servers requiring client 610 authentication will inherently, because of the purpose of DORMS, be 611 providing the DORMS metadata to potentially many receivers. 613 Accordingly, future YANG modules that augment data paths under "ietf- 614 dorms:metadata" MUST NOT include any sensitive data unsuitable for 615 public dissemination in those data paths. Because of the possibility 616 that scalable read-only access might be necessary to fulfill the 617 scalability goals for a DORMS server, data under these paths MAY be 618 cached or replicated by numerous external entities, so owners of such 619 data SHOULD NOT assume it can be kept secret when provided by DORMS 620 servers anywhere under the "ietf-dorms:metadata" path, even if they 621 are authenticating clients. 623 7.3. DNS Bootstrapping 625 The DNS bootstrap phase relies on DNS for the reverse IP tree. When 626 using DNS to discover a DORMS server's domain name, there must be a 627 trust relationship between the end consumer of this resource record 628 and the DNS server. This relationship may be end-to-end DNSSEC 629 validation, a TSIG [RFC2845] or SIG(0) [RFC2931] channel to another 630 secure source, a secure local channel on the host, DNS over TLS 631 [RFC7858] or HTTPS [RFC8484], or some other secure mechanism. 633 If the SRV Resource Record cannot be authenticated, it may be 634 possible for an attacker who can spoof the resource record to perform 635 a denial of service for the receiver by providing wrong or missing 636 authentication metadata. An attacker who can also inject traffic for 637 (S,G)s, would also be able to provide false content in the data 638 stream, so an attacker who can perform both could provide 639 authenticated false content by authenticating with a trust anchor 640 from an attacker-controlled DORMS server. 642 Clients MAY use other secure methods to explicitly associate an (S,G) 643 with a set of DORMS server hostnames, such as a configured mapping or 644 an alternative trusted lookup service. 646 8. Acknowledgements 648 Thanks to Christian Worm Mortensen for some very helpful comments and 649 review. 651 9. References 653 9.1. Normative References 655 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 656 Requirement Levels", BCP 14, RFC 2119, 657 DOI 10.17487/RFC2119, March 1997, 658 . 660 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 661 specifying the location of services (DNS SRV)", RFC 2782, 662 DOI 10.17487/RFC2782, February 2000, 663 . 665 [RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, 666 "DNS Extensions to Support IP Version 6", STD 88, 667 RFC 3596, DOI 10.17487/RFC3596, October 2003, 668 . 670 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", 671 RFC 6991, DOI 10.17487/RFC6991, July 2013, 672 . 674 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 675 RFC 7950, DOI 10.17487/RFC7950, August 2016, 676 . 678 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 679 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 680 . 682 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 683 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 684 May 2017, . 686 [RFC8294] Liu, X., Qu, Y., Lindem, A., Hopps, C., and L. Berger, 687 "Common YANG Data Types for the Routing Area", RFC 8294, 688 DOI 10.17487/RFC8294, December 2017, 689 . 691 [W3C.REC-cors-20140116] 692 Kesteren, A., "Cross-Origin Resource Sharing", World Wide 693 Web Consortium Recommendation REC-cors-20140116, January 694 2014, . 696 9.2. Informative References 698 [I-D.draft-jholland-cb-assisted-cc-01] 699 Holland, J., "Circuit Breaker Assisted Congestion Control 700 (CBACC): Protocol Specification", draft-jholland-cb- 701 assisted-cc-01 (work in progress), April 2017. 703 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 704 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 705 . 707 [RFC1035] Mockapetris, P., "Domain names - implementation and 708 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 709 November 1987, . 711 [RFC2845] Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B. 712 Wellington, "Secret Key Transaction Authentication for DNS 713 (TSIG)", RFC 2845, DOI 10.17487/RFC2845, May 2000, 714 . 716 [RFC2931] Eastlake 3rd, D., "DNS Request and Transaction Signatures 717 ( SIG(0)s )", RFC 2931, DOI 10.17487/RFC2931, September 718 2000, . 720 [RFC3040] Cooper, I., Melve, I., and G. Tomlinson, "Internet Web 721 Replication and Caching Taxonomy", RFC 3040, 722 DOI 10.17487/RFC3040, January 2001, 723 . 725 [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. 726 Thyagarajan, "Internet Group Management Protocol, Version 727 3", RFC 3376, DOI 10.17487/RFC3376, October 2002, 728 . 730 [RFC3810] Vida, R., Ed. and L. Costa, Ed., "Multicast Listener 731 Discovery Version 2 (MLDv2) for IPv6", RFC 3810, 732 DOI 10.17487/RFC3810, June 2004, 733 . 735 [RFC4604] Holbrook, H., Cain, B., and B. Haberman, "Using Internet 736 Group Management Protocol Version 3 (IGMPv3) and Multicast 737 Listener Discovery Protocol Version 2 (MLDv2) for Source- 738 Specific Multicast", RFC 4604, DOI 10.17487/RFC4604, 739 August 2006, . 741 [RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for 742 IP", RFC 4607, DOI 10.17487/RFC4607, August 2006, 743 . 745 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 746 the Network Configuration Protocol (NETCONF)", RFC 6020, 747 DOI 10.17487/RFC6020, October 2010, 748 . 750 [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. 751 Cheshire, "Internet Assigned Numbers Authority (IANA) 752 Procedures for the Management of the Service Name and 753 Transport Protocol Port Number Registry", BCP 165, 754 RFC 6335, DOI 10.17487/RFC6335, August 2011, 755 . 757 [RFC6415] Hammer-Lahav, E., Ed. and B. Cook, "Web Host Metadata", 758 RFC 6415, DOI 10.17487/RFC6415, October 2011, 759 . 761 [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., 762 and P. Hoffman, "Specification for DNS over Transport 763 Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 764 2016, . 766 [RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS 767 (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, 768 . 770 [whatwg-fetch] 771 Kesteren, A., "WHATWG Fetch Living Standard", August 2019, 772 . 774 Author's Address 776 Jake Holland 777 Akamai Technologies, Inc. 778 150 Broadway 779 Cambridge, MA 02144 780 United States of America 782 Email: jakeholland.net@gmail.com