Cardinal Vs Ordinal Optimization:

The Reality PoliceVijay Gill

<vgill@mfnx.net>Metromedia Fiber Network

The Problem

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

Why

• Instability caused by resource exhaustion– test cef

• Prefix Hijacking– Malicious or otherwise

• 7007

A Stability Argument

• Many prefixes/paths consume resources• Convergence times rise

– Thrashing• Instability

– complaining customers

Scaled RIB/FIB Memory UsageRoutes Vs Memory Usage

0%

10%

20%

30%

40%

50%

60%

70%

80%

90%

100%

0 50000 100000 150000 200000 250000 300000 350000 400000 450000

VIP Memory Used RSP Memory Usage Poly. (VIP Memory Used) Poly. (RSP Memory Usage)

Peer UpdatesTime To Converge

030 35 50

100

195

360

550

810

1114

0

200

400

600

800

1,000

1,200

0 20000 40000 60000 80000 100000 120000 140000 160000 180000 200000

Routes

Seco

nds

Peer Update Poly. (Peer Update)

Prefix Hijacking

• Malicious users inject prefixes with fake NEXT_HOPS

• Redirect traffic

This Means

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

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

Soften Requirements

• Softening strict requirement of optimality can make problems tractable

Cost = $1m

Cost = $1m/x

Getting the best decision for certain

Getting a decision within the top 5%With probability = 0.99

In real life, we often settle for such a tradeoff with x=100 to 10,000

What did that mean?

• Dense filtering for customers• Coarse Filtering between Peers

Dense FilteringCoarse Filtering

• 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

Agent Provocateur

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

Continued

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

From: Mike O'Dell <mo@UU.NET>*

Subject: Re: DOS attack tracking

Date: Tue, 09 Feb 1999 16:32:01 -0500

just stop

the IRR is bankrupt

*Reprinted with permission

Ordinal Policy Implementation[edit protocols bgp group group-name neighbor address

prefix-limit { maximum number; teardown <percentage>;}

neighbor {ip-address | peer-group-name} maximum-prefix maximum [threshold]

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 <5% change in # announced

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

Thank You*

Hate mail and questions to vgill@mfnx.net

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