1 / 11

Working Group 6: Secure BGP Deployment

Communications Security, Reliability and Interoperability Council. CSR C. Working Group 6: Secure BGP Deployment. September 12, 2012 Andy Ogielski, Renesys Jennifer Rexford, Princeton U. WG 6 Co-Chairs. WG 6: Mission Statement.

takara
Télécharger la présentation

Working Group 6: Secure BGP Deployment

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. Communications Security, Reliability and Interoperability Council CSR C Working Group 6: Secure BGP Deployment September 12, 2012 Andy Ogielski, Renesys Jennifer Rexford, Princeton U. WG 6 Co-Chairs

  2. WG 6: Mission Statement • Short description: The Border Gateway Protocol (BGP) controls inter-domain packet traffic routing on the entire global Internet. BGP relies on trust among operators of gateway routers to ensure the integrity of the Internet routing infrastructure. Over the years, this trust has been compromised on a number of occasions, both accidentally and maliciously, revealing fundamental weaknesses of this critical infrastructure. This Working Group willrecommend the framework for industry regarding incremental adoption of secure routing procedures and protocols based on existing work in industry and research. The framework will include specific technical procedures and protocols. The framework will be proposed in a way suitable for opt-in by large Internet Service Providers (ISPs) in order to create incentives for a wider scale, incremental ISP deployment of secure BGP protocols and practices in a market-driven, cost-effective manner. • Duration: August 2011 – March 2013 2

  3. WG 6 – Participants

  4. Interdomain Routing • Interdomain routing isfundamental for operation of the Internet (the “Inter” in Internet) • BGP protocol is simple • BGP router may relay messages to neighbors about routes • Every route is constructed hop-by-hop • BGP policy is complex • Local policies for accepting and propagating routes • This is good: Great flexibility to support business objectives • This is bad: Vulnerability to propagating false routes 4

  5. Ground Truth Today • Security relies on establishing “ground truth” • E.g., Autonomous Systems (ASes) that can announce each IP address block (IP prefix) • Best common practices • Whitelisting of prefixes on customer sessions • Information from Internet Routing Registries • Incomplete, inaccurate IRR data • Lack of globally unique, meaningful names • Lack of enforcement of authorization model • No expiration of records 5

  6. Resource Public Key Infrastructure (RPKI) • Hierarchy of certificate authorities • Mapping directly on IP address allocation hierarchy • Validate authority to use IP number resources • Not the identity of individuals or organizations • E.g., Route Origin Authorization for IP address blocks • Origin validation on BGP update messages • Valid: origin AS matches a valid ROA • Invalid: IP prefix has valid ROAs, but do not match • Unknown: IP prefix is not described in any valid ROA • To generate alarm, de-preference, or filter the route 6

  7. Risks Inherent in Using the RPKI • Misconfiguration • Mistakes in entering data, letting certificates expire,… • Punitive revocation • Certificate authorities overwrite or revoke certificates • Impact depends on how other ASes use the data • Collateral damage on other prefixes, or surgical strikes • Important of monitoring • Tools to identify possible configuration mistakes • Monitoring of overwriting and revoking of certificates • Detect and diagnose errors and possible attacks 7

  8. Recommendations • Desirability of number resource certification • Need authoritative, accurate, and verifiable info • Ensure registries are public, complete, and accurate • Begin certifying numbered resources • Tools to predict impact of RPKI submissions • Compare new information to BGP routing tables • Flag potential problems before they occur • Cautious, staged deployment strategies • Part of vetting when configuring customer session • Analysis of BGP-learned routes to detect anomalies • An input to the construction of prefix filters 8

  9. Recommendations (Continued) • Transparency of RPKI processes • Organizational identity is useful for detecting and remediating problems • RPKI certificates need not disclose organization • Yet, can include information about point of contact • Monitoring changes in the RPKI data • Build confidence in RPKI’s accuracy and stability • Log and audit to track progress, detect mistakes, and flag suspicious manipulations • Publish real-time data publicly • Further investigation of RPKI risks • Continued study of technical and policy risks 9

  10. Conclusions • Interdomain routing is vulnerable • Easy to propagate invalid routing information • Routing registries are incomplete and inaccurate • Resource certification can improve security • Stronger notion of “ground truth” • Basis for detecting and avoiding invalid routes • Recommendations • Certify number resources • Preserve organizational information • Apply tools and monitoring for RPKI changes • Staged deployment for using the RPKI data 10

  11. Future Work • Monitoring • BGP routes: detecting and diagnosing anomalies • RPKI data: detecting mistakes and manipulations • RPKI risks • Explore risks of targeted manipulation of RPKI • Identify approaches for mitigating risks • Deployment incentives • Analyze deployment benefits and costs • Identify guidelines for incremental deployment 11

More Related