Upload
russ-white
View
1.354
Download
2
Tags:
Embed Size (px)
Citation preview
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