Distributed-Denial-of-Service Open Threat Signaling (DOTS) Agent Discovery
draft-ietf-dots-server-discovery-07
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft that was ultimately published as RFC 8973.
|
|
|---|---|---|---|
| Authors | Mohamed Boucadair , Tirumaleswar Reddy.K | ||
| Last updated | 2020-01-07 | ||
| Replaces | draft-boucadair-dots-server-discovery | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Formats | |||
| Reviews |
GENART Last Call review
(of
-12)
by Peter Yee
Ready w/issues
TSVART Last Call review
(of
-11)
by Kyle Rose
Ready w/issues
|
||
| Additional resources | Mailing list discussion | ||
| Stream | WG state | WG Consensus: Waiting for Write-Up | |
| Associated WG milestone |
|
||
| Document shepherd | Valery Smyslov | ||
| IESG | IESG state | Became RFC 8973 (Proposed Standard) | |
| Consensus boilerplate | Yes | ||
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | Valery Smyslov <valery@smyslov.net> |
draft-ietf-dots-server-discovery-07
DOTS M. Boucadair
Internet-Draft Orange
Intended status: Standards Track T. Reddy
Expires: July 10, 2020 McAfee
January 7, 2020
Distributed-Denial-of-Service Open Threat Signaling (DOTS) Agent
Discovery
draft-ietf-dots-server-discovery-07
Abstract
It may not be possible for a network to determine the cause for an
attack, but instead just realize that some resources seem to be under
attack. To fill that gap, Distributed-Denial-of-Service Open Threat
Signaling (DOTS) allows a network to inform a DOTS server that it is
under a potential attack so that appropriate mitigation actions are
undertaken.
This document specifies mechanisms to configure DOTS clients with
their DOTS servers. The discovery procedure also covers the DOTS
Signal Channel Call Home.
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 July 10, 2020.
Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
Boucadair & Reddy Expires July 10, 2020 [Page 1]
Internet-Draft DOTS Server/Call Home Client Discovery January 2020
(https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Why Multiple Discovery Mechanisms? . . . . . . . . . . . . . 5
4. Unified DOTS Discovery Procedure . . . . . . . . . . . . . . 6
5. DHCP Options for DOTS Agent Discovery . . . . . . . . . . . . 8
5.1. DHCPv6 DOTS Options . . . . . . . . . . . . . . . . . . . 9
5.1.1. Format of DOTS Reference Identifier Option . . . . . 9
5.1.2. Format of DOTS Address Option . . . . . . . . . . . . 10
5.1.3. DHCPv6 Client Behavior . . . . . . . . . . . . . . . 10
5.2. DHCPv4 DOTS Options . . . . . . . . . . . . . . . . . . . 11
5.2.1. Format of DOTS Reference Identifier Option . . . . . 11
5.2.2. Format of DOTS Address Option . . . . . . . . . . . . 12
5.2.3. DHCPv4 Client Behavior . . . . . . . . . . . . . . . 13
6. Discovery using Service Resolution . . . . . . . . . . . . . 13
7. DNS Service Discovery . . . . . . . . . . . . . . . . . . . . 16
8. Security Considerations . . . . . . . . . . . . . . . . . . . 16
8.1. DHCP . . . . . . . . . . . . . . . . . . . . . . . . . . 16
8.2. Service Resolution . . . . . . . . . . . . . . . . . . . 16
8.3. DNS Service Discovery . . . . . . . . . . . . . . . . . . 17
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
9.1. The Service Name and Transport Protocol Port Number
Registry . . . . . . . . . . . . . . . . . . . . . . . . 17
9.2. DHCPv6 Options . . . . . . . . . . . . . . . . . . . . . 17
9.3. DHCPv4 Options . . . . . . . . . . . . . . . . . . . . . 17
9.4. Application Service & Application Protocol Tags . . . . . 18
9.4.1. DOTS Application Service Tag Registration . . . . . . 18
9.4.2. DOTS Call Home Application Service Tag Registration . 18
9.4.3. signal.udp Application Protocol Tag Registration . . 18
9.4.4. signal.tcp Application Protocol Tag Registration . . 19
9.4.5. data.tcp Application Protocol Tag Registration . . . 19
10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 19
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 20
12.1. Normative References . . . . . . . . . . . . . . . . . . 20
12.2. Informative References . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22
Boucadair & Reddy Expires July 10, 2020 [Page 2]
Internet-Draft DOTS Server/Call Home Client Discovery January 2020
1. Introduction
DDoS Open Threat Signaling (DOTS) [I-D.ietf-dots-architecture]
specifies an architecture, in which a DOTS client can inform a DOTS
server that the network is under a potential attack and that
appropriate mitigation actions are required. Indeed, because the
lack of a common method to coordinate a real-time response among
involved actors and network domains inhibits the effectiveness of
DDoS attack mitigation, DOTS signal channel protocol
[I-D.ietf-dots-signal-channel] is meant to carry requests for DDoS
attack mitigation, thereby reducing the impact of an attack and
leading to more efficient defensive actions in various deployment
scenarios such as those discussed in [I-D.ietf-dots-use-cases].
Moreover, DOTS clients can instruct a DOTS server to install
filtering rules by means of the DOTS data channel protocol
[I-D.ietf-dots-data-channel].
The basic high-level DOTS architecture is illustrated in Figure 1:
+-----------+ +-------------+
| Mitigator | ~~~~~~~~~~ | DOTS Server |
+-----------+ +------+------+
|
|
|
+---------------+ +------+------+
| Attack Target | ~~~~~~ | DOTS Client |
+---------------+ +-------------+
Figure 1: Basic DOTS Architecture
[I-D.ietf-dots-architecture] specifies that the DOTS client may be
provided with a list of DOTS servers; each associated with one or
more IP addresses. These addresses may or may not be of the same
address family. The DOTS client establishes one or more DOTS
sessions by connecting to the provided DOTS server addresses.
This document specifies methods for DOTS clients to discover their
DOTS server(s). The rationale for specifying multiple discovery
mechanisms is discussed in Section 3.
The discovery methods can also be used by a DOTS server to locate a
DOTS client in the context of DOTS Signal Channel Call Home
[I-D.ietf-dots-signal-call-home]. The basic high-level DOTS Call
Home architecture is illustrated in Figure 2:
Boucadair & Reddy Expires July 10, 2020 [Page 3]
Internet-Draft DOTS Server/Call Home Client Discovery January 2020
+---------------+ +-------------+
| Alert/DMS/ | ~~~~~~ | Call Home |
| Peer DMS/... | | DOTS client |
+---------------+ +------+------+
|
|
|
+---------------+ +------+------+
| Attack | ~~~~~~ | Call Home |
| Source(s) | | DOTS server |
+---------------+ +-------------+
Figure 2: Basic DOTS Signal Channel Call Home Functional Architecture
A DOTS agent may be used to establish base DOTS channels, DOTS Call
Home, or both. This specification accommodates all these deployment
cases.
Considerations for the selection of DOTS server(s) by multi-homed
DOTS clients are out of scope; readers should refer to
[I-D.ietf-dots-multihoming] for more details.
This document assumes that security credentials to authenticate DOTS
server(s) are provisioned to a DOTS client using a variety of means
such as (but not limited to) those discussed in [RFC8572] or
[I-D.ietf-anima-bootstrapping-keyinfra]. DOTS clients use those
credentials for authentication purposes following the rules
documented in [I-D.ietf-dots-signal-channel].
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDEDAbstract
The Hypertext Transfer Protocol (HTTP) is an application-level
protocol for distributed, collaborative, hypertext information
systems. HTTP has been in use by the World Wide Web global
information initiative since 1990. This document provides an
overview of HTTP architecture and its associated terminology, defines
the "http" and "https" Uniform Resource Identifier (URI) schemes,
defines the HTTP/1.1 message syntax and parsing requirements, and
describes general security concerns for implementations.
Editorial Note (To be removed by RFC Editor)
Discussion of this draft takes place on the HTTPBIS working group
mailing list (ietf-http-wg@w3.org), which is archived at
<http://lists.w3.org/Archives/Public/ietf-http-wg/>.
The current issues list is at
<http://tools.ietf.org/wg/httpbis/trac/report/3> and related
documents (including fancy diffs) can be found at
<http://tools.ietf.org/wg/httpbis/>.
The changes in this draft are summarized in Appendix D.2.
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 http://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
Fielding & Reschke Expires August 27, 2013 [Page 1]
Internet-Draft HTTP/1.1 Message Syntax and Routing February 2013
material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 27, 2013.
Copyright Notice
Copyright (c) 2013 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
(http://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.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.1. Requirement Notation . . . . . . . . . . . . . . . . . . . 6
1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 6
2. Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1. Client/Server Messaging . . . . . . . . . . . . . . . . . 7
2.2. Implementation Diversity . . . . . . . . . . . . . . . . . 8
2.3. Intermediaries . . . . . . . . . . . . . . . . . . . . . . 9
2.4. Caches . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.5. Conformance and Error Handling . . . . . . . . . . . . . . 12
2.6. Protocol Versioning . . . . . . . . . . . . . . . . . . . 13
2.7. Uniform Resource Identifiers . . . . . . . . . . . . . . . 15
2.7.1. http URI scheme . . . . . . . . . . . . . . . . . . . 16
2.7.2. https URI scheme . . . . . . . . . . . . . . . . . . . 17
2.7.3. http and https URI Normalization and Comparison . . . 18
3. Message Format . . . . . . . . . . . . . . . . . . . . . . . . 19
Fielding & Reschke Expires August 27, 2013 [Page 2]
Internet-Draft HTTP/1.1 Message Syntax and Routing February 2013
3.1. Start Line . . . . . . . . . . . . . . . . . . . . . . . . 19
3.1.1. Request Line . . . . . . . . . . . . . . . . . . . . . 20
3.1.2. Status Line . . . . . . . . . . . . . . . . . . . . . 21
3.2. Header Fields . . . . . . . . . . . . . . . . . . . . . . 22
3.2.1. Field Extensibility . . . . . . . . . . . . . . . . . 22
3.2.2. Field Order . . . . . . . . . . . . . . . . . . . . . 22
3.2.3. Whitespace . . . . . . . . . . . . . . . . . . . . . . 23
3.2.4. Field Parsing . . . . . . . . . . . . . . . . . . . . 24
3.2.5. Field Limits . . . . . . . . . . . . . . . . . . . . . 25
3.2.6. Field value components . . . . . . . . . . . . . . . . 25
3.3. Message Body . . . . . . . . . . . . . . . . . . . . . . . 26
3.3.1. Transfer-Encoding . . . . . . . . . . . . . . . . . . 27
3.3.2. Content-Length . . . . . . . . . . . . . . . . . . . . 28
3.3.3. Message Body Length . . . . . . . . . . . . . . . . . 30
3.4. Handling Incomplete Messages . . . . . . . . . . . . . . . 32
3.5. Message Parsing Robustness . . . . . . . . . . . . . . . . 33
4. Transfer Codings . . . . . . . . . . . . . . . . . . . . . . . 33
4.1. Chunked Transfer Coding . . . . . . . . . . . . . . . . . 34
4.1.1. Trailer . . . . . . . . . . . . . . . . . . . . . . . 35
4.1.2. Decoding chunked . . . . . . . . . . . . . . . . . . . 36
4.2. Compression Codings . . . . . . . . . . . . . . . . . . . 37
4.2.1. Compress Coding . . . . . . . . . . . . . . . . . . . 37
4.2.2. Deflate Coding . . . . . . . . . . . . . . . . . . . . 37
4.2.3. Gzip Coding . . . . . . . . . . . . . . . . . . . . . 37
4.3. TE . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
5. Message Routing . . . . . . . . . . . . . . . . . . . . . . . 38
5.1. Identifying a Target Resource . . . . . . . . . . . . . . 38
5.2. Connecting Inbound . . . . . . . . . . . . . . . . . . . . 39
5.3. Request Target . . . . . . . . . . . . . . . . . . . . . . 39
5.4. Host . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
5.5. Effective Request URI . . . . . . . . . . . . . . . . . . 43
5.6. Associating a Response to a Request . . . . . . . . . . . 44
5.7. Message Forwarding . . . . . . . . . . . . . . . . . . . . 44
5.7.1. Via . . . . . . . . . . . . . . . . . . . . . . . . . 45
5.7.2. Transformations . . . . . . . . . . . . . . . . . . . 46
6. Connection Management . . . . . . . . . . . . . . . . . . . . 47
6.1. Connection . . . . . . . . . . . . . . . . . . . . . . . . 48
6.2. Establishment . . . . . . . . . . . . . . . . . . . . . . 49
6.3. Persistence . . . . . . . . . . . . . . . . . . . . . . . 49
6.3.1. Retrying Requests . . . . . . . . . . . . . . . . . . 50
6.3.2. Pipelining . . . . . . . . . . . . . . . . . . . . . . 51
6.4. Concurrency . . . . . . . . . . . . . . . . . . . . . . . 52
6.5. Failures and Time-outs . . . . . . . . . . . . . . . . . . 52
6.6. Tear-down . . . . . . . . . . . . . . . . . . . . . . . . 53
6.7. Upgrade . . . . . . . . . . . . . . . . . . . . . . . . . 54
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 55
7.1. Header Field Registration . . . . . . . . . . . . . . . . 55
7.2. URI Scheme Registration . . . . . . . . . . . . . . . . . 56
Fielding & Reschke Expires August 27, 2013 [Page 3]
Internet-Draft HTTP/1.1 Message Syntax and Routing February 2013
7.3. Internet Media Type Registration . . . . . . . . . . . . . 56
7.3.1. Internet Media Type message/http . . . . . . . . . . . 57
7.3.2. Internet Media Type application/http . . . . . . . . . 58
7.4. Transfer Coding Registry . . . . . . . . . . . . . . . . . 59
7.5. Transfer Coding Registration . . . . . . . . . . . . . . . 59
7.6. Upgrade Token Registry . . . . . . . . . . . . . . . . . . 60
7.7. Upgrade Token Registration . . . . . . . . . . . . . . . . 61
8. Security Considerations . . . . . . . . . . . . . . . . . . . 61
8.1. DNS-related Attacks . . . . . . . . . . . . . . . . . . . 61
8.2. Intermediaries and Caching . . . . . . . . . . . . . . . . 61
8.3. Buffer Overflows . . . . . . . . . . . . . . . . . . . . . 62
8.4. Message Integrity . . . . . . . . . . . . . . . . . . . . 62
8.5. Server Log Information . . . . . . . . . . . . . . . . . . 63
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 63
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 65
10.1. Normative References . . . . . . . . . . . . . . . . . . . 65
10.2. Informative References . . . . . . . . . . . . . . . . . . 66
Appendix A. HTTP Version History . . . . . . . . . . . . . . . . 68
A.1. Changes from HTTP/1.0 . . . . . . . . . . . . . . . . . . 69
A.1.1. Multi-homed Web Servers . . . . . . . . . . . . . . . 69
A.1.2. Keep-Alive Connections . . . . . . . . . . . . . . . . 69
A.1.3. Introduction of Transfer-Encoding . . . . . . . . . . 70
A.2. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 70
Appendix B. ABNF list extension: #rule . . . . . . . . . . . . . 72
Appendix C. Collected ABNF . . . . . . . . . . . . . . . . . . . 73
Appendix D. Change Log (to be removed by RFC Editor before
publication) . . . . . . . . . . . . . . . . . . . . 76
D.1. Since RFC 2616 . . . . . . . . . . . . . . . . . . . . . . 76
D.2. Since draft-ietf-httpbis-p1-messaging-21 . . . . . . . . . 76
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
Fielding & Reschke Expires August 27, 2013 [Page 4]
Internet-Draft HTTP/1.1 Message Syntax and Routing February 2013
1. Introduction
The Hypertext Transfer Protocol (HTTP) is an application-level
request/response protocol that uses extensible semantics and self-
descriptive message payloads for flexible interaction with network-
based hypertext information systems. This document is the first in a
series of documents that collectively form the HTTP/1.1
specification:
RFC xxx1: Message Syntax and Routing
RFC xxx2: Semantics and Content
RFC xxx3: Conditional Requests
RFC xxx4: Range Requests
RFC xxx5: Caching
RFC xxx6: Authentication
This HTTP/1.1 specification obsoletes and moves to historic status
RFC 2616, its predecessor RFC 2068, and RFC 2145 (on HTTP
versioning). This specification also updates the use of CONNECT to
establish a tunnel, previously defined in RFC 2817, and defines the
"https" URI scheme that was described informally in RFC 2818.
HTTP is a generic interface protocol for information systems. It is
designed to hide the details of how a service is implemented by
presenting a uniform interface to clients that is independent of the
types of resources provided. Likewise, servers do not need to be
aware of each client's purpose: an HTTP request can be considered in
isolation rather than being associated with a specific type of client
or a predetermined sequence of application steps. The result is a
protocol that can be used effectively in many different contexts and
for which implementations can evolve independently over time.
HTTP is also designed for use as an intermediation protocol for
translating communication to and from non-HTTP information systems.
HTTP proxies and gateways can provide access to alternative
information services by translating their diverse protocols into a
hypertext format that can be viewed and manipulated by clients in the
same way as HTTP services.
One consequence of this flexibility is that the protocol cannot be
defined in terms of what occurs behind the interface. Instead, we
are limited to defining the syntax of communication, the intent of
received communication, and the expected behavior of recipients. If
Fielding & Reschke Expires August 27, 2013 [Page 5]
Internet-Draft HTTP/1.1 Message Syntax and Routing February 2013
the communication is considered in isolation, then successful actions
ought to be reflected in corresponding changes to the observable
interface provided by servers. However, since multiple clients might
act in parallel and perhaps at cross-purposes, we cannot require that
such changes be observable beyond the scope of a single response.
This document describes the architectural elements that are used or
referred to in HTTP, defines the "http" and "https" URI schemes,
describes overall network operation and connection management, and
defines HTTP message framing and forwarding requirements. Our goal
is to define all of the mechanisms necessary for HTTP message
handling that are independent of message semantics, thereby defining
the complete set of requirements for message parsers and message-
forwarding intermediaries.
1.1. Requirement Notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
Conformance criteria and considerations regarding error handling are
defined in Section 2.5.
1.2. Syntax Notation
This specification uses the Augmented Backus-Naur Form (ABNF)
notation of [RFC5234] with the list rule extension defined in
Appendix B. Appendix C shows the collected ABNF with the list rule
expanded.
The following core rules are included by reference, as defined in
[RFC5234], Appendix B.1: ALPHA (letters), CR (carriage return), CRLF
(CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote),
HEXDIG (hexadecimal 0-9/A-F/a-f), HTAB (horizontal tab), LF (line
feed), OCTET (any 8-bit sequence of data), SP (space), and VCHAR (any
visible [USASCII] character).
As a convention, ABNF rule names prefixed with "obs-" denote
"obsolete" grammar rules that appear for historical reasons.
2. Architecture
HTTP was created for the World Wide Web architecture and has evolved
over time to support the scalability needs of a worldwide hypertext
system. Much of that architecture is reflected in the terminology
and syntax productions used to define HTTP.
Fielding & Reschke Expires August 27, 2013 [Page 6]
Internet-Draft HTTP/1.1 Message Syntax and Routing February 2013
2.1. Client/Server Messaging
HTTP is a stateless request/response protocol that operates by
exchanging messages (Section 3) across a reliable transport or
session-layer "connection" (Section 6). An HTTP "client" is a
program that establishes a connection to a server for the purpose of
sending one or more HTTP requests. An HTTP "server" is a program
that accepts connections in order to service HTTP requests by sending
HTTP responses.
The terms client and server refer only to the roles that these
programs perform for a particular connection. The same program might
act as a client on some connections and a server on others. We use
the term "user agent" to refer to any of the various client programs
that initiate a request, including (but not limited to) browsers,
spiders (web-based robots), command-line tools, native applications,
and mobile apps. The term "origin server" is used to refer to the
program that can originate authoritative responses to a request. For
general requirements, we use the terms "sender" and "recipient" to
refer to any component that sends or receives, respectively, a given
message.
HTTP relies upon the Uniform Resource Identifier (URI) standard
[RFC3986] to indicate the target resource (Section 5.1) and
relationships between resources. Messages are passed in a format
similar to that used by Internet mail [RFC5322] and the Multipurpose
Internet Mail Extensions (MIME) [RFC2045] (see Appendix A of [Part2]
for the differences between HTTP and MIME messages).
Most HTTP communication consists of a retrieval request (GET) for a
representation of some resource identified by a URI. In the simplest
case, this might be accomplished via a single bidirectional
connection (===) between the user agent (UA) and the origin server
(O).
request >
UA ======================================= O
< response
A client sends an HTTP request to a server in the form of a request
message, beginning with a request-line that includes a method, URI,
and protocol version (Section 3.1.1), followed by header fields
containing request modifiers, client information, and representation
metadata (Section 3.2), an empty line to indicate the end of the
header section, and finally a message body containing the payload
body (if any, Section 3.3).
A server responds to a client's request by sending one or more HTTP
Fielding & Reschke Expires August 27, 2013 [Page 7]
Internet-Draft HTTP/1.1 Message Syntax and Routing February 2013
response messages, each beginning with a status line that includes
the protocol version, a success or error code, and textual reason
phrase (Section 3.1.2), possibly followed by header fields containing
server information, resource metadata, and representation metadata
(Section 3.2), an empty line to indicate the end of the header
section, and finally a message body containing the payload body (if
any, Section 3.3).
A connection might be used for multiple request/response exchanges,
as defined in Section 6.3.
The following example illustrates a typical message exchange for a
GET request on the URI "http://www.example.com/hello.txt":
client request:
GET /hello.txt HTTP/1.1
User-Agent: curl/7.16.3 libcurl/7.16.3 OpenSSL/0.9.7l zlib/1.2.3
Host: www.example.com
Accept-Language: en, mi
server response:
HTTP/1.1 200 OK
Date: Mon, 27 Jul 2009 12:28:53 GMT
Server: Apache
Last-Modified: Wed, 22 Jul 2009 19:15:56 GMT
ETag: "34aa387-d-1568eb00"
Accept-Ranges: bytes
Content-Length: 14
Vary: Accept-Encoding
Content-Type: text/plain
Hello World!
(Note that the content length includes the trailing CR/LF sequence of
the body text)
2.2. Implementation Diversity
When considering the design of HTTP, it is easy to fall into a trap
of thinking that all user agents are general-purpose browsers and all
origin servers are large public websites. That is not the case in
practice. Common HTTP user agents include household appliances,
stereos, scales, firmware update scripts, command-line programs,
mobile apps, and communication devices in a multitude of shapes and
sizes. Likewise, common HTTP origin servers include home automation
Fielding & Reschke Expires August 27, 2013 [Page 8]
Internet-Draft HTTP/1.1 Message Syntax and Routing February 2013
units, configurable networking components, office machines,
autonomous robots, news feeds, traffic cameras, ad selectors, and
video delivery platforms.
The term "user agent" does not imply that there is a human user
directly interacting with the software agent at the time of a
request. In many cases, a user agent is installed or configured to
run in the background and save its results for later inspection (or
save only a subset of those results that might be interesting or
erroneous). Spiders, for example, are typically given a start URI
and configured to follow certain behavior while crawling the Web as a
hypertext graph.
The implementation diversity of HTTP means that we cannot assume the
user agent can make interactive suggestions to a user or provide
adequate warning for security or privacy options. In the few cases
where this specification requires reporting of errors to the user, it
is acceptable for such reporting to only be observable in an error
console or log file. Likewise, requirements that an automated action
be confirmed by the user before proceeding can be met via advance
configuration choices, run-time options, or simply not proceeding
with the unsafe action.
2.3. Intermediaries
HTTP enables the use of intermediaries to satisfy requests through a
chain of connections. There are three common forms of HTTP
intermediary: proxy, gateway, and tunnel. In some cases, a single
intermediary might act as an origin server, proxy, gateway, or
tunnel, switching behavior based on the nature of each request.
> > > >
UA =========== A =========== B =========== C =========== O
< < < <
The figure above shows three intermediaries (A, B, and C) between the
user agent and origin server. A request or response message that
travels the whole chain will pass through four separate connections.
Some HTTP communication options might apply only to the connection
with the nearest, non-tunnel neighbor, only to the end-points of the
chain, or to all connections along the chain. Although the diagram
is linear, each participant might be engaged in multiple,
simultaneous communications. For example, B might be receiving
requests from many clients other than A, and/or forwarding requests
to servers other than C, at the same time that it is handling A's
request.
We use the terms "upstream" and "downstream" to describe various
Fielding & Reschke Expires August 27, 2013 [Page 9]
Internet-Draft HTTP/1.1 Message Syntax and Routing February 2013
requirements in relation to the directional flow of a message: all
messages flow from upstream to downstream. Likewise, we use the
terms inbound and outbound to refer to directions in relation to the
request path: "inbound" means toward the origin server and "outbound"
means toward the user agent.
A "proxy" is a message forwarding agent that is selected by the
client, usually via local configuration rules, to receive requests
for some type(s) of absolute URI and attempt to satisfy those
requests via translation through the HTTP interface. Some
translations are minimal, such as for proxy requests for "http" URIs,
whereas other requests might require translation to and from entirely
different application-level protocols. Proxies are often used to
group an organization's HTTP requests through a common intermediary
for the sake of security, annotation services, or shared caching.
An HTTP-to-HTTP proxy is called a "transforming proxy" if it is
designed or configured to modify request or response messages in a
semantically meaningful way (i.e., modifications, beyond those
required by normal HTTP processing, that change the message in a way
that would be significant to the original sender or potentially
significant to downstream recipients). For example, a transforming
proxy might be acting as a shared annotation server (modifying
responses to include references to a local annotation database), a
malware filter, a format transcoder, or an intranet-to-Internet
privacy filter. Such transformations are presumed to be desired by
the client (or client organization) that selected the proxy and are
beyond the scope of this specification. However, when a proxy is not
intended to transform a given message, we use the term "non-
transforming proxy" to target requirements that preserve HTTP message
semantics. See Section 6.3.4 of [Part2] and Section 7.5 of [Part6]
for status and warning codes related to transformations.
A "gateway" (a.k.a., "reverse proxy") is a receiving agent that acts
as a layer above some other server(s) and translates the received
requests to the underlying server's protocol. Gateways are often
used to encapsulate legacy or untrusted information services, to
improve server performance through "accelerator" caching, and to
enable partitioning or load-balancing of HTTP services across
multiple machines.
A gateway behaves as an origin server on its outbound connection and
as a user agent on its inbound connection. All HTTP requirements
applicable to an origin server also apply to the outbound
communication of a gateway. A gateway communicates with inbound
servers using any protocol that it desires, including private
extensions to HTTP that are outside the scope of this specification.
However, an HTTP-to-HTTP gateway that wishes to interoperate with
Fielding & Reschke Expires August 27, 2013 [Page 10]
Internet-Draft HTTP/1.1 Message Syntax and Routing February 2013
third-party HTTP servers MUST conform to HTTP user agent requirements
on the gateway's inbound connection and MUST implement the Connection
(Section 6.1) and Via (Section 5.7.1) header fields for both
connections.
A "tunnel" acts as a blind relay between two connections without
changing the messages. Once active, a tunnel is not considered a
party to the HTTP communication, though the tunnel might have been
initiated by an HTTP request. A tunnel ceases to exist when both
ends of the relayed connection are closed. Tunnels are used to
extend a virtual connection through an intermediary, such as when
Transport Layer Security (TLS, [RFC5246]) is used to establish
confidential communication through a shared firewall proxy.
The above categories for intermediary only consider those acting as
participants in the HTTP communication. There are also
intermediaries that can act on lower layers of the network protocol
stack, filtering or redirecting HTTP traffic without the knowledge or
permission of message senders. Network intermediaries often
introduce security flaws or interoperability problems by violating
HTTP semantics. For example, an "interception proxy" [RFC3040] (also
commonly known as a "transparent proxy" [RFC1919] or "captive
portal") differs from an HTTP proxy because it is not selected by the
client. Instead, an interception proxy filters or redirects outgoing
TCP port 80 packets (and occasionally other common port traffic).
Interception proxies are commonly found on public network access
points, as a means of enforcing account subscription prior to
allowing use of non-local Internet services, and within corporate
firewalls to enforce network usage policies. They are
indistinguishable from a man-in-the-middle attack.
HTTP is defined as a stateless protocol, meaning that each request
message can be understood in isolation. Many implementations depend
on HTTP's stateless design in order to reuse proxied connections or
dynamically load-balance requests across multiple servers. Hence,
servers MUST NOT assume that two requests on the same connection are
from the same user agent unless the connection is secured and
specific to that agent. Some non-standard HTTP extensions (e.g.,
[RFC4559]) have been known to violate this requirement, resulting in
security and interoperability problems.
2.4. Caches
A "cache" is a local store of previous response messages and the
subsystem that controls its message storage, retrieval, and deletion.
A cache stores cacheable responses in order to reduce the response
time and network bandwidth consumption on future, equivalent
requests. Any client or server MAY employ a cache, though a cache
Fielding & Reschke Expires August 27, 2013 [Page 11]
Internet-Draft HTTP/1.1 Message Syntax and Routing February 2013
cannot be used by a server while it is acting as a tunnel.
The effect of a cache is that the request/response chain is shortened
if one of the participants along the chain has a cached response
applicable to that request. The following illustrates the resulting
chain if B has a cached copy of an earlier response from O (via C)
for a request that has not been cached by UA or A.
> >
UA =========== A =========== B - - - - - - C - - - - - - O
< <
A response is "cacheable" if a cache is allowed to store a copy of
the response message for use in answering subsequent requests. Even
when a response is cacheable, there might be additional constraints
placed by the client or by the origin server on when that cached
response can be used for a particular request. HTTP requirements for
cache behavior and cacheable responses are defined in Section 2 of
[Part6].
There are a wide variety of architectures and configurations of
caches deployed across the World Wide Web and inside large
organizations. These include national hierarchies of proxy caches to
save transoceanic bandwidth, collaborative systems that broadcast or
multicast cache entries, archives of pre-fetched cache entries for
use in off-line or high-latency environments, and so on.
2.5. Conformance and Error Handling
This specification targets conformance criteria according to the role
of a participant in HTTP communication. Hence, HTTP requirements are
placed on senders, recipients, clients, servers, user agents,
intermediaries, origin servers, proxies, gateways, or caches,
depending on what behavior is being constrained by the requirement.
Additional (social) requirements are placed on implementations,
resource owners, and protocol element registrations when they apply
beyond the scope of a single communication.
The verb "generate" is used instead of "send" where a requirement
differentiates between creating a protocol element and merely
forwarding a received element downstream.
An implementation is considered conformant if it complies with all of
the requirements associated with the roles it partakes in HTTP. Note
that SHOULD-level requirements are relevant here, unless one of the
documented exceptions is applicable.
Conformance applies to both the syntax and semantics of HTTP protocol
Fielding & Reschke Expires August 27, 2013 [Page 12]
Internet-Draft HTTP/1.1 Message Syntax and Routing February 2013
elements. A sender MUST NOT generate protocol elements that convey a
meaning that is known by that sender to be false. A sender MUST NOT
generate protocol elements that do not match the grammar defined by
the ABNF rules for those protocol elements that are applicable to the
sender's role. If a received protocol element is processed, the
recipient MUST be able to parse any value that would match the ABNF
rules for that protocol element, excluding only those rules not
applicable to the recipient's role.
Unless noted otherwise, a recipient MAY attempt to recover a usable
protocol element from an invalid construct. HTTP does not define
specific error handling mechanisms except when they have a direct
impact on security, since different applications of the protocol
require different error handling strategies. For example, a Web
browser might wish to transparently recover from a response where the
Location header field doesn't parse according to the ABNF, whereas a
systems control client might consider any form of error recovery to
be dangerous.
2.6. Protocol Versioning
HTTP uses a "<major>.<minor>" numbering scheme to indicate versions
of the protocol. This specification defines version "1.1". The
protocol version as a whole indicates the sender's conformance with
the set of requirements laid out in that version's corresponding
specification of HTTP.
The version of an HTTP message is indicated by an HTTP-version field
in the first line of the message. HTTP-version is case-sensitive.
HTTP-version = HTTP-name "/" DIGIT "." DIGIT
HTTP-name = %x48.54.54.50 ; "HTTP", case-sensitive
The HTTP version number consists of two decimal digits separated by a
"." (period or decimal point). The first digit ("major version")
indicates the HTTP messaging syntax, whereas the second digit ("minor
version") indicates the highest minor version to which the sender is
conformant and able to understand for future communication. The
minor version advertises the sender's communication capabilities even
when the sender is only using a backwards-compatible subset of the
protocol, thereby letting the recipient know that more advanced
features can be used in response (by servers) or in future requests
(by clients).
When an HTTP/1.1 message is sent to an HTTP/1.0 recipient [RFC1945]
or a recipient whose version is unknown, the HTTP/1.1 message is
constructed such that it can be interpreted as a valid HTTP/1.0
message if all of the newer features are ignored. This specification
Fielding & Reschke Expires August 27, 2013 [Page 13]
Internet-Draft HTTP/1.1 Message Syntax and Routing February 2013
places recipient-version requirements on some new features so that a
conformant sender will only use compatible features until it has
determined, through configuration or the receipt of a message, that
the recipient supports HTTP/1.1.
The interpretation of a header field does not change between minor
versions of the same major HTTP version, though the default behavior
of a recipient in the absence of such a field can change. Unless
specified otherwise, header fields defined in HTTP/1.1 are defined
for all versions of HTTP/1.x. In particular, the Host and Connection
header fields ought to be implemented by all HTTP/1.x implementations
whether or not they advertise conformance with HTTP/1.1.
New header fields can be defined such that, when they are understood
by a recipient, they might override or enhance the interpretation of
previously defined header fields. When an implementation receives an
unrecognized header field, the recipient MUST ignore that header
field for local processing regardless of the message's HTTP version.
An unrecognized header field received by a proxy MUST be forwarded
downstream unless the header field's field-name is listed in the
message's Connection header field (see Section 6.1). These
requirements allow HTTP's functionality to be enhanced without
requiring prior update of deployed intermediaries.
Intermediaries that process HTTP messages (i.e., all intermediaries
other than those acting as tunnels) MUST send their own HTTP-version
in forwarded messages. In other words, they MUST NOT blindly forward
the first line of an HTTP message without ensuring that the protocol
version in that message matches a version to which that intermediary
is conformant for both the receiving and sending of messages.
Forwarding an HTTP message without rewriting the HTTP-version might
result in communication errors when downstream recipients use the
message sender's version to determine what features are safe to use
for later communication with that sender.
An HTTP client SHOULD send a request version equal to the highest
version to which the client is conformant and whose major version is
no higher than the highest version supported by the server, if this
is known. An HTTP client MUST NOT send a version to which it is not
conformant.
An HTTP client MAY send a lower request version if it is known that
the server incorrectly implements the HTTP specification, but only
after the client has attempted at least one normal request and
determined from the response status or header fields (e.g., Server)
that the server improperly handles higher request versions.
An HTTP server SHOULD send a response version equal to the highest
Fielding & Reschke Expires August 27, 2013 [Page 14]
Internet-Draft HTTP/1.1 Message Syntax and Routing February 2013
version to which the server is conformant and whose major version is
less than or equal to the one received in the request. An HTTP
server MUST NOT send a version to which it is not conformant. A
server MAY send a 505 (HTTP Version Not Supported) response if it
cannot send a response using the major version used in the client's
request.
An HTTP server MAY send an HTTP/1.0 response to an HTTP/1.0 request
if it is known or suspected that the client incorrectly implements
the HTTP specification and is incapable of correctly processing later
version responses, such as when a client fails to parse the version
number correctly or when an intermediary is known to blindly forward
the HTTP-version even when it doesn't conform to the given minor
version of the protocol. Such protocol downgrades SHOULD NOT be
performed unless triggered by specific client attributes, such as
when one or more of the request header fields (e.g., User-Agent)
uniquely match the values sent by a client known to be in error.
The intention of HTTP's versioning design is that the major number
will only be incremented if an incompatible message syntax is
introduced, and that the minor number will only be incremented when
changes made to the protocol have the effect of adding to the message
semantics or implying additional capabilities of the sender.
However, the minor version was not incremented for the changes
introduced between [RFC2068] and [RFC2616], and this revision has
specifically avoiding any such changes to the protocol.
2.7. Uniform Resource Identifiers
Uniform Resource Identifiers (URIs) [RFC3986] are used throughout
HTTP as the means for identifying resources (Section 2 of [Part2]).
URI references are used to target requests, indicate redirects, and
define relationships.
This specification adopts the definitions of "URI-reference",
"absolute-URI", "relative-part", "port", "host", "path-abempty",
"query", "segment", and "authority" from the URI generic syntax. In
addition, we define an "absolute-path" rule (that differs from RFC
3986's "path-absolute" in that it allows a leading "//") and a
"partial-URI" rule for protocol elements that allow a relative URI
but not a fragment.
Fielding & Reschke Expires August 27, 2013 [Page 15]
Internet-Draft HTTP/1.1 Message Syntax and Routing February 2013
URI-reference = <URI-reference, defined in [RFC3986], Section 4.1>
absolute-URI = <absolute-URI, defined in [RFC3986], Section 4.3>
relative-part = <relative-part, defined in [RFC3986], Section 4.2>
authority = <authority, defined in [RFC3986], Section 3.2>
path-abempty = <path-abempty, defined in [RFC3986], Section 3.3>
port = <port, defined in [RFC3986], Section 3.2.3>
query = <query, defined in [RFC3986], Section 3.4&", "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.
The reader should be familiar with the terms defined in
[I-D.ietf-dots-architecture], [RFC3958], and
[I-D.ietf-dots-signal-call-home].
DHCP refers to both DHCPv4 [RFC2131] and DHCPv6 [RFC8415].
"Peer DOTS agent" refers to the peer DOTS server (base DOTS
operation) or to a peer Call Home DOTS client (for DOTS Signal
Channel Call Home).
Boucadair & Reddy Expires July 10, 2020 [Page 4]
Internet-Draft DOTS Server/Call Home Client Discovery January 2020
3. Why Multiple Discovery Mechanisms?
It is tempting to specify one single discovery mechanism for DOTS.
Nevertheless, the analysis of the various use cases sketched in
[I-D.ietf-dots-use-cases] reveals that it is unlikely that one single
discovery method can be suitable for all the sample deployments.
Concretely:
o Many use cases discussed in [I-D.ietf-dots-use-cases] do involve a
CPE device. Multiple CPEs, connected to distinct network
providers may even be considered. It is intuitive to leverage on
existing mechanisms such as discovery using service resolution or
DHCP to provision the CPE acting as a DOTS client with the DOTS
server(s).
o Resolving a DOTS server domain name offered by an upstream transit
provider provisioned to a DOTS client into IP address(es) require
the use of the appropriate DNS resolvers; otherwise, resolving
those names will fail. The use of protocols such as DHCP does
allow to associate provisioned DOTS server domain names with a
list of DNS servers to be used for name resolution. Furthermore,
DHCP allows to directly provision IP addresses avoiding therefore
the need for extra lookup delays.
o Some of the use cases may allow DOTS clients to have direct
communications with upstream DOTS servers; that is no DOTS gateway
is involved. Leveraging on existing features that do not require
specific feature on the node embedding the DOTS client may ease
DOTS deployment. Typically, the use of Straightforward-Naming
Authority Pointer (S-NAPTR) lookups [RFC3958] allows the DOTS
server administrators to provision the preferred DOTS transport
protocol between the DOTS client and the DOTS server and allows
the DOTS client to discover this preference.
o The upstream network provider is not the DDoS mitigation provider
for some of these use cases. It is safe to assume that for such
deployments, the DOTS server(s) domain name is provided during the
service subscription (i.e., manual/local configuration).
o Multiple DOTS clients may be enabled within a network (e.g.,
enterprise network). Dynamic means to discover DOTS servers in a
deterministic manner are interesting from an operational
standpoint.
o Some of the use cases may involve a DOTS gateway that is
responsible for selecting the appropriate DOTS server(s) to relay
requests received from DOTS clients.
Boucadair & Reddy Expires July 10, 2020 [Page 5]
Internet-Draft DOTS Server/Call Home Client Discovery January 2020
Consequently, this document describes a unified discovery logic
(Section 4) which involves the following mechanisms:
o Dynamic discovery using DHCP (Section 5).
o A resolution mechanism based on straightforward Naming Authority
Pointer (S-NAPTR) resource records in the Domain Name System (DNS)
(Section 6).
o DNS Service Discovery (Section 7).
4. Unified DOTS Discovery Procedure
A key point in the deployment of DOTS is the ability of network
operators to be able to configure DOTS clients with the correct DOTS
server(s) information consistently. To accomplish this, operators
will need a consistent set of ways in which DOTS clients can discover
this information, and a consistent priority among these options. If
some devices prefer manual configuration over dynamic discovery,
while others prefer dynamic discovery over manual configuration, the
result will be a process of "whack-a-mole", where the operator must
find devices that are using the wrong DOTS server(s), determine how
to ensure the devices are configured properly, and then reconfigure
the device through the preferred method.
All DOTS clients MUST support at least one of the three mechanisms
below to determine a DOTS server list. All DOTS clients SHOULD
implement all three, or as many as are practical for any specific
device (e.g., a CPE will support the first two mechanisms, a host
within a LAN will support the last two mechanisms, or an application
server will support a local configuration. More samples are
discussed in Section 3), of these ways to discover DOTS servers, in
order to facilitate the deployment of DOTS in large scale
environments:
1. Explicit configuration:
* Local/Manual configuration: A DOTS client, will learn the DOTS
server(s) by means of local or manual DOTS configuration
(i.e., DOTS servers configured at the system level).
Configuration discovered from a DOTS client application is
considered as local configuration.
An implementation may give the user an opportunity (e.g., by
means of configuration file options or menu items) to specify
DOTS server(s) for each address family. These may be
specified either as IP addresses or the DNS name of a DOTS
server. When only DOTS server's IP addresses are configured,
Boucadair & Reddy Expires July 10, 2020 [Page 6]
Internet-Draft DOTS Server/Call Home Client Discovery January 2020
a reference identifier must also be configured for
authentication purposes.
* Automatic configuration (e.g., DHCP, an automation system):
The DOTS client attempts to discover DOTS server(s) names and/
or addresses from DHCP, as described in Section 5.
2. Service Resolution : The DOTS client attempts to discover DOTS
server name(s) using service resolution, as specified in
Section 6.
3. DNS SD: DNS Service Discovery. The DOTS client attempts to
discover DOTS server name(s) using DNS service discovery, as
specified in Section 7.
Some of these mechanisms imply the use of DNS to resolve the IP
address(es) of the DOTS server, while others imply an IP address of
the relevant DOTS server is obtained directly. Implementation
options may vary on a per device basis, as some devices may not have
DNS capabilities and/or proper configuration.
DOTS clients will prefer information received from the discovery
methods in the order listed.
On hosts with more than one interface or address family (IPv4/v6),
the DOTS server discovery procedure has to be performed for each
combination of interface and address family. A DOTS client may
choose to perform the discovery procedure only for a desired
interface/address combination if the client does not wish to discover
a DOTS server for all combinations of interface and address family.
This procedure is also followed by a Call Home DOTS server to
discover its Call Home DOTS client in the context of
[I-D.ietf-dots-signal-call-home].
The discovery method is reiterated by a DOTS agent upon the following
events:
o Expiry of a lease associated with a discovered DOTS agent.
o Expiry of a peer DOTS agent's certificate currently in use.
o Attachment to a new network.
Boucadair & Reddy Expires July 10, 2020 [Page 7]
Internet-Draft DOTS Server/Call Home Client Discovery January 2020
5. DHCP Options for DOTS Agent Discovery
As reported in Section 1.7.2 of [RFC6125]:
"few certification authorities issue server certificates based on
IP addresses, but preliminary evidence indicates that such
certificates are a very small percentage (less than 1%) of issued
certificates".
In order to allow for PKIX-based authentication between a DOTS client
and server while accommodating for the current best practices for
issuing certificates, this document allows for configuring names to
DOTS clients. These names can be used for two purposes: to retrieve
the list of IP addresses of a DOTS server or to be presented as a
reference identifier for authentication purposes.
Defining the option to include a list of IP addresses would avoid a
dependency on an underlying name resolution, but that design requires
to also supply a name for PKIX-based authentication purposes.
The list of the IP addresses returned by DHCP servers is typically
used to fed the DOTS server selection procedure or to provide DOTS
agents with primary and backup IP addresses of their peer DOTS
agents.
The design assumes that the same peer DOTS agent is used for
establishing both signal and data channels. For more customized
configurations (e.g., transport-specific configuration, distinct DOTS
servers for the signal and the data channels), an operator can supply
only a DOTS reference identifier that will be then passed to the
procedure described in Section 6.
The design allows to terminate the base DOTS channels and DOTS Call
Home on the same or distinct peer DOTS agents. If distinct peer DOTS
agents are deployed, the DHCP option can return, for example, a list
of IP addresses to a requesting DOTS agent. This list includes the
IP address to be used for the base DOTS channels and the IP address
for the DOTS Call Home. The DOTS client (or Call Home DOTS server)
will then use the address selection specified in Section 4.3 of
[I-D.ietf-dots-signal-channel] to identify the IP address of the peer
DOTS server (or Call Home DOTS client). For example:
Let>
segment = <segment, defined in [RFC3986], Section 3.3>
uri-host = <host, defined in [RFC3986], Section 3.2.2>
absolute-path = 1*( "/" segment )
partial-URI = relative-part [ "?" query ]
Each protocol element in HTTP that allows a URI reference will
indicate in its ABNF production whether the element allows any form
of reference (URI-reference), only a URI in absolute form (absolute-
URI), only the path and optional query components, or some
combination of the above. Unless otherwise indicated, URI references
are parsed relative to the effective request URI (Section 5.5).
2.7.1. http URI scheme
The "http" URI scheme is hereby defined for the purpose of minting
identifiers according to their association with the hierarchical
namespace governed by a potential HTTP origin server listening for
TCP connections on a given port.
http-URI = "http:" "//" authority path-abempty [ "?" query ]
The HTTP origin server is identified by the generic syntax's
authority component, which includes a host identifier and optional
TCP port ([RFC3986], Section 3.2.2). The remainder of the URI,
consisting of both the hierarchical path component and optional query
component, serves as an identifier for a potential resource within
that origin server's name space.
If the host identifier is provided as an IP address, then the origin
server is any listener on the indicated TCP port at that IP address.
If host is a registered name, then that name is considered an
indirect identifier and the recipient might use a name resolution
service, such as DNS, to find the address of a listener for that
host. The host MUST NOT be empty; if an "http" URI is received with
an empty host, then it MUST be rejected as invalid. If the port
subcomponent is empty or not given, then TCP port 80 is assumed (the
default reserved port for WWW services).
Regardless of the form of host identifier, access to that host is not
implied by the mere presence of its name or address. The host might
Fielding & Reschke Expires August 27, 2013 [Page 16]
Internet-Draft HTTP/1.1 Message Syntax and Routing February 2013
or might not exist and, even when it does exist, might or might not
be running an HTTP server or listening to the indicated port. The
"http" URI scheme makes use of the delegated nature of Internet names
and addresses to establish a naming authority (whatever entity has
the ability to place an HTTP server at that Internet name or address)
and allows that authority to determine which names are valid and how
they might be used.
When an "http" URI is used within a context that calls for access to
the indicated resource, a client MAY attempt access by resolving the
host to an IP address, establishing a TCP connection to that address
on the indicated port, and sending an HTTP request message
(Section 3) containing the URI's identifying data (Section 5) to the
server. If the server responds to that request with a non-interim
HTTP response message, as described in Section 6 of [Part2], then
that response is considered an authoritative answer to the client's
request.
Although HTTP is independent of the transport protocol, the "http"
scheme is specific to TCP-based services because the name delegation
process depends on TCP for establishing authority. An HTTP service
based on some other underlying connection protocol would presumably
be identified using a different URI scheme, just as the "https"
scheme (below) is used for resources that require an end-to-end
secured connection. Other protocols might also be used to provide
access to "http" identified resources -- it is only the authoritative
interface used for mapping the namespace that is specific to TCP.
The URI generic syntax for authority also includes a deprecated
userinfo subcomponent ([RFC3986], Section 3.2.1) for including user
authentication information in the URI. Some implementations make use
of the userinfo component for internal configuration of
authentication information, such as within command invocation
options, configuration files, or bookmark lists, even though such
usage might expose a user identifier or password. Senders MUST
exclude the userinfo subcomponent (and its "@" delimiter) when an
"http" URI is transmitted within a message as a request target or
header field value. Recipients of an "http" URI reference SHOULD
parse for userinfo and treat its presence as an error, since it is
likely being used to obscure the authority for the sake of phishing
attacks.
2.7.2. https URI scheme
The "https" URI scheme is hereby defined for the purpose of minting
identifiers according to their association with the hierarchical
namespace governed by a potential HTTP origin server listening to a
given TCP port for TLS-secured connections [RFC5246].
Fielding & Reschke Expires August 27, 2013 [Page 17]
Internet-Draft HTTP/1.1 Message Syntax and Routing February 2013
All of the requirements listed above for the "http" scheme are also
requirements for the "https" scheme, except that a default TCP port
of 443 is assumed if the port subcomponent is empty or not given, and
the TCP connection MUST be secured, end-to-end, through the use of
strong encryption prior to sending the first HTTP request.
https-URI = "https:" "//" authority path-abempty [ "?" query ]
Resources made available via the "https" scheme have no shared
identity with the "http" scheme even if their resource identifiers
indicate the same authority (the same host listening to the same TCP
port). They are distinct name spaces and are considered to be
distinct origin servers. However, an extension to HTTP that is
defined to apply to entire host domains, such as the Cookie protocol
[RFC6265], can allow information set by one service to impact
communication with other services within a matching group of host
domains.
The process for authoritative access to an "https" identified
resource is defined in [RFC2818].
2.7.3. http and https URI Normalization and Comparison
Since the "http" and "https" schemes conform to the URI generic
syntax, such URIs are normalized and compared according to the
algorithm defined in [RFC3986], Section 6, using the defaults
described above for each scheme.
If the port is equal to the default port for a scheme, the normal
form is to elide the port subcomponent. When not being used in
absolute form as the request target of an OPTIONS request, an empty
path component is equivalent to an absolute path of "/", so the
normal form is to provide a path of "/" instead. The scheme and host
are case-insensitive and normally provided in lowercase; all other
components are compared in a case-sensitive manner. Characters other
than those in the "reserved" set are equivalent to their percent-
encoded octets (see [RFC3986], Section 2.1): the normal form is to
not encode them.
For example, the following three URIs are equivalent:
http://example.com:80/~smith/home.html
http://EXAMPLE.com/%7Esmith/home.html
http://EXAMPLE.com:/%7esmith/home.html
Fielding & Reschke Expires August 27, 2013 [Page 18]
Internet-Draft HTTP/1.1 Message Syntax and Routing February 2013
3. Message Format
All HTTP/1.1 messages consist of a start-line followed by a sequence
of octets in a format similar to the Internet Message Format
[RFC5322]: zero or more header fields (collectively referred to as
the "headers" or the "header section"), an empty line indicating the
end of the header section, and an optional message body.
HTTP-message = start-line
*( header-field CRLF )
CRLF
[ message-body ]
The normal procedure for parsing an HTTP message is to read the
start-line into a structure, read each header field into a hash table
by field name until the empty line, and then use the parsed data to
determine if a message body is expected. If a message body has been
indicated, then it is read as a stream until an amount of octets
equal to the message body length is read or the connection is closed.
Recipients MUST parse an HTTP message as a sequence of octets in an
encoding that is a superset of US-ASCII [USASCII]. Parsing an HTTP
message as a stream of Unicode characters, without regard for the
specific encoding, creates security vulnerabilities due to the
varying ways that string processing libraries handle invalid
multibyte character sequences that contain the octet LF (%x0A).
String-based parsers can only be safely used within protocol elements
after the element has been extracted from the message, such as within
a header field-value after message parsing has delineated the
individual fields.
An HTTP message can be parsed as a stream for incremental processing
or forwarding downstream. However, recipients cannot rely on
incremental delivery of partial messages, since some implementations
will buffer or delay message forwarding for the sake of network
efficiency, security checks, or payload transformations.
3.1. Start Line
An HTTP message can either be a request from client to server or a
response from server to client. Syntactically, the two types of
message differ only in the start-line, which is either a request-line
(for requests) or a status-line (for responses), and in the algorithm
for determining the length of the message body (Section 3.3).
In theory, a client could receive requests and a server could receive
responses, distinguishing them by their different start-line formats,
but in practice servers are implemented to only expect a request (a
Fielding & Reschke Expires August 27, 2013 [Page 19]
Internet-Draft HTTP/1.1 Message Syntax and Routing February 2013
response is interpreted as an unknown or invalid request method) and
clients are implemented to only expect a response.
start-line = request-line / status-line
A sender MUST NOT send whitespace between the start-line and the
first header field. The presence of such whitespace in a request
might be an attempt to trick a server into ignoring that field or
processing the line after it as a new request, either of which might
result in a security vulnerability if other implementations within
the request chain interpret the same message differently. Likewise,
the presence of such whitespace in a response might be ignored by
some clients or cause others to cease parsing.
A recipient that receives whitespace between the start-line and the
first header field MUST either reject the message as invalid or
consume each whitespace-preceded line without further processing of
it (i.e., ignore the entire line, along with any subsequent lines
preceded by whitespace, until a properly formed header field is
received or the header block is terminated).
3.1.1. Request Line
A request-line begins with a method token, followed by a single space
(SP), the request-target, another single space (SP), the protocol
version, and ending with CRLF.
request-line = method SP request-target SP HTTP-version CRLF
The method token indicates the request method to be performed on the
target resource. The request method is case-sensitive.
method = token
The methods defined by this specification can be found in Section 4
of [Part2], along with information regarding the HTTP method registry
and considerations for defining new methods.
The request-target identifies the target resource upon which to apply
the request, as defined in Section 5.3.
No whitespace is allowed inside the method, request-target, and
protocol version. Hence, recipients typically parse the request-line
into its component parts by splitting on whitespace (see
Section 3.5).
Unfortunately, some user agents fail to properly encode hypertext
references that have embedded whitespace, sending the characters
Fielding & Reschke Expires August 27, 2013 [Page 20]
Internet-Draft HTTP/1.1 Message Syntax and Routing February 2013
#x27;s consider that the DOTS server is reachable at
2001:db8:122:300::1 while the Call Home DOTS client is reachable
at 2001:db8:122:300::2. The DHCP server will then return one DOTS
reference identifier and a list that includes both
2001:db8:122:300::1 and 2001:db8:122:300::2 to a requesting DHCP
client. That list is passed to the DOTS client (or Call Home DOTS
Boucadair & Reddy Expires July 10, 2020 [Page 8]
Internet-Draft DOTS Server/Call Home Client Discovery January 2020
server) which will try to establish connections to the addresses
of that list and destination port number 4646 (or 4647). As a
result, the DOTS client (or Call Home DOTS server) will select
2001:db8:122:300::1 (or 2001:db8:122:300::2) as a DOTS server (or
Call Home DOTS client).
5.1. DHCPv6 DOTS Options
5.1.1. Format of DOTS Reference Identifier Option
The DHCPv6 DOTS Reference Identifier option is used to configure a
name of the DOTS server (or the name of the Call Home DOTS client).
The format of this option is shown in Figure 3.
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_V6_DOTS_RI | Option-length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| dots-agent-name (FQDN) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: DHCPv6 DOTS Reference Identifier Option
The fields of the option shown in Figure 3 are as follows:
o Option-code: OPTION_V6_DOTS_RI (TBA1, see Section 9.2)
o Option-length: Length of the dots-agent-name field in octets.
o dots-agent-name: A fully qualified domain name of the peer DOTS
agent. This field is formatted as specified in Section 10 of
[RFC8415].
An example of the dots-agent-name encoding is shown in Figure 4.
This example conveys the FQDN "dots.example.com.".
+------+------+------+------+------+------+------+------+------+
| 0x04 | d | o | t | s | 0x07 | e | x | a |
+------+------+------+------+------+------+------+------+------+
| m | p | l | e | 0x03 | c | o | m | 0x00 |
+------+------+------+------+------+------+------+------+------+
Figure 4: An example of the dots-agent-name Encoding
Boucadair & Reddy Expires July 10, 2020 [Page 9]
Internet-Draft DOTS Server/Call Home Client Discovery January 2020
5.1.2. Format of DOTS Address Option
The DHCPv6 DOTS Address option can be used to configure a list of
IPv6 addresses of a DOTS server (or a Call Home DOTS client). The
format of this option is shown in Figure 5. As a reminder, this
format follows the guidelines for creating new DHCPv6 options
(Section 5.1 of [RFC7227]).
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_V6_DOTS_ADDRESS | Option-length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| DOTS ipv6-address |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| DOTS ipv6-address |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: DHCPv6 DOTS Address Option
The fields of the option shown in Figure 5 are as follows:
o Option-code: OPTION_V6_DOTS_ADDRESS (TBA2, see Section 9.2)
o Option-length: Length of the 'DOTS ipv6-address(es)' field in
octets. MUST be a multiple of 16.
o DOTS ipv6-address: Includes one or more IPv6 addresses [RFC4291]
of the peer DOTS agent to be used by a DOTS agent for establishing
a DOTS session.
Note, IPv4-mapped IPv6 addresses (Section 2.5.5.2 of [RFC4291])
are allowed to be included in this option.
5.1.3. DHCPv6 Client Behavior
DHCP clients MAY request options OPTION_V6_DOTS_RI and
OPTION_V6_DOTS_ADDRESS, as defined in [RFC8415], Sections 18.2.1,
18.2.2, 18.2.4, 18.2.5, 18.2.6, and 21.7. As a convenience to the
reader, it is mentioned here that the DHCP client includes the
requested option codes in the Option Request Option.
Boucadair & Reddy Expires July 10, 2020 [Page 10]
Internet-Draft DOTS Server/Call Home Client Discovery January 2020
If the DHCP client receives more than one instance of
OPTION_V6_DOTS_RI (or OPTION_V6_DOTS_ADDRESS) option, it MUST use
only the first instance of that option.
If the DHCP client receives both OPTION_V6_DOTS_RI and
OPTION_V6_DOTS_ADDRESS, the content of OPTION_V6_DOTS_RI is used as
reference identifier for authentication purposes (e.g., PKIX
[RFC6125]), while the addresses included in OPTION_V6_DOTS_ADDRESS
are used to reach the peer DOTS agent. In other words, the name
conveyed in OPTION_V6_DOTS_RI MUST NOT be passed to underlying
resolution library in the presence of OPTION_V6_DOTS_ADDRESS in a
response.
If the DHCP client receives OPTION_V6_DOTS_RI only, but
OPTION_V6_DOTS_RI option contains more than one name, as
distinguished by the presence of multiple root labels, the DHCP
client MUST use only the first name. Once the name is validated
(Section 8 of [RFC8415]), the name is passed to a name resolution
library. Moreover, that name is also used as a reference identifier
for authentication purposes.
If the DHCP client receives OPTION_V6_DOTS_ADDRESS only, the
address(es) included in OPTION_V6_DOTS_ADDRESS are used to reach the
peer DOTS agent. In addition, these addresses can be used as
identifiers for authentication.
The DHCP client MUST silently discard multicast and host loopback
addresses [RFC6890] conveyed in OPTION_V6_DOTS_ADDRESS.
5.2. DHCPv4 DOTS Options
5.2.1. Format of DOTS Reference Identifier Option
The DHCPv4 DOTS Reference Identifier option is used to configure a
name of the peer DOTS agent. The format of this option is
illustrated in Figure 6.
Code Length Peer DOTS agent name
+-----+-----+-----+-----+-----+-----+-----+--
|TBA3 | n | s1 | s2 | s3 | s4 | s5 | ...
+-----+-----+-----+-----+-----+-----+-----+--
The values s1, s2, s3, etc. represent the domain name labels in the
domain name encoding.
Figure 6: DHCPv4 DOTS Reference Identifier Option
Boucadair & Reddy Expires July 10, 2020 [Page 11]
Internet-Draft DOTS Server/Call Home Client Discovery January 2020
The fields of the option shown in Figure 6 are as follows:
o Code: OPTION_V4_DOTS_RI (TBA3, see Section 9.3).
o Length: Includes the length of the "Peer DOTS agent name" field in
octets; the maximum length is 255 octets.
o Peer DOTS agent name: The domain name of the peer DOTS agent.
This field is formatted as specified in Section 10 of [RFC8415].
5.2.2. Format of DOTS Address Option
The DHCPv4 DOTS Address option can be used to configure a list of
IPv4 addresses of a peer DOTS agent. The format of this option is
illustrated in Figure 7.
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code=TBA4 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ DOTS IPv4 Address |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---
| | |
+ DOTS IPv4 Address | |
| | optional
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
. ... . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---
Figure 7: DHCPv4 DOTS Address Option
The fields of the option shown in Figure 7 are as follows:
o Code: OPTION_V4_DOTS_ADDRESS (TBA4, see Section 9.3).
o Length: is set to 4*N, where N is the number of IPv4 addresses
included in the option.
o DOTS IPv4 Address(es): Contains one or more IPv4 addresses of the
peer DOTS agent to be used by a DOTS agent.
OPTION_V4_DOTS_ADDRESS is a concatenation-requiring option. As such,
the mechanism specified in [RFC3396] MUST be used if
OPTION_V4_DOTS_ADDRESS exceeds the maximum DHCPv4 option size of 255
octets.
Boucadair & Reddy Expires July 10, 2020 [Page 12]
Internet-Draft DOTS Server/Call Home Client Discovery January 2020
5.2.3. DHCPv4 Client Behavior
To discover a peer DOTS agent, the DHCPv4 client MUST include both
OPTION_V4_DOTS_RI and OPTION_V4_DOTS_ADDRESS in a Parameter Request
List Option [RFC2132].
If the DHCP client receives more than one instance of
OPTION_V4_DOTS_RI (or OPTION_V4_DOTS_ADDRESS) option, it MUST use
only the first instance of that option.
If the DHCP client receives both OPTION_V4_DOTS_RI and
OPTION_V4_DOTS_ADDRESS, the content of OPTION_V6_DOTS_RI is used as
reference identifier for authentication purposes, while the addresses
included in OPTION_V4_DOTS_ADDRESS are used to reach the peer DOTS
agent. In other words, the name conveyed in OPTION_V4_DOTS_RI MUST
NOT be passed to underlying resolution library in the presence of
OPTION_V4_DOTS_ADDRESS in a response.
If the DHCP client receives OPTION_V4_DOTS_RI only, but
OPTION_V4_DOTS_RI option contains more than one name, as
distinguished by the presence of multiple root labels, the DHCP
client MUST use only the first name. Once the name is validated
(Section 10 of [RFC8415]), the name is passed to a name resolution
library. Moreover, that name is also used as a reference identifier
for authentication purposes.
If the DHCP client receives OPTION_V4_DOTS_ADDRESS only, the
address(es) included in OPTION_V4_DOTS_ADDRESS are used to reach the
peer DOTS server. In addition, these addresses can be used as
identifiers for authentication.
The DHCP client MUST silently discard multicast and host loopback
addresses conveyed in OPTION_V4_DOTS_ADDRESS.
6. Discovery using Service Resolution
This mechanism is performed in two steps:
1. A DNS domain name is retrieved for each combination of interface
and address family. A DOTS agent has to determine the domain in
which it is located relying on dynamic means such as DHCP
(Section 5) . Implementations may allow the user to specify a
default name that is used, if no specific name has been
configured.
2. Retrieved DNS domain names are then used for S-NAPTR lookups
[RFC3958]. Further DNS lookups may be necessary to determine the
peer DOTS agent IP address(es).
Boucadair & Reddy Expires July 10, 2020 [Page 13]
Internet-Draft DOTS Server/Call Home Client Discovery January 2020
Once the DOTS agent has retrieved its DNS domain or discovered the
peer DOTS agent name that needs to be resolved (e.g., Section 5), an
S-NAPTR lookup with 'DOTS' application service and the desired
protocol tag is made to obtain information necessary to connect to
the authoritative peer DOTS agent within the given domain.
This specification defines "DOTS" and "DOTS-CALL-HOME" as application
service tags (Sections 9.4.1 and 9.4.2). It also defines
"signal.udp" (Section 9.4.3), "signal.tcp" (Section 9.4.4), and
"data.tcp" (Section 9.4.5) as application protocol tags. An example
is provided in Figure 8.
In the example below, for domain 'example.net', the resolution
algorithm will result in IP address(es), port, tag, and protocol
tuples listed in Table 1.
example.net.
IN NAPTR 100 10 "" DOTS:signal.udp "" signal.example.net.
IN NAPTR 200 10 "" DOTS:signal.tcp "" signal.example.net.
IN NAPTR 300 10 "" DOTS:data.tcp "" data.example.net.
signal.example.net.
IN NAPTR 100 10 "s" DOTS:signal.udp "" _dots-signal._udp.example.net.
IN NAPTR 200 10 "s" DOTS:signal.tcp "" _dots-signal._tcp.example.net.
data.example.net.
IN NAPTR 100 10 "s" DOTS:data.tcp "" _dots-data._tcp.example.net.
_dots-signal._udp.example.net.
IN SRV 0 0 5000 a.example.net.
_dots-signal._tcp.example.net.
IN SRV 0 0 5001 a.example.net.
_dots-data._tcp.example.net.
IN SRV 0 0 5002 a.example.net.
a.example.net.
IN AAAA 2001:db8::1
Figure 8: Sample Example of Discovery of DOTS Servers using Service
Resolution
Boucadair & Reddy Expires July 10, 2020 [Page 14]
Internet-Draft DOTS Server/Call Home Client Discovery January 2020
+-------+----------+-------------+------+--------+
| Order | Protocol | IP address | Port | Tag |
+-------+----------+-------------+------+--------+
| 1 | UDP | 2001:db8::1 | 5000 | Signal |
| 2 | TCP | 2001:db8::1 | 5001 | Signal |
| 3 | TCP | 2001:db8::1 | 5002 | Data |
+-------+----------+-------------+------+--------+
Table 1
An example is provided in Figure 9 for the Call Home case. In this
example, the resolution algorithm will result in IP address(es),
port, and protocol listed in Table 2 for domain 'example.net'.
example.net.
IN NAPTR 100 10 "" DOTS-CALL-HOME:signal.udp "" signal.example.net.
IN NAPTR 200 10 "" DOTS-CALL-HOME:signal.tcp "" signal.example.net.
signal.example.net.
IN NAPTR 100 10 "s" DOTS-CALL-HOME:signal.udp ""
_dots-call-home._udp.example.net.
IN NAPTR 200 10 "s" DOTS-CALL-HOME:signal.tcp ""
_dots-call-home._tcp.example.net.
_dots-call-home._udp.example.net.
IN SRV 0 0 6000 b.example.net.
_dots-call-home._tcp.example.net.
IN SRV 0 0 6001 b.example.net.
b.example.net.
IN AAAA 2001:db8::2
Figure 9: Sample Example of Discovery of DOTS Call Home Client using
Service Resolution
+-------+----------+-------------+------+
| Order | Protocol | IP address | Port |
+-------+----------+-------------+------+
| 1 | UDP | 2001:db8::2 | 6000 |
| 2 | TCP | 2001:db8::2 | 6001 |
+-------+----------+-------------+------+
Table 2
If no DOTS-specific S-NAPTR records can be retrieved, the discovery
procedure fails for this domain name (and the corresponding interface
and IP protocol version). If more domain names are known, the
discovery procedure MAY perform the corresponding S-NAPTR lookups
Boucadair & Reddy Expires July 10, 2020 [Page 15]
Internet-Draft DOTS Server/Call Home Client Discovery January 2020
immediately. However, before retrying a lookup that has failed, a
DOTS client MUST wait a time period that is appropriate for the
encountered error (e.g., NXDOMAIN, timeout, etc.).
7. DNS Service Discovery
DNS-based Service Discovery (DNS-SD) [RFC6763] provides generic
solutions for discovering services. DNS-SD defines a set of naming
rules for certain DNS record types that they use for advertising and
discovering services.
Section 4.1 of [RFC6763] specifies that a service instance name in
DNS-SD has the following structure:
<Instance> . <Service> . <Domain>
The <Domain> portion specifies the DNS sub-domain where the service
instance is registered. It may be "local.", indicating the mDNS
local domain, or it may be a conventional domain name such as
"example.com.".
The <Service> portion of the DOTS service instance name MUST be
"_dots-signal._udp" or "_dots-signal._tcp" or "_dots-data._tcp" or
"_dots-call-home._udp" or "_dots-call-home._tcp".
8. Security Considerations
DOTS-related security considerations are discussed in Section 4 of
[I-D.ietf-dots-architecture]. As a reminder, DOTS agents must
authenticate each other using (D)TLS before a DOTS session is
considered valid according to the [I-D.ietf-dots-signal-channel].
8.1. DHCP
The security considerations in [RFC2131] and [RFC8415] are to be
considered.
8.2. Service Resolution
The primary attack against the methods described in Section 6 is one
that would lead to impersonation of a peer DOTS agent. An attacker
could attempt to compromise the S-NAPTR resolution. The use of
mutual authentication makes it difficult to redirect a DOTS client
(or a Call Home DOTS server) to an illegitimate DOTS server (or a
Call Home DOTS client).
Boucadair & Reddy Expires July 10, 2020 [Page 16]
Internet-Draft DOTS Server/Call Home Client Discovery January 2020
8.3. DNS Service Discovery
Since DNS-SD is a specification for how to name and use records in
the existing DNS system, it has no specific additional security
requirements over and above those that already apply to DNS queries
and DNS updates. For DNS queries, DNS Security Extensions (DNSSEC)
[RFC4033] SHOULD be used where the authenticity of information is
important. For DNS updates, secure updates [RFC2136][RFC3007] SHOULD
generally be used to control which clients have permission to update
DNS records.
9. IANA Considerations
9.1. The Service Name and Transport Protocol Port Number Registry
IANA is requested to allocate the service name of "dots-signal" for
DOTS signal channel over UDP or TCP, the service name of "dots-call-
home" for DOTS signal channel call home over UDP or TCP, and the
service name of "dots-data" for DOTS data channel over TCP. The
registry is available at: https://www.iana.org/assignments/service-
names-port-numbers/service-names-port-numbers.xhtml.
These names are used to construct the SRV service names discussed in
Section 7.
9.2. DHCPv6 Options
IANA is requested to assign the following new DHCPv6 Option Codes in
the registry maintained in: https://www.iana.org/assignments/dhcpv6-
parameters/dhcpv6-parameters.xhtml#dhcpv6-parameters-2.
Value Description Client ORO Singleton Option
TBD1 OPTION_V6_DOTS_RI Yes Yes
TBD2 OPTION_V6_DOTS_ADDRESS Yes Yes
9.3. DHCPv4 Options
IANA is requested to assign the following new DHCPv4 Option Codes in
the registry maintained in: https://www.iana.org/assignments/bootp-
dhcp-parameters/bootp-dhcp-parameters.xhtml#options.
Boucadair & Reddy Expires July 10, 2020 [Page 17]
Internet-Draft DOTS Server/Call Home Client Discovery January 2020
Option Name Value Data length Meaning
---------------------- ----- ----------------- ----------------------
OPTION_V4_DOTS_RI TBA3 Variable; the Includes the name of
maximum length is the peer DOTS agent.
255 octets.
OPTION_V4_DOTS_ADDRESS TBA4 Variable Includes one or more
IP addresses of peer
DOTS agent(s).
9.4. Application Service & Application Protocol Tags
This document requests IANA to make the following allocations from
the registries available at: https://www.iana.org/assignments/s-
naptr-parameters/s-naptr-parameters.xhtml for Application Service
Tags and https://www.iana.org/assignments/s-naptr-parameters/s-naptr-
parameters.xhtml#s-naptr-parameters-2 for Application Protocol Tags.
9.4.1. DOTS Application Service Tag Registration
o Application Protocol Tag: DOTS
o Intended Usage: See Section 6
o Security Considerations: See Section 8
o Interoperability considerations: None
o Relevant publications: This document
9.4.2. DOTS Call Home Application Service Tag Registration
o Application Protocol Tag: DOTS-CALL-HOME
o Intended Usage: See Section 6
o Security Considerations: See Section 8
o Interoperability considerations: None
o Relevant publications: This document
9.4.3. signal.udp Application Protocol Tag Registration
o Application Protocol Tag: signal.udp
o Intended Usage: See Section 6
o Security Considerations: See Section 8
Boucadair & Reddy Expires July 10, 2020 [Page 18]
Internet-Draft DOTS Server/Call Home Client Discovery January 2020
o Interoperability considerations: None
o Relevant publications: This document
9.4.4. signal.tcp Application Protocol Tag Registration
o Application Protocol Tag: signal.tcp
o Intended Usage: See Section 6
o Security Considerations: See Section 8
o Interoperability considerations: None
o Relevant publications: This document
9.4.5. data.tcp Application Protocol Tag Registration
o Application Protocol Tag: data.tcp
o Intended Usage: See Section 6
o Security Considerations: See Section 8
o Interoperability considerations: None
o Relevant publications: This document
10. Contributors
Prashanth Patil
Cisco Systems, Inc.
Email: praspati@cisco.com
11. Acknowledgements
Thanks to Brian Carpenter for the review of the BRSKI text.
Many thanks to Russ White for the review, comments, and text
contribution.
Thanks for Dan Wing, Pei Wei, Valery Smyslov, and Jon Shallow for the
review and comments.
Thanks to Bernie Volz for the review of the DHCP section.
Boucadair & Reddy Expires July 10, 2020 [Page 19]
Internet-Draft DOTS Server/Call Home Client Discovery January 2020
12. References
12.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol",
RFC 2131, DOI 10.17487/RFC2131, March 1997,
<https://www.rfc-editor.org/info/rfc2131>.
[RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor
Extensions", RFC 2132, DOI 10.17487/RFC2132, March 1997,
<https://www.rfc-editor.org/info/rfc2132>.
[RFC3396] Lemon, T. and S. Cheshire, "Encoding Long Options in the
Dynamic Host Configuration Protocol (DHCPv4)", RFC 3396,
DOI 10.17487/RFC3396, November 2002,
<https://www.rfc-editor.org/info/rfc3396>.
[RFC3958] Daigle, L. and A. Newton, "Domain-Based Application
Service Location Using SRV RRs and the Dynamic Delegation
Discovery Service (DDDS)", RFC 3958, DOI 10.17487/RFC3958,
January 2005, <https://www.rfc-editor.org/info/rfc3958>.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, DOI 10.17487/RFC4291, February
2006, <https://www.rfc-editor.org/info/rfc4291>.
[RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service
Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013,
<https://www.rfc-editor.org/info/rfc6763>.
[RFC6890] Cotton, M., Vegoda, L., Bonica, R., Ed., and B. Haberman,
"Special-Purpose IP Address Registries", BCP 153,
RFC 6890, DOI 10.17487/RFC6890, April 2013,
<https://www.rfc-editor.org/info/rfc6890>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
Boucadair & Reddy Expires July 10, 2020 [Page 20]
Internet-Draft DOTS Server/Call Home Client Discovery January 2020
[RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A.,
Richardson, M., Jiang, S., Lemon, T., and T. Winters,
"Dynamic Host Configuration Protocol for IPv6 (DHCPv6)",
RFC 8415, DOI 10.17487/RFC8415, November 2018,
<https://www.rfc-editor.org/info/rfc8415>.
12.2. Informative References
[I-D.ietf-anima-bootstrapping-keyinfra]
Pritikin, M., Richardson, M., Eckert, T., Behringer, M.,
and K. Watsen, "Bootstrapping Remote Secure Key
Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping-
keyinfra-34 (work in progress), January 2020.
[I-D.ietf-dots-architecture]
Mortensen, A., Reddy.K, T., Andreasen, F., Teague, N., and
R. Compton, "Distributed-Denial-of-Service Open Threat
Signaling (DOTS) Architecture", draft-ietf-dots-
architecture-14 (work in progress), May 2019.
[I-D.ietf-dots-data-channel]
Boucadair, M. and T. Reddy.K, "Distributed Denial-of-
Service Open Threat Signaling (DOTS) Data Channel
Specification", draft-ietf-dots-data-channel-31 (work in
progress), July 2019.
[I-D.ietf-dots-multihoming]
Boucadair, M., Reddy.K, T., and W. Pan, "Multi-homing
Deployment Considerations for Distributed-Denial-of-
Service Open Threat Signaling (DOTS)", draft-ietf-dots-
multihoming-02 (work in progress), July 2019.
[I-D.ietf-dots-signal-call-home]
Reddy.K, T., Boucadair, M., and J. Shallow, "Distributed
Denial-of-Service Open Threat Signaling (DOTS) Signal
Channel Call Home", draft-ietf-dots-signal-call-home-07
(work in progress), November 2019.
[I-D.ietf-dots-signal-channel]
Reddy.K, T., Boucadair, M., Patil, P., Mortensen, A., and
N. Teague, "Distributed Denial-of-Service Open Threat
Signaling (DOTS) Signal Channel Specification", draft-
ietf-dots-signal-channel-41 (work in progress), January
2020.
Boucadair & Reddy Expires July 10, 2020 [Page 21]
Internet-Draft DOTS Server/Call Home Client Discovery January 2020
[I-D.ietf-dots-use-cases]
Dobbins, R., Migault, D., Moskowitz, R., Teague, N., Xia,
L., and K. Nishizuka, "Use cases for DDoS Open Threat
Signaling", draft-ietf-dots-use-cases-20 (work in
progress), September 2019.
[RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound,
"Dynamic Updates in the Domain Name System (DNS UPDATE)",
RFC 2136, DOI 10.17487/RFC2136, April 1997,
<https://www.rfc-editor.org/info/rfc2136>.
[RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic
Update", RFC 3007, DOI 10.17487/RFC3007, November 2000,
<https://www.rfc-editor.org/info/rfc3007>.
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "DNS Security Introduction and Requirements",
RFC 4033, DOI 10.17487/RFC4033, March 2005,
<https://www.rfc-editor.org/info/rfc4033>.
[RFC6125] Saint-Andre, P. and J. Hodges, "Representation and
Verification of Domain-Based Application Service Identity
within Internet Public Key Infrastructure Using X.509
(PKIX) Certificates in the Context of Transport Layer
Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March
2011, <https://www.rfc-editor.org/info/rfc6125>.
[RFC7227] Hankins, D., Mrugalski, T., Siodelski, M., Jiang, S., and
S. Krishnan, "Guidelines for Creating New DHCPv6 Options",
BCP 187, RFC 7227, DOI 10.17487/RFC7227, May 2014,
<https://www.rfc-editor.org/info/rfc7227>.
[RFC8572] Watsen, K., Farrer, I., and M. Abrahamsson, "Secure Zero
Touch Provisioning (SZTP)", RFC 8572,
DOI 10.17487/RFC8572, April 2019,
<https://www.rfc-editor.org/info/rfc8572>.
Authors' Addresses
Mohamed Boucadair
Orange
Rennes 35000
France
Email: mohamed.boucadair@orange.com
Boucadair & Reddy Expires July 10, 2020 [Page 22]
Internet-Draft DOTS Server/Call Home Client Discovery January 2020
Tirumaleswar Reddy
McAfee, Inc.
Embassy Golf Link Business Park
Bangalore, Karnataka 560071
India
Email: TirumaleswarReddy_Konda@McAfee.com
Boucadair & Reddy Expires July 10, 2020 [Page 23]