idnits 2.17.1 draft-ietf-mboned-dorms-03.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 non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 624 has weird spacing: '...address ine...' == Line 629 has weird spacing: '...rw port ine...' -- The document date (23 October 2021) is 887 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-17) exists of draft-ietf-core-comi-11 == Outdated reference: A later version (-03) exists of draft-ietf-mboned-ambi-01 == Outdated reference: A later version (-04) exists of draft-ietf-mboned-cbacc-02 Summary: 0 errors (**), 0 flaws (~~), 7 warnings (==), 1 comment (--). 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 23 October 2021 5 Expires: 26 April 2022 7 Discovery Of Restconf Metadata for Source-specific multicast 8 draft-ietf-mboned-dorms-03 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 26 April 2022. 38 Copyright Notice 40 Copyright (c) 2021 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 (https://trustee.ietf.org/ 45 license-info) in effect on the date of publication of this document. 46 Please review these documents carefully, as they describe your rights 47 and restrictions with respect to this document. Code Components 48 extracted from this document must include Simplified BSD License text 49 as described in Section 4.e of the Trust Legal Provisions and are 50 provided without warranty as described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 55 1.1. Background . . . . . . . . . . . . . . . . . . . . . . . 3 56 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 57 1.3. Motivation and Use Cases . . . . . . . . . . . . . . . . 5 58 1.3.1. Provisioning and Oversubscription Protection . . . . 5 59 1.3.2. Authentication . . . . . . . . . . . . . . . . . . . 5 60 1.3.3. Content Description . . . . . . . . . . . . . . . . . 5 61 1.4. Channel Discovery . . . . . . . . . . . . . . . . . . . . 5 62 1.5. Notes for Contributors and Reviewers . . . . . . . . . . 6 63 1.5.1. Venues for Contribution and Discussion . . . . . . . 6 64 1.5.2. Non-obvious doc choices . . . . . . . . . . . . . . . 7 65 2. Discovery and Metdata Retrieval . . . . . . . . . . . . . . . 7 66 2.1. DNS Bootstrap . . . . . . . . . . . . . . . . . . . . . . 7 67 2.2. Ignore List . . . . . . . . . . . . . . . . . . . . . . . 9 68 2.3. RESTCONF Bootstrap . . . . . . . . . . . . . . . . . . . 9 69 2.3.1. Root Resource Discovery . . . . . . . . . . . . . . . 9 70 2.3.2. Yang Library Version . . . . . . . . . . . . . . . . 10 71 2.3.3. Yang Library Contents . . . . . . . . . . . . . . . . 11 72 2.3.4. Metadata Retrieval . . . . . . . . . . . . . . . . . 12 73 2.3.5. Cross Origin Resource Sharing (CORS) . . . . . . . . 13 74 3. Scalability Considerations . . . . . . . . . . . . . . . . . 13 75 3.1. Provisioning . . . . . . . . . . . . . . . . . . . . . . 13 76 3.2. Data Scoping . . . . . . . . . . . . . . . . . . . . . . 13 77 4. YANG Model . . . . . . . . . . . . . . . . . . . . . . . . . 14 78 4.1. Yang Tree . . . . . . . . . . . . . . . . . . . . . . . . 14 79 4.2. Yang Module . . . . . . . . . . . . . . . . . . . . . . . 14 80 5. Privacy Considerations . . . . . . . . . . . . . . . . . . . 16 81 5.1. Linking Content to Traffic Streams . . . . . . . . . . . 17 82 5.2. Linking Multicast Subscribers to Unicast Connections . . 17 83 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 84 6.1. The YANG Module Names Registry . . . . . . . . . . . . . 17 85 6.2. The XML Registry . . . . . . . . . . . . . . . . . . . . 18 86 6.3. The Service Name and Transport Protocol Port Number 87 Registry . . . . . . . . . . . . . . . . . . . . . . . . 18 88 7. Security Considerations . . . . . . . . . . . . . . . . . . . 18 89 7.1. YANG Model Considerations . . . . . . . . . . . . . . . . 18 90 7.2. Exposure of Metadata . . . . . . . . . . . . . . . . . . 20 91 7.3. Secure Communications . . . . . . . . . . . . . . . . . . 20 92 7.4. Record-Spoofing . . . . . . . . . . . . . . . . . . . . . 21 93 7.5. CORS considerations . . . . . . . . . . . . . . . . . . . 21 94 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22 95 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 96 9.1. Normative References . . . . . . . . . . . . . . . . . . 22 97 9.2. Informative References . . . . . . . . . . . . . . . . . 24 98 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 26 100 1. Introduction 102 This document defines DORMS (Discovery Of Restconf Metadata for 103 Source-specific multicast). 105 A DORMS service is a RESTCONF [RFC8040] service that provides read 106 access to data in the "ietf-dorms" YANG [RFC7950] model defined in 107 Section 4. This model, along with optional extensions defined in 108 other documents, provide an extensible set of information about 109 multicast data streams. A review of some example use cases that can 110 be enabled by this kind of metadata is given in Section 1.3. 112 This document does not prohibit the use of the "ietf-dorms" model 113 with other protocols such as NETCONF [RFC6241], CORECONF 114 [I-D.draft-ietf-core-comi], or gNMI 115 [I-D.draft-openconfig-rtgwg-gnmi-spec], but the semantics of using 116 the model over those protocols is out of scope for this document. 117 This document only defines the discovery and use of the "ietf-dorms" 118 YANG model in RESTCONF. 120 This document defines the "dorms" service name for use with the SRV 121 DNS Resource Record (RR) type [RFC2782]. A sender using a DORMS 122 service to publish metadata SHOULD configure at least one SRV RR for 123 the "_dorms._tcp" subdomain in the reverse IP DNS zone for the source 124 IP used by some active multicast traffic. The domain name in one of 125 these SRV records provides a hostname corresponding to a DORMS server 126 that can provide metadata for the sender's source-specific multicast 127 traffic. Publishing such a RR enables DORMS clients to discover and 128 query a DORMS server as described in Section 2. 130 1.1. Background 132 The reader is assumed to be familiar with the basic DNS concepts 133 described in [RFC1034], [RFC1035], and the subsequent documents that 134 update them, as well as the use of the SRV Resource Record type as 135 described in [RFC2782]. 137 The reader is also assumed to be familiar with the concepts and 138 terminology regarding source-specific multicast as described in 139 [RFC4607] and the use of IGMPv3 [RFC3376] and MLDv2 [RFC3810] for 140 group management of source-specific multicast channels, as described 141 in [RFC4604]. 143 The reader is also assumed to be familiar with the concepts and 144 terminology for RESTCONF [RFC8040] and YANG [RFC7950]. 146 1.2. Terminology 148 +========+=================================================+ 149 | Term | Definition | 150 +========+=================================================+ 151 | (S,G) | A source-specific multicast channel, as | 152 | | described in [RFC4607]. A pair of IP addresses | 153 | | with a source host IP and destination group IP. | 154 +--------+-------------------------------------------------+ 155 | DORMS | An application or system that can communicate | 156 | client | with DORMS servers to fetch metadata about | 157 | | (S,G)s. | 158 +--------+-------------------------------------------------+ 159 | DORMS | A RESTCONF server that implements the ietf- | 160 | server | dorms YANG model defined in this document. | 161 +--------+-------------------------------------------------+ 162 | RR | A DNS Resource Record, as described in | 163 | | [RFC1034] | 164 +--------+-------------------------------------------------+ 165 | RRType | A DNS Resource Record Type, as described in | 166 | | [RFC1034] | 167 +--------+-------------------------------------------------+ 168 | SSM | Source-specific multicast, as described in | 169 | | [RFC4607] | 170 +--------+-------------------------------------------------+ 172 Table 1 174 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 175 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 176 "OPTIONAL" in this document are to be interpreted as described in 177 [RFC2119] and [RFC8174] when, and only when, they appear in all 178 capitals, as shown here. 180 1.3. Motivation and Use Cases 182 DORMS provides a framework that can be extended to publish 183 supplemental information about multicast traffic in a globally 184 discoverable manner. This supplemental information is sometimes 185 needed by entities engaged in delivery or processing of the traffic 186 to handle the traffic according to their requirements. 188 Detailing the specifics of all known possible extensions is out of 189 scope for this document except to note that a range of possible use 190 cases are expected and they may be supported by a variety of 191 different future extensions. But a few example use cases are 192 provided below for illustration. 194 1.3.1. Provisioning and Oversubscription Protection 196 One use case for DORMS is when a network that is capable of 197 forwarding multicast traffic may need to take provisioning actions or 198 make admission control decisions based on the expected bitrate of the 199 traffic in order to prevent oversubscription of constrained devices 200 in the network. [I-D.draft-ietf-mboned-cbacc] defines some DORMS 201 extensions to support this use case. 203 1.3.2. Authentication 205 Another use case for DORMS is providing information for use in 206 authenticating the multicast traffic before accepting it for 207 forwarding by a network device, or for processing by a receiving 208 application. [I-D.draft-ietf-mboned-ambi] defines some DORMS 209 extensions to support this use case. 211 1.3.3. Content Description 213 Another use case for DORMS is describing the contents carried by a 214 multicast traffic channel. The content description could include 215 information about the protocols or applications that can be used to 216 consume the traffic, or information about the media carried (e.g. 217 information based on the Dublin Core Metadata Element Set [RFC5013]), 218 or could make assertions about the legal status of the traffic within 219 specific contexts. 221 1.4. Channel Discovery 223 DORMS provides a method for clients to fetch metadata about (S,G)s 224 that are already known to the clients. In general, a DORMS client 225 might learn of an (S,G) by any means, so describing all possible 226 methods a DORMS client might use to discover a set of (S,G)s for 227 which it wants metadata is out of scope for this document. 229 But for example, a multicast receiver application that is a DORMS 230 client might learn about an (S,G) by getting signals from inside the 231 application logic, such as a selection made by a user, or a scheduled 232 API call that reacts to updates in a library provided by a service 233 operator. 235 As another example, an on-path router that's a DORMS client might 236 instead learn about an (S,G) by receiving a PIM message or an IGMP or 237 MLD membership report indicating a downstream client has tried to 238 subscribe to an (S,G). Such a router might use information learned 239 from the DORMS metadata to make an access control decision about 240 whether to propagate the join futher upstream in the network. 242 Other approaches for learning relevant (S,G)s could be driven by 243 monitoring a route reflector to discover channels that are being 244 actively forwarded, for a purpose such as monitoring network health. 246 1.5. Notes for Contributors and Reviewers 248 Note to RFC Editor: Please remove this section and its subsections 249 before publication. 251 This section is to provide references to make it easier to review the 252 development and discussion on the draft so far. 254 1.5.1. Venues for Contribution and Discussion 256 This document is in the Github repository at: 258 https://github.com/GrumpyOldTroll/ietf-dorms-cluster 260 Readers are welcome to open issues and send pull requests for this 261 document. 263 Please note that contributions may be merged and substantially 264 edited, and as a reminder, please carefully consider the Note Well 265 before contributing: https://datatracker.ietf.org/submit/note-well/ 267 Substantial discussion of this document should take place on the 268 MBONED working group mailing list (mboned@ietf.org). 270 * Join: https://www.ietf.org/mailman/listinfo/mboned 272 * Search: https://mailarchive.ietf.org/arch/browse/mboned/ 274 1.5.2. Non-obvious doc choices 276 Log of odd things that need to be the way they are because of some 277 reason that the author or reviewers may want to know later. 279 * building the draft without this line produces a warning about no 280 reference to [RFC6991] or [RFC8294], but these are imported in the 281 yang model. RFC 8407 requires the normative reference to 8294 282 (there's an exception for 6991 but I'm not sure why and it doesn't 283 seem forbidden). 285 * Although it's non-normative, I chose the boundaries in the 286 recommendation for default setting of DNS expiry time in 287 Section 2.2 based on the best practices advice at 288 https://www.varonis.com/blog/dns-ttl/ for "Short" and "Long" 289 times. 291 * Section 7.1 is intended to be the template from 292 https://trac.ietf.org/trac/ops/wiki/yang-security-guidelines 293 (https://trac.ietf.org/trac/ops/wiki/yang-security-guidelines), as 294 required by https://datatracker.ietf.org/doc/html/rfc8407#section- 295 3.7 (https://datatracker.ietf.org/doc/html/rfc8407#section-3.7). 296 Individual nodes are not listed because blanket statements in that 297 section covere them. 299 * The 'must' constraint in the group list seems awkward, but seems 300 to work. Its intent is to require source & group to be either 301 both IPv4 or both IPv6, without mixing & matching. It requires 302 that either both the group address and its source parent's address 303 must contain a colon or both must NOT contain a colon, where 304 presence of a colon is used to distinguish IPv4 from IPv6. Maybe 305 there's a better way? 307 2. Discovery and Metdata Retrieval 309 A client that needs metadata about an (S,G) MAY attempt to discover 310 metadata for the (S,G) using the mechanisms defined here, and MAY use 311 the metadata received to manage the forwarding or processing of the 312 packets in the channel. 314 2.1. DNS Bootstrap 316 The DNS Bootstrap step is how a client discovers an appropriate 317 RESTCONF server, given the source address of an (S,G). Use of the 318 DNS Bootstrap is OPTIONAL for clients with an alternate method of 319 obtaining a hostname of a trusted DORMS server that has information 320 about a target (S,G). 322 This mechanism only works for source-specific multicast (SSM) 323 channels. The source address of the (S,G) is reversed and used as an 324 index into one of the reverse mapping trees (in-addr.arpa for IPv4, 325 as described in Section 3.5 of [RFC1035], or ip6.arpa for IPv6, as 326 described in Section 2.5 of [RFC3596]). 328 When a DORMS client needs metadata for an (S,G), for example when 329 handling a new join for that (S,G) and looking up the authentication 330 methods that are available, the DORMS client can issue a DNS query 331 for a SRV RR using the "dorms" service name with the domain from the 332 reverse mapping tree, combining them as described in [RFC2782]. 334 For example, a client looking for metadata about the channel with a 335 source IP of 2001:db8::a and the group address of ff3e::8000:d, the 336 client would start the DNS bootstrap step by performing a query for 337 the SRV RRType for the following domain (after removing the line 338 break inserted for editorial reasons): 340 _dorms._tcp.a.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0. 341 0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa. 343 Or for an IPv4 (S,G) with a source address of 203.0.113.4, the DORMS 344 client would request the SRV record from the in-addr.arpa tree 345 instead: 347 _dorms._tcp.4.113.0.203.in-addr.arpa. 349 In either case, the DNS response for this domain might return a 350 record such as this: 352 SRV 0 1 443 dorms-restconf.example.com. 354 This response informs the client that a DORMS server should be 355 reachable at dorms-restconf.example.com on port 443, and should 356 contain metadata about multicast traffic from the given source IP. 357 Multiple SRV records are handled as described by [RFC2782]. 359 A sender providing DORMS discovery SHOULD publish at least one SRV 360 record in the reverse DNS zone for each source address of the 361 multicast channels it is sending in order to advertise the hostname 362 of the DORMS server to DORMS clients. The DORMS servers advertised 363 SHOULD be configured with metadata for all the groups sent from the 364 same source IP address that have metadata published with DORMS. 366 When performing the SRV lookup, any CNAMEs or DNAMEs found MUST be 367 followed. This is necessary to support zone delegation. Some 368 examples outlining this need are described in [RFC2317]. 370 2.2. Ignore List 372 If a DORMS client reaches a DORMS server but determines through 373 examination of responses from that DORMS server that it may not 374 understand or be able to use the responses of the server (for example 375 due to an issue like a version mismatch or modules that are missing 376 but are required for the DORMS client's purposes), the client MAY add 377 this server to an ignore list and reject servers in its ignore list 378 during future discovery attempts. 380 A client using the DNS Bootstrap discovery method in Section 2.1 381 would treat servers in its ignore list as unreachable for the 382 purposes of processing the SRV RR as described in [RFC2782]. (For 383 example, a client might end up selecting a server with a less- 384 preferred priority than servers in its ignore list, even if an HTTPS 385 connection could have been formed successfully with some of those 386 servers.) 388 If an ignore list is maintained, entries SHOULD time out and allow 389 for re-checking after either the cache expiration time from the DNS 390 response that caused the server to be added to the ignore list, or 391 for a configurable hold-down time that has a default value no shorter 392 than 1 hour and no longer than 24 hours. 394 2.3. RESTCONF Bootstrap 396 Once a DORMS server has been chosen (whether via an SRV RR from a DNS 397 response or via some other method), RESTCONF provides all the 398 information necessary to determine the versions and url paths for 399 metadata from the server. A walkthrough is provided here for a 400 sequence of example requests and responses from a receiver connecting 401 to a new DORMS server. 403 2.3.1. Root Resource Discovery 405 As described in Section 3.1 of [RFC8040] and [RFC6415], the RESTCONF 406 server provides the link to the RESTCONF api entry point via the 407 "/.well-known/host-meta" or "/.well-known/host-meta.json" resource. 409 Example: 411 The receiver might send: 413 GET /.well-known/host-meta.json HTTP/1.1 414 Host: dorms-restconf.example.com 415 Accept: application/json 417 The server might respond as follows: 419 HTTP/1.1 200 OK 420 Date: Tue, 09 Jul 2021 20:56:00 GMT 421 Server: example-server 422 Cache-Control: no-cache 423 Content-Type: application/json 425 { 426 "links":[ 427 { 428 "rel":"restconf", 429 "href":"/top/restconf" 430 } 431 ] 432 } 434 2.3.2. Yang Library Version 436 As described in Section 3.3.3 of [RFC8040], the yang-library-version 437 leaf is required by RESTCONF, and can be used to determine the schema 438 of the ietf-yang-library module: 440 Example: 442 The receiver might send: 444 GET /top/restconf/yang-library-version HTTP/1.1 445 Host: dorms-restconf.example.com 446 Accept: application/yang-data+json 448 The server might respond as follows: 450 HTTP/1.1 200 OK 451 Date: Tue, 09 Jul 2021 20:56:01 GMT 452 Server: example-server 453 Cache-Control: no-cache 454 Content-Type: application/yang-data+json 456 { 457 "ietf-restconf:yang-library-version": "2016-06-21" 458 } 460 If a DORMS client determines through examination of the yang-library- 461 version that it may not understand the responses of the server due to 462 a version mismatch, the server qualifies as a candidate for adding to 463 an ignore list as described in Section 2.2. 465 2.3.3. Yang Library Contents 467 After checking that the version of the yang-library module will be 468 understood by the receiver, the client can check that the desired 469 metadata modules are available on the DORMS server by fetching the 470 module-state resource from the ietf-yang-library module. 472 Example: 474 The receiver might send: 476 GET /top/restconf/data/ietf-yang-library:modules-state/\ 477 module=ietf-dorms,2021-07-08 478 Host: dorms-restconf.example.com 479 Accept: application/yang-data+json 481 The server might respond as follows: 483 HTTP/1.1 200 OK 484 Date: Tue, 09 Jul 2021 20:56:02 GMT 485 Server: example-server 486 Cache-Control: no-cache 487 Content-Type: application/yang-data+json 489 { 490 "ietf-yang-library:module": [ 491 { 492 "conformance-type": "implement", 493 "name": "ietf-dorms", 494 "namespace": "urn:ietf:params:xml:ns:yang:ietf-dorms", 495 "revision": "2021-07-08", 496 "schema": 497 "https://example.com/yang/ietf-dorms@2021-07-08.yang" 498 } 499 ] 500 } 502 Other modules required or desired by the client also can be checked 503 in a similar way, or the full set of available modules can be 504 retrieved by not providing a key for the "module" list. If a DORMS 505 client that requires the presence of certain modules to perform its 506 function discovers the required modules are not present on a server, 507 that server qualifies for inclusion in an ignore list according to 508 Section 2.2. 510 2.3.4. Metadata Retrieval 512 Once the expected DORMS version is confirmed, the client can retrieve 513 the metadata specific to the desired (S,G). 515 Example: 517 The receiver might send: 519 GET /top/restconf/data/ietf-dorms:dorms/metadata/\ 520 sender=2001:db8::a/group=ff3e::8000:1 521 Host: dorms-restconf.example.com 522 Accept: application/yang-data+json 524 The server might respond as follows: 526 HTTP/1.1 200 OK 527 Date: Tue, 09 Jul 2021 20:56:02 GMT 528 Server: example-server 529 Cache-Control: no-cache 530 Content-Type: application/yang-data+json 532 { 533 "ietf-dorms:group": [ 534 { 535 "group-address":"ff3e::8000:1", 536 "udp-stream":[ 537 { 538 "port":"5001" 539 } 540 ] 541 } 542 ] 543 } 545 Note that when other modules are installed on the DORMS server that 546 extend the ietf-dorms module, other fields MAY appear inside the 547 response. This is the primary mechanism for providing extensible 548 metadata for an (S,G), so clients SHOULD ignore fields they do not 549 understand. 551 As mentioned in Section 3.2, most clients SHOULD use data resource 552 identifiers in the request URI as in the above example, in order to 553 retrieve metadata for only the targeted (S,G)s. 555 2.3.5. Cross Origin Resource Sharing (CORS) 557 It is RECOMMENDED that DORMS servers use the Access-Control-Allow- 558 Origin header field, as specified by [whatwg-fetch], and that they 559 respond appropriately to Preflight requests. 561 The use of '*' for allowed origins is NOT RECOMMENDED for publicly 562 reachable DORMS servers. A review of some of the potential 563 consequences of unrestricted CORS access is given in Section 7.5. 565 3. Scalability Considerations 567 3.1. Provisioning 569 In contrast to many common RESTCONF deployments that are intended to 570 provide configuration management for a service to a narrow set of 571 authenticated administrators, DORMS servers often provide read-only 572 metadata for public access or for a very large set of end receivers, 573 since it provides metadata in support of multicast data streams and 574 multicast can scale to very large audiences. 576 Operators are advised to provision the DORMS service in a way that 577 will scale appropriately to the size of the expected audience. 578 Specific advice on such scaling is out of scope for this document, 579 but some of the mechanisms outlined in [RFC3040] or other online 580 resources might be useful, depending on the expected number of 581 receivers. 583 3.2. Data Scoping 585 Except as outlined below, clients SHOULD issue narrowed requests for 586 DORMS resources by following the format from Section 3.5.3 of 587 [RFC8040] to encode data resource identifiers in the request URI. 588 This avoids downloading excessive data, since the DORMS server may 589 provide metadata for many (S,G)s, possibly from many different 590 senders. 592 However, clients with out of band knowledge about the scope of the 593 expected contents MAY issue requests for (S,G) metadata narrowed only 594 by the source-address, or not narrowed at all. Depending on the 595 request patterns and the contents of the data store, this may result 596 in fewer round trips or less overhead, and can therefore be helpful 597 behavior for scaling purposes in some scenarios. In general, 598 engaging in this behavior requires some administrative configuration 599 or some optimization heuristics that can recover from unexpected 600 results. 602 Servers MAY restrict or throttle client access based on the client 603 certificate presented (if any), or based on heuristics that take note 604 of client request patterns. 606 A complete description of the heuristics for clients and servers to 607 meet their scalability goals is out of scope for this document. 609 4. YANG Model 611 The primary purpose of the YANG model defined here is to serve as a 612 scaffold for the more useful metadata that will extend it. See 613 Section 1.3 for some example use cases that can be enabled by the use 614 of DORMS extensions. 616 4.1. Yang Tree 618 The tree diagram below follows the notation defined in [RFC8340]. 620 module: ietf-dorms 621 +--rw dorms 622 +--rw metadata 623 +--rw sender* [source-address] 624 +--rw source-address inet:ip-address 625 +--rw group* [group-address] 626 +--rw group-address 627 | rt-types:ip-multicast-group-address 628 +--rw udp-stream* [port] 629 +--rw port inet:port-number 631 Figure 1: DORMS Tree Diagram 633 4.2. Yang Module 635 636 file ietf-dorms@2021-10-23.yang 637 module ietf-dorms { 638 yang-version 1.1; 640 namespace "urn:ietf:params:xml:ns:yang:ietf-dorms"; 641 prefix "dorms"; 643 import ietf-inet-types { 644 prefix "inet"; 645 reference "RFC 6991 Section 4"; 646 } 648 import ietf-routing-types { 649 prefix "rt-types"; 650 reference "RFC 8294"; 651 } 653 organization "IETF MBONED (Multicast Backbone 654 Deployment) Working Group"; 656 contact 657 "Author: Jake Holland 658 659 "; 661 description 662 "Copyright (c) 2019 IETF Trust and the persons identified as 663 authors of the code. All rights reserved. 665 Redistribution and use in source and binary forms, with or 666 without modification, is permitted pursuant to, and subject to 667 the license terms contained in, the Simplified BSD License set 668 forth in Section 4.c of the IETF Trust's Legal Provisions 669 Relating to IETF Documents 670 (https://trustee.ietf.org/license-info). 672 This version of this YANG module is part of RFC XXXX 673 (https://www.rfc-editor.org/info/rfcXXXX); see the RFC itself 674 for full legal notices. 676 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL 677 NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED', 678 'MAY', and 'OPTIONAL' in this document are to be interpreted as 679 described in BCP 14 (RFC 2119) (RFC 8174) when, and only when, 680 they appear in all capitals, as shown here. 682 This module contains the definition for the DORMS data type. 683 It provides out of band metadata about SSM channels."; 685 revision 2021-07-08 { 686 description "Draft version, post-early-review."; 687 reference 688 "draft-ietf-mboned-dorms"; 689 } 691 container dorms { 692 description "Top-level DORMS container."; 693 container metadata { 694 description "Metadata scaffold for source-specific multicast 695 channels."; 696 list sender { 697 key source-address; 698 description "Sender for DORMS"; 700 leaf source-address { 701 type inet:ip-address; 702 mandatory true; 703 description 704 "The source IP address of a multicast sender."; 705 } 707 list group { 708 key group-address; 709 description "Metadata for a DORMS (S,G)."; 711 leaf group-address { 712 type rt-types:ip-multicast-group-address; 713 mandatory true; 714 description "The group IP address for an (S,G)."; 715 } 716 must '(re-match(./group-address, "[^:]*") and ' + 717 're-match(../source-address, "[^:]*")) or ' + 718 '(re-match(./group-address, ".*:.*") and ' + 719 're-match(../source-address, ".*:.*"))' { 720 error-message 'A group-address type must match '+ 721 'its parent source-address type'; 722 } 724 list udp-stream { 725 key "port"; 726 description 727 "Metadata for UDP traffic on a specific port."; 728 leaf port { 729 type inet:port-number; 730 mandatory true; 731 description 732 "The UDP port of a data stream."; 733 } 734 } 735 } 736 } 737 } 738 } 739 } 740 742 5. Privacy Considerations 743 5.1. Linking Content to Traffic Streams 745 In the typical case, the mechanisms defined in this document provide 746 a standardized way to discover information that is already available 747 in other ways. 749 However, depending on the metadata provided by the server, observers 750 may be able to more easily associate traffic from an (S,G) with the 751 content contained within the (S,G). At the subscriber edge of a 752 multicast-capable network, where the network operator has the 753 capability to localize an IGMP [RFC3376] or MLD [RFC3810] channel 754 subscription to a specific user or location, for example by MAC 755 address or source IP address, the structured publishing of metadata 756 may make it easier to automate collection of data about the content a 757 receiver is consuming. 759 5.2. Linking Multicast Subscribers to Unicast Connections 761 Subscription to a multicast channel generally only exposes the IGMP 762 or MLD membership report to others on the same LAN, and as the 763 membership propagates through a multicast-capable network, it 764 ordinarily gets aggregated with other end users. 766 However, a RESTCONF connection is a unicast connection, and exposes a 767 different set of information to the operator of the RESTCONF server, 768 including IP address and timing about the requests made. Where DORMS 769 access becomes required to succeed a multicast join (for example, as 770 expected in a browser deployment), this can expose new information 771 about end users relative to services based solely on multicast 772 streams. The information disclosure occurs by giving the DORMS 773 service operator information about the client's IP and the channels 774 the client queried. 776 In some deployments it may be possible to use a proxy that aggregates 777 many end users when the aggregate privacy characteristics are needed 778 by end users. 780 6. IANA Considerations 782 6.1. The YANG Module Names Registry 784 This document adds one YANG module to the "YANG Module Names" 785 registry maintained at . The following registrations are made, per the format in 787 Section 14 of [RFC6020]: 789 name: ietf-dorms 790 namespace: urn:ietf:params:xml:ns:yang:ietf-dorms 791 prefix: dorms 792 reference: I-D.draft-ietf-mboned-dorms 794 6.2. The XML Registry 796 This document adds the following registration to the "ns" subregistry 797 of the "IETF XML Registry" defined in [RFC3688], referencing this 798 document. 800 URI: urn:ietf:params:xml:ns:yang:ietf-dorms 801 Registrant Contact: The IESG. 802 XML: N/A, the requested URI is an XML namespace. 804 6.3. The Service Name and Transport Protocol Port Number Registry 806 This document adds one service name to the "Service Name and 807 Transport Protocol Port Number Registry" maintained at 808 . The 809 following registrations are made, per the format in Section 8.1.1 of 810 [RFC6335]: 812 Service Name: dorms 813 Transport Protocol(s): TCP, UDP 814 Assignee: IESG 815 Contact: IETF Chair 816 Description: The DORMS service (RESTCONF that 817 includes ietf-dorms YANG model) 818 Reference: I-D.draft-ietf-mboned-dorms 819 Port Number: N/A 820 Service Code: N/A 821 Known Unauthorized Uses: N/A 822 Assignment Notes: N/A 824 7. Security Considerations 826 7.1. YANG Model Considerations 828 The YANG module specified in this document defines a schema for data 829 that is designed to be accessed via RESTCONF [RFC8040]. The lowest 830 RESTCONF layer is HTTPS, and the mandatory-to-implement secure 831 transport is TLS [RFC8446]. 833 There are a number of data nodes defined in this YANG module that are 834 writable/creatable/deletable (i.e., config true, which is the 835 default). These data nodes may be considered sensitive or vulnerable 836 in some network environments. Write operations (e.g., edit-config) 837 to these data nodes without proper protection can have a negative 838 effect on network operations. These are the subtrees and data nodes 839 and their sensitivity/vulnerability: 841 Subtrees: 843 * /dorms/metadata 845 * /dorms/metadata/sender 847 * /dorms/metadata/sender/group 849 * /dorms/metadata/sender/group/udp-stream 851 Data nodes: 853 * /dorms/metadata/sender/source-address 855 * /dorms/metadata/sender/group/group-address 857 * /dorms/metadata/sender/group/udp-stream/port 859 These data nodes refer to the characteristics of a stream of data 860 packets being sent on a multicast channel. If an unauthorized or 861 incorrect edit is made, receivers would no longer be able to 862 associate the data stream to the correct metadata, resulting in a 863 denial of service for end users that rely on the metadata to properly 864 process the data packets. Therefore DORMS servers MUST constrain 865 write access to ensure that unauthorized users cannot edit the data 866 published by the server. 868 The Network Configuration Access Control Model (NACM) [RFC8341] 869 provides the means to restrict access for particular NETCONF or 870 RESTCONF users to a preconfigured subset of all available NETCONF or 871 RESTCONF protocol operations and content. DORMS servers MAY use NACM 872 to constrain write accesses. 874 However, note that scalability considerations described in 875 Section 3.1 might make the naive use of NACM intractable in many 876 deployments, for a broadcast use case. So alternative methods to 877 constrain write access to the metadata MAY be used instead of or in 878 addition to NACM. For example, some deployments that use a CDN or 879 caching layer of discoverable DORMS servers might uniformly provide 880 read-only access through the caching layer, and might require the 881 trusted writers of configuration to use an alternate method of 882 accessing the underlying database such as connecting directly to the 883 origin, or requiring the use of a non-RESTCONF mechanism for editing 884 the contents of the metadata. 886 The data nodes defined in this YANG module are writable because some 887 deployments might manage the contents in the database by using normal 888 RESTCONF editing operations with NACM, but in typical deployments 889 it's expected that DORMS clients will generally have read-only 890 access. For the reasons and requirements described in Section 7.2, 891 none of the data nodes in the DORMS module or its extensions contain 892 sensitive data. 894 DORMS servers MAY provide read-only access to clients for publicly 895 available metadata without authenticating the clients. That is, 896 under the terms in Section 2.5 of [RFC8040] read-only access to 897 publicly available data MAY be treated as unprotected resources. 899 7.2. Exposure of Metadata 901 Although some DORMS servers MAY restrict access based on client 902 identity, as described in Section 2.5 of [RFC8040], many DORMS 903 servers will use the ietf-dorms YANG model to publish information 904 without restriction, and even DORMS servers requiring client 905 authentication will inherently, because of the purpose of DORMS, be 906 providing the DORMS metadata to potentially many receivers. 908 Accordingly, future YANG modules that augment data paths under "ietf- 909 dorms:dorms" MUST NOT include any sensitive data unsuitable for 910 public dissemination in those data paths. 912 Because of the possibility that scalable read-only access might be 913 necessary to fulfill the scalability goals for a DORMS server, data 914 under these paths MAY be cached or replicated by numerous external 915 entities, so owners of such data SHOULD NOT assume such data can be 916 kept secret when provided by DORMS servers anywhere under the "ietf- 917 dorms:dorms" path even if access controls are used with authenticated 918 clients unless additional operational procedures and restrictions are 919 defined and implemented that can effectively control the 920 dissemination of the secret data. DORMS alone does not provide any 921 such mechanisms, and users of DORMS can be expected not to be 922 following any such mechanisms in the absence of additional 923 assurances. 925 7.3. Secure Communications 927 The provisions of Section 2 of [RFC8040] provide secure communication 928 requirements that are already required of DORMS servers, since they 929 are RESTCONF servers. All RESTCONF requirements and security 930 considerations remain in force for DORMS servers. 932 It is intended that security related metadata about the SSM channels 933 such as public keys for use with cryptographic algorithms may be 934 delivered over the RESTCONF connection, and that information 935 available from this connection can be used as a trust anchor. The 936 secure transport provided by these minimum requirements are relied 937 upon to provide authenticated delivery of these trust anchors, once a 938 connection with a trusted DORMS server has been established. 940 7.4. Record-Spoofing 942 When using the DNS Boostrap method of discovery described in 943 Section 2.1, the SRV resource record contains information that SHOULD 944 be communicated to the DORMS client without being modified. The 945 method used to ensure the result was unmodified is up to the client. 947 There must be a trust relationship between the end consumer of this 948 resource record and the DNS server. This relationship may be end-to- 949 end DNSSEC validation or a secure connection to a trusted DNS server 950 that provides end-to-end safety to prevent record-spoofing of the 951 response from the trusted server. The connection to the trusted 952 server can use any secure channel, such as with a TSIG [RFC8945] or 953 SIG(0) [RFC2931] channel, a secure local channel on the host, DNS 954 over TLS [RFC7858], DNS over HTTPS [RFC8484], or some other mechanism 955 that provides authentication of the RR. 957 If a DORMS client accepts a maliciously crafted SRV record, the 958 client could connect to a server controlled by the attacker, and use 959 metadata provided by them. The consequences of trusting maliciously 960 crafted metadata could range from attacks against the DORMS client's 961 parser of the metadata (via malicious constructions of the formatting 962 of the data) to arbitrary disruption of the decisions the DORMS 963 client makes as a result of processing validly constructed metadata. 965 Clients MAY use other secure methods to explicitly associate an (S,G) 966 with a set of DORMS server hostnames, such as a configured mapping or 967 an alternative trusted lookup service. 969 7.5. CORS considerations 971 As described in Section 2.3.5, it's RECOMMENDED that DORMS servers 972 provide appropriate restrictions to ensure only authorized web pages 973 access metadata for their (S,G)s from the widely deployed base of 974 secure browsers that use the CORS protocol according to 975 [whatwg-fetch]. 977 Providing '*' for the allowed origins exposes the DORMS-based 978 metadata to access by scripts in all web pages, which opens the 979 possibility of certain kinds of attacks against networks where 980 browsers have support for joining multicast (S,G)s. 982 If the authentication for an (S,G) relies on DORMS-based metadata 983 (for example, as defined in [I-D.draft-ietf-mboned-ambi]), an 984 unauthorized web page that tries to join an (S,G) not permitted by 985 the CORS headers for the DORMS server will be prevented from 986 subscribing to the channels. 988 If an unauthorized site is not prevented from subscribing, code on 989 the site (for example a malicious advertisement) could request 990 subscriptions from many different (S,G)s, overflowing limits on the 991 joining of (S,G)s and disrupting the delivery of multicast traffic 992 for legitimate use. 994 Further, if the malicious script can be distributed to many different 995 users within the same receiving network, the script could coordinate 996 an attack against the network as a whole by joining disjoint sets of 997 (S,G)s from different users within the receiving network. The 998 distributed subscription requests across the receiving network could 999 overflow limits for the receiving network as a whole, essentially 1000 causing the websites displaying the ad to participate in an 1001 overjoining attack (see Appendix A of [I-D.draft-ietf-mboned-cbacc]). 1003 Even if network safety mechanisms protect the network from the worst 1004 effects of oversubscription, the population counts for the multicast 1005 subscriptions could be disrupted by this kind of attack, and 1006 therefore push out legitimately requested traffic that's being 1007 consumed by real users. For a legitimately popular event, this could 1008 cause a widespread disruption to the service if it's successfully 1009 pushed out. 1011 A denial of service attack of this sort would be thwarted by 1012 restricting the access to (S,G)s to authorized websites through the 1013 use of properly restricted CORS headers. 1015 8. Acknowledgements 1017 Thanks to Christian Worm Mortensen, Dino Farinacci, Lenny Guiliano, 1018 and Reshad Rahman for their very helpful comments and reviews. 1020 9. References 1022 9.1. Normative References 1024 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1025 Requirement Levels", BCP 14, RFC 2119, 1026 DOI 10.17487/RFC2119, March 1997, 1027 . 1029 [RFC2317] Eidnes, H., de Groot, G., and P. Vixie, "Classless IN- 1030 ADDR.ARPA delegation", BCP 20, RFC 2317, 1031 DOI 10.17487/RFC2317, March 1998, 1032 . 1034 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 1035 specifying the location of services (DNS SRV)", RFC 2782, 1036 DOI 10.17487/RFC2782, February 2000, 1037 . 1039 [RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, 1040 "DNS Extensions to Support IP Version 6", STD 88, 1041 RFC 3596, DOI 10.17487/RFC3596, October 2003, 1042 . 1044 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 1045 and A. Bierman, Ed., "Network Configuration Protocol 1046 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 1047 . 1049 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", 1050 RFC 6991, DOI 10.17487/RFC6991, July 2013, 1051 . 1053 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 1054 RFC 7950, DOI 10.17487/RFC7950, August 2016, 1055 . 1057 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 1058 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 1059 . 1061 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1062 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1063 May 2017, . 1065 [RFC8294] Liu, X., Qu, Y., Lindem, A., Hopps, C., and L. Berger, 1066 "Common YANG Data Types for the Routing Area", RFC 8294, 1067 DOI 10.17487/RFC8294, December 2017, 1068 . 1070 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 1071 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 1072 . 1074 [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration 1075 Access Control Model", STD 91, RFC 8341, 1076 DOI 10.17487/RFC8341, March 2018, 1077 . 1079 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 1080 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 1081 . 1083 [whatwg-fetch] 1084 "WHATWG Fetch Living Standard", October 2020, 1085 . 1087 9.2. Informative References 1089 [I-D.draft-ietf-core-comi] 1090 Veillette, M., Stok, P. V. D., Pelov, A., Bierman, A., and 1091 I. Petrov, "CoAP Management Interface (CORECONF)", Work in 1092 Progress, Internet-Draft, draft-ietf-core-comi-11, 17 1093 January 2021, . 1096 [I-D.draft-ietf-mboned-ambi] 1097 Holland, J. and K. Rose, "Asymmetric Manifest Based 1098 Integrity", Work in Progress, Internet-Draft, draft-ietf- 1099 mboned-ambi-01, 31 October 2020, 1100 . 1103 [I-D.draft-ietf-mboned-cbacc] 1104 Holland, J., "Circuit Breaker Assisted Congestion 1105 Control", Work in Progress, Internet-Draft, draft-ietf- 1106 mboned-cbacc-02, 1 February 2021, 1107 . 1110 [I-D.draft-openconfig-rtgwg-gnmi-spec] 1111 Shakir, R., Shaikh, A., Borman, P., Hines, M., Lebsack, 1112 C., and C. Morrow, "gRPC Network Management Interface 1113 (gNMI)", Work in Progress, Internet-Draft, draft- 1114 openconfig-rtgwg-gnmi-spec-01, 5 March 2018, 1115 . 1118 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 1119 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 1120 . 1122 [RFC1035] Mockapetris, P., "Domain names - implementation and 1123 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 1124 November 1987, . 1126 [RFC2931] Eastlake 3rd, D., "DNS Request and Transaction Signatures 1127 ( SIG(0)s )", RFC 2931, DOI 10.17487/RFC2931, September 1128 2000, . 1130 [RFC3040] Cooper, I., Melve, I., and G. Tomlinson, "Internet Web 1131 Replication and Caching Taxonomy", RFC 3040, 1132 DOI 10.17487/RFC3040, January 2001, 1133 . 1135 [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. 1136 Thyagarajan, "Internet Group Management Protocol, Version 1137 3", RFC 3376, DOI 10.17487/RFC3376, October 2002, 1138 . 1140 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1141 DOI 10.17487/RFC3688, January 2004, 1142 . 1144 [RFC3810] Vida, R., Ed. and L. Costa, Ed., "Multicast Listener 1145 Discovery Version 2 (MLDv2) for IPv6", RFC 3810, 1146 DOI 10.17487/RFC3810, June 2004, 1147 . 1149 [RFC4604] Holbrook, H., Cain, B., and B. Haberman, "Using Internet 1150 Group Management Protocol Version 3 (IGMPv3) and Multicast 1151 Listener Discovery Protocol Version 2 (MLDv2) for Source- 1152 Specific Multicast", RFC 4604, DOI 10.17487/RFC4604, 1153 August 2006, . 1155 [RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for 1156 IP", RFC 4607, DOI 10.17487/RFC4607, August 2006, 1157 . 1159 [RFC5013] Kunze, J. and T. Baker, "The Dublin Core Metadata Element 1160 Set", RFC 5013, DOI 10.17487/RFC5013, August 2007, 1161 . 1163 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 1164 the Network Configuration Protocol (NETCONF)", RFC 6020, 1165 DOI 10.17487/RFC6020, October 2010, 1166 . 1168 [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. 1169 Cheshire, "Internet Assigned Numbers Authority (IANA) 1170 Procedures for the Management of the Service Name and 1171 Transport Protocol Port Number Registry", BCP 165, 1172 RFC 6335, DOI 10.17487/RFC6335, August 2011, 1173 . 1175 [RFC6415] Hammer-Lahav, E., Ed. and B. Cook, "Web Host Metadata", 1176 RFC 6415, DOI 10.17487/RFC6415, October 2011, 1177 . 1179 [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., 1180 and P. Hoffman, "Specification for DNS over Transport 1181 Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 1182 2016, . 1184 [RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS 1185 (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, 1186 . 1188 [RFC8945] Dupont, F., Morris, S., Vixie, P., Eastlake 3rd, D., 1189 Gudmundsson, O., and B. Wellington, "Secret Key 1190 Transaction Authentication for DNS (TSIG)", STD 93, 1191 RFC 8945, DOI 10.17487/RFC8945, November 2020, 1192 . 1194 Author's Address 1196 Jake Holland 1197 Akamai Technologies, Inc. 1198 150 Broadway 1199 Cambridge, MA 02144, 1200 United States of America 1202 Email: jakeholland.net@gmail.com