--- 1/draft-ietf-mboned-dorms-00.txt 2020-10-31 16:13:24.161229518 -0700 +++ 2/draft-ietf-mboned-dorms-01.txt 2020-10-31 16:13:24.205230630 -0700 @@ -1,18 +1,18 @@ Mboned J. Holland Internet-Draft Akamai Technologies, Inc. -Intended status: Standards Track March 10, 2020 -Expires: September 11, 2020 +Intended status: Standards Track October 30, 2020 +Expires: May 3, 2021 Discovery Of Restconf Metadata for Source-specific multicast - draft-ietf-mboned-dorms-00 + draft-ietf-mboned-dorms-01 Abstract This document defines DORMS (Discovery Of Restconf Metadata for Source-specific multicast), a method to discover and retrieve extensible metadata about source-specific multicast channels using RESTCONF. The reverse IP DNS zone for a multicast sender's IP address is configured to use SRV resource records to advertise the hostname of a RESTCONF server that publishes metadata according to a new YANG module with support for extensions. A new service name and @@ -26,97 +26,105 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on September 11, 2020. + This Internet-Draft will expire on May 3, 2021. Copyright Notice Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Background . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 - 2. Discovery and Metdata Retrieval . . . . . . . . . . . . . . . 4 - 2.1. DNS Bootstrap . . . . . . . . . . . . . . . . . . . . . . 4 - 2.2. RESTCONF Bootstrap . . . . . . . . . . . . . . . . . . . 5 - 2.2.1. Root Resource Discovery . . . . . . . . . . . . . . . 5 - 2.2.2. Yang Library Version . . . . . . . . . . . . . . . . 6 - 2.2.3. Yang Library Contents . . . . . . . . . . . . . . . . 6 - 2.2.4. Metadata Retrieval . . . . . . . . . . . . . . . . . 7 - 2.2.5. Cross Origin Resource Sharing (CORS) . . . . . . . . 8 - 3. Scalability Considerations . . . . . . . . . . . . . . . . . 9 - 3.1. Provisioning . . . . . . . . . . . . . . . . . . . . . . 9 - 3.2. Data Scoping . . . . . . . . . . . . . . . . . . . . . . 9 - 4. YANG Model . . . . . . . . . . . . . . . . . . . . . . . . . 9 - 4.1. Yang Tree . . . . . . . . . . . . . . . . . . . . . . . . 10 - 4.2. Yang Module . . . . . . . . . . . . . . . . . . . . . . . 10 - 5. Privacy Considerations . . . . . . . . . . . . . . . . . . . 12 - 5.1. Linking Content to Traffic Streams . . . . . . . . . . . 12 - 5.2. Linking Multicast Subscribers to Unicast Connections . . 12 - 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 - 6.1. The YANG Module Names Registry . . . . . . . . . . . . . 13 - 6.2. The Service Name and Transport Protocol Port Number - Registry . . . . . . . . . . . . . . . . . . . . . . . . 13 - 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 - 7.1. Secure Communications . . . . . . . . . . . . . . . . . . 13 - 7.2. Exposure of Metadata . . . . . . . . . . . . . . . . . . 14 - 7.3. DNS Bootstrapping . . . . . . . . . . . . . . . . . . . . 14 - 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 - 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 - 9.1. Normative References . . . . . . . . . . . . . . . . . . 15 - 9.2. Informative References . . . . . . . . . . . . . . . . . 16 - Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 17 + 1.3. Motivation . . . . . . . . . . . . . . . . . . . . . . . 4 + 1.3.1. Use cases . . . . . . . . . . . . . . . . . . . . . . 4 + 1.3.2. Channel Selection . . . . . . . . . . . . . . . . . . 5 + 1.4. Notes for Contributors and Reviewers . . . . . . . . . . 5 + 1.4.1. Venues for Contribution and Discussion . . . . . . . 5 + 1.4.2. Non-obvious doc choices . . . . . . . . . . . . . . . 6 + 2. Discovery and Metdata Retrieval . . . . . . . . . . . . . . . 6 + 2.1. DNS Bootstrap . . . . . . . . . . . . . . . . . . . . . . 6 + 2.2. Ignore List . . . . . . . . . . . . . . . . . . . . . . . 7 + 2.3. RESTCONF Bootstrap . . . . . . . . . . . . . . . . . . . 8 + 2.3.1. Root Resource Discovery . . . . . . . . . . . . . . . 8 + 2.3.2. Yang Library Version . . . . . . . . . . . . . . . . 8 + 2.3.3. Yang Library Contents . . . . . . . . . . . . . . . . 9 + 2.3.4. Metadata Retrieval . . . . . . . . . . . . . . . . . 10 + 2.3.5. Cross Origin Resource Sharing (CORS) . . . . . . . . 11 + 3. Scalability Considerations . . . . . . . . . . . . . . . . . 11 + 3.1. Provisioning . . . . . . . . . . . . . . . . . . . . . . 11 + 3.2. Data Scoping . . . . . . . . . . . . . . . . . . . . . . 12 + 4. YANG Model . . . . . . . . . . . . . . . . . . . . . . . . . 12 + 4.1. Yang Tree . . . . . . . . . . . . . . . . . . . . . . . . 12 + 4.2. Yang Module . . . . . . . . . . . . . . . . . . . . . . . 13 + 5. Privacy Considerations . . . . . . . . . . . . . . . . . . . 15 + 5.1. Linking Content to Traffic Streams . . . . . . . . . . . 15 + 5.2. Linking Multicast Subscribers to Unicast Connections . . 15 + 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 + 6.1. The YANG Module Names Registry . . . . . . . . . . . . . 16 + 6.2. The XML Registry . . . . . . . . . . . . . . . . . . . . 16 + 6.3. The Service Name and Transport Protocol Port Number + Registry . . . . . . . . . . . . . . . . . . . . . . . . 16 + 7. Security Considerations . . . . . . . . . . . . . . . . . . . 17 + 7.1. YANG Model Considerations . . . . . . . . . . . . . . . . 17 + 7.2. Exposure of Metadata . . . . . . . . . . . . . . . . . . 17 + 7.3. Secure Communications . . . . . . . . . . . . . . . . . . 18 + 7.4. Record-Spoofing . . . . . . . . . . . . . . . . . . . . . 18 + 7.5. CORS considerations . . . . . . . . . . . . . . . . . . . 19 + 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20 + 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 + 9.1. Normative References . . . . . . . . . . . . . . . . . . 20 + 9.2. Informative References . . . . . . . . . . . . . . . . . 21 + + Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 23 1. Introduction This document defines DORMS (Discovery Of Restconf Metadata for Source-specific multicast). A DORMS service is a RESTCONF [RFC8040] service that provides read access to data in the "ietf-dorms" YANG [RFC7950] model defined in Section 4. This model, along with optional extensions defined in other documents, provide an extensible set of information about - multicast data streams. + multicast data streams. A review of some example use cases that can + be enabled by this kind of metadata is given in Section 1.3. This document defines the "dorms" service name for use with the SRV - DNS Resource Record (RR) type [RFC2782]. A sender offering a DORMS + DNS Resource Record (RR) type [RFC2782]. 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 of its multicast channel to advertise a hostname for a DORMS - server that can provide metadata for the sender's source-specific - multicast traffic. Doing so enables receivers and middleboxes to - discover and query a DORMS server as described in Section 2. - - The goal is to provide an extensible framework for attaching - information necessary for the correct processing of multicast data - channels, both for middle boxes forwarding the traffic, and for - receivers subscribing to traffic (hereafter called "clients"). + 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 Section 2. 1.1. Background The reader is assumed to be familiar with the basic DNS concepts described in [RFC1034], [RFC1035], and the subsequent documents that update them, as well as the use of the SRV Resource Record type as described in [RFC2782]. The reader is also assumed to be familiar with the concepts and terminology regarding source-specific multicast as described in @@ -121,99 +129,223 @@ The reader is also assumed to be familiar with the concepts and terminology regarding source-specific multicast as described in [RFC4607] and the use of IGMPv3 [RFC3376] and MLDv2 [RFC3810] for group management of source-specific multicast channels, as described in [RFC4604]. The reader is also assumed to be familiar with the concepts and terminology for RESTCONF [RFC8040] and YANG [RFC7950]. 1.2. Terminology - +--------+----------------------------------------------------------+ | Term | Definition | +--------+----------------------------------------------------------+ | (S,G) | A source-specific multicast channel, as described in | | | [RFC4607]. A pair of IP addresses with a source host IP | | | and destination group IP. | | | | + | DORMS | An application or system that can communicate with DORMS | + | client | servers to fetch metadata about (S,G)s. | + | | | + | DORMS | A RESTCONF server that implements the ietf-dorms YANG | + | server | model defined in this document. | + | | | | RR | A DNS Resource Record, as described in [RFC1034] | | | | | RRType | A DNS Resource Record Type, as described in [RFC1034] | | | | | SSM | Source-specific multicast, as described in [RFC4607] | +--------+----------------------------------------------------------+ + 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 [RFC2119] and [RFC8174] when, and only when, they appear in all capitals, as shown here. +1.3. Motivation + + DORMS provides a framework that can be extended to publish + supplemental information about multicas traffic in a globally + discoverable manner. This is useful so that entities engaged in + delivery or processing of the traffic that are not affiliated with + the sender of the traffic and who may not otherwise have any means to + discover information about the traffic, such as forwarding ISPs or + operators of firewalls providing security guarantees to their users, + can discover the information they may need in order to process the + traffic according to their requirements. + +1.3.1. Use cases + + For example, a network that is capable of forwarding multicast + traffic may need to take provisioning actions or make admission + control decisions at ingress points based on the expected bitrate of + the traffic in order to prevent oversubscription of the network. + + Other use cases may include metadata that can be used to authenticate + the multicast traffic, metadata that describes the contents of the + traffic, metadata that makes assertions about the legal status of the + traffic within specific contexts, or metadata that describes the + protocols or applications that can be used to consume the traffic. + Extensions to DORMS to support these or other kinds of metadata can + be defined by later specifications. + + Detailing the specific of the 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. + +1.3.2. Channel Selection + + In general, a DORMS client might learn of an (S,G) by any means. + Therefore, describing the full set of 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 to give a few examples, 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 futher upstream in the network. + + Other approaches for learning an (S,G) could be driven by monitoring + a route reflector to discover channels that are being actively + forwarded, for a purpose such as monitoring network health. + +1.4. 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. + +1.4.1. 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). + + o Join: https://www.ietf.org/mailman/listinfo/mboned + + o Search: https://mailarchive.ietf.org/arch/browse/mboned/ + +1.4.2. Non-obvious doc choices + + Log of odd things that need to be the way they are because of some + reason that the author or reviewers may want to know later. + + o building the draft without this line produces a warning about no + reference to [RFC6991] or [RFC8294], but these are imported in the + yang model. RFC 8407 requires the normative reference to 8294 + (there's an exception for 6991 but I'm not sure why and it doesn't + seem forbidden). + 2. Discovery and Metdata Retrieval - A client that needs metadata about a (S,G) MAY attempt to discover + 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. 2.1. 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 RESTCONF hostname for a DORMS server with metadata for an - (S,G). + obtaining a hostname of a trusted DORMS server with information about + the 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 [RFC1035], or ip6.arpa for IPv6, as described in Section 2.5 of [RFC3596]). - When a receiver or middle box needs metadata for an (S,G), for - example when handling a new join for that (S,G) and looking up - authentication methods available, a receiver or middlebox can issue a - DNS query for a SRV RR using the "dorms" service name with the domain + 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, a receiver or middlebox can issue a DNS + query for a SRV RR using the "dorms" service name with the domain from the reverse mapping tree, combining them as described in [RFC2782]. For example, while handling a join for (203.0.113.15, 232.1.1.1), a receiver would perform a DNS query for the SRV RRType for the domain: _dorms._tcp.15.113.0.203.in-addr.arpa. The DNS response for this domain might return a record such as: SRV 0 1 443 dorms-restconf.example.com. - This response informs the receiver that a DORMS server SHOULD be - reachable at dorms-restconf.example.com on port 443. Multiple SRV - records are handled as described by [RFC2782]. + This response informs the receiver 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 [RFC2782]. 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 receivers and middle boxes. 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. + 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. -2.2. RESTCONF Bootstrap +2.2. 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 Section 2.1 + would treat servers in its ignore list as unreachable for the + purposes of processing the SRV RR as described in [RFC2782]. (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 either the cache expiration time from the + response that caused the server to be added to the ignore list, or + for a configurable hold-down time that has a default value no shorter + than an hour and no longer than 3 days. + +2.3. RESTCONF Bootstrap Once a DORMS host 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 from a receiver connecting to a new DORMS server. -2.2.1. Root Resource Discovery +2.3.1. Root Resource Discovery As described in Section 3.1 of [RFC8040] and [RFC6415], 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 receiver might send: GET /.well-known/host-meta.json HTTP/1.1 @@ -230,21 +362,21 @@ { "links":[ { "rel":"restconf", "href":"/top/restconf" } ] } -2.2.2. Yang Library Version +2.3.2. Yang Library Version As described in Section 3.3.3 of [RFC8040], 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 receiver might send: GET /top/restconf/yang-library-version HTTP/1.1 @@ -256,34 +388,30 @@ HTTP/1.1 200 OK Date: Tue, 27 Aug 2019 20:56:01 GMT Server: example-server Cache-Control: no-cache Content-Type: application/yang-data+json { "ietf-restconf:yang-library-version": "2016-06-21" } - TBD: We might need a method for learning a specific restconf server - or resource path that supports a version the client knows how to use, - in the case the client is older than the server after a new yang- - library version is released... Can this be just retry with a hold- - down on specific hostnames, so that you can find a lower priority - older server from the SRV records, or is signaling that can find or - negotiate an explicit version as part of the lookup going to be - necessary? -jake 2019-08-26 + 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 Section 2.2. -2.2.3. Yang Library Contents +2.3.3. Yang Library Contents After checking that the version of the yang-library module will be understood by the receiver, the client can check that the desired - metadata module is available on the DORMS server by fetching the + metadata modules are available on the DORMS server by fetching the module-state resource from the ietf-yang-library module. Example: The receiver might send: GET /top/restconf/data/ietf-yang-library:modules-state/\ module=ietf-dorms,2016-08-15 Host: dorms-restconf.example.com Accept: application/yang-data+json @@ -304,23 +432,27 @@ "namespace": "urn:ietf:params:xml:ns:yang:ietf-dorms", "revision": "2019-08-25", "schema": "https://example.com/yang/ietf-dorms@2019-08-25.yang" } ] } 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. + 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 + Section 2.2. -2.2.4. Metadata Retrieval +2.3.4. Metadata Retrieval Once the expected DORMS version is confirmed, the client can retrieve the metadata specific to the desired (S,G). Example: The receiver might send: GET /top/restconf/data/ietf-dorms:metadata/\ sender=203.0.113.15/group=232.1.1.1 @@ -351,45 +483,38 @@ 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 Section 3.2, 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. -2.2.5. Cross Origin Resource Sharing (CORS) +2.3.5. Cross Origin Resource Sharing (CORS) It is RECOMMENDED that DORMS servers use the Access-Control-Allow- - Origin header field, as specified by [W3C.REC-cors-20140116], and - that they respond appropriately to Preflight requests. + Origin header field, as specified by [whatwg-fetch], and that they + respond appropriately to Preflight requests. - Providing '*' for the allowed origins exposes the DORMS-based - metadata to all web pages. When access to the metadata is used as a - prerequisite to permitting the joining of the multicast flows, this - would permit scripts from arbitrary web pages to issue joins for the - multicast flows, which could allow e.g. malicious advertisements to - participate in overjoining attacks (see Appendix A of - [I-D.draft-jholland-cb-assisted-cc-01]) using multicast flows not - controlled by the ad's senders. Therefore the use of '*' for allowed - origins is NOT RECOMMENDED. (TBD: this probably deserves a security - considerations section.) + The use of '*' for allowed origins is NOT RECOMMENDED for DORMS + servers. A review of some of the potential consequences of + unrestricted CORS access is given in Section 7.5. 3. Scalability Considerations 3.1. 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, + 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 [RFC3040] or other online resources might be useful, depending on the expected number of receivers. @@ -400,68 +525,73 @@ Section 3.5.3 of [RFC8040] 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 MAY use heuristics or out of band information about the service to issue requests for (S,G) metadata narrowed only by the source-address, or not narrowed at all. 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. 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. + for scaling purposes in some scenarios. 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. 4. 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. Currently - known use cases include providing authentication information and bit- - rate information for use by receivers and middle boxes, but more use - cases are anticipated. + scaffold for the more useful metadata that will extend it. Example + specified use cases include providing authentication information + [I-D.draft-ietf-mboned-ambi-00] and bit-rate information + [I-D.draft-ietf-mboned-cbacc-00] for use by receivers and middle + boxes, but more use cases are anticipated. 4.1. Yang Tree + The tree diagram below follows the notation defined in [RFC8340]. + module: ietf-dorms +--rw metadata +--rw sender* [source-address] +--rw source-address inet:ip-address +--rw group* [group-address] +--rw group-address rt-types:ip-multicast-group-address +--rw udp-stream* [port] +--rw port inet:port-number DORMS Tree Diagram 4.2. Yang Module - file ietf-dorms@2020-03-10.yang + file ietf-dorms@2020-10-31.yang module ietf-dorms { yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:ietf-dorms"; prefix "dorms"; import ietf-inet-types { prefix "inet"; reference "RFC 6991 Section 4"; } import ietf-routing-types { prefix "rt-types"; reference "RFC 8294"; } - organization "IETF"; + organization "IETF MBONED (Multicast Backbone + Deployment) Working Group"; contact "Author: Jake Holland "; description "Copyright (c) 2019 IETF Trust and the persons identified as authors of the code. All rights reserved. @@ -481,22 +611,21 @@ '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 2019-08-25 { description "Initial revision."; reference - ""; - // "I-D.draft-jholland-mboned-dorms"; + "I-D.draft-ietf-mboned-dorms"; } container metadata { description "Metadata scaffold for source-specific multicast channels."; list sender { key source-address; description "Sender for DORMS"; leaf source-address { @@ -517,21 +646,21 @@ } 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 in an (S,G)."; + "The UDP port of a data stream."; } } } } } } 5. Privacy Considerations @@ -539,24 +668,24 @@ 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 [RFC3376] or MLD [RFC3810] channel - subscription to a specific user or location 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. + 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. 5.2. 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, @@ -574,102 +703,192 @@ 6.1. The YANG Module Names Registry This document adds one YANG module to the "YANG Module Names" registry maintained at . The following registrations are made, per the format in Section 14 of [RFC6020]: name: ietf-dorms namespace: urn:ietf:params:xml:ns:yang:ietf-dorms prefix: dorms - reference: I-D.draft-jholland-mboned-dorms + reference: I-D.draft-ietf-mboned-dorms -6.2. The Service Name and Transport Protocol Port Number Registry +6.2. The XML Registry + + This document adds the following registration to the "ns" subregistry + of the "IETF XML Registry" defined in [RFC3688], referencing this + document. + + URI: urn:ietf:params:xml:ns:yang:ietf-dorms + Registrant Contact: The IESG. + XML: N/A, the requested URI is an XML namespace. + +6.3. 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 . The following registrations are made, per the format in Section 8.1.1 of [RFC6335]: Service Name: dorms - Transport Protocol(s): TCP + Transport Protocol(s): TCP, UDP Assignee: IESG Contact: IETF Chair - Description: This service name is used to construct the - SRV service label "_dorms" for discovering - DORMS servers. - Reference: I-D.draft-jholland-mboned-dorms + 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: This protocol uses HTTPS as a substrate. + Assignment Notes: N/A 7. Security Considerations -7.1. Secure Communications +7.1. YANG Model Considerations - It is intended that security related metadata about the SSM channels - will be delivered over the RESTCONF connection, and that information - available from this connection can be used as a trust anchor. + The YANG module specified in this document defines a schema for data + that is designed to be accessed via RESTCONF [RFC8040]. The lowest + RESTCONF layer is HTTPS, and the mandatory-to-implement secure + transport is TLS [RFC8446]. - The provisions of Section 2 of [RFC8040] 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. + The Network Configuration Access Control Model (NACM) [RFC8341] + 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 MAY use NACM + to control access to data nodes. + + No data nodes defined in this YANG module are writable, creatable, or + deletable. This YANG module is intended for publication of read-only + data according to a well-defined schema. 7.2. Exposure of Metadata Although some DORMS servers MAY restrict access based on client identity, as described in Section 2.5 of [RFC8040], many DORMS servers will use the ietf-dorms YANG model to publish information without restriction, and even DORMS servers requiring client authentication will inherently, because of the purpose of DORMS, be providing the DORMS metadata to potentially many receivers. Accordingly, future YANG modules that augment data paths under "ietf- dorms:metadata" 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 it can be kept secret when provided by DORMS - servers anywhere under the "ietf-dorms:metadata" path, even if they - are authenticating clients. + public dissemination in those data paths. -7.3. DNS Bootstrapping + 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:metadata" 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. - The DNS bootstrap phase relies on DNS for the reverse IP tree. When - using DNS to discover a DORMS server's domain name, 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, a TSIG [RFC2845] or SIG(0) [RFC2931] channel to another - secure source, a secure local channel on the host, DNS over TLS - [RFC7858] or HTTPS [RFC8484], or some other secure mechanism. +7.3. Secure Communications - If the SRV Resource Record cannot be authenticated, it may be - possible for an attacker who can spoof the resource record to perform - a denial of service for the receiver by providing wrong or missing - authentication metadata. An attacker who can also inject traffic for - (S,G)s, would also be able to provide false content in the data - stream, so an attacker who can perform both could provide - authenticated false content by authenticating with a trust anchor - from an attacker-controlled DORMS server. + The provisions of Section 2 of [RFC8040] 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. + +7.4. Record-Spoofing + + When using the DNS Boostrap method of discovery described in + Section 2.1, the SRV resource record contains information that SHOULD + 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 DNS server + that provides end-to-end safety to prevent record-spoofing of the + response from the trusted server. The connection to the trusted + server can use any secure channel, such as with a TSIG [RFC2845] or + SIG(0) [RFC2931] channel, a secure local channel on the host, DNS + over TLS [RFC7858], DNS over HTTPS [RFC8484], or some other mechanism + that provides authentication of the 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. +7.5. CORS considerations + + As described in Section 2.3.5, it's 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 + [whatwg-fetch]. + + 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 [I-D.draft-ietf-mboned-ambi-00]), 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 + [I-D.draft-ietf-mboned-cbacc-00]). + + 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's 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. + 8. Acknowledgements - Thanks to Christian Worm Mortensen for some very helpful comments and - review. + Thanks to Christian Worm Mortensen, Dino Farinacci, and Lenny + Guiliano for their very helpful comments and reviews. 9. References 9.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . @@ -697,31 +916,44 @@ [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8294] Liu, X., Qu, Y., Lindem, A., Hopps, C., and L. Berger, "Common YANG Data Types for the Routing Area", RFC 8294, DOI 10.17487/RFC8294, December 2017, . - [W3C.REC-cors-20140116] - Kesteren, A., "Cross-Origin Resource Sharing", World Wide - Web Consortium Recommendation REC-cors-20140116, January - 2014, . + [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", + BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, + . + + [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration + Access Control Model", STD 91, RFC 8341, + DOI 10.17487/RFC8341, March 2018, + . + + [whatwg-fetch] + "WHATWG Fetch Living Standard", October 2020, + . 9.2. Informative References - [I-D.draft-jholland-cb-assisted-cc-01] - Holland, J., "Circuit Breaker Assisted Congestion Control - (CBACC): Protocol Specification", draft-jholland-cb- - assisted-cc-01 (work in progress), April 2017. + [I-D.draft-ietf-mboned-ambi-00] + Holland, J. and K. Rose, "Asymmetric Manifest Based + Integrity", draft-ietf-mboned-ambi-00 (work in progress), + March 2020. + + [I-D.draft-ietf-mboned-cbacc-00] + Holland, J., "Circuit Breaker Assisted Congestion + Control", draft-ietf-mboned-cbacc-00 (work in progress), + March 2020. [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, . [RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, November 1987, . [RFC2845] Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B. @@ -736,20 +968,24 @@ [RFC3040] Cooper, I., Melve, I., and G. Tomlinson, "Internet Web Replication and Caching Taxonomy", RFC 3040, DOI 10.17487/RFC3040, January 2001, . [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. Thyagarajan, "Internet Group Management Protocol, Version 3", RFC 3376, DOI 10.17487/RFC3376, October 2002, . + [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, + DOI 10.17487/RFC3688, January 2004, + . + [RFC3810] Vida, R., Ed. and L. Costa, Ed., "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", RFC 3810, DOI 10.17487/RFC3810, June 2004, . [RFC4604] Holbrook, H., Cain, B., and B. Haberman, "Using Internet Group Management Protocol Version 3 (IGMPv3) and Multicast Listener Discovery Protocol Version 2 (MLDv2) for Source- Specific Multicast", RFC 4604, DOI 10.17487/RFC4604, August 2006, . @@ -772,27 +1008,27 @@ [RFC6415] Hammer-Lahav, E., Ed. and B. Cook, "Web Host Metadata", RFC 6415, DOI 10.17487/RFC6415, October 2011, . [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., and P. Hoffman, "Specification for DNS over Transport Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 2016, . + [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol + Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, + . + [RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, . - [whatwg-fetch] - Kesteren, A., "WHATWG Fetch Living Standard", August 2019, - . - Author's Address Jake Holland Akamai Technologies, Inc. 150 Broadway Cambridge, MA 02144 United States of America Email: jakeholland.net@gmail.com