DDoS Open Threat Signaling (DOTS) Working Group Operational - - PowerPoint PPT Presentation

▶
ddos open threat signaling dots working group operational
SMART_READER_LITE
LIVE PREVIEW

DDoS Open Threat Signaling (DOTS) Working Group Operational - - PowerPoint PPT Presentation

Feb 05, 2023 42 likes •386 views

DDoS Open Threat Signaling (DOTS) Working Group Operational Requirements Chris Morrow <morrowc@ops-netman.net> Network Security Engineer , Google Roland Dobbins <rdobbins@arbor.net>

slide-1
SLIDE 1

DOTS WG

Operational Requirements DDoS Open Threat Signaling (DOTS) Working Group

Chris ¡Morrow ¡<morrowc@ops-­‑netman.net> ¡ Network ¡Security ¡Engineer, ¡Google ¡ ¡ Roland ¡Dobbins ¡<rdobbins@arbor.net> ¡ Principal ¡Engineer, ¡Arbor ¡Networks ¡

slide-2
SLIDE 2

DOTS WG

2 ¡

IntroducDon ¡& ¡Context ¡

slide-3
SLIDE 3

DOTS WG

What is a Distributed Denial of Service (DDoS) attack?

  • An attempt to consume finite resources, exploit weaknesses in software

design or implementation, or exploit lack of infrastructure capacity

  • Targets the availability and utility of computing and network resources
  • Attacks are almost always distributed for even more significant effect

(i.e., DDoS)

  • The collateral damage caused by an attack can be as bad, if not worse,

than the attack itself

  • DDoS attacks affect availability! No availability, no applications/services/

data/Internet! No revenue!

  • DDoS attacks are attacks against capacity and/or state!

DDoS Background

slide-4
SLIDE 4

DOTS WG

Confiden'ality ¡ Integrity ¡ Availability ¡

Three Security Characteristics

  • The goal of security is to maintain these three

characteristics

slide-5
SLIDE 5

DOTS WG

Three Security Characteristics

  • The primary goal of DDoS defense is

maintaining availability in the face of attack

Confiden'ality ¡ Integrity ¡

Availability ¡

slide-6
SLIDE 6

DOTS WG

6 ¡

ReflecDon/AmplificaDon ¡ DDoS ¡ALacks ¡

RealiDes ¡of ¡Coordinated ¡ DDoS ¡Defense ¡

slide-7
SLIDE 7

DOTS WG

7 ¡

Common Perception of Internet Security Posture Today

slide-8
SLIDE 8

DOTS WG

8 ¡

Actual State of Internet Defenses Today

slide-9
SLIDE 9

DOTS WG

9 ¡

Who Can Help? Your ISP or MSSP!

slide-10
SLIDE 10

DOTS WG

10 ¡

How Can You Ask for Help Today?

Technology pioneered by Robert Hooke in 1667, only slightly improved!

slide-11
SLIDE 11

DOTS WG

11 ¡

Asking for Help is Hard! Knowing How to Help is Harder!

  • Most end-customers have no idea what their normal Internet

traffic looks like, much less what’s actually happening when they’re being DDoSed (or even understanding that they’re under attack!).

  • Many ISPs/MSSPs do not provision DDoS defenses in detail

for their end-customers. In many (most?) cases, end- customers cannot articulate what servers/services need protection, what network access policies should be in place, etc.

  • This drastically slows reaction/mitigation times.
  • This drastically impedes reaction/mitigation efficacy.
  • This leads to extended outages, lost revenue, frustrated

end-customers (and customers of those end-customers).

slide-12
SLIDE 12

DOTS WG

12 ¡

Automated DDoS Attack Notification Methods Exist Today

  • But they are proprietary!
  • End-customers can’t mix-and-match vendors, ISP DDoS cloud

mitigation providers, MSSP DDoS cloud mitigation providers. Effective coordination during an attack is for all practical purposes impossible.

  • Servers/services/infrastructure devices which are the targets of DDoS

can’t signal for mitigation, even if they have the ability to detect and classify DDoS attacks (think Apache mod_security/mod_evasive, BIND RRL).

  • ISPs/MSSPs must coordinate (badly, inefficiently) manually when jointly

working to mitigate DDoS attacks.

  • As attackers shift DDoS vectors/resources, severe latency, common

miscuing occurs between defenders.

  • Web portals exist; they’re specific to vendors/ISPs/MSSPs, have varying

degrees of mitigation configurability (most end-customers wouldn’t know what to configure), and can be difficult to access during an attack when IDC & client LAN transit are conflated.

slide-13
SLIDE 13

DOTS WG

13 ¡

DDoS Defense Becomes a Typing Contest . . . Attacker.

slide-14
SLIDE 14

DOTS WG

14 ¡

DDoS Defense Becomes a Typing Contest . . . Defender.

slide-15
SLIDE 15

DOTS WG

15 ¡

Largely Static, Low-Agility Defenses . . .

slide-16
SLIDE 16

DOTS WG

16 ¡

. . . Lead to Predictable Outcomes.

slide-17
SLIDE 17

DOTS WG

17 ¡

Coordination of DDoS Defenses, Circa 1995.

slide-18
SLIDE 18

DOTS WG

18 ¡

Coordination of DDoS Defenses, Circa 2005.

slide-19
SLIDE 19

DOTS WG

19 ¡

Coordination of DDoS Defenses, Circa 2015.

slide-20
SLIDE 20

DOTS WG

20 ¡

We Can – and Must – Do Better Than This!

slide-21
SLIDE 21

DOTS WG

21 ¡

We Need a Standardized Way of Sharing Information . . .

slide-22
SLIDE 22

DOTS WG

22 ¡

. . . Across a Fast, Low-Latency, Unreliable Transport . . .

slide-23
SLIDE 23

DOTS WG

23 ¡

. . . Across a Reliable Transport That Will Make It Through Policies . . .

slide-24
SLIDE 24

DOTS WG

24 ¡

. . . Tell Us About Itself, Its Problems, and Its Desired Actions. . .

slide-25
SLIDE 25

DOTS WG

25 ¡

. . . That Can Be Relayed Internally and Externally as Needed . . .

slide-26
SLIDE 26

DOTS WG

26 ¡

. . . Everyone and Everything on the Network Can Participate . . .

slide-27
SLIDE 27

DOTS WG

27 ¡

. . . In Coordinated, On-Demand DDoS Defense.

slide-28
SLIDE 28

DOTS WG

28 ¡

Summary ¡of ¡DOTS ¡ OperaDonal ¡Requirements ¡

slide-29
SLIDE 29

DOTS WG

29 ¡

DOTS Operational Requirements

  • Standards-based exchange of DDoS

attack and mitigation information.

  • Must not assume organic detection/

classification capabilities of supplicant.

  • Must work across common unreliable and

reliable transports.

  • Must support mutual authentication and
  • ptional crypto.
slide-30
SLIDE 30

DOTS WG

30 ¡

  • Must describe target under attack (IP

address range, ports/protocols/services running on target, etc.).

  • Must describe desired outcome in general

terms (block, redirect, scrub, rate-limit, etc.).

  • Must update supplicant with implemented

actions and status, supplicant must do same.

  • Must support intra- and inter-organizational

relays. DOTS Operational Requirements (cont.)

slide-31
SLIDE 31

DOTS WG

31 ¡

DOTS Operational Requirements (cont.)

  • Must support policy-based action/outcome

filtering and transformation.

  • Must be extensible.
  • Must focus on DDoS initially, other uses

can come later.

  • Must minimize complexity of

implementation and node interaction.

slide-32
SLIDE 32

DOTS WG

32 ¡

DOTS Operational Requirements (cont.)

  • Must include a ‘heartbeat’ function.
  • Must be detection/classification/mitigation-

technology agnostic.

  • Must support allowed distribution scope

(TLP?).

  • Should utilize existing protocols and

information models wherever possible and whenever appropriate.

slide-33
SLIDE 33

DOTS WG

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

slide-34
SLIDE 34

DOTS WG

Thank You!

Chris ¡Morrow ¡<morrowc@ops-­‑netman.net> ¡ Network ¡Security ¡Engineer, ¡Google ¡ ¡ Roland ¡Dobbins ¡<rdobbins@arbor.net> ¡ Principal ¡Engineer, ¡Arbor ¡Networks ¡

DDoS Open Threat Signaling (DOTS) Working Group