idnits 2.17.1 draft-teague-dots-protocol-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC0793], [I-D.reddy-dots-data-channel], [RFC0768]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 15, 2017) is 2625 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) ** Obsolete normative reference: RFC 5405 (Obsoleted by RFC 8085) ** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147) ** Obsolete normative reference: RFC 6555 (Obsoleted by RFC 8305) == Outdated reference: A later version (-18) exists of draft-ietf-dots-architecture-01 ** Downref: Normative reference to an Informational draft: draft-ietf-dots-architecture (ref. 'I-D.ietf-dots-architecture') == Outdated reference: A later version (-22) exists of draft-ietf-dots-requirements-03 ** Downref: Normative reference to an Informational draft: draft-ietf-dots-requirements (ref. 'I-D.ietf-dots-requirements') -- Possible downref: Non-RFC (?) normative reference: ref. 'PROTOBUF' == Outdated reference: A later version (-05) exists of draft-reddy-dots-data-channel-03 -- Obsolete informational reference (is this intentional?): RFC 1519 (Obsoleted by RFC 4632) -- Obsolete informational reference (is this intentional?): RFC 5575 (Obsoleted by RFC 8955) Summary: 7 errors (**), 0 flaws (~~), 4 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DOTS N. Teague 3 Internet-Draft Verisign, Inc. 4 Intended status: Standards Track A. Mortensen 5 Expires: August 19, 2017 Arbor Networks, Inc. 6 February 15, 2017 8 DDoS Open Threat Signaling Protocol 9 draft-teague-dots-protocol-02 11 Abstract 13 This document describes Distributed-Denial-of-Service (DDoS) Open 14 Threat Signaling (DOTS), a protocol for requesting and managing 15 mitigation of DDoS attacks. 17 DOTS mitigation requests over the signal channel permit domains to 18 signal the need for help fending off DDoS attacks, setting the scope 19 and duration of the requested mitigation. Elements called DOTS 20 servers field the signals for help, and enable defensive 21 countermeasures to defend against the attack reported by the clients, 22 reporting the status of the delegated defense to the requesting 23 clients. DOTS clients additionally may use a reliable data channel 24 to manage filters and black- and white-lists to restrict or allow 25 traffic to the clients' domains arbitrarily. The DOTS signal channel 26 may operate over UDP [RFC0768] and if necessary TCP [RFC0793]. This 27 revision discusses a transport-agnostic approach to this channel, 28 focusing on the message exchanges and delegating transport specifics 29 to other documents. Discussion of the reliable data channel may be 30 found in [I-D.reddy-dots-data-channel]. 32 Status of This Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at http://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on August 19, 2017. 49 Copyright Notice 51 Copyright (c) 2017 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (http://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 67 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 68 2. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 4 69 2.1. DOTS Agents . . . . . . . . . . . . . . . . . . . . . . . 4 70 3. DOTS Communication Channels . . . . . . . . . . . . . . . . . 5 71 4. Signal Channel . . . . . . . . . . . . . . . . . . . . . . . 5 72 4.1. Minimum Viable Information . . . . . . . . . . . . . . . 6 73 4.2. Signal Channel Messages . . . . . . . . . . . . . . . . . 7 74 4.2.1. Messaging Overview . . . . . . . . . . . . . . . . . 7 75 4.2.2. Message Definition and Serialization . . . . . . . . 9 76 4.2.3. Client Message Fields . . . . . . . . . . . . . . . . 9 77 4.2.4. Mitigation Request Fields . . . . . . . . . . . . . . 10 78 4.2.5. DOTS Server Message Fields . . . . . . . . . . . . . 11 79 4.2.6. Server Errors . . . . . . . . . . . . . . . . . . . . 11 80 4.2.7. Server Mitigation Status Fields . . . . . . . . . . . 13 81 4.3. Interactions . . . . . . . . . . . . . . . . . . . . . . 13 82 4.3.1. Session Initialization . . . . . . . . . . . . . . . 13 83 4.3.2. Heartbeat . . . . . . . . . . . . . . . . . . . . . . 15 84 4.3.3. Mitigation Request Handling . . . . . . . . . . . . . 18 85 4.3.4. Ancillary Messages . . . . . . . . . . . . . . . . . 20 86 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 87 6. Security Considerations . . . . . . . . . . . . . . . . . . . 23 88 7. Appendix A: Message Schemas . . . . . . . . . . . . . . . . . 23 89 7.1. DOTS Client Message Schema . . . . . . . . . . . . . . . 23 90 7.2. Mitigation Request Schema . . . . . . . . . . . . . . . . 23 91 7.3. Session Configuration Schema . . . . . . . . . . . . . . 24 92 7.4. DOTS Server Message Schema . . . . . . . . . . . . . . . 24 93 7.5. DOTS Redirect Schema . . . . . . . . . . . . . . . . . . 25 94 7.6. DOTS Mitigation Status Schema . . . . . . . . . . . . . . 26 95 7.7. Server Error Schema . . . . . . . . . . . . . . . . . . . 26 96 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 27 97 8.1. Normative References . . . . . . . . . . . . . . . . . . 27 98 8.2. Informative References . . . . . . . . . . . . . . . . . 28 99 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29 101 1. Introduction 103 Distributed-Denial-of-Service attack scale and frequency continues to 104 increase year over year, and the trend shows no signs of abating 105 [WISR]. In response to the DDoS attack trends, service providers and 106 vendors have developed various approaches to sharing or delegating 107 responsibility for defense, among them ad hoc service relationships, 108 filtering through peering relationships [COMMUNITYFS], and 109 proprietary solutions ([CLOUDSIGNAL], [OPENHYBRID]). Such hybrid 110 approaches to DDoS defense have proven effective, but the 111 heterogeneous methods employed to coordinate DDoS defenses across 112 domain boundaries have necessarily limited their scope and 113 effectiveness, as the mechanisms in one domain have no traction in 114 another. 116 The DDoS Open Threat Signaling (DOTS) protocol provides a common 117 mechanism to achieve the coordinated attack response previously 118 restricted to custom or proprietary solutions. To meet the needs of 119 network operators facing down modern DDoS attacks, DOTS itself is a 120 hybrid protocol, consisting of a signal channel and a data channel. 121 DOTS uses the signal channel, a lightweight and robust communication 122 layer, to signal the need for mitigation regardless of network 123 conditions, and uses the reliable data channel as vehicle for 124 provisioning, configuration, telemetry, filter management, and other 125 unsized or bulk data exchange. 127 The DOTS protocol is not intended as a replacement for such protocols 128 as BGP Flow Specification [RFC5575] or as a general purpose DDoS 129 countermeasure application programming interface (API), but rather as 130 an advisory protocol enabling attack response coordination between 131 DOTS agents. Any DOTS-enabled device or service is capable of 132 triggering a request for help and shaping the scope and nature of 133 that help, with the details of the actual mitigation left to the 134 discretion of the operators of the attack mitigators. DOTS thereby 135 permits all participating parties to manage their own attack defenses 136 in the manner most appropriate for their own domains. 138 1.1. Terminology 140 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 141 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 142 document are to be interpreted as described in [RFC2119]. 144 Terms used to define entity relationships, transmitted data, and 145 methods of communication are drawn from the terminology defined in 146 [I-D.ietf-dots-requirements]. 148 2. Architecture 150 The architecture in which the DOTS protocol operates is assumed to be 151 derived from the architectural components and concepts described in 152 [I-D.ietf-dots-architecture]. 154 2.1. DOTS Agents 156 All protocol communication is between a DOTS client and a DOTS 157 server. The logical agent termed a DOTS gateway is in practice a 158 DOTS server placed back-to-back with a DOTS client. As discussed in 159 [I-D.ietf-dots-architecture], any interface enabling the back-to-back 160 DOTS server and client to act as a DOTS gateway is implementation- 161 specific. This protocol is therefore concerned only with managing 162 one or more bilateral relationships between DOTS clients and the DOTS 163 servers, a signaling mode known as Direct Signaling in the DOTS 164 architecture. This is shown in Figure 1 below: 166 +-----------+ signal channel +-----------+ 167 | |<---------------->| | 168 |DOTS client| |DOTS server| 169 | |<================>| | 170 +-----------+ data channel +-----------+ 172 Figure 1: DOTS protocol direct signaling 174 The DOTS architecture anticipates many-to-one and one-to-many 175 deployments, in which multiple DOTS clients maintain distinct 176 signaling sessions with a single DOTS server or a single DOTS client 177 maintains distinct signaling sessions with multiple DOTS servers, as 178 shown below in Figure 2: 180 +----+ +----+ +----+ 181 | c1 | | Sa |------| c2 | 182 +----+ +----+ +----+ 183 \ / 184 \ / 185 \ +----+ / 186 +--| Sb |--+ 187 +----+ 189 DOTS DOTS DOTS 190 client 1 servers client 2 192 Figure 2: DOTS protocol direct signaling 194 DOTS server Sb has signaling sessions with DOTS clients c1 and c2. 195 DOTS client c2 has signaling sessions with DOTS servers Sa and Sb. 196 Except where explicitly defined in this protocol, all mechanisms to 197 maintain multiple signaling sessions are left to the implementation. 199 3. DOTS Communication Channels 201 DOTS uses two channels, a signal channel and a data channel. 203 The signal channel is the minimal secure communication layer a DOTS 204 client uses to request mitigation for resources under the 205 administrative control the DOTS client; administrative control may be 206 delegated. 208 The data channel offers DOTS clients a limited ability to manage 209 configuration and attack filtering for requested mitigations. The 210 data channel offers DOTS client operators the limited ability to 211 adjust configuration and filtering for their mitigation requests. 213 This document describes the DOTS signal channel. The data channel is 214 defined separately in [I-D.reddy-dots-data-channel]. 216 4. Signal Channel 218 The purpose of the signaling channel is to convey DDoS mitigation 219 request and status information between participating agents (client 220 and server or gateway). Conditions during a DDoS attack are 221 invariably hostile for connection-oriented protocols traversing 222 affected paths. Mechanisms such as Happy Eyeballs [RFC6555] may be 223 used to select a transport suitable for a given time and prevailing 224 network conditions. 226 Implementations are required to support the DOTS signal channel over 227 UDP as specified in [I-D.ietf-dots-requirements]. This document 228 therefore assumes the the availability of a transport based upon UDP 229 [RFC0768], but also defines the message exchanges agnostic of the 230 underlying transport used to convey the signaling. 232 Key tenets of DOTS protocol design are low communication overhead and 233 efficient message packing to increase the chances of successful 234 transmission and receipt. Desirable side-effects of efficient 235 packing are the removal of the possibility of fragmentation in 236 addition to a message size that is friendly towards encapsulation 237 (e.g via GRE [RFC2784] or MPLS [RFC3031]). Large UDP packets may 238 also be treated adversely by middleboxes with restrictive policies or 239 may fall foul of aggressive filtering. 241 In support of operational requirements for protocol efficiency, 242 backward compatibility and extensibility in 243 [I-D.ietf-dots-requirements], the signaling channel uses Protocol 244 Buffers [PROTOBUF], also known as Protobufs, to define message 245 schemas and serialize messages exchanged between DOTS agents. 247 The security requirements described in [I-D.ietf-dots-requirements] 248 (peer mutual authentication, message confidentiality and integrity, 249 and message replay protection are not discussed here. However, these 250 qualities must be present in the transport over which the DOTS signal 251 channel operates. 253 Key distribution in support of those security requirements to may be 254 achieved via the data channel, via an online mechanism such as DANE 255 [RFC6698], Enrollment over Secure Transport [RFC7030], or by out-of- 256 band means. The key distribution mechanism is not specified in this 257 document, but operators must take care to ensure the distribution 258 provides the same level of security demanded by the signal channel 259 itself. 261 4.1. Minimum Viable Information 263 DOTS is intended to be extensible and to evolve to meet the future 264 needs in communicating as yet unknown threats. However, it must be 265 able to convey the minimum information required for an upstream 266 mitigation platform to successfully counter a DDoS attack. A client 267 may have limited visibility into the full breadth of an attack and as 268 such may not be well placed to provide useful telemetry. DDoS 269 sources may or may not be spoofed and number in the millions. Once 270 mitigation is active, the filtered traffic seen by the DOTS client 271 (or elements informing the DOTS client operator's decision to request 272 mitigation) may not be representative of the ongoing attack. This 273 provides challenges for the quality and usefulness of telemetry and 274 mitigation/countermeasure stipulations and as such this type of 275 information if conveyed can only be considered advisory. 277 In these instances the minimum viable information required for the 278 majority of mitigations to be activated is that which pertains to the 279 resource being targeted by the attack (host, prefix, protocol, port, 280 URI etc.), per [I-D.ietf-dots-requirements] (OP-006). The DOTS 281 requirements also identify a mitigation lifetime period (OP-005) and 282 mitigation efficacy metric (OP-007). The former may be considered 283 for inclusion in the minimum viable information set, however, the 284 latter may only be relevant in updates. An explicit mitigation 285 request/terminate flag is also required: a mitigation MUST be 286 explicitly requested by a DOTS client operator. Finally, each 287 message should include a message id or sequence number field as well 288 as a field for the last received message id or sequence number. 289 These may then be compared by the endpoints to assist in tracking 290 state and/or identifying loss. 292 4.2. Signal Channel Messages 294 4.2.1. Messaging Overview 296 The signal channel requirements in [I-D.ietf-dots-requirements] 297 demand a protocol capable of operating despite significant link 298 congestion between DOTS agents. In an effort to maximize the 299 probability of signal delivery between DOTS agents, all DOTS signal 300 channel messages in the DOTS protocol are conceptually unidirectional 301 heartbeats sent between DOTS agents. 303 The result is a form of scheduled messaging between DOTS agents, in 304 contrast to a conventional request-response model. Once a signal 305 channel is established, a DOTS client begins sending unidirectional 306 heartbeats to the DOTS server, separated by the configured session 307 heartbeat interval (see Section 4.3.1 below). To request mitigation, 308 a DOTS client merely adds the requested mitigation parameters to its 309 heartbeat, and maintains that request until a heartbeat from the DOTS 310 server indicates receipt of that mitigation request. The DOTS server 311 likewise sends its unidirectional heartbeat on the schedule interval, 312 augmenting the content of the heartbeat with mitigation request 313 status. 315 A simple exchange between DOTS agents with an established signaling 316 session is shown below in Figure 3. 318 Client Server 319 | | // Active signaling session 320 |<==== Signal Channel Active ====>| // with heartbeat interval of 321 | | // 15 seconds, +/- jitter. 322 | | 323 |----------Heartbeat------------->| // Client heartbeat 324 | | 325 |<---------Heartbeat--------------| // Server heartbeat 326 | | 327 \ \ // 15 seconds elapse, during 328 / / // which client adds request 329 \ \ // for mitigation. 330 | | 331 |----------HeartBeat------------->| // Client heartbeat now has 332 | + MitigationRequest | // mitigation request params. 333 | | 334 |<---------HeartBeat--------------| // Server heartbeat now has 335 | + MitigationPending | // pending mitigation request 336 | | // status. 337 | | 338 \ \ 339 / / // 15s elapse, +/- jitter. 340 \ \ 341 | | 342 |----------HeartBeat------------->| // Client heartbeat maintains 343 | + MitigationRequest | // request as it waits for 344 | | // mitigation to begin. 345 | | 346 | X----HeartBeat--------------| // Mitigation enabled, but 347 | + MitigationRunning | // server heartbeat is dropped 348 | | 349 \ \ 350 / / // 15s elapse, +/- jitter. 351 \ \ 352 | | 353 |----------HeartBeat------------->| // Client heartbeat maintains 354 | + MitigationRequest | // request as it waits for 355 | | // mitigation to begin. 356 | | 357 |<---------HeartBeat--------------| // Server heartbeat, status of 358 | + MitigationRunning | // running mitigation 359 | | // delivered to client. 361 Figure 3: Signaling Session with Mitigation Request 363 All messages are variations of this scheduled heartbeat model. See 364 Section 4.3 below for detailed discussion of the message exchanges 365 between DOTS agents. 367 4.2.2. Message Definition and Serialization 369 The DOTS protocol signal channel uses Protobufs [PROTOBUF] as an 370 interface definition language (IDL) for signal channel messaging 371 between DOTS agent, reducing the number of discrete messages to just 372 a single message superset per direction, with function defined by the 373 chosen fields contained within the message. 375 Protobufs schemas are used to define the messages sent in either 376 direction, from which code may be generated for specific language 377 implementations of DOTS. As Protobufs serialization relies on 378 numbered fields, signal channel messaging permits the introduction of 379 new numbered fields arbitrarily, adding the requisite extensibility 380 to the protocol while retaining backward compatibility. Future 381 revisions of or extensions to the protocol may use the data channel 382 to provide a mechanism by which schema updates or expansions may be 383 communicated during provisioning/session establishment. 385 4.2.3. Client Message Fields 387 Only the seqno and last_svr_seqno fields are required in every 388 message, as they are the minimum required for the heartbeat. Subsets 389 of the other fields are used to convey a given signal message type. 391 The fields in the DOTS client signal channel message have the 392 following functions: 394 seqno: a client-generated sequence number unique to the message. 395 The client increments the seqno value by one for each message sent 396 over the signal channel. 398 last_svr_seqno: the sequence number of the last message received 399 from the server, provided to the server as a simple way to detect 400 lost messages. 402 mitigations: a list of mitigations requested or withdrawn by the 403 client. The mitigation schema fields are described below. 405 active: indicates a request for a list of active mitigations and 406 their detail that are current on the DOTS server. 408 ping: an operator initiated heartbeat like message which will elicit 409 a response from the DOTS server. This may be used to prove bi- 410 directional communications on an ad-hoc basis. For example, a 411 DOTS ping may be used to prove keying material on the DOTS client 412 is valid and may be used to establish signaling sessions with the 413 DOTS server. 415 extensions: these fields may be used to communicate implementation 416 specific details. An example would be the dissemination of 417 filters between DOTS client and DOTS server. 419 4.2.3.1. Client Message Schema 421 The DOTS client message schema is detailed in Section 7.1. 423 4.2.4. Mitigation Request Fields 425 The fields in a mitigation request are as follows: 427 eventid: an opaque client generated identifier that distinguishes a 428 unique event or incident. May be used by the client as a 429 reference to the specific event triggering a mitigation request, 430 or for other implementation-specific purposes. 432 requested: signals the need for mitigation to the DOTS server. If 433 true, the DOTS client is requesting mitigation for the provided 434 scope. If false, the DOTS client is indicating it does not 435 require mitigation, and the DOTS server MUST cease the mitigation 436 for the provided scope. 438 scope: the scope of the mitigation requested, which may be any of 439 the types described in [I-D.ietf-dots-requirements], such as 440 Classless Internet Domain Routing (CIDR) [RFC1518],[RFC1519] 441 prefixes, DNS names, or aliases defined by the DOTS client 442 operator through the data channel. 444 lifetime: the lifetime in seconds a mitigation request should be 445 considered valid. 447 efficacy: a metric to convey to a DOTS server the perceived efficacy 448 of an active mitigation, per operational requirements in 449 [I-D.ietf-dots-requirements]. The mitigation efficacy is 450 represented as a floating point value between 0 and 1, with 451 smaller values indicating lesser efficacy, and larger greater 452 efficacy. 454 extensions: these fields may be used to provide implementation- 455 specific mitigation details. 457 4.2.4.1. Mitigation Request Schema 459 The DOTS client message schema is detailed in Section 7.2. 461 4.2.5. DOTS Server Message Fields 463 DOTS server messages use a subset of the available fields to convey 464 the given signal type, including additional relevant fields as 465 necessary. The only fields which may be common to all signals are 466 seqno and last_client_seqno which may be used to detect message loss 467 or out-of-order delivery. When conveying mitigation information, the 468 server schema may bundle multiple mitigation status datasets into a 469 single message, provided this does not violate the required sub-MTU 470 message size [I-D.ietf-dots-requirements]. 472 The fields in the DOTS server signal channel message schema have the 473 following functions: 475 seqno: a server generated sequence number unique to the message. 477 last_cli_seqno: the seqno of the last message received from the 478 client. 480 ping: an operator-initiated heartbeat like message which will elicit 481 a response from the DOTS client. This may be used to prove bi- 482 directional communications on an ad-hoc basis. 484 error: details of an error caused by a DOTS client request. 486 redirect: Populated with the details of the redirection target DOTS 487 server, if the DOTS server is redirecting the DOTS client to 488 another DOTS server. 490 mitigations: a list containing the status of mitigations requested 491 by the DOTS client. The fields in the mitigation status schema 492 are described below. 494 extensions: these fields may be used to communicate implementation 495 specific details. An example would be the communication of DNS 496 mitigation vip to the DOTS client by the DOTS server. 498 4.2.5.1. DOTS Server Message Schema 500 The server message schema is detailed in Section 7.4. 502 4.2.6. Server Errors 504 If a DOTS client message cannot be processed by the DOTS server, or 505 for any other reason causes an error, the DOTS server MUST populate 506 the error field in any response to the message causing the error. As 507 the error response itself may be lost, a DOTS client may continue 508 sending problematic messages regardless of the DOTS server's error 509 notifications. DOTS server implementations MAY terminate the 510 signaling session after client-triggered errors exceed a threshold 511 during a time period equivalent to three times the session heartbeat 512 interval. 514 The DOTS client message triggering the error condition is indicated 515 in the last_client_seqno value of the DOTS server message containing 516 the error. 518 Error codes MUST be one of the following types: 520 NOERROR: Indicates the DOTS server has detected no error resulting 521 from a DOTS client message. Implementations MAY omit the error 522 field entirely when no error condition is present. This value is 523 included in the schema largely to adhere to the convention that an 524 error status of 0 indicates success. 526 INVALID_VALUE: Indicates the DOTS client included an invalid value 527 for a field in the client message most recently received from the 528 client. The DOTS server SHOULD include specifics of the invalid 529 value in the details field of the error. 531 MITIGATION_UNAVAILABLE: Indicates the DOTS server is unable to 532 provide mitigation in response to a mitigation request from the 533 DOTS client. 535 MITIGATION_CONFLICT: Indicates a mitigation request conflicts with 536 an existing mitigation from the client. The DOTS server SHOULD 537 populate the error details field with the status information of 538 the mitigation conflicting with the requested mitigation. 540 MALFORMED_MESSAGE: Indicates the DOTS client message is malformed 541 and cannot be processed. 543 4.2.6.1. Server Error Fields 545 code: a numeric code categorizing the error type detected by the 546 DOTS server. 548 details: specific information about the reason for the detected 549 error. 551 4.2.6.2. Server Error Schema 553 The server error schema is detailed in Section 7.7. 555 4.2.7. Server Mitigation Status Fields 557 The DOTS server message contains zero or more mitigation status 558 messages, the fields of which have the following functions: 560 eventid: an opaque client generated identifier that distinguishes a 561 unique event or incident. 563 ttl: the remaining lifetime of the mitigation, in seconds. 565 bytes_dropped: the total dropped byte count for the mitigation 566 associated with eventid. 568 bps_dropped: the dropped bytes per second for the mitigation 569 associated with eventid. This value is expected to be calculated 570 by the mitigator, and as such is implementation-specific. 572 pkts_dropped: the total dropped packet count for the mitigation 573 associated with eventid.. 575 pps_dropped: the dropped packets per second for the mitigation 576 associated with eventid. This value is expected to be calculated 577 by the mitigator, and as such is implementation-specific. 579 blacklist_enabled: Indicates whether a blacklist of prohibited 580 traffic sources is enabled for the mitigation associated with 581 eventid. The blacklist is managed through the data channel. 583 whitelist_enabled: Indicates whether a whitelist of sources from 584 which traffic must always be allowed is enabled. The whitelist is 585 managed through the data channel. 587 filters_enabled: Indicates whether client-specified traffic filters 588 are enabled for the mitigation associated with eventid. 590 4.3. Interactions 592 4.3.1. Session Initialization 594 Signaling sessions are initiated by the DOTS client. Session 595 initialization begins when the DOTS client connects to the DOTS 596 server port, 4646. After connecting, the DOTS client establishes the 597 channel security context, including all necessary cryptographic 598 exchanges between the two DOTS agents. 600 This signal channel specification is transport-agnostic, and 601 delegates the details of transport, including transport security, to 602 transport-specific documents. Regardless of transport, DOTS 603 implementations nonetheless MUST provide signal channel security 604 meeting the requirements in [I-D.ietf-dots-requirements]. 606 Once the signal channel security context is established, the DOTS 607 client sends a channel initialization message to the DOTS server, 608 optionally including signaling session configuration values; if the 609 session configuration values are excluded, defaults MUST be used for 610 the signaling session. An example initialization message setting the 611 acceptable signal loss and heartbeat interval for the signaling 612 sessions is described in Figure 4 below: 614 message DOTSClientMessage { 615 1 (seqno) = %; 616 2 (last_svr_seqno) = %; 617 6 (config) = { 618 1 (loss_limit) = %; 619 3 (heartbeat_interval) = %; 620 }; 621 } 623 Figure 4: Signal Channel Initialization Message 625 The DOTS server MUST respond immediately by sending a heartbeat (see 626 Section 4.3.2 below) to the DOTS client. The signal channel is 627 active when the DOTS client receives a heartbeat from the DOTS server 628 with a last_client_seqno of a signal channel initialization message. 629 Both DOTS agents MUST begin sending heartbeats on the interval for 630 the signaling session once the session is active. 632 The following example assumes a DOTS implementation using UDP as the 633 transport and DTLS1.2 [RFC6347]. In Figure 5 below, the DOTS client 634 uses the default values for acceptable signal loss, maximum 635 mitigation lifetime, and heartbeat interval. The initial DOTS server 636 heartbeat is lost, so the DOTS client sends another channel 637 initialization message after waiting for the minimum heartbeat 638 interval defined below in Section 4.3.2: 640 Client Server 641 | | 642 |<- - - - DTLS1.2 handshake - - ->| // Server listens on UDP:4646. 643 | | // Client initiates DTLS 644 | | // handshake. 645 | | 646 |----------ChannelInit----------->| // Client sends signal 647 | seqno = 1 | // channel init message 648 | last_svr_seqno = 0 | 649 | | 650 | X----HeartBeat--------------| // Server immediately sends 651 | seqno = 1 | // heartbeat reply, which 652 | last_client_seqno = 1 | // is lost. 653 | | 654 \ \ // Session heartbeat interval 655 / / // elapses. 656 \ \ 657 |----------ChannelInit----------->| // Client retries signal 658 | seqno = 2 | // channel init message. 659 | last_svr_seqno = 0 | 660 | | 661 |<---------HeartBeat--------------| // Server immediately sends 662 | seqno = 2 | // heartbeat reply 663 | last_client_seqno = 2 | 664 | | 665 |<==== Signal Channel Active ====>| 667 Figure 5: Signal Channel Initialization 669 4.3.1.1. Session Initialization Error Handling 671 If the DOTS client specifies invalid values for the signal channel 672 configuration, the DOTS server replies with an error, and may 673 ultimately terminate the connection if the client fails to correct 674 the invalid values, as described in [I-D.ietf-dots-architecture]. 676 4.3.1.2. Mis-Sequencing 678 In the event that the DOTS agent receives messages containing invalid 679 seqno, last_client_seqno or last_svr_seqno these should be discarded 680 and ignored. 682 4.3.2. Heartbeat 684 The most common message exchanged between a DOTS client and a DOTS 685 server is a heartbeat (OP-002 [I-D.ietf-dots-requirements]), which 686 maintains and monitors the health of the DOTS session. This is 687 achieved with simple, loosely-coupled bi-directional messages 688 containing the sending DOTS agent's message sequence number and the 689 sequence number the sending DOTS agent last received from its peer. 690 Due to the stress volumetric DDoS impose upon a network, a degree of 691 loss during attacks is to be expected. Message loss tolerance may be 692 set on signal channel establishment. 694 The default heartbeat interval is 20 seconds, plus or minus a number 695 of milliseconds between 50 and 2000. The number of milliseconds MUST 696 be randomized in order to introduce jitter into the heartbeat 697 interval, as recommended by [RFC5405]. The default interval is 698 derived from the recommendations in [RFC5405] regarding middlebox 699 traversal, to maintain NAT bindings in the path between DOTS agents. 701 The interval between heartbeats is may also be set by the client when 702 establishing the signal channel. The minimum heartbeat interval is 703 15 seconds, plus the random number of milliseconds as described 704 above. The maximum heartbeat interval is 120 seconds (two minutes), 705 minus the random number of milliseconds described above. 707 Heartbeats are loosely-coupled, meaning each DOTS agent in a 708 bilateral signaling session sends DOTS heartbeats on the specified 709 interval, but asynchronously, without acknowledgement. Each DOTS 710 agent tracks heartbeats received from its peer, and includes the 711 sequence number of the last heartbeat received from the peer agent in 712 the next heartbeat sent, as shown in Figure 6: 714 Client Server 715 | | 716 |----------HeartBeat------------->| // Client heartbeat 717 | seqno = 1 | 718 | last_svr_seqno = 0 | 719 | | 720 |<---------HeartBeat--------------| // Server heartbeat 721 | seqno = 1 | 722 | last_client_seqno = 1 | 723 | | 724 |----------HeartBeat------------->| // Client heartbeat 725 | seqno = 2 | 726 | last_svr_seqno = 1 | 727 | | 728 | X---HeartBeat--------------| // Server heartbeat lost 729 | seqno = 2 | 730 | last_client_seqno = 2 | 731 | | 732 |----------HeartBeat------------->| // Client heartbeat, 733 | seqno = 3 | // last_svr_seqno remains 1, 734 | last_svr_seqno = 1 | // indicating lost heartbeat 735 | | 736 |<---------HeartBeat--------------| // Server heartbeat resumes 737 | seqno = 3 | 738 | last_client_seqno = 3 | 739 | | 740 |----------HeartBeat------------->| // Client heartbeat 741 | seqno = 4 | 742 | last_svr_seqno = 3 | 743 | | 745 Figure 6: Heartbeats Between DOTS agents 747 The DOTS client heartbeat has the following format: 749 message DOTSClientMessage { 750 1 (seqno) = %; 751 2 (last_svr_seqno) = %; 752 } 754 The DOTS server heartbeat is identical aside from the schema type: 756 message DOTSServerMessage { 757 1 (seqno) = %; 758 2 (last_svr_seqno) = %; 759 } 761 Should the number of signals lost exceed the acceptable lossiness 762 value for the signaling session, the agent detecting the signal loss 763 may consider the signaling session lost. The default value for 764 acceptable signal loss is 9, which, when coupled with the default 765 heartbeat interval, amounts to lack of heartbeat from the peer DOTS 766 agent for 180 seconds (three minutes). 768 4.3.2.1. Ping 770 There may be cases where a DOTS client or server operator wishes to 771 trigger an immediate heartbeat response in order to validate bi- 772 directional communication (e.g. during provisioning). This ad-hoc 773 triggering may be achieved by setting the ping field set to TRUE. 774 When DOTS agent receives a message on the signal channel with the 775 ping field set to TRUE, it MUST immediately send heartbeat back to 776 the ping sender. A ping reply MUST consist of only the senders 777 sequence number and the sequence number of the received ping. 778 [[EDITOR'S NOTE: rate limiting of pings required?]] 780 A ping is identical to a standard heartbeat, but with the ping field 781 included and set to true: 783 message DOTSClientMessage { 784 1 (seqno) = %; 785 2 (last_svr_seqno) = %; 786 5 (ping) = true; 787 } 789 4.3.3. Mitigation Request Handling 791 The mitigation request is the crux of the DOTS protocol, and is 792 comprised of the minimum viable information described in Section 4.1. 793 The request may be augmented with additional implementation specific 794 extensions where these do not result in undue packet bloat. The DOTS 795 client may send repeated requests until it receives a suitable 796 response from the DOTS server by which it may interpret successful 797 receipt. 799 message DOTSClientMessage { 800 1 (seqno) = %; 801 2 (last_svr_seqno) = %; 802 3 (mitigations) = [ 803 { 804 1 (eventid) = %; 805 2 (requested) = %; 806 3 (scope) = %; 807 4 (lifetime) = %; 808 } 809 ]; 810 } 812 The DOTS server is expected to respond to confirm that it has 813 accepted and or rejected the mitigation request. Upon receipt of the 814 response the DOTS client should cease sending additional initial 815 requests for the same eventid. If these do not cease then the server 816 may assume that the response was possibly lost and should resend 817 accordingly. Acceptance status is communicated by the DOTS server 818 replying with the corresponding eventid and the enabled field set to 819 1 for acceptance and 0 for rejection. A rejection by the DOTS server 820 should be accompanied with an extension field detailing succinctly 821 the reason (e.g. out of contract, conflict, maintenance etc. ). 823 message DOTSServerMessage { 824 1 (seqno) = %; 825 2 (last_cli_seqno) = %; 826 4 (mitigations) = [ 827 { 828 1 (eventid) = %; 829 2 (enabled) = true; // Mitigation request accepted 830 } 831 ] 832 } 834 After a period of time the mitigation request may expire and the DOTS 835 server may end the mitigation. Alternately, the DOTS client may 836 explicitly terminate the active mitigation by sending a message to 837 the server that contains a mitigation value with the eventid and that 838 has the requested field set to false, as shown below: 840 message DOTSClientMessage { 841 1 (seqno) = %; 842 2 (last_svr_seqno) = %; 843 3 (mitigations) = [ 844 { 845 1 (eventid) = %; 846 2 (requested) = false; // Terminate mitigation 847 } 848 ]; 849 } 851 The server must explicitly acknowledge the termination with a 852 response message with the enabled field now set to false: 854 message DOTSServerMessage { 855 1 (seqno) = %; 856 2 (last_cli_seqno) = %; 857 6 (mitigations) = [ 858 { 859 1 (eventid) = %; 860 2 (enabled) = false; // Mitigation terminated 861 } 862 ]; 863 } 865 The life cycle of a DOTS mitigation request resembles the following: 867 Client Server 868 | | 869 |---Request(M=true)----------->| // Mitigation request 870 | | 871 |<---------MitigationActive----| // Server acceptance 872 | | 873 |< - - - - MitigationFeedback -| 874 | | 875 |---Terminate(M=false)-------->| // Mitigation termination 876 | | 877 |<---------MitigationEnded-----| // Server termination ack 879 4.3.4. Ancillary Messages 881 In addition to the basic interaction, additional messages may be 882 exchanged throughout the lifetime of the mitigation. The following 883 message types are defined to provide requisite information between 884 DOTS agents during an active signaling session. 886 4.3.4.1. Mitigation Feedback 888 The DOTS server MUST update the client with current mitigation 889 status. This MUST include the eventid, and SHOULD include available 890 dropped attack traffic statistics provided by the mitigator. A DOTS 891 server MAY provide feedback for more than one mitigation in a single 892 message, provided the resulting message meets the sub-MTU size 893 requirements in [I-D.ietf-dots-requirements]. 895 The DOTS client SHOULD use the feedback from the DOTS server when 896 deciding to update or terminate a mitigation request. For example, 897 if the DOTS client learns from DOTS server mitigation feedback that 898 the dropped_pps rate is low, the DOTS client might decide to 899 terminate upstream mitigation and handle the attack locally. 901 A mitigation feedback message from the DOTS server would resemble the 902 following format, assuming an active mitigation request from the DOTS 903 client: 905 message DOTSServerMessage { 906 1 (seqno) = %; 907 2 (last_client_seqno) = %; 908 6 (mitigations) = [ 909 { 910 1 (eventid) = %; 911 2 (enabled) = %; 912 3 (ttl) = %; 913 4 (bytes_dropped) = %; 914 5 (bps_dropped) = %; 915 6 (pkts_dropped) = %; 916 7 (pps_dropped) = %; 917 10 (filters_enabled) = true; 918 }, 919 ]; 920 } 922 4.3.4.2. Mitigation Lifetime Update 924 The DOTS client may wish to update the mitigation during its 925 lifetime. Updates may be to alter the lifetime to extend the 926 mitigation, or an update may communicate the perceived efficacy of 927 the mitigation. The former may be as a result of the DOTS sever 928 feedback which may suggest that an attack shows no sign of abating. 929 The latter may be to notify the DOTS server whether the 930 countermeasures deployed are perceived as effective or not. 932 A DOTS client may update the lifetime of multiple mitigations in a 933 single request as long as the message size meets the sub-MTU 934 requirement per [I-D.ietf-dots-requirements]. The lifetime update 935 message has the following format: 937 message DOTSClientMessage { 938 1 (seqno) = %; 939 2 (last_svr_seqno) = %; 940 3 (mitigations) = [ 941 { 942 1 (eventid) = %; 943 2 (requested) = true; 944 4 (lifetime) = %; 945 } 946 ]; 947 } 949 Upon receipt of the mitigation lifetime update, the DOTS server 950 replace the current mitigation expiration time with the new value. 951 The updated lifetime MUST be visible in the ttl field in subsequent 952 mitigation feedback messages. When updating a mitigation lifetime, 953 the DOTS client SHOULD continue sending the lifetime update request 954 at the heartbeat interval until the DOTS server's mitigation feedback 955 shows an updated ttl for the updated mitigation. 957 4.3.4.3. Mitigation Efficacy Updates 959 When a mitigation is active, a DOTS client MUST periodically 960 communicate the locally perceived efficacy of the mitigation to the 961 DOTS server. This gives the DOTS server a rough sense of whether the 962 DOTS client perceives the mitigator's deployed countermeasures as 963 effective. The efficacy update update message has the following 964 format: 966 message DOTSClientMessage { 967 1 (seqno) = %; 968 2 (last_svr_seqno) = %; 969 3 (mitigations) = [ 970 { 971 1 (eventid) = %; 972 6 (efficacy) = %; 973 } 974 ]; 975 } 977 The DOTS server SHOULD consider the efficacy update an indication of 978 the effectiveness of any ongoing mitigations related to the eventid 979 provided by the DOTS client. The DOTS server nonetheless MAY treat 980 any efficacy update from the client as advisory, and is under no 981 obligation to alter the mitigation strategy in response. 983 5. IANA Considerations 985 The DOTS protocol requires a well-known port to which DOTS client 986 messages are sent. The DOTS server listens on the well-known port 987 for client messages. The DOTS client binds to an ephemeral port per 988 Section 4.3.1 above. This document selects port 4646 (the ASCII 989 decimal values for "..": "DOTS") as the well-known port. 991 6. Security Considerations 993 The DOTS protocol controls mitigation request and withdrawal and as 994 such care must be taken to protect against concerns outlined in the 995 security considerations of [I-D.ietf-dots-architecture]. 997 7. Appendix A: Message Schemas 999 7.1. DOTS Client Message Schema 1001 syntax = "proto3"; 1002 import "google/protobuf/any.proto"; 1004 message DOTSClientMessage { 1005 // Client generated sequence number 1006 uint64 seqno = 1; 1008 // Sequence number of last received server message 1009 uint64 last_svr_seqno = 2; 1011 repeated DOTSMitigation mitigations = 3; 1013 // Request active mitigation list from server 1014 bool active = 4; 1016 // Ping request (operator initiated) 1017 bool ping = 5; 1019 DOTSSessionConfig config = 6; 1021 repeated google.protobuf.Any extensions = 999; 1022 } 1024 Figure 7: DOTS Client Message Schema 1026 7.2. Mitigation Request Schema 1027 message DOTSMitigation { 1028 // Opaque client-generated event identifier 1029 string eventid = 1; 1031 // Toggle mitigation for the above scope 1032 bool requested = 2; 1034 // Mitigation scope as described in I-D.ietf-dots-requirements 1035 string scope = 3; 1037 // Lifetime of the requested mitigation. 1038 uint32 lifetime = 4; 1040 // Mitigation efficacy score as a float value between 0 and 1 1041 float efficacy = 5; 1043 repeated google.protobuf.Any extensions = 999; 1044 } 1046 Figure 8: DOTS Client Mitigation Request Schema 1048 7.3. Session Configuration Schema 1050 // Per session configuration sent on signaling session init 1051 message DOTSSessionConfig { 1052 // Acceptable signal loss 1053 uint32 loss_limit = 1; 1055 // Maximum mitigation lifetime in seconds 1056 uint32 lifetime_max = 2; 1058 // Heartbeat interval in milliseconds 1059 uint32 heartbeat_interval = 3; 1060 } 1062 Figure 9: DOTS Session Conifiguration Schema 1064 7.4. DOTS Server Message Schema 1065 syntax = "proto3"; 1066 import "google/protobuf/any.proto"; 1068 message DOTSServerMessage { 1069 // Server generated sequence number 1070 uint64 seqno = 1; 1072 // Sequence number of last received Client message 1073 uint64 last_client_seqno = 2; 1075 // Request immediate heartbeat response from client. 1076 bool ping = 3; 1078 // Server error details, if available 1079 DOTSServerError error = 4; 1081 DOTSRedirect redirect = 5; 1083 // Mitigation data, limited by MTU 1084 repeated DOTSMitigationStatus mitigations = 6; 1085 } 1087 Figure 10: DOTS Server Message Schema 1089 7.5. DOTS Redirect Schema 1091 message DOTSRedirect { 1092 // Redirection target DOTS server address 1093 string target = 1; 1095 // Address family of redirection target 1096 enum RedirectionTargetType { 1097 DNSNAME = 0; 1098 IPV4 = 4; 1099 IPV6 = 6; 1100 } 1101 RedirectionTargetType target_type = 2; 1103 // Port on which to contact redirection target. 1104 // XXX Protobufs has no uint16 type, implementations 1105 // will need to sanity check. 1106 uint32 port = 3; 1107 } 1109 7.6. DOTS Mitigation Status Schema 1111 syntax = "proto3"; 1112 import "google/protobuf/any.proto"; 1114 message DOTSMitigationStatus { 1115 // Opaque Client generated event identifier, used by DOTS client 1116 // to associate a mitigation status with the event triggering the 1117 // mitigation request. 1118 string eventid = 1; 1120 // Mitigation state 1121 bool enabled = 2; 1123 // Mitigation time-to-live (lifetime - (now - start)) 1124 uint32 ttl = 3; 1126 // Dropped byte count 1127 uint64 bytes_dropped = 4; 1129 // Dropped bits per second 1130 uint64 bps_dropped = 5; 1132 // Dropped packet count 1133 uint64 pkts_dropped = 6; 1135 // Dropped packets per second 1136 uint64 pps_dropped = 7; 1138 // Blacklist enabled through data channel 1139 bool blacklist_enabled = 8; 1141 // Whitelist enabled through data channel 1142 bool whitelist_enabled = 9; 1144 // Filters enabled through data channel 1145 bool filters_enabled = 10; 1147 repeated google.protobuf.Any extensions = 999; 1148 } 1150 Figure 11: DOTS Server Mitigation Status Schema 1152 7.7. Server Error Schema 1153 syntax = "proto3"; 1154 import "google/protobuf/any.proto"; 1156 message DOTSServerError { 1157 enum ErrorCode { 1158 NOERROR = 0; 1159 INVALID_VALUE = 1; 1160 MITIGATION_UNAVAILABLE = 2; 1161 MITIGATION_CONFLICT = 3; 1162 MALFORMED_MESSAGE = 4; 1163 } 1164 ErrorCode code = 1; 1166 // Error details, returned as a blob 1167 google.protobuf.Any details = 2; 1168 } 1170 Figure 12: DOTS Server Error Schema 1172 8. References 1174 8.1. Normative References 1176 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, DOI 1177 10.17487/RFC0768, August 1980, 1178 . 1180 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 1181 793, DOI 10.17487/RFC0793, September 1981, 1182 . 1184 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1185 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 1186 RFC2119, March 1997, 1187 . 1189 [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. 1190 Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, 1191 DOI 10.17487/RFC2784, March 2000, 1192 . 1194 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 1195 Label Switching Architecture", RFC 3031, DOI 10.17487/ 1196 RFC3031, January 2001, 1197 . 1199 [RFC5405] Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines 1200 for Application Designers", BCP 145, RFC 5405, DOI 1201 10.17487/RFC5405, November 2008, 1202 . 1204 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 1205 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 1206 January 2012, . 1208 [RFC6555] Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with 1209 Dual-Stack Hosts", RFC 6555, DOI 10.17487/RFC6555, April 1210 2012, . 1212 [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication 1213 of Named Entities (DANE) Transport Layer Security (TLS) 1214 Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August 1215 2012, . 1217 [RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed., 1218 "Enrollment over Secure Transport", RFC 7030, DOI 1219 10.17487/RFC7030, October 2013, 1220 . 1222 [I-D.ietf-dots-architecture] 1223 Mortensen, A., Andreasen, F., Reddy, T., 1224 christopher_gray3@cable.comcast.com, c., Compton, R., and 1225 N. Teague, "Distributed-Denial-of-Service Open Threat 1226 Signaling (DOTS) Architecture", draft-ietf-dots- 1227 architecture-01 (work in progress), October 2016. 1229 [I-D.ietf-dots-requirements] 1230 Mortensen, A., Moskowitz, R., and T. Reddy, "Distributed 1231 Denial of Service (DDoS) Open Threat Signaling 1232 Requirements", draft-ietf-dots-requirements-03 (work in 1233 progress), October 2016. 1235 [PROTOBUF] 1236 Google, Inc., "Protocol Buffers", 2016, 1237 . 1239 8.2. Informative References 1241 [I-D.reddy-dots-data-channel] 1242 Reddy, T., Boucadair, M., Nishizuka, K., Xia, L., and P. 1243 Patil, "Distributed Denial-of-Service Open Threat 1244 Signaling (DOTS) Data Channel", draft-reddy-dots-data- 1245 channel-03 (work in progress), December 2016. 1247 [RFC1518] Rekhter, Y. and T. Li, "An Architecture for IP Address 1248 Allocation with CIDR", RFC 1518, DOI 10.17487/RFC1518, 1249 September 1993, . 1251 [RFC1519] Fuller, V., Li, T., Yu, J., and K. Varadhan, "Classless 1252 Inter-Domain Routing (CIDR): an Address Assignment and 1253 Aggregation Strategy", RFC 1519, DOI 10.17487/RFC1519, 1254 September 1993, . 1256 [RFC5575] Marques, P., Sheth, N., Raszuk, R., Greene, B., Mauch, J., 1257 and D. McPherson, "Dissemination of Flow Specification 1258 Rules", RFC 5575, DOI 10.17487/RFC5575, August 2009, 1259 . 1261 [CLOUDSIGNAL] 1262 Arbor Networks, Inc., "Cloud Signaling: A Faster, 1263 Automated Way to Mitigate DDoS Attacks", 2011, 1264 . 1267 [COMMUNITYFS] 1268 Team Cymru, Inc., "Community FlowSpec", 2011, 1269 . 1271 [OPENHYBRID] 1272 Verisign, Inc., "Verisign OpenHybrid", 2016, 1273 . 1276 [WISR] Arbor Networks, Inc., "Worldwide Infrastructure Security 1277 Report", 2016, 1278 . 1281 Authors' Addresses 1283 Nik Teague 1284 Verisign, Inc. 1285 12061 Bluemont Way 1286 Reston, VA 20190 1287 United States 1289 Email: nteague@verisign.com 1290 Andrew Mortensen 1291 Arbor Networks, Inc. 1292 2727 S. State St 1293 Ann Arbor, MI 48104 1294 United States 1296 Email: amortensen@arbor.net