ddos open threat signaling (dots) working group presentation on draft-ietf-dots-use-cases-00

DOTS WG

draft-ietf-dots-use-cases-00

DDoS Open Threat Signaling (DOTS) Working Group

Roland Dobbins – Arbor Networks

Stefan Fouant – Corero Network Security

Daniel Migault – Ericsson

Robert Moskowitz – HTT ConsulAng

Nik Teague – Verisign

Liang ‘Frank’ Xia – Huawei

DOTS WG 2

IntroducAon & Context

DOTS WG 3

draft-ietf-dots-use-cases-00 Summary

•  Provides example use-cases for DOTS (actually, categories). •  All examples can be CE/PE or PE/PE. •  Room for wide variation within each category (see 4.1.1). •  All DOTS communications in each example can be directly

between DOTS servers and DOTS clients, or mediated by DOTS relays.

•  DOTS relays can forward messages between DOTS clients and servers using either stateless transport, stateful transport, or a combination of the two.

•  DOTS relays can aggregate service requests, status messages, and responses.

•  DOTS relays can filter service requests, status messages, and responses

DOTS WG 4

draft-ietf-dots-use-cases-00 Summary (cont.)

•  Use-cases in -00 are not exhaustive, are illustrative. •  Use-cases in -00 focus on DDoS mitigation using dedicated

mitigation devices. S/RTBH, flowspec, OpenFlow, etc. can also be used to leverage network infrastructure for DDoS mitigation.

•  4.1.1 use-case in this presentation illustrates full DOTS communications cycle, variants.

•  Other use-cases in this presentation are summarized ‘diffs’ illustrating DOTS communications model in widely varying circumstances.

•  Use-cases in this presentation focus on protecting servers under DDoS attack on destination networks. DOTS can also be used to suppress attack traffic on origin networks or as it traverses intermediary networks.

DOTS WG 5

4.1 -‐ Primary Use Cases

DOTS WG 6

ReflecAon/AmplificaAon DDoS AYacks

4.1.1 – CPE or PE MiAgators Request Upstream DDoS MiAgaAon

DOTS WG 7

DOTS WG 8

DOTS WG 9

DOTS WG 10

DOTS WG 11

DDoS a&ack ini+ated.

DOTS WG 12

A&ack mi+gated on-‐prem.

DOTS WG 13

On-‐prem mi+ga+on capacity exceeded.

DOTS WG 14

On-‐prem mi+ga+on capacity exceeded.

DOTS WG 15

DOTS client signals for upstream mi+ga+on.

DOTS WG 16

DOTS server acknowledges mi+ga+on request, mi+ga+on ini+ated.

DOTS WG 17

Mi+ga+on in progress.

DOTS WG 18

Status messages exhanged during mi+ga+on – efficacy, mi+ga+on status, etc.

DOTS WG 19

A&ack terminated.

DOTS WG 20

Mi+ga+on status change message transmi&ed.

DOTS WG 21

Mi+ga+on termina+on service request.

DOTS WG 22

Mi+ga+on termina+on service acknowledgement.

DOTS WG 23

Mi+ga+on terminated, return to status quo ante.

DOTS WG 24

DOTS communica+on rela+onships.

DOTS WG 25


4.1.1 – VariaAon with DOTS Relay MediaAng CommunicaAons

DOTS WG 26

DOTS WG 27

DOTS WG 28


DOTS WG 29


DOTS WG 30


DOTS WG 31


4.1.1 – VariaAon with Overlay DDoS MiAgaAon Service Provider

DOTS WG 32

DOTS WG 33


DOTS WG 34


DOTS WG 35


4.1.1 – VariaAon with MulAple Upstream DDoS MiAgaAon Providers

DOTS WG 36

DOTS WG 37


DOTS WG 38

Mi+ga+on status messaging between providers.

DOTS WG 39


DOTS WG 40


4.1.2 – Network Infrastructure Device Requests Upstream DDoS

MiAgaAon

DOTS WG 41

DOTS WG 42


DOTS WG 43


DOTS WG 44


4.1.3 – AYack Telemetry DetecAon/ClassificaAon System Requests Upstream

DDoS MiAgaAon

DOTS WG 45

DOTS WG 46


DOTS WG 47


DOTS WG 48


4.1.4 – Targeted Service/ApplicaAon Requests Upstream DDoS MiAgaAon

DOTS WG 49

DOTS WG 50


DOTS WG 51


DOTS WG 52


4.1.5 – Manual Web Portal Request to Upstream MiAgator

DOTS WG 53

DOTS WG 54

Mi+ga+on in progress. HTTP/S between Web browser & DOTS client on Web portal.

DOTS WG 55

Mi+ga+on in progress. HTTP/S between Web browser & DOTS client on Web portal.

DOTS WG 56

Communica+on rela+onships. DOTS on upstream mi+ga+on network only.

DOTS WG 57


4.1.6 – Manual Mobile Device ApplicaAon Request to Upstream

MiAgator

DOTS WG 58

DOTS WG 59


DOTS WG 60


DOTS WG 61

s


4.1.7 – Unsuccessful CPE or PE MiAgator Request for Upstream

DDoS MiAgaAon

DOTS WG 62

DOTS WG 63


DOTS WG 64

Another a&ack ini+ated, different target.

DOTS WG 65

Mi+ga+on service request refused due to mi+ga+on capacity constraints.

DOTS WG 66


DOTS WG 67

4.2 -‐ Ancillary Use Cases

DOTS WG 68

4.2.1 – Auto-Registration

•  Beyond attack mitigation requests, responses, and status messages, DOTS can also be useful for administrative tasks.

•  Administrative tasks are a significant barrier to effective DDoS mitigation.

•  DOTS clients with appropriate credentials can auto-register with DOTS servers on upstream mitigation networks.

•  This helps with DDoS mitigation service on-boarding, moves/adds/changes.

DOTS WG 69

4.2.2 – Automatic Provisioning of DDoS Countermeasures

•  DDoS countermeasure provisioning today is a largely manual process, errors and inefficiency can be problematic.

•  This can lead to inadequately-provisioned DDoS mitigation services which often are not optimized for the assets under DDoS protection. Mitigation rapidity, efficacy suffers.

•  On-boarding organizations during an attack – an all-too-common situation – can be very challenging.

•  The ‘self-descriptive’ nature of DOTS registration and mitigation status requests can be leveraged to automate the countermeasure selection, provisioning, and tuning process.

•  Mitigation efficacy feedback from DOTS clients to DOTS servers during an attack can be leveraged for real-time mitigation tuning and optimization.

DOTS WG 70

4.2.3 – Informational DDoS Attack Notification to Third Parties

•  In addition to service requests from organizations under attack to upstream mitigators, DOTS can be used to send DDoS attack notification and status messages to interested and authorized third parties.

•  It may be beneficial in some circumstances to automatically provide attack notifications and status messages econdary or tertiary ‘backup’ mitigation providers, security researchers, vendors, law enforcement agencies, regulatory agencies, etc.

•  Any such sharing of information with third parties should only take place in accordance with all relevant laws, regulations, contractual obligations, privacy and confidentiality agreements.

DOTS WG 71

s


Next Steps for Use-‐Cases Drac

DOTS WG 72

To-Do List for draft-dots-ietf-use-cases-01

•  Fix typos (doh!). •  Remove duplicative verbiage. •  Wordsmith phrasing for clarity. •  Present use-cases via ‘diffs’ – i.e., refer to commonalities

with other use-cases, emphasize specific factors unique to each use-case.

•  Reconcile definitions of terminology with dots-ietf-requirements draft.

•  Add use-cases illustrating suppression of DDoS attack traffic on origin networks, filtering on intermediate networks.

•  Add use-cases illustrating specific PE-PE scenarios (e.g., ‘overflow’ requests for additional DDoS mitigation capacity, etc.).

DOTS WG 73

Request for Feedback from WG Participants

•  What should we add? •  What should we remove? •  What should we change? •  Should we include variations (via ‘diffs’)

on each use-case similar to what was done with 4.1.1 in this presentation?

•  Other input?

DOTS WG

This Presentation – http://bit.ly/1N6u8za

DOTS WG

Thank you!

DDoS Open Threat Signaling (DOTS) Working Group

Roland Dobbins – Arbor Networks

Stefan Fouant – Corero Network Security

Daniel Migault – Ericsson

Robert Moskowitz – HTT ConsulAng

Nik Teague – Verisign

Liang ‘Frank’ Xia – Huawei

ddos open threat signaling (dots) working group presentation on draft-ietf-dots-use-cases-00

Internet