DOTS K. Nishizuka Internet-Draft NTT Communications Intended status: Standards Track L. Xia Expires: June 30, 2017 J. Xia Huawei Technologies Co., Ltd. D. Zhang L. Fang Microsoft C. Gray Comcast, Inc. R. Compton Charter Communications, Inc. December 27, 2016 Inter-organization cooperative DDoS protection mechanism draft-nishizuka-dots-inter-domain-mechanism-02 Abstract As DDoS attacks evolve rapidly in the aspect of volume and sophistication, cooperation among operators has become very necessary because it gives us quicker and more sophisticated protection to cope with the varius DDoS attacks. This document describes possible mechanisms which implement the cooperative inter-organization DDoS protection by DOTS protocol. The described data models are intended to cover intra-organization and inter-organization solutions. 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 material or to cite them other than as "work in progress." This Internet-Draft will expire on June 30, 2017. Nishizuka, et al. Expires June 30, 2017 [Page 1] Internet-Draft Inter-organization DDoS protection December 2016 Copyright Notice Copyright (c) 2016 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Key Words . . . . . . . . . . . . . . . . . . . . . . . . 4 2.2. Definition of Terms . . . . . . . . . . . . . . . . . . . 4 3. Inter-organization DDoS Protection Requirements . . . . . . . 4 3.1. Provisioning Requirements . . . . . . . . . . . . . . . . 4 3.1.1. Automatic Provisioning vs Manual Provisioning . . . . 5 3.2. Coordination Requirements . . . . . . . . . . . . . . . . 5 3.2.1. Near Source Protection Problem . . . . . . . . . . . 5 3.3. Returning Path Requirements . . . . . . . . . . . . . . . 6 4. Inter-organization DOTS Architecture . . . . . . . . . . . . 6 4.1. Distributed Architecture . . . . . . . . . . . . . . . . 7 4.2. Centralized Architecture . . . . . . . . . . . . . . . . 10 5. Inter-organization DOTS Protocol . . . . . . . . . . . . . . 11 5.1. Provisioning Stage . . . . . . . . . . . . . . . . . . . 13 5.1.1. Messages . . . . . . . . . . . . . . . . . . . . . . 13 5.1.2. Operations . . . . . . . . . . . . . . . . . . . . . 17 5.2. Signaling Stage . . . . . . . . . . . . . . . . . . . . . 18 5.2.1. Messages . . . . . . . . . . . . . . . . . . . . . . 18 5.2.2. Operations . . . . . . . . . . . . . . . . . . . . . 24 6. Other Considerations . . . . . . . . . . . . . . . . . . . . 25 6.1. Billing Data . . . . . . . . . . . . . . . . . . . . . . 25 7. Security Considerations . . . . . . . . . . . . . . . . . . . 26 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 9. Normative References . . . . . . . . . . . . . . . . . . . . 26 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 Nishizuka, et al. Expires June 30, 2017 [Page 2] Internet-Draft Inter-organization DDoS protection December 2016 1. Introduction These days, DDoS attacks are getting bigger and more sophisticated. All organizations facing to the internet should be prepared for such attacks in order to minimize damages to their business. There are still too big platforms of DDoS attacks which consist of vulnerable servers, broadband routers and other network equipments including IoT devices distributed all over the world. Because of the amplification feature of the reflection attack, attackers can generate massive attacks with small resources. Moreover, there are many booters who are selling DDoS attacks as a service. DDoS attack is commoditized, so frequency of DDoS attacks is also increasing. These trends of the attack could exceed a capacity of a protection system of one organization in the aspect of volume and frequency. Therefore, sharing the capacity and capability of the protection system with each other has become very necessary. By utilizing other organization's resources, the burden of the protection can be shared. The shared resources are not only CPU/ memory resources of dedicated mitigation devices but also the capability of mitigation actions such as blackholing and filtering. We call the protection which utilize resources of each other "cooperative DDoS protection". The cooperative DDoS protection have numerous merits. First, as described above, it can leverage the capacity of the protection by sharing the resources among organizations. Generally DDoS attack happens unexpectedly, thus the capacity utilization ratio of a protection system is not constant. So, while the utilization ratio is low, it can be used by other organization which is under attack. Second, organizations can get various countermeasures. If an attack is highly sophisticated and there is no countermeasure in the system, cooperative DDoS protection can offer optimal countermeasure of all partners. Third, it can block malicious traffic near to the origin of the attack. Near source defense is ideal for the health of the internet because it can reduce the total cost of forwarding packets which are mostly consist of useless massive attack traffic. Sometimes uplink circuits get congested by massive attacks, so cooperative DDoS protection by uplink organization is the only way to solve such a congestion problem. Finally, it can reduce time to respond. After getting attacked, prompt response is important because the outage of the service can make significant loss to the victim organization. Cooperating channel between partner organizations can be automated by DOTS protocol. The proposed solutions are covering both intra-organization and inter-organization situations. Nishizuka, et al. Expires June 30, 2017 [Page 3] Internet-Draft Inter-organization DDoS protection December 2016 1.1. Scope The solutions described in this draft are based on intra-organization and inter-organization usecases in [I-D.draft-ietf-dots-use-cases]. The DOTS protocols coordinating DDoS protection in inter-organization situations in this draft are compliant with requirements in [I- D.draft-ietf-dots-requirements]. Generally DOTS is assumed to be most effective when aiding coordination of attack response between two or more organizations, but single organization scenarios are also valuable[I-D.draft-mortensen-dots-architecture]. The data model described in this draft is mainly focusing on inter-organization coordination of DDoS protection because it also covers single organization scenarios. The information required in single organization scenarios is assumed to be a subset of the information required in inter-organization scenarios. 2. Terminology 2.1. Key Words 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]. 2.2. Definition of Terms This document uses the terms defined in [I-D.draft-ietf-dots- requirements]. 3. Inter-organization DDoS Protection Requirements In this section, requirements unique to inter-organization cooperative DDoS protection are described. 3.1. Provisioning Requirements In inter-organization situation, a DOTS client is in a different organization from a DOTS server. To enable the protection in other organization, provisioning information should be informed to a DOTS server in advance. In the later section, the total scenario is divided into two stages: provisioning stage and signaling stage. In provisioning stage, a DOTS client is required to communicate registration messages with DOTS server which include the capacity building of protection. The data model of registration message is defined in the protocol section of this draft. It is also required to find a way to provision other organization's DDoS protection service in secure manner. All of the messages should have Nishizuka, et al. Expires June 30, 2017 [Page 4] Internet-Draft Inter-organization DDoS protection December 2016 confidentiality, integrity and authenticity. The requirments of the message protocol is following [I-D.draft-ietf-dots-requirements]. 3.1.1. Automatic Provisioning vs Manual Provisioning Manual provisioning is easier way to utilize DDoS protection service of other organizations. An organization can trust other organization who are going to use their DDoS protection service by any means like phone, e-mail, Web portal, etc,. However, it will take much time to provision the DDoS protection system, therefore the attack will succeed to make significant impact on the protected service. To reduce the time to start the protection, automatic provisioning is desirable. If an organization could build a capacity of protection by exchanging information of the DDoS protection service via dots protocol in short time, the cooperative DDoS protection will succeed at a certain level. Other important works carried out in the bootstrapping process are auto-discovery, automatic capability building between the member DDoS protection service providers as the basis for the following coordination process. 3.2. Coordination Requirements The number of the member DDoS protection service provider of cooperative DDoS protection is important factor. If only two providers are involved, there is a bilateral relationship only. It is easy to negotiate about the capacity of their own DDoS protection system. In the state of emergency, they can decide to ask for help each other if the capacity of their own system is insufficient. When a lot of providers are joining cooperative DDoS protection, it is difficult to decide where to ask for help. They need to negotiate about their capacity with every participant. It is needed to take into account all combinations to do appropriate protection. The coordination between the member providers of cooperative DDoS protection is a complete process consisting of mitigation start/stop, status notification, mitigation policy updates and so on. The Inter- organization DOTS architectures described in the later section are intended to fulfill these requirements. 3.2.1. Near Source Protection Problem Stopping malicious traffic at the nearest point in the internet will reduce exhaustion of resources in all the path of the attack. To find the entry point of the attack, traceback of the attack traffic to the origin is needed. If there is cooperative partner near the attack source, asking for help to that network is most effective. However, the problem is that it is difficult to decide which network is nearest to the attack source because in many cases source address of attack packets are spoofed to avoid to be visible from others. Nishizuka, et al. Expires June 30, 2017 [Page 5] Internet-Draft Inter-organization DDoS protection December 2016 Moreover, uncovering some topology information of operator's network would be required in order to make the decision correctly, however there could be privacy protection issue between operators. Those problems will lead to the difficulties of locating the attack source. 3.3. Returning Path Requirements As one of protection methods, some DDoS protection service provider announce BGP route to detour the attack traffic to their own network to deal with it. After scrubbing, cleaned traffic should be returned to the original destination. The returning path is often called "clean pipe". The DDoS service provider should be careful about routing loop because if the end point of a clean pipe is still included in a reach of the announced BGP route, the traffic will return to the mitigation path again and again. In the case of inter- organization DDoS protection, returning path information should be propagated to partners. 4. Inter-organization DOTS Architecture With the fast growth of DDoS attack volume and sophistication, a global cooperative DDoS protection service is desirable. This service can not only address the inter-organization uplink congestion problem, but also take full advantage of global DDoS mitigation resources from different operators efficiently and enable the near source mitigation. Moreover, with the way of providing DDoS mitigation as service, more customers will get the service flexibly by their demands with maximized territory and resources. Together with on- premise DDoS protection appliance, the multiple layer DDoS protection system provides a comprehensive DDoS protection against all types of attacks, such as application layer attacks, network layer large traffic attacks and others. DOTS protocol is used among DOTS agents to facilitate the coordinated DDoS protection service as a whole. [I-D.draft-ietf-dots-use-cases] lists most options that DOTS agents could be, and describes their communications. Although this document is initiated to specify the DOTS protocol for the inter-organization use cases, the final protocol would and should be the same since it is all about the signaling messages and their process between the DOTS clients and DOTS servers essentially. In other words, the protocol described here would also apply to all the intra-organization use cases. To support all the identified use cases and possibly new use cases in future, DOTS protocol must be extensible in terms of the message definition, protocol process, etc, which will be discussed in details in the following section. The text below discusses the protocol mainly in respect of inter-organization use cases. Nishizuka, et al. Expires June 30, 2017 [Page 6] Internet-Draft Inter-organization DDoS protection December 2016 The inter-organization DDoS protection service is set up by the member operators' own DDoS protection system and the coordination protocol between them. The inter-organization protocol for the goal of DDoS protection coordination is the main focus of this document. Note that both network operators and cloud based DDoS protection service providers can participate in the inter-organization DDoS protection service. In general, the member operator's own DDoS protection system should at least consist of attack detector, customer (DOTS client), controller (DOTS server, and possible DOTS client for the inter-organization use cases) and mitigator. Attack Detector: be responsible for attack detection and source traceback. An example is the flow analyzer Customer: when certain DDoS attack is detected, it requests mitigation service to the controller and exchanges status with controller regularly Controller: be responsible for intra-organization DDoS mitigation controlling and communication with customer and other operators' controller for inter-organization coordination Mitigator: be responsible for mitigation and results reporting There are two ways for operators to implement the inter-organization DDoS protection service: distributed way or centralized way. The following parts give the respective discussion to them with aligning to DOTS terms. 4.1. Distributed Architecture Operators can set up the bilateral cooperative relation of DDoS protection between each other, thereby a distributed inter- organization DDoS protection service is realized, which has the peer to peer Communication among all the participated operators. The distributed architecture is illustrated in the following diagram: Nishizuka, et al. Expires June 30, 2017 [Page 7] Internet-Draft Inter-organization DDoS protection December 2016 Customer +-------+ |DOTS | |Client | +----A--+ | ---------------- --+------ ////- \\\\ /// | \\\ /// +-----------------------------+-------+ \\ // +-----------------+-------+ \\ / | | \ || | | | || +-----V-+-----V-+ | | +----V----------+ +---V---+---V---+ | | |DOTS |DOTS | | | |DOTS |DOTS <-->DOTS |DOTS <--+----+--->Server |Client | | | |Server |Client | |Server |Client | | | +-----A-+------A+ | | +--A----+-------+ +----A--+---A---+ | | Controller / | | | Controller Controller\ | | / / | || | | \ \ || \ // // / \\| | \ // \\/ ISP2 / // |\\ ISP1 | \ // \ / \\ / /// | \\\\- | -//// \ / ----/---- | -+-----------+- \ \ / / | | \ \ / / | | \ \ / / +---V---+ +----V--+ \ -----/--- // |DOTS | |DOTS | \// / \\ \\ / |Client | |Client | // \ / \ /\\ +-------+ +-------+ / \ / \ / \ Customer Customer +---V---+----V--+ | +-------+ | |DOTS |DOTS | | |DOTS | | |Client |Server <---+---->Client | | +-------+-------+ | +-------+ | Controller | Customer | | \ cloud based / \\ Anti-DDoS // \\\ Provider /// -------- Figure 1: Distributed Architecture for Inter-organization DDoS Protection Service As shown in above diagram, when the customer is suffering a large traffic DDoS attack, it acts as the DOTS client to request DDoS protection service to its operator. The operator's controller acts as the DOTS server to authenticate the customer's validity and then initiate the intra-organization DDoS mitigation service with its own resource for the customer. If the controller finds the attack volume exceeds it capacity, or the attack type is unknown type, or its Nishizuka, et al. Expires June 30, 2017 [Page 8] Internet-Draft Inter-organization DDoS protection December 2016 inter-organization upstream link is congested, it should act as the DOTS client to request inter-organization coordinated DDoS Protection service to its upstream operators' controller which it has cooperative relation with. The operator's controller should support the functions of DOTS server and DOTS client at the same time in order to participate in the system of inter-organization DDoS protection service. In other words, as the representative for an operator's DDoS protection service, the controller manages and provides DDoS mitigation service to its customer in one hand, but may require helps from other operators under some situation especially when the attack volume exceeds its capacity or the attack is from other operators. The inter-organization coordination can be a repeated process until the nearest operator located from the attack source receives the inter-organization coordination request and starts to mitigate the attack traffic. In particular, each operator is able to decide its responding actions to its peering operator's request flexibly by its internal policies, such as whether or not perform the mitigation function, or relay the request message to other operators. But these are out of the scope of this document. The distributed architecture is straightforward and simple when the number of member operators are not too large. For deployment, all the work an operator needs to do is to configure other cooperative member operator's information (i.e., IP, port, DNS name, etc) and relevant policies for subsequent inter-organization communication. Regarding to operation, each operator's controller just performs the mitigation service according to customer's request and possibly requests for inter-organization helps to other operators if necessary. In the meantime, the mitigation report and statistics information is exchanged between the peering operators for the goal of monitoring and accounting. Some points for this architecture are noted as below: o Every operator controller only has the information of those opeators which have cooperative relation with it, and does not necessarily have the information of all operators participated in the inter-organization DDoS protection service. The incomplete information may not lead to the most optimized operation o When the number of member operators is very large, a new joining operator will be required to configure and maintain a lot of peering operators' information. It's very complex and error-prone o Due to the exclusive repeating nature of the this architecture mentioned above, it's possible that the really effective Nishizuka, et al. Expires June 30, 2017 [Page 9] Internet-Draft Inter-organization DDoS protection December 2016 mitigation service by one upstream operator starts after several rounds of repeating the inter-organization coordination process. It may take a long time and is unacceptable 4.2. Centralized Architecture For the centralized architecture, the biggest difference from the distributed architecture is that a centralized orchestrator exists for controlling the inter-organization DDoS protection coordination centrally. The centralized architecture for the inter-organization DDoS protection service is illustrated in the following diagram: Orchestrator +-------+-------+ ADOTS |DOTS A /|Server |Client |\ / +---AA--+A--A---+ \ / | \ / \ / |/ /\ \ / /| / \ \ -----/---------- / / \ --\------ ////- / /\\\\| \ /// \ \\\ /// / / / |\\ \ // \ \\ // / / / | \\ \/ \ \ || / / / | || \ +-------+---V---+ | | +-----V---------+ /+---V---+---V---+ | | \|DOTS |DOTS | | | |DOTS |DOTS V |DOTS |DOTS | | | VClient |Server | | | |Client |Server | |Server |Client | | | +-------+---A---+ | | +-------+---A---+ +----A--+-------+ | | Controller | | | Controller | | Controller | | | | || | | || \ | / \\ | | // \\ ISP2 | // \\\ | ISP1 | // \\\ |/// \\\\- | | -//// --------+ -+-----------+- | | | | | | | +-----V-+ +----V--+ +---V---+ |DOTS | |DOTS | |DOTS | |Client | |Client | |Client | +-------+ +-------+ +-------+ Customer Customer Customer Figure 2: Centralized Architecture for Inter-organization DDoS Protection Service As shown in above diagram, the orchestrator is the core component to the whole system. Each operator controller only communicates with it Nishizuka, et al. Expires June 30, 2017 [Page 10] Internet-Draft Inter-organization DDoS protection December 2016 for the goal of registering, coordination requesting and reporting. When it receives the inter-organization coordination request message from the operator controller, a simple way is to notify all the other operator controllers which have registered to the orchestrator, to enable the possible mitigation services. Another way is to choose a number of operators to notify them to enable the mitigation services according to the traceback result or other policies. The details about traceback are to be discussed in future. Based on the above analysis, the orchestrator is also a combination of DOTS server and DOTS client which support both functions at the same time. In addition to the orchestrator and its related functions, the signaling and operations of centralized architecture are very similar to the distributed architecture. The centralized architecture has its own characteristics as below: o Since it is the centralized architecture, the orchestrator is easy to suffer the single failure problem like failure, congestion and performance downgrade, which directly influences the availability of the whole system. This can be improved by some redundancy mechanism o A centralized orchestrator facilitates the auto-discovery mechanism for the member operators. And for each controller, its deployment and operation becomes easy since it is only required to communicate with the orchestrator during the whole process o Due to the direct communication between the orchestrator and all controllers, the inter-organization DDoS coordination is able to be finished in a short and fixed time period o Only the central orchestrator is required to support different transport protocols (e.g., TCP, UDP, CoAP) to communicate with all the controllers. The orchestrator is able to translate and relay different transport protocols among all the operators. So, the operator controller uses one transport protocol to communicate with orchestrator and is not required to support multiple kinds of transport protocol 5. Inter-organization DOTS Protocol According to [I-D.draft-ietf-dots-requirements], DOTS protocols MUST take steps to protect the confidentiality, integrity and authenticity of messages sent between the DOTS client and server, and provide peer mutual authentication between the DOTS client and server before a DOTS session is considered active. The DOTS agents can use HTTPS (with TLS) for the goal of protocol security. The HTTP RESTful APIs Nishizuka, et al. Expires June 30, 2017 [Page 11] Internet-Draft Inter-organization DDoS protection December 2016 are used in this section as the protocol channel, and the DOTS message content can be in JSON format. With respect to the inter-organization DOTS protocol, all the DOTS messages are exchanged between DOTS client and server, no matter what the architecture (distributed or centralized) is. So, the message formats and operations of DOTS protocol ought to be the same for all architecture options. The DOTS messages can be categorized by which time period they are mainly required in for DDoS protection, as below: o Provisioning stage: Before getting attacked by malicious traffic, a DOTS client should register itself to the DOTS server, as well as enable capacity building in advance o Signaling stage: Once the DOTS client has registered itself to the DOTS server, the DOTS session is created between them and the signaling stage begins. The signaling stage ends when the DOTS client cancels its registration to the DOTS server and the DOTS session is closed. During the signaling stage, the DOTS client should ask the DOTS server for DDoS mitigation service to the customer service under attack once the attack is detected. When the attack is over, the DOTS client should notify the DOTS server to stop the mitigation service. DOTS protocol can run on HTTPS (with TLS) and support several different ways for authentication: o Employ bidirectional certificate authentication ([ITU-T X.509]) on the DOTS server and client: Both DOTS server and client need to verify the certificates of each other o Employ unidirectional certificate authentication ([ITU-T X.509]) on the DOTS server: Only the DOTS server needs to install the certificate. The DOTS client needs to verify its certificate. In the opposite direction, DOTS server can authenticate DOTS client by the ways of user/role:password, IP address white-list or digital signature o Employ bidirectional digital signature authentication on the DOTS server and client: In this condition, the DOTS server and client must keep the customer's private key safely, which is used for calculate the digital signature Besides authenticating the DOTS client, the DOTS server also verifies the timestamp of the packets from the DOTS client. If the time difference between the timestamp and the current time of the DOTS server exceeds the specified threshold (60 seconds as an example), Nishizuka, et al. Expires June 30, 2017 [Page 12] Internet-Draft Inter-organization DDoS protection December 2016 the DOTS server will consider the packet invalid and will not process it. Therefore, NTP must be configured on both the DOTS server and client to ensure time synchronization. This method can protect DOTS server against the replay attack effectively. The following sections present the detailed description of all the DOTS messages for each stage, and the relevant DOTS protocol operations. 5.1. Provisioning Stage In the provisioning stage, DOTS client can be located either in the customer side, in the operator controller or in the inter- organization orchestrator (for the centralized architecture). In any cases, the DOTS client should register itself to its peering DOTS server which provides the intra/inter organization DDoS mitigation service to it, in order to set up the DOTS protocol session. More importantly, the registration process also facilitates the auto- discovery, capacity building and configuration between the DOTS client and server. 5.1.1. Messages In the provisioning stage, the messages of registration (DOTS client to server), registration response (DOTS server to client), registration cancelling (DOTS client to server) and registration cancelling response (DOTS server to client) are required. Since all the messages in this stage are not expected to be used under the DDoS attack conditions, transmitting all the messages through DOTS data channel over the TLS is able to meet the requirements of reliability, privacy and integrity. The HTTP POST method with the message body in JSON format is used for the registration and registration response messages as below: METHOD:POST - URL:{scheme}://{host}:{port}/dots/api/registration registration body: { "customer_name": string; "ip_version": string; "protected_zone": [ "index": number; "need_alias": string; "ipv4_CIDR": string; "ipv6_address": string; "BGP_route": string; "SIP_URI": string; "E164_number": string; Nishizuka, et al. Expires June 30, 2017 [Page 13] Internet-Draft Inter-organization DDoS protection December 2016 "DNS_name": string; ]; "protected_port": string; "protected_protocol": string; "countermeasures": string; "tunnel_information": string; "next_hop": string; "security_profile": { "TLS": string; "DTLS": string; "CoAP": string; } "white_list": [ "name": string; "source_ip": string; "destination_ip": string; "source_port": string; "destination_port": string; "protocol": string; "length": string; "TTL": string; "DSCP": number; "ip_flags": number; "tcp_flags": number; ]; "black_list": [ "name": string; "source_ip": string; "destination_ip": string; "source_port": string; "destination_port": string; "protocol": string; "length": string; "TTL": string; "DSCP": number; "ip_flags": number; "tcp_flags": number; ]; } registration response body: { "customer_name": string; "customer_id": string; "alias_of_mitigation_address": [ "index": number; "alias": string; ]; "security_profile": string; Nishizuka, et al. Expires June 30, 2017 [Page 14] Internet-Draft Inter-organization DDoS protection December 2016 "access_token": string; "thresholds_bps": number; "thresholds_pps": number; "duration": number; "capable_attack_type": string; "registration_time": string; "mitigation_status": string; } Registration body: customer_name: The name of the customer (DOTS client); ip_version: Current IP version. It can be "v4" or "v6"; protected_zone: Limit the address range of protection. Especially it will be limited to the prefixes possessed by the customer; index: index of the protected zone; need_alias: the flag representing if this protected zone needs an alias. "true" represents that the alias is needed; ipv4_CIDR: ipv4 CIDR address or prefix scope of the protected zone; ipv6_address: ipv6 address or prefix scope of the protected zone; BGP_route: BGP route of the protected zone; SIP_URI: SIP URI of the protected zone; E164_number: E.164 number of the protected zone; DNS_name: DNS name of the protected zone; protected_port: Limit the port range of protection, "0" represents all the ports are to be protected; protected_protocol: Valid protected protocol values include tcp and udp, "all" represents all the protocols are to be protected; countermeasures: Some of the protection need mitigation and others need Blackholing, "all" represents the DOTS client can accept all kinds of countermeasures; tunnel_information: The tunnel between the mitigation provider's network and the customer's network. Tunnel technologies such as GRE[RFC2784] can be used to return normal traffic. "null" represents there is no tunnel information provided and the DOTS server can decide the return tunnel for the normal traffic by itself; next_hop: The returning path to the customer's network. "null" represents there is no next hop information provided and the DOTS server can decide it by itself; security_profile: The security profile in transport layer for the DOTS signaling channel that DOTS client supports; TLS: "true" represents that the DOTS client supports TLS over TCP, "false" represents the opposite side; DTLS: "true" represents that the DOTS client supports DTLS over UDP, "false" represents the opposite side; CoAP: "true" represents that the DOTS client supports CoAP, "false" represents the opposite side; white_list: The white-list information provided to the DOTS server; name: Name of the white-list; source_ip: The source ip address attribute used in the white-list; destination_ip: The destination ip address attribute used in the white-list; source_port: The source port attribute used in the white-list; destination_port": The destination port attribute used in the white-list; protocol: The protocol attribute in ip packet header used in the white-list; length: The length attribute in ip packet header used in the white-list; TTL: The TTL attribute in ip packet header used in the white-list; DSCP: The DSCP attribute in ip packet header used in the white-list; ip_flags: The ip flags attribute used in the white-list; tcp_flags: The tcp flags attribute used in the white-list; black_list: The black-list information provided to the DOTS server; name: Name of the black-list; Nishizuka, et al. Expires June 30, 2017 [Page 15] Internet-Draft Inter-organization DDoS protection December 2016 source_ip: The source ip address attribute used in the black-list; destination_ip: The destination ip address attribute used in the black-list; source_port: The source port attribute used in the black-list; destination_port: The destination port attribute used in the black-list; protocol: The protocol attribute in ip packet header used in the black-list; length: The length attribute in ip packet header used in the black-list; TTL: The TTL attribute in ip packet header used in the black-list; DSCP: The DSCP attribute in ip packet header used in the black-list; ip_flags: The ip flags attribute used in the black-list; tcp_flags: The tcp flags attribute used in the black-list; registration response body: customer_name: The name of the customer (DOTS client); customer_id: The unique id of the customer (DOTS client); alias_of_mitigation_address: index: index of the protected zone; alias: The alias that the DOTS server assigns to this protected zone; security_profile: The negotiated security profile for the DOTS session; access_token: Authentication token (e.g. pre-shared nonce). "null" represents there is no access token; thresholds_bps: If an attack volume is over this threshold, the controller will reject the protection in order to comply with the negotiated contract; thresholds_pps: If an attack volume is over this threshold, the controller will reject the protection in order to comply with the negotiated contract; duration: If an attack longed over this threshold, the controller will reject the protection in order to comply with the negotiated contract; capable_attack_type: Limit the protectable attack type; registration_time: The time of registration; mitigation_status: The status of current mitigation service of the ISP. Similarly, another HTTP POST method with the message body in JSON format is used for the registration cancelling and registration cancelling response messages as below: Nishizuka, et al. Expires June 30, 2017 [Page 16] Internet-Draft Inter-organization DDoS protection December 2016 METHOD:POST - URL:{scheme}://{host}:{port}/dots/api/ registration_cancelling registration cancelling body: { "customer_id": string; "reasons": string; } registration cancelling response body: { "customer_id": string; "result": string; } Registration cancelling body: customer_id: The unique id of the customer (DOTS client); reasons: The reasons why the DOTS client cancel the registration; registration cancelling response body: customer_id: The unique id of the customer (DOTS client); result: The final result if the DOTS controller accepts the registration cancelling request. 5.1.2. Operations The main operations in the provisioning stage include: o The customers (DOTS client) registers to operator controller with configuration and capability building including protection methods, process capacity, protected zone, security profile, white/black-list, etc; o The DOTS client in operator controller registers to the DOTS server in inter-organization orchestrator (centralized architecture) or other operator controllers (distributed architecture) according to inter-organization DDoS protection requirements; o The DOTS client can send the registration cancelling message to the DOTS server for cancelling its DDoS protection service. The DOTS server indicates the result of processing the POST request using HTTP response codes: o Response code 200 (OK) will be returned in the response if the DOTS server has accepted the mitigation request and will try to mitigate the attack. The HTTP response will include the JSON body of response messages specified above; o If the request is missing one or more mandatory attributes then 400 (Bad Request) will be returned in the response or if the Nishizuka, et al. Expires June 30, 2017 [Page 17] Internet-Draft Inter-organization DDoS protection December 2016 request contains invalid or unknown parameters then 500 (Invalid query) will be returned in the response. The HTTP response will include the JSON body received in the request, with an extra attribute to represent the specific error reason: "error_reason": number; 0: Bad Request; 1: Invalid Query; 2: Server Error; 3: Protected Zone Confliction; 4: Countermeasure Not Support; 5: Security Profile Not Support; 6: Confliction Exists for White-list or Black-list; 255: Others; 5.2. Signaling Stage During the signaling stage, the DOTS signaling channel created with the negotiated security profile in the provisioning stage is used for the DDoS attack mitigation coordination. Once the DOTS client detects the attack to the customer service, a mitigation initiation request message is created and sent to the provisioned DOTS server to call for the DDoS protection service. The DOTS server decides to protect the customer service based on the information from the request message and its configured policy. One operator's DOTS server may ask the co-located DOTS client to resume sending the mitigation initiation request message to other operators' DOTS server to request the inter-organization coordinated mitigation service while it isn't able to deal with the attack by itself. Meanwhile, some other messages are required to be communicated between DOTS client and server for information updates about status, efficacy and scope. When the DOTS server is informed from the mitigator that the attack is over, it should notify the DOTS client to terminate the mitigation service. 5.2.1. Messages In the signaling stage, the DOTS signaling channel is expected to transmit DOTS messages under extremely hostile network conditions such as link saturation. To meet the requirements of resilience and robustness, unidirectional messages MUST be supported within the bidirectional signal channel to allow for unsolicited message delivery, enabling asynchronous notifications between DOTS client and server. So, the listed DOTS messages are required: mitigation initiation request (DOTS client to server), mitigation efficacy updates (DOTS client to server), mitigation status updates (DOTS server to client), mitigation termination (DOTS client to server), Nishizuka, et al. Expires June 30, 2017 [Page 18] Internet-Draft Inter-organization DDoS protection December 2016 mitigation termination status acknowledgement (DOTS client to server) and heartbeat (bidirectional message). Mitigation Request: A HTTP POST method with the message body in JSON is used for the mitigation request message: METHOD:POST - URL:{scheme}://{host}:{port}/dots/api/ mitigation_request mitigation request body: { "version": string; "type": string; "alert_id": string; "sender_id": string; "sender_asn": string; "mitigation_action": number; "lifetime": number; "max_bandwidth": number; "packet_header": { "dst_ip": string; "dst_ports": string; "src_ips": string; "src_ports": string; "protocols": string; "tcp_flags": string; "fragment": string; "pkt_len": string; "icmp_type": string; "icmp_code": string; "DSCP": string; "TTL": string; } "current_throughputs": { "bps": string; "pps": string; } "peak_throughputs": { "bps": string; "pps": string; } "average_throughputs": { "bps": string; "pps": string; } "info": { "attack_types": string; "started": number; Nishizuka, et al. Expires June 30, 2017 [Page 19] Internet-Draft Inter-organization DDoS protection December 2016 "ongoing": number; "severity": number; "direction": number; "health": number; } "vendor": { "name": string; "version": string; "payload": { "offset": number; "content": string; "hash": string; } } } mitigation request body: version: A 3 digit set, similar to linux. (Major.Minor.Revision); type: Only "attack" in scope for v1; alert_id: A SHA-256 hash that is derived from DST_IP and started with some random nonce; sender_id: A SHA-256 hash signature of the sender. This is used to validate who sent it; sender_asn: Asn of the sender. Could be used to link back to sender_id to validate the sender of being a valid sender_id; mitigation_action: The requested mitigation actions by DOTS client. Possible value could be: 1 - mitigation, 2 - blackhole, 3 - flowspec, ...; lifetime: The desired lifetime of the mitigation service from the DOTS client. Upon the expiry of this lifetime, and if the request is not refreshed, the mitigation service is stopped. The service can be refreshed by sending the message with the same "alert_id" again. A lifetime of zero indicates indefinite lifetime for the mitigation service. This is an optional attribute in the request message; max_bandwidth: The max bandwidth DOTS client can undertake. The unit is "G bytes"; packet_header: IP packet header contents used for report. CSV (Comma Separated Values) format is used here when multiple values are possible. Note that no spaces between comma's for CSV format, and the multiple values for every attribute should be in the same order as they are assigned. dst_ip: A single /32 ip under attack; dst_ports: The destination port(s) used for the attack; src_ips: The list of source ips of the attack; src_ports: The source port(s) used for the attack; protocols: The protocol numbers used for the attack. The list of IP protocol numbers are defined and maintained by IANA; tcp_flags: The tcp flags used for the attack. Possible value could be: SYN, FIN, ACK, PSH, RST, URG, NULL; fragment: The fragment flags in ip header for the attack. Possible value could be: DF - Don't fragment, IsF - Is a fragment, FF - First fragment, LF - Last fragment; pkt_len: The packet length used for the attack; icmp_type: The icmp type used for the attack; icmp_code: The icmp code used for the attack; DSCP: The DSCP value used for the attack.; TTL: The TTL value used for the attack; current_throughputs: Current throughput in bps/pps for the above attack flows bps: bytes per second; pps: packets per second; Nishizuka, et al. Expires June 30, 2017 [Page 20] Internet-Draft Inter-organization DDoS protection December 2016 peak_throughputs: The peak throughput in bps/pps for the above attack flows until the time the DOTS request message is sent bps: bytes per second; pps: packets per second; average_throughputs: The calculated average throughput in bps/pps for the above attack flows until the time the DOTS request message is sent bps: bytes per second; pps: packets per second; info: Other general information which is possibly useful attack_types: List of attacks being used together for this attack, on this single DST_IP; started: Unix EPOCH when the attack is started; ongoing: The value representing whether the attack is still ongoning. 1 - yes, 0 - no; severity: The severity level of the attack. 1, 2, 3 - low, medium, high; direction: The direction of the attack. in or out; health: The health condition of the DOTS client. 0-100; vendor: name: Company name; version: version of the DOTS client on the vendors device; payload: The attack packet payload provided to DOTS server for further analysis offset: The payload offset; content: The payload content that is base64 encoded; hash: A SHA-256 hash used as a checksum, of the original payload before being base64 encoded. This is to proof the payload is complete. Not to prove if it has been tampered with; Mitigation Status Exchange: A HTTP POST method with the message body in JSON is used for the mitigation efficacy updates message: METHOD:POST - URL:{scheme}://{host}:{port}/dots/api/ mitigation_efficacy_updates mitigation efficacy updates body: { "version": string; "alert_id": string; "sender_id": string; "sender_asn": string; "attack_status": string; "health": number; } mitigation efficacy updates body: version: A 3 digit set, similar to linux. (Major.Minor.Revision); alert_id: A SHA-256 hash that is derived from DST_IP and started with some random nonce; sender_id: A SHA-256 hash signature of the sender. This is used to validate who sent it; sender_asn: Asn of the sender. Could be used to link back to sender_id to validate the sender of being a valid sender_id; attack_status: The current attack status of the DOTS client. Possible value could be: 0 - in-process, 1 - terminated; health: The health condition of the DOTS client. 0-100; A HTTP POST method with the message body in JSON is used for the mitigation status updates message: Nishizuka, et al. Expires June 30, 2017 [Page 21] Internet-Draft Inter-organization DDoS protection December 2016 METHOD:POST - URL:{scheme}://{host}:{port}/dots/api/ mitigation_status_updates mitigation status updates body: { "version": string; "alert_id": string; "sender_id": string; "sender_asn": string; "status": number; "error_reason": number; "lifetime": number; "source_ports": string; "destination_ports": string; "source_ips": string; "destination_ip": string; "TCP_flags": string; "start_time": number; "end_time": number; "forwarded_total_packets": number; "forwarded_total_bits": number; "forwarded_peak_pps": number; "forwarded_peak_bps": number; "forwarded_average_pps": number; "forwarded_average_bps": number; "malicious_total_packets": number; "malicious_total_bits": number; "malicious_peak_pps": number; "malicious_peak_bps": number; "malicious_average_pps": number; "malicious_average_bps": number; "record_time": string; } mitigation status updates body: version: A 3 digit set, similar to linux. (Major.Minor.Revision); alert_id: A SHA-256 hash that is derived from DST_IP and started with some random nonce; sender_id: A SHA-256 hash signature of the sender. This is used to validate who sent it. The sender is the DOTS server for this message; sender_asn: Asn of the sender. Could be used to link back to sender_id to validate the sender of being a valid sender_id; status: Current mitigation status, such as: pending, ongoing, done, error; error_reason: If status attribute is error, then this attribute expresses its reason, the possible value could be: 0 - Bad Request, 1 - Server Error, 3 - Mitigation Scope Confliction, 4 - Mitigation Action Not Support, 255 - Others; lifetime: The lifetime of mitigation service that DOTS server has assigned to DOTS client. DOTS client MUST follow this value; source_ports: For TCP or UDP or SCTP or DCCP: the source range of ports (e.g., 1024-65535) of the discarded traffic; destination_ports: For TCP or UDP or SCTP or DCCP: the destination range of ports (e.g., 1-443) of the discarded traffic; source_ips: The source IP addresses or prefixes of the discarded traffic; destination_ip: The destination IP addresses or prefixes of the discarded traffic; TCP_flags: TCP flag of the discarded traffic; start_time: The start time for the duration of this mitigation status message; Nishizuka, et al. Expires June 30, 2017 [Page 22] Internet-Draft Inter-organization DDoS protection December 2016 end_time: The end time for the duration of this mitigation status message; forwarded_total_packets: The total number of packets forwarded; forwarded_total_bits: The total bits for all the packets forwarded; forwarded_peak_pps: The peak pps of the traffic forwarded; forwarded_peak_bps: The peak bps of the traffic forwarded; forwarded_average_pps: The average pps of the traffic forwarded; forwarded_average_bps: The average bps of the traffic forwarded; malicious_total_packets: The total number of malicious packets; malicious_total_bits: The total bits of malicious packets; malicious_peak_pps: The peak pps of the malicious traffic; malicious_peak_bps: The peak bps of the malicious traffic; malicious_average_pps: The average pps of the malicious traffic; malicious_average_bps: The average bps of the malicious traffic; record_time: The time the mitigation status updates message is created; Mitigation Termination: A HTTP POST method with the message body in JSON is used for the mitigation termination request message: METHOD:POST - URL:{scheme}://{host}:{port}/dots/api/ mitigation_termination_request mitigation termination request body: { "version": string; "alert_id": string; "sender_id": string; "sender_asn": string; } mitigation termination request body: version: A 3 digit set, similar to linux. (Major.Minor.Revision); alert_id: A SHA-256 hash that is derived from DST_IP and started with some random nonce; sender_id: A SHA-256 hash signature of the sender. This is used to validate who sent it; sender_asn: Asn of the sender. Could be used to link back to sender_id to validate the sender of being a valid sender_id; A HTTP POST method with the message body in JSON is used for the mitigation termination status acknowledgement message: Nishizuka, et al. Expires June 30, 2017 [Page 23] Internet-Draft Inter-organization DDoS protection December 2016 METHOD:POST - URL:{scheme}://{host}:{port}/dots/api/ mitigation_termination_status_acknowledgement mitigation termination status acknowledgement body: { "version": string; "alert_id": string; "sender_id": string; "sender_asn": string; } mitigation termination status acknowledgement body: version: A 3 digit set, similar to linux. (Major.Minor.Revision); alert_id: A SHA-256 hash that is derived from DST_IP and started with some random nonce; sender_id: A SHA-256 hash signature of the sender. This is used to validate who sent it; sender_asn: Asn of the sender. Could be used to link back to sender_id to validate the sender of being a valid sender_id; Heartbeat: A HTTP POST method with the message body in JSON is used for the heartbeat message: METHOD:POST - URL:{scheme}://{host}:{port}/dots/api/heartbeat heartbeat body { "version": string; "sender_id": string; "sender_asn": string; } heartbeat body: version: A 3 digit set, similar to linux. (Major.Minor.Revision); sender_id: A SHA-256 hash signature of the sender. This is used to validate who sent it; sender_asn: Asn of the sender. Could be used to link back to sender_id to validate the sender of being a valid sender_id; 5.2.2. Operations The main operations in the signaling stage include: o The customer (DOTS client) detects malicious attack, requests mitigation service to its operator controller (DOTS server); o DOTS server authenticates and provides its intra- organization mitigation service to the DOTS client; o When the DOTS server are mitigating the attack and finding the attack volume exceeds it capacity, or the attack type is unknown type, or its upstream link is congested, it should request to other DOTS server for inter-organization cooperation; Nishizuka, et al. Expires June 30, 2017 [Page 24] Internet-Draft Inter-organization DDoS protection December 2016 o Working DOTS server report their statistics results by mitigation status updates message to the DOTS client; o The DOTS client can updates its mitigation scope to the DOTS server by resending the mitigation request message. It also can update its mitigation efficacy result to the DOTS server; o When the DOTS server is informed from the mitigator that the attack is over, it should notify the DOTS client by the mitigation status updates message to terminate the mitigation service; o When DOTS client is notified by the DOTS server to terminate its mitigation service, it should send a DOTS termination request message to the DOTS server. The DOTS server stop its mitigation service and notifies it to DOTS client by sending DOTS status updates message. At last, DOTS client sends a DOTS mitigation termination acknowledgement message to finish the whole DOTS session; o The heartbeat message is exchange between the DOTS client and DOTS server to check their respective status. If any side of the channel fails to receive the heartbeat message, then it will trigger an alert or further investigation into why they never reached their destination. 6. Other Considerations 6.1. Billing Data This is not technical nor a part of dots protocol but it has relation to deployment models. If other organization utilized resources of DDoS protection service, it is natural to charge it according to the amount of use. However, how to count the amount of use differs among DDoS protection service providers. For example, some DDoS protection service provider charges users by volume of the attack traffic or dropped packets. On the other hand, some of them use volume of normal traffic. Number of execution can be also used. We can not decide what information should be taken into account for billing purpose in advance, however those information is needed to be exchanged while coordinating DDoS protection. These information could be also used to determine which service would be used when asking for help. Though it is out of the scope of dots, coordinating and optimizing the cooperation in the aspect of business is difficult to solve. Nishizuka, et al. Expires June 30, 2017 [Page 25] Internet-Draft Inter-organization DDoS protection December 2016 7. Security Considerations TBD 8. IANA Considerations No need to describe any request regarding number assignment. 9. 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, . [RFC2784] D. Farinacci., T. Li., S. Hanks., D. Meyer., and P. Traina., "Generic Routing Encapsulation (GRE), March 2000". [I-D.draft-ietf-dots-use-cases] R. Dobbins, Ed., S. Fouant., D. Migault., R. Moskowitz., N. Teague., L. Xia, K. Nishizuka., "Use cases for DDoS Open Threat Signaling, October 2015". [I-D.draft-ietf-dots-requirements] A. Mortensen., R. Moskowitz., and T. Reddy., "DDoS Open Threat Signaling Requirements, draft-ietf-dots- requirements-00, October 2015". [I-D.draft-mortensen-dots-architecture] A. Mortensen., F. Andreasen., T. Reddy., C. Gray., R. Compton., and N. Teague., "Distributed-Denial-of-Service (DDoS) Open Threat Signaling Architecture, March 2016". [I-D.draft-reddy-dots-transport] T. Reddy., D. Wing., P. Patil., M. Geller., M. Boucadair., and R. Moskowitz., "Co-operative DDoS Mitigation, October 2015". Authors' Addresses Kaname Nishizuka NTT Communications GranPark 16F 3-4-1 Shibaura, Minato-ku, Tokyo 108-8118,Japan EMail: kaname@nttv6.jp Nishizuka, et al. Expires June 30, 2017 [Page 26] Internet-Draft Inter-organization DDoS protection December 2016 Liang Xia Huawei Technologies Co., Ltd. 101 Software Avenue, Yuhuatai District Nanjing, Jiangsu 210012, China EMail: frank.xialiang@huawei.com Jinwei Xia Huawei Technologies Co., Ltd. 101 Software Avenue, Yuhuatai District Nanjing, Jiangsu 210012, China EMail: xiajinwei@huawei.com Dacheng Zhang Beijing China EMail: dacheng.zdc@alibaba-inc.com Luyuan Fang Microsoft 15590 NE 31st St Redmond, WA 98052 EMail: lufang@microsoft.com Christopher Gray Comcast, Inc. United States EMail: Christopher_Gray3@cable.comcast.com Rich Compton Charter Communications, Inc. EMail: Rich.Compton@charter.com Nishizuka, et al. Expires June 30, 2017 [Page 27]