BGP SecurityOverview and Options

Agenda• Origin Authentication

• BGPSEC Path Validation

• Graph Based Path Validation

Origin Authenticationhttps://datatracker.ietf.org/doc/rfc6483/

AS65003

AS65002

AS65000

Origin Authentication• Who really owns 192.0.2.0/24? BGP assumes these two

advertisements reach the same destination

However, one could be a spoofed source or a hijack

How can this be resolved?

192.0.2.0/24 192.0.2.0/24

Origin Authentication• The RIR authorizes

AS65002 to originate 192.0.2.0/24

• AS65002 creates a Resource Certificate (RC) signed with a private key and any additional parameters Can be a longer length, etc. Longest prefix within this

block

• AS65002 places this in the RPKI database

• AS65000 can verify the origin AS against the RPKI database

RIR (Trust Anchor)

Route Origin Authorization

(ROA)

AS65003

AS65002

AS65000

192.0.2.0/24 192.0.2.0/24Resource Certificate (RC)

Structural Issues• RPKI database is currently synchronized through rsync

• Can take days for the database to update/etc.

• There are concerns over the being able to “shut down” a business by taking their addresses off the ‘net

AS65003

AS65002

AS65000

Security Issues• AS65003 can simply advertise 192.0.2.0/24 with the AS Path [65002,65003]

• AS65000 will be none the wiser…

• To resolve this, path validation of some sort is needed

192.0.2.0/24 192.0.2.0/24

BGPSEC (S-BGP)https://datatracker.ietf.org/doc/draft-ietf-sidr-bgpsec-overview/

Operation• Certificate added as BGP

attribute Signature (hash created

using private key) Private key retrieval

information Valid lifetime Other information… Certificate is around 256

octets

• Exchange of certificates attributes is negotiated at initial peering

192.0.2.0/24

AS65

000

AS65

001

AS65

002

NLRI: 192.0.2.0/24Attributes: Communities, Certificate, etc.

NLRI: 192.0.2.0/24Attributes: Communities, Certificate, etc.

Operation• Receiving Speaker

Calculates hash based on retrieved public key for each AS in the AS Path

Compares calculated hash against hash carried in the certificate within the update

• Sending Speaker Adds a new certificate

containing the sending AS and receiving AS

Calculates a hash across any existing certificates and this new information

Inserts the certificate into the attributes

192.0.2.0/24

AS65

000

AS65

001

AS65

002

Signs across ([65000,65001], 192.0.2.0/24)

Validates signature using public key against([65000,65001], 192.0.2.0/24)

Signs across ([first hop signature, [65001,65002])

Validates using AS65000 public key for first hop signature, AS65001 public key for second hop signature

Performance• Database Size

Each NLRI must now carry 256 octets of new data per hop About 15x the current table size

• Convergence Time Attribute per NLRI means no packing (update compression)

15x longer transfer time for a full table

• Processing Each signature must be processed in each update I.E. – at the fourth hop, there will be four hashes to calculate per prefix

Replay & Timers• The Setup

AS5004 is advertising a set of routes through AS65003 and AS65002

All of these routes are signed properly, etc., so AS65000 considers them valid

• AS65004 terminates its contract AS65003 Assume this is not on “friendly”

terms AS65003 would like to harm

AS65004 in some way

AS65003

AS65002

AS65000

AS65004

Replay & Timers• How long can AS65003 continue to advertise AS65004’s routes?

• As long as the signature remains valid The timer in the signature

controls the amount of time AS65004 is vulnerable to a replay attack

AS65003

AS65002

AS65000

AS65004

Continue Advertising

Timers & Replay• Timers in updates…

Every route in the table must be refreshed within the timeout

If all AS’ set their timers to 24 hours, this is around 6 updates per second added to BGP – a lot of churn

• Choosing the Timer Shorter timers help you by reducing the replay window

But shorter timers hurt the ‘net by pushing processing onto “other people”

Tragedy of the Commons problem – no solution

Information Leaks• If AS65004 uses the same certificate to sign all outbound updates… How can this certificate be

transported to every eBGP speaker?

If a single eBGP speaker is compromised, the entire AS has been compromised

• How do we resolve this?

AS65003

AS65002

AS65000

AS65004

Same Certificate?

Information Leaks• To resolve this, BGPSEC assumes each eBGP speaker will have it’s own certificate The AS has a private/public key pair This is used to sign each eBGP speaker’s actual certificate

This is used to actually sign routing updates

• Problems The certificate database across which validate must take place is per eBGP speaker, not per AS – this is huge

Examining updates tells you not only who is peered, but where, with what routers, how many places, and who else shares those peering points

Route Leaks• How does AS65003 signal that AS65004 is not a transit AS? This is the route leaks problem

described in draft-ietf-grow-route-leak-problem-definition-01

• There has been some suggestion to include a “not transit” bit in the certificate signed by AS65003 This repeats functionality already

in communities – should we start replicating other functions as well?

AS65003

AS65002

AS65000

AS65004

Do not transit AS65004

Graph Alternatives

Concept• Each AS advertises what

other AS’ it is connected to Signed using a private key

(x.509)

• Characteristics Not granular to the NLRI level

(good and bad) AS Level semantics Only AS level changes are

reflected in the base advertisements

More detail may be included

• What could we do with this information?

AS65003

AS65002

AS65000

AS65004

Connected to AS65003Connected to AS65002

Connected to AS65000Connected to AS65004

Connected to AS65000Connected to AS65004

Connected to AS65003Connected to AS65002

No Graph (Quick and Dirty)• Just build some sort of

table keyed on the first AS in each pair Simple sorted pair list

within lists implementation Need to perform two way

connectivity before inserting into the table

• To process an update… Pull the AS Path Look up the first AS See if the second AS is on

the list If all pairs match, the path

is valid (it exists)

AS65003

AS65002

AS65000

AS65004

• AS65000• AS65002• AS65003

• AS65002• AS65000• AS65004

• AS65003• AS65000• AS65004

• AS65004• AS65002• AS65003

AS Based Graph• Build a DAG across the

advertisements Like SPF only don’t cull

from the TENT to the final tree

Perform two way connectivity checks when moving things into the tree

• To process an update… Start from the origin AS in

the AS Path Walk the tree If you don’t fall off the tree

getting to yourself, the path is valid (it exists)

AS65003

AS65002

AS65000

AS65004

AS65003

AS65002

AS65000

AS65004

Topology

Tree from AS65000

AS65004

(ME)

Connection Based Graph• Build the Tree

Advertise each connection separately

Build a DAG with the connection as the node

This reverses the tree – nodes are connections, edges are AS’

• To process an update For each AS in the AS

Path… Find a connection that pairs

with the next AS in the AS Path

If you don’t fall off the tree before you reach the connection to yourself, the path is valid (it exists)

AS65003

AS65002

AS65000

AS65004

AS65000AS65002

Tree from AS65000

AS65000AS65003

AS65003AS65004

AS65002AS65004

Topology

Thoughts on These Options• Sorted List

Probably more difficult to implement than it appears Probably not very efficient Hack-y

• AS Based Tree Simple to implement

SPF is well understood Easy to produce a DAG rather than a SPT

No real place to “hang” policy More difficult to hide connections

Thoughts on These Options• Connection Based Tree

Maybe more difficult to implement Perhaps more confusing to understand More advertisements per AS

One per connection, rather than one per AS Easier to hide connections

Just don’t advertise all connections to everyone Filtered advertisements are already well understood

The node becomes a place to “hang” policy Such as “no transit” Rules could be put in place about how to handle multiple policies But all policy is optional, and can be hidden (you can advertise

different things to different peers)

Security Considerations• Can’t verity the policy of the path, only the existence This is a major point of contention in some circles However, in some cases (connection based graph) this information can be added where needed

• Must advertise connections publicly for this to work Not necessarily – in the connection based graph, specifically, not all connections need to be advertised – just transits

The tree doesn’t need to be “contiguous,” there can be many DAGs for different pieces of the network

Transport Considerations• How should we transport this?

• Probably cleanest is just another AF with negotiation Can negotiate the AF on a standard eBGP peering Can set up special peers that only exchange these certificates

Certificates are transmitted “at the speed of BGP”

Background

OverviewIdea Proposal References/Notes

Origin Authentication

RPKI (SIDR) RFC6811, RFC7115

Signed Updates S-BGP Replaced by BGPSEC

BGPSEC https://datatracker.ietf.org/doc/draft-ietf-sidr-bgpsec-overview/

Graph Based soBGP http://www.cisco.com/web/about/ac123/ac147/archived_issues/ipj_6-3/securing_bgp_sobgp.htmlGenerally replaced with Path State VectorsPSV Research (no drafts, single paper)

Relationship to DNSSEC• Origin Authentication in DNS

Proposed, but never really “drafted” or written up Generally overcome by the current RPKI deployment

• DNSSEC secures A, AAA, MX, etc. No other relationship to BGP

• Might it have made sense to combine the trust chain? Argument for: A lot simpler in deployment terms Argument against: Different roots Argument against appears to have won