Cardinal Vs Ordinal Optimization: The Reality Police

1. Cardinal Vs Ordinal Optimization:The Reality Police Vijay Gill <vgill@mfnx.net> Metromedia Fiber Network

2. The Problem • What is the problem we’re 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 x=100 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 <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

16. 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]

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 <5% 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

20. Thank You* Hate mail and questions to vgill@mfnx.net *No cable company Ethernet ports were tapped in the making of this presentation.