1 / 10

Defining the Scope of BGP

This article discusses the scope of BGP and its implications for software extensibility, misconfiguration, and information leakage. It proposes potential mitigations for these concerns and raises the question of whether current solutions adequately address the issues.

ernestinee
Télécharger la présentation

Defining the Scope of BGP

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. Defining the Scope of BGP Ron Bonica July 17, 2003

  2. Background • Routers support many applications that require synchronization with peers regarding specific data structures • Examples • BGP peers synchronized adj-RIBs-in and adj-RIBs-out • Proposals for automated synchronization of tunnel configuration data between tunnel endpoints

  3. Problem Statement • BGP could support all of these applications • BGP contains a well-understood and widely-deployed mechanism for data distribution • Concern regarding BGP scope creep • BGP is essential to the well being of the Internet • Handle with extreme care

  4. Specific Concerns • Software Extensibility • The more we add to BGP, the buggier implementations become • Misconfiguration • As BGP functionality increases, the odds of misconfiguration increase • Possibility of leaking arbitrary information • Possibility of misinterpreting leaked information

  5. Mitigation of Specific Concerns • Software Extensibility • Many BGP implementations are modular • Data transfer functions are separate from IDR functions • AFI specifies data structures to be synchronized • Specific modules support specific functions • Misconfiguration • BGP peers can protect themselves from neighbor misbehavior with policy

  6. Second Order Concerns • The Big Bug • The wrong AFI get associated with advertisements • Incomprehensibility • BGP becomes so large that no one individual understands it all • Others?

  7. Mitigation of Second Order Concerns • The Big Bug • Testing • BGP peers protect themselves with policy • Incomprehensibility • Individuals understand an overview and specific modules • Overview and modules are documented separately

  8. Options • Restrict BGP to distribution of L3 NLRI • Clone BGP one or more times for other applications • Abstract BGP data transfer component to be used by other applications • Allow BGP to distribute other types of information • Mitigate concerns as described in previous slides

  9. Conclusion (or lack thereof) • Neither Solution is clearly correct • Cloned code = cloned bugs + increased software maintenance cost • Are we sure that we will mitigate the concerns • We are on shaky ground • Extensibility concerns and mitigation are about software engineering • IETF does not standardize software engineering practice

  10. Next Steps • Listen to vendors • Are they worried about extensibility • Listen to operators • Are they worried about misconfiguration

More Related