Label Switched Paths (LSP) Hierarchy with Generalized Multi-Protocol Label Switching (GMPLS) Traffic Engineering (TE)
RFC 4206
| Document | Type | RFC - Proposed Standard (October 2005) IPR | |
|---|---|---|---|
| Authors | Kireeti Kompella , Yakov Rekhter | ||
| Last updated | 2018-12-20 | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Formats | |||
| Additional resources | Mailing list discussion | ||
| IESG | Responsible AD | Scott O. Bradner | |
| Send notices to | (None) |
RFC 4206
Network Working Group P. Hoffman
Internet-Draft ICANN
Intended status: Standards Track P. McManus
Expires: February 17, 2019 Mozilla
August 16, 2018
DNS Queries over HTTPS (DoH)
draft-ietf-doh-dns-over-https-14
Abstract
This document defines a protocol for sending DNS queries and getting
DNS responses over HTTPS. Each DNS query-response pair is mapped
into an HTTP exchange.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on February 17, 2019.
Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Hoffman & McManus Expires February 17, 2019 [Page 1]
Internet-Draft DNS Queries over HTTPS (DoH) August 2018
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Selection of DoH Server . . . . . . . . . . . . . . . . . . . 3
4. The HTTP Exchange . . . . . . . . . . . . . . . . . . . . . . 4
4.1. The HTTP Request . . . . . . . . . . . . . . . . . . . . 4
4.1.1. HTTP Request Examples . . . . . . . . . . . . . . . . 5
4.2. The HTTP Response . . . . . . . . . . . . . . . . . . . . 6
4.2.1. Handling DNS and HTTP Errors . . . . . . . . . . . . 6
4.2.2. HTTP Response Example . . . . . . . . . . . . . . . . 7
5. HTTP Integration . . . . . . . . . . . . . . . . . . . . . . 7
5.1. Cache Interaction . . . . . . . . . . . . . . . . . . . . 7
5.2. HTTP/2 . . . . . . . . . . . . . . . . . . . . . . . . . 9
5.3. Server Push . . . . . . . . . . . . . . . . . . . . . . . 9
5.4. Content Negotiation . . . . . . . . . . . . . . . . . . . 10
6. Definition of the application/dns-message media type . . . . 10
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
7.1. Registration of application/dns-message Media Type . . . 10
8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 12
8.1. On The Wire . . . . . . . . . . . . . . . . . . . . . . . 12
8.2. In The Server . . . . . . . . . . . . . . . . . . . . . . 12
9. Security Considerations . . . . . . . . . . . . . . . . . . . 14
10. Operational Considerations . . . . . . . . . . . . . . . . . 14
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
11.1. Normative References . . . . . . . . . . . . . . . . . . 16
11.2. Informative References . . . . . . . . . . . . . . . . . 17
Appendix A. Protocol Development . . . . . . . . . . . . . . . . 19
Appendix B. Previous Work on DNS over HTTP or in Other Formats . 19
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20
1. Introduction
This document defines a specific protocol, DNS over HTTPS (DoH), for
sending DNS [RFC1035] queries and getting DNS responses over HTTP
[RFC7540] using https [RFC2818] URIs (and therefore TLS [RFC8446]
security for integrity and confidentiality). Each DNS query-response
pair is mapped into an HTTP exchange.
The described approach is more than a tunnel over HTTP. It
establishes default media formatting types for requests and responses
but uses normal HTTP content negotiation mechanisms for selecting
alternatives that endpoints may prefer in anticipation of serving new
use cases. In addition to this media type negotiation, it aligns
itself with HTTP features such as caching, redirection, proxying,
authentication, and compression.
Hoffman & McManus Expires February 17, 2019 [Page 2]
Internet-Draft DNS Queries over HTTPS (DoH) August 2018
The integration with HTTP provides a transport suitable for both
existing DNS clients and native web applications seeking access to
the DNS.
Two primary use cases were considered during this protocol's
development. They were preventing on-path devices from interfering
with DNS operations and allowing web applications to access DNS
information via existing browser APIs in a safe way consistent with
Cross Origin Resource Sharing (CORS) [CORS]. No special effort has
been taken to enable or prevent application to other use cases. This
document focuses on communication between DNS clients (such as
operating system stub resolvers) and recursive resolvers.
2. Terminology
A server that supports this protocol is called a "DoH server" to
differentiate it from a "DNS server" (one that only provides DNS
service over one or more of the other transport protocols
standardized for DNS). Similarly, a client that supports this
protocol is called a "DoH client".
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
3. Selection of DoH Server
The DoH client is configured with a URI Template [RFC6570] which
describes how to construct the URL to use for resolution.
Configuration, discovery, and updating of the URI Template is done
out of band from this protocol. Note that configuration might be
manual (such as a user typing URI Templates in a user interface for
"optionsquot;SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in BCP 14, RFC 2119
[RFC2119].
Kompella & Rekhter Standards Track [Page 3]
RFC 4206 LSP Hierarchy with GMPLS TE October 2005
3. Routing Aspects
In this section we describe procedures for constructing FAs out of
LSPs, and handling of FAs by ISIS/OSPF. Specifically, this section
describes how to construct the information needed to advertise LSPs
as links into ISIS/OSPF. Procedures for creation/termination of such
LSPs are defined in Section 5, "Controlling FA-LSPs boundaries".
FAs may be represented as either unnumbered or numbered links. If
FAs are numbered with IPv4 addresses, the local and remote IPv4
addresses come out of a /31 that is allocated by the LSR that
originates the FA-LSP; the head-end address of the FA-LSP is the one
specified as the IPv4 tunnel sender address; the remote (tail-end)
address can then be inferred. If the LSP is bidirectional, the
tail-end can thus know the addresses to assign to the reverse FA.
If there are multiple LSPs that all originate on one LSR and all
terminate on another LSR, then at one end of the spectrum all these
LSPs could be merged (under control of the head-end LSR) into a
single FA using the concept of Link Bundling (see [BUNDLE]); while at
the other end of the spectrum each such LSP could be advertised as
its own adjacency.
When an FA is created under administrative control (static
provisioning), the attributes of the FA-LSP have to be provided via
configuration. Specifically, the following attributes may be
configured for the FA-LSP: the head-end address (if left
unconfigured, this defaults to the head-end LSR's Router ID); the
tail-end address; bandwidth and resource colors constraints. The
path taken by the FA-LSP may be either computed by the LSR at the
head-end of the FA-LSP, or specified by explicit configuration; this
choice is determined by configuration.
When an FA is created dynamically, the attributes of its FA-LSP are
inherited from the LSP that induced its creation. Note that the
bandwidth of the FA-LSP must be at least as big as the LSP that
induced it, but may be bigger if only discrete bandwidths are
available for the FA-LSP. In general, for dynamically provisioned
FAs, a policy-based mechanism may be needed to associate attributes
to the FA-LSPs.
3.1. Traffic Engineering Parameters
In this section, the Traffic Engineering parameters (see [OSPF-TE]
and [ISIS-TE]) for FAs are described.
Kompella & Rekhter Standards Track [Page 4]
RFC 4206 LSP Hierarchy with GMPLS TE October 2005
3.1.1. Link Type (OSPF Only)
The Link Type of an FA is set to "point-to-point".
3.1.2. Link ID (OSPF Only)
The Link ID is set to the Router ID of the tail-end of FA-LSP.
3.1.3. Local and Remote Interface IP Address
If the FA is to be numbered, the local interface IP address (OSPF) or
IPv4 interface address (ISIS) is set to the head-end address of the
FA-LSP. The remote interface IP address (OSPF) or IPv4 neighbor
address (ISIS) is set to the tail-end address of the FA-LSP.
3.1.4. Local and Remote Link Identifiers
For an unnumbered FA, the assignment and handling of the local and
remote link identifiers is specified in [UNNUM-RSVP], [UNNUM-CRLDP].
3.1.5. Traffic Engineering Metric
By default the TE metric on the FA is set to max(1, (the TE metric of
the FA-LSP path) - 1) so that it attracts traffic in preference to
setting up a new LSP. This may be overridden via configuration at
the head-end of the FA.
3.1.6. Maximum Bandwidth
By default, the Maximum Reservable Bandwidth and the initial Maximum
LSP Bandwidth for all priorities of the FA is set to the bandwidth of
the FA-LSP. These may be overridden via configuration at the head-
end of the FA (note that the Maximum LSP Bandwidth at any one
priority should be no more than the bandwidth of the FA-LSP).
3.1.7. Unreserved Bandwidth
The initial unreserved bandwidth for all priority levels of the FA is
set to the bandwidth of the FA-LSP.
3.1.8. Resource Class/Color
By default, an FA does not have resource colors (administrative
groups). This may be overridden by configuration at the head-end of
the FA.
Kompella & Rekhter Standards Track [Page 5]
RFC 4206 LSP Hierarchy with GMPLS TE October 2005
3.1.9. Interface Switching Capability
The (near-end) Interface Switching Capability associated with the FA
is the (near end) Interface Switching Capability of the first link in
the FA-LSP.
When the (near-end) Interface Switching Capability field is PSC-1,
PSC-2, PSC-3, or PSC-4, the specific information includes Interface
MTU and Minimum LSP Bandwidth. The Interface MTU is the minimum MTU
along the path of the FA-LSP; the Minimum LSP Bandwidth is the
bandwidth of the LSP.
3.1.10. SRLG Information
An FA advertisement could contain the information about the Shared
Risk Link Groups (SRLG) for the path taken by the FA-LSP associated
with that FA. This information may be used for path calculation by
other LSRs. The information carried is the union of the SRLGs of the
underlying TE links that make up the FA-LSP path; it is carried in
the SRLG TLV in IS-IS or the SRLG sub-TLV of the TE Link TLV in OSPF.
See [GMPLS-ISIS, GMPLS-OSPF] for details on the format of this
information.
It is possible that the underlying path information might change over
time, via configuration updates or dynamic route modifications,
resulting in the change of the SRLG TLV.
If FAs are bundled (via link bundling), and if the resulting bundled
link carries an SRLG TLV, it MUST be the case that the list of SRLGs
in the underlying path, followed by each of the FA-LSPs that form the
component links, is the same (note that the exact paths need not be
the same).
4. Other Considerations
It is expected that FAs will not be used for establishing ISIS/OSPF
peering relation between the routers at the ends of the adjacency.
It may be desired in some cases to use FAs only in Traffic
Engineering path computations. In IS-IS, this can be accomplished by
setting the default metric of the extended IS reachability TLV for
the FA to the maximum link metric (2^24 - 1). In OSPF, this can be
accomplished by not advertising the link as a regular LSA, but only
as a TE opaque LSA.
Kompella & Rekhter Standards Track [Page 6]
RFC 4206 LSP Hierarchy with GMPLS TE October 2005
5. Controlling FA-LSPs Boundaries
To facilitate controlling the boundaries of FA-LSPs, this document
introduces two new mechanisms: Interface Switching Capability (see
[GMPLS-ISIS, GMPLS-OSPF], and "LSP region" (or just "region").
5.1. LSP Regions
The information carried in the Interface Switching Capabilities is
used to construct LSP regions and to determine regions' boundaries as
follows.
Define an ordering among interface switching capabilities as follows:
PSC-1 < PSC-2 < PSC-3 < PSC-4 < TDM < LSC < FSC. Given two
interfaces if-1 and if-2 with interface switching capabilities isc-1
and isc-2 respectively, say that if-1 < if-2 iff isc-1 < isc-2 or
isc-1 == isc-2 == TDM, and if-1's max LSP bandwidth is less than if-
2's max LSP bandwidth.
Suppose an LSP's path is as follows: node-0, link-1, node-1, link-2,
node-2, ..., link-n, node-n. Moreover, for link-i denote by [link-i,
node-(i-1)] the interface that connects link-i to node-(i-1), and by
[link-i, node-i] the interface that connects link-i to node-i.
If [link-(i+1), node-i)] < [link-(i+1), node-(i+1)], we say that the
LSP has crossed a region boundary at node-i; with respect to that LSP
path, the LSR at node-i is an edge LSR. The 'other edge' of the
region with respect to the LSP path is node-k, where k is the
smallest number greater than i such that [link-(i+1), node-(i+1)]
equal [link-k, node-(k-1)], and [link-k, node-(k-1)] > [link-k,
node-k].
Path computation may take region boundaries into account when
computing a path for an LSP. For example, path computation may
restrict the path taken by an LSP to only the links whose Interface
Switching Capability is PSC-1.
Note that an interface may have multiple Interface Switching
Capabilities. In such a case, the test is whether if-i < if-j
depends on the Interface Switching Capabilities chosen for if-i and
if-j, which in turn determines whether or not there is a region
boundary at node-i.
Kompella & Rekhter Standards Track [Page 7]
RFC 4206 LSP Hierarchy with GMPLS TE October 2005
6. Signalling Aspects
In this section we describe procedures that an LSR at the head-end of
an FA uses for handling LSP setup originated by other LSR.
As we mentioned before, establishment/termination of FA-LSPs may be
triggered either by mechanisms outside of GMPLS (e.g., via
administrative control), or by mechanisms within GMPLS (e.g., as a
result of the LSR at the edge of an aggregate LSP receiving LSP setup
requests originated by some other LSRs beyond LSP aggregate and its
edges). Procedures described in Section 6.1, "Common Procedures",
apply to both cases. Procedures described in Section 6.2, &Hoffman & McManus Expires February 17, 2019 [Page 3]
Internet-Draft DNS Queries over HTTPS (DoH) August 2018
not extend DNS resolution privileges to URIs that are not recognized
by the DoH client as configured URIs. Such scenarios may create
additional operational, tracking, and security hazards that require
limitations for safe usage. A future specification may support this
use case.
4. The HTTP Exchange
4.1. The HTTP Request
A DoH client encodes a single DNS query into an HTTP request using
either the HTTP GET or POST method and the other requirements of this
section. The DoH server defines the URI used by the request through
the use of a URI Template.
The URI Template defined in this document is processed without any
variables when the HTTP method is POST. When the HTTP method is GET
the single variable "dns" is defined as the content of the DNS
request (as described in Section 6), encoded with base64url
[RFC4648].
Future specifications for new media types for DoH MUST define the
variables used for URI Template processing with this protocol.
DoH servers MUST implement both the POST and GET methods.
When using the POST method the DNS query is included as the message
body of the HTTP request and the Content-Type request header field
indicates the media type of the message. POST-ed requests are
generally smaller than their GET equivalents.
Using the GET method is friendlier to many HTTP cache
implementations.
The DoH client SHOULD include an HTTP "Accept" request header field
to indicate what type of content can be understood in response.
Irrespective of the value of the Accept request header field, the
client MUST be prepared to process "application/dns-message" (as
described in Section 6) responses but MAY also process other DNS-
related media types it receives.
In order to maximize HTTP cache friendliness, DoH clients using media
formats that include the ID field from the DNS message header, such
as application/dns-message, SHOULD use a DNS ID of 0 in every DNS
request. HTTP correlates the request and response, thus eliminating
the need for the ID in a media type such as application/dns-message.
The use of a varying DNS ID can cause semantically equivalent DNS
queries to be cached separately.
Hoffman & McManus Expires February 17, 2019 [Page 4]
Internet-Draft DNS Queries over HTTPS (DoH) August 2018
DoH clients can use HTTP/2 padding and compression [RFC7540] in the
same way that other HTTP/2 clients use (or don't use) them.
4.1.1. HTTP Request Examples
These examples use HTTP/2 style formatting from [RFC7540].
These examples use a DoH service with a URI Template of
"https://dnsserver.example.net/dns-query{?dns}" to resolve IN A
records.
The requests are represented as application/dns-message typed bodies.
The first example request uses GET to request www.example.com
:method = GET
:scheme = https
:authority = dnsserver.example.net
:path = /dns-query?dns=AAABAAABAAAAAAAAA3d3dwdleGFtcGxlA2NvbQAAAQAB
accept = application/dns-message
The same DNS query for www.example.com, using the POST method would
be:
:method = POST
:scheme = https
:authority = dnsserver.example.net
:path = /dns-query
accept = application/dns-message
content-type = application/dns-message
content-length = 33
<33 bytes represented by the following hex encoding>
00 00 01 00 00 01 00 00 00 00 00 00 03 77 77 77
07 65 78 61 6d 70 6c 65 03 63 6f 6d 00 00 01 00
01
In this example, the 33 bytes are the DNS message in DNS wire format
[RFC1035] starting with the DNS header.
Finally, a GET based query for a.62characterlabel-makes-base64url-
distinct-from-standard-base64.example.com is shown as an example to
emphasize that the encoding alphabet of base64url is different than
regular base64 and that padding is omitted.
The DNS query, expressed in DNS wire format, is 94 bytes represented
by the following:
Hoffman & McManus Expires February 17, 2019 [Page 5]
Internet-Draft DNS Queries over HTTPS (DoH) August 2018
00 00 01 00 00 01 00 00 00 00 00 00 01 61 3e 36
32 63 68 61 72 61 63 74 65 72 6c 61 62 65 6c 2d
6d 61 6b 65 73 2d 62 61 73 65 36 34 75 72 6c 2d
64 69 73 74 69 6e 63 74 2d 66 72 6f 6d 2d 73 74
61 6e 64 61 72 64 2d 62 61 73 65 36 34 07 65 78
61 6d 70 6c 65 03 63 6f 6d 00 00 01 00 01
:method = GET
:scheme = https
:authority = dnsserver.example.net
:path = /dns-query? (no space or CR)
dns=AAABAAABAAAAAAAAAWE-NjJjaGFyYWN0ZXJsYWJl (no space or CR)
bC1tYWtlcy1iYXNlNjR1cmwtZGlzdGluY3QtZnJvbS1z (no space or CR)
dGFuZGFyZC1iYXNlNjQHZXhhbXBsZQNjb20AAAEAAQ
accept = application/dns-message
4.2. The HTTP Response
The only response type defined in this document is "application/dns-
message", but it is possible that other response formats will be
defined in the future. A DoH server MUST be able to process
application/dns-message request messages.
Different response media types will provide more or less information
from a DNS response. For example, one response type might include
information from the DNS header bytes while another might omit it.
The amount and type of information that a media type gives is solely
up to the format, and not defined in this protocol.
Each DNS request-response pair is mapped to one HTTP exchange. The
responses may be processed and transported in any order using HTTP's
multi-streaming functionality ([RFC7540] Section 5).
Section 5.1 discusses the relationship between DNS and HTTP response
caching.
4.2.1. Handling DNS and HTTP Errors
DNS response codes indicate either success or failure for the DNS
query. A successful HTTP response with a 2xx status code ([RFC7231]
Section 6.3) is used for any valid DNS response, regardless of the
DNS response code. For example, a successful 2xx HTTP status code is
used even with a DNS message whose DNS response code indicates
failure, such as SERVFAIL or NXDOMAIN.
HTTP responses with non-successful HTTP status codes do not contain
replies to the original DNS question in the HTTP request. DoH
Hoffman & McManus Expires February 17, 2019 [Page 6]
Internet-Draft DNS Queries over HTTPS (DoH) August 2018
clients need to use the same semantic processing of non-successful
HTTP status codes as other HTTP clients. This might mean that the
DoH client retries the query with the same DoH server, such as if
there are authorization failures (HTTP status code 401 [RFC7235]
Section 3.1). It could also mean that the DoH client retries with a
different DoH server, such as for unsupported media types (HTTP
status code 415, [RFC7231] Section 6.5.13), or where the server
cannot generate a representation suitable for the client (HTTP status
code 406, [RFC7231] Section 6.5.6), and so on.
4.2.2. HTTP Response Example
This is an example response for a query for the IN AAAA records for
"www.example.com" with recursion turned on. The response bears one
answer record with an address of 2001:db8:abcd:12:1:2:3:4 and a TTL
of 3709 seconds.
:status = 200
content-type = application/dns-message
content-length = 61
cache-control = max-age=3709
<61 bytes represented by the following hex encoding>
00 00 81 80 00 01 00 01 00 00 00 00 03 77 77 77
07 65 78 61 6d 70 6c 65 03 63 6f 6d 00 00 1c 00
01 c0 0c 00 1c 00 01 00 00 0e 7d 00 10 20 01 0d
b8 ab cd 00 12 00 01 00 02 00 03 00 04
5. HTTP Integration
This protocol MUST be used with the https scheme URI [RFC7230].
Section 8 and Section 9 discuss additional considerations for the
integration with HTTP.
5.1. Cache Interaction
A DoH exchange can pass through a hierarchy of caches that include
both HTTP- and DNS-specific caches. These caches may exist between
the DoH server and client, or on the DoH client itself. HTTP caches
are by design generic; that is, they do not understand this protocol.
Even if a DoH client has modified its cache implementation to be
aware of DoH semantics, it does not follow that all upstream caches
(for example, inline proxies, server-side gateways and Content
Delivery Networks) will be.
Hoffman & McManus Expires February 17, 2019 [Page 7]
Internet-Draft DNS Queries over HTTPS (DoH) August 2018
As a result, DoH servers need to carefully consider the HTTP caching
metadata they send in response to GET requests (responses to POST
requests are not cacheable unless specific response header fields are
sent; this is not widely implemented, and not advised for DoH).
In particular, DoH servers SHOULD assign an explicit HTTP freshness
lifetime ([RFC7234] Section 4.2) so that the DoH client is more
likely to use fresh DNS data. This requirement is due to HTTP caches
being able to assign their own heuristic freshness (such as that
described in [RFC7234] Section 4.2.2), which would take control of
the cache contents out of the hands of the DoH server.
The assigned freshness lifetime of a DoH HTTP response MUST be less
than or equal to the smallest TTL in the Answer section of the DNS
response. A freshness lifetime equal to the smallest TTL in the
Answer section is RECOMMENDED. For example, if a HTTP response
carries three RRsets with TTLs of 30, 600, and 300, the HTTP
freshness lifetime should be 30 seconds (which could be specified as
"Cache-Control: max-age=30"). This requirement helps prevent exipred
RRsets in messages in an HTTP cache from unintentionally being
served.
If the DNS response has no records in the Answer section, and the DNS
response has an SOA record in the Authority section, the response
freshness lifetime MUST NOT be greater than the MINIMUM field from
that SOA record (see [RFC2308]).
The stale-while-revalidate and stale-if-error Cache-Control
directives ([RFC5861]) could be well-suited to a DoH implementation
when allowed by server policy. Those mechanisms allow a client, at
the server's discretion, to reuse an HTTP cache entry that is no
longer fresh. In such a case, the client reuses all of a cached
entry, or none of it.
DoH servers also need to consider HTTP caching when generating
responses that are not globally valid. For instance, if a DoH server
customizes a response based on the client's identity, it would not
want to allow global reuse of that response. This could be
accomplished through a variety of HTTP techniques such as a Cache-
Control max-age of 0, or by using the Vary response header field
([RFC7231] Section 7.1.4) to establish a secondary cache key
([RFC7234] Section 4.1).
DoH clients MUST account for the Age response header field's value
([RFC7234]) when calculating the DNS TTL of a response. For example,
if an RRset is received with a DNS TTL of 600, but the Age header
field indicates that the response has been cached for 250 seconds,
Hoffman & McManus Expires February 17, 2019 [Page 8]
Internet-Draft DNS Queries over HTTPS (DoH) August 2018
the remaining lifetime of the RRset is 350 seconds. This requirement
applies to both DoH client HTTP caches and DoH client DNS caches.
DoH clients can request an uncached copy of a HTTP response by using
the "no-cache"Specific
Procedures", apply only to the latter case.
6.1. Common Procedures
For the purpose of processing the ERO in a Path/Request message of an
LSP that is to be tunneled over an FA, an LSR at the head-end of the
FA-LSP views the LSR at the tail of that FA-LSP as adjacent (one IP
hop away).
How this is to be achieved for RSVP-TE and CR-LDP is described in the
following subsections.
In either case (RSVP-TE or CR-LDP), when an LSP is tunneled through
an FA-LSP, the LSR at the head-end of the FA-LSP subtracts the LSP's
bandwidth from the unreserved bandwidth of the FA.
In the presence of link bundling (when link bundling is applied to
FAs), when an LSP is tunneled through an FA-LSP, the LSR at the
head-end of the FA-LSP also needs to adjust Max LSP bandwidth of the
FA.
6.1.1. RSVP-TE
If one uses RSVP-TE to signal an LSP to be tunneled over an FA-LSP,
then the Path message MUST contain an IF_ID RSVP_HOP object
[GRSVP-TE, GSIG] instead of an RSVP_HOP object; and the data
interface identification MUST identify the FA-LSP.
The preferred method of sending the Path message is to set the
destination IP address of the Path message to the computed NHOP for
that Path message. This NHOP address must be a routable address; in
the case of separate control and data planes, this must be a control
plane address.
Kompella & Rekhter Standards Track [Page 8]
RFC 4206 LSP Hierarchy with GMPLS TE October 2005
Furthermore, the IP header for the Path message MUST NOT have the
Router Alert option. The Path message is intended to be IP-routed to
the tail-end of the FA-LSP without being intercepted and processed as
an RSVP message by any of the intermediate nodes.
Finally, the IP TTL vs. RSVP TTL check MUST NOT be made. In general,
if the IF_ID RSVP_HOP object is used, this check must be disabled, as
the number of hops over the control plane may be greater than one.
Instead, the following check is done by the receiver Y of the IF_ID
RSVP_HOP object:
1. Make sure that the data interface identified in the IF_ID RSVP_HOP
object actually terminates on Y.
2. Find the "other end" of the above data interface, say X. Make
sure that the PHOP in the IF_ID RSVP_HOP object is a control
channel address that belongs to the same node as X.
How check #2 is carried out is beyond the scope of this document;
suffice it to say that it may require a Traffic Engineering Database,
or the use of LMP [LMP], or yet other means.
An alternative method is to encapsulate the Path message in an IP
tunnel (or, in the case that the Interface Switching Capability of
the FA-LSP is PSC[1-4], in the FA-LSP itself), and unicast the
message to the tail-end of the FA-LSP, without the Router Alert
option. This option may be needed if intermediate nodes process RSVP
messages regardless of whether the Router Alert option is present.
A PathErr sent in response to a Path message with an IF_ID RSVP_HOP
object SHOULD contain an IF_ID HOP object. (Note: a PathErr does not
normally carry an RSVP_HOP object, but in the case of separated
control and data, it is necessary to identify the data channel in the
PathErr message.)
The Resv message back to the head-end of the FA-LSP (PHOP) is IP-
routed to the PHOP in the Path message. If necessary, Resv Messages
MAY be encapsulated in another IP header whose destination IP address
is the PHOP of the received Path message.
6.1.2. CR-LDP
If one uses CR-LDP to signal an LSP to be tunneled over an FA-LSP,
then the Request message MUST contain an IF_ID TLV [GCR-LDP] object,
and the data interface identification MUST identify the FA-LSP.
Kompella & Rekhter Standards Track [Page 9]
RFC 4206 LSP Hierarchy with GMPLS TE October 2005
Furthermore, the head-end LSR must create a targeted LDP session with
the tail-end LSR. The Request (Mapping) message is unicast from the
head-end (tail-end) to the tail-end (head-end).
6.2. Specific Procedures
When an LSR receives a Path/Request message, the LSR determines
whether it is at the edge of a region with respect to the ERO carried
in the message. The LSR does this by looking up the interface
switching capabilities of the previous hop and the next hop in its
IGP database, and comparing them using the relation defined in this
section. If the LSR is not at the edge of a region, the procedures
in this section do not apply.
If the LSR is at the edge of a region, it must then determine the
other edge of the region with respect to the ERO, again using the IGP
database. The LSR then extracts (from the ERO) the subsequence of
hops from itself to the other end of the region.
The LSR then compares the subsequence of hops with all existing FA-
LSPs originated by the LSR. If a match is found, that FA-LSP has
enough unreserved bandwidth for the LSP being signaled, the L3PID of
the FA-LSP is compatible with the L3PID of the LSP being signaled,
and the LSR uses that FA-LSP as follows. The Path/Request message
for the original LSP is sent to the egress of the FA-LSP, not to the
next hop along the FA-LSP's path. The PHOP in the message is the
address of the LSR at the head-end of the FA-LSP. Before sending the
Path/Request message, the ERO in that message is adjusted by removing
the subsequence of the ERO that lies in the FA-LSP, and replacing it
with just the end point of the FA-LSP.
Otherwise (if no existing FA-LSP is found), the LSR sets up a new
FA-LSP. That is, it initiates a new LSP setup just for the FA-LSP.
Note that the new LSP may traverse either 'basic' TE links or FAs.
After the LSR establishes the new FA-LSP, the LSR announces this LSP
into IS-IS/OSPF as an FA.
The unreserved bandwidth of the FA is computed by subtracting the
bandwidth of sessions pending the establishment of the FA-LSP
associated from the bandwidth of the FA-LSP.
An FA-LSP could be torn down by the LSR at the head-end of the FA-LSP
as a matter of policy local to the LSR. It is expected that the FA-
LSP would be torn down once there are no more LSPs carried by the
FA-LSP. When the FA-LSP is torn down, the FA associated with the
FA-LSP is no longer advertised into IS-IS/OSPF.
Kompella & Rekhter Standards Track [Page 10]
RFC 4206 LSP Hierarchy with GMPLS TE October 2005
6.3. FA-LSP Holding Priority
The value of the holding priority of an FA-LSP must be the minimum of
the configured holding priority of the FA-LSP and the holding
priorities of the LSPs tunneling through the FA-LSP (note that
smaller priority values denote higher priority). Thus, if an LSP of
higher priority than the FA-LSP tunnels through the FA-LSP, the FA-
LSP is itself promoted to the higher priority. However, if the
tunneled LSP is torn down, the FA-LSP need not drop its priority to
its old value right away; it may be advisable to apply hysteresis in
this case.
If the holding priority of an FA-LSP is configured, this document
restricts it to 0.
7. Security Considerations
From a security point of view, the primary change introduced in this
document is that the implicit assumption of a binding between data
interfaces and the interface over which a control message is sent is
no longer valid.
This means that the "sending interface" or "receiving interface" is
no longer well-defined, as the interface over which an RSVP message
is sent may change as routing changes. Therefore, mechanisms that
depend on these concepts (for example, the definition of a security
association) need a clearer definition.
[RFC2747] provides a solution: in Section 2.1, under "Key
Identifier", an IP address is a valid identifier for the sending (and
by analogy, receiving) interface. Since RSVP messages for a given
LSP are sent to an IP address that identifies the next/previous hop
for the LSP, one can replace all occurrences of 'sending [receiving]
interface' with 'receiver's [sender's] IP address' (respectively).
For example, in Section 4, third paragraph, instead of:
"Each sender SHOULD have distinct security associations (and keys)
per secured sending interface (or LIH). ... At the sender,
security association selection is based on the interface through
which the message is sent."
it should read:
"Each sender SHOULD have distinct security associations (and keys)
per secured receiver's IP address. ... At the sender, security
association selection is based on the IP address to which the
message is sent."
Kompella & Rekhter Standards Track [Page 11]
RFC 4206 LSP Hierarchy with GMPLS TE October 2005
Note that CR-LDP does not have this issue, as CR-LDP messages are
sent over TCP sessions, and no assumption is made that these sessions
are to direct neighbors. The recommended mechanism for
authentication and integrity of LDP message exchange is to use the
TCP MD5 option [LDP].
Another consequence (relevant to RSVP) of the changes proposed in
this document is that IP destination address of Path messages be set
to the receiver's address, not to the session destination. Thus, the
objections raised in Section 1.2 of [RFC2747] should be revisited to
see if IPSec AH is now a viable means of securing RSVP-TE messages.
8. Acknowledgements
Many thanks to Alan Hannan, whose early discussions with Yakov
Rekhter contributed greatly to the notion of Forwarding Adjacencies.
We would also like to thank George Swallow, Quaizar Vohra and Ayan
Banerjee.
9. Normative References
[GCR-LDP] Ashwood-Smith, P. and L. Berger, "Generalized Multi-
Protocol Label Switching (GMPLS) Signaling Constraint-
based Routed Label Distribution Protocol (CR-LDP)
Extensions", RFC 3472, January 2003.
[GMPLS-ISIS] Kompella, K., Ed., and Y. Rekhter, Ed., "Intermediate
System to Intermediate System (IS-IS) Extensions in
Support of Generalized Multi-Protocol Label Switching
(GMPLS)", RFC 4205, October 2005.
[GMPLS-OSPF] Kompella, K., Ed., and Y. Rekhter, Ed., "OSPF
Extensions in Support of Generalized Multi-Protocol
Label Switching (GMPLS)", RFC 4203, October 2005.
[GRSVP-TE] Berger, L., "Generalized Multi-Protocol Label Switching
(GMPLS) Signaling Resource ReserVation Protocol-Traffic
Engineering (RSVP-TE) Extensions", RFC 3473, January
2003.
[GSIG] Berger, L., "Generalized Multi-Protocol Label Switching
(GMPLS) Signaling Functional Description", RFC 3471,
January 2003.
[ISIS-TE] Smit, H. and T. Li, "Intermediate System to
Intermediate System (IS-IS) Extensions for Traffic
Engineering (TE)", RFC 3784, June 2004.
Kompella & Rekhter Standards Track [Page 12]
RFC 4206 LSP Hierarchy with GMPLS TE October 2005
[LDP] Andersson, L., Doolan, P., Feldman, N., Fredette, A.,
and B. Thomas, "Label Distribution Protocol", RFC 3036,
January 2001.
[OSPF-TE] Katz, D., Kompella, K., and D. Yeung, "Traffic
Engineering (TE) Extensions to OSPF Version 2", RFC
3630, September 2003.
[UNNUM-CRLDP] Kompella, K., Rekhter, Y., and A. Kullberg, "Signalling
Unnumbered Links in CR-LDP (Constraint-Routing Label
Distribution Protocol)", RFC 3480, February 2003.
[UNNUM-RSVP] Kompella, K. and Y. Rekhter, "Signalling Unnumbered
Links in Resource ReSerVation Protocol - Traffic
Engineering (RSVP-TE)", RFC 3477, January 2003.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2747] Baker, F., Lindell, B., and M. Talwar, "RSVP
Cryptographic Authentication", RFC 2747, January 2000.
10. Informative References
[BUNDLE] Kompella, K., Rekhter, Y., and L. Berger, "Link
Bundling in MPLS Traffic Engineering (TE)", RFC 4201,
October 2005.
[LMP] Lang, L., Ed., "Link Management Protocol (LMP)", RFC
4204, October 2005.
Authors' Addresses
Kireeti Kompella
Juniper Networks, Inc.
1194 N. Mathilda Ave
Sunnyvale, CA 94089
EMail: kireeti@juniper.net
Yakov Rekhter
Juniper Networks, Inc.
1194 N. Mathilda Ave
Sunnyvale, CA 94089
EMail: yakov@juniper.net
Kompella & Rekhter Standards Track [Page 13]
RFC 4206 LSP Hierarchy with GMPLS TE October 2005
Full Copyright Statement
Copyright (C) The Internet Society (2005).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Kompella & Rekhter Standards Track [Page 14]