< draft-ietf-mboned-dorms-02.txt   draft-ietf-mboned-dorms-03.txt >
Mboned J. Holland Mboned J. Holland
Internet-Draft Akamai Technologies, Inc. Internet-Draft Akamai Technologies, Inc.
Intended status: Standards Track July 10, 2021 Intended status: Standards Track 23 October 2021
Expires: January 11, 2022 Expires: 26 April 2022
Discovery Of Restconf Metadata for Source-specific multicast Discovery Of Restconf Metadata for Source-specific multicast
draft-ietf-mboned-dorms-02 draft-ietf-mboned-dorms-03
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 January 11, 2022. This Internet-Draft will expire on 26 April 2022.
Copyright Notice Copyright Notice
Copyright (c) 2021 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/
(https://trustee.ietf.org/license-info) in effect on the date of license-info) in effect on the date of publication of this document.
publication of this document. Please review these documents Please review these documents carefully, as they describe your rights
carefully, as they describe your rights and restrictions with respect and restrictions with respect to this document. Code Components
to this document. Code Components extracted from this document must extracted from this document must include Simplified BSD License text
include Simplified BSD License text as described in Section 4.e of as described in Section 4.e of the Trust Legal Provisions and are
the Trust Legal Provisions and are provided without warranty as 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 . . . . . . . . . . . . . . . . . . . . . . . 4 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
1.3. Motivation and Use Cases . . . . . . . . . . . . . . . . 4 1.3. Motivation and Use Cases . . . . . . . . . . . . . . . . 5
1.3.1. Provisioning and Oversubscription Protection . . . . 5 1.3.1. Provisioning and Oversubscription Protection . . . . 5
1.3.2. Authentication . . . . . . . . . . . . . . . . . . . 5 1.3.2. Authentication . . . . . . . . . . . . . . . . . . . 5
1.3.3. Content Description . . . . . . . . . . . . . . . . . 5 1.3.3. Content Description . . . . . . . . . . . . . . . . . 5
1.4. Channel Discovery . . . . . . . . . . . . . . . . . . . . 5 1.4. Channel Discovery . . . . . . . . . . . . . . . . . . . . 5
1.5. Notes for Contributors and Reviewers . . . . . . . . . . 6 1.5. Notes for Contributors and Reviewers . . . . . . . . . . 6
1.5.1. Venues for Contribution and Discussion . . . . . . . 6 1.5.1. Venues for Contribution and Discussion . . . . . . . 6
1.5.2. Non-obvious doc choices . . . . . . . . . . . . . . . 6 1.5.2. Non-obvious doc choices . . . . . . . . . . . . . . . 7
2. Discovery and Metdata Retrieval . . . . . . . . . . . . . . . 7 2. Discovery and Metdata Retrieval . . . . . . . . . . . . . . . 7
2.1. DNS Bootstrap . . . . . . . . . . . . . . . . . . . . . . 7 2.1. DNS Bootstrap . . . . . . . . . . . . . . . . . . . . . . 7
2.2. Ignore List . . . . . . . . . . . . . . . . . . . . . . . 8 2.2. Ignore List . . . . . . . . . . . . . . . . . . . . . . . 9
2.3. RESTCONF Bootstrap . . . . . . . . . . . . . . . . . . . 9 2.3. RESTCONF Bootstrap . . . . . . . . . . . . . . . . . . . 9
2.3.1. Root Resource Discovery . . . . . . . . . . . . . . . 9 2.3.1. Root Resource Discovery . . . . . . . . . . . . . . . 9
2.3.2. Yang Library Version . . . . . . . . . . . . . . . . 10 2.3.2. Yang Library Version . . . . . . . . . . . . . . . . 10
2.3.3. Yang Library Contents . . . . . . . . . . . . . . . . 10 2.3.3. Yang Library Contents . . . . . . . . . . . . . . . . 11
2.3.4. Metadata Retrieval . . . . . . . . . . . . . . . . . 11 2.3.4. Metadata Retrieval . . . . . . . . . . . . . . . . . 12
2.3.5. Cross Origin Resource Sharing (CORS) . . . . . . . . 12 2.3.5. Cross Origin Resource Sharing (CORS) . . . . . . . . 13
3. Scalability Considerations . . . . . . . . . . . . . . . . . 12 3. Scalability Considerations . . . . . . . . . . . . . . . . . 13
3.1. Provisioning . . . . . . . . . . . . . . . . . . . . . . 12 3.1. Provisioning . . . . . . . . . . . . . . . . . . . . . . 13
3.2. Data Scoping . . . . . . . . . . . . . . . . . . . . . . 13 3.2. Data Scoping . . . . . . . . . . . . . . . . . . . . . . 13
4. YANG Model . . . . . . . . . . . . . . . . . . . . . . . . . 13 4. YANG Model . . . . . . . . . . . . . . . . . . . . . . . . . 14
4.1. Yang Tree . . . . . . . . . . . . . . . . . . . . . . . . 13 4.1. Yang Tree . . . . . . . . . . . . . . . . . . . . . . . . 14
4.2. Yang Module . . . . . . . . . . . . . . . . . . . . . . . 14 4.2. Yang Module . . . . . . . . . . . . . . . . . . . . . . . 14
5. Privacy Considerations . . . . . . . . . . . . . . . . . . . 16 5. Privacy Considerations . . . . . . . . . . . . . . . . . . . 16
5.1. Linking Content to Traffic Streams . . . . . . . . . . . 16 5.1. Linking Content to Traffic Streams . . . . . . . . . . . 17
5.2. Linking Multicast Subscribers to Unicast Connections . . 17 5.2. Linking Multicast Subscribers to Unicast Connections . . 17
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
6.1. The YANG Module Names Registry . . . . . . . . . . . . . 17 6.1. The YANG Module Names Registry . . . . . . . . . . . . . 17
6.2. The XML Registry . . . . . . . . . . . . . . . . . . . . 17 6.2. The XML Registry . . . . . . . . . . . . . . . . . . . . 18
6.3. The Service Name and Transport Protocol Port Number 6.3. The Service Name and Transport Protocol Port Number
Registry . . . . . . . . . . . . . . . . . . . . . . . . 18 Registry . . . . . . . . . . . . . . . . . . . . . . . . 18
7. Security Considerations . . . . . . . . . . . . . . . . . . . 18 7. Security Considerations . . . . . . . . . . . . . . . . . . . 18
7.1. YANG Model Considerations . . . . . . . . . . . . . . . . 18 7.1. YANG Model Considerations . . . . . . . . . . . . . . . . 18
7.2. Exposure of Metadata . . . . . . . . . . . . . . . . . . 19 7.2. Exposure of Metadata . . . . . . . . . . . . . . . . . . 20
7.3. Secure Communications . . . . . . . . . . . . . . . . . . 20 7.3. Secure Communications . . . . . . . . . . . . . . . . . . 20
7.4. Record-Spoofing . . . . . . . . . . . . . . . . . . . . . 20 7.4. Record-Spoofing . . . . . . . . . . . . . . . . . . . . . 21
7.5. CORS considerations . . . . . . . . . . . . . . . . . . . 21 7.5. CORS considerations . . . . . . . . . . . . . . . . . . . 21
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 22
9.1. Normative References . . . . . . . . . . . . . . . . . . 22 9.1. Normative References . . . . . . . . . . . . . . . . . . 22
9.2. Informative References . . . . . . . . . . . . . . . . . 23 9.2. Informative References . . . . . . . . . . . . . . . . . 24
9.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 25 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 26
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
skipping to change at page 4, line 10 skipping to change at page 4, line 16
terminology regarding source-specific multicast as described in terminology regarding source-specific multicast as described in
[RFC4607] and the use of IGMPv3 [RFC3376] and MLDv2 [RFC3810] for [RFC4607] and the use of IGMPv3 [RFC3376] and MLDv2 [RFC3810] for
group management of source-specific multicast channels, as described group management of source-specific multicast channels, as described
in [RFC4604]. in [RFC4604].
The reader is also assumed to be familiar with the concepts and The reader is also assumed to be familiar with the concepts and
terminology for RESTCONF [RFC8040] and YANG [RFC7950]. terminology for RESTCONF [RFC8040] and YANG [RFC7950].
1.2. Terminology 1.2. Terminology
+--------+----------------------------------------------------------+ +========+=================================================+
| Term | Definition | | Term | Definition |
+--------+----------------------------------------------------------+ +========+=================================================+
| (S,G) | A source-specific multicast channel, as described in | | (S,G) | A source-specific multicast channel, as |
| | [RFC4607]. A pair of IP addresses with a source host IP | | | described in [RFC4607]. A pair of IP addresses |
| | and destination group IP. | | | with a source host IP and destination group IP. |
| | | +--------+-------------------------------------------------+
| DORMS | An application or system that can communicate with DORMS | | DORMS | An application or system that can communicate |
| client | servers to fetch metadata about (S,G)s. | | client | with DORMS servers to fetch metadata about |
| | | | | (S,G)s. |
| DORMS | A RESTCONF server that implements the ietf-dorms YANG | +--------+-------------------------------------------------+
| server | model defined in this document. | | DORMS | A RESTCONF server that implements the ietf- |
| | | | server | dorms YANG model defined in this document. |
| RR | A DNS Resource Record, as described in [RFC1034] | +--------+-------------------------------------------------+
| | | | RR | A DNS Resource Record, as described in |
| RRType | A DNS Resource Record Type, as described in [RFC1034] | | | [RFC1034] |
| | | +--------+-------------------------------------------------+
| SSM | Source-specific multicast, as described in [RFC4607] | | RRType | A DNS Resource Record Type, as described in |
+--------+----------------------------------------------------------+ | | [RFC1034] |
+--------+-------------------------------------------------+
| SSM | Source-specific multicast, as described in |
| | [RFC4607] |
+--------+-------------------------------------------------+
Table 1
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 and Use Cases 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
skipping to change at page 6, line 33 skipping to change at page 6, line 46
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).
o Join: https://www.ietf.org/mailman/listinfo/mboned * Join: https://www.ietf.org/mailman/listinfo/mboned
o Search: https://mailarchive.ietf.org/arch/browse/mboned/ * Search: https://mailarchive.ietf.org/arch/browse/mboned/
1.5.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 * 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 * Although it's non-normative, I chose the boundaries in the
recommendation for default setting of DNS expiry time in recommendation for default setting of DNS expiry time in
Section 2.2 based on the best practices advice at Section 2.2 based on the best practices advice at
https://www.varonis.com/blog/dns-ttl/ for "Short" and "Long" https://www.varonis.com/blog/dns-ttl/ for "Short" and "Long"
times. times.
o Section 7.1 is intended to be the template from * Section 7.1 is intended to be the template from
https://trac.ietf.org/trac/ops/wiki/yang-security-guidelines [1], https://trac.ietf.org/trac/ops/wiki/yang-security-guidelines
as required by https://datatracker.ietf.org/doc/html/ (https://trac.ietf.org/trac/ops/wiki/yang-security-guidelines), as
rfc8407#section-3.7 [2]. Individual nodes are not listed because required by https://datatracker.ietf.org/doc/html/rfc8407#section-
blanket statements in that section covere them. 3.7 (https://datatracker.ietf.org/doc/html/rfc8407#section-3.7).
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 * The 'must' constraint in the group list seems awkward, but seems
to work. Its intent is to require source & group to be either to work. Its intent is to require source & group to be either
both IPv4 or both IPv6, without mixing & matching. It requires both IPv4 or both IPv6, without mixing & matching. It requires
that either both the group address and its source parent's address that either both the group address and its source parent's address
must contain a colon or both must NOT contain a colon, where must contain a colon or both must NOT contain a colon, where
presence of a colon is used to distinguish IPv4 from IPv6. Maybe presence of a colon is used to distinguish IPv4 from IPv6. Maybe
there's a better way? 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
skipping to change at page 8, line 8 skipping to change at page 8, line 26
For example, a client looking for metadata about the channel with a For example, a client looking for metadata about the channel with a
source IP of 2001:db8::a and the group address of ff3e::8000:d, the 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 client would start the DNS bootstrap step by performing a query for
the SRV RRType for the following domain (after removing the line the SRV RRType for the following domain (after removing the line
break inserted for editorial reasons): break inserted for editorial reasons):
_dorms._tcp.a.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0. _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. 0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa.
Or for an IPv4 (S,G) with a source address of 203.0.113.4 and a group Or for an IPv4 (S,G) with a source address of 203.0.113.4, the DORMS
address of 232.1.1.1, the DORMS client would request the SRV record client would request the SRV record from the in-addr.arpa tree
from the in-addr.arpa tree instead: instead:
_dorms._tcp.4.113.0.203.in-addr.arpa. _dorms._tcp.4.113.0.203.in-addr.arpa.
In either case, the DNS response for this domain might return a In either case, the DNS response for this domain might return a
record such as this: record such as this:
SRV 0 1 443 dorms-restconf.example.com. SRV 0 1 443 dorms-restconf.example.com.
This response informs the client 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
skipping to change at page 14, line 16 skipping to change at page 14, line 34
+--rw dorms +--rw dorms
+--rw metadata +--rw metadata
+--rw sender* [source-address] +--rw sender* [source-address]
+--rw source-address inet:ip-address +--rw source-address inet:ip-address
+--rw group* [group-address] +--rw group* [group-address]
+--rw group-address +--rw group-address
| rt-types:ip-multicast-group-address | rt-types:ip-multicast-group-address
+--rw udp-stream* [port] +--rw udp-stream* [port]
+--rw port inet:port-number +--rw port inet:port-number
DORMS Tree Diagram Figure 1: DORMS Tree Diagram
4.2. Yang Module 4.2. Yang Module
<CODE BEGINS> file ietf-dorms@2021-07-11.yang <CODE BEGINS>
file ietf-dorms@2021-10-23.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";
} }
skipping to change at page 18, line 34 skipping to change at page 18, line 49
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 There are a number of data nodes defined in this YANG module that are
users cannot edit the data published by the server. Unauthorized writable/creatable/deletable (i.e., config true, which is the
editing of any data nodes or any extensions to data nodes could default). These data nodes may be considered sensitive or vulnerable
result in a denial of service for end users. in some network environments. Write operations (e.g., edit-config)
to these data nodes without proper protection can have a negative
effect on network operations. These are the subtrees and data nodes
and their sensitivity/vulnerability:
Subtrees:
* /dorms/metadata
* /dorms/metadata/sender
* /dorms/metadata/sender/group
* /dorms/metadata/sender/group/udp-stream
Data nodes:
* /dorms/metadata/sender/source-address
* /dorms/metadata/sender/group/group-address
* /dorms/metadata/sender/group/udp-stream/port
These data nodes refer to the characteristics of a stream of data
packets being sent on a multicast channel. If an unauthorized or
incorrect edit is made, receivers would no longer be able to
associate the data stream to the correct metadata, resulting in a
denial of service for end users that rely on the metadata to properly
process the data packets. Therefore DORMS servers MUST constrain
write access to ensure that unauthorized users cannot edit the data
published by the server.
The Network Configuration Access Control Model (NACM) [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 constrain write accesses. to constrain write accesses.
However, note that scalability considerations described in However, note that scalability considerations described in
Section 3.1 might make the naive use of NACM intractable in many Section 3.1 might make the naive use of NACM intractable in many
deployments. So alternative methods to constrain write access to the deployments, for a broadcast use case. So alternative methods to
metadata MAY be used instead of or in addition to NACM. For example, constrain write access to the metadata MAY be used instead of or in
some deployments that use a CDN or caching layer of discoverable addition to NACM. For example, some deployments that use a CDN or
DORMS servers might uniformly provide read-only access through the caching layer of discoverable DORMS servers might uniformly provide
caching layer, and might require the trusted writers of configuration read-only access through the caching layer, and might require the
to use an alternate method of accessing the underlying database such trusted writers of configuration to use an alternate method of
as connecting directly to the origin, or requiring the use of a non- accessing the underlying database such as connecting directly to the
RESTCONF mechanism for editing the contents of the metadata. 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 The data nodes defined in this YANG module are writable because some
deployments might manage the contents in the database by using normal deployments might manage the contents in the database by using normal
RESTCONF editing operations with NACM, but in many deployments it's RESTCONF editing operations with NACM, but in typical deployments
expected that DORMS clients will generally have read-only access. it's expected that DORMS clients will generally have read-only
For the reasons and requirements described in Section 7.2, none of access. For the reasons and requirements described in Section 7.2,
the data nodes in the DORMS module or its extensions contain none of the data nodes in the DORMS module or its extensions contain
sensitive data. sensitive data.
DORMS servers MAY provide read-only access to clients for publicly DORMS servers MAY provide read-only access to clients for publicly
available metadata without authenticating the clients. That is, available metadata without authenticating the clients. That is,
under the terms in Section 2.5 of [RFC8040] read-only access to under the terms in Section 2.5 of [RFC8040] read-only access to
publicly available data MAY be treated as unprotected resources. 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.
skipping to change at page 20, line 32 skipping to change at page 21, line 25
When using the DNS Boostrap method of discovery described in When using the DNS Boostrap method of discovery described in
Section 2.1, the SRV resource record contains information that SHOULD Section 2.1, the SRV resource record contains information that SHOULD
be communicated to the DORMS client without being modified. The be communicated to the DORMS client without being modified. The
method used to ensure the result was unmodified is up to the client. 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 There must be a trust relationship between the end consumer of this
resource record and the DNS server. This relationship may be end-to- resource record and the DNS server. This relationship may be end-to-
end DNSSEC validation or a secure connection to a trusted DNS server end DNSSEC validation or a secure connection to a trusted DNS server
that provides end-to-end safety to prevent record-spoofing of the that provides end-to-end safety to prevent record-spoofing of the
response from the trusted server. The connection to the trusted response from the trusted server. The connection to the trusted
server can use any secure channel, such as with a TSIG [RFC2845] or server can use any secure channel, such as with a TSIG [RFC8945] or
SIG(0) [RFC2931] channel, a secure local channel on the host, DNS SIG(0) [RFC2931] channel, a secure local channel on the host, DNS
over TLS [RFC7858], DNS over HTTPS [RFC8484], or some other mechanism over TLS [RFC7858], DNS over HTTPS [RFC8484], or some other mechanism
that provides authentication of the RR. that provides authentication of the RR.
If a DORMS client accepts a maliciously crafted SRV record, the If a DORMS client accepts a maliciously crafted SRV record, the
client could connect to a server controlled by the attacker, and use client could connect to a server controlled by the attacker, and use
metadata provided by them. The consequences of trusting maliciously metadata provided by them. The consequences of trusting maliciously
crafted metadata could range from attacks against the DORMS client's crafted metadata could range from attacks against the DORMS client's
parser of the metadata (via malicious constructions of the formatting parser of the metadata (via malicious constructions of the formatting
of the data) to arbitrary disruption of the decisions the DORMS of the data) to arbitrary disruption of the decisions the DORMS
skipping to change at page 23, line 35 skipping to change at page 24, line 26
<https://www.rfc-editor.org/info/rfc8446>. <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-core-comi] [I-D.draft-ietf-core-comi]
Veillette, M., Stok, P. V. D., Pelov, A., Bierman, A., and Veillette, M., Stok, P. V. D., Pelov, A., Bierman, A., and
I. Petrov, "CoAP Management Interface (CORECONF)", draft- I. Petrov, "CoAP Management Interface (CORECONF)", Work in
ietf-core-comi-11 (work in progress), January 2021. Progress, Internet-Draft, draft-ietf-core-comi-11, 17
January 2021, <https://www.ietf.org/archive/id/draft-ietf-
core-comi-11.txt>.
[I-D.draft-ietf-mboned-ambi] [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-01 (work in progress), Integrity", Work in Progress, Internet-Draft, draft-ietf-
October 2020. mboned-ambi-01, 31 October 2020,
<https://www.ietf.org/archive/id/draft-ietf-mboned-ambi-
01.txt>.
[I-D.draft-ietf-mboned-cbacc] [I-D.draft-ietf-mboned-cbacc]
Holland, J., "Circuit Breaker Assisted Congestion Holland, J., "Circuit Breaker Assisted Congestion
Control", draft-ietf-mboned-cbacc-02 (work in progress), Control", Work in Progress, Internet-Draft, draft-ietf-
February 2021. mboned-cbacc-02, 1 February 2021,
<https://www.ietf.org/archive/id/draft-ietf-mboned-cbacc-
02.txt>.
[I-D.draft-openconfig-rtgwg-gnmi-spec] [I-D.draft-openconfig-rtgwg-gnmi-spec]
Shakir, R., Shaikh, A., Borman, P., Hines, M., Lebsack, Shakir, R., Shaikh, A., Borman, P., Hines, M., Lebsack,
C., and C. Morrow, "gRPC Network Management Interface C., and C. Morrow, "gRPC Network Management Interface
(gNMI)", draft-openconfig-rtgwg-gnmi-spec-01 (work in (gNMI)", Work in Progress, Internet-Draft, draft-
progress), March 2018. openconfig-rtgwg-gnmi-spec-01, 5 March 2018,
<https://www.ietf.org/archive/id/draft-openconfig-rtgwg-
gnmi-spec-01.txt>.
[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.
Wellington, "Secret Key Transaction Authentication for DNS
(TSIG)", RFC 2845, DOI 10.17487/RFC2845, May 2000,
<https://www.rfc-editor.org/info/rfc2845>.
[RFC2931] Eastlake 3rd, D., "DNS Request and Transaction Signatures [RFC2931] Eastlake 3rd, D., "DNS Request and Transaction Signatures
( SIG(0)s )", RFC 2931, DOI 10.17487/RFC2931, September ( SIG(0)s )", RFC 2931, DOI 10.17487/RFC2931, September
2000, <https://www.rfc-editor.org/info/rfc2931>. 2000, <https://www.rfc-editor.org/info/rfc2931>.
[RFC3040] Cooper, I., Melve, I., and G. Tomlinson, "Internet Web [RFC3040] Cooper, I., Melve, I., and G. Tomlinson, "Internet Web
Replication and Caching Taxonomy", RFC 3040, Replication and Caching Taxonomy", RFC 3040,
DOI 10.17487/RFC3040, January 2001, DOI 10.17487/RFC3040, January 2001,
<https://www.rfc-editor.org/info/rfc3040>. <https://www.rfc-editor.org/info/rfc3040>.
[RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A.
skipping to change at page 25, line 34 skipping to change at page 26, line 30
[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>.
[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 [RFC8945] Dupont, F., Morris, S., Vixie, P., Eastlake 3rd, D.,
Gudmundsson, O., and B. Wellington, "Secret Key
[1] https://trac.ietf.org/trac/ops/wiki/yang-security-guidelines Transaction Authentication for DNS (TSIG)", STD 93,
RFC 8945, DOI 10.17487/RFC8945, November 2020,
[2] https://datatracker.ietf.org/doc/html/rfc8407#section-3.7 <https://www.rfc-editor.org/info/rfc8945>.
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. 36 change blocks. 
101 lines changed or deleted 140 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/