DOTS N Teague Internet-Draft Verisign Intended Status: Informational July 5, 2015 Expires: January 6, 2016 Open Threat Signaling using RPC API over HTTPS and IPFIX draft-teague-open-threat-signaling-01 Abstract This document defines a method by which a device or application may signal information relating to current threat handling to other devices/applications that may reside locally or at the service provider. The initial focus is ddos mitigation; however, the method may be extended to communicate any threat type. This will allow for a vendor or provider agnostic approach to threat mitigation utilising multiple layers of protection as the operator sees fit. The dissemination of threat information will occur utilising JSON RPC API over HTTPS communications between devices/applications and will be augmented by IPFIX and UDP or SCTP for signaling telemetry information relating to attacks and protected object data. An open standards based approach to communication between on-premise DDoS mitigation devices and service provider based DDoS protection services allows for enterprises to have a wider range of options to better secure their environments without the limitations of vendor lock-in. 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 January 6, 2016. Teague Expires January 6, 2016 [Page 1] INTERNET DRAFT draft-teague-open-threat-signaling-01 July 5, 2015 Copyright Notice Copyright (c) 2015 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. Table of Contents 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2 Data Dictionary . . . . . . . . . . . . . . . . . . . . . . . . 3 2.1 Upstream Feedback . . . . . . . . . . . . . . . . . . . . . 6 3 Attack/threat categories and sub elements . . . . . . . . . . . 6 4 Threat Enumeration . . . . . . . . . . . . . . . . . . . . . . . 9 5 JSON RPC API over HTTPS communication . . . . . . . . . . . . . 11 5.1 JSON API example interaction . . . . . . . . . . . . . . . . 13 6 IPFIX export . . . . . . . . . . . . . . . . . . . . . . . . . . 15 6.1 Event Template . . . . . . . . . . . . . . . . . . . . . . . 15 6.2 Protected Object Template . . . . . . . . . . . . . . . . . 16 6.3 Attack and Threat Identification Template . . . . . . . . . 17 6.4 Feedback Template . . . . . . . . . . . . . . . . . . . . . 17 7 Security Considerations . . . . . . . . . . . . . . . . . . . . 18 8 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 18 9 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 18 10 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18 11 References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 11.1 Normative References . . . . . . . . . . . . . . . . . . . 19 12 Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 Teague Expires January 6, 2016 [Page 2] INTERNET DRAFT draft-teague-open-threat-signaling-01 July 5, 2015 1 Introduction There are many devices and applications dealing with threat handling that may be a discrete part of a larger strategy. These elements may be required from time to time to signal to an upstream component or provider that the capabilities of the device are exceeded and that an offramping of attack traffic to a more capable element or infrastructure is desired or required. Signaling the need to off- ramp is not the only necessary feature; however, it is also desirable to communicate the form that the threat takes in order to accelerate the next layer mitigation process. Although many vendors and providers implement their own variation or invest in integrating disparate APIs, we are proposing the adoption of a standard method for elements to signal allowing greater integration among any on-premise device or service provider. In addition to the goal of interoperability, the intent is to present a robust method capable of continued signaling in the event of congested ingress paths to the originator. Stateful transport exchanges between components may leverage recognized JSON API channels in order to pass white & black lists, export collector information, protected object attributes, signature updates, mitigation details etc. These exchanges can occur at regular intervals during times of relative inactivity and could continue during attacks up to the point where a signaling component or path becomes overwhelmed. In parallel, a UDP or SCTP IPFIX channel will export data pertaining to protected objects as well as current and ongoing incidents. The receiver for export will be delivered to the signaling component via the JSON API channel, allowing for the upstream element to set the destination dynamically. The UDP or SCTP export will focus more specifically on communicating the current state of the threat and the component dealing with it. Should the signaling component risk becoming degraded, the telemetry data passed from this node will communicate this risk while also ensuring an upstream device or provider has the required information to take over traffic handling without the need to relearn and re-detect. Should an upstream element take over mitigation of an incident, this element will signal the ongoing status of the threat handling to the originating entity to ensure increased awareness to support effective decision making. 2 Data Dictionary The data dictionary refers to a set of attributes common across implementations. The dictionary is not exhaustive and expansion is encouraged. The object definitions, as presented in this draft, are intended to communicate an event. An event will include a number of attributes which will identify an attack profile, the targeted Teague Expires January 6, 2016 [Page 3] INTERNET DRAFT draft-teague-open-threat-signaling-01 July 5, 2015 resource, any existing mitigation actions being undertaken, sla information and scope. In certain circumstances, such as initial registration and discovery, it may be desirable to export information regarding protected objects currently managed by the signaling component outside the scope of any threat or action. These may be identified as informational when the record is accompanied by an event key of 0. For the sake of initial scoping the attributes are expressed in descriptive terms. Reuse of existing IPFIX field names, where appropriate, is to be encouraged. The event attributes will appear: - Access Token - Key - Time - Type (category and subtype) - Description - Scope - SOS - Thresholds * Access Token - authentication token (e.g. pre-shared nonce) * Key - the signaling component specific event identifier. * Time - the time the event was triggered. The timestamp of the record may be used to determine the resulting duration. * Type - determined from the attack definitions * Description - textual notes * Scope - refers to the status of started, ended or ongoing * SOS - this allows for a signaling component to simply communicate that further filtering by additional infrastructure, or provider is necessary. This negates the need to perform additional analytics on traffic characteristics and load. This field should be ignored where the scope identifies an attack as having ended. The SOS field is expected to communicate whenever the signaling component is overwhelmed but in certain circumstances this may need to be set for any or all events, it should therefore not be exclusively tied to signaling components health. * Thresholds - load_factor1 % of max, load_factor2 % of max The above event attributes will be augmented by additional data relating to the resource being attacked and the current handling. Teague Expires January 6, 2016 [Page 4] INTERNET DRAFT draft-teague-open-threat-signaling-01 July 5, 2015 The protected object attributes will appear: - Access Token - Key - Label - IPv/Prefix * version * address/prefix * protocol * port(s) - SLA/QoS - Mitigation status - B/W threshold - Counters *CurrentPps *CurrentBps *PeakPps *PeakBps *TypicalPps *TypicalBps The Access Token and Key elements correspond to those found in the event notifier. Timestamp may be derived from the export-timestamp in the IPFIX header. * Label - textual label * IPv/Prefix - identifies the protected object under attack including ip version, address, protocol, port * SLA - expressed as the first three bits of the dscp field value. This will map to (lowest to highest) BE, CS1, CS2, CS3, CS4, and CS5. The purpose is for the upstream element or provider to be able to classify and handle attack traffic accordingly. * Mitigation status - simple true or false to denote whether an active mitigation is occurring * B/W threshold - event bandwidth as a % of overall capacity * Rate/frequency - exports counters based upon current, peak and average bps/pps The attack type identifier will be constructed from a category and a sub element. The category will be one of the high level types below with the sub element providing greater granularity into the event. This specific set of identifiers may be further expanded and a mechanism to update the attack dictionary across the JSON API channel or alternately for the elements to negotiate a standard set of definitions or an expanded set should be considered for a future iteration. Teague Expires January 6, 2016 [Page 5] INTERNET DRAFT draft-teague-open-threat-signaling-01 July 5, 2015 2.1 Upstream Feedback In the event that attack traffic is offramped to an upstream element it is desirable that attack status information is relayed back to the originating device. In intra-domain applications this is essential in order for the operator to fully understand the extent of the ongoing mitigation. This may be done in the form of a return data set comprising the event Key and the CurrentPps and CurrentBps of the attack. This may potentially be extended to include additional information such as onramp clean traffic. The feedback attributes will appear: - Access Token - Key - CurrentBps - CurrentPps The Access Token and Key elements correspond to those found in the event notifier. As with other data sets the timestamp may derived from the export-timestamp contained in the IPFIX header. * CurrentBps - the current level of offramped traffic in Bps * CurrentPps - the current level of offramped traffic in Pps 3 Attack/threat categories and sub elements - Bandwidth - b/w exceeds available capacity or threshold - Packet Rate - pps exceeds capacity or threshold - Ipv4 Object - may be one or a combination of the following: - addr - protocol - src port - dscp - length - flags - ttl - martian - Ipv6 Object - may be on or a combination of the following: - addr - protocol/next-header - src port - length - traffic class - hop limit - flow label - martian - Packet Sanity - packets that fail basic sanity checks: - UDP packets with invalid UDP length Teague Expires January 6, 2016 [Page 6] INTERNET DRAFT draft-teague-open-threat-signaling-01 July 5, 2015 - TCP packets with corrupt header - UDP/TCP with src/dst port 0 - invalid version - invalid option - runt/giant/ping of death - land - fragments - TCP - attacks against TCP: - syn abuse - ack abuse - fin abuse - rst abuse - psh abuse - urg abuse - window abuse - invalid TCP flags (null,xmas) - fragment abuse - invalid option - sockstress - UDP - attacks against UDP: - flood abuse - fragment abuse - 0 payload - ICMP - attacks against icmp: - flood - Application - higher layer attacks: - hash collision - http - get flood - post flood - random/invalid url - slowloris - slow read - r-u-dead-yet (rudy) - url regex - malformed request - xss - https - ssl session exhaustion - dns - request spoofing - query flood - nxdomain flood - any flood - query regex - malformed query - response flood - dnssec abuse Teague Expires January 6, 2016 [Page 7] INTERNET DRAFT draft-teague-open-threat-signaling-01 July 5, 2015 - sip - malformed request - sql - injection - smtp - backscatter - abuse - Amplification - amplified/amplifier attacks - dns - ntp - snmp - netbios - ssdp - chargen - qotd - bittorrent - kad - smurf - quake - steam - Intrusion - potential intrusion or nuisance - port scan - buffer overflow - well know threat identifiers (CERT, emerging threats etc.) - Custom - used for arbitrary definitions - custom1 - custom2 - etc. An event will be triggered based on the attack profile. E.g. application:http-slowloris and icmp:flood would be considered 2x separate events. The ability to roll individual events into a parent event id is also permissible. In these instances the ability to identify a parent event would be necessary. A device may use a threat data field in the export to communicate a sample payload for scrutiny by an upstream system or provider and on which a signature based filter may be based. Teague Expires January 6, 2016 [Page 8] INTERNET DRAFT draft-teague-open-threat-signaling-01 July 5, 2015 4 Threat Enumeration Threats will be identified using a 16 bit format split into 2x octets, the 1st octet will identify the category where there 2nd octet will relate to a specific sub type. +---------------+----------+--------------------------------+--------+ | Category | ID | SubType | ID | +---------------+----------+--------------------------------+--------+ | Bandwidth | 1 | | | | Packet Rate | 10 | | | | IPv4 Object | 11 | | | | | | addr | 0b1 | | | | protocol | 0b10 | | | | port | 0b11 | | | | src port | 0b100 | | | | dscp | 0b101 | | | | length | 0b110 | | | | flags | 0b111 | | | | ttl | 0b1000 | | | | martian | 0b1001 | | IPv6 Object | 100 | | | | | | addr | 0b1 | | | | protocol/nh | 0b11 | | | | src port | 0b100 | | | | length | 0b101 | | | | traffic class | 0b110 | | | | hop limit | 0b111 | | | | flow label | 0b1000 | | | | martian | 0b1001 | | Packet Sanity | 101 | | | | | | UDP length | 0b1 | | | | TCP corrupt header | 0b10 | | | | UDP/TCP src port 0 | 0b11 | | | | invalid version | 0b100 | | | | invalid option | 0b101 | | | | runt/giant/ping of death | 0b110 | | | | land | 0b111 | | | | fragments | 0b1000 | | TCP | 110 | | | | | | syn abuse | 0b1 | | | | ack abuse | 0b10 | | | | fin abuse | 0b11 | | | | rst abuse | 0b100 | | | | psh abuse | 0b101 | | | | urg abuse | 0b111 | | | | window abuse | 0b1000 | | | | invalid TCP flags | 0b1001 | | | | fragment abuse | 0b1010 | Teague Expires January 6, 2016 [Page 9] INTERNET DRAFT draft-teague-open-threat-signaling-01 July 5, 2015 | | | invalid option | 0b1011 | | | | sockstress | 0b1100 | | UDP | 111 | | | | | | flood abuse | 0b1 | | | | fragment abuse | 0b10 | | | | 0 payload | 0b11 | | ICMP | 1000 | | | | | | flood | 0b1 | | Application | 1001 | | | | | | hash collision | 0b1 | | | | http - get flood | 0b10 | | | | http - post flood | 0b11 | | | | http - random/invalid url | 0b100 | | | | http - slowloris | 0b101 | | | | http - slow read | 0b110 | | | | http - r-u-dead-yet (rudy) | 0b111 | | | | http - malformed request | 0b1000 | | | | http - xss | 0b1001 | | | | https - ssl session exhaustion | 0b1010 | | | | dns - request spoofing | 0b1011 | | | | dns - query flood | 0b1100 | | | | dns - nxdomain flood | 0b1101 | | | | dns - query regex | 0b1110 | | | | dns - malformed query | 0b1111 | | | | dns - response flood | 0b10000| | | | dns - dnssec abuse | 0b10001| | | | sip - malformed request | 0b10010| | | | sql - injection | 0b10011| | | | smtp - backscatter | 0b10100| | | | smtp - abuse | 0b10101| | Amplification | 1010 | | | | | | dns | 0b1 | | | | ntp | 0b10 | | | | snmp | 0b11 | | | | netbios | 0b100 | | | | ssdp | 0b101 | | | | chargen | 0b110 | | | | qotd | 0b111 | | | | bittorrent | 0b1000 | | | | kad | 0b1001 | | | | smurf | 0b1010 | | | | quake | 0b1011 | | | | steam | 0b1100 | | Intrusion | 1011 | | | | | | port scan | 0b1 | | | | buffer overflow | 0b10 | | | | well known - emerging threats | 0b11 | | | | well known - us-cert | 0b100 | Teague Expires January 6, 2016 [Page 10] INTERNET DRAFT draft-teague-open-threat-signaling-01 July 5, 2015 | | | well known - idefence | 0b101 | | ... | ... | ... | ... | | Custom | 11111111 | | | | | | custom1 | 0b1 | | | | custom2 | 0b10 | | | | custom3 | 0b11 | | | | custom4 | 0b100 | | | | custom5 | 0b101 | | | | custom6 | 0b110 | | | | custom7 | 0b111 | | | | custom8 | 0b1000 | | | | ... | ... | +---------------+----------+--------------------------------+--------+ 5 JSON RPC API over HTTPS communication The JSON API channel is expected to be opened at regular intervals for the exchange of command and control data. The signaling component will authenticate using a standard user/role:password or api-key and request URL:{scheme}://{host}:{port}/dots/api/info using a POST method with a request body of: {"device_ip":"", "device_load_config":{ "load_factor1":[""], "load_factor2":[""]...} The upstream element will use the access token plus ip address to verify the originators credentials as valid signaling component. The upstream element may then pass to the requesting component the IPFIX ID token, the IPFIX destination address, white lists and mitigation information. METHOD:POST - URL:{scheme}://{host}:{port}/dots/api/info Request Body: { "device_ip": "", "device_load_config": { "load_factor1": [ "", "% of max" ], "load_factor2": [ "", "% of max" ] } } Teague Expires January 6, 2016 [Page 11] INTERNET DRAFT draft-teague-open-threat-signaling-01 July 5, 2015 Response Body: { "access_token":"", "export_host":"", "whitelist_ips":[ "", "", .. ], "mitigation":{ "status":"", swing_flag":"", "blacklistaddrs":[ "", "", .. ] }, "custom":"arbitrary data" } Request Body: The device_ip attribute simply details the signaling components source address. The device_load_config is an extensible object that allows the device to communicate aliases and thresholds associated to load factors of interest e.g. cpu, memory, state table etc. The threshold may be used to communicate a level at which the element may be expected to trigger an SOS=true event if exceeded. Response Body: The access_token will be used for basic authentication of IPFIX exports to the upstream collector. The export_host will communicate the ipv4/ipv6 addr of the upstream IPFIX collector. The whitelist_ips attribute will allow for a provider instance to white list certain ip addresses from which all traffic should be accepted to ensure that any proxied traffic where the original address is obscured is not mistaken for a new attack signature. The mitigation object is also extensible and will communicate the current status, offramp/restoration status and any relevant black Teague Expires January 6, 2016 [Page 12] INTERNET DRAFT draft-teague-open-threat-signaling-01 July 5, 2015 list information. The status attribute of the mitigation_info object as 3x states: * Inactive - no IPFIX messages have been received in the last health- refresh-timeout period. * Monitoring - IPFIX messages are being received * Mitigating - the upstream is actively mitigating a threat The swing attribute of the mitigation_info object is set either true or false: * True - the attack has abated or reduced (if volumetric) to a level deemed within the capacity of the original signaling component. * False - the attack mitigation should continue to be handled by the upstream element. The blacklistaddrs attribute is a simple set of ipv4 or ipv6 addresses and allows an upstream element to communicate known bad actors or compromised hosts to the signaling component. The custom field may be used for the upstream element to communicate an arbitrary object. This could include a service provider portal url or some other yet to be standardised data. 5.1 JSON API example interaction +-+-+ +-+-+ | D |---------HTTPS-------| C | +-+-+ +-+-+ | | | +-+-+ +-----------IPFIX-------| I | +-+-+ D = DDoS mitigation device 192.0.2.1 C = Service provider 198.51.100.1 I = IPFIX receiver 203.0.113.1 D initiates an https connection to C: URL: https://user:password@198.51.100.1:443/dots/api/info Teague Expires January 6, 2016 [Page 13] INTERNET DRAFT draft-teague-open-threat-signaling-01 July 5, 2015 D posts: { "device_ip":"192.0.2.1", "device_load_config": { "load_factor1": [ "cpu", "85" ], "load_factor2": [ "mem", "85" ], "load_factor3": [ "bandwidth", "75" ] } } C responds: { "access_token":"abc123", "export_host":"203.0.113.1", "whitelist_ips":[ "203.0.113.254", "203.0.113.253" ], "mitigation": { "status":"Inactive", "swing_flag":"True", "blacklistaddrs":[] }, "custom":{"portal_url":"https://portal.ddossp.net/Mitige?=192.0.2.1"} } Upon receipt of the response body the device 192.0.2.1 would now send event exports to the IPFIX collecttor at 203.0.113.1 and would authenticate using the ID "abc123". Periodically a new token may be exchanged or an alternate IPFIX destination (export_host) set. In these instances the signaling component should start using the new credentials or destination immediately. The component will whitelist the ip addresses of 203.0.113.254 and 203.0.113.253. The SOS flag will be set to true should the component cpu=85% or mem=85% or bandwidth=75%. Teague Expires January 6, 2016 [Page 14] INTERNET DRAFT draft-teague-open-threat-signaling-01 July 5, 2015 6 IPFIX export IPFIX was selected for this channel due to its push nature, extensible templates and its existing availability on ddos and security platforms. Leveraging an existing protocol will result in minimal retooling and hopefully lower any barrier to adoption. An attack will trigger the creation of an incident record on the component which in turn will trigger IPFIX export to an upstream device or provider with details of the attack parameters. Due to the unreliable nature of UDP event data sets will repeat at regular intervals for the duration of the attack. An attack may generate different data exports which will communicate various facets of the threat, the target and the overall incident. The event data set will define the base key and this will be used to link other records such as protected objects and threat profile data sets. Corresponding data sets referencing the same key will be considered part of the same event when combined with the component id. An IPFIX event data export may be used as a heartbeat between elements. It is recommended that the signaling component periodically send heartbeats upstream to verify its status during periods of relative inactivity, failure by the upstream to receive these heartbeats may then trigger an alert or further investigation into why they never reached their destination. 6.1 Event Template The template for events will contain 8x fields as detailed: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Set ID = 2 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Template ID n | Field Count = 8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1| Access Token | Field Length = n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1| Key | Field Length = n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1| Time | Field Length = n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1| Type | Field Length = n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1| Description | Field Length = n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1| Scope | Field Length = n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Teague Expires January 6, 2016 [Page 15] INTERNET DRAFT draft-teague-open-threat-signaling-01 July 5, 2015 |1| SOS | Field Length = n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1| Thresholds | Field Length = n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6.2 Protected Object Template The template for protected object will contain 16x fields as detailed: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Set ID = 2 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Template ID n | Field Count = 16 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1| Access Token | Field Length = n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1| Key | Field Length = n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1| Label | Field Length = n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1| IP version | Field Length = n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1| Address/Prefix | Field Length = n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1| Protocol | Field Length = n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1| Port | Field Length = n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1| SLA Code Point | Field Length = n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1| Mitigation Status | Field Length = n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1| B/W Threshold | Field Length = n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1| Current Pps | Field Length = n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1| Current Bps | Field Length = n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1| Peak Pps | Field Length = n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1| Peak Bps | Field Length = n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1| Typical Pps | Field Length = n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1| Typical Bps | Field Length = n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Teague Expires January 6, 2016 [Page 16] INTERNET DRAFT draft-teague-open-threat-signaling-01 July 5, 2015 6.3 Attack and Threat Identification Template The template for attack and threat identification will contain 4x fields as detailed: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Set ID = 2 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Template ID n | Field Count = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1| Access Token | Field Length = n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1| Key | Field Length = n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1| Threat Identifier | Field Length = n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1| Threat Data | Field Length = n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Note - where no threat data is required to aid in mitigation (ie the identifier is enough) the Threat Data field may be set to null. 6.4 Feedback Template The template for feedback will contain 4x fields as detailed: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Set ID = 2 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Template ID n | Field Count = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1| Access Token | Field Length = n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1| Key | Field Length = n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1| CurrentBps | Field Length = n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1| CurrentPps | Field Length = n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Teague Expires January 6, 2016 [Page 17] INTERNET DRAFT draft-teague-open-threat-signaling-01 July 5, 2015 7 Security Considerations The protocol described here serves as a security mitigation tool. Potential vulnerabilities of this system are addressed by the use of encrypted channels for communication between the elements and the use of low overhead control signals in case there is denial of service or congestion affecting the paths between the elements. The security considerations of [RFC7011], [RFC5405] and [RFC4960] apply to the IPFIX, UDP and SCTP based channels respectively. Additional security considerations will be added to subsequent drafts. 8 IANA Considerations There may be requests to IANA in order to update the registry of IPFIX entities. 9 Contributors The initial version of this document represented a collaborative effort by engineers at Verisign and Juniper to create a candidate for an open standards effort supporting communication between on-premise DDoS mitigation devices and provider based DDoS mitigation services. A standards based approach allows businesses to have a wider range of options to better secure their complex environments without the limitation of vendor lock-in. The companies published a draft specification through the Internet Engineering Task Force (IETF) to encourage community participation and further development of these proposals toward becoming an open standard. 10 Acknowledgements The following people are acknowledged for their technical contributions in the development of this document: Aziz Mohaisen, Jon Shallow, Suresh Bhogavilli, Jeshmi Raman, Malathy Poruran, Roman Danyliw, Andrew Mortensen, Rich Groves, Scott Barvick, Franck Martin, Brian Trammel. Teague Expires January 6, 2016 [Page 18] INTERNET DRAFT draft-teague-open-threat-signaling-01 July 5, 2015 11 References 11.1 Normative References [RFC7011] Claise, B., Trammell, B., and P. Aitken, "Specification of the IP Flow Information Export (IPFIX) Protocol for the Echange of Flow Information" https://tools.ietf.org/html/rfc7011 September 2013 [RFC5405] Eggert, L. and G. Fairhurst, "Unicast UDP usage Guidelines for Application Designers" https://tools.ietf.org/html/rfc5405 November 2008 [RFC4960] Stewart, R, Ed. "Stream Control Transmission Protocol" https://tools.ietf.org/html/rfc4960 September 2007 12 Changelog Changes between 00 and 01: * Cleaned up language to remove 'cloud' and 'cpe' terminology for clarity * Added feedback element and described same * Called out SCTP as possible transport for IPFIX * Adjusted thresholds to be informed by the originating device * Tidied JSON and other representations * Added smtp ddos to the data dictionary Authors' Addresses Nik Teague Verisign Inc. 12061 Bluemont Way Reston, VA 20190 US EMail: nteague@verisign.com Teague Expires January 6, 2016 [Page 19]