Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel Specification
draft-ietf-dots-signal-channel-25
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 8782.
|
|
|---|---|---|---|
| Authors | Tirumaleswar Reddy.K , Mohamed Boucadair , Prashanth Patil , Andrew Mortensen , Nik Teague | ||
| Last updated | 2018-10-16 (Latest revision 2018-09-06) | ||
| Replaces | draft-reddy-dots-signal-channel | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Formats | |||
| Reviews | |||
| Additional resources | Mailing list discussion | ||
| Stream | WG state | Submitted to IESG for Publication | |
| Document shepherd | Liang Xia | ||
| Shepherd write-up | Show Last changed 2018-09-19 | ||
| IESG | IESG state | Became RFC 8782 (Proposed Standard) | |
| Consensus boilerplate | Yes | ||
| Telechat date | (None) | ||
| Responsible AD | Benjamin Kaduk | ||
| Send notices to | Liang Xia <frank.xialiang@huawei.com> |
draft-ietf-dots-signal-channel-25
9. IANA Considerations
This specification registers a service port (Section 9.1), a URI
suffix in the Well-Known URIs registry (Section 9.2), and a YANG
module (Section 9.7). It also creates a registry for mappings to
CBOR (Section 9.3).
9.1. DOTS Signal Channel UDP and TCP Port Number
IANA is requested to assign the port number TBD to the DOTS signal
channel protocol for both UDP and TCP from the "Service Name and
Transport Protocol Port Number Registry" available at
https://www.iana.org/assignments/service-names-port-numbers/service-
names-port-numbers.xhtml.
The assignment of port number 4646 is strongly suggested, as 4646 is
the ASCII decimal value for ".." (DOTS).
9.2. Well-Known 'dots' URI
This document requests IANA to register the 'dots' well-known URI
(Table 5) in the Well-Known URIs registry
(https://www.iana.org/assignments/well-known-uris/well-known-
uris.xhtml) as defined by [RFC5785]:
+----------+----------------+---------------------+-----------------+
| URI | Change | Specification | Related |
| suffix | controller | document(s) | information |
+----------+----------------+---------------------+-----------------+
| dots | IETF | [RFCXXXX] | None |
+----------+----------------+---------------------+-----------------+
Table 5: 'dots' well-known URI
9.3. DOTS Signal Channel CBOR Mappings Registry
The DOTS signal channel protocol is extensible to support new
parameters and instructions for doing it are discussed below:
The document requests IANA to create a new registry, entitled "DOTS
Signal Channel CBOR Mappings Registry". The structure of this
registry is provided in Section 9.3.1. Registration requests are
evaluated using the criteria described in the CBOR Key Value
instructions in the registration template below after a three-week
review period on the dots-signal-reg-review@ietf.org mailing list, on
the advice of one or more Designated Experts [RFC8126]. However, to
allow for the allocation of values prior to publication, the
Designated Experts may approve registration once they are satisfied
Reddy, et al. Expires March 9, 2019 [Page 76]
Internet-Draft DOTS Signal Channel Protocol September 2018
that such a specification will be published. [[ Note to the RFC
Editor: The name of the mailing list should be determined in
consultation with the IESG and IANA. Suggested name: dots-signal-
reg-review@ietf.org. ]]
Registration requests sent to the mailing list for review should use
an appropriate subject (e.g., "Request to register parameter:
example"). Registration requests that are undetermined for a period
longer than 21 days can be brought to the IESG's attention (using the
iesg@ietf.org mailing list) for resolution.
Criteria that should be applied by the Designated Experts includes
determining whether the proposed registration duplicates existing
functionality, whether it is likely to be of general applicability or
whether it is useful only for a single application, and whether the
registration description is clear.
IANA must only accept registry updates from the Designated Experts
and should direct all requests for registration to the review mailing
list.
It is suggested that multiple Designated Experts be appointed who are
able to represent the perspectives of different applications using
this specification in order to enable broadly informed review of
registration decisions. In cases where a registration decision could
be perceived as creating a conflict of interest for a particular
Expert, that Expert should defer to the judgment of the other
Experts.
The registry is initially populated with the values in Table 6.
9.3.1. Registration Template
Parameter name:
Parameter name as used in the DOTS signal channel.
CBOR Key Value:
Key value for the parameter. The key value MUST be an integer in
the 1-65535 range. The key values of the comprehension-required
range (0x0001 - 0x3FFF) and of the comprehension-optional range
(0x8000 - 0xBFFF) are assigned by IETF Review [RFC8126]. The key
values of the comprehension-optional range (0x4000 - 0x7FFF) are
assigned by Designated Expert [RFC8126] and of the comprehension-
optional range (0xC000 - 0xFFFF) are reserved for Private Use
[RFC8126].
CBOR Major Type:
CBOR Major type and optional tag for the parameter.
Reddy, et al. Expires March 9, 2019 [Page 77]
Internet-Draft DOTS Signal Channel Protocol September 2018
Change Controller:
For Standards Track RFCs, list the "IESG". For others, give the
name of the responsible party. Other details (e.g., postal
address, email address, home page URI) may also be included.
Specification Document(s):
Reference to the document or documents that specify the parameter,
preferably including URIs that can be used to retrieve copies of
the documents. An indication of the relevant sections may also be
included but is not required.
9.3.2. Initial Registry Content
+----------------------+-------+-------+------------+---------------+
| Parameter Name | CBOR | CBOR | Change | Specification |
| | Key | Major | Controller | Document(s) |
| | Value | Type | | |
+----------------------+-------+-------+------------+---------------+
| ietf-dots-signal-chan| 1 | 5 | IESG | [RFCXXXX] |
| nel:mitigation-scope | | | | |
| scope | 2 | 4 | IESG | [RFCXXXX] |
| cdid | 3 | 3 | IESG | [RFCXXXX] |
| cuid | 4 | 3 | IESG | [RFCXXXX] |
| mid | 5 | 0 | IESG | [RFCXXXX] |
| target-prefix | 6 | 4 | IESG | [RFCXXXX] |
| target-port-range | 7 | 4 | IESG | [RFCXXXX] |
| lower-port | 8 | 0 | IESG | [RFCXXXX] |
| upper-port | 9 | 0 | IESG | [RFCXXXX] |
| target-protocol | 10 | 4 | IESG | [RFCXXXX] |
| target-fqdn | 11 | 4 | IESG | [RFCXXXX] |
| target-uri | 12 | 4 | IESG | [RFCXXXX] |
| alias-name | 13 | 4 | IESG | [RFCXXXX] |
| lifetime | 14 | 0/1 | IESG | [RFCXXXX] |
| mitigation-start | 15 | 0 | IESG | [RFCXXXX] |
| status | 16 | 0 | IESG | [RFCXXXX] |
| conflict-information | 17 | 5 | IESG | [RFCXXXX] |
| conflict-status | 18 | 0 | IESG | [RFCXXXX] |
| conflict-cause | 19 | 0 | IESG | [RFCXXXX] |
| retry-timer | 20 | 0 | IESG | [RFCXXXX] |
| conflict-scope | 21 | 5 | IESG | [RFCXXXX] |
| acl-list | 22 | 4 | IESG | [RFCXXXX] |
| acl-name | 23 | 3 | IESG | [RFCXXXX] |
| acl-type | 24 | 3 | IESG | [RFCXXXX] |
| bytes-dropped | 25 | 0 | IESG | [RFCXXXX] |
| bps-dropped | 26 | 0 | IESG | [RFCXXXX] |
| pkts-dropped | 27 | 0 | IESG | [RFCXXXX] |
| pps-dropped | 28 | 0 | IESG | [RFCXXXX] |
| attack-status | 29 | 0 | IESG | [RFCXXXX] |
Reddy, et al. Expires March 9, 2019 [Page 78]
Internet-Draft DOTS Signal Channel Protocol September 2018
| ietf-dots-signal- | 30 | 5 | IESG | [RFCXXXX] |
| channel:signal-config| | | | |
| sid | 31 | 0 | IESG | [RFCXXXX] |
| mitigating-config | 32 | 5 | IESG | [RFCXXXX] |
| heartbeat-interval | 33 | 5 | IESG | [RFCXXXX] |
| min-value | 34 | 0 | IESG | [RFCXXXX] |
| max-value | 35 | 0 | IESG | [RFCXXXX] |
| current-value | 36 | 0 | IESG | [RFCXXXX] |
| missing-hb-allowed | 37 | 5 | IESG | [RFCXXXX] |
| max-retransmit | 38 | 5 | IESG | [RFCXXXX] |
| ack-timeout | 39 | 5 | IESG | [RFCXXXX] |
| ack-random-factor | 40 | 5 | IESG | [RFCXXXX] |
| min-value-decimal | 41 | 6tag4 | IESG | [RFCXXXX] |
| max-value-decimal | 42 | 6tag4 | IESG | [RFCXXXX] |
| current-value- | 43 | 6tag4 | IESG | [RFCXXXX] |
| decimal | | | | |
| idle-config | 44 | 5 | IESG | [RFCXXXX] |
| trigger-mitigation | 45 | 7 | IESG | [RFCXXXX] |
| ietf-dots-signal-chan| 46 | 5 | IESG | [RFCXXXX] |
| nel:redirected-signal| | | | |
| alt-server | 47 | 3 | IESG | [RFCXXXX] |
| alt-server-record | 48 | 4 | IESG | [RFCXXXX] |
+----------------------+-------+-------+------------+---------------+
Table 6: Initial DOTS Signal Channel CBOR Mappings Registry
9.4. Media Type Registration
This section registers the "application/dots+cbor" media type in the
"Media Types" registry [IANA.MediaTypes] in the manner described in
RFC 6838 [RFC6838], which can be used to indicate that the content is
a DOTS signal channel object.
9.4.1. Registry Contents
o Type name: application
o Subtype name: dots+cbor
o Required parameters: N/A
o Optional parameters: N/A
o Encoding considerations: binary
o Security considerations: See the Security Considerations section
of [RFCXXXX]
o Interoperability considerations: N/A
o Published specification: [RFCXXXX]
o Applications that use this media type: DOTS agents sending DOTS
messages over CoAP over (D)TLS.
o Fragment identifier considerations: N/A
o Additional information:
Reddy, et al. Expires March 9, 2019 [Page 79]
Internet-Draft DOTS Signal Channel Protocol September 2018
Magic number(s): N/A
File extension(s): N/A
Macintosh file type code(s): N/A
o Person & email address to contact for further information:
IESG, iesg@ietf.org
o Intended usage: COMMON
o Restrictions on usage: none
o Author: Tirumaleswar Reddy, kondtir@gmail.com
o Change controller: IESG
o Provisional registration? No
9.5. CoAP Content-Formats Registration
This section registers the CoAP Content-Format ID for the
"application/dots+cbor" media type in the "CoAP Content-Formats"
registry [IANA.CoAP.Content-Formats].
9.5.1. Registry Contents
o Media Type: application/dots+cbor
o Encoding: -
o Id: TBD
o Reference: [RFCXXXX]
9.6. CBOR Tag registration
This section defines the DOTS CBOR tag as another means for
applications to declare that a CBOR data structure is a DOTS signal
channel object. Its use is optional and is intended for use in cases
in which this information would not otherwise be known. DOTS CBOR
tag is not required for DOTS signal channel protocol version "v1.0".
If present, the DOTS tag MUST prefix a DOTS signal channel object.
This section registers the DOTS signal channel CBOR tag in the "CBOR
Tags" registry [IANA.CBOR.Tags].
9.6.1. Registry Contents
o CBOR Tag: TBD (please assign the same value as the Content-Format)
o Data Item: DDoS Open Threat Signaling (DOTS) signal channel object
o Semantics: DDoS Open Threat Signaling (DOTS) signal channel
object, as defined in [RFCXXXX]
o Description of Semantics: [RFCXXXX]
o Point of Contact: Tirumaleswar Reddy, kondtir@gmail.com
Reddy, et al. Expires March 9, 2019 [Page 80]
Internet-Draft DOTS Signal Channel Protocol September 2018
9.7. DOTS Signal Channel YANG Module
This document requests IANA to register the following URI in the
"IETF XML Registry" [RFC3688]:
URI: urn:ietf:params:xml:ns:yang:ietf-dots-signal-channel
Registrant Contact: The IESG.
XML: N/A; the requested URI is an XML namespace.
This document requests IANA to register the following YANG module in
the "YANG Module Names" registry [RFC7950].
name: ietf-signal
namespace: urn:ietf:params:xml:ns:yang:ietf-dots-signal-channel
prefix: signal
reference: RFC XXXX
10. Security Considerations
Authenticated encryption MUST be used for data confidentiality and
message integrity. The interaction between the DOTS agents requires
Datagram Transport Layer Security (DTLS) and Transport Layer Security
(TLS) with a cipher suite offering confidentiality protection and the
guidance given in [RFC7525] MUST be followed to avoid attacks on
(D)TLS. The (D)TLS protocol profile for DOTS signal channel is
specified in Section 7.
If TCP is used between DOTS agents, an attacker may be able to inject
RST packets, bogus application segments, etc., regardless of whether
TLS authentication is used. Because the application data is TLS
protected, this will not result in the application receiving bogus
data, but it will constitute a DoS on the connection. This attack
can be countered by using TCP-AO [RFC5925]. If TCP-AO is used, then
any bogus packets injected by an attacker will be rejected by the
TCP-AO integrity check and therefore will never reach the TLS layer.
Rate-limiting DOTS requests, including those with new 'cuid' values,
from the same DOTS client defends against DoS attacks that would
result in varying the 'cuid' to exhaust DOTS server resources. Rate-
limit policies SHOULD be enforced on DOTS gateways (if deployed) and
DOTS servers.
In order to prevent leaking internal information outside a client-
domain, DOTS gateways located in the client-domain SHOULD NOT reveal
the identification information that pertains to internal DOTS clients
(e.g., source IP address, client's hostname) unless explicitly
configured to do so.
Reddy, et al. Expires March 9, 2019 [Page 81]
Internet-Draft DOTS Signal Channel Protocol September 2018
DOTS servers MUST verify that requesting DOTS clients are entitled to
trigger actions on a given IP prefix. That is, only actions on IP
resources that belong to the DOTS client' domain MUST be authorized
by a DOTS server. The exact mechanism for the DOTS servers to
validate that the target prefixes are within the scope of the DOTS
client's domain is deployment-specific.
The presence of DOTS gateways may lead to infinite forwarding loops,
which is undesirable. To prevent and detect such loops, this
document uses the Hop-Limit Option.
CoAP-specific security considerations are discussed in Section 11 of
[RFC7252], while CBOR-related security considerations are discussed
in Section 8 of [RFC7049].
11. Contributors
The following individuals have contributed to this document:
o Jon Shallow, NCC Group, Email: jon.shallow@nccgroup.trust
o Mike Geller, Cisco Systems, Inc. 3250 Florida 33309 USA, Email:
mgeller@cisco.com
o Robert Moskowitz, HTT Consulting Oak Park, MI 42837 United States,
Email: rgm@htt-consult.com
o Dan Wing, Email: dwing-ietf@fuggles.com
12. Acknowledgements
Thanks to Christian Jacquenet, Roland Dobbins, Roman D. Danyliw,
Michael Richardson, Ehud Doron, Kaname Nishizuka, Dave Dolson, Liang
Xia, Gilbert Clark, Xialiang Frank, Jim Schaad, Klaus Hartke and
Nesredien Suleiman for the discussion and comments.
Thanks to the core WG for the recommendations on Hop-Limit and
redirect signaling.
13. References
13.1. Normative References
[IANA.CBOR.Tags]
IANA, "Concise Binary Object Representation (CBOR) Tags",
<http://www.iana.org/assignments/cbor-tags/
cbor-tags.xhtml>.
Reddy, et al. Expires March 9, 2019 [Page 82]
Internet-Draft DOTS Signal Channel Protocol September 2018
[IANA.CoAP.Content-Formats]
IANA, "CoAP Content-Formats",
<http://www.iana.org/assignments/core-parameters/
core-parameters.xhtml#content-formats>.
[IANA.MediaTypes]
IANA, "Media Types",
<http://www.iana.org/assignments/media-types>.
[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>.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
DOI 10.17487/RFC3688, January 2004,
<https://www.rfc-editor.org/info/rfc3688>.
[RFC4279] Eronen, P., Ed. and H. Tschofenig, Ed., "Pre-Shared Key
Ciphersuites for Transport Layer Security (TLS)",
RFC 4279, DOI 10.17487/RFC4279, December 2005,
<https://www.rfc-editor.org/info/rfc4279>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246,
DOI 10.17487/RFC5246, August 2008,
<https://www.rfc-editor.org/info/rfc5246>.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
<https://www.rfc-editor.org/info/rfc5280>.
[RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known
Uniform Resource Identifiers (URIs)", RFC 5785,
DOI 10.17487/RFC5785, April 2010,
<https://www.rfc-editor.org/info/rfc5785>.
[RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS)
Extensions: Extension Definitions", RFC 6066,
DOI 10.17487/RFC6066, January 2011,
<https://www.rfc-editor.org/info/rfc6066>.
Reddy, et al. Expires March 9, 2019 [Page 83]
Internet-Draft DOTS Signal Channel Protocol September 2018
[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>.
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,
January 2012, <https://www.rfc-editor.org/info/rfc6347>.
[RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object
Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049,
October 2013, <https://www.rfc-editor.org/info/rfc7049>.
[RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J.,
Weiler, S., and T. Kivinen, "Using Raw Public Keys in
Transport Layer Security (TLS) and Datagram Transport
Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250,
June 2014, <https://www.rfc-editor.org/info/rfc7250>.
[RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
Application Protocol (CoAP)", RFC 7252,
DOI 10.17487/RFC7252, June 2014,
<https://www.rfc-editor.org/info/rfc7252>.
[RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre,
"Recommendations for Secure Use of Transport Layer
Security (TLS) and Datagram Transport Layer Security
(DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May
2015, <https://www.rfc-editor.org/info/rfc7525>.
[RFC7641] Hartke, K., "Observing Resources in the Constrained
Application Protocol (CoAP)", RFC 7641,
DOI 10.17487/RFC7641, September 2015,
<https://www.rfc-editor.org/info/rfc7641>.
[RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
RFC 7950, DOI 10.17487/RFC7950, August 2016,
<https://www.rfc-editor.org/info/rfc7950>.
[RFC7959] Bormann, C. and Z. Shelby, Ed., "Block-Wise Transfers in
the Constrained Application Protocol (CoAP)", RFC 7959,
DOI 10.17487/RFC7959, August 2016,
<https://www.rfc-editor.org/info/rfc7959>.
Reddy, et al. Expires March 9, 2019 [Page 84]
Internet-Draft DOTS Signal Channel Protocol September 2018
[RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage
Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085,
March 2017, <https://www.rfc-editor.org/info/rfc8085>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>.
[RFC8323] Bormann, C., Lemay, S., Tschofenig, H., Hartke, K.,
Silverajan, B., and B. Raymor, Ed., "CoAP (Constrained
Application Protocol) over TCP, TLS, and WebSockets",
RFC 8323, DOI 10.17487/RFC8323, February 2018,
<https://www.rfc-editor.org/info/rfc8323>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>.
13.2. Informative References
[I-D.boucadair-core-hop-limit]
Boucadair, M., Reddy, T., and J. Shallow, "Constrained
Application Protocol (CoAP) Hop Limit Option", draft-
boucadair-core-hop-limit-00 (work in progress), August
2018.
[I-D.ietf-core-comi]
Veillette, M., Stok, P., Pelov, A., and A. Bierman, "CoAP
Management Interface", draft-ietf-core-comi-03 (work in
progress), June 2018.
[I-D.ietf-core-yang-cbor]
Veillette, M., Pelov, A., Somaraju, A., Turner, R., and A.
Minaburo, "CBOR Encoding of Data Modeled with YANG",
draft-ietf-core-yang-cbor-06 (work in progress), February
2018.
[I-D.ietf-dots-architecture]
Mortensen, A., Andreasen, F., Reddy, T.,
christopher_gray3@cable.comcast.com, c., Compton, R., and
N. Teague, "Distributed-Denial-of-Service Open Threat
Signaling (DOTS) Architecture", draft-ietf-dots-
architecture-07 (work in progress), September 2018.
Reddy, et al. Expires March 9, 2019 [Page 85]
Internet-Draft DOTS Signal Channel Protocol September 2018
[I-D.ietf-dots-data-channel]
Boucadair, M., Reddy, T., Nishizuka, K., Xia, L., Patil,
P., Mortensen, A., and N. Teague, "Distributed Denial-of-
Service Open Threat Signaling (DOTS) Data Channel
Specification", draft-ietf-dots-data-channel-19 (work in
progress), September 2018.
[I-D.ietf-dots-requirements]
Mortensen, A., Moskowitz, R., and T. Reddy, "Distributed
Denial of Service (DDoS) Open Threat Signaling
Requirements", draft-ietf-dots-requirements-15 (work in
progress), August 2018.
[I-D.ietf-dots-use-cases]
Dobbins, R., Migault, D., Fouant, S., Moskowitz, R.,
Teague, N., Xia, L., and K. Nishizuka, "Use cases for DDoS
Open Threat Signaling", draft-ietf-dots-use-cases-16 (work
in progress), July 2018.
[I-D.ietf-tls-dtls13]
Rescorla, E., Tschofenig, H., and N. Modadugu, "The
Datagram Transport Layer Security (DTLS) Protocol Version
1.3", draft-ietf-tls-dtls13-28 (work in progress), July
2018.
[proto_numbers]
"IANA, "Protocol Numbers"", 2011,
<http://www.iana.org/assignments/protocol-numbers>.
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,
DOI 10.17487/RFC0791, September 1981,
<https://www.rfc-editor.org/info/rfc791>.
[RFC1983] Malkin, G., Ed., "Internet Users' Glossary", FYI 18,
RFC 1983, DOI 10.17487/RFC1983, August 1996,
<https://www.rfc-editor.org/info/rfc1983>.
[RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network
Address Translator (Traditional NAT)", RFC 3022,
DOI 10.17487/RFC3022, January 2001,
<https://www.rfc-editor.org/info/rfc3022>.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, DOI 10.17487/RFC3986, January 2005,
<https://www.rfc-editor.org/info/rfc3986>.
Reddy, et al. Expires March 9, 2019 [Page 86]
Internet-Draft DOTS Signal Channel Protocol September 2018
[RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram
Congestion Control Protocol (DCCP)", RFC 4340,
DOI 10.17487/RFC4340, March 2006,
<https://www.rfc-editor.org/info/rfc4340>.
[RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing
(CIDR): The Internet Address Assignment and Aggregation
Plan", BCP 122, RFC 4632, DOI 10.17487/RFC4632, August
2006, <https://www.rfc-editor.org/info/rfc4632>.
[RFC4732] Handley, M., Ed., Rescorla, E., Ed., and IAB, "Internet
Denial-of-Service Considerations", RFC 4732,
DOI 10.17487/RFC4732, December 2006,
<https://www.rfc-editor.org/info/rfc4732>.
[RFC4787] Audet, F., Ed. and C. Jennings, "Network Address
Translation (NAT) Behavioral Requirements for Unicast
UDP", BCP 127, RFC 4787, DOI 10.17487/RFC4787, January
2007, <https://www.rfc-editor.org/info/rfc4787>.
[RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol",
RFC 4960, DOI 10.17487/RFC4960, September 2007,
<https://www.rfc-editor.org/info/rfc4960>.
[RFC4987] Eddy, W., "TCP SYN Flooding Attacks and Common
Mitigations", RFC 4987, DOI 10.17487/RFC4987, August 2007,
<https://www.rfc-editor.org/info/rfc4987>.
[RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
"Session Traversal Utilities for NAT (STUN)", RFC 5389,
DOI 10.17487/RFC5389, October 2008,
<https://www.rfc-editor.org/info/rfc5389>.
[RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP
Authentication Option", RFC 5925, DOI 10.17487/RFC5925,
June 2010, <https://www.rfc-editor.org/info/rfc5925>.
[RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X.
Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052,
DOI 10.17487/RFC6052, October 2010,
<https://www.rfc-editor.org/info/rfc6052>.
[RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful
NAT64: Network Address and Protocol Translation from IPv6
Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146,
April 2011, <https://www.rfc-editor.org/info/rfc6146>.
Reddy, et al. Expires March 9, 2019 [Page 87]
Internet-Draft DOTS Signal Channel Protocol September 2018
[RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms
(SHA and SHA-based HMAC and HKDF)", RFC 6234,
DOI 10.17487/RFC6234, May 2011,
<https://www.rfc-editor.org/info/rfc6234>.
[RFC6296] Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Prefix
Translation", RFC 6296, DOI 10.17487/RFC6296, June 2011,
<https://www.rfc-editor.org/info/rfc6296>.
[RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown,
"Default Address Selection for Internet Protocol Version 6
(IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012,
<https://www.rfc-editor.org/info/rfc6724>.
[RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type
Specifications and Registration Procedures", BCP 13,
RFC 6838, DOI 10.17487/RFC6838, January 2013,
<https://www.rfc-editor.org/info/rfc6838>.
[RFC6887] Wing, D., Ed., Cheshire, S., Boucadair, M., Penno, R., and
P. Selkirk, "Port Control Protocol (PCP)", RFC 6887,
DOI 10.17487/RFC6887, April 2013,
<https://www.rfc-editor.org/info/rfc6887>.
[RFC6888] Perreault, S., Ed., Yamagata, I., Miyakawa, S., Nakagawa,
A., and H. Ashida, "Common Requirements for Carrier-Grade
NATs (CGNs)", BCP 127, RFC 6888, DOI 10.17487/RFC6888,
April 2013, <https://www.rfc-editor.org/info/rfc6888>.
[RFC7413] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP
Fast Open", RFC 7413, DOI 10.17487/RFC7413, December 2014,
<https://www.rfc-editor.org/info/rfc7413>.
[RFC7452] Tschofenig, H., Arkko, J., Thaler, D., and D. McPherson,
"Architectural Considerations in Smart Object Networking",
RFC 7452, DOI 10.17487/RFC7452, March 2015,
<https://www.rfc-editor.org/info/rfc7452>.
[RFC7589] Badra, M., Luchuk, A., and J. Schoenwaelder, "Using the
NETCONF Protocol over Transport Layer Security (TLS) with
Mutual X.509 Authentication", RFC 7589,
DOI 10.17487/RFC7589, June 2015,
<https://www.rfc-editor.org/info/rfc7589>.
[RFC7918] Langley, A., Modadugu, N., and B. Moeller, "Transport
Layer Security (TLS) False Start", RFC 7918,
DOI 10.17487/RFC7918, August 2016,
<https://www.rfc-editor.org/info/rfc7918>.
Reddy, et al. Expires March 9, 2019 [Page 88]
Internet-Draft DOTS Signal Channel Protocol September 2018
[RFC7924] Santesson, S. and H. Tschofenig, "Transport Layer Security
(TLS) Cached Information Extension", RFC 7924,
DOI 10.17487/RFC7924, July 2016,
<https://www.rfc-editor.org/info/rfc7924>.
[RFC7951] Lhotka, L., "JSON Encoding of Data Modeled with YANG",
RFC 7951, DOI 10.17487/RFC7951, August 2016,
<https://www.rfc-editor.org/info/rfc7951>.
[RFC8305] Schinazi, D. and T. Pauly, "Happy Eyeballs Version 2:
Better Connectivity Using Concurrency", RFC 8305,
DOI 10.17487/RFC8305, December 2017,
<https://www.rfc-editor.org/info/rfc8305>.
[RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams",
BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018,
<https://www.rfc-editor.org/info/rfc8340>.
Authors' Addresses
Tirumaleswar Reddy (editor)
McAfee, Inc.
Embassy Golf Link Business Park
Bangalore, Karnataka 560071
India
Email: kondtir@gmail.com
Mohamed Boucadair (editor)
Orange
Rennes 35000
France
Email: mohamed.boucadair@orange.com
Prashanth Patil
Cisco Systems, Inc.
Email: praspati@cisco.com
Reddy, et al. Expires March 9, 2019 [Page 89]
Internet-Draft DOTS Signal Channel Protocol September 2018
Andrew Mortensen
Arbor Networks, Inc.
2727 S. State St
Ann Arbor, MI 48104
United States
Email: amortensen@arbor.net
Nik Teague
Verisign, Inc.
United States
Email: nteague@verisign.com
Reddy, et al. Expires March 9, 2019 [Page 90]