idnits 2.17.1 draft-teague-open-threat-signaling-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 5, 2015) is 3217 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 5405 (Obsoleted by RFC 8085) ** Obsolete normative reference: RFC 4960 (Obsoleted by RFC 9260) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DOTS N Teague 3 Internet-Draft Verisign 4 Intended Status: Informational July 5, 2015 5 Expires: January 6, 2016 7 Open Threat Signaling using RPC API over HTTPS and IPFIX 8 draft-teague-open-threat-signaling-01 10 Abstract 12 This document defines a method by which a device or application may 13 signal information relating to current threat handling to other 14 devices/applications that may reside locally or at the service 15 provider. The initial focus is ddos mitigation; however, the method 16 may be extended to communicate any threat type. This will allow for 17 a vendor or provider agnostic approach to threat mitigation utilising 18 multiple layers of protection as the operator sees fit. 20 The dissemination of threat information will occur utilising JSON RPC 21 API over HTTPS communications between devices/applications and will 22 be augmented by IPFIX and UDP or SCTP for signaling telemetry 23 information relating to attacks and protected object data. 25 An open standards based approach to communication between on-premise 26 DDoS mitigation devices and service provider based DDoS protection 27 services allows for enterprises to have a wider range of options to 28 better secure their environments without the limitations of vendor 29 lock-in. 31 Status of this Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. Internet-Drafts are working 35 documents of the Internet Engineering Task Force (IETF). Note that 36 other groups may also distribute working documents as Internet- 37 Drafts. The list of current Internet-Drafts is at 38 http://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on January 6, 2016. 47 Copyright Notice 49 Copyright (c) 2015 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. 59 Table of Contents 61 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2 Data Dictionary . . . . . . . . . . . . . . . . . . . . . . . . 3 63 2.1 Upstream Feedback . . . . . . . . . . . . . . . . . . . . . 6 64 3 Attack/threat categories and sub elements . . . . . . . . . . . 6 65 4 Threat Enumeration . . . . . . . . . . . . . . . . . . . . . . . 9 66 5 JSON RPC API over HTTPS communication . . . . . . . . . . . . . 11 67 5.1 JSON API example interaction . . . . . . . . . . . . . . . . 13 68 6 IPFIX export . . . . . . . . . . . . . . . . . . . . . . . . . . 15 69 6.1 Event Template . . . . . . . . . . . . . . . . . . . . . . . 15 70 6.2 Protected Object Template . . . . . . . . . . . . . . . . . 16 71 6.3 Attack and Threat Identification Template . . . . . . . . . 17 72 6.4 Feedback Template . . . . . . . . . . . . . . . . . . . . . 17 73 7 Security Considerations . . . . . . . . . . . . . . . . . . . . 18 74 8 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 18 75 9 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 18 76 10 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18 77 11 References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 78 11.1 Normative References . . . . . . . . . . . . . . . . . . . 19 79 12 Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 82 1 Introduction 84 There are many devices and applications dealing with threat handling 85 that may be a discrete part of a larger strategy. These elements may 86 be required from time to time to signal to an upstream component or 87 provider that the capabilities of the device are exceeded and that an 88 offramping of attack traffic to a more capable element or 89 infrastructure is desired or required. Signaling the need to off- 90 ramp is not the only necessary feature; however, it is also desirable 91 to communicate the form that the threat takes in order to accelerate 92 the next layer mitigation process. 94 Although many vendors and providers implement their own variation or 95 invest in integrating disparate APIs, we are proposing the adoption 96 of a standard method for elements to signal allowing greater 97 integration among any on-premise device or service provider. In 98 addition to the goal of interoperability, the intent is to present a 99 robust method capable of continued signaling in the event of 100 congested ingress paths to the originator. Stateful transport 101 exchanges between components may leverage recognized JSON API 102 channels in order to pass white & black lists, export collector 103 information, protected object attributes, signature updates, 104 mitigation details etc. These exchanges can occur at regular 105 intervals during times of relative inactivity and could continue 106 during attacks up to the point where a signaling component or path 107 becomes overwhelmed. In parallel, a UDP or SCTP IPFIX channel will 108 export data pertaining to protected objects as well as current and 109 ongoing incidents. The receiver for export will be delivered to the 110 signaling component via the JSON API channel, allowing for the 111 upstream element to set the destination dynamically. The UDP or SCTP 112 export will focus more specifically on communicating the current 113 state of the threat and the component dealing with it. Should the 114 signaling component risk becoming degraded, the telemetry data passed 115 from this node will communicate this risk while also ensuring an 116 upstream device or provider has the required information to take over 117 traffic handling without the need to relearn and re-detect. Should 118 an upstream element take over mitigation of an incident, this element 119 will signal the ongoing status of the threat handling to the 120 originating entity to ensure increased awareness to support effective 121 decision making. 123 2 Data Dictionary 125 The data dictionary refers to a set of attributes common across 126 implementations. The dictionary is not exhaustive and expansion is 127 encouraged. The object definitions, as presented in this draft, are 128 intended to communicate an event. An event will include a number of 129 attributes which will identify an attack profile, the targeted 130 resource, any existing mitigation actions being undertaken, sla 131 information and scope. In certain circumstances, such as initial 132 registration and discovery, it may be desirable to export information 133 regarding protected objects currently managed by the signaling 134 component outside the scope of any threat or action. These may be 135 identified as informational when the record is accompanied by an 136 event key of 0. For the sake of initial scoping the attributes are 137 expressed in descriptive terms. Reuse of existing IPFIX field names, 138 where appropriate, is to be encouraged. 140 The event attributes will appear: 142 - Access Token 143 - Key 144 - Time 145 - Type (category and subtype) 146 - Description 147 - Scope 148 - SOS 149 - Thresholds 151 * Access Token - authentication token (e.g. pre-shared nonce) 152 * Key - the signaling component specific event identifier. 153 * Time - the time the event was triggered. The timestamp of the 154 record may be used to determine the resulting duration. 155 * Type - determined from the attack definitions 156 * Description - textual notes 157 * Scope - refers to the status of started, ended or ongoing 158 * SOS - this allows for a signaling component to simply communicate 159 that further filtering by additional infrastructure, or provider is 160 necessary. This negates the need to perform additional analytics on 161 traffic characteristics and load. This field should be ignored where 162 the scope identifies an attack as having ended. The SOS field is 163 expected to communicate whenever the signaling component is 164 overwhelmed but in certain circumstances this may need to be set for 165 any or all events, it should therefore not be exclusively tied to 166 signaling components health. 167 * Thresholds - load_factor1 % of max, load_factor2 % of max 169 The above event attributes will be augmented by additional data 170 relating to the resource being attacked and the current handling. 172 The protected object attributes will appear: 174 - Access Token 175 - Key 176 - Label 177 - IPv/Prefix 178 * version 179 * address/prefix 180 * protocol 181 * port(s) 182 - SLA/QoS 183 - Mitigation status 184 - B/W threshold 185 - Counters 186 *CurrentPps 187 *CurrentBps 188 *PeakPps 189 *PeakBps 190 *TypicalPps 191 *TypicalBps 193 The Access Token and Key elements correspond to those found in the 194 event notifier. Timestamp may be derived from the export-timestamp 195 in the IPFIX header. 197 * Label - textual label 198 * IPv/Prefix - identifies the protected object under attack including 199 ip version, address, protocol, port 200 * SLA - expressed as the first three bits of the dscp field value. 201 This will map to (lowest to highest) BE, CS1, CS2, CS3, CS4, and CS5. 202 The purpose is for the upstream element or provider to be able to 203 classify and handle attack traffic accordingly. 204 * Mitigation status - simple true or false to denote whether an 205 active mitigation is occurring 206 * B/W threshold - event bandwidth as a % of overall capacity 207 * Rate/frequency - exports counters based upon current, peak and 208 average bps/pps 210 The attack type identifier will be constructed from a category and a 211 sub element. The category will be one of the high level types below 212 with the sub element providing greater granularity into the event. 213 This specific set of identifiers may be further expanded and a 214 mechanism to update the attack dictionary across the JSON API channel 215 or alternately for the elements to negotiate a standard set of 216 definitions or an expanded set should be considered for a future 217 iteration. 219 2.1 Upstream Feedback 221 In the event that attack traffic is offramped to an upstream element 222 it is desirable that attack status information is relayed back to the 223 originating device. In intra-domain applications this is essential 224 in order for the operator to fully understand the extent of the 225 ongoing mitigation. This may be done in the form of a return data 226 set comprising the event Key and the CurrentPps and CurrentBps of the 227 attack. This may potentially be extended to include additional 228 information such as onramp clean traffic. 230 The feedback attributes will appear: 232 - Access Token 233 - Key 234 - CurrentBps 235 - CurrentPps 237 The Access Token and Key elements correspond to those found in the 238 event notifier. As with other data sets the timestamp may derived 239 from the export-timestamp contained in the IPFIX header. 241 * CurrentBps - the current level of offramped traffic in Bps 242 * CurrentPps - the current level of offramped traffic in Pps 244 3 Attack/threat categories and sub elements 245 - Bandwidth - b/w exceeds available capacity or threshold 246 - Packet Rate - pps exceeds capacity or threshold 247 - Ipv4 Object - may be one or a combination of the following: 248 - addr 249 - protocol 250 - src port 251 - dscp 252 - length 253 - flags 254 - ttl 255 - martian 256 - Ipv6 Object - may be on or a combination of the following: 257 - addr 258 - protocol/next-header 259 - src port 260 - length 261 - traffic class 262 - hop limit 263 - flow label 264 - martian 265 - Packet Sanity - packets that fail basic sanity checks: 266 - UDP packets with invalid UDP length 267 - TCP packets with corrupt header 268 - UDP/TCP with src/dst port 0 269 - invalid version 270 - invalid option 271 - runt/giant/ping of death 272 - land 273 - fragments 274 - TCP - attacks against TCP: 275 - syn abuse 276 - ack abuse 277 - fin abuse 278 - rst abuse 279 - psh abuse 280 - urg abuse 281 - window abuse 282 - invalid TCP flags (null,xmas) 283 - fragment abuse 284 - invalid option 285 - sockstress 286 - UDP - attacks against UDP: 287 - flood abuse 288 - fragment abuse 289 - 0 payload 290 - ICMP - attacks against icmp: 291 - flood 292 - Application - higher layer attacks: 293 - hash collision 294 - http 295 - get flood 296 - post flood 297 - random/invalid url 298 - slowloris 299 - slow read 300 - r-u-dead-yet (rudy) 301 - url regex 302 - malformed request 303 - xss 304 - https 305 - ssl session exhaustion 306 - dns 307 - request spoofing 308 - query flood 309 - nxdomain flood 310 - any flood 311 - query regex 312 - malformed query 313 - response flood 314 - dnssec abuse 316 - sip 317 - malformed request 318 - sql 319 - injection 320 - smtp 321 - backscatter 322 - abuse 323 - Amplification - amplified/amplifier attacks 324 - dns 325 - ntp 326 - snmp 327 - netbios 328 - ssdp 329 - chargen 330 - qotd 331 - bittorrent 332 - kad 333 - smurf 334 - quake 335 - steam 336 - Intrusion - potential intrusion or nuisance 337 - port scan 338 - buffer overflow 339 - well know threat identifiers (CERT, emerging threats etc.) 340 - Custom - used for arbitrary definitions 341 - custom1 342 - custom2 343 - etc. 345 An event will be triggered based on the attack profile. E.g. 346 application:http-slowloris and icmp:flood would be considered 2x 347 separate events. The ability to roll individual events into a parent 348 event id is also permissible. In these instances the ability to 349 identify a parent event would be necessary. A device may use a 350 threat data field in the export to communicate a sample payload for 351 scrutiny by an upstream system or provider and on which a signature 352 based filter may be based. 354 4 Threat Enumeration 356 Threats will be identified using a 16 bit format split into 2x 357 octets, the 1st octet will identify the category where there 2nd 358 octet will relate to a specific sub type. 359 +---------------+----------+--------------------------------+--------+ 360 | Category | ID | SubType | ID | 361 +---------------+----------+--------------------------------+--------+ 362 | Bandwidth | 1 | | | 363 | Packet Rate | 10 | | | 364 | IPv4 Object | 11 | | | 365 | | | addr | 0b1 | 366 | | | protocol | 0b10 | 367 | | | port | 0b11 | 368 | | | src port | 0b100 | 369 | | | dscp | 0b101 | 370 | | | length | 0b110 | 371 | | | flags | 0b111 | 372 | | | ttl | 0b1000 | 373 | | | martian | 0b1001 | 374 | IPv6 Object | 100 | | | 375 | | | addr | 0b1 | 376 | | | protocol/nh | 0b11 | 377 | | | src port | 0b100 | 378 | | | length | 0b101 | 379 | | | traffic class | 0b110 | 380 | | | hop limit | 0b111 | 381 | | | flow label | 0b1000 | 382 | | | martian | 0b1001 | 383 | Packet Sanity | 101 | | | 384 | | | UDP length | 0b1 | 385 | | | TCP corrupt header | 0b10 | 386 | | | UDP/TCP src port 0 | 0b11 | 387 | | | invalid version | 0b100 | 388 | | | invalid option | 0b101 | 389 | | | runt/giant/ping of death | 0b110 | 390 | | | land | 0b111 | 391 | | | fragments | 0b1000 | 392 | TCP | 110 | | | 393 | | | syn abuse | 0b1 | 394 | | | ack abuse | 0b10 | 395 | | | fin abuse | 0b11 | 396 | | | rst abuse | 0b100 | 397 | | | psh abuse | 0b101 | 398 | | | urg abuse | 0b111 | 399 | | | window abuse | 0b1000 | 400 | | | invalid TCP flags | 0b1001 | 401 | | | fragment abuse | 0b1010 | 402 | | | invalid option | 0b1011 | 403 | | | sockstress | 0b1100 | 404 | UDP | 111 | | | 405 | | | flood abuse | 0b1 | 406 | | | fragment abuse | 0b10 | 407 | | | 0 payload | 0b11 | 408 | ICMP | 1000 | | | 409 | | | flood | 0b1 | 410 | Application | 1001 | | | 411 | | | hash collision | 0b1 | 412 | | | http - get flood | 0b10 | 413 | | | http - post flood | 0b11 | 414 | | | http - random/invalid url | 0b100 | 415 | | | http - slowloris | 0b101 | 416 | | | http - slow read | 0b110 | 417 | | | http - r-u-dead-yet (rudy) | 0b111 | 418 | | | http - malformed request | 0b1000 | 419 | | | http - xss | 0b1001 | 420 | | | https - ssl session exhaustion | 0b1010 | 421 | | | dns - request spoofing | 0b1011 | 422 | | | dns - query flood | 0b1100 | 423 | | | dns - nxdomain flood | 0b1101 | 424 | | | dns - query regex | 0b1110 | 425 | | | dns - malformed query | 0b1111 | 426 | | | dns - response flood | 0b10000| 427 | | | dns - dnssec abuse | 0b10001| 428 | | | sip - malformed request | 0b10010| 429 | | | sql - injection | 0b10011| 430 | | | smtp - backscatter | 0b10100| 431 | | | smtp - abuse | 0b10101| 432 | Amplification | 1010 | | | 433 | | | dns | 0b1 | 434 | | | ntp | 0b10 | 435 | | | snmp | 0b11 | 436 | | | netbios | 0b100 | 437 | | | ssdp | 0b101 | 438 | | | chargen | 0b110 | 439 | | | qotd | 0b111 | 440 | | | bittorrent | 0b1000 | 441 | | | kad | 0b1001 | 442 | | | smurf | 0b1010 | 443 | | | quake | 0b1011 | 444 | | | steam | 0b1100 | 445 | Intrusion | 1011 | | | 446 | | | port scan | 0b1 | 447 | | | buffer overflow | 0b10 | 448 | | | well known - emerging threats | 0b11 | 449 | | | well known - us-cert | 0b100 | 450 | | | well known - idefence | 0b101 | 451 | ... | ... | ... | ... | 452 | Custom | 11111111 | | | 453 | | | custom1 | 0b1 | 454 | | | custom2 | 0b10 | 455 | | | custom3 | 0b11 | 456 | | | custom4 | 0b100 | 457 | | | custom5 | 0b101 | 458 | | | custom6 | 0b110 | 459 | | | custom7 | 0b111 | 460 | | | custom8 | 0b1000 | 461 | | | ... | ... | 462 +---------------+----------+--------------------------------+--------+ 463 5 JSON RPC API over HTTPS communication 465 The JSON API channel is expected to be opened at regular intervals 466 for the exchange of command and control data. The signaling 467 component will authenticate using a standard user/role:password or 468 api-key and request URL:{scheme}://{host}:{port}/dots/api/info using 469 a POST method with a request body of: 471 {"device_ip":"", "device_load_config":{ 472 "load_factor1":[""], "load_factor2":[""]...} 474 The upstream element will use the access token plus ip address to 475 verify the originators credentials as valid signaling component. The 476 upstream element may then pass to the requesting component the IPFIX 477 ID token, the IPFIX destination address, white lists and mitigation 478 information. 480 METHOD:POST - URL:{scheme}://{host}:{port}/dots/api/info 482 Request Body: 484 { 485 "device_ip": "", 486 "device_load_config": { 487 "load_factor1": [ 488 "", 489 "% of max" 490 ], 491 "load_factor2": [ 492 "", 493 "% of max" 494 ] 495 } 496 } 497 Response Body: 499 { 500 "access_token":"", 501 "export_host":"", 502 "whitelist_ips":[ 503 "", 504 "", 505 .. 506 ], 507 "mitigation":{ 508 "status":"", 509 swing_flag":"", 510 "blacklistaddrs":[ 511 "", 512 "", 513 .. 514 ] 515 }, 516 "custom":"arbitrary data" 517 } 519 Request Body: 521 The device_ip attribute simply details the signaling components 522 source address. 524 The device_load_config is an extensible object that allows the device 525 to communicate aliases and thresholds associated to load factors of 526 interest e.g. cpu, memory, state table etc. The threshold may be 527 used to communicate a level at which the element may be expected to 528 trigger an SOS=true event if exceeded. 530 Response Body: 532 The access_token will be used for basic authentication of IPFIX 533 exports to the upstream collector. 535 The export_host will communicate the ipv4/ipv6 addr of the upstream 536 IPFIX collector. 538 The whitelist_ips attribute will allow for a provider instance to 539 white list certain ip addresses from which all traffic should be 540 accepted to ensure that any proxied traffic where the original 541 address is obscured is not mistaken for a new attack signature. 543 The mitigation object is also extensible and will communicate the 544 current status, offramp/restoration status and any relevant black 545 list information. The status attribute of the mitigation_info object 546 as 3x states: 548 * Inactive - no IPFIX messages have been received in the last health- 549 refresh-timeout period. 550 * Monitoring - IPFIX messages are being received 551 * Mitigating - the upstream is actively mitigating a threat 553 The swing attribute of the mitigation_info object is set either true 554 or false: 556 * True - the attack has abated or reduced (if volumetric) to a level 557 deemed within the capacity of the original signaling component. * 558 False - the attack mitigation should continue to be handled by the 559 upstream element. 561 The blacklistaddrs attribute is a simple set of ipv4 or ipv6 562 addresses and allows an upstream element to communicate known bad 563 actors or compromised hosts to the signaling component. 565 The custom field may be used for the upstream element to communicate 566 an arbitrary object. This could include a service provider portal 567 url or some other yet to be standardised data. 569 5.1 JSON API example interaction 571 +-+-+ +-+-+ 572 | D |---------HTTPS-------| C | 573 +-+-+ +-+-+ 574 | | 575 | +-+-+ 576 +-----------IPFIX-------| I | 577 +-+-+ 579 D = DDoS mitigation device 192.0.2.1 580 C = Service provider 198.51.100.1 581 I = IPFIX receiver 203.0.113.1 583 D initiates an https connection to C: 584 URL: https://user:password@198.51.100.1:443/dots/api/info 585 D posts: 586 { 587 "device_ip":"192.0.2.1", 588 "device_load_config": { 589 "load_factor1": [ 590 "cpu", 591 "85" 592 ], 593 "load_factor2": [ 594 "mem", 595 "85" 596 ], 597 "load_factor3": [ 598 "bandwidth", 599 "75" 600 ] 601 } 602 } 604 C responds: 605 { 606 "access_token":"abc123", 607 "export_host":"203.0.113.1", 608 "whitelist_ips":[ 609 "203.0.113.254", 610 "203.0.113.253" 611 ], 612 "mitigation": { 613 "status":"Inactive", 614 "swing_flag":"True", 615 "blacklistaddrs":[] 616 }, 617 "custom":{"portal_url":"https://portal.ddossp.net/Mitige?=192.0.2.1"} 618 } 620 Upon receipt of the response body the device 192.0.2.1 would now send 621 event exports to the IPFIX collecttor at 203.0.113.1 and would 622 authenticate using the ID "abc123". Periodically a new token may be 623 exchanged or an alternate IPFIX destination (export_host) set. In 624 these instances the signaling component should start using the new 625 credentials or destination immediately. The component will whitelist 626 the ip addresses of 203.0.113.254 and 203.0.113.253. The SOS flag 627 will be set to true should the component cpu=85% or mem=85% or 628 bandwidth=75%. 630 6 IPFIX export 632 IPFIX was selected for this channel due to its push nature, 633 extensible templates and its existing availability on ddos and 634 security platforms. Leveraging an existing protocol will result in 635 minimal retooling and hopefully lower any barrier to adoption. 637 An attack will trigger the creation of an incident record on the 638 component which in turn will trigger IPFIX export to an upstream 639 device or provider with details of the attack parameters. Due to the 640 unreliable nature of UDP event data sets will repeat at regular 641 intervals for the duration of the attack. 643 An attack may generate different data exports which will communicate 644 various facets of the threat, the target and the overall incident. 645 The event data set will define the base key and this will be used to 646 link other records such as protected objects and threat profile data 647 sets. Corresponding data sets referencing the same key will be 648 considered part of the same event when combined with the component 649 id. 651 An IPFIX event data export may be used as a heartbeat between 652 elements. It is recommended that the signaling component 653 periodically send heartbeats upstream to verify its status during 654 periods of relative inactivity, failure by the upstream to receive 655 these heartbeats may then trigger an alert or further investigation 656 into why they never reached their destination. 658 6.1 Event Template 660 The template for events will contain 8x fields as detailed: 661 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 662 | Set ID = 2 | Length | 663 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 664 | Template ID n | Field Count = 8 | 665 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 666 |1| Access Token | Field Length = n | 667 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 668 |1| Key | Field Length = n | 669 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 670 |1| Time | Field Length = n | 671 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 672 |1| Type | Field Length = n | 673 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 674 |1| Description | Field Length = n | 675 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 676 |1| Scope | Field Length = n | 677 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 678 |1| SOS | Field Length = n | 679 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 680 |1| Thresholds | Field Length = n | 681 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 683 6.2 Protected Object Template 685 The template for protected object will contain 16x fields as 686 detailed: 687 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 688 | Set ID = 2 | Length | 689 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 690 | Template ID n | Field Count = 16 | 691 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 692 |1| Access Token | Field Length = n | 693 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 694 |1| Key | Field Length = n | 695 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 696 |1| Label | Field Length = n | 697 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 698 |1| IP version | Field Length = n | 699 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 700 |1| Address/Prefix | Field Length = n | 701 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 702 |1| Protocol | Field Length = n | 703 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 704 |1| Port | Field Length = n | 705 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 706 |1| SLA Code Point | Field Length = n | 707 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 708 |1| Mitigation Status | Field Length = n | 709 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 710 |1| B/W Threshold | Field Length = n | 711 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 712 |1| Current Pps | Field Length = n | 713 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 714 |1| Current Bps | Field Length = n | 715 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 716 |1| Peak Pps | Field Length = n | 717 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 718 |1| Peak Bps | Field Length = n | 719 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 720 |1| Typical Pps | Field Length = n | 721 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 722 |1| Typical Bps | Field Length = n | 723 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 725 6.3 Attack and Threat Identification Template 727 The template for attack and threat identification will contain 4x 728 fields as detailed: 729 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 730 | Set ID = 2 | Length | 731 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 732 | Template ID n | Field Count = 4 | 733 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 734 |1| Access Token | Field Length = n | 735 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 736 |1| Key | Field Length = n | 737 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 738 |1| Threat Identifier | Field Length = n | 739 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 740 |1| Threat Data | Field Length = n | 741 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 742 Note - where no threat data is required to aid in mitigation (ie the 743 identifier is enough) the Threat Data field may be set to null. 745 6.4 Feedback Template 747 The template for feedback will contain 4x fields as detailed: 748 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 749 | Set ID = 2 | Length | 750 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 751 | Template ID n | Field Count = 4 | 752 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 753 |1| Access Token | Field Length = n | 754 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 755 |1| Key | Field Length = n | 756 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 757 |1| CurrentBps | Field Length = n | 758 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 759 |1| CurrentPps | Field Length = n | 760 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 762 7 Security Considerations 764 The protocol described here serves as a security mitigation tool. 765 Potential vulnerabilities of this system are addressed by the use of 766 encrypted channels for communication between the elements and the use 767 of low overhead control signals in case there is denial of service or 768 congestion affecting the paths between the elements. The security 769 considerations of [RFC7011], [RFC5405] and [RFC4960] apply to the 770 IPFIX, UDP and SCTP based channels respectively. Additional security 771 considerations will be added to subsequent drafts. 773 8 IANA Considerations 775 There may be requests to IANA in order to update the registry of 776 IPFIX entities. 778 9 Contributors 780 The initial version of this document represented a collaborative 781 effort by engineers at Verisign and Juniper to create a candidate for 782 an open standards effort supporting communication between on-premise 783 DDoS mitigation devices and provider based DDoS mitigation services. 784 A standards based approach allows businesses to have a wider range of 785 options to better secure their complex environments without the 786 limitation of vendor lock-in. The companies published a draft 787 specification through the Internet Engineering Task Force (IETF) to 788 encourage community participation and further development of these 789 proposals toward becoming an open standard. 791 10 Acknowledgements 793 The following people are acknowledged for their technical 794 contributions in the development of this document: Aziz Mohaisen, Jon 795 Shallow, Suresh Bhogavilli, Jeshmi Raman, Malathy Poruran, Roman 796 Danyliw, Andrew Mortensen, Rich Groves, Scott Barvick, Franck Martin, 797 Brian Trammel. 799 11 References 801 11.1 Normative References 803 [RFC7011] Claise, B., Trammell, B., and P. Aitken, 804 "Specification of the IP Flow Information Export 805 (IPFIX) Protocol for the Echange of Flow Information" 806 https://tools.ietf.org/html/rfc7011 September 2013 808 [RFC5405] Eggert, L. and G. Fairhurst, "Unicast UDP usage 809 Guidelines for Application Designers" 810 https://tools.ietf.org/html/rfc5405 November 2008 812 [RFC4960] Stewart, R, Ed. "Stream Control Transmission 813 Protocol" https://tools.ietf.org/html/rfc4960 814 September 2007 816 12 Changelog 818 Changes between 00 and 01: 819 * Cleaned up language to remove 'cloud' and 'cpe' terminology for 820 clarity 821 * Added feedback element and described same 822 * Called out SCTP as possible transport for IPFIX 823 * Adjusted thresholds to be informed by the originating device 824 * Tidied JSON and other representations 825 * Added smtp ddos to the data dictionary 827 Authors' Addresses 829 Nik Teague 830 Verisign Inc. 831 12061 Bluemont Way 832 Reston, VA 20190 833 US 835 EMail: nteague@verisign.com