draft-ietf-mboned-dorms-01.txt   draft-ietf-mboned-dorms-02.txt 
Mboned J. Holland Mboned J. Holland
Internet-Draft Akamai Technologies, Inc. Internet-Draft Akamai Technologies, Inc.
Intended status: Standards Track October 30, 2020 Intended status: Standards Track July 10, 2021
Expires: May 3, 2021 Expires: January 11, 2022
Discovery Of Restconf Metadata for Source-specific multicast Discovery Of Restconf Metadata for Source-specific multicast
draft-ietf-mboned-dorms-01 draft-ietf-mboned-dorms-02
Abstract Abstract
This document defines DORMS (Discovery Of Restconf Metadata for This document defines DORMS (Discovery Of Restconf Metadata for
Source-specific multicast), a method to discover and retrieve Source-specific multicast), a method to discover and retrieve
extensible metadata about source-specific multicast channels using extensible metadata about source-specific multicast channels using
RESTCONF. The reverse IP DNS zone for a multicast sender's IP RESTCONF. The reverse IP DNS zone for a multicast sender's IP
address is configured to use SRV resource records to advertise the address is configured to use SRV resource records to advertise the
hostname of a RESTCONF server that publishes metadata according to a hostname of a RESTCONF server that publishes metadata according to a
new YANG module with support for extensions. A new service name and new YANG module with support for extensions. A new service name and
skipping to change at page 1, line 37 skipping to change at page 1, line 37
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on May 3, 2021. This Internet-Draft will expire on January 11, 2022.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Background . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Background . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
1.3. Motivation . . . . . . . . . . . . . . . . . . . . . . . 4 1.3. Motivation and Use Cases . . . . . . . . . . . . . . . . 4
1.3.1. Use cases . . . . . . . . . . . . . . . . . . . . . . 4 1.3.1. Provisioning and Oversubscription Protection . . . . 5
1.3.2. Channel Selection . . . . . . . . . . . . . . . . . . 5 1.3.2. Authentication . . . . . . . . . . . . . . . . . . . 5
1.4. Notes for Contributors and Reviewers . . . . . . . . . . 5 1.3.3. Content Description . . . . . . . . . . . . . . . . . 5
1.4.1. Venues for Contribution and Discussion . . . . . . . 5 1.4. Channel Discovery . . . . . . . . . . . . . . . . . . . . 5
1.4.2. Non-obvious doc choices . . . . . . . . . . . . . . . 6 1.5. Notes for Contributors and Reviewers . . . . . . . . . . 6
2. Discovery and Metdata Retrieval . . . . . . . . . . . . . . . 6 1.5.1. Venues for Contribution and Discussion . . . . . . . 6
2.1. DNS Bootstrap . . . . . . . . . . . . . . . . . . . . . . 6 1.5.2. Non-obvious doc choices . . . . . . . . . . . . . . . 6
2.2. Ignore List . . . . . . . . . . . . . . . . . . . . . . . 7 2. Discovery and Metdata Retrieval . . . . . . . . . . . . . . . 7
2.3. RESTCONF Bootstrap . . . . . . . . . . . . . . . . . . . 8 2.1. DNS Bootstrap . . . . . . . . . . . . . . . . . . . . . . 7
2.3.1. Root Resource Discovery . . . . . . . . . . . . . . . 8 2.2. Ignore List . . . . . . . . . . . . . . . . . . . . . . . 8
2.3.2. Yang Library Version . . . . . . . . . . . . . . . . 8 2.3. RESTCONF Bootstrap . . . . . . . . . . . . . . . . . . . 9
2.3.3. Yang Library Contents . . . . . . . . . . . . . . . . 9 2.3.1. Root Resource Discovery . . . . . . . . . . . . . . . 9
2.3.4. Metadata Retrieval . . . . . . . . . . . . . . . . . 10 2.3.2. Yang Library Version . . . . . . . . . . . . . . . . 10
2.3.5. Cross Origin Resource Sharing (CORS) . . . . . . . . 11 2.3.3. Yang Library Contents . . . . . . . . . . . . . . . . 10
3. Scalability Considerations . . . . . . . . . . . . . . . . . 11 2.3.4. Metadata Retrieval . . . . . . . . . . . . . . . . . 11
3.1. Provisioning . . . . . . . . . . . . . . . . . . . . . . 11 2.3.5. Cross Origin Resource Sharing (CORS) . . . . . . . . 12
3.2. Data Scoping . . . . . . . . . . . . . . . . . . . . . . 12 3. Scalability Considerations . . . . . . . . . . . . . . . . . 12
4. YANG Model . . . . . . . . . . . . . . . . . . . . . . . . . 12 3.1. Provisioning . . . . . . . . . . . . . . . . . . . . . . 12
4.1. Yang Tree . . . . . . . . . . . . . . . . . . . . . . . . 12 3.2. Data Scoping . . . . . . . . . . . . . . . . . . . . . . 13
4.2. Yang Module . . . . . . . . . . . . . . . . . . . . . . . 13 4. YANG Model . . . . . . . . . . . . . . . . . . . . . . . . . 13
5. Privacy Considerations . . . . . . . . . . . . . . . . . . . 15 4.1. Yang Tree . . . . . . . . . . . . . . . . . . . . . . . . 13
5.1. Linking Content to Traffic Streams . . . . . . . . . . . 15 4.2. Yang Module . . . . . . . . . . . . . . . . . . . . . . . 14
5.2. Linking Multicast Subscribers to Unicast Connections . . 15 5. Privacy Considerations . . . . . . . . . . . . . . . . . . . 16
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 5.1. Linking Content to Traffic Streams . . . . . . . . . . . 16
6.1. The YANG Module Names Registry . . . . . . . . . . . . . 16 5.2. Linking Multicast Subscribers to Unicast Connections . . 17
6.2. The XML Registry . . . . . . . . . . . . . . . . . . . . 16 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
6.1. The YANG Module Names Registry . . . . . . . . . . . . . 17
6.2. The XML Registry . . . . . . . . . . . . . . . . . . . . 17
6.3. The Service Name and Transport Protocol Port Number 6.3. The Service Name and Transport Protocol Port Number
Registry . . . . . . . . . . . . . . . . . . . . . . . . 16 Registry . . . . . . . . . . . . . . . . . . . . . . . . 18
7. Security Considerations . . . . . . . . . . . . . . . . . . . 17 7. Security Considerations . . . . . . . . . . . . . . . . . . . 18
7.1. YANG Model Considerations . . . . . . . . . . . . . . . . 17 7.1. YANG Model Considerations . . . . . . . . . . . . . . . . 18
7.2. Exposure of Metadata . . . . . . . . . . . . . . . . . . 17 7.2. Exposure of Metadata . . . . . . . . . . . . . . . . . . 19
7.3. Secure Communications . . . . . . . . . . . . . . . . . . 18 7.3. Secure Communications . . . . . . . . . . . . . . . . . . 20
7.4. Record-Spoofing . . . . . . . . . . . . . . . . . . . . . 18 7.4. Record-Spoofing . . . . . . . . . . . . . . . . . . . . . 20
7.5. CORS considerations . . . . . . . . . . . . . . . . . . . 19 7.5. CORS considerations . . . . . . . . . . . . . . . . . . . 21
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 22
9.1. Normative References . . . . . . . . . . . . . . . . . . 20 9.1. Normative References . . . . . . . . . . . . . . . . . . 22
9.2. Informative References . . . . . . . . . . . . . . . . . 21 9.2. Informative References . . . . . . . . . . . . . . . . . 23
9.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 23 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 25
1. Introduction 1. Introduction
This document defines DORMS (Discovery Of Restconf Metadata for This document defines DORMS (Discovery Of Restconf Metadata for
Source-specific multicast). Source-specific multicast).
A DORMS service is a RESTCONF [RFC8040] service that provides read A DORMS service is a RESTCONF [RFC8040] service that provides read
access to data in the "ietf-dorms" YANG [RFC7950] model defined in access to data in the "ietf-dorms" YANG [RFC7950] model defined in
Section 4. This model, along with optional extensions defined in Section 4. This model, along with optional extensions defined in
other documents, provide an extensible set of information about other documents, provide an extensible set of information about
multicast data streams. A review of some example use cases that can 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. be enabled by this kind of metadata is given in Section 1.3.
This document does not prohibit the use of the "ietf-dorms" model
with other protocols such as NETCONF [RFC6241], CORECONF
[I-D.draft-ietf-core-comi], or gNMI
[I-D.draft-openconfig-rtgwg-gnmi-spec], 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 This document defines the "dorms" service name for use with the SRV
DNS Resource Record (RR) type [RFC2782]. A sender using 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 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 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 IP used by some active multicast traffic. The domain name in one of
these SRV records provides a hostname corresponding to a DORMS server these SRV records provides a hostname corresponding to a DORMS server
that can provide metadata for the sender's source-specific multicast that can provide metadata for the sender's source-specific multicast
traffic. Publishing such a RR enables DORMS clients to discover and traffic. Publishing such a RR enables DORMS clients to discover and
query a DORMS server as described in Section 2. query a DORMS server as described in Section 2.
skipping to change at page 4, line 30 skipping to change at page 4, line 36
| | | | | |
| SSM | Source-specific multicast, as described in [RFC4607] | | SSM | Source-specific multicast, as described in [RFC4607] |
+--------+----------------------------------------------------------+ +--------+----------------------------------------------------------+
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
[RFC2119] and [RFC8174] when, and only when, they appear in all [RFC2119] and [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
1.3. Motivation 1.3. Motivation and Use Cases
DORMS provides a framework that can be extended to publish DORMS provides a framework that can be extended to publish
supplemental information about multicas traffic in a globally supplemental information about multicast traffic in a globally
discoverable manner. This is useful so that entities engaged in discoverable manner. This supplemental information is sometimes
delivery or processing of the traffic that are not affiliated with needed by entities engaged in delivery or processing of the traffic
the sender of the traffic and who may not otherwise have any means to to handle the traffic according to their requirements.
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 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.
For example, a network that is capable of forwarding multicast 1.3.1. Provisioning and Oversubscription Protection
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 One use case for DORMS is when a network that is capable of
the multicast traffic, metadata that describes the contents of the forwarding multicast traffic may need to take provisioning actions or
traffic, metadata that makes assertions about the legal status of the make admission control decisions based on the expected bitrate of the
traffic within specific contexts, or metadata that describes the traffic in order to prevent oversubscription of constrained devices
protocols or applications that can be used to consume the traffic. in the network. [I-D.draft-ietf-mboned-cbacc] defines some DORMS
Extensions to DORMS to support these or other kinds of metadata can extensions to support this use case.
be defined by later specifications.
Detailing the specific of the possible extensions is out of scope for 1.3.2. Authentication
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 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. [I-D.draft-ietf-mboned-ambi] defines some DORMS
extensions to support this use case.
In general, a DORMS client might learn of an (S,G) by any means. 1.3.3. Content Description
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 Another use case for DORMS is describing the contents carried by a
a DORMS client might learn about an (S,G) by getting signals from multicast traffic channel. The content description could include
inside the application logic, such as a selection made by a user, or information about the protocols or applications that can be used to
a scheduled API call that reacts to updates in a library provided by consume the traffic, or information about the media carried (e.g.
a service operator. information based on the Dublin Core Metadata Element Set [RFC5013]),
or could make assertions about the legal status of the traffic within
specific contexts.
1.4. 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 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 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 MLD membership report indicating a downstream client has tried to
subscribe to an (S,G). Such a router might use information learned subscribe to an (S,G). Such a router might use information learned
from the DORMS metadata to make an access control decision about from the DORMS metadata to make an access control decision about
whether to propagate the join futher upstream in the network. whether to propagate the join futher upstream in the network.
Other approaches for learning an (S,G) could be driven by monitoring Other approaches for learning relevant (S,G)s could be driven by
a route reflector to discover channels that are being actively monitoring a route reflector to discover channels that are being
forwarded, for a purpose such as monitoring network health. actively forwarded, for a purpose such as monitoring network health.
1.4. Notes for Contributors and Reviewers 1.5. Notes for Contributors and Reviewers
Note to RFC Editor: Please remove this section and its subsections Note to RFC Editor: Please remove this section and its subsections
before publication. before publication.
This section is to provide references to make it easier to review the This section is to provide references to make it easier to review the
development and discussion on the draft so far. development and discussion on the draft so far.
1.4.1. Venues for Contribution and Discussion 1.5.1. Venues for Contribution and Discussion
This document is in the Github repository at: This document is in the Github repository at:
https://github.com/GrumpyOldTroll/ietf-dorms-cluster https://github.com/GrumpyOldTroll/ietf-dorms-cluster
Readers are welcome to open issues and send pull requests for this Readers are welcome to open issues and send pull requests for this
document. document.
Please note that contributions may be merged and substantially Please note that contributions may be merged and substantially
edited, and as a reminder, please carefully consider the Note Well edited, and as a reminder, please carefully consider the Note Well
before contributing: https://datatracker.ietf.org/submit/note-well/ before contributing: https://datatracker.ietf.org/submit/note-well/
Substantial discussion of this document should take place on the Substantial discussion of this document should take place on the
MBONED working group mailing list (mboned@ietf.org). MBONED working group mailing list (mboned@ietf.org).
skipping to change at page 6, line 18 skipping to change at page 6, line 37
edited, and as a reminder, please carefully consider the Note Well edited, and as a reminder, please carefully consider the Note Well
before contributing: https://datatracker.ietf.org/submit/note-well/ before contributing: https://datatracker.ietf.org/submit/note-well/
Substantial discussion of this document should take place on the Substantial discussion of this document should take place on the
MBONED working group mailing list (mboned@ietf.org). MBONED working group mailing list (mboned@ietf.org).
o Join: https://www.ietf.org/mailman/listinfo/mboned o Join: https://www.ietf.org/mailman/listinfo/mboned
o Search: https://mailarchive.ietf.org/arch/browse/mboned/ o Search: https://mailarchive.ietf.org/arch/browse/mboned/
1.4.2. Non-obvious doc choices 1.5.2. Non-obvious doc choices
Log of odd things that need to be the way they are because of some 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. reason that the author or reviewers may want to know later.
o building the draft without this line produces a warning about no o building the draft without this line produces a warning about no
reference to [RFC6991] or [RFC8294], but these are imported in the reference to [RFC6991] or [RFC8294], but these are imported in the
yang model. RFC 8407 requires the normative reference to 8294 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 (there's an exception for 6991 but I'm not sure why and it doesn't
seem forbidden). seem forbidden).
o Although it's non-normative, I chose the boundaries in the
recommendation for default setting of DNS expiry time in
Section 2.2 based on the best practices advice at
https://www.varonis.com/blog/dns-ttl/ for "Short" and "Long"
times.
o Section 7.1 is intended to be the template from
https://trac.ietf.org/trac/ops/wiki/yang-security-guidelines [1],
as required by https://datatracker.ietf.org/doc/html/
rfc8407#section-3.7 [2]. Individual nodes are not listed because
blanket statements in that section covere them.
o The 'must' constraint in the group list seems awkward, but seems
to work. Its intent is to require source & group to be either
both IPv4 or both IPv6, without mixing & matching. It requires
that either both the group address and its source parent's address
must contain a colon or both must NOT contain a colon, where
presence of a colon is used to distinguish IPv4 from IPv6. Maybe
there's a better way?
2. Discovery and Metdata Retrieval 2. Discovery and Metdata Retrieval
A client that needs metadata about an (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 metadata for the (S,G) using the mechanisms defined here, and MAY use
the metadata received to manage the forwarding or processing of the the metadata received to manage the forwarding or processing of the
packets in the channel. packets in the channel.
2.1. DNS Bootstrap 2.1. DNS Bootstrap
The DNS Bootstrap step is how a client discovers an appropriate The DNS Bootstrap step is how a client discovers an appropriate
RESTCONF server, given the source address of an (S,G). Use of the RESTCONF server, given the source address of an (S,G). Use of the
DNS Bootstrap is OPTIONAL for clients with an alternate method of DNS Bootstrap is OPTIONAL for clients with an alternate method of
obtaining a hostname of a trusted DORMS server with information about obtaining a hostname of a trusted DORMS server that has information
the target (S,G). about a target (S,G).
This mechanism only works for source-specific multicast (SSM) This mechanism only works for source-specific multicast (SSM)
channels. The source address of the (S,G) is reversed and used as an 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, 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 as described in Section 3.5 of [RFC1035], or ip6.arpa for IPv6, as
described in Section 2.5 of [RFC3596]). described in Section 2.5 of [RFC3596]).
When a DORMS client needs metadata for an (S,G), for example when 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 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 methods that are available, the DORMS client can issue a DNS query
query for a SRV RR using the "dorms" service name with the domain for a SRV RR using the "dorms" service name with the domain from the
from the reverse mapping tree, combining them as described in reverse mapping tree, combining them as described in [RFC2782].
[RFC2782].
For example, while handling a join for (203.0.113.15, 232.1.1.1), a For example, a client looking for metadata about the channel with a
receiver would perform a DNS query for the SRV RRType for the domain: 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):
_dorms._tcp.15.113.0.203.in-addr.arpa. _dorms._tcp.a.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.
0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa.
The DNS response for this domain might return a record such as: Or for an IPv4 (S,G) with a source address of 203.0.113.4 and a group
address of 232.1.1.1, the DORMS client would request the SRV record
from the in-addr.arpa tree instead:
_dorms._tcp.4.113.0.203.in-addr.arpa.
In either case, the DNS response for this domain might return a
record such as this:
SRV 0 1 443 dorms-restconf.example.com. SRV 0 1 443 dorms-restconf.example.com.
This response informs the receiver that a DORMS server should be This response informs the client that a DORMS server should be
reachable at dorms-restconf.example.com on port 443, and should reachable at dorms-restconf.example.com on port 443, and should
contain metadata about multicast traffic from the given source IP. contain metadata about multicast traffic from the given source IP.
Multiple SRV records are handled as described by [RFC2782]. Multiple SRV records are handled as described by [RFC2782].
A sender providing DORMS discovery SHOULD publish at least one SRV A sender providing DORMS discovery SHOULD publish at least one SRV
record in the reverse DNS zone for each source address of the record in the reverse DNS zone for each source address of the
multicast channels it is sending in order to advertise the hostname multicast channels it is sending in order to advertise the hostname
of the DORMS server to DORMS clients. The DORMS servers advertised of the DORMS server to DORMS clients. The DORMS servers advertised
SHOULD be configured with metadata for all the groups sent from the SHOULD be configured with metadata for all the groups sent from the
same source IP address that have metadata published with DORMS. 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 [RFC2317].
2.2. Ignore List 2.2. Ignore List
If a DORMS client reaches a DORMS server but determines through If a DORMS client reaches a DORMS server but determines through
examination of responses from that DORMS server that it may not examination of responses from that DORMS server that it may not
understand or be able to use the responses of the server (for example 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 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 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 this server to an ignore list and reject servers in its ignore list
during future discovery attempts. during future discovery attempts.
skipping to change at page 7, line 47 skipping to change at page 9, line 4
this server to an ignore list and reject servers in its ignore list this server to an ignore list and reject servers in its ignore list
during future discovery attempts. during future discovery attempts.
A client using the DNS Bootstrap discovery method in Section 2.1 A client using the DNS Bootstrap discovery method in Section 2.1
would treat servers in its ignore list as unreachable for the would treat servers in its ignore list as unreachable for the
purposes of processing the SRV RR as described in [RFC2782]. (For purposes of processing the SRV RR as described in [RFC2782]. (For
example, a client might end up selecting a server with a less- example, a client might end up selecting a server with a less-
preferred priority than servers in its ignore list, even if an HTTPS preferred priority than servers in its ignore list, even if an HTTPS
connection could have been formed successfully with some of those connection could have been formed successfully with some of those
servers.) servers.)
If an ignore list is maintained, entries SHOULD time out and allow If an ignore list is maintained, entries SHOULD time out and allow
for re-checking after either the cache expiration time from the for re-checking after either the cache expiration time from the DNS
response that caused the server to be added to the ignore list, or 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 for a configurable hold-down time that has a default value no shorter
than an hour and no longer than 3 days. than 1 hour and no longer than 24 hours.
2.3. RESTCONF Bootstrap 2.3. RESTCONF Bootstrap
Once a DORMS host has been chosen (whether via an SRV RR from a DNS 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 response or via some other method), RESTCONF provides all the
information necessary to determine the versions and url paths for information necessary to determine the versions and url paths for
metadata from the server. A walkthrough is provided here for a metadata from the server. A walkthrough is provided here for a
sequence of example requests and responses from a receiver connecting sequence of example requests and responses from a receiver connecting
to a new DORMS server. to a new DORMS server.
2.3.1. Root Resource Discovery 2.3.1. Root Resource Discovery
As described in Section 3.1 of [RFC8040] and [RFC6415], the RESTCONF As described in Section 3.1 of [RFC8040] and [RFC6415], the RESTCONF
server provides the link to the RESTCONF api entry point via the server provides the link to the RESTCONF api entry point via the
skipping to change at page 8, line 33 skipping to change at page 9, line 36
The receiver might send: The receiver might send:
GET /.well-known/host-meta.json HTTP/1.1 GET /.well-known/host-meta.json HTTP/1.1
Host: dorms-restconf.example.com Host: dorms-restconf.example.com
Accept: application/json Accept: application/json
The server might respond as follows: The server might respond as follows:
HTTP/1.1 200 OK HTTP/1.1 200 OK
Date: Tue, 27 Aug 2019 20:56:00 GMT Date: Tue, 09 Jul 2021 20:56:00 GMT
Server: example-server Server: example-server
Cache-Control: no-cache Cache-Control: no-cache
Content-Type: application/json Content-Type: application/json
{ {
"links":[ "links":[
{ {
"rel":"restconf", "rel":"restconf",
"href":"/top/restconf" "href":"/top/restconf"
} }
skipping to change at page 9, line 16 skipping to change at page 10, line 22
The receiver might send: The receiver might send:
GET /top/restconf/yang-library-version HTTP/1.1 GET /top/restconf/yang-library-version HTTP/1.1
Host: dorms-restconf.example.com Host: dorms-restconf.example.com
Accept: application/yang-data+json Accept: application/yang-data+json
The server might respond as follows: The server might respond as follows:
HTTP/1.1 200 OK HTTP/1.1 200 OK
Date: Tue, 27 Aug 2019 20:56:01 GMT Date: Tue, 09 Jul 2021 20:56:01 GMT
Server: example-server Server: example-server
Cache-Control: no-cache Cache-Control: no-cache
Content-Type: application/yang-data+json Content-Type: application/yang-data+json
{ {
"ietf-restconf:yang-library-version": "2016-06-21" "ietf-restconf:yang-library-version": "2016-06-21"
} }
If a DORMS client determines through examination of the yang-library- If a DORMS client determines through examination of the yang-library-
version that it may not understand the responses of the server due to version that it may not understand the responses of the server due to
skipping to change at page 9, line 42 skipping to change at page 10, line 48
After checking that the version of the yang-library module will be After checking that the version of the yang-library module will be
understood by the receiver, the client can check that the desired understood by the receiver, the client can check that the desired
metadata modules are 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. module-state resource from the ietf-yang-library module.
Example: Example:
The receiver might send: The receiver might send:
GET /top/restconf/data/ietf-yang-library:modules-state/\ GET /top/restconf/data/ietf-yang-library:modules-state/\
module=ietf-dorms,2016-08-15 module=ietf-dorms,2021-07-08
Host: dorms-restconf.example.com Host: dorms-restconf.example.com
Accept: application/yang-data+json Accept: application/yang-data+json
The server might respond as follows: The server might respond as follows:
HTTP/1.1 200 OK HTTP/1.1 200 OK
Date: Tue, 27 Aug 2019 20:56:02 GMT Date: Tue, 09 Jul 2021 20:56:02 GMT
Server: example-server Server: example-server
Cache-Control: no-cache Cache-Control: no-cache
Content-Type: application/yang-data+json Content-Type: application/yang-data+json
{ {
"ietf-yang-library:module": [ "ietf-yang-library:module": [
{ {
"conformance-type": "implement", "conformance-type": "implement",
"name": "ietf-dorms", "name": "ietf-dorms",
"namespace": "urn:ietf:params:xml:ns:yang:ietf-dorms", "namespace": "urn:ietf:params:xml:ns:yang:ietf-dorms",
"revision": "2019-08-25", "revision": "2021-07-08",
"schema": "schema":
"https://example.com/yang/ietf-dorms@2019-08-25.yang" "https://example.com/yang/ietf-dorms@2021-07-08.yang"
} }
] ]
} }
Other modules required or desired by the client also can be checked 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 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 retrieved by not providing a key for the "module" list. If a DORMS
client that requires the presence of certain modules to perform its client that requires the presence of certain modules to perform its
function discovers the required modules are not present on a server, function discovers the required modules are not present on a server,
that server qualifies for inclusion in an ignore list according to that server qualifies for inclusion in an ignore list according to
skipping to change at page 10, line 41 skipping to change at page 11, line 41
2.3.4. Metadata Retrieval 2.3.4. Metadata Retrieval
Once the expected DORMS version is confirmed, the client can retrieve Once the expected DORMS version is confirmed, the client can retrieve
the metadata specific to the desired (S,G). the metadata specific to the desired (S,G).
Example: Example:
The receiver might send: The receiver might send:
GET /top/restconf/data/ietf-dorms:metadata/\ GET /top/restconf/data/ietf-dorms:dorms/metadata/\
sender=203.0.113.15/group=232.1.1.1 sender=2001:db8::a/group=ff3e::8000:1
Host: dorms-restconf.example.com Host: dorms-restconf.example.com
Accept: application/yang-data+json Accept: application/yang-data+json
The server might respond as follows: The server might respond as follows:
HTTP/1.1 200 OK HTTP/1.1 200 OK
Date: Tue, 27 Aug 2019 20:56:02 GMT Date: Tue, 09 Jul 2021 20:56:02 GMT
Server: example-server Server: example-server
Cache-Control: no-cache Cache-Control: no-cache
Content-Type: application/yang-data+json Content-Type: application/yang-data+json
{ {
"ietf-dorms:group": [ "ietf-dorms:group": [
{ {
"group-address":"232.1.1.1", "group-address":"ff3e::8000:1",
"udp-stream":[ "udp-stream":[
{ {
"port":"5001" "port":"5001"
} }
] ]
} }
] ]
} }
Note that when other modules are installed on the DORMS server that Note that when other modules are installed on the DORMS server that
skipping to change at page 11, line 40 skipping to change at page 12, line 40
As mentioned in Section 3.2, most clients SHOULD use data resource 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 identifiers in the request URI as in the above example, in order to
retrieve metadata for only the targeted (S,G)s. retrieve metadata for only the targeted (S,G)s.
2.3.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- It is RECOMMENDED that DORMS servers use the Access-Control-Allow-
Origin header field, as specified by [whatwg-fetch], and that they Origin header field, as specified by [whatwg-fetch], and that they
respond appropriately to Preflight requests. respond appropriately to Preflight requests.
The use of '*' for allowed origins is NOT RECOMMENDED for DORMS The use of '*' for allowed origins is NOT RECOMMENDED for publicly
servers. A review of some of the potential consequences of reachable DORMS servers. A review of some of the potential
unrestricted CORS access is given in Section 7.5. consequences of unrestricted CORS access is given in Section 7.5.
3. Scalability Considerations 3. Scalability Considerations
3.1. Provisioning 3.1. Provisioning
In contrast to many common RESTCONF deployments that are intended to In contrast to many common RESTCONF deployments that are intended to
provide configuration management for a service to a narrow set of provide configuration management for a service to a narrow set of
authenticated administrators, DORMS servers often provide read-only 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 since it provides metadata in support of multicast data streams and
skipping to change at page 12, line 16 skipping to change at page 13, line 16
Operators are advised to provision the DORMS service in a way that Operators are advised to provision the DORMS service in a way that
will scale appropriately to the size of the expected audience. will scale appropriately to the size of the expected audience.
Specific advice on such scaling is out of scope for this document, Specific advice on such scaling is out of scope for this document,
but some of the mechanisms outlined in [RFC3040] or other online but some of the mechanisms outlined in [RFC3040] or other online
resources might be useful, depending on the expected number of resources might be useful, depending on the expected number of
receivers. receivers.
3.2. Data Scoping 3.2. Data Scoping
In the absence of contextual information, clients SHOULD issue Except as outlined below, clients SHOULD issue narrowed requests for
narrowed requests for DORMS resources by following the format from DORMS resources by following the format from Section 3.5.3 of
Section 3.5.3 of [RFC8040] to encode data resource identifiers in the [RFC8040] to encode data resource identifiers in the request URI.
request URI. This avoids downloading excessive data, since the DORMS This avoids downloading excessive data, since the DORMS server may
server may provide metadata for many (S,G)s, possibly from many provide metadata for many (S,G)s, possibly from many different
different senders. senders.
However, clients MAY use heuristics or out of band information about However, clients with out of band knowledge about the scope of the
the service to issue requests for (S,G) metadata narrowed only by the expected contents MAY issue requests for (S,G) metadata narrowed only
source-address, or not narrowed at all. Depending on the request by the source-address, or not narrowed at all. Depending on the
patterns and the contents of the data store, this may result in fewer request patterns and the contents of the data store, this may result
round trips or less overhead, and can therefore be helpful behavior in fewer round trips or less overhead, and can therefore be helpful
for scaling purposes in some scenarios. Servers MAY restrict or behavior for scaling purposes in some scenarios. In general,
throttle client access based on the client certificate presented (if engaging in this behavior requires some administrative configuration
any), or based on heuristics that take note of client request or some optimization heuristics that can recover from unexpected
patterns. 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 A complete description of the heuristics for clients and servers to
meet their scalability goals is out of scope for this document. meet their scalability goals is out of scope for this document.
4. YANG Model 4. YANG Model
The primary purpose of the YANG model defined here is to serve as a The primary purpose of the YANG model defined here is to serve as a
scaffold for the more useful metadata that will extend it. Example scaffold for the more useful metadata that will extend it. See
specified use cases include providing authentication information Section 1.3 for some example use cases that can be enabled by the use
[I-D.draft-ietf-mboned-ambi-00] and bit-rate information of DORMS extensions.
[I-D.draft-ietf-mboned-cbacc-00] for use by receivers and middle
boxes, but more use cases are anticipated.
4.1. Yang Tree 4.1. Yang Tree
The tree diagram below follows the notation defined in [RFC8340]. The tree diagram below follows the notation defined in [RFC8340].
module: ietf-dorms module: ietf-dorms
+--rw metadata +--rw dorms
+--rw sender* [source-address] +--rw metadata
+--rw source-address inet:ip-address +--rw sender* [source-address]
+--rw group* [group-address] +--rw source-address inet:ip-address
+--rw group-address rt-types:ip-multicast-group-address +--rw group* [group-address]
+--rw udp-stream* [port] +--rw group-address
+--rw port inet:port-number | rt-types:ip-multicast-group-address
+--rw udp-stream* [port]
+--rw port inet:port-number
DORMS Tree Diagram DORMS Tree Diagram
4.2. Yang Module 4.2. Yang Module
<CODE BEGINS> file ietf-dorms@2020-10-31.yang <CODE BEGINS> file ietf-dorms@2021-07-11.yang
module ietf-dorms { module ietf-dorms {
yang-version 1.1; yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-dorms"; namespace "urn:ietf:params:xml:ns:yang:ietf-dorms";
prefix "dorms"; prefix "dorms";
import ietf-inet-types { import ietf-inet-types {
prefix "inet"; prefix "inet";
reference "RFC 6991 Section 4"; reference "RFC 6991 Section 4";
} }
import ietf-routing-types { import ietf-routing-types {
prefix "rt-types"; prefix "rt-types";
reference "RFC 8294"; reference "RFC 8294";
} }
organization "IETF MBONED (Multicast Backbone organization "IETF MBONED (Multicast Backbone
Deployment) Working Group"; Deployment) Working Group";
contact contact
"Author: Jake Holland "Author: Jake Holland
<mailto:jholland@akamai.com> <mailto:jholland@akamai.com>
"; ";
description description
"Copyright (c) 2019 IETF Trust and the persons identified as "Copyright (c) 2019 IETF Trust and the persons identified as
authors of the code. All rights reserved. authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject to without modification, is permitted pursuant to, and subject to
the license terms contained in, the Simplified BSD License set the license terms contained in, the Simplified BSD License set
forth in Section 4.c of the IETF Trust's Legal Provisions forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents Relating to IETF Documents
(https://trustee.ietf.org/license-info). (https://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC XXXX This version of this YANG module is part of RFC XXXX
(https://www.rfc-editor.org/info/rfcXXXX); see the RFC itself (https://www.rfc-editor.org/info/rfcXXXX); see the RFC itself
for full legal notices. for full legal notices.
The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL
NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED', NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED',
'MAY', and 'OPTIONAL' in this document are to be interpreted as 'MAY', and 'OPTIONAL' in this document are to be interpreted as
described in BCP 14 (RFC 2119) (RFC 8174) when, and only when, described in BCP 14 (RFC 2119) (RFC 8174) when, and only when,
they appear in all capitals, as shown here. they appear in all capitals, as shown here.
This module contains the definition for the DORMS data type. This module contains the definition for the DORMS data type.
It provides out of band metadata about SSM channels."; It provides out of band metadata about SSM channels.";
revision 2019-08-25 { revision 2021-07-08 {
description "Initial revision."; description "Draft version, post-early-review.";
reference reference
"I-D.draft-ietf-mboned-dorms"; "draft-ietf-mboned-dorms";
} }
container dorms {
description "Top-level DORMS container.";
container metadata { container metadata {
description "Metadata scaffold for source-specific multicast description "Metadata scaffold for source-specific multicast
channels."; channels.";
list sender { list sender {
key source-address; key source-address;
description "Sender for DORMS"; description "Sender for DORMS";
leaf source-address { leaf source-address {
type inet:ip-address; type inet:ip-address;
mandatory true; mandatory true;
description description
"The source IP address of a multicast sender."; "The source IP address of a multicast sender.";
} }
list group { list group {
key group-address; key group-address;
description "Metadata for a DORMS (S,G)."; description "Metadata for a DORMS (S,G).";
leaf group-address { leaf group-address {
type rt-types:ip-multicast-group-address; type rt-types:ip-multicast-group-address;
mandatory true; mandatory true;
description "The group IP address for an (S,G)."; 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 { list udp-stream {
key "port"; key "port";
description description
"Metadata for UDP traffic on a specific port."; "Metadata for UDP traffic on a specific port.";
leaf port { leaf port {
type inet:port-number; type inet:port-number;
mandatory true; mandatory true;
description description
"The UDP port of a data stream."; "The UDP port of a data stream.";
}
}
} }
}
} }
}
} }
}
} }
<CODE ENDS> <CODE ENDS>
5. Privacy Considerations 5. Privacy Considerations
5.1. Linking Content to Traffic Streams 5.1. Linking Content to Traffic Streams
In the typical case, the mechanisms defined in this document provide In the typical case, the mechanisms defined in this document provide
a standardized way to discover information that is already available a standardized way to discover information that is already available
in other ways. in other ways.
skipping to change at page 15, line 46 skipping to change at page 17, line 15
5.2. Linking Multicast Subscribers to Unicast Connections 5.2. Linking Multicast Subscribers to Unicast Connections
Subscription to a multicast channel generally only exposes the IGMP Subscription to a multicast channel generally only exposes the IGMP
or MLD membership report to others on the same LAN, and as the or MLD membership report to others on the same LAN, and as the
membership propagates through a multicast-capable network, it membership propagates through a multicast-capable network, it
ordinarily gets aggregated with other end users. ordinarily gets aggregated with other end users.
However, a RESTCONF connection is a unicast connection, and exposes a However, a RESTCONF connection is a unicast connection, and exposes a
different set of information to the operator of the RESTCONF server, different set of information to the operator of the RESTCONF server,
including IP address and timing about the requests made. Where DORMS including IP address and timing about the requests made. Where DORMS
access becomes required to succeed a multicast join, as expected in a access becomes required to succeed a multicast join (for example, as
browser deployment, this can expose new information about end users expected in a browser deployment), this can expose new information
relative to services based solely on multicast streams. 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.
In some deployments it may be possible to use a proxy that aggregates In some deployments it may be possible to use a proxy that aggregates
many end users when the aggregate privacy characteristics are needed many end users when the aggregate privacy characteristics are needed
by end users. by end users.
6. IANA Considerations 6. IANA Considerations
6.1. The YANG Module Names Registry 6.1. The YANG Module Names Registry
This document adds one YANG module to the "YANG Module Names" This document adds one YANG module to the "YANG Module Names"
skipping to change at page 17, line 14 skipping to change at page 18, line 34
7. Security Considerations 7. Security Considerations
7.1. YANG Model Considerations 7.1. YANG Model Considerations
The YANG module specified in this document defines a schema for data The YANG module specified in this document defines a schema for data
that is designed to be accessed via RESTCONF [RFC8040]. The lowest that is designed to be accessed via RESTCONF [RFC8040]. The lowest
RESTCONF layer is HTTPS, and the mandatory-to-implement secure RESTCONF layer is HTTPS, and the mandatory-to-implement secure
transport is TLS [RFC8446]. transport is TLS [RFC8446].
DORMS servers MUST constrain write access to ensure that unauthorized
users cannot edit the data published by the server. Unauthorized
editing of any data nodes or any extensions to data nodes could
result in a denial of service for end users.
The Network Configuration Access Control Model (NACM) [RFC8341] The Network Configuration Access Control Model (NACM) [RFC8341]
provides the means to restrict access for particular NETCONF or provides the means to restrict access for particular NETCONF or
RESTCONF users to a preconfigured subset of all available NETCONF or RESTCONF users to a preconfigured subset of all available NETCONF or
RESTCONF protocol operations and content. DORMS servers MAY use NACM RESTCONF protocol operations and content. DORMS servers MAY use NACM
to control access to data nodes. to constrain write accesses.
No data nodes defined in this YANG module are writable, creatable, or However, note that scalability considerations described in
deletable. This YANG module is intended for publication of read-only Section 3.1 might make the naive use of NACM intractable in many
data according to a well-defined schema. deployments. 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 might require the trusted writers of configuration
to use an alternate method of accessing the underlying database such
as connecting directly to the origin, or requiring the use of a non-
RESTCONF mechanism 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 many deployments it's
expected that DORMS clients will generally have read-only access.
For the reasons and requirements described in Section 7.2, 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 [RFC8040] read-only access to
publicly available data MAY be treated as unprotected resources.
However, DORMS servers MUST authenticate clients in order to provide
write access.
7.2. Exposure of Metadata 7.2. Exposure of Metadata
Although some DORMS servers MAY restrict access based on client Although some DORMS servers MAY restrict access based on client
identity, as described in Section 2.5 of [RFC8040], many DORMS identity, as described in Section 2.5 of [RFC8040], many DORMS
servers will use the ietf-dorms YANG model to publish information servers will use the ietf-dorms YANG model to publish information
without restriction, and even DORMS servers requiring client without restriction, and even DORMS servers requiring client
authentication will inherently, because of the purpose of DORMS, be authentication will inherently, because of the purpose of DORMS, be
providing the DORMS metadata to potentially many receivers. providing the DORMS metadata to potentially many receivers.
Accordingly, future YANG modules that augment data paths under "ietf- Accordingly, future YANG modules that augment data paths under "ietf-
dorms:metadata" MUST NOT include any sensitive data unsuitable for dorms:dorms" MUST NOT include any sensitive data unsuitable for
public dissemination in those data paths. public dissemination in those data paths.
Because of the possibility that scalable read-only access might be Because of the possibility that scalable read-only access might be
necessary to fulfill the scalability goals for a DORMS server, data necessary to fulfill the scalability goals for a DORMS server, data
under these paths MAY be cached or replicated by numerous external under these paths MAY be cached or replicated by numerous external
entities, so owners of such data SHOULD NOT assume such data can be entities, so owners of such data SHOULD NOT assume such data can be
kept secret when provided by DORMS servers anywhere under the "ietf- kept secret when provided by DORMS servers anywhere under the "ietf-
dorms:metadata" path even if access controls are used with dorms:dorms" path even if access controls are used with authenticated
authenticated clients unless additional operational procedures and clients unless additional operational procedures and restrictions are
restrictions are defined and implemented that can effectively control defined and implemented that can effectively control the
the dissemination of the secret data. DORMS alone does not provide dissemination of the secret data. DORMS alone does not provide any
any such mechanisms, and users of DORMS can be expected not to be such mechanisms, and users of DORMS can be expected not to be
following any such mechanisms in the absence of additional following any such mechanisms in the absence of additional
assurances. assurances.
7.3. Secure Communications 7.3. Secure Communications
The provisions of Section 2 of [RFC8040] provide secure communication The provisions of Section 2 of [RFC8040] provide secure communication
requirements that are already required of DORMS servers, since they requirements that are already required of DORMS servers, since they
are RESTCONF servers. All RESTCONF requirements and security are RESTCONF servers. All RESTCONF requirements and security
considerations remain in force for DORMS servers. considerations remain in force for DORMS servers.
skipping to change at page 19, line 19 skipping to change at page 21, line 19
access metadata for their (S,G)s from the widely deployed base of access metadata for their (S,G)s from the widely deployed base of
secure browsers that use the CORS protocol according to secure browsers that use the CORS protocol according to
[whatwg-fetch]. [whatwg-fetch].
Providing '*' for the allowed origins exposes the DORMS-based Providing '*' for the allowed origins exposes the DORMS-based
metadata to access by scripts in all web pages, which opens the metadata to access by scripts in all web pages, which opens the
possibility of certain kinds of attacks against networks where possibility of certain kinds of attacks against networks where
browsers have support for joining multicast (S,G)s. browsers have support for joining multicast (S,G)s.
If the authentication for an (S,G) relies on DORMS-based metadata 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 (for example, as defined in [I-D.draft-ietf-mboned-ambi]), an
unauthorized web page that tries to join an (S,G) not permitted by unauthorized web page that tries to join an (S,G) not permitted by
the CORS headers for the DORMS server will be prevented from the CORS headers for the DORMS server will be prevented from
subscribing to the channels. subscribing to the channels.
If an unauthorized site is not prevented from subscribing, code on If an unauthorized site is not prevented from subscribing, code on
the site (for example a malicious advertisement) could request the site (for example a malicious advertisement) could request
subscriptions from many different (S,G)s, overflowing limits on the subscriptions from many different (S,G)s, overflowing limits on the
joining of (S,G)s and disrupting the delivery of multicast traffic joining of (S,G)s and disrupting the delivery of multicast traffic
for legitimate use. for legitimate use.
Further, if the malicious script can be distributed to many different Further, if the malicious script can be distributed to many different
users within the same receiving network, the script could coordinate users within the same receiving network, the script could coordinate
an attack against the network as a whole by joining disjoint sets of an attack against the network as a whole by joining disjoint sets of
(S,G)s from different users within the receiving network. The (S,G)s from different users within the receiving network. The
distributed subscription requests across the receiving network could distributed subscription requests across the receiving network could
overflow limits for the receiving network as a whole, essentially overflow limits for the receiving network as a whole, essentially
causing the websites displaying the ad to participate in an causing the websites displaying the ad to participate in an
overjoining attack (see Appendix A of overjoining attack (see Appendix A of [I-D.draft-ietf-mboned-cbacc]).
[I-D.draft-ietf-mboned-cbacc-00]).
Even if network safety mechanisms protect the network from the worst Even if network safety mechanisms protect the network from the worst
effects of oversubscription, the population counts for the multicast effects of oversubscription, the population counts for the multicast
subscriptions could be disrupted by this kind of attack, and subscriptions could be disrupted by this kind of attack, and
therefore push out legitimately requested traffic that's being therefore push out legitimately requested traffic that's being
consumed by real users. For a legitimately popular event, this could consumed by real users. For a legitimately popular event, this could
cause a widespread disruption to the service if it's successfully cause a widespread disruption to the service if it's successfully
pushed out. pushed out.
A denial of service attack of this sort would be thwarted by A denial of service attack of this sort would be thwarted by
restricting the access to (S,G)s to authorized websites through the restricting the access to (S,G)s to authorized websites through the
use of properly restricted CORS headers. use of properly restricted CORS headers.
8. Acknowledgements 8. Acknowledgements
Thanks to Christian Worm Mortensen, Dino Farinacci, and Lenny Thanks to Christian Worm Mortensen, Dino Farinacci, Lenny Guiliano,
Guiliano for their very helpful comments and reviews. and Reshad Rahman for their very helpful comments and reviews.
9. References 9. References
9.1. Normative References 9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC2317] Eidnes, H., de Groot, G., and P. Vixie, "Classless IN-
ADDR.ARPA delegation", BCP 20, RFC 2317,
DOI 10.17487/RFC2317, March 1998,
<https://www.rfc-editor.org/info/rfc2317>.
[RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
specifying the location of services (DNS SRV)", RFC 2782, specifying the location of services (DNS SRV)", RFC 2782,
DOI 10.17487/RFC2782, February 2000, DOI 10.17487/RFC2782, February 2000,
<https://www.rfc-editor.org/info/rfc2782>. <https://www.rfc-editor.org/info/rfc2782>.
[RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, [RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi,
"DNS Extensions to Support IP Version 6", STD 88, "DNS Extensions to Support IP Version 6", STD 88,
RFC 3596, DOI 10.17487/RFC3596, October 2003, RFC 3596, DOI 10.17487/RFC3596, October 2003,
<https://www.rfc-editor.org/info/rfc3596>. <https://www.rfc-editor.org/info/rfc3596>.
[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
and A. Bierman, Ed., "Network Configuration Protocol
(NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
<https://www.rfc-editor.org/info/rfc6241>.
[RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types",
RFC 6991, DOI 10.17487/RFC6991, July 2013, RFC 6991, DOI 10.17487/RFC6991, July 2013,
<https://www.rfc-editor.org/info/rfc6991>. <https://www.rfc-editor.org/info/rfc6991>.
[RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
RFC 7950, DOI 10.17487/RFC7950, August 2016, RFC 7950, DOI 10.17487/RFC7950, August 2016,
<https://www.rfc-editor.org/info/rfc7950>. <https://www.rfc-editor.org/info/rfc7950>.
[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
skipping to change at page 21, line 10 skipping to change at page 23, line 23
[RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams",
BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018,
<https://www.rfc-editor.org/info/rfc8340>. <https://www.rfc-editor.org/info/rfc8340>.
[RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration
Access Control Model", STD 91, RFC 8341, Access Control Model", STD 91, RFC 8341,
DOI 10.17487/RFC8341, March 2018, DOI 10.17487/RFC8341, March 2018,
<https://www.rfc-editor.org/info/rfc8341>. <https://www.rfc-editor.org/info/rfc8341>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>.
[whatwg-fetch] [whatwg-fetch]
"WHATWG Fetch Living Standard", October 2020, "WHATWG Fetch Living Standard", October 2020,
<https://fetch.spec.whatwg.org/>. <https://fetch.spec.whatwg.org/>.
9.2. Informative References 9.2. Informative References
[I-D.draft-ietf-mboned-ambi-00] [I-D.draft-ietf-core-comi]
Veillette, M., Stok, P. V. D., Pelov, A., Bierman, A., and
I. Petrov, "CoAP Management Interface (CORECONF)", draft-
ietf-core-comi-11 (work in progress), January 2021.
[I-D.draft-ietf-mboned-ambi]
Holland, J. and K. Rose, "Asymmetric Manifest Based Holland, J. and K. Rose, "Asymmetric Manifest Based
Integrity", draft-ietf-mboned-ambi-00 (work in progress), Integrity", draft-ietf-mboned-ambi-01 (work in progress),
March 2020. October 2020.
[I-D.draft-ietf-mboned-cbacc-00] [I-D.draft-ietf-mboned-cbacc]
Holland, J., "Circuit Breaker Assisted Congestion Holland, J., "Circuit Breaker Assisted Congestion
Control", draft-ietf-mboned-cbacc-00 (work in progress), Control", draft-ietf-mboned-cbacc-02 (work in progress),
March 2020. February 2021.
[I-D.draft-openconfig-rtgwg-gnmi-spec]
Shakir, R., Shaikh, A., Borman, P., Hines, M., Lebsack,
C., and C. Morrow, "gRPC Network Management Interface
(gNMI)", draft-openconfig-rtgwg-gnmi-spec-01 (work in
progress), March 2018.
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
<https://www.rfc-editor.org/info/rfc1034>. <https://www.rfc-editor.org/info/rfc1034>.
[RFC1035] Mockapetris, P., "Domain names - implementation and [RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
November 1987, <https://www.rfc-editor.org/info/rfc1035>. November 1987, <https://www.rfc-editor.org/info/rfc1035>.
[RFC2845] Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B. [RFC2845] Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B.
skipping to change at page 22, line 24 skipping to change at page 25, line 5
[RFC4604] Holbrook, H., Cain, B., and B. Haberman, "Using Internet [RFC4604] Holbrook, H., Cain, B., and B. Haberman, "Using Internet
Group Management Protocol Version 3 (IGMPv3) and Multicast Group Management Protocol Version 3 (IGMPv3) and Multicast
Listener Discovery Protocol Version 2 (MLDv2) for Source- Listener Discovery Protocol Version 2 (MLDv2) for Source-
Specific Multicast", RFC 4604, DOI 10.17487/RFC4604, Specific Multicast", RFC 4604, DOI 10.17487/RFC4604,
August 2006, <https://www.rfc-editor.org/info/rfc4604>. August 2006, <https://www.rfc-editor.org/info/rfc4604>.
[RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for [RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for
IP", RFC 4607, DOI 10.17487/RFC4607, August 2006, IP", RFC 4607, DOI 10.17487/RFC4607, August 2006,
<https://www.rfc-editor.org/info/rfc4607>. <https://www.rfc-editor.org/info/rfc4607>.
[RFC5013] Kunze, J. and T. Baker, "The Dublin Core Metadata Element
Set", RFC 5013, DOI 10.17487/RFC5013, August 2007,
<https://www.rfc-editor.org/info/rfc5013>.
[RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for
the Network Configuration Protocol (NETCONF)", RFC 6020, the Network Configuration Protocol (NETCONF)", RFC 6020,
DOI 10.17487/RFC6020, October 2010, DOI 10.17487/RFC6020, October 2010,
<https://www.rfc-editor.org/info/rfc6020>. <https://www.rfc-editor.org/info/rfc6020>.
[RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S.
Cheshire, "Internet Assigned Numbers Authority (IANA) Cheshire, "Internet Assigned Numbers Authority (IANA)
Procedures for the Management of the Service Name and Procedures for the Management of the Service Name and
Transport Protocol Port Number Registry", BCP 165, Transport Protocol Port Number Registry", BCP 165,
RFC 6335, DOI 10.17487/RFC6335, August 2011, RFC 6335, DOI 10.17487/RFC6335, August 2011,
skipping to change at page 22, line 45 skipping to change at page 25, line 30
[RFC6415] Hammer-Lahav, E., Ed. and B. Cook, "Web Host Metadata", [RFC6415] Hammer-Lahav, E., Ed. and B. Cook, "Web Host Metadata",
RFC 6415, DOI 10.17487/RFC6415, October 2011, RFC 6415, DOI 10.17487/RFC6415, October 2011,
<https://www.rfc-editor.org/info/rfc6415>. <https://www.rfc-editor.org/info/rfc6415>.
[RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D.,
and P. Hoffman, "Specification for DNS over Transport and P. Hoffman, "Specification for DNS over Transport
Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May
2016, <https://www.rfc-editor.org/info/rfc7858>. 2016, <https://www.rfc-editor.org/info/rfc7858>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>.
[RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS [RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS
(DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018,
<https://www.rfc-editor.org/info/rfc8484>. <https://www.rfc-editor.org/info/rfc8484>.
9.3. URIs
[1] https://trac.ietf.org/trac/ops/wiki/yang-security-guidelines
[2] https://datatracker.ietf.org/doc/html/rfc8407#section-3.7
Author's Address Author's Address
Jake Holland Jake Holland
Akamai Technologies, Inc. Akamai Technologies, Inc.
150 Broadway 150 Broadway
Cambridge, MA 02144 Cambridge, MA 02144
United States of America United States of America
Email: jakeholland.net@gmail.com Email: jakeholland.net@gmail.com
 End of changes. 88 change blocks. 
242 lines changed or deleted 370 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/