1 / 10

Secure Origin BGP: What is (and isn't) in a name?

Learn about Secure Origin BGP (s-BGP), a system created by Cisco engineers as a lightweight alternative to BGP security. Discover its certificate types, changes to BGP, processing updates, and other benefits.

tomeka
Download Presentation

Secure Origin BGP: What is (and isn't) in a name?

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. Secure Origin BGP: What is (and isn't) in a name? Dan WendlandtPrinceton Routing Security Reading Group

  2. History • Created by Cisco engineers as a light-weight (computation and PKI) alternative to s-bgp. • Originally only secured “origin” of routes, but topology information added later for additional security. • Goal: A more real-world and usable system

  3. Certificate Types • Entity Cert: Organization -> ASN, Public Key • Policy Cert: ASN -> Neighbors, Security Parameters • Authorization Cert: ASN -> Network Prefixes, meta-data

  4. Changes to BGP • New “Security” Message (ie: updates are not used for security data). • Ability to “ask” neighbor for security certificates. • Authorization, Entity Certificate and Path Database

  5. “Web of Trust” for Public Keys • Root of Entity Cert trust hierarchy is not necessarily ICANN, but instead a group of “well-known entities”. It could also be private entity like Verisign, or a collection of tier-1 ISPs. • Ambiguity with respect to Auth Certs (need ICANN hierarchy or not?)

  6. Origin Auth + Path “Plausibility” • Originating AS's are validated much like s-BGP • AS-Path's are checked plausibility against topology database, not attested with cryptography • Path Check bits in Policy Cert. • Security Preference allows for “fuzzy” match.

  7. Processing Updates • Find Auth Cert for this prefix in local database. • If route is originated by an ASN in the cert, continue, else discard • If path-check bit is set, check that each hop in the AS-PATH exists in both directions in the path database (alternately, just check 1st hop). • Set “security preference” and install in RIB.

  8. Other Benefits • Policy Flexibility (let's you split an update, advertising some prefixes, but not others) • Less verification load vs path attestation (still need crypto hardware though?). • Robustness to gaps in deployment? • Ability to “outsource” certificate validation to servers, provide routers with databases. • Include policy information in certificates (AS X may not transit this route, etc)

  9. Dirty “Little” Issues • Peer links advertised (confidentiality)? • Aggregation • Determining extent of trust propagation within web-of-trust. • Difference between path plausibility and path attestation? • Where is database stored? Memory Issues in keeping AS-level topology? • Incremental Deployment needs multi-hop BGP sessions to participants.

  10. References • ftp://ftp-eng.cisco.com/sobgp/index.html • Extensions to BGP to Support Secure Origin BGP: draft-ng-sobpg-bgp-extensions-01.txt • soBGP Architecture & Deployment: draft-white-sobgp-architecture-01.txt

More Related