1 / 20

Cardinal Vs Ordinal Optimization: The Reality Police

Cardinal Vs Ordinal Optimization: The Reality Police. Vijay 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.

bryga
Download Presentation

Cardinal Vs Ordinal Optimization: The Reality Police

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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

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

More Related