WIXLIB

Scalable DDoS mitigationPeter FiloSenior Systems EngineerALEF Distribution SK

Agenda Traditional DDoS Mitigation– Remote Triggered Blackhole Filtering Scalable DDoS Mitigation– BGP FlowSpec Cloud DDoS Protection– F5 Silverline

DDoS Overview Distributed denial-of‐service (DDoS) attacks target networkinfrastructures or computer services by sending overwhelmingnumber of service requests to the server from many sources. Server resources are used up in serving the fake requests resultingin denial or degradation of legitimate service requests to be served Addressing DDoS attacks– Detection Detect incoming fake requests– Mitigation Diversion – Send traffic to a specialized device that removes the fake packetsfrom the traffic stream while retaining the legitimate packets Return – Send back the clean traffic to the server

DDoS Detection NetFlow / IPFIX / sFlow– How many flows/sec can your routers meter, and how fast is yourcollector/analyzer?– What are you going to look at? SNMP– Are you looking at all the right values?– Are you polling your devices every second, every minute, every hour? SYSLOG– Need to set up proper rules to filter out the events you want to see RADIUS/TACACS logging– Watch those authentication failures and changes to the nodes Packet capturing– Do you use TAPs/Splitters?

Goals of DDoS Mitigation Stop the attack Drop only the DDoS traffic Application aware filtering, redirection, mirroring Dynamic and adaptive technology Simple to configure Easy to disseminate

Remote Triggered Black-Hole Filtering (RTBH) Once the attack has been detected, traffic related to the DDoSshould be discarded on the edge of the service provider network BGP router (trigger) signals over BGP to the edge routers that trafficcausing DDoS should be discarded (forwarded to null interface) Destination-based RTBH– Traffic going to the IP addresses of the customer is discarded on theedge Source-based RTBH– Traffic coming from the IP addresses of the attacker is discarded onthe edge– Uses strict uRPF with BGP signalling

Destination-based RTBH! PE1 router!ip route 192.0.2.1 255.255.255.255 Null0!interface Null0no ip unreachablesSPAS 65535Gi0/0PE1PE2Signalling routerAttackerCustomer172.19.61.0/24! Signalling router!router bgp 65535.redistribute static route-map static-to-bgp.!route-map static-to-bgp permit 10match tag 66set ip next-hop 192.0.2.1set local-preference 200set community no-exportset origin igp!route-map static-to-bgp permit 20! Signalling router / adding a static route when under attack!ip route 172.19.61.1 255.255.255.255 Null0 Tag 66192.168.10.0/24

Source-based RTBH! PE1 router!ip route 192.0.2.1 255.255.255.255 Null0!interface Null0no ip unreachables!interface GigabitEthernet0/0/0ip verify unicast source reachable-via rxSPAS 65535Gi0/0/0PE1PE2Signalling routerAttackerCustomer172.19.61.0/24! Signalling router!router bgp 65535.redistribute static route-map static-to-bgp.!route-map static-to-bgp permit 10match tag 66set ip next-hop 192.0.2.1set local-preference 200set community no-exportset origin igp!route-map static-to-bgp permit 20! Signalling router / adding a static route when under attack!ip route 192.168.10.0 255.255.255.0 Null0 Tag 66192.168.10.0/24

RTBH as a Service Ask your uplink providers for blackhole BGP community Provide blackhole BGP community to your customersweb server172.19.61.1/24DDoS TrafficBGP: 172.19.61.0/24F0/0SPAS 65535CEPE2InternetPE1BGP: 172.19.61.1/32Com: 65535:666! CE routerrouter bgp 65500.network 172.19.61.0 mask 255.255.255.0redistribute static route-map static-to-bgp!route-map static-to-bgp permit 5match tag 666set community additive 65535:666!ip route 172.19.61.1 255.255.255.255 FastEthernet0/0 tag 666!!172.19.61.1/32 Discard! PE2 routerrouter bgp 65535.neighbor cust route-map from-customer in!ip community-list standard BH permit 65535:666!route-map from-customer permit 10match community BHset ip next-hop 192.0.2.1set local-preference 200set community no-export!route-map rm-community-in permit 20!

Remote Triggered Black-Hole Filtering (RTBH) No more DDoS traffic on my web server But no more traffic at all on my webserver IP based solution only Is this the solution you were looking for?

Policy Based Routing ? Identification of DDoS traffic based around conditionsregarding MATCH statements–––––Source/Destination addressProtocolPacket SizePort NumberEtc. Actions upon DDoS traffic––––DiscardRate LimitingRedirectionEtc.No more DDoS traffic on my web server Does not this sound as a great solution?

Policy Based Routing ? Good solution for– Done with hardware acceleration for carrier grade routers– Can provide very good precision of match statements andactions to impose But.– Customer need to call its Service Provider– Service Provider has to accept and run this filter on each oftheir peering routers– Customers need to call the Service Provider and removethe rule after Not scalable.

Solution: BGP FlowSpec Makes static PBR a dynamic solution Allows to propagate PBR rules Existing control plane communication channel is used Uses your existing MP-BGP infrastructure

RFC5575 Dissemination of Flow Specification Rules Published in August 2009 New Flow Specification NLRI type encoded usingMP REACH NLRI/MP UNREACH NLRI Inter-domain support Point-to-multipoint with Route-Reflectors Networking engineers and architects understand perfectly BGP Capability to send via a BGP address Family– Match criteria (NLRI)– Action criteria (Extended communities) Three elements– Controller– Client– Route-reflector (optional)

BGP FlowSpec Components Controller– Injects rules remotely in the clients– Needs to implement at the minimum the Control Path– Examples of BGP FS Controllers: Router (ASR9K, CRS, NCS6000, XR12000) Server (ExaBGP, Arbor PeakFlow SP Collector Platform) Virtual router (XRv) Client– Receives rules from Controller(s) and programs the match/action in hw– Needs to implement both Control Plane and Data Plane– Examples of BGP FS Clients: Router (ASR9K, ASR1K) Route-Reflector (optional)– Receives rules from Controller(s) and distributes them to Clients– Examples of BGP FS Route-Reflectors: ASR9K; CRS; NCS6000 or XRv

RFC5575 Dissemination of Flow Specification Rules New NLRI defined (AFI 1, SAFI 133) to describe the traffic of interest1. Destination IP Address (1 component)2. Source IP Address (1 component) ------- 3. IP Protocol ( 1 component) Address Family Identifier (2 octets) 4. Port ( 1 component) ------- 5. Destination port ( 1 component) Subsequent Address Family Identifier (1 octet) ------- 6. Source port ( 1 component) Length of Next Hop Network Address (1 octet) 7. ICMP Type ------- Network Address of Next Hop (variable) 8. ICMP code ------- 9. TCP Flags Reserved (1 octet) ------- 10. Packet length Network Layer Reachability Information (variable) 11. DSCP ------- 12.FragmentThe MP REACH NLRI – RFC 4760Notice from the RFC: “Flow specification components must follow strict type ordering. A givencomponent type may or may not be present in the specification, but if present, it MUST precedeany component of higher numeric type value.”

RFC5575 Dissemination of Flow Specification Rules Traffic Action is defined in extended communities (RFC4360)01230 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Type high Type low(*) - - - - - - - - - - - - - - - - Value - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - TypeDescriptionEncoding0x8006Traffic-rate2bytes ASN; 4 bytes as float0x8007Traffic-actionBitmask0x8008Redirect6 bytes RT (Route Target)0x8009Traffic-markingDSCP value

Cisco IOS XR Routers BGP FS Implementation Platform HardwareControl Plane SupportData Plane SupportASR9K – Typhoon LC5.2.05.2.0ASR9K – Thor LC5.2.05.2.2ASR90015.2.05.2.2ASR9K – TomahawkTarget 5.3.xTarget 5.3.xCRS – Taiko LC5.2.05.2.0CRS – Topaz LC5.2.0Target 5.3.1XRv5.2.0N/AC12K5.2.0Not plannedNCS6000Target 5.2.3/5.2.4Target 5.2.3/5.2.4In Cisco IOS 15.5(S) release, BGP flow specification is supported only on a route reflector.IOS XE software supports BGP flow specification client function and does not support BGPflow specification controller function.Mixing of address family matches and actions is not supported in flow spec rules. Forexample, IPv4 matches cannot be combined with IPv6 actions and vice versa.

Cisco IOS XR Routers BGP FS ImplementationNLRI typeMatch fieldsValue inputmethodXR PIASR9KCRSNCS6000Type 1IPv4 DestinationaddressPrefix length Type 2IPv4 Source addressPrefix length Type 3IPv4 protocolMulti value range Type 4IPv4 source ordestination portMulti value range Type 5IPv4 destinationportMulti value range Type 6IPv4 source portMulti value range Type 7IPv4 ICMP typeMulti value range Type 8IPv4 ICMP codeMulti value range Type 9IPv4 TCP flagsBit mask Only lower Bytereserved and NS bitnot supportedOnly lower Bytereserved and NS bitnot supportedOnly lower Bytereserved and NS bitnot supportedType 10IPv4 packet lengthMulti value range Type 11IPv4 DSCPMulti value range Type 12IPv4 fragmentationbitsBit mask Only indication offragment

Cisco IOS XR Routers BGP FS ImplementationNLRI typeMatch fieldsValue input methodXR PIASR9KCRSNCS6000Type 1IPv6 DestinationaddressPrefix length Type 2IPv6 Source addressPrefix length Type 3IPv6 Next headerMulti value range Type 4IPv6 source ordestination portMulti value range Type 5IPv6 destinationportMulti value range Type 6IPv6 source portMulti value range Type 7IPv6 ICMP typeMulti value range Type 8IPv6 ICMP codeMulti value range Type 9IPv6 TCP flagsBit mask Only lower Bytereserved and NS bitnot supportedOnly lower Bytereserved and NS bitnot supportedOnly lower Bytereserved and NS bitnot supportedType 10IPv6 packet lengthMulti value range Type 11IPv6 Traffic classMulti value range Type 12ReservedN/AN/AN/AN/AN/AType 13IPv6 Flow BasedMulti value rangexxxx

Configuring BGP FlowSpec on IOS XR Routers Signalisation: Use of a new Address-family flowspecController!router bgp1bgprouter-id 6.6.6.6address-family ipv4 flowspec!neighbor-group ibgp-flowspecremote-as 1update-source loopbook0address-family ipv4 flowspec!!neighbor 25.2.1.3use neighbor-group ibgp-flowspec!neighbor 25.2.1.4use neighbor-group ibgp-flowspec!!flowspecaddress-family ipv4service-policy type pbr FS!Client!router bgp1bgprouter-id 3.3.3.3address-family ipv4 flowspec!neighbor-group ibgp-flowspecremote-as 1update-source loopback0address-family ipv4 flowspec!neighbor 25.2.1.11use neighbor-group ibgp-flowspec!!flowspeclocal-install interface-all!Advertise policy FSInstall all ruleson all interfaces

Configuring BGP FlowSpec on IOS XR Routers Verifying the Session Establishment (on Client)RP/0/RP0/CPU0:Client#sh bgp ipv4 flowspec summaryBGP router identifier 3.3.3.3, local AS number 1BGP generic scan interval 60 secsNon-stop routing is enabledBGP table state: ActiveTable ID: 0x0 RD version: 7072BGP main routing table version 7072BGP NSR Initial initsyncversion 0 (Reached)BGP NSR/ISSU Sync-Group versions 7072/0BGP scan interval 60 secsBGP is operating in STANDALONE mode.ProcessSpeakerRcvTblVer7072Neighbor Spk25.2.1.11 fxRcd1001

Configuring BGP FlowSpec on IOS XR Routers Configuring Rules on the Controller In many aspects, the rules configuration on the controller issimilar to the MQC (Modular QoS Configuration) Rules are defined in Cisco Common Classification PolicyLanguage (C3PL) format:– Traffic Matching is defined in class-map– Action is defined in a policy-map and refers a class-map– This policy-map is advertised by the “service-policy type pbr”