Pretty Good BGP

1
Pretty Good BGP

• Josh Karlin
• 8/15/2006

2
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)

3
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?

4
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! Doesnt stop an attack from
  spreading.

5
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

6
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)

7
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

8
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, its 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 its clean.

9
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 its still
  in the RIB.

10
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. Thats a data
  plane issue.

11
Example Prefix Hijack
12
Prefix Hijack with PGBGP
13
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

14
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

15
PGBGP on the Net(Will it Work?)
16
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

17
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 its a
  sub-prefix of a recently seen prefix its
  potentially a sub-prefix hijack. Label it as
  suspicious.
• UNLESS The supernets origin AS is on the AS
  Path of the update. Then its clean.

18
Stopping Sub-Prefix Hijacks

• How does PGBGP stop a sub-prefix hijack?
• Cant 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 its still
  in the RIB.

19
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. Thats a data plane issue.

20
Example Sub-Prefix Hijack
21
Example Sub-Prefix Hijack with PGBGP
22
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?

23
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

24
PGBGP on the Net(Will it Work?)
25
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!

26
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 Lads Prefix Hijack Alert System is very
  similar. The more the merrier!
• Maybe we can embarrass the operators into good
  behavior!

27
Interesting Hijacks

• Here are some hijacks spotted by the IAR, some of
  which get posted to NANOG
• Aug 14th 2006 AS 8437 announced the Internets
  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

28
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)

29
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

30
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.

31
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.

32
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?

33
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.

34
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
  arent
• Perhaps do a RIB sync every now and then? How
  often?
• Should I order the updates as they arrive?

35

• Introduction
• Why hasnt 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 cant 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