1 / 25

BGPSEC : A BGP Extension to Support AS-Path Validation

BGPSEC : A BGP Extension to Support AS-Path Validation. Matt Lepinski BBN Technologies. What is BGPSEC?. Proposal for securing the AS-PATH attribute Extension to BGP that is negotiated as a new capability (RFC 5492)

wayne-campbell
Download Presentation

BGPSEC : A BGP Extension to Support AS-Path Validation

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. BGPSEC :A BGP Extension to Support AS-Path Validation Matt Lepinski BBN Technologies

  2. What is BGPSEC? • Proposal for securing the AS-PATH attribute • Extension to BGP that is negotiated as a new capability (RFC 5492) • An optional path attribute that contains a list of cryptographic signatures that protect the AS-PATH

  3. Goals and Non-Goals • Goal: To ensure the integrity of the NRLI and AS-PATH attribute in a BGP Update Example: an update X.Y/16 with AS-PATH: AS 1, AS 2, AS 3 Upon Receipt of this update, AS 4 is assured that • AS 1 originated a route for X.Y/16 and sent it to AS 2 • AS 2 received this route from AS 1 and sent it to AS 3 • AS 3 received this route from AS 2 and sent it to AS 4 • Non-Goal : Anything having to do with the data path!

  4. The -00 drafts • Please read: • draft-lepinski-bgpsec-overview-00 • draft-lepinski-bgpsec-protocol-00 • A first cut at specifying an incrementally deployable BGP extension for securing the AS-Path • Focus: simple, understandable protocol with correct semantics • No attempts whatsoever were made to optimize computation time, storage space, network traffic, etc • For List Discussion: Do these documents describe an approach that the SIDR WG wants to pursue?

  5. Negotiating BGPSEC • BGPSEC only between consenting routers • BGPSEC capability contains • Send bit == “I am willing to send the BGPSEC attribute” • Receive bit == “I am willing to receive the attribute” • AFI : IPv4 and IPv6 negotiated separately • Adding signatures can make update messages big • In order to receive BGPSEC you probably need to support updates larger than 4096 bytes • See: draft-ymbk-bgp-extended-messages • Note: Permit negotiation of simplex BGPSEC because sending is much easier than receiving

  6. Signing at Provider Boundaries • Protects only interdomain routing, not iBGP • Signatures are added when a route announcement leaves an AS • However, iBGP needs to carry BGPSEC signatures AS 2 AS 1 eBGP AS 0 Signature added iBGP

  7. AS3130 rtr-00 AS3130 rtr-00 AS 123 rtr-00 AS3130 rtr-00 AS3130 rtr-00 192.0.2.0/24 AS 123, AS 456 AS 123 Public Key Public Key End-Entity Certificates for Routers • Extend the RPKI to include new end-entity certs • Issued under the CA certificate for an AS • Private keys held by the AS’s edge routers • Can do one key per router, or share common keys CA CA ISP AS Cert Router EE Cert Router EE Cert Router EE Cert Router EE Cert Router EE Cert Public Key Public Key Public Key Public Key Public Key

  8. BGPSEC and the RPKI RPKI Repository RPKI Repository RPKI Repository • To send BGPSEC, a router needs only its private key • To validate BGPSEC, a router needs • (SKI, Public Key, AS) triples from valid certs • Origin validation data Validating Cache Edge Router Edge Router

  9. What Data is Signed (1/2) New Optional Path Attribute • The Signature of AS 0 includes the AS number of the peer to whom the update is being sent • The SKI is used by the recipient to look-up the public key needed to verify the signature Hash Signed (Te) by Router Key AS0-Rtr-xx Time NLRI AS0 SKI 0 AS1 Sig0 Signed Forward Reference

  10. What Data is Signed (2/2) New Path Transitive Attribute New Optional Path Attribute • The signature of AS 1 covers the signature of AS 0 plus new fields added by AS 1 • When AS 2 receives the update message it contains signatures from both AS 1 and AS 0 Hash Signed (Te) by Router Key AS0.Rtr-xxz Hash Signed by Router Key AS1-Rtr-yy Time NLRI AS0 SKI 0 AS1 Sig0 Sig1 AS1 SKI 1 AS2 Signed Forward Reference

  11. To see such signatures are useful … … recall the threats presentation

  12. Kapela/Pilosov Attack (1/2) AS 125 wants to be a MITM for traffic to 129.7/16 129.7/16: (120) 129.7/16: (123, 120) AS 120 AS 123 AS 125 129.7/16: (120) 129.7/16: (124, 122, 123, 120) AS 124 AS 121 AS 122 129.7/16: (121, 120) 129.7/16: (122, 123, 120)

  13. Kapela/Pilosov Attack (2/2) AS 125 forwards hijacked traffic to AS 120 via this path 129.7/16: (123, 120) 129.7/16: (120) AS 120 AS 123 AS 125 129.7/16: (120) 129.7/17: (125, 123, 120) 129.7/16: (123, 120) AS 124 AS 121 AS 122 129.7/17: (122, 124, 125, 123, 120) 129.7/17: (124, 125, 123, 120)

  14. Note on Signing the NLRI • The signature of the origin AS covers the NLRI in the update • Therefore, changing the NLRI breaks the signature • This is important so an adversary does not change a received prefix (e.g., lengthen it) • BGPSEC does not currently support multiple prefixes in the NLRI of a single update • To avoid problems if a later AS only advertised one of a set of received prefixes • Possible area to explore future optimizations

  15. But changing the NLRI is not the only way to attract traffic …

  16. Dropping an AS AS 120 has a ROA for 129.7/16 AS 122 wants to be a MITM for traffic to 129.7/16 129.7/16: (120) 129.7/16: (123, 120) AS 120 AS 123 AS 125 129.7/16: (120) 129.7/16: (124, 122, 120) 129.7/16: (123, 120) AS 124 AS 121 AS 122 drops an AS to make its path appear shorter, to attract 129.7/16 traffic from AS 124 AS 122 129.7/16: (122, 120) 129.7/16: (121, 120)

  17. What Data is Signed New Path Transitive Attribute New Optional Path Attribute Hash Signed (Te) by Router Key AS0.Rtr-xxz Hash Signed by Router Key AS1-Rtr-yy Time NLRI AS0 SKI 0 AS1 Sig0 Sig1 AS1 SKI 1 AS2 Signed Forward Reference

  18. BGPSEC_Path_Signatures Attribute Expire Time • Note: Red block of signatures is optional and is used only to facilitate algorithm transition • Expire Time? … let’s recall the threats presentation … Algorithm ID Algorithm ID SKI of 3rd AS SKI of 3rd AS Signature of 2rd AS Signature of 2rd AS SKI of 2nd AS SKI of 2nd AS Signature of 2nd AS Signature of 2nd AS SKI of Origin AS SKI of Origin AS Signature of Origin AS Signature of Origin AS

  19. Hijack via Update Replay (1/2) AS 120 has a ROA for 129.7/16 129.7/16: (120) 129.7/16: (123, 120) AS 120 AS 123 AS 125 129.7/16: (120) 129.7/16: (124, 122, 123, 120) 129.7/16: (123, 120) AS 124 AS 121 AS 122 129.7/16: (121, 120) 129.7/16: (122, 123, 120)

  20. Hijack via Update Replay (2/2) AS 120 has a ROA for 129.7/16 129.7/16: (120) 129.7/16: (123, 120) AS 120 AS 123 AS 125 129.7/16: (120) 129.7/16: (122, 123, 120) AS 124 AS 121 AS 122 no longer has a path to 120, but it can replay an old update AS 122 129.7/16: (122, 123, 120)

  21. Expire Time and Beaconing • Origin of a route announcement selects the Expire Time • Expire Time limits the window of vulnerability to replay attacks • New prefix announcement needs to be made well before the Expire Time is reached, AKA beaconing • Natural trade-off: • Short expire time means stronger replay protection • Longer expire time means less BGP traffic

  22. BGPSEC Validation • Recipient validates as follows: • Check the expire time • Perform origin validation • Fetch public keys and verify the AS in AS-PATH matches the AS from the router end-entity certificate • Verify the signatures <=== Crypto • Validation need only be done upon receiving a signed update from external peer • What you do with the validation state is completely up to your local policy!!

  23. Final Notes • Incrementally deployable • An AS can use BGPSEC for only some prefixes or only at certain edge routers • Protects only the AS-PATH attribute and the NLRI • Consistent with the current SIDR charter • Consistent with our current understanding of threats and desired BGP semantics • Cryptographic algorithm agility • Specification outlines a procedure for changing algorithms • As with the RPKI, algorithm transitions are expensive and global

  24. Co-Authors • Rob Austein, ISC • Steven Bellovin, Columbia Univ • Rany Bush, IIJ • Russ Housley, Vigilsec • Stephen Kent, BBN • Warren Kumari, Google • Doug Montgomery, NIST • KotikalapudiSriram, NIST • Samuel Weiler, Sparta

  25. Valuable Review and Contribution • Luke Berndt • Sharon Goldberg • Ed Kern • Chris Marrow • Doug Maughan • PradoshMohapatra • Russ Mundy • Sandy Murphy • Keyur Patel • Mark Reynolds • Heather Schiller • Jason Schiller • John Scudder • David Ward • Ruediger Volk • Your Name Here!

More Related