Cardinal Vs Ordinal Optimization: The Reality Police

1
Cardinal Vs Ordinal OptimizationThe Reality
Police

• Vijay Gill
• ltvgill_at_mfnx.netgt
• Metromedia Fiber Network

2
The Problem

• What is the problem were trying to solve?
• Why do we care?

3
Why

• Instability caused by resource exhaustion
• test cef
• Prefix Hijacking
• Malicious or otherwise
• 7007

4
A Stability Argument

• Many prefixes/paths consume resources
• Convergence times rise
• Thrashing
• Instability
• complaining customers

5
Scaled RIB/FIB Memory Usage
6
Peer Updates
7
Prefix Hijacking

• Malicious users inject prefixes with fake
  NEXT_HOPS
• Redirect traffic

8
This Means

• Protection Mechanisms
• Protect against malicious hijacking
• Protect against resource consumption overload

9
Cardinal Vs Ordinal Optimization

• More important to quickly narrow the search for
  an optimal solution to a good enough subset
  than to calculate the perfect solution
• Ordinal (which is better) before Cardinal (value
  of optimum)
• Ballpark estimate
• Historical Internet Vs the Telco approach

Based on work done by Yu-Chi Ho
10
Soften Requirements

• Softening strict requirement of optimality can
  make problems tractable

Getting the best decision for certain
Cost 1m
Getting a decision within the top 5 With
probability 0.99
Cost 1m/x
In real life, we often settle for such a tradeoff
with x100 to 10,000
11
What did that mean?

• Dense filtering for customers
• Coarse Filtering between Peers

Dense Filtering
Coarse Filtering
12
Agent Provocateur

• What we need
• An authoritative statement for each prefix of
  which AS is allowed to originate injection
• Not an arbitrarily complex mish-mash of
  woulda-coulda-shoulda-how-mighta policy stuff

we don't need to boil the ocean - all we want is
a poached fish
13
Continued

• Keep track of the AS allowed to control injection
  is an extension of the book keeping already done
  by the registries
• Neutral Third Party
• Publishing that information would allow people to
  filter at the edges to a very significant degree
• No dramatic increase in systemic brittleness
  produced by relying on cumulative grot introduced
  by the IRR model.

14
Recap

• Dense filtering of customers and untrusted peers
  prevents severe tire damage.
• Filtering Customers - Soft-state model
• IRR Hard-state
• No incentive to clean grot out of IRR
• For the rest.

15
From Mike O'Dell ltmo_at_UU.NETgt Subject Re DOS
attack tracking Date Tue, 09 Feb 1999 163201
-0500 just stop the IRR is bankrupt
Reprinted with permission
16
Ordinal Policy Implementation
edit protocols bgp group group-name
neighbor address prefix-limit maximum
number teardown ltpercentagegt neighbor
ip-address peer-group-name maximum-prefix
maximum threshold
17
Monitoring

• MFN monitors prefixes received grouped by peering
  session
• Surprisingly stable, once pathologies are removed
  (dense filtering)
• 20 threshold for teardown, the vast majority
  exhibit lt5 change in announced

18
Need

• Huge configuration space
• ACL 155 8k lines long
• Crashed router on write
• Better Code
• Nov 1998 meltdown caused by my customer
• Fully filtered. Fence-post AS-PATH error.
• Registries to Publish AS/Allowed Prefix
  information

19
(No Transcript)
20
Thank You

• Hate mail and questions to
• vgill_at_mfnx.net

No cable company Ethernet ports were tapped in
the making of this presentation.