Pretty Good BGP

Josh Karlin

8/15/2006

Towards Securing BGP

• Authenticate Origins– Prefix hijacks– Sub-prefix hijacks– Often caused by router misconfiguration

• Authenticate AS Paths– AS-in-middle attacks

• Authenticate Autonomous Systems– AS impersonation attacks (use IPsec)

The Crypto Approach (sBGP/soBGP)

• Requires complete (and updated) routing registries

• Unknown effectiveness of partial deployment

• Complicated (protocol and bureaucracy)

• Cost?

• Secures the control plane, what about data?

Anomaly Detection

• Lots of false positives

• Varying degrees of complexity

• How do you perform verification?

• A “hack” as opposed to an elegantly engineered design

• Cost?

• Ineffective! Doesn’t stop an attack from spreading.

Pretty Good BGP

• Main Ideas: – Lower the local preference of suspicious routes– Only inform the operators involved with the hijacked

route of the problem. Nobody else can authoritatively answer.

• Benefits– Network has a chance to stop an attack before it

spreads– Accidental short-term routes do no harm– Low operator overhead– No loss in reachability– Adaptive– Simple

I have a hammer!

• Authenticate Origins– Prefix hijack– Sub-prefix hijack– These can be caused by misconfigurations

• Authenticate Paths– AS-In-Middle Attack

• Authenticate AS– Fake AS Number (use IPsec)

Identifying Prefix Hijacks

• What is a prefix hijack?– A prefix hijack occurs when AS originates a

prefix that it does not own and is originated elsewhere.

• How can we spot a prefix hijack?– Map the origin ASs of each prefix. If a new

origin appears for a prefix, it could be a prefix hijack

Identifying Prefix Hijacks (2)

• How does PGBGP spot a prefix hijack?– Keep track of the origin ASs of each prefix

that have been seen in the RIB and updates over the last 10 days.

– If an update contains a new origin AS for a prefix, it’s potentially a prefix hijack. Label it as suspicious.

– UNLESS: A recently seen origin AS of the prefix is on the AS Path of the update. Then it’s clean.

Stopping Prefix Hijacks

• How does PGBGP stop a prefix hijack?– Lower the local preference of suspicious

routes for 24 hours.– After 24 hours, promote the suspicious route

to its normal preference, and add it to the history of known origin ASs for the prefix if it’s still in the RIB.

Stopping Prefix Hijacks (2)

• Did it actually stop anything?– For a single-homed stub AS, this does

nothing.– For a multi-homed AS, potentially other

providers offer a non-suspicious route. With a solution like ACR, there are lots of routes to choose from.

– If the hijacker is on your AS path, packets will by default route to the hijacker. That’s a data plane issue.

Example Prefix Hijack

Prefix Hijack with PGBGP

PGBGP on the ‘Net

• Will it slow down basic routing procedures?– Announcement of backup routes– Change of provider– Super-fast load-balancing changes?

• Will it work?• When it does slow things down, how slow

are we talking about? – The diameter of the net in the worst case –

roughly 6 days

PGBGP on the ‘Net(Basic Routing Procedures)

• Backup routes will not be affected if the original origin AS is withdrawn or the provider uses a prepended AS path to announce their backup link

• Change of provider will occur as soon as the old provider withdraws the prefix. Or, you can wait a few days for testing.

• Fast load balancing works if you use prepended paths

PGBGP on the ‘Net(Will it Work?)

Identifying Sub-Prefix Hijacks

• What is a sub-prefix hijack?– A sub-prefix hijack occurs when AS originates

a prefix that it does not own and the space is originated elsewhere and its space is wholly contained within another announced prefix block

• How can we spot a sub-prefix hijack?– Keep a list of all recently seen prefixes. If a

new prefix appears in an update, it could be a sub-prefix hijack

Identifying Sub-Prefix Hijacks (2)

• How does PGBGP spot a sub-prefix hijack?– Keep track of each prefix that has been seen

in the RIB and updates over the last 10 days.– If an update contains a new prefix, and it’s a

sub-prefix of a recently seen prefix it’s potentially a sub-prefix hijack. Label it as suspicious.

– UNLESS: The supernet’s origin AS is on the AS Path of the update. Then it’s clean.

Stopping Sub-Prefix Hijacks

• How does PGBGP stop a sub-prefix hijack?– Can’t lower the local preference– Route to the super net instead– This requires an assumption:

• The supernet origin AS will forward the data on to the legitimate origin AS of the subnet

– After 24 hours, route to the sub-prefix and add it to the history of known prefixes if it’s still in the RIB.

Stopping Sub-Prefix Hijacks (2)

• Did it actually stop anything?– For a stub AS, this does nothing as the

provider will deflect the route to the sub-prefix– For a multi-homed AS, potentially other

providers rejected the sub-prefix, use them if possible.

– If the hijacker is on your AS path, packets will by default route to the hijacker. Nothing we can do about that. That’s a data plane issue.

Example Sub-Prefix Hijack

Example Sub-Prefix Hijack with PGBGP

PGBGP on the ‘Net

• Will it slow down basic routing procedures?– Can I still sub-prefix hijack myself?– Change of provider– Super-fast load-balancing changes?

• Will it work?

PGBGP on the ‘Net(Basic Routing Procedures)

• Sub-prefix hijacking yourself is fine as your AS is on the path of the sub-prefix hijack.

• Change of provider requires the following protocol: 1) Have the old provider announce the sub-prefix. 2) Have the new provider announce the sub-prefix. 3) Have the old provider drop the sub-prefix. Or, you can wait a few days for testing.

• Fast load balancing works so long as your AS is on the AS path

PGBGP on the ‘Net(Will it Work?)

The Internet Alert Registry

• This is where operators opt-in to find out about alerts that pertain to their own AS numbers.

• A website which collects feeds from many RIPE viewpoints and runs the PGBGP algorithm on them.

• The origin of the suspicious route is found and the alert is emailed to the operator if they opt in. Likewise, the trusted origin of the prefix is also emailed.

• Only 1 email on average per day for Tier-1 ASs!

IAR Continued

• The IAR is a useful mechanism on its own. Currently 26 subscribers.

• If IAR becomes popular, moving to PGBGP requires no additional daily overhead.

• Mohit Lad’s Prefix Hijack Alert System is very similar. The more the merrier!

• Maybe we can embarrass the operators into good behavior!

Interesting Hijacks

• Here are some hijacks spotted by the IAR, some of which get posted to NANOG:

– Aug 14th 2006 – AS 8437 announced the Internet’s dark space

– June 7th 2006 – AS 23520 announced 1/8,2/8,3/8,4/8,5/8,7/8,8/8,12/8 carried by Sprint and UUNET

– February 26th 2006 – TTNET announced 4/8, 8/8, and 12/8

I still have my hammer! (Future Work)

• Authenticate Origins– Prefix hijack– Sub-prefix hijack– These can be caused by misconfigurations

• Authenticate Paths– AS-in-Middle Attack

• Authenticate AS– Fake AS Number (use IPsec)

Squashing the AS-in-the-Middle

• AS-in-Middle attack: When an AS prepends an illegitimate route to the proper origin of a prefix before announcing it.– E.g. – The path should be: 1 2 3 4 5 6– But 3 instead announces: 1 2 3 6

Squashing the AS-in-the-Middle (2)

• Keep track of each edge seen in the RIB and updates over the last 10 days

• If a new edge is seen in an update, label it as suspicious and depreference it.

• This causes about 10 times more alerts than prefix/sub-prefix alerts. Too many for operators? Probably.

Conclusions

• PGBGP– Is simple– Protects each AS that deploys it as they

deploy it– Is low overhead– Offers significant protection

– Provides a solution for automated response in anomaly detection and reduces operator verification overhead with the IAR.

Bulletproofing PGBGP?(Discussion)

• Given:– The operators review their IAR messages and we

have full deployment – Which means the history data is clean– PGBGP is AS-in-middle resistant (in the works)– ASs use IPsec to secure their border links (optional)

• Then:– Guarantees?

Incorporating Registries/Crypto?(Discussion)

• If an AS could register their information then PGBGP could check against the registry.

• This could also be done by some crypto scheme.

IAR Messy Details (Discussion)

• What if I miss some updates?– This could cause the PGBGP algorithm to

believe some routes are still in the RIB that actually aren’t

– Perhaps do a RIB sync every now and then? How often?

• Should I order the updates as they arrive?

• Introduction– Why hasn’t a security solution to the BGP problem been deployed?

• cost / complexity / Define the extra features we would like a secure solution to have (include incremental effectiveness, simplicity, etc..)

• Threat Model– Show examples both types of hijacks and as-in-middle attacks– Talk about what can be done with the data– Talk about how the data plane can’t be secured through the control plane– Back to the features we would like to have, PGBGP focuses on origination (misconfigs),

future work focuses on as-in-middle, ipsec/md5 handles the rest• PGBGP

– How to identify and stop prefix hijacks– How to identify and stop sub-prefix hijacks– When to allow it (if the legit origin is on the path)– History length / Delay length

• IAR– Complications --- discussion – do I want to put in time order? What do I do about possible

lost updates?• Future Work

– How to deal w/ AS-in-middle– With some assumptions, and AS-in-middle taken care of, then we can identify each attack,

and stop them– Our assumptions are quite fair– Deployment scenarios