draft-ietf-mboned-dorms-00.txt   draft-ietf-mboned-dorms-01.txt 
Mboned J. Holland Mboned J. Holland
Internet-Draft Akamai Technologies, Inc. Internet-Draft Akamai Technologies, Inc.
Intended status: Standards Track March 10, 2020 Intended status: Standards Track October 30, 2020
Expires: September 11, 2020 Expires: May 3, 2021
Discovery Of Restconf Metadata for Source-specific multicast Discovery Of Restconf Metadata for Source-specific multicast
draft-ietf-mboned-dorms-00 draft-ietf-mboned-dorms-01
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 September 11, 2020. This Internet-Draft will expire on May 3, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Background . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Background . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. Discovery and Metdata Retrieval . . . . . . . . . . . . . . . 4 1.3. Motivation . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. DNS Bootstrap . . . . . . . . . . . . . . . . . . . . . . 4 1.3.1. Use cases . . . . . . . . . . . . . . . . . . . . . . 4
2.2. RESTCONF Bootstrap . . . . . . . . . . . . . . . . . . . 5 1.3.2. Channel Selection . . . . . . . . . . . . . . . . . . 5
2.2.1. Root Resource Discovery . . . . . . . . . . . . . . . 5 1.4. Notes for Contributors and Reviewers . . . . . . . . . . 5
2.2.2. Yang Library Version . . . . . . . . . . . . . . . . 6 1.4.1. Venues for Contribution and Discussion . . . . . . . 5
2.2.3. Yang Library Contents . . . . . . . . . . . . . . . . 6 1.4.2. Non-obvious doc choices . . . . . . . . . . . . . . . 6
2.2.4. Metadata Retrieval . . . . . . . . . . . . . . . . . 7 2. Discovery and Metdata Retrieval . . . . . . . . . . . . . . . 6
2.2.5. Cross Origin Resource Sharing (CORS) . . . . . . . . 8 2.1. DNS Bootstrap . . . . . . . . . . . . . . . . . . . . . . 6
3. Scalability Considerations . . . . . . . . . . . . . . . . . 9 2.2. Ignore List . . . . . . . . . . . . . . . . . . . . . . . 7
3.1. Provisioning . . . . . . . . . . . . . . . . . . . . . . 9 2.3. RESTCONF Bootstrap . . . . . . . . . . . . . . . . . . . 8
3.2. Data Scoping . . . . . . . . . . . . . . . . . . . . . . 9 2.3.1. Root Resource Discovery . . . . . . . . . . . . . . . 8
4. YANG Model . . . . . . . . . . . . . . . . . . . . . . . . . 9 2.3.2. Yang Library Version . . . . . . . . . . . . . . . . 8
4.1. Yang Tree . . . . . . . . . . . . . . . . . . . . . . . . 10 2.3.3. Yang Library Contents . . . . . . . . . . . . . . . . 9
4.2. Yang Module . . . . . . . . . . . . . . . . . . . . . . . 10 2.3.4. Metadata Retrieval . . . . . . . . . . . . . . . . . 10
5. Privacy Considerations . . . . . . . . . . . . . . . . . . . 12 2.3.5. Cross Origin Resource Sharing (CORS) . . . . . . . . 11
5.1. Linking Content to Traffic Streams . . . . . . . . . . . 12 3. Scalability Considerations . . . . . . . . . . . . . . . . . 11
5.2. Linking Multicast Subscribers to Unicast Connections . . 12 3.1. Provisioning . . . . . . . . . . . . . . . . . . . . . . 11
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 3.2. Data Scoping . . . . . . . . . . . . . . . . . . . . . . 12
6.1. The YANG Module Names Registry . . . . . . . . . . . . . 13 4. YANG Model . . . . . . . . . . . . . . . . . . . . . . . . . 12
6.2. The Service Name and Transport Protocol Port Number 4.1. Yang Tree . . . . . . . . . . . . . . . . . . . . . . . . 12
Registry . . . . . . . . . . . . . . . . . . . . . . . . 13 4.2. Yang Module . . . . . . . . . . . . . . . . . . . . . . . 13
7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 5. Privacy Considerations . . . . . . . . . . . . . . . . . . . 15
7.1. Secure Communications . . . . . . . . . . . . . . . . . . 13 5.1. Linking Content to Traffic Streams . . . . . . . . . . . 15
7.2. Exposure of Metadata . . . . . . . . . . . . . . . . . . 14 5.2. Linking Multicast Subscribers to Unicast Connections . . 15
7.3. DNS Bootstrapping . . . . . . . . . . . . . . . . . . . . 14 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 6.1. The YANG Module Names Registry . . . . . . . . . . . . . 16
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 6.2. The XML Registry . . . . . . . . . . . . . . . . . . . . 16
9.1. Normative References . . . . . . . . . . . . . . . . . . 15 6.3. The Service Name and Transport Protocol Port Number
9.2. Informative References . . . . . . . . . . . . . . . . . 16 Registry . . . . . . . . . . . . . . . . . . . . . . . . 16
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 17 7. Security Considerations . . . . . . . . . . . . . . . . . . . 17
7.1. YANG Model Considerations . . . . . . . . . . . . . . . . 17
7.2. Exposure of Metadata . . . . . . . . . . . . . . . . . . 17
7.3. Secure Communications . . . . . . . . . . . . . . . . . . 18
7.4. Record-Spoofing . . . . . . . . . . . . . . . . . . . . . 18
7.5. CORS considerations . . . . . . . . . . . . . . . . . . . 19
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 20
9.1. Normative References . . . . . . . . . . . . . . . . . . 20
9.2. Informative References . . . . . . . . . . . . . . . . . 21
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 23
1. Introduction 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. multicast data streams. A review of some example use cases that can
be enabled by this kind of metadata is given in Section 1.3.
This document defines the "dorms" service name for use with the SRV This document defines the "dorms" service name for use with the SRV
DNS Resource Record (RR) type [RFC2782]. A sender offering a DORMS DNS Resource Record (RR) type [RFC2782]. A sender using a DORMS
service to publish metadata SHOULD configure at least one SRV RR for 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 of its multicast channel to advertise a hostname for a DORMS IP used by some active multicast traffic. The domain name in one of
server that can provide metadata for the sender's source-specific these SRV records provides a hostname corresponding to a DORMS server
multicast traffic. Doing so enables receivers and middleboxes to that can provide metadata for the sender's source-specific multicast
discover and query a DORMS server as described in Section 2. traffic. Publishing such a RR enables DORMS clients to discover and
query a DORMS server as described in Section 2.
The goal is to provide an extensible framework for attaching
information necessary for the correct processing of multicast data
channels, both for middle boxes forwarding the traffic, and for
receivers subscribing to traffic (hereafter called "clients").
1.1. Background 1.1. Background
The reader is assumed to be familiar with the basic DNS concepts The reader is assumed to be familiar with the basic DNS concepts
described in [RFC1034], [RFC1035], and the subsequent documents that described in [RFC1034], [RFC1035], and the subsequent documents that
update them, as well as the use of the SRV Resource Record type as update them, as well as the use of the SRV Resource Record type as
described in [RFC2782]. described in [RFC2782].
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 regarding source-specific multicast as described in terminology regarding source-specific multicast as described in
skipping to change at page 3, line 38 skipping to change at page 4, line 4
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 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 described in |
| | [RFC4607]. A pair of IP addresses with a source host IP | | | [RFC4607]. A pair of IP addresses with a source host IP |
| | and destination group IP. | | | and destination group IP. |
| | | | | |
| DORMS | An application or system that can communicate with DORMS |
| client | servers to fetch metadata about (S,G)s. |
| | |
| DORMS | A RESTCONF server that implements the ietf-dorms YANG |
| server | model defined in this document. |
| | |
| RR | A DNS Resource Record, as described in [RFC1034] | | RR | A DNS Resource Record, as described in [RFC1034] |
| | | | | |
| RRType | A DNS Resource Record Type, as described in [RFC1034] | | RRType | A DNS Resource Record Type, as described in [RFC1034] |
| | | | | |
| 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
DORMS provides a framework that can be extended to publish
supplemental information about multicas traffic in a globally
discoverable manner. This is useful so that entities engaged in
delivery or processing of the traffic that are not affiliated with
the sender of the traffic and who may not otherwise have any means to
discover information about the traffic, such as forwarding ISPs or
operators of firewalls providing security guarantees to their users,
can discover the information they may need in order to process the
traffic according to their requirements.
1.3.1. Use cases
For example, a network that is capable of forwarding multicast
traffic may need to take provisioning actions or make admission
control decisions at ingress points based on the expected bitrate of
the traffic in order to prevent oversubscription of the network.
Other use cases may include metadata that can be used to authenticate
the multicast traffic, metadata that describes the contents of the
traffic, metadata that makes assertions about the legal status of the
traffic within specific contexts, or metadata that describes the
protocols or applications that can be used to consume the traffic.
Extensions to DORMS to support these or other kinds of metadata can
be defined by later specifications.
Detailing the specific of the possible extensions is out of scope for
this document except to note that a range of possible use cases are
expected and they may be supported by a variety of different future
extensions.
1.3.2. Channel Selection
In general, a DORMS client might learn of an (S,G) by any means.
Therefore, describing the full set of possible methods a DORMS client
might use to discover a set of (S,G)s for which it wants metadata is
out of scope for this document.
But to give a few examples, a multicast receiver application that is
a DORMS client might learn about an (S,G) by getting signals from
inside the application logic, such as a selection made by a user, or
a scheduled API call that reacts to updates in a library provided by
a service operator.
As another example, an on-path router that's a DORMS client might
instead learn about an (S,G) by receiving a PIM message or an IGMP or
MLD membership report indicating a downstream client has tried to
subscribe to an (S,G). Such a router might use information learned
from the DORMS metadata to make an access control decision about
whether to propagate the join futher upstream in the network.
Other approaches for learning an (S,G) could be driven by monitoring
a route reflector to discover channels that are being actively
forwarded, for a purpose such as monitoring network health.
1.4. Notes for Contributors and Reviewers
Note to RFC Editor: Please remove this section and its subsections
before publication.
This section is to provide references to make it easier to review the
development and discussion on the draft so far.
1.4.1. Venues for Contribution and Discussion
This document is in the Github repository at:
https://github.com/GrumpyOldTroll/ietf-dorms-cluster
Readers are welcome to open issues and send pull requests for this
document.
Please note that contributions may be merged and substantially
edited, and as a reminder, please carefully consider the Note Well
before contributing: https://datatracker.ietf.org/submit/note-well/
Substantial discussion of this document should take place on the
MBONED working group mailing list (mboned@ietf.org).
o Join: https://www.ietf.org/mailman/listinfo/mboned
o Search: https://mailarchive.ietf.org/arch/browse/mboned/
1.4.2. Non-obvious doc choices
Log of odd things that need to be the way they are because of some
reason that the author or reviewers may want to know later.
o building the draft without this line produces a warning about no
reference to [RFC6991] or [RFC8294], but these are imported in the
yang model. RFC 8407 requires the normative reference to 8294
(there's an exception for 6991 but I'm not sure why and it doesn't
seem forbidden).
2. Discovery and Metdata Retrieval 2. Discovery and Metdata Retrieval
A client that needs metadata about a (S,G) MAY attempt to discover A client that needs metadata about an (S,G) MAY attempt to discover
metadata for the (S,G) using the mechanisms defined here, and MAY use 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 RESTCONF hostname for a DORMS server with metadata for an obtaining a hostname of a trusted DORMS server with information about
(S,G). the 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 receiver or middle box needs metadata for an (S,G), for When a DORMS client needs metadata for an (S,G), for example when
example when handling a new join for that (S,G) and looking up handling a new join for that (S,G) and looking up the authentication
authentication methods available, a receiver or middlebox can issue a methods that are available, a receiver or middlebox can issue a DNS
DNS query for a SRV RR using the "dorms" service name with the domain query for a SRV RR using the "dorms" service name with the domain
from the reverse mapping tree, combining them as described in from the 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, while handling a join for (203.0.113.15, 232.1.1.1), a
receiver would perform a DNS query for the SRV RRType for the domain: receiver would perform a DNS query for the SRV RRType for the domain:
_dorms._tcp.15.113.0.203.in-addr.arpa. _dorms._tcp.15.113.0.203.in-addr.arpa.
The DNS response for this domain might return a record such as: The DNS response for this domain might return a record such as:
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 receiver that a DORMS server should be
reachable at dorms-restconf.example.com on port 443. Multiple SRV reachable at dorms-restconf.example.com on port 443, and should
records are handled as described by [RFC2782]. contain metadata about multicast traffic from the given source IP.
Multiple SRV records are handled as described by [RFC2782].
A sender providing DORMS discovery SHOULD publish at least one SRV 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 receivers and middle boxes. The DORMS servers of the DORMS server to DORMS clients. The DORMS servers advertised
advertised SHOULD be configured with metadata for all the groups sent SHOULD be configured with metadata for all the groups sent from the
from the same source IP address that have metadata published with same source IP address that have metadata published with DORMS.
DORMS.
2.2. RESTCONF Bootstrap 2.2. Ignore List
If a DORMS client reaches a DORMS server but determines through
examination of responses from that DORMS server that it may not
understand or be able to use the responses of the server (for example
due to an issue like a version mismatch or modules that are missing
but are required for the DORMS client's purposes), the client MAY add
this server to an ignore list and reject servers in its ignore list
during future discovery attempts.
A client using the DNS Bootstrap discovery method in Section 2.1
would treat servers in its ignore list as unreachable for the
purposes of processing the SRV RR as described in [RFC2782]. (For
example, a client might end up selecting a server with a less-
preferred priority than servers in its ignore list, even if an HTTPS
connection could have been formed successfully with some of those
servers.)
If an ignore list is maintained, entries SHOULD time out and allow
for re-checking after either the cache expiration time from the
response that caused the server to be added to the ignore list, or
for a configurable hold-down time that has a default value no shorter
than an hour and no longer than 3 days.
2.3. RESTCONF Bootstrap
Once a DORMS host has been chosen (whether via an SRV RR from a DNS Once a DORMS host has been chosen (whether via an SRV RR from a DNS
response or via some other method), RESTCONF provides all the 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.2.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
"/.well-known/host-meta" or "/.well-known/host-meta.json" resource. "/.well-known/host-meta" or "/.well-known/host-meta.json" resource.
Example: Example:
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
skipping to change at page 6, line 5 skipping to change at page 8, line 47
{ {
"links":[ "links":[
{ {
"rel":"restconf", "rel":"restconf",
"href":"/top/restconf" "href":"/top/restconf"
} }
] ]
} }
2.2.2. Yang Library Version 2.3.2. Yang Library Version
As described in Section 3.3.3 of [RFC8040], the yang-library-version As described in Section 3.3.3 of [RFC8040], the yang-library-version
leaf is required by RESTCONF, and can be used to determine the schema leaf is required by RESTCONF, and can be used to determine the schema
of the ietf-yang-library module: of the ietf-yang-library module:
Example: Example:
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
skipping to change at page 6, line 31 skipping to change at page 9, line 25
HTTP/1.1 200 OK HTTP/1.1 200 OK
Date: Tue, 27 Aug 2019 20:56:01 GMT Date: Tue, 27 Aug 2019 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"
} }
TBD: We might need a method for learning a specific restconf server If a DORMS client determines through examination of the yang-library-
or resource path that supports a version the client knows how to use, version that it may not understand the responses of the server due to
in the case the client is older than the server after a new yang- a version mismatch, the server qualifies as a candidate for adding to
library version is released... Can this be just retry with a hold- an ignore list as described in Section 2.2.
down on specific hostnames, so that you can find a lower priority
older server from the SRV records, or is signaling that can find or
negotiate an explicit version as part of the lookup going to be
necessary? -jake 2019-08-26
2.2.3. Yang Library Contents 2.3.3. Yang Library Contents
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 module is available on the DORMS server by fetching the metadata modules are available on the DORMS server by fetching the
module-state resource from the ietf-yang-library module. 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,2016-08-15
Host: dorms-restconf.example.com Host: dorms-restconf.example.com
Accept: application/yang-data+json Accept: application/yang-data+json
skipping to change at page 7, line 33 skipping to change at page 10, line 26
"namespace": "urn:ietf:params:xml:ns:yang:ietf-dorms", "namespace": "urn:ietf:params:xml:ns:yang:ietf-dorms",
"revision": "2019-08-25", "revision": "2019-08-25",
"schema": "schema":
"https://example.com/yang/ietf-dorms@2019-08-25.yang" "https://example.com/yang/ietf-dorms@2019-08-25.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. retrieved by not providing a key for the "module" list. If a DORMS
client that requires the presence of certain modules to perform its
function discovers the required modules are not present on a server,
that server qualifies for inclusion in an ignore list according to
Section 2.2.
2.2.4. Metadata Retrieval 2.3.4. Metadata Retrieval
Once the expected DORMS version is confirmed, the client can retrieve 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:metadata/\
sender=203.0.113.15/group=232.1.1.1 sender=203.0.113.15/group=232.1.1.1
skipping to change at page 8, line 34 skipping to change at page 11, line 34
Note that when other modules are installed on the DORMS server that Note that when other modules are installed on the DORMS server that
extend the ietf-dorms module, other fields MAY appear inside the extend the ietf-dorms module, other fields MAY appear inside the
response. This is the primary mechanism for providing extensible response. This is the primary mechanism for providing extensible
metadata for an (S,G), so clients SHOULD ignore fields they do not metadata for an (S,G), so clients SHOULD ignore fields they do not
understand. understand.
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.2.5. Cross Origin Resource Sharing (CORS) 2.3.5. Cross Origin Resource Sharing (CORS)
It is RECOMMENDED that DORMS servers use the Access-Control-Allow- It is RECOMMENDED that DORMS servers use the Access-Control-Allow-
Origin header field, as specified by [W3C.REC-cors-20140116], and Origin header field, as specified by [whatwg-fetch], and that they
that they respond appropriately to Preflight requests. respond appropriately to Preflight requests.
Providing '*' for the allowed origins exposes the DORMS-based The use of '*' for allowed origins is NOT RECOMMENDED for DORMS
metadata to all web pages. When access to the metadata is used as a servers. A review of some of the potential consequences of
prerequisite to permitting the joining of the multicast flows, this unrestricted CORS access is given in Section 7.5.
would permit scripts from arbitrary web pages to issue joins for the
multicast flows, which could allow e.g. malicious advertisements to
participate in overjoining attacks (see Appendix A of
[I-D.draft-jholland-cb-assisted-cc-01]) using multicast flows not
controlled by the ad's senders. Therefore the use of '*' for allowed
origins is NOT RECOMMENDED. (TBD: this probably deserves a security
considerations section.)
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
multicast can scale to very large audiences. multicast can scale to very large audiences.
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.
skipping to change at page 9, line 37 skipping to change at page 12, line 28
Section 3.5.3 of [RFC8040] to encode data resource identifiers in the Section 3.5.3 of [RFC8040] to encode data resource identifiers in the
request URI. This avoids downloading excessive data, since the DORMS request URI. This avoids downloading excessive data, since the DORMS
server may provide metadata for many (S,G)s, possibly from many server may provide metadata for many (S,G)s, possibly from many
different senders. different senders.
However, clients MAY use heuristics or out of band information about However, clients MAY use heuristics or out of band information about
the service to issue requests for (S,G) metadata narrowed only by the the service to issue requests for (S,G) metadata narrowed only by the
source-address, or not narrowed at all. Depending on the request source-address, or not narrowed at all. Depending on the request
patterns and the contents of the data store, this may result in fewer patterns and the contents of the data store, this may result in fewer
round trips or less overhead, and can therefore be helpful behavior round trips or less overhead, and can therefore be helpful behavior
for scaling purposes. Servers MAY restrict or throttle client access for scaling purposes in some scenarios. Servers MAY restrict or
based on the client certificate presented (if any), or based on throttle client access based on the client certificate presented (if
heuristics that take note of client request patterns. 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. Currently scaffold for the more useful metadata that will extend it. Example
known use cases include providing authentication information and bit- specified use cases include providing authentication information
rate information for use by receivers and middle boxes, but more use [I-D.draft-ietf-mboned-ambi-00] and bit-rate information
cases are anticipated. [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].
module: ietf-dorms module: ietf-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 rt-types:ip-multicast-group-address +--rw 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 DORMS Tree Diagram
4.2. Yang Module 4.2. Yang Module
<CODE BEGINS> file ietf-dorms@2020-03-10.yang <CODE BEGINS> file ietf-dorms@2020-10-31.yang
module ietf-dorms { module ietf-dorms {
yang-version 1.1; yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-dorms";
prefix "dorms";
import ietf-inet-types { namespace "urn:ietf:params:xml:ns:yang:ietf-dorms";
prefix "inet"; prefix "dorms";
reference "RFC 6991 Section 4";
}
import ietf-routing-types { import ietf-inet-types {
prefix "rt-types"; prefix "inet";
reference "RFC 8294"; reference "RFC 6991 Section 4";
} }
organization "IETF"; import ietf-routing-types {
prefix "rt-types";
reference "RFC 8294";
}
contact organization "IETF MBONED (Multicast Backbone
"Author: Jake Holland Deployment) Working Group";
<mailto:jholland@akamai.com>
";
description contact
"Copyright (c) 2019 IETF Trust and the persons identified as "Author: Jake Holland
authors of the code. All rights reserved. <mailto:jholland@akamai.com>
";
Redistribution and use in source and binary forms, with or description
without modification, is permitted pursuant to, and subject to "Copyright (c) 2019 IETF Trust and the persons identified as
the license terms contained in, the Simplified BSD License set authors of the code. All rights reserved.
forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents
(https://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC XXXX Redistribution and use in source and binary forms, with or
(https://www.rfc-editor.org/info/rfcXXXX); see the RFC itself without modification, is permitted pursuant to, and subject to
for full legal notices. the license terms contained in, the Simplified BSD License set
forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents
(https://trustee.ietf.org/license-info).
The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL This version of this YANG module is part of RFC XXXX
NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED', (https://www.rfc-editor.org/info/rfcXXXX); see the RFC itself
'MAY', and 'OPTIONAL' in this document are to be interpreted as for full legal notices.
described in BCP 14 (RFC 2119) (RFC 8174) when, and only when,
they appear in all capitals, as shown here.
This module contains the definition for the DORMS data type. The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL
It provides out of band metadata about SSM channels."; NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED',
'MAY', and 'OPTIONAL' in this document are to be interpreted as
described in BCP 14 (RFC 2119) (RFC 8174) when, and only when,
they appear in all capitals, as shown here.
revision 2019-08-25 { This module contains the definition for the DORMS data type.
description "Initial revision."; It provides out of band metadata about SSM channels.";
reference
"";
// "I-D.draft-jholland-mboned-dorms";
}
container metadata { revision 2019-08-25 {
description "Metadata scaffold for source-specific multicast description "Initial revision.";
channels."; reference
list sender { "I-D.draft-ietf-mboned-dorms";
key source-address; }
description "Sender for DORMS";
leaf source-address { container metadata {
type inet:ip-address; description "Metadata scaffold for source-specific multicast
mandatory true; channels.";
description list sender {
"The source IP address of a multicast sender."; key source-address;
} description "Sender for DORMS";
list group { leaf source-address {
key group-address; type inet:ip-address;
description "Metadata for a DORMS (S,G)."; mandatory true;
description
"The source IP address of a multicast sender.";
}
leaf group-address { list group {
type rt-types:ip-multicast-group-address; key group-address;
mandatory true; description "Metadata for a DORMS (S,G).";
description "The group IP address for an (S,G).";
}
list udp-stream { leaf group-address {
key "port"; type rt-types:ip-multicast-group-address;
description
"Metadata for UDP traffic on a specific port.";
leaf port {
type inet:port-number;
mandatory true; mandatory true;
description description "The group IP address for an (S,G).";
"The UDP port of a data stream in an (S,G).";
} }
}
} list udp-stream {
} key "port";
} description
} "Metadata for UDP traffic on a specific port.";
<CODE ENDS> leaf port {
type inet:port-number;
mandatory true;
description
"The UDP port of a data stream.";
}
}
}
}
}
}
<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.
However, depending on the metadata provided by the server, observers However, depending on the metadata provided by the server, observers
may be able to more easily associate traffic from an (S,G) with the may be able to more easily associate traffic from an (S,G) with the
content contained within the (S,G). At the subscriber edge of a content contained within the (S,G). At the subscriber edge of a
multicast-capable network, where the network operator has the multicast-capable network, where the network operator has the
capability to localize an IGMP [RFC3376] or MLD [RFC3810] channel capability to localize an IGMP [RFC3376] or MLD [RFC3810] channel
subscription to a specific user or location by MAC address or source subscription to a specific user or location, for example by MAC
IP address, the structured publishing of metadata may make it easier address or source IP address, the structured publishing of metadata
to automate collection of data about the content a receiver is may make it easier to automate collection of data about the content a
consuming. receiver is consuming.
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,
skipping to change at page 13, line 21 skipping to change at page 16, line 21
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"
registry maintained at <https://www.iana.org/assignments/yang- registry maintained at <https://www.iana.org/assignments/yang-
parameters>. The following registrations are made, per the format in parameters>. The following registrations are made, per the format in
Section 14 of [RFC6020]: Section 14 of [RFC6020]:
name: ietf-dorms name: ietf-dorms
namespace: urn:ietf:params:xml:ns:yang:ietf-dorms namespace: urn:ietf:params:xml:ns:yang:ietf-dorms
prefix: dorms prefix: dorms
reference: I-D.draft-jholland-mboned-dorms reference: I-D.draft-ietf-mboned-dorms
6.2. The Service Name and Transport Protocol Port Number Registry 6.2. The XML Registry
This document adds the following registration to the "ns" subregistry
of the "IETF XML Registry" defined in [RFC3688], referencing this
document.
URI: urn:ietf:params:xml:ns:yang:ietf-dorms
Registrant Contact: The IESG.
XML: N/A, the requested URI is an XML namespace.
6.3. The Service Name and Transport Protocol Port Number Registry
This document adds one service name to the "Service Name and This document adds one service name to the "Service Name and
Transport Protocol Port Number Registry" maintained at Transport Protocol Port Number Registry" maintained at
<https://www.iana.org/assignments/service-names-port-numbers>. The <https://www.iana.org/assignments/service-names-port-numbers>. The
following registrations are made, per the format in Section 8.1.1 of following registrations are made, per the format in Section 8.1.1 of
[RFC6335]: [RFC6335]:
Service Name: dorms Service Name: dorms
Transport Protocol(s): TCP Transport Protocol(s): TCP, UDP
Assignee: IESG <iesg@ietf.org> Assignee: IESG <iesg@ietf.org>
Contact: IETF Chair <chair@ietf.org> Contact: IETF Chair <chair@ietf.org>
Description: This service name is used to construct the Description: The DORMS service (RESTCONF that
SRV service label "_dorms" for discovering includes ietf-dorms YANG model)
DORMS servers. Reference: I-D.draft-ietf-mboned-dorms
Reference: I-D.draft-jholland-mboned-dorms Port Number: N/A
Port Number: N/A Service Code: N/A
Service Code: N/A Known Unauthorized Uses: N/A
Known Unauthorized Uses: N/A Assignment Notes: N/A
Assignment Notes: This protocol uses HTTPS as a substrate.
7. Security Considerations 7. Security Considerations
7.1. Secure Communications 7.1. YANG Model Considerations
It is intended that security related metadata about the SSM channels The YANG module specified in this document defines a schema for data
will be delivered over the RESTCONF connection, and that information that is designed to be accessed via RESTCONF [RFC8040]. The lowest
available from this connection can be used as a trust anchor. RESTCONF layer is HTTPS, and the mandatory-to-implement secure
transport is TLS [RFC8446].
The provisions of Section 2 of [RFC8040] provide secure communication The Network Configuration Access Control Model (NACM) [RFC8341]
requirements that are already required of DORMS servers, since they provides the means to restrict access for particular NETCONF or
are RESTCONF servers. All RESTCONF requirements and security RESTCONF users to a preconfigured subset of all available NETCONF or
considerations remain in force for DORMS servers. RESTCONF protocol operations and content. DORMS servers MAY use NACM
to control access to data nodes.
No data nodes defined in this YANG module are writable, creatable, or
deletable. This YANG module is intended for publication of read-only
data according to a well-defined schema.
7.2. Exposure of Metadata 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:metadata" MUST NOT include any sensitive data unsuitable for
public dissemination in those data paths. Because of the possibility public dissemination in those data paths.
that scalable read-only access might be necessary to fulfill the
scalability goals for a DORMS server, data under these paths MAY be
cached or replicated by numerous external entities, so owners of such
data SHOULD NOT assume it can be kept secret when provided by DORMS
servers anywhere under the "ietf-dorms:metadata" path, even if they
are authenticating clients.
7.3. DNS Bootstrapping Because of the possibility that scalable read-only access might be
necessary to fulfill the scalability goals for a DORMS server, data
under these paths MAY be cached or replicated by numerous external
entities, so owners of such data SHOULD NOT assume such data can be
kept secret when provided by DORMS servers anywhere under the "ietf-
dorms:metadata" path even if access controls are used with
authenticated clients unless additional operational procedures and
restrictions are defined and implemented that can effectively control
the dissemination of the secret data. DORMS alone does not provide
any such mechanisms, and users of DORMS can be expected not to be
following any such mechanisms in the absence of additional
assurances.
The DNS bootstrap phase relies on DNS for the reverse IP tree. When 7.3. Secure Communications
using DNS to discover a DORMS server's domain name, there must be a
trust relationship between the end consumer of this resource record
and the DNS server. This relationship may be end-to-end DNSSEC
validation, a TSIG [RFC2845] or SIG(0) [RFC2931] channel to another
secure source, a secure local channel on the host, DNS over TLS
[RFC7858] or HTTPS [RFC8484], or some other secure mechanism.
If the SRV Resource Record cannot be authenticated, it may be The provisions of Section 2 of [RFC8040] provide secure communication
possible for an attacker who can spoof the resource record to perform requirements that are already required of DORMS servers, since they
a denial of service for the receiver by providing wrong or missing are RESTCONF servers. All RESTCONF requirements and security
authentication metadata. An attacker who can also inject traffic for considerations remain in force for DORMS servers.
(S,G)s, would also be able to provide false content in the data
stream, so an attacker who can perform both could provide It is intended that security related metadata about the SSM channels
authenticated false content by authenticating with a trust anchor such as public keys for use with cryptographic algorithms may be
from an attacker-controlled DORMS server. delivered over the RESTCONF connection, and that information
available from this connection can be used as a trust anchor. The
secure transport provided by these minimum requirements are relied
upon to provide authenticated delivery of these trust anchors, once a
connection with a trusted DORMS server has been established.
7.4. Record-Spoofing
When using the DNS Boostrap method of discovery described in
Section 2.1, the SRV resource record contains information that SHOULD
be communicated to the DORMS client without being modified. The
method used to ensure the result was unmodified is up to the client.
There must be a trust relationship between the end consumer of this
resource record and the DNS server. This relationship may be end-to-
end DNSSEC validation or a secure connection to a trusted DNS server
that provides end-to-end safety to prevent record-spoofing of the
response from the trusted server. The connection to the trusted
server can use any secure channel, such as with a TSIG [RFC2845] or
SIG(0) [RFC2931] channel, a secure local channel on the host, DNS
over TLS [RFC7858], DNS over HTTPS [RFC8484], or some other mechanism
that provides authentication of the RR.
If a DORMS client accepts a maliciously crafted SRV record, the
client could connect to a server controlled by the attacker, and use
metadata provided by them. The consequences of trusting maliciously
crafted metadata could range from attacks against the DORMS client's
parser of the metadata (via malicious constructions of the formatting
of the data) to arbitrary disruption of the decisions the DORMS
client makes as a result of processing validly constructed metadata.
Clients MAY use other secure methods to explicitly associate an (S,G) Clients MAY use other secure methods to explicitly associate an (S,G)
with a set of DORMS server hostnames, such as a configured mapping or with a set of DORMS server hostnames, such as a configured mapping or
an alternative trusted lookup service. an alternative trusted lookup service.
7.5. CORS considerations
As described in Section 2.3.5, it's RECOMMENDED that DORMS servers
provide appropriate restrictions to ensure only authorized web pages
access metadata for their (S,G)s from the widely deployed base of
secure browsers that use the CORS protocol according to
[whatwg-fetch].
Providing '*' for the allowed origins exposes the DORMS-based
metadata to access by scripts in all web pages, which opens the
possibility of certain kinds of attacks against networks where
browsers have support for joining multicast (S,G)s.
If the authentication for an (S,G) relies on DORMS-based metadata
(for example, as defined in [I-D.draft-ietf-mboned-ambi-00]), an
unauthorized web page that tries to join an (S,G) not permitted by
the CORS headers for the DORMS server will be prevented from
subscribing to the channels.
If an unauthorized site is not prevented from subscribing, code on
the site (for example a malicious advertisement) could request
subscriptions from many different (S,G)s, overflowing limits on the
joining of (S,G)s and disrupting the delivery of multicast traffic
for legitimate use.
Further, if the malicious script can be distributed to many different
users within the same receiving network, the script could coordinate
an attack against the network as a whole by joining disjoint sets of
(S,G)s from different users within the receiving network. The
distributed subscription requests across the receiving network could
overflow limits for the receiving network as a whole, essentially
causing the websites displaying the ad to participate in an
overjoining attack (see Appendix A of
[I-D.draft-ietf-mboned-cbacc-00]).
Even if network safety mechanisms protect the network from the worst
effects of oversubscription, the population counts for the multicast
subscriptions could be disrupted by this kind of attack, and
therefore push out legitimately requested traffic that's being
consumed by real users. For a legitimately popular event, this could
cause a widespread disruption to the service if it's successfully
pushed out.
A denial of service attack of this sort would be thwarted by
restricting the access to (S,G)s to authorized websites through the
use of properly restricted CORS headers.
8. Acknowledgements 8. Acknowledgements
Thanks to Christian Worm Mortensen for some very helpful comments and Thanks to Christian Worm Mortensen, Dino Farinacci, and Lenny
review. Guiliano 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>.
skipping to change at page 16, line 5 skipping to change at page 20, line 50
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8294] Liu, X., Qu, Y., Lindem, A., Hopps, C., and L. Berger, [RFC8294] Liu, X., Qu, Y., Lindem, A., Hopps, C., and L. Berger,
"Common YANG Data Types for the Routing Area", RFC 8294, "Common YANG Data Types for the Routing Area", RFC 8294,
DOI 10.17487/RFC8294, December 2017, DOI 10.17487/RFC8294, December 2017,
<https://www.rfc-editor.org/info/rfc8294>. <https://www.rfc-editor.org/info/rfc8294>.
[W3C.REC-cors-20140116] [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams",
Kesteren, A., "Cross-Origin Resource Sharing", World Wide BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018,
Web Consortium Recommendation REC-cors-20140116, January <https://www.rfc-editor.org/info/rfc8340>.
2014, <http://www.w3.org/TR/2014/REC-cors-20140116>.
[RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration
Access Control Model", STD 91, RFC 8341,
DOI 10.17487/RFC8341, March 2018,
<https://www.rfc-editor.org/info/rfc8341>.
[whatwg-fetch]
"WHATWG Fetch Living Standard", October 2020,
<https://fetch.spec.whatwg.org/>.
9.2. Informative References 9.2. Informative References
[I-D.draft-jholland-cb-assisted-cc-01] [I-D.draft-ietf-mboned-ambi-00]
Holland, J., "Circuit Breaker Assisted Congestion Control Holland, J. and K. Rose, "Asymmetric Manifest Based
(CBACC): Protocol Specification", draft-jholland-cb- Integrity", draft-ietf-mboned-ambi-00 (work in progress),
assisted-cc-01 (work in progress), April 2017. March 2020.
[I-D.draft-ietf-mboned-cbacc-00]
Holland, J., "Circuit Breaker Assisted Congestion
Control", draft-ietf-mboned-cbacc-00 (work in progress),
March 2020.
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", [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 16, line 44 skipping to change at page 22, line 5
[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.
Thyagarajan, "Internet Group Management Protocol, Version Thyagarajan, "Internet Group Management Protocol, Version
3", RFC 3376, DOI 10.17487/RFC3376, October 2002, 3", RFC 3376, DOI 10.17487/RFC3376, October 2002,
<https://www.rfc-editor.org/info/rfc3376>. <https://www.rfc-editor.org/info/rfc3376>.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
DOI 10.17487/RFC3688, January 2004,
<https://www.rfc-editor.org/info/rfc3688>.
[RFC3810] Vida, R., Ed. and L. Costa, Ed., "Multicast Listener [RFC3810] Vida, R., Ed. and L. Costa, Ed., "Multicast Listener
Discovery Version 2 (MLDv2) for IPv6", RFC 3810, Discovery Version 2 (MLDv2) for IPv6", RFC 3810,
DOI 10.17487/RFC3810, June 2004, DOI 10.17487/RFC3810, June 2004,
<https://www.rfc-editor.org/info/rfc3810>. <https://www.rfc-editor.org/info/rfc3810>.
[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>.
skipping to change at page 17, line 36 skipping to change at page 22, line 45
[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>.
[whatwg-fetch]
Kesteren, A., "WHATWG Fetch Living Standard", August 2019,
<https://fetch.spec.whatwg.org/>.
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. 68 change blocks. 
239 lines changed or deleted 475 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/