1 / 22

BGP FlowSpec: Operational Experience & Future Developments

Explore practical steps to mitigate DDoS attacks using BGP FlowSpec with insights on collaborative initiatives, vendor support, and operational experiences. Learn about the challenges, improvements, and the potential of flexible payload matching.

juliol
Download Presentation

BGP FlowSpec: Operational Experience & Future Developments

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. BGP FlowSpec in 2019: operational experienceandfuturedevelopments a.k.a. “yet another FlowSpec talk” Alessandro Bulletti Kirill Kasavchenko

  2. Volumetric DDoS attacks 2018-2019 Source: Rapporto Clusit 2019 sulla Sicurezza ICT in Italia - Tipologie di attacchi DDoS (Dati Fastweb relativi all’anno 2018) Source: Netscout Threat Report 2018

  3. The needforcollaboration • Ideally, large DDoSattacksshouldbemitigatedasclosetothesourceaspossible. • Practically, thegoodfirststepwouldbe: • Customer asksupstreamprovidertomitigate • Peer asksanotherpeers • As time goesbyandtrustisbuilt, wemightexpectmitigationtonaturallypropagateclosertothesource.

  4. Wait... This is not a newidea! Someof initiatives in thisarea: • Fingerprint Sharing Alliance (Arbor, 2005) • BGP FlowSpec (IETF, 2009) • M3AAWG DDoS Info Sharing (2017) • I2NSF (IETF, 2017) • Stellar: advancedblackholing (DE-CIX/TU Berlin/Max Planck Institute, 2018) • DOTS (IETF, work in progress)

  5. Wait... This is not a newidea! Someof initiatives in thisarea: • Fingerprint Sharing Alliance (Arbor, 2005) • BGP FlowSpec (IETF, 2009) • M3AAWG DDoS Info Sharing (2017) • I2NSF (IETF, 2017) • Stellar: advancedblackholing (DE-CIX/TU Berlin/Max Planck Institute, 2018) • DOTS (IETF, work in progress) • Vendorsupport • Open-sourcetools • Operational experience • User groups

  6. FlowSpec: vendorsand open-source Controllers and BGP FlowSpecspeakers: • Arbor (Netscout) • ExaBGP • FastNetMon • Nokia • Radware Routers: • Cisco IOS-XR (ASR9K, NCS5K) and IOS-XE • Juniper MX/PTX • Alcatel/Nokia 7x50 • Huawei NE routers • 6WIND • Arista FlowSpec Telemetry

  7. FlowSpec: operational experience & usergroups Deployments (based on publicinformation): • Cloudflare, Level3, Rostelecom, Orange Poland DDoSPeering initiative: • AT&T, Century Link, Charter • See slides at NANOG 71 and 75 (links in the end ofthispresentation) FlowSpecmultivendortestsby T-Mobile Austria andNextLayer : • Cisco, Juniper, Huawei, Nokia • Focus on Inter-AS applicabilityand operational needs

  8. Whatworkswell • FlowSpecisextensivelyusedagainstDDoSAmplificationattacks: • Wesee operational communityisautomatingFlowSpecgenerationtostopattackswithout human involvement: • Not just hyperscalers • WeseeadoptionofFlowSpecasthewaytoredirecttraffic on demand: • Redirect to Route Target • Redirect to Next-Hop

  9. Whatcouldbeimproved • Scale on routerside: • NumberofconcurrentlysupportedFlowSpecrules • Speed ofFlowSpecrulesimportandprocessing • Various „safetynets“: • PreventtoomanyFlowSpecrulesfromimpactingrouterforwardingperformance • Lack ofgranularity in importpolicies: • Itisimpossibletoallow/rejectFlowSpecrulesbased on action • Therefore, possibleforcustomertochange DSCP oftheirtrafficto „network-critical“ • These areimplementation-specificimprovements. They do not requireindustryconsensus in a form of IETF documentor BCP.

  10. Whatisimpossibleto do withFlowSpectoday • Match trafficbased on random L3-L4 fieldorbased on payload • Example: IP TTL, TCP Window Size • Report trafficstatisticsacross administrative boundaries • ISP1 sends a FlowSpecruleto ISP2 • How ISP1 getsvisibilityintodroppedtraffictoestimatetheefficacyofFlowSpec? • Thereis a lack ofcommonapproachtotheseproblems. • Weneedstandards (think RFC documents) orsome well-defined Best Current Practices

  11. Flexible Payload Matching: problemstatement • MajorityofvolumetricDDoSattacksareamplificationattacks. Theycanbesuccessfullymitigatedusing „standard“ FlowSpec, matchingsource UDP port: • However, thereexistmorecomplexcases: • Bittorentamplification • SSDP diffraction • These attacksresult in packetswithrandomsource UDP port, so it‘s not possibletocreate a classifierusingFlowSpec. • At the same time, theseattacksgeneratespecificpatterns in payload. • Andsomeroutersareabletomatchpacketsbased on payload.

  12. Flexible Payload Matching: solution (1/2) • ExtendFlowSpecwith „flexible matchconditions“ component type: • draft-khare-idr-bgp-flowspec-payload-match Type X – Flexible Match Conditions

  13. Flexible Payload Matching: solution (2/2) • Usenewcomponent type tomatchanywhere in the packet: • In anyfield • Acrossfieldsregardlessoffieldboundaries • In payload • Match using: • Bit patternwithbitmask • Numericpattern • Regular expressions • draft-khare-idr-bgp-flowspec-payload-match

  14. FlowSpecand Reporting: problemstatement • How do youknowifFlowSpecruleiseffective? • NostandardizedwaytoreporttrafficthatmatchesFlowSpecpolicy: • SNMP counters • XML/Netconf • draft-wu-idr-flowspec-yang-cfg-02 • Goodnews: mostroutersgenerateflowtelemetryfortraffic, droppedbyFlowSpec:

  15. FlowSpecand Reporting: solution • CorellateFlowSpec NLRI and Flow records: • Vendor-independent approach • Noneedto parse proprietary SNMP or XML datamodels Flow Record Src IP Dest IP Src Port Dst Port Proto Input Intf Output Intf = 0 ToS Flags Packet length Etc… Dest Prefix Source Prefix IP Protocol Port Dst Port Src Port ICMP type ICMP code TCP flags FlowSpec NLRI

  16. FlowSpecand Reporting: Inter-AS? • Reporting based on NetflowandFlowSpeccorrelationwon‘tworkbetween ASNs • Nowayfor ISP1 toreceiveflowtelemetryfrom ISP2 • Other approaches (SNMP, Netconf, streamingtelemetry) won‘tworkeither • Wewouldneedsomethingtotallynew: • Most likelysomemediationtoolthatmakessureonly relevant informationisreportedbetween ASNs • Orsomeconceptof „administrative domains“ in flow / SNMP / streamingtelemetry • Whateverthesolutionwouldbe, havingvisibilityintoFlowSpecrulespropagatedbetween ASNs isgoingtobe an essential factorforadoption

  17. FlowSpecevolution: RFC5575bis • Defines all traffic action extended communities as transitive extended communities. RFC5575 defined the traffic- rate action to be non-transitive and did not define the transitivity of the other action communities at all. • Introduces a new traffic filtering action traffic-rate-packets: • Instead of ”rate-limit to 100 bps” you can now “rate-limit to 100 pps” • Introduces rules how updates of Flow Specifications shall be handled in case they contain interfering actions • A full list of changes can be found in the references section of this slide deck • Major changes

  18. Other interestingFlowSpecdevelopments • FlowSpec interface set (draft-ietf-idr-flowspec-interfaceset) • Use BGP communities to signal to which interfaces (interface-set) should a FlowSpec action be applied • Supported in Cisco IOS-XE

  19. Summary • FlowSpecis a matureDDoSmitigationtechnology • No, it‘s not perfectandaloneis not enoughtostop all typesofDDoSattacks • itis not applicableagainst TCP SYN floodsandapplicationlayerDDoS • but itmitigatesthemostimpactingDDoStypes in ISP networks – amplificationattacks • Check with $your_router_vendorwhattheplatformlimitsare: • Scale • Policies • Don‘tbeafraidtoautomateFlowSpec. Ifyoudon‘tknowhow – talktous. • Work with IETF andvendorstogetnewFlowSpecideasimplemented • A.k.a Last Slide

  20. References • Stellar, advancedblackholing: https://www.de-cix.net/Files/2731074c857497be3827ac9537b6e486f27aa57c/Research-paper-Stellar-Network-Attack-Mitigation-using-Advanced-Blackholing.pdf • NANOG71 DDoSpeering: https://www.youtube.com/watch?v=Aj8EKYVSTtk • NANOG75 eBGPFlowSpecpeering: https://www.youtube.com/watch?v=rKEz8mXcC7o • InteropFlowSpectestsby T-Mobile and Next Layer: https://www.nextlayer.at/wp-content/uploads/2018/06/loibl-bacher-bgp-flowspec-interop-012017.pdf • FlowSpecpayloadmatching: https://datatracker.ietf.org/doc/draft-khare-idr-bgp-flowspec-payload-match/ • SSDP DiffractionAttack: https://www.netscout.com/blog/asert/new-twist-ssdp-attacks • FlowSpec at CloudFlare: https://meetings.ripe.net/see4/files/RIPE%20SEE4%20Belgrade%20Serbia%20-%20CloudFlare%20-%20DDoS%20mitigation%20-%20Martin%20Levy.pdf • FlowSpec at Level3: https://www.capacitymedia.com/articles/3585228/Level-3-launches-BGP-Flowspec-on-global-backbone • FlowSpec at Rostelecom: https://habr.com/ru/company/rostelecom/blog/325138/ • FlowSpec in Orange Poland: https://cert.orange.pl/aktualnosci/ddos-w-naszej-sieci-coraz-silniej-coraz-wiecej • RFC5575bis changescomparedto RFC5575: https://tools.ietf.org/html/draft-ietf-idr-rfc5575bis-14#appendix-A • The last slide, really

  21. alessandro.bulletti@netscout.com kirill.kasavchenko@netscout.com

More Related