idnits 2.17.1 draft-andreasen-dots-info-data-model-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 31, 2016) is 2735 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-18) exists of draft-ietf-dots-architecture-00 ** Downref: Normative reference to an Informational draft: draft-ietf-dots-architecture (ref. 'I-D.ietf-dots-architecture') == Outdated reference: A later version (-22) exists of draft-ietf-dots-requirements-02 ** Downref: Normative reference to an Informational draft: draft-ietf-dots-requirements (ref. 'I-D.ietf-dots-requirements') -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) -- Obsolete informational reference (is this intentional?): RFC 6347 (Obsoleted by RFC 9147) Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 DOTS F. Andreasen 2 Internet Draft T. Reddy 3 Intended status: Standards Track Cisco 4 Expires: April 30, 2017 October 31, 2016 6 Distributed Denial-of-Service Open Threat Signaling (DOTS) 7 Information and Data Model 8 draft-andreasen-dots-info-data-model-01.txt 10 Abstract 12 This document defines an information model and a data model for 13 Distributed Denial-of-Service Open Threat Signaling (DOTS). The 14 document specifies the Message and Information Elements that are 15 transported between DOTS agents and their interconnected 16 relationships. The primary purpose of the DOTS Information and Data 17 Model is to address the DOTS requirements and DOTS use cases. 19 Status of this Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six 30 months and may be updated, replaced, or obsoleted by other documents 31 at any time. It is inappropriate to use Internet-Drafts as 32 reference material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on March 30, 2017. 36 Copyright Notice 38 Copyright (c) 2016 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with 46 respect to this document. Code Components extracted from this 47 document must include Simplified BSD License text as described in 48 Section 4.e of the Trust Legal Provisions and are provided without 49 warranty as described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction...................................................3 54 2. Notational Conventions and Terminology.........................4 55 3. Information Model..............................................4 56 3.1. General...................................................4 57 3.2. Signal Channel Messages...................................6 58 3.2.1. Open Signal Channel..................................6 59 3.2.2. Close Signal Channel.................................8 60 3.2.3. Redirect Signal Channel..............................8 61 3.2.4. Request Status Update................................9 62 3.2.5. Status Update.......................................10 63 3.2.6. Request Mitigation..................................10 64 3.2.7. Stop Mitigation.....................................11 65 3.3. Data Channel Messages....................................11 66 3.3.1. Open Data Channel...................................11 67 3.3.2. Close Data Channel..................................12 68 3.3.3. Redirect Data Channel...............................12 69 3.3.4. SendData............................................12 70 3.4. Information Elements.....................................13 71 3.4.1. Protocol version....................................13 72 3.4.2. Attack Target.......................................13 73 3.4.3. Agent Id............................................13 74 3.4.4. Blacklist...........................................13 75 3.4.5. Whitelist...........................................13 76 3.4.6. Attack telemetry....................................13 77 3.4.7. Mitigator feedback..................................14 78 3.4.8. Mitigation efficacy.................................14 79 3.4.9. Mitigation failure..................................14 80 3.4.10. Mitigation Scope...................................14 81 3.4.11. Mitigation Scope Conflict..........................15 82 3.4.12. Resource Group Alias...............................15 83 3.4.13. Mitigation duration................................15 84 3.4.14. Peer health........................................15 85 3.4.15. Filters............................................15 86 3.4.16. Filter-actions.....................................15 87 3.4.17. Acceptable signal lossiness........................15 88 3.4.18. Heartbeat interval.................................16 89 3.4.19. Data Channel Address...............................16 90 3.4.20. Extensions.........................................16 92 4. Data Model....................................................16 93 5. IANA Considerations...........................................16 94 6. Security Considerations.......................................16 95 7. Acknowledgements..............................................16 96 8. References....................................................17 97 8.1. Normative References.....................................17 98 8.2. Informative References...................................17 100 1. Introduction 102 A distributed denial-of-service (DDoS) attack is an attempt to make 103 machines or network resources unavailable to their intended users. 104 In most cases, sufficient scale can be achieved by compromising 105 enough end-hosts and using those infected hosts to perpetrate and 106 amplify the attack. The victim in this attack can be an application 107 server, a client, a router, a firewall, or an entire network. 109 In order to mitigate a DDoS attack while still providing service to 110 legitimate entities, it is necessary to identify and separate the 111 majority of attack traffic from legitimate traffic and only forward 112 the latter to the entity under attack, which is also known as 113 "scrubbing". Depending on the type of attack, the scrubbing process 114 may be more or less complicated, and in some cases, e.g. a bandwidth 115 saturation, it must be done upstream of the DDoS attack target. 117 DDoS Open Threat Signaling (DOTS) defines an architecture to help 118 solve these issues (see [I-D.ietf-dots-architecture]). In the DOTS 119 architecture, a DDoS attack target is associated with a DOTS client 120 which can signal a DOTS server for help in mitigating an attack. 121 The DOTS client and DOTS server (collectively referred to as DOTS 122 agents) can interact with each other over two different channels: a 123 signal and a data channel, as illustrated in Figure 1. 125 +---------------+ +---------------+ 126 | | <------- Signal Channel ------> | | 127 | DOTS Client | | DOTS Server | 128 | | <======= Data Channel ======> | | 129 +---------------+ +---------------+ 131 : DOTS signal and data channels 133 The DOTS signal channel is primarily used to convey information 134 related to a possible DDoS attack so appropriate mitigation actions 135 can be undertaken on the suspect traffic. The DOTS data channel is 136 used for infrequent bulk data exchange between DOTS agents in the 137 aim to significantly augment attack response coordination. 139 In this document, we define the overall information model and data 140 model for the DOTS signal channel and data channel. The information 141 and data models are designed to adhere to the overall DOTS 142 architecture [I-D.ietf-dots-architecture] , the DOTS use case 143 scenarios, and the DOTS requirements [I-D.ietf-dots-requirements]. 145 2. Notational Conventions and Terminology 147 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 148 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 149 document are to be interpreted as described in [RFC2119]. 151 The reader should be familiar with the terms defined in [I-D.ietf- 152 dots-architecture]. 154 3. Information Model 156 The information model is broken into the following areas: 158 o General, which provides a general high-level overview of the 159 overall information model and its structure 161 o Signal Channel specific, which provides an API-style interface 162 description for the signal channel 164 o Data Channel specific, which provides an API-style interface 165 description for the data channel 167 o Information Element specific, which describes the various 168 information elements used by the above 170 3.1. General 172 DOTS supports request/response style interactions as well as 173 asynchronous messages as illustrated below: 175 DOTS-Request(parameters) => DOTS-Response(parameters) 177 DOTS-Notification(parameters) 179 DOTS requests, responses and notifications are collectively referred 180 to as DOTS messages, and associated with each DOTS message is one or 181 more parameters. DOTS messages include one or more parameters, each 182 of which belong to one of the following categories 184 o Mandatory, which are base DOTS protocol parameters that MUST 185 always be included with the message in question. 187 o Optional, which are base DOTS protocol parameters that MAY be 188 included with the message in question. 190 o Extensions, which are extended DOTS protocol parameters that MAY 191 be included with the message in question. 193 Mandatory and optional DOTS protocol parameters MUST be supported by 194 all DOTS agents. Extension DOTS protocol parameters define extended 195 functionality above and beyond the base DOTS protocol that MAY be 196 supported by a particular DOTS agent. The DOTS protocol includes an 197 extension framework that enables each DOTS agent to determine which 198 extension a peer DOTS agent supports. The extension framework also 199 enables a DOTS agent to specify how to handle any unsupported 200 extensions. 202 DOTS supports versioning in the form of a DOTS protocol version, 203 which is included in every DOTS message. If a DOTS agent receives a 204 DOTS request with an unsupported protocol version, it will reply 205 with a failure and an indication of the protocol version(s) 206 supported. This enables a future version of the DOTS protocol to be 207 defined in a backwards compatible manner. If a DOTS Notification 208 with an unsupported protocol version is received, it will simply be 209 discarded. 211 All DOTS messages include a message-id and an agent-id. The agent-id 212 identifies the originator of the message, whereas the message-id 213 provides an identifier for DOTS Request/Response correlation and 214 DOTS Notification identification. 216 o [Editor's note: There are different views on whether an agent-id 217 is needed at the DOTS level or whether the underlying security 218 mechanisms (incl. authenticated identity via (D)TLS) suffices. 219 For now, the draft includes an explicit agent-id at the DOTS 220 level]. 222 o [Editor's note: Need to look more closely at how we ensure 223 message-id uniqueness. One option is to include the agent-id from 224 the request or notification as part of it. Also, not clear (yet) 225 if this is really information/data model or protocol] 227 DOTS messages are exchanged over the DOTS Signal channel and the 228 DOTS Data Channel. In either case, there is a channel establishment 229 procedure taking place initially whereby: 231 1. The DOTS client determines the address of a DOTS server to 232 establish the DOTS channel with. The base DOTS protocol assumes 233 the DOTS client has already obtained either this address, or a 234 domain name [RFC1034] or DNS SRV name [RFC2782] that can lead to 235 it. One way of achieving that is by provisioning. 237 2. The DOTS agents mutually authenticate each other. The Information 238 and Data model assumes that the DOTS protocol will run on top of 239 a secure transport (e.g. TLS [RFC5246] or DTLS [RFC6347]) that 240 also provides mutual authentication. The DOTS agent-id will need 241 to be tied-to or covered by this transport-level mutual 242 authentication. If not, explicit mutual authentication of the 243 DOTS agent-id at the DOTS protocol level will be needed 245 o [Editor's note: The mutual authentication aspect of the DOTS 246 agent-id is a bit sketchy; needs more consideration] 248 Note that the mutual authentication of the DOTS agents are needed to 249 verify the service relationship between the DOTS client and server 250 as well as govern relevant authorization policies with respect 251 further DOTS operation (e.g. scrubbing of traffic for the client in 252 question). 254 o [Editor's note: The below is work in progress - main focus is on 255 overall approach and messages right now. The actual parameters 256 are expected to evolve in future versions] 258 3.2. Signal Channel Messages 260 In this section, we describe the signal channel messages. 262 o [Editor's note: Most (all ?) messages can be extended - 263 currently not clearly shown in the following] 265 3.2.1. Open Signal Channel 267 The OpenSignalChannel request establishes a signal channel from the 268 LocalAgent to the RemoteAgent: 270 OSCreply OpenSignalChannel(LocalAgentId, RemoteAgent 271 [, ExtensionsSupported]) 273 LocalAgentId is the local DOTS client id. 275 RemoteAgent is one or more of IP-address(es), domain-name and DNS 276 SRV name for the remote DOTS agent with which the signal channel is 277 to be established. When more than one of these is present, the 278 priority order for client use is DNS SRV, domain-name and IP- 279 address(es). A lower priority MUST NOT be used unless a higher 280 priority fails to produce a response. 282 o Note that the intent of this priority order is not to replace any 283 DNS caching but rather to provide a "last resort" in case of DNS 284 failure. If domain name use is not desired, then RemoteAgent MUST 285 only include IP-address(es). 287 ExtensionsSupported may optionally be included to indicate which 288 extensions are supported by the DOTS client. 290 A successful OSCreply contains the following information: 292 o Response code, which indicates the outcome of the request 294 o RemoteAgentId, which is the peer DOTS agent Id. 296 o SignalChannel, which is a handle for the new signal channel 297 assuming the request succeeded 299 o [optional] ExtensionsSupported, which lists the extensions 300 supported by the remote DOTS agent. 302 A failure OSCreply contains the following information: 304 o Response code, which indicates the outcome of the request 306 o RemoteAgent, which indicates a different agent to establish the 307 signal channel with (redirect) 309 o [optional] ExtensionsSupported, which lists the extensions 310 supported by the remote DOTS agent. 312 3.2.2. Close Signal Channel 314 The CloseSignalChannel request closes a previously established 315 signal channel: 317 CSCreply CloseSignalChannel(SignalChannel) 319 SignalChannel is the handle for the signal channel to be closed. 321 The CSCreply contains the following information 323 o Response code, which indicates the outcome of the request 325 3.2.3. Redirect Signal Channel 327 The RedirectSignalChannel request instructs the peer DOTS agent to 328 change the signal channel to the alternative DOTS agent indicated. 330 o [Editor's note: At the IETF Berlin meeting, there was discussion 331 around using anycast to possibly avoid redirection. Anycast 332 however would not be mandatory, and even when supported, it may 333 be desirable to "redirect" to a non-anycast address after initial 334 discovery for stability] 336 o [Editor's note: Data channel is currently associated with the 337 data channel. Either they both have to get redirected or we need 338 a way of (re)associating the data channel with the new signal 339 channel; maybe a MoveSignalChannel() ?] 341 o [Editor's note: When redirecting the channel, do we redirect the 342 existing one or create a new one and close the old one ? The 343 latter seems cleaner, albeit more explicit.] 345 RSCreply RedirectSignalChannel(SignalChannel, NewAgent) 347 SignalChannel is the handle for the signal channel to be redirected. 349 NewAgent is an IP-address, domain-name or DNS SRV name for the new 350 remote DOTS agent with which the signal channel is to be redirected 351 to. 353 The CSCreply contains the following information 355 o Response code, which indicates the outcome of the request. Note 356 that a success response merely indicates successful receipt and 357 reply to the request; successful redirection of signal channel is 358 not implied. 360 3.2.4. Request Status Update 362 The RequestStatusUpdate message is a notification to the peer agent 363 asking it to provide a status update as indicated 365 RequestStatusUpdate(Target [, Heartbeat] [, Health] [, Attack] 366 [, Mitigation] [, Efficacy]) 368 Target specifies the attack target for which status updates are 369 requested 371 o [Editor's note: Need to come up with a more detailed model for 372 how we identify and describe targets] 374 Heartbeat requests a status update at the heartbeat interval 375 specified. 377 Health requests health information for the target. 379 Attack requests attack information for the target. 381 Mitigation requests mitigation status information for the target. 383 Efficacy requests mitigation efficacy information for the target. 385 3.2.5. Status Update 387 The StatusUpdate message is a notification to the peer agent. 388 StatusUpdate provides heartbeat functionality and updates around 389 health, attack status, mitigation status and mitigation efficacy 391 StatusUpdate(Target, [, HealthStatus] [, AttackStatus] 392 [, MitigationStatus] [, MitigationEfficacy]) 394 Target specifies the attack target for which status updates are 395 provided. 397 HealthStatus provides overall health for the target 399 AttackStatus provides information about an ongoing attack for the 400 target 402 o [Editor's note: Do we need to identify and refer to specific 403 attacks for a given target or just the target itself. For now, 404 assume just the target itself. Question applies to other 405 parameters here as well.] 407 MitigationStatus provides information about current mitigation(s) in 408 place for the target. The status reflects information from the 409 mitigator's point of view. 411 MitigationEfficacy provides information about the efficacy of the 412 mitigation. The efficacy reflects information from the attack 413 target's point of view. 415 3.2.6. Request Mitigation 417 The RequestMitigation message is a notification to the peer agent to 418 invoke mitigation for the attack target specified. If the request is 419 received and honored, mitigation will commence and a StatusUpdate 420 message will be sent to reflect that. Note that either message is 421 especially susceptible to loss during an active DDoS attack 423 RequestMitigation(Target) 425 Target specifies the attack target for mitigation is requested. 427 3.2.7. Stop Mitigation 429 The StopMitigation message is a notification to the peer agent to 430 stop further attack mitigation for the target indicated. The message 431 is sent on behalf of the attack target towards the mitigator. 433 StopMitigation(Target) 435 Target specifies the attack target for which mitigation is to be 436 stopped. 438 3.3. Data Channel Messages 440 In this section, we describe the data channel messages. 442 o [Editor's note: Most (all ?) messages can be extended - currently 443 not clearly shown in the following] 445 3.3.1. Open Data Channel 447 The OpenDataChannel request opens a Data Channel to be used in 448 conjunction with a previously established Signal Channel 450 ODCreply OpenDataChannel(SignalChannel [, ExtensionsSupported]) 452 SignalChannel is the handle for the existing signal channel. 454 ExtensionsSupported may optionally be included to indicate which 455 extensions are supported by the DOTS client. 457 A successful ODCreply contains the following information 459 o DataChannel, which is a handle for the new data channel 461 o [optional] ExtensionsSupported, which lists the extensions 462 supported by the remote DOTS agent. 464 A failure ODCreply contains the following information 466 o Response code, which indicates the outcome of the request 468 o RemoteAgent, which indicates a different agent to establish the 469 data channel with (redirect) 471 3.3.2. Close Data Channel 473 The CloseDataChannel request closes a previously established data 474 channel: 476 CDCreply CloseDataChannel(DataChannel) 478 DataChannel is the handle for the data channel to be closed. 480 The CDCreply contains the following information 482 o Response code, which indicates the outcome of the request 484 3.3.3. Redirect Data Channel 486 o [Editor's note: Resolve open questions in Redirect Signal Channel 487 first] 489 3.3.4. SendData 491 The SendData request sends data to the peer DOTS agent over the data 492 channel. 494 SDreply SendData(DataChannelData) 496 DataChannelData may contain one or more of the following: 498 o Blacklists, whitelists, filters, aliases\names) 500 [Editor's note: The above needs much more work and overall 501 structure. Break up into individual pieces and make sure it's 502 modular, extensible and we have clarity on which data is mandatory 503 versus optional to support] 505 3.4. Information Elements 507 o [Editor's note: The following should merely be considered as a 508 bucket of possible IEs at this point; further work needed, 509 including reconciling with message definitions in sections above] 511 3.4.1. Protocol version 513 3.4.2. Attack Target 515 o [Editor's note: may be superfluous given Mitigation Scope below"] 517 3.4.3. Agent Id 519 (identity for each DOTS client and server, contains a least a domain 520 portion that can be authenticated) 522 3.4.4. Blacklist 524 (define, retrieve, manage and refer to) 526 3.4.5. Whitelist 528 (define, retrieve, manage and refer to) 530 3.4.6. Attack telemetry 532 (collected behavioral characteristics defining the nature of a DDoS 533 attack) 534 o [9/27: Probably extended functionality.] 536 3.4.7. Mitigator feedback 538 (attack mitigation feedback from server to client, incl. mitigation 539 status [start, stop, metrics, etc.], attack ended and information 540 about mitigation failure) 542 3.4.8. Mitigation efficacy 544 (attack mitigation efficacy feedback from client to server) 546 3.4.9. Mitigation failure 548 (unsupported target type, mitigation capacity exceeded, excessive 549 "clean traffic", out-of-service, etc.) 551 3.4.10. Mitigation Scope 553 Classless Internet Domain Routing (CIDR) prefixes, BGP prefix, URI, 554 DNS names, E.164, "resource group alias", port range, protocol, or 555 service 557 o [Editor's note: comes from requirements - not clear how 558 "protocol" and "service" are defined. Also, consider which URI 559 schemes] 561 o [Editor's note: It would probably be useful to structure 562 mitigation scope and related information (like telemetry, 563 blacklist, etc.) into different "types", since different types of 564 targets will have different parameters and different DOTS servers 565 may support different types of attack targets] 567 Information about the attack (e.g. targeted port range, protocol or 568 scope) 570 o [Editor's note: Not clear this is really different from 571 "Mitigation Scope" below - taken from requirement OP-006] 573 o [9/27: Roland doesn't think we need this as baseline 574 information.] 576 3.4.11. Mitigation Scope Conflict 578 Nature and scope of conflicting mitigation requests received from 579 two or more clients 581 3.4.12. Resource Group Alias 583 (define in data channel, refer to in signal/data channel; aliases 584 for mitigation scope) 586 3.4.13. Mitigation duration 588 (desired lifetime - renewable) 590 3.4.14. Peer health 592 (? - measure of peer health) 594 3.4.15. Filters 596 3.4.16. Filter-actions 598 (rate-limit, discard) 600 3.4.17. Acceptable signal lossiness 602 (for unreliable delivery) 604 3.4.18. Heartbeat interval 606 3.4.19. Data Channel Address 608 o Editor's note: For discussion (not entirely aligned with current 609 architecture draft text); assumes establish signal channel first 610 and learn data channel address through it (would be useful for 611 redirection as well and makes it easier for signal and data 612 channel to terminate on different entities)] 614 3.4.20. Extensions 616 (standard, vendor-specific, supported) 618 4. Data Model 620 TODO 622 5. IANA Considerations 624 TODO 626 6. Security Considerations 628 TODO 630 7. Acknowledgements 632 TODO 634 This document was prepared using 2-Word-v2.0.template.dot. 636 8. References 638 8.1. Normative References 640 [RFC1034] Mockapetris, P.V., "Domain Names - concept and 641 facilities", RFC 1034, November 1987. 643 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 644 specifying the location of services (DNS SRV)", RFC 2782, 645 February 2000. 647 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 648 Requirement Levels", BCP 14, RFC 2119, March 1997. 650 [I-D.ietf-dots-architecture] Mortensen, A., Andreasen, F., Reddy, 651 T., christopher_gray3@cable.comcast.com, c., Compton, R., 652 and N. Teague, "Distributed-Denial-of-Service Open Threat 653 Signaling (DOTS) Architecture", draft-ietf-dots- 654 architecture-00 (work in progress), July 2016. 656 [I-D.ietf-dots-requirements] Mortensen, A., Moskowitz, R., and T. 657 Reddy, "Distributed Denial of Service (DDoS) Open Threat 658 Signaling Requirements", draft-ietf-dots-requirements-02 659 (work in progress), July 2016. 661 8.2. Informative References 663 [RFC5246] Dierks, T., and E. Rescorla, "The Transport Layer Security 664 (TLS) Protocol Version 1.2", RFC 5246, August 2008 666 [RFC6347] Rescorla, E., and N. Modadugu, "Datagram Transport Layer 667 Security Version 1.2", RFC 6347, January 2012 669 Authors' Addresses 671 Flemming Andreasen 672 Cisco Systems, Inc. 673 USA 675 Email: fandreas@cisco.com 677 Tirumaleswar Reddy 678 Cisco Systems, Inc. 679 Cessna Business Park, Varthur Hobli 680 Sarjapur Marathalli Outer Ring Road 681 Bangalore, Karnataka 560103 682 India 684 Email: tireddy@cisco.com