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