Discovery Of Restconf Metadata for Source-specific multicast

Introduction This document defines DORMS (Discovery Of Restconf Metadata for Source-specific multicast). A DORMS service is a RESTCONF service that provides read access to data in the "ietf-dorms" YANG model defined in . This model, along with optional extensions defined in other documents, provide an extensible set of information about multicast data streams. A review of some example use cases that can be enabled by this kind of metadata is given in . This document does not prohibit the use of the "ietf-dorms" model with other protocols such as NETCONF , CORECONF , or gNMI , but the semantics of using the model over those protocols is out of scope for this document. This document only defines the discovery and use of the "ietf-dorms" YANG model in RESTCONF. This document defines the "dorms" service name for use with the SRV DNS Resource Record (RR) type . A sender using a DORMS service to publish metadata SHOULD configure at least one SRV RR for the "_dorms._tcp" subdomain in the reverse IP DNS zone for the source IP used by some active multicast traffic. The domain name in one of these SRV records provides a hostname corresponding to a DORMS server that can provide metadata for the sender's source-specific multicast traffic. Publishing such a RR enables DORMS clients to discover and query a DORMS server as described in .

Background The reader is assumed to be familiar with the basic DNS concepts described in , , and the subsequent documents that update them, as well as the use of the SRV Resource Record type as described in . The reader is also assumed to be familiar with the concepts and terminology regarding source-specific multicast as described in and the use of IGMPv3 and MLDv2 for group management of source-specific multicast channels, as described in . The reader is also assumed to be familiar with the concepts and terminology for RESTCONF and YANG .

Terminology

Term	Definition
(S,G)	A source-specific multicast channel, as described in . A pair of IP addresses with a source host IP and destination group IP.
DORMS client	An application or system that can communicate with DORMS servers to fetch metadata about (S,G)s.
DORMS server	A RESTCONF server that implements the ietf-dorms YANG model defined in this document.
RR	A DNS Resource Record, as described in
RRType	A DNS Resource Record Type, as described in
SSM	Source-specific multicast, as described in

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in and when, and only when, they appear in all capitals, as shown here.

Motivation and Use Cases DORMS provides a framework that can be extended to publish supplemental information about multicast traffic in a globally discoverable manner. This supplemental information may be needed by entities involved in the delivery or processing of the traffic to ensure it is handled in accordance with their operational or policy requirements. Detailing the specifics of all known possible extensions is out of scope for this document except to note that a range of possible use cases are expected and they may be supported by a variety of different future extensions. But a few example use cases are provided below for illustration.

Provisioning and Oversubscription Protection One use case for DORMS is when a network that is capable of forwarding multicast traffic may need to take provisioning actions or make admission control decisions based on the expected bitrate of the traffic in order to prevent oversubscription of constrained devices in the network. In such a case, the network in question could learn these bitrates from the metadata provided by DORMS. defines some DORMS extensions to support this use case.

Authentication Another use case for DORMS is providing information for use in authenticating the multicast traffic before accepting it for forwarding by a network device, or for processing by a receiving application. As DORMS metadata is transmitted over a secure and authenticated connection, it can act as a security anchor for data required to verify the authenticity of multicast packets. defines some DORMS extensions to support this use case.

Content Description Another use case for DORMS is describing the contents carried by a multicast traffic channel. The content description could include information about the protocols or applications that can be used to consume the traffic, or information about the media carried (e.g. information based on the Dublin Core Metadata Element Set ), or could make assertions about the legal status of the traffic within specific contexts.

Notes for Contributors and Reviewers Note to RFC Editor: Please remove this section and its subsections before publication. This section is to provide references to make it easier to review the development and discussion on the draft so far.

Venues for Contribution and Discussion This document is in the Github repository at: https://github.com/GrumpyOldTroll/ietf-dorms-cluster Readers are welcome to open issues and send pull requests for this document. Please note that contributions may be merged and substantially edited, and as a reminder, please carefully consider the Note Well before contributing: https://datatracker.ietf.org/submit/note-well/ Substantial discussion of this document should take place on the MBONED working group mailing list (mboned@ietf.org).

Join: https://www.ietf.org/mailman/listinfo/mboned
Search: https://mailarchive.ietf.org/arch/browse/mboned/

Discovery and Metadata Retrieval A client that needs metadata about an (S,G) MAY attempt to discover metadata for the (S,G) using the mechanisms defined here, and MAY use the metadata received to manage the forwarding or processing of the packets in the channel.

Channel Discovery DORMS provides a method for clients to fetch metadata about (S,G)s that are already known to the clients. In general, a DORMS client might learn of an (S,G) by any means, so describing all possible methods a DORMS client might use to discover a set of (S,G)s for which it wants metadata is out of scope for this document. But for example, a multicast receiver application that is a DORMS client might learn about an (S,G) by getting signals from inside the application logic, such as a selection made by a user, or a scheduled API call that reacts to updates in a library provided by a service operator. As another example, an on-path router that’s a DORMS client might instead learn about an (S,G) by receiving a PIM message or an IGMP or MLD membership report indicating a downstream client has tried to subscribe to an (S,G). Such a router might use information learned from the DORMS metadata to make an access control decision about whether to propagate the join further upstream in the network. Other approaches for learning relevant (S,G)s could be driven by monitoring a route reflector to discover channels that are being actively forwarded, for a purpose such as monitoring network health.

DNS Bootstrap The DNS Bootstrap step is how a client discovers an appropriate RESTCONF server, given the source address of an (S,G). Use of the DNS Bootstrap is OPTIONAL for clients with an alternate method of obtaining a hostname of a trusted DORMS server that has information about a target (S,G). This mechanism only works for source-specific multicast (SSM) channels. The source address of the (S,G) is reversed and used as an index into one of the reverse mapping trees (in-addr.arpa for IPv4, as described in Section 3.5 of , or ip6.arpa for IPv6, as described in Section 2.5 of ). When a DORMS client needs metadata for an (S,G), for example when handling a new join for that (S,G) and looking up the authentication methods that are available, the DORMS client can issue a DNS query for an SRV RR using the "dorms" service name with the domain from the reverse mapping tree, combining them as described in . For example, a client looking for metadata about the channel with a source IP of 2001:db8::a and the group address of ff3e::8000:d, the client would start the DNS bootstrap step by performing a query for the SRV RRType for the following domain (after removing the line break inserted for editorial reasons): Or for an IPv4 (S,G) with a source address of 203.0.113.4, the DORMS client would request the SRV record from the in-addr.arpa tree instead: In either case, the DNS response for this domain might return a record such as this: This response informs the client that a DORMS server should be reachable at dorms-restconf.example.com on port 443, and should contain metadata about multicast traffic from the given source IP. Multiple SRV records are handled as described by . A sender providing DORMS discovery SHOULD publish at least one SRV record in the reverse DNS zone for each source address of the multicast channels it is sending in order to advertise the hostname of the DORMS server to DORMS clients. The DORMS servers advertised SHOULD be configured with metadata for all the groups sent from the same source IP address that have metadata published with DORMS. When performing the SRV lookup, any CNAMEs or DNAMEs found MUST be followed. This is necessary to support zone delegation. Some examples outlining this need are described in .

RESTCONF Bootstrap Once a DORMS server has been chosen (whether via an SRV RR from a DNS response or via some other method), RESTCONF provides all the information necessary to determine the versions and url paths for metadata from the server. A walkthrough is provided here for a sequence of example requests and responses between a DORMS client and a new DORMS server.

Root Resource Discovery As described in Section 3.1 of and , the RESTCONF server provides the link to the RESTCONF api entry point via the "/.well-known/host-meta" or "/.well-known/host-meta.json" resource. Example: The client might send: The server might respond as follows:

YANG Library Version As described in Section 3.3.3 of , the yang-library-version leaf is required by RESTCONF, and can be used to determine the schema of the ietf-yang-library module: Example: The client might send: The server might respond as follows: If a DORMS client determines through examination of the yang-library-version that it may not understand the responses of the server due to a version mismatch, the server qualifies as a candidate for adding to an ignore list as described in .

YANG Library Contents After checking that it supports the version of the yang-library module offered by the server, the client can check that the desired metadata modules are available on the DORMS server by fetching the module-state resource from the ietf-yang-library module. Example: The client might send: The server might respond as follows: Other modules required or desired by the client also can be checked in a similar way, or the full set of available modules can be retrieved by not providing a key for the "module" list. If a DORMS client that requires the presence of certain modules to perform its function discovers the required modules are not present on a server, that server qualifies for inclusion in an ignore list according to .

Metadata Retrieval Once the expected DORMS version is confirmed, the client can retrieve the metadata specific to the desired (S,G). Example: The client might send: The server might respond as follows: Note that when other modules are installed on the DORMS server that extend the ietf-dorms module, other fields MAY appear inside the response. This is the primary mechanism for providing extensible metadata for an (S,G), so clients SHOULD ignore fields they do not understand. As mentioned in , most clients SHOULD use data resource identifiers in the request URI as in the above example, in order to retrieve metadata for only the targeted (S,G)s.

Cross Origin Resource Sharing (CORS) It is RECOMMENDED that DORMS servers use the Access-Control-Allow-Origin header field, as specified by , and that they respond appropriately to Preflight requests. The use of '*' for allowed origins is NOT RECOMMENDED for publicly reachable DORMS servers. A review of some of the potential consequences of unrestricted CORS access is given in .

YANG Model The primary purpose of the YANG model defined here is to serve as a scaffold for the more useful metadata that will extend it. See for some example use cases that can be enabled by the use of DORMS extensions.

YANG Tree The tree diagram below follows the notation defined in .

DORMS Tree Diagram

YANG Module "; description "Copyright (c) 2025 IETF Trust and the persons identified as authors of the code. All rights reserved. Redistribution and use in source and binary forms, with or without modification, is permitted pursuant to, and subject to the license terms contained in, the Simplified BSD License set forth in Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info). This version of this YANG module is part of RFC XXXX (https://www.rfc-editor.org/info/rfcXXXX); see the RFC itself for full legal notices. The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document are to be interpreted as described in BCP 14 (RFC 2119) (RFC 8174) when, and only when, they appear in all capitals, as shown here. This module contains the definition for the DORMS data type. It provides out of band metadata about SSM channels."; revision 2025-09-15 { description "Draft version, post-early-review."; reference "draft-ietf-mboned-dorms"; } container dorms { description "Top-level DORMS container."; container metadata { description "Metadata scaffold for source-specific multicast channels."; list sender { key source-address; description "Sender for DORMS"; leaf source-address { type inet:ip-address-no-zone; mandatory true; description "The source IP address of a multicast sender."; } list group { key group-address; description "Metadata for a DORMS (S,G)."; leaf group-address { type rt-types:ip-multicast-group-address; mandatory true; description "The group IP address for an (S,G)."; } must '(re-match(./group-address, "[^:]*") and ' + 're-match(../source-address, "[^:]*")) or ' + '(re-match(./group-address, ".*:.*") and ' + 're-match(../source-address, ".*:.*"))' { error-message 'A group-address type must match '+ 'its parent source-address type'; } list udp-stream { key "port"; description "Metadata for UDP traffic on a specific port."; leaf port { type inet:port-number; mandatory true; description "The UDP port of a data stream."; } } } } } } } ]]>

Security Considerations

YANG Model Considerations The YANG module specified in this document defines a schema for data that is designed to be accessed via RESTCONF . The lowest RESTCONF layer is HTTPS, and the mandatory-to-implement secure transport is TLS . There are a number of data nodes defined in this YANG module that are writable/creatable/deletable (i.e., config true, which is the default). These data nodes may be considered sensitive or vulnerable in some network environments. Write operations to these data nodes (e.g., via HTTP POST/PUT/PATCH/DELETE methods) without proper protection can have a negative effect on network operations. These are the subtrees and data nodes and their sensitivity/vulnerability: Subtrees:

/dorms/metadata
/dorms/metadata/sender
/dorms/metadata/sender/group
/dorms/metadata/sender/group/udp-stream

Data nodes:

/dorms/metadata/sender/source-address
/dorms/metadata/sender/group/group-address
/dorms/metadata/sender/group/udp-stream/port

These data nodes refer to the characteristics of a stream of data packets being sent on a multicast channel. If an unauthorized or incorrect edit is made, receivers would no longer be able to associate the data stream to the correct metadata, resulting in a denial-of-service for end users that rely on the metadata to properly process the data packets. Therefore, DORMS servers MUST constrain write access to ensure that unauthorized users cannot edit the data published by the server. The Network Configuration Access Control Model (NACM) provides the means to restrict access for particular NETCONF or RESTCONF users to a preconfigured subset of all available NETCONF or RESTCONF protocol operations and content. DORMS servers SHOULD use NACM to constrain write accesses if NETCONF or RESTCONF are configured to offer any write access at all. However, note that scalability considerations described in might make the naive use of NACM intractable in many deployments, for a broadcast use case. So alternative methods to constrain write access to the metadata MAY be used instead of or in addition to NACM. For example, some deployments that use a CDN or caching layer of discoverable DORMS servers might uniformly provide read-only access through the caching layer, and require the trusted writers of configuration to use an alternate method for accessing the underlying database such as connecting directly to the origin, or requiring the use of a non-RESTCONF mechanism (such as an HTTPS API requiring some kind of client authentication) for editing the contents of the metadata. The data nodes defined in this YANG module are writable because some deployments might manage the contents in the database by using normal RESTCONF editing operations with NACM, but in typical deployments it is expected that DORMS clients will generally have read-only access. For the reasons and requirements described in , none of the data nodes in the DORMS module or its extensions contain sensitive data. DORMS servers MAY provide read-only access to clients for publicly available metadata without authenticating the clients. That is, under the terms in Section 2.5 of read-only access to publicly available data MAY be treated as unprotected resources.

Exposure of Metadata Although some DORMS servers MAY restrict access based on client identity, as described in Section 2.5 of , many DORMS servers will use the ietf-dorms YANG model to publish information without restriction, and even DORMS servers requiring client authentication will inherently be providing the DORMS metadata to a multitude of multicast receivers acting as DORMS clients. Accordingly, future YANG modules that augment data paths under "ietf-dorms:dorms" MUST NOT include any sensitive data unsuitable for public dissemination in those data paths. Because of the possibility that scalable read-only access might be necessary to fulfill the scalability goals for a DORMS server, data under these paths MAY be cached or replicated by numerous external entities, so owners of such data SHOULD NOT assume such data can be kept secret when provided by DORMS servers anywhere under the "ietf-dorms:dorms" path even if access controls are used with authenticated clients unless additional operational procedures and restrictions are defined and implemented that can effectively control the dissemination of the secret data. DORMS alone does not provide any such mechanisms, and users of DORMS can be expected not to be following any such mechanisms in the absence of additional assurances.

Secure Communications The provisions of Section 2 of provide secure communication requirements that are already required of DORMS servers, since they are RESTCONF servers. All RESTCONF requirements and security considerations remain in force for DORMS servers. It is intended that security-related metadata about the SSM channels such as public keys for use with cryptographic algorithms may be delivered over the RESTCONF connection, and that information available from this connection can be used as a trust anchor. The secure transport provided by these minimum requirements are relied upon to provide authenticated delivery of these trust anchors, once a connection with a trusted DORMS server has been established.

Record-Spoofing When using the DNS Bootstrap method of discovery described in , the SRV resource record contains information that MUST be communicated to the DORMS client without being modified. The method used to ensure the result was unmodified is up to the client. There must be a trust relationship between the end consumer of this resource record and the DNS server. This relationship may be end-to-end DNSSEC validation or a secure connection to a trusted resolver that itself makes use of mechanisms for ensuring RR integrity (e.g., by enforcing DNSSEC validation on recursive requests) to prevent record-spoofing of the response from the trusted server. The connection to this trusted resolver can use any secure channel, such as with a TSIG or SIG(0) channel, a secure local channel on the host, DNS over TLS , or DNS over HTTPS . Any combination of mechanisms may be employed that together guarantee end-to-end integrity of the intended RR. If a DORMS client accepts a maliciously crafted SRV record, the client could connect to a server controlled by the attacker, and use metadata provided by them. The consequences of trusting maliciously crafted metadata could range from attacks against the DORMS client's parser of the metadata (via malicious constructions of the formatting of the data) to arbitrary disruption of the decisions the DORMS client makes as a result of processing validly constructed metadata. Clients MAY use other secure methods to explicitly associate an (S,G) with a set of DORMS server hostnames, such as a configured mapping or an alternative trusted lookup service.

CORS considerations As described in , it is RECOMMENDED that DORMS servers provide appropriate restrictions to ensure only authorized web pages access metadata for their (S,G)s from the widely deployed base of secure browsers that use the CORS protocol according to . Providing '*' for the allowed origins exposes the DORMS-based metadata to access by scripts in all web pages, which opens the possibility of certain kinds of attacks against networks where browsers have support for joining multicast (S,G)s. If the authentication for an (S,G) relies on DORMS-based metadata (for example, as defined in ), an unauthorized web page that tries to join an (S,G) not permitted by the CORS headers for the DORMS server will be prevented from subscribing to the channels. If an unauthorized site is not prevented from subscribing, code on the site (for example a malicious advertisement) could request subscriptions from many different (S,G)s, overflowing limits on the joining of (S,G)s and disrupting the delivery of multicast traffic for legitimate use. Further, if the malicious script can be distributed to many different users within the same receiving network, the script could coordinate an attack against the network as a whole by joining disjoint sets of (S,G)s from different users within the receiving network. The distributed subscription requests across the receiving network could overflow limits for the receiving network as a whole, essentially causing the websites displaying the ad to participate in an overjoining attack (see Appendix A of ). Even if network safety mechanisms protect the network from the worst effects of oversubscription, the population counts for the multicast subscriptions could be disrupted by this kind of attack, and therefore push out legitimately requested traffic that's being consumed by real users. For a legitimately popular event, this could cause a widespread disruption to the service if it is successfully pushed out. A denial-of-service attack of this sort would be thwarted by restricting the access to (S,G)s to authorized websites through the use of properly restricted CORS headers.

Privacy Considerations

Linking Content to Traffic Streams In the typical case, the mechanisms defined in this document provide a standardized way to discover information that is already available in other ways. However, depending on the metadata provided by the server, observers may be able to more easily associate traffic from an (S,G) with the content contained within the (S,G). At the subscriber edge of a multicast-capable network, where the network operator has the capability to localize an IGMP or MLD channel subscription to a specific user or location, for example by MAC address or source IP address, the structured publishing of metadata may make it easier to automate collection of data about the content a receiver is consuming.

Linking Multicast Subscribers to Unicast Connections Subscription to a multicast channel generally only exposes the IGMP or MLD membership report to others on the same LAN, and as the membership propagates through a multicast-capable network, it ordinarily gets aggregated with other end users. However, a RESTCONF connection is a unicast connection, and exposes a different set of information to the operator of the RESTCONF server, including IP address and timing about the requests made. Where DORMS access becomes required for a successful multicast join (for example, as expected in a browser deployment), this can expose new information about end users relative to services based solely on multicast streams. The information disclosure occurs by giving the DORMS service operator information about the client's IP and the channels the client queried. Additionally, an on-path observer may infer multicast subscription intent by observing client traffic directed to a known DORMS server. In some deployments it may be possible to use a proxy that aggregates many end users when the aggregate privacy characteristics are needed by end users.

Operational Considerations

Provisioning In contrast to many common RESTCONF deployments that are intended to provide configuration management for a service to a narrow set of authenticated administrators, DORMS servers often provide read-only metadata for public access or for a very large set of end receivers, since it provides metadata in support of multicast data streams and multicast can scale to very large audiences. Operators are advised to provision the DORMS service in a way that will scale appropriately to the size of the expected audience. Specific advice on such scaling is out of scope for this document, but some of the mechanisms outlined in or other online resources might be useful, depending on the expected number of clients.

Data Scoping Except as outlined below, clients SHOULD issue narrowed requests for DORMS resources by following the format from Section 3.5.3 of to encode data resource identifiers in the request URI. This avoids downloading excessive data, since the DORMS server may provide metadata for many (S,G)s, possibly from many different senders. However, clients that possess out-of-band knowledge about the expected content scope MAY issue (S,G) metadata requests that are filtered only by the source address, or that are unfiltered altogether. Depending on the request patterns and the contents of the data store, this may result in fewer round trips or less overhead, and can therefore be helpful behavior for scaling purposes in some scenarios. In general, engaging in this behavior requires some administrative configuration or some optimization heuristics that can recover from unexpected results. Servers MAY restrict or throttle client access based on the client certificate presented (if any), or based on heuristics that take note of client request patterns. A complete description of the heuristics for clients and servers to meet their scalability goals is out of scope for this document.

Ignore List If a DORMS client reaches a DORMS server but determines through examination of responses from that DORMS server that it may not understand or be able to use the responses of the server (for example due to an issue like a version mismatch or modules that are missing but are required for the DORMS client's purposes), the client MAY add this server to an ignore list and reject servers in its ignore list during future discovery attempts. A client using the DNS Bootstrap discovery method in would treat servers in its ignore list as unreachable for the purposes of processing the SRV RR as described in . (For example, a client might end up selecting a server with a less-preferred priority than servers in its ignore list, even if an HTTPS connection could have been formed successfully with some of those servers.) If an ignore list is maintained, entries SHOULD time out and allow for re-checking after a configurable hold-down time that has a default value no shorter than 1 hour and no longer than 24 hours.

IANA Considerations

The YANG Module Names Registry This document adds one YANG module to the "YANG Module Names" registry maintained at <https://www.iana.org/assignments/yang-parameters>. The following registrations are made, per the format in Section 14 of :

The XML Registry This document adds the following registration to the "ns" subregistry of the "IETF XML Registry" defined in , referencing this document.

The Service Name and Transport Protocol Port Number Registry This document adds one service name to the "Service Name and Transport Protocol Port Number Registry" maintained at <https://www.iana.org/assignments/service-names-port-numbers>. The following registrations are made, per the format in Section 8.1.1 of : Contact: IETF Chair Description: The DORMS service (RESTCONF that includes ietf-dorms YANG model) Reference: I-D.draft-ietf-mboned-dorms Port Number: N/A Service Code: N/A Known Unauthorized Uses: N/A Assignment Notes: N/A ]]>

Acknowledgements Thanks to Christian Worm Mortensen, Dino Farinacci, Lenny Guiliano, and Reshad Rahman for their very helpful comments and reviews.