Authorizing Network Control at Software Defined Exchange Points - - PowerPoint PPT Presentation

authorizing network control at software defined exchange
SMART_READER_LITE
LIVE PREVIEW

Authorizing Network Control at Software Defined Exchange Points - - PowerPoint PPT Presentation

Authorizing Network Control at Software Defined Exchange Points Arpit Gupta Princeton University http://sdx.cs.princeton.edu Nick Feamster, Laurent Vanbever Internet Exchange Points (IXPs) Route Server BGP Session IXP Switching Fabric AS


slide-1
SLIDE 1

Authorizing Network Control at Software Defined Exchange Points

Arpit Gupta

Princeton University http://sdx.cs.princeton.edu

Nick Feamster, Laurent Vanbever

slide-2
SLIDE 2

Internet Exchange Points (IXPs)

AS A Router AS C Router AS B Router BGP Session Switching Fabric

IXP

Route Server

2

slide-3
SLIDE 3

Software Defined IXPs (SDXs)

AS A Router AS C Router AS B Router BGP Session SDN Switch SDX Controller

SDX

3

slide-4
SLIDE 4

SDX Opens Up New Possibilities

  • More flexible business relationships

– Make peering decisions based on time of day, volume of traffic & nature of application

  • More direct & flexible traffic control

– Define fine-grained traffic engineering policies

  • Better security

– Block or redirect attack traffic at finer level of granularity

4

slide-5
SLIDE 5

SDX for DDoS Attack Mitigation

5

SDX 1 SDX 2 Attacker AS 88

Attack traffic traverses two different SDXs

slide-6
SLIDE 6

Remotely Block Attack Traffic

6

SDX 1 SDX 2 Attacker AS 88

Victim remotely pushes block rules to SDX

SDN Policies

slide-7
SLIDE 7

Subscribe to Third Party Services

7

SDX 1 SDX 2 Attacker AS 88

Victim Subscribes to Verisign for DDoS Protection

Verisign SDN Policies DOTS

slide-8
SLIDE 8

SDX vs. Traditional DDoS Defense

  • Remote influence

Physical connectivity to SDX not required

  • More specific

Drop rules based on multiple header fields, source address, destination address, port number …

  • Coordinated

Drop rules can be coordinated across multiple IXPs

8

slide-9
SLIDE 9

Spider-Man Dilemma

  • Authorize Remote Requests

– Is AS 88 owner of flow space under attack?

  • Authorize Third Party Requests

– Is Verisign authorized by AS 88 to block or redirect attack traffic? – Is AS 88 owner of flow space under attack?

9

With Great Power Comes Great Responsibility

slide-10
SLIDE 10

Authorization Logic

  • Conventional Authorization Logic

– Applied over discrete resources – Limited allowable actions (read/write etc.)

  • Authorization Logic for Network Control

– Resources à Set of packets within some flow space – Actions à Transformations on the packet’s metadata

10

slide-11
SLIDE 11

FLANC Authorization Logic

  • Resource Ownership

– Principals that own the resource under consideration

  • Allowed Actions

– Set of allowed transformations for resource owners, T:{sIP, sPort, dIP, dPort, phyPort} à {sIP, sPort, dIP, dPort, phyPort} – e.g. Drop Telnet traffic from 10.0.0.1 and 20.0.0.1 T:{{10.0.0.1,20.0.0.1}, *,*, {23},*} à {*,*,*,*,{}}

  • Delegations

– Mechanisms by which one principal gives other permission to operate

  • n their resources

11

slide-12
SLIDE 12

Reference Monitor

Participant 1 Participant 2 Participant N Southbound APIs Network Events Event Handler Credential Handler Request Handler Credentials

FLANC Authorization Logic at SDX

SDX Controller Switching Fabric

slide-13
SLIDE 13

AS 88 sends Delegation Credentials

13

SDX 1 SDX 2 Attacker AS 88 Verisign AS 88 says, Verisign speaks for AS 88 for T, where T:{*,*,{128.112.0.0/16},{80,443},*} à {*,*,*,*,*}

slide-14
SLIDE 14

14

SDX 1 SDX 2 Attacker AS 88

(HTTP, 128.112.136.35)

Verisign

AS 88’s HTTP Server under Attack

slide-15
SLIDE 15

AS 88 sends DOTS Message

15

SDX 1 SDX 2 Attacker AS 88 Verisign

{128.112.136.35,80,TCP}

slide-16
SLIDE 16

Verisign sends SDN Policies

16

SDX 1 SDX 2 Attacker AS 88 Verisign

dIP=128.112.136.80, dPort=80 à fwd(V)

slide-17
SLIDE 17

Checking Authorization at SDX

  • Request Handler

– Associate request with the principal (Verisign) – Extract request transformation

  • Treq:{*, *, 128.112.136.80, 80, *} à {*,*,*,*,V}
  • Credential Handler

– CA says, “AS 88 owns {*, *, 128.112.0.0/16, *, * }” – Delegation credentials from AS 88

  • Reference Monitor

– Generate a proof, “Verisign can say Treq”

17

slide-18
SLIDE 18

Evaluation Results

Dataset: AS 88 IPS logs for 1 week, 550K alert events

18

20 40 60 80 100 120 140 Time (us) 0.0 0.2 0.4 0.6 0.8 1.0 Cumulative Distribution of Time

Remote Requests Third Party Requests

slide-19
SLIDE 19

Evaluation Results

FLANC incurs minimal performance overhead

19

20 40 60 80 100 120 140 Time (us) 0.0 0.2 0.4 0.6 0.8 1.0 Cumulative Distribution of Time

Remote Requests Third Party Requests

slide-20
SLIDE 20

Takeaways

  • Authorizing Network Control at SDX is critical
  • FLANC is the first step

– Associates requests with principal – Considers flow space abstraction – Considers conditional delegations

  • FLANC’s scope is broader than SDX

– Campus Network – Mitigating Route Hijacks

20