interdomain routing security. how secure are bgp security protocols? some strange assumptions? –...

Interdomain Routing SecurityInterdomain Routing Security

How Secure are BGP Security Protocols?

• Some strange assumptions?– Focused on attracting traffic from as many Ases as

possible– Subprefix attacks not considered– Can prefix lists be generated easily? (the evil of

multi-homing)

Outline• Security goals for interdomain routing– Secure message exchange– Prefix ownership and attributes– Agreement with the forwarding path– Preventing resource exhaustion

• BGP (in)security today– Best common practices

• Proposed security enhancements– Secure BGP (S-BGP)– Anomaly-detection schemes

• Discussion

Security Goals

Secure Message Exchange Between Neighbors

• Confidential BGP message exchange– Can two ASes exchange messages without

someone watching?

• No denial of service– Prevent CPU overload, session reset, and

tampered BGP messages?BGP session

physical link

Validity of Route Announcements• Origin authentication– Is the prefix owned by the AS announcing it?

1

2

3

4

5

67

12.34.0.0/1612.34.0.0/16

Validity of Route Announcements

• AS path authentication– Is AS path the sequence of ASes the BGP update

traversed?

1

2

3

4

5

67“7 5 6”

“4 6”

Adherence to Business Contracts

• AS path policy – Does the AS path adhere to the routing policies of

each AS?– Is a path announced when it should be?

1 2

0

1 2

0

customer

peers

Correspondence to the Data Path

• Agreement between control and data plane– Does the traffic follow the advertised AS path?

1

2

3

4

5

67

“7 5 6”

“4 5 6”

Preventing Resource Exhaustion• Limiting the size of the BGP table– Can the router run out of memory?– Storing routes for many prefixes, with long paths?

• Limiting the number of BGP messages– Can the router run out of CPU and bandwidth?– Due to flapping prefixes, duplicate messages, etc.

BGP sessions

BGP (In)Security Today

BGP Security: Applying Best Common Practices

• Securing the BGP session– Authentication, encryption, TTL tricks

• Filtering routes by prefix and AS path– Preventing your customers from hijacking others

• Resetting attributes to default values– Preventing your peers from tricking you

• Packet filters to block unexpected BGP traffic– Blocking port 179 from unexpected places

• Preventing resource exhaustion– Limiting #prefixes/session, and prefix lengths

Best Practice is Not Good Enough

• Depends on vigilant application of BCPs– By your neighbors, and your neighbors’ neighbors,

and your neighbors’ neighbors’ neighbors– And nobody making configuration mistakes!

• Doesn’t address fundamental problems– Can’t tell who owns the IP address block– Can’t tell if the AS path is bogus or invalid– Can’t be sure data packets follow the chosen

route– Can’t easily bound the memory requirements

Security Enhancements to BGP

Secure BGP (S-BGP)• Address attestations– Claim the right to originate a prefix– Signed and distributed out-of-band– Checked through delegation chain from ICANN

• Route attestations– Distributed as an attribute in BGP update message– Signed by each AS as route traverses the network– Signature signs previously attached signatures

• S-BGP can validate– AS path indicates the order ASes were traversed– No intermediate ASes were added or removed

S-BGP Deployment Challenges• Complete, accurate registries– E.g., of prefix ownership

• Public Key Infrastructure– To know the public key for any given AS

• Cryptographic operations– E.g., digital signatures on BGP messages

• Need to perform operations quickly– To avoid delaying response to routing changes

• Difficulty of incremental deployment– Hard to have a “flag day” to deploy S-BGP

S-BGP

• Prevents many threats– Prefix hijacking– Route modification

• But not others– Collusion: two ASes claiming to have an edge– Policy violation: distributing a route from one

provider to another– Data-plane attacks: announcing one path but using

another– Resource exhaustion: announcing too many routes

Anomaly-Detection Schemes• Monitoring BGP update messages

– Use past history as an implicit registry– E.g., AS that announces each address block– E.g., AS-level edges and paths

• Out-of-band detection mechanism– Generate reports and alerts– Internet Alert Registry: http://iar.cs.unm.edu/– Prefix Hijack Alert System: http://phas.netsec.colostate.edu/

• Soft response to suspicious routes– Prefer routes that agree with the past– Delay adoption of unfamiliar routes when possible– Some (e.g., misconfiguration) will disappear on their own

Anomaly-Detection Schemes

• Risk of false positives– Temporarily (?) avoiding legitimate routes

• Risk of false negatives– Possibly vulnerable to a smart adversary

• Can detect some paths S-BGP cannot– E.g., announcing from one provider to another

• Does not prevent all attacks– Does not prevent collusion or data-plane attacks

• More amenable to incremental deployment

Discussion

Security Goals• What kind of attacks should we withstand?– Misconfiguration? – Control-plane adversary?– Colluding adversaries?– Data-plane adversaries?

• What solution would we want, from scratch?– S-BGP?– Data-plane path verification?– Multipath routing?

• What kind of solution can be deployed?– S-BGP? Anomaly detection? Multipath routing?

Conclusions

• BGP is highly vulnerable– Based on trust, even of ASes many hops away

• BGP security is a serious problem– Blackholing, snooping, impersonating, spamming

• Defining the threat is challenging, too– Control-plane validation or much, much more?

• Incremental deployment is a real challenge– Bootstrapping a PKI (though this has improved)

• Still a very active area of research