Network Working Group N Teague Internet Draft Verisign Inc Intended status: Informational January 14, 2015 Expires: July 2015 Open Threat Signaling using RPC API over HTTPS and IPFIX draft-teague-open-threat-signaling-00 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 in the cloud. 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 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 cloud 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 July 18, 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. Teague. Expires July 18 2015 [Page 1] Internet-Draft draft-teague-open-threat-signaling-00 January 15 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 CPE (Customer Premise Equipment) device, service or cloud 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 recognised 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 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 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. 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 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. Teague. Expires July 18 2015 [Page 2] Internet-Draft draft-teague-open-threat-signaling-00 January 15 The event attributes will appear: - Access Token - Key - Time - Type (category and subtype) - Description - Counter - 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, provider or cloud 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. 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 Teague. Expires July 18 2015 [Page 3] Internet-Draft draft-teague-open-threat-signaling-00 January 15 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. 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 Teague. Expires July 18 2015 [Page 4] Internet-Draft draft-teague-open-threat-signaling-00 January 15 - Packet Sanity - packets that fail basic sanity checks: - UDP packets with invalid UDP length - 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 Teague. Expires July 18 2015 [Page 5] Internet-Draft draft-teague-open-threat-signaling-00 January 15 - 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 - sip - malformed request - sql - injection - 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 that may not yet be part of the standard - custom1 - custom2 - etc. Teague. Expires July 18 2015 [Page 6] Internet-Draft draft-teague-open-threat-signaling-00 January 15 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. 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 | Teague. Expires July 18 2015 [Page 7] Internet-Draft draft-teague-open-threat-signaling-00 January 15 | 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 | | | | 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| Teague. Expires July 18 2015 [Page 8] Internet-Draft draft-teague-open-threat-signaling-00 January 15 | 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 | 0b1011 | | | | port scan | 0b1 | | | | buffer overflow | 0b10 | | | | well known - emerging threats | 0b11 | | | | well known - us-cert | 0b100 | | | | 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}/ocs/api/cloudinfo using a POST method with a request body of {"device_ip":"", "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. Teague. Expires July 18 2015 [Page 9] Internet-Draft draft-teague-open-threat-signaling-00 January 15 METHOD:POST URL:{scheme}://{host}:{port}/ocs/api/cloudinfo Request Body: {"device_ip":"", "load_factor1": "", "load_factor2": "" } Response Body: { "access_token":"", "export_host":"", "whitelist_ips":["",""..], "device_threshold_config": {"load_factor1": "% of max", "load_factor2": "% of max", "load_factor3":"% of max"} "mitigation_info":{"status":"" ,"swing_flag":"", "blacklistaddrs":["",""..]} "custom":"arbitrary data" } Request Body: The device_ip attribute simply details the signaling components source address. The device may also communicate the aliases assigned to local load factors of interest e.g. cpu, memory, state table etc. 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 an provider or cloud 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 device_threshold_config is an extensible object which allows the upstream element to set thresholds of common metrics at which to trigger an SOS=true. The common metrics are described as load_factors and may be device specific, these should be expressed as a % of the maximum capacity. The mitigation_info object is also extensible and will communicate the current status, offramp/restoration status and any relevant black list information. Teague. Expires July 18 2015 [Page 10] Internet-Draft draft-teague-open-threat-signaling-00 January 15 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 portal url in the cloud 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 = Cloud 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/ocs/api/cloudinfo D posts: { "device_ip":"192.0.2.1" } Teague. Expires July 18 2015 [Page 11] Internet-Draft draft-teague-open-threat-signaling-00 January 15 C responds: { "access_token":"abc123", "export_host":"203.0.113.1", "whitelist_ips":["203.0.113.254","203.0.113.253"], "device_threshold_config": {"load_factor1": "85", "load_factor2": "75", "load_factor3": "85"}, "mitigation_info": {"status":"Inactive","swing_flag":"True", "blacklistaddrs":[""]}, "custom":{"portal_url":"https://portal.cloud.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 receiver 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%. 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. Teague. Expires July 18 2015 [Page 12] Internet-Draft draft-teague-open-threat-signaling-00 January 15 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1| SOS | Field Length = n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1| Thresholds | Field Length = n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Teague. Expires July 18 2015 [Page 13] Internet-Draft draft-teague-open-threat-signaling-00 January 15 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 July 18 2015 [Page 14] Internet-Draft draft-teague-open-threat-signaling-00 January 15 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. 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] and [RFC5405] apply to the IPFIX and UDP based channels respectively. Additional security considerations will be added to subsequent drafts. 8. IANA Considerations There are not expected to be requests to the IANA in relation to this memo. 9. Contributors This document represents 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 cloud 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 have 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. Teague. Expires July 18 2015 [Page 15] Internet-Draft draft-teague-open-threat-signaling-00 January 15 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 11. 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 12. Authors' Addresses Nik Teague Verisign Inc. 12061 Bluemont Way Reston, VA 20190 US Phone: +1 703 948 3200 Email: nteague@verisign.com URI: http://www.verisigninc.com