BGP Security Techniques Danny McPherson danny@arbor.net Kyoto, - - PowerPoint PPT Presentation

▶
bgp security techniques
SMART_READER_LITE
LIVE PREVIEW

BGP Security Techniques Danny McPherson danny@arbor.net Kyoto, - - PowerPoint PPT Presentation

Sep 14, 2023 159 likes •455 views

BGP Security Techniques Danny McPherson danny@arbor.net Kyoto, Japan APRICOT 2005 1 Agenda Overview & Discussion Context BGP Blackhole Routing BGP Diversion BGP Route Tagging BGP Flow Specification Analyzing

slide-1
SLIDE 1

Kyoto, Japan APRICOT 2005 1

BGP Security Techniques

Danny McPherson danny@arbor.net

slide-2
SLIDE 2

Kyoto, Japan APRICOT 2005 2

Agenda

  • Overview & Discussion Context
  • BGP Blackhole Routing
  • BGP Diversion
  • BGP Route Tagging
  • BGP Flow Specification
  • Analyzing “Dark IP” Data
slide-3
SLIDE 3

Kyoto, Japan APRICOT 2005 3

Overview

  • The purpose of this discussion is to

both discuss BGP security techniques employed by network operators today, as well as to introduce some new mechanisms and techniques currently under development and request feedback from the community

slide-4
SLIDE 4

Kyoto, Japan APRICOT 2005 4

About this talk….

  • What this talk is about:

– Using BGP as a security response tool – Benefits of employing unutilized/unallocated address space

  • What this talk is NOT about:

– Securing the BGP protocol (e.g., MD5 or IPSEC for Transport connection) – Securing information carried by BGP (e.g., prefix filters, soBGP & SBGP, RIRs & IRRs, etc..) – Configuration syntax - however, appropriate references provided

slide-5
SLIDE 5

Kyoto, Japan APRICOT 2005 5

Interesting Notes…

  • Have seen DoS attacks greater than 10Gbps aggregate

capacity!

  • Of 1127 DoS attacks seen on a very large network since JAN

03, only 4 employed address spoofing - "spoofing is out of vogue”?

  • 140415 node botnet largest "seen" in the wild - larger botnets

probable.

  • Miscreants are avoiding RFC1918 and other bogon address

space and explicitly targeting "easy pickens” prefixes such as 24/8.

  • Miscreants often patch exploitable code once they compromise

a system in order to "keep it” -- they probably install more patches than users!

  • DOS attack vectors are changing (e.g., UDP brute force as
  • pposed to TCP-based, arbitrary DDOS toolkit)
slide-6
SLIDE 6

Kyoto, Japan APRICOT 2005 6

The Problem…

  • The magnitude of DDOS attacks result in network

instability and often times collateral damage to the network infrastructure

  • Mitigation policies need to be deployed at the

network ingress and propagated to upstream networks in near real-time

  • ACL management, deployment and implementation/

performance implications inhibit their use considerably - consider deployment of attack mitigation policies to 2000 interfaces on 400 routers, augmenting existing policies and removing said policies once attack has ceased

slide-7
SLIDE 7

Kyoto, Japan APRICOT 2005 7

BGP Blackhole Routing

  • Commonly referred to as BGP Real-Time Blackhole Routing

(RTBH), or Blackhole Filtering; results in packets being forwarded to a routers bit bucket, also known as:

– Null Interface – Discard Interface

  • Several Techniques:

– Destination-based BGP Blackhole Routing – Source-based BGP Blackhole Routing (coupling uRPF) – Customer-triggered

  • Exploits router’s forwarding logic - typically results in desired

packets being dropped with minimal or no performance impact

  • Enables BGP Backscatter Traceback Technique
slide-8
SLIDE 8

Kyoto, Japan APRICOT 2005 8

Exploits Forwarding Logic

FIB

  • Ingress Packet

Filter

  • Null0/Discard

Packets Arrive

  • Forward packet to the Bit Bucket
  • Saves on CPU and ACL

processing

Egress Interface

slide-9
SLIDE 9

Kyoto, Japan APRICOT 2005 9

Customer is DOSed – Before – Collateral Damage

NOC A B C D E F G

Target

Peer B Peer A

IXP-W IXP- E

Upstream A Upstream B Upstream B

POP

Upstream A Customers

Attack causes Collateral Damage

slide-10
SLIDE 10

Kyoto, Japan APRICOT 2005 10

Customer is DOSed – After – Packet Drops Pushed to Network Ingress

NOC A B C D E F G

BGP Advertises Black Holed Prefixes Target

Peer B Peer A IXP-W IXP-E

Upstream A Upstream B Upstream B

POP

Upstream A

slide-11
SLIDE 11

Kyoto, Japan APRICOT 2005 11

Monitoring Backscatter

  • Inferring Internet Denial-of-Service Activity

– http://www.caida.org/outreach/papers/2001/BackScatter/

  • Backscatter Traceback (NANOG 23)
slide-12
SLIDE 12

Kyoto, Japan APRICOT 2005 12

Beyond Destination-based RTBH

  • Employing uRPF in conjunction with

RTBH can provide source-based solution v. destination-based

  • Why not allow customer triggered

blackholing for more-specifics of their prefixes?

slide-13
SLIDE 13

Kyoto, Japan APRICOT 2005 13

BGP Diversion Techniques

  • Rather than employing BGP to simply discard traffic

(and often effectively complete a Denial of Service attack), use BGP to divert traffic to data analysis or packet “scrubbing” centers, often referred to as Sinkholes

  • Divert via resetting BGP next hop to IP address of

analysis system(s) or matching community tags that result in different BGP next hops being assigned for a given prefix (or PBR, or static, or…)

slide-14
SLIDE 14

Kyoto, Japan APRICOT 2005 14

Typical Aggregate Sources

AS 100 AS 65530

10.1/16

  • 10.1/16 allocated to AS 100
  • 10.1.0/19 used for infrastructure
  • 10.1.32/19 AS 65530
  • 10.1.64/19 AS 65531
  • 10.1/16 (10.1.96-10.1.255.255) implicitly nailed to null interface on core routers (C,B,D&E)

AS 65531

10.1.0/19 10.1.32/19 10.1.64/19

H G F E D C B A

slide-15
SLIDE 15

Kyoto, Japan APRICOT 2005 15

Routers Collect Garbage Data

AS 100 AS 65530

10.1/16

  • Routers collect all the garbage (backscatter, scans, etc..) destined for

10.1/19, 10.1.96/19 & 10.1.128/17 addresses

  • Routers are required to process data, send ICMP unreachables, etc..

AS 65531

10.1.0/19 10.1.32/19 10.1.64/19

Scans, Backscatter, Other Garbage

A C B E D F G H

slide-16
SLIDE 16

Kyoto, Japan APRICOT 2005 16

Why not Divert to Sinkhole?

AS 100 AS 65530

10.1/16

AS 65531

10.1.0/19 10.1.32/19 10.1.64/19

Scans, Backscatter, Worms, Other Garbage

10.1.0/19 & 10.128/17

C A D G E B H F

  • Why not divert garbage to sinkhole, if not for further analysis, at least to off-load

data processing from routers

  • Traffic forwarded to sinkhole for analysis, removes processing overhead from

routers

  • Provide collection point for further analysis
slide-17
SLIDE 17

Kyoto, Japan APRICOT 2005 17

Sinkholes – Advertising Dark IP

  • Move the CIDR Block Advertisements (or at least more-specifics of

those advertisements) to Sinkholes

  • Does not impact BGP routing – route origination can happen

anywhere in the iBGP mesh (careful about MEDs and aggregates)

  • Control where you drop the packet
  • Turns networks inherent behaviors into a security tool!

To ISP Backbone To ISP Backbone To ISP Backbone

Sinkhole Gateway Target Router Sniffers and Analyzers

Target router receives the garbage Advertise CIDR blocks with Static Lock-ups pointing to the target router

slide-18
SLIDE 18

Kyoto, Japan APRICOT 2005 18

BGP Route Tagging

  • Employ same technique as previously

discussed mechanisms to tag routes (usually via BGP Communities) in order to apply some firewall, packet filter, rate limit, quality

  • f service or similar policy to packets

matching the prefix (or attributes identified by the policy)

  • E.g., Cisco’s BGP Policy Propagation (BPP)
slide-19
SLIDE 19

Kyoto, Japan APRICOT 2005 19

BGP Flow Specification

  • Defined in:

– http://www.ietf.org/internet-drafts/draft-marques-idr-flow-spec-02.txt

  • Specifies procedures for the distribution of flow

specification rules via BGP

  • Defines AN application for the purpose of packet

filtering in order to mitigate (distributed) denial of service attacks

  • Defines procedure to encode flow specification rules

as BGP NLRI which can be used in any way the implementer desires

slide-20
SLIDE 20

Kyoto, Japan APRICOT 2005 20

What’s a Flow Specification?

  • A flow specification is an n-tuple consisting of several matching

criteria that can be applied to IP packet data

  • May or May not include reachability information (e.g.,

NEXT_HOP)

  • Well-known or AS-specific COMMUNITIES can be used to

encode/trigger a pre-defined set of actions (e.g., blackhole, PBR, rate-limit, divert, etc..)

  • Application is identified by a specific (AFI, SAFI) pair and

corresponds to a distinct set of RIBs

  • BGP itself treats the NLRI as an opaque key to an entry in its

database

slide-21
SLIDE 21

Kyoto, Japan APRICOT 2005 21

What’s it for?

  • Primarily/Initially: DDOS/Worm Mitigation
  • Continue evolution from:

– Destination-based blackhole routing – uRPF/source-based BGP blackhole routing

  • To:

– Much more precise/granular mechanism that contains all the benefits of it’s predecessors

  • At least one implementation complete, another

(more?) on the way

slide-22
SLIDE 22

Kyoto, Japan APRICOT 2005 22

We Need Operator Feedback!

  • Is this useful?
  • What’s missing (e.g., more flexible

specification language)

  • Does this belong in BGP?
  • What are our alternatives?
  • Comments to authors are welcome!

– flow-spec@tcb.net

slide-23
SLIDE 23

Kyoto, Japan APRICOT 2005 23

About Dark IP…

  • Various IP address classifications

– RFC 1918 (e.g., 10/8, 172.16/12 & 192.168/16) – Bogon addresses are address blocks that have not yet been allocated by IANA or a RIR (e.g., APNIC or ARIN) – Dark IP addresses have been allocated to a network operator and are currently being advertised, but have not yet been allocated to end-users/customers; typically subsets of allocated blocks – Active address space has been allocated to end- users/customers and end systems

slide-24
SLIDE 24

Kyoto, Japan APRICOT 2005 24

Packets to Dark IP Destinations

  • Limited set of traffic destined for these

IP addresses:

– Broken/Misconfigured – Scanning/Malicious – Backscatter – No legitimate traffic to these IP addresses

  • Monitor traffic to detect deviations,

reconnaissance activities, etc..

slide-25
SLIDE 25

Kyoto, Japan APRICOT 2005 25

Dark IP Monitor

  • Can monitor via packet collection, flow

analysis, etc..

  • Can also monitor RFC1918 address

space in this manner, assuming no use internally

  • Can even use flow-based monitoring to

monitor all traffic of this type n network- wide - even production traffic.

slide-26
SLIDE 26

Kyoto, Japan APRICOT 2005 26

The Internet Motion Sensor Project

  • University of Michigan led research project
  • Distributed on many networks, monitoring

10s of millions of unique “Dark IP” address blocks

  • Utilizes BGP diversion and Dark IP

monitoring

– W/Throttled active responders – Correlation and alerting agents, etc..

  • For more information: http://ims.eecs.umich.edu
slide-27
SLIDE 27

Kyoto, Japan APRICOT 2005 27

References

  • Backscatter Traceback (NANOG 23)
  • Security on the CPE Edge (NANOG 26)
  • Sinkholes (NANOG 28)
  • Customer-Triggered Real-time Blackholes (NANOG 30)
  • APRICOT 2004 - “ISP Security: Deploying and Using Sinkholes”
  • http://www.ietf.org/internet-drafts/draft-marques-idr-flow-spec-

02.txt

  • http://www.nanog.org (Index of Talks)
  • The Internet Motion Sensor http://ims.eecs.umich.edu
  • The Internet Motion Sensor: A distributed blackhole monitoring
  • system. NDSS ’05, San Diego, CA, February 2005.
  • Tracking Global Threats with the Internet Motion Sensor.

Presentation at NANOG 32, October 2004.

  • Toward Understanding Distributed Blackhole Placement. In

WORM’04: Proceedings of the 2004 ACM workshop on Rapid Malcode, 2004.

slide-28
SLIDE 28

Kyoto, Japan APRICOT 2005 28

Questions?

danny@arbor.net